ใครที่อาจจะใหม่ต่อระบบ infrastructure ของระบบ Cloud เช่น Microsoft Azure หรือ Amazon โดยเฉพาะในส่วน App Service อาจจะไม่เข้าใจความสามารถที่เรียกว่า Scaling หนำซ้ำยังมีแตกออกแบบ 2 แบบใหญ่ๆ นั่นคือ
- Scale Up/Down
- Scale Out/In
มาๆ ทำความเข้าใจกันง่ายๆ กับโค้ชพลกัน
เมื่อความต้องการมันเยอะกว่าทรัพยากรที่เรามี
Image by Tumisu, please consider ☕ Thank you! 🤗 from Pixabay
ในที่นี้ลองมองภาพง่ายๆ ว่าถ้าเราซื้อคอม หรือมือถือมาสักเครื่องเพื่อเล่นเกมส์ และพอเราโหลดเกมส์มาเล่นแล้วกลับพบว่า
อ้าวกระตุกแหะ
ซึ่งก็มักจะเกิดจากที่เครื่องเราไม่แรงพอ แรมไม่เยอะพอ หรือการ์ดจอไม่เทพพอ อะไรก็แล้วแต่ แต่เรารู้ว่า เครื่องเรามันเล่นเกมส์นี้พอไหว แต่อาจจะไม่ดีพอ
และในสถานการณ์อื่นๆ ก็อาจจะไหวแต่กระตุก หรือไม่ก็เครื่องค้างไปเลย
เครื่องไม่แรงพอทำไงดี?
ถ้าเป็นเกมส์บนเครื่องเรา เราก็อาจจะปรับความงามของกราฟฟิกในเกมส์ลงหน่อยใช่ไหม
แต่กับพวกระบบที่รองรับการใช้งานอย่างเช่นเครื่องคอมพิวเตอร์ที่ใช้รัน Web App หรือ Web API ที่เราจะไปบอกให้ผู้ใช้เพลาๆ การกดเข้าแอพเราหน่อยไม่ได้เนี่ย มักจะมีจุดจบที่เว็บรองรับการใช้งานไม่ไหว หรืออย่างพวกเว็บล่มที่เราเห็นกันบ่อยๆ
ดังนั้นจะทำยังไงล่ะ? ถ้าเป็นการเล่นเกมส์ เราก็คงเปลี่ยนการ์ดจอให้แรงขึ้น หรือไม่ก็ยกคอมไปร้าน
แต่มันทำไม่ได้กับพวกบริการที่อยู่บน Cloud ไงครับ
ทางออกของเราคือ
การทำ Scaling นั่นเอง
Scaling
ตอนเราใช้บริการพวก Cloud เช่น Azure App Service มันจะให้เราเลือกแพคเกจก่อนใช่ไหม ว่าอยากใช้แบบแรงแค่ไหน (ราคาก็ไปตามแพคเกจความแรง) ซึ่งเราอาจจะเลือกแบบต่ำๆ ไว้ก่อน
แต่เวลาใช้งานจริง ผู้ใช้อาจจะกระหน่ำเข้ามาใช้เกินกว่าที่เราเลือกไว้ตอนแรกจะรับไหว
ก็เราก็สามารถทำ Scaling ได้ครับ มันก็คล้ายๆ กับการเพิ่มประสิทธิภาพของแพคเกจที่เราใช้รัน Web App หรือ Web API ในปัจจุบัน ให้รองรับการทำงานได้มากขึ้นในช่วงเวลานั้นๆ นั่นเอง
โดยการทำ Scaling นั้นได้รับความนิยมมาก เพราะว่า
- Scaling เพิ่มแล้ว ค่าใช้จ่ายก็ต้องเพิ่มใช่ไหม? แต่ไม่เพิ่มตลอดไปหรอก เราสามารถปรับลงมาที่ระดับเดิมได้ เมื่อความต้องการใช้ระบบของเราไม่เยอะแล้ว
- สามารถเลือกวิธี Scale ได้ตามความต้องการ นั่นคือ Scale Up/Down หรือ Scale Out/In ซึ่งเดี๋ยวจะเล่าต่อด้านล่าง
- การทำ Scale ไม่จำเป็นต้องหยุดการทำงานของ Web App หรือ Web API ที่ทำงานอยู่
Scaling Up/Down
ตัวเลือกแรกที่หลายคนเข้าใจคือตัวนี้แหละ สำหรับระบบ Cloud ทั่วไปมันคือการเลือกปรับแพคเกจ (ใน Azure App Service เรียกว่า Pricing Tier) ซึ่งจะรวมไปถึง
- การเพิ่ม CPU, Memory, พื้นที่ฮาร์ดดิสก์
- custom domain, custom certificate
- เพิ่ม Staging Slot อันนี้เป็นเรื่องของ Deployment Slot ใน Azure App Service
และในการทำ Scale Down ก็คือการปรับแพคเกจ หรือ Pricing tier ลงมานั่นเอง
Scaling Out/In
อีกแบบที่ได้รับความนิยมไม่แพ้กันคือตัวนี้ เพราะแทนที่จะเพิ่ม CPU, Ram ให้กับ Service ของเรา (เหมือนยกเครื่องไปที่ร้าน) มันเปรียบเหมือนการซื้อเครื่องเพิ่มครับ (VM Instance) ลองนึกถึงเราไปซื้อเครื่องคอมสเปกเดียวกันอีกเครื่องมาต่อกันให้พลังประมวลผลเพิ่มขึ้น
อันนี้ถ้ามองเป็นการเล่นเกมส์อาจจะเปรียบได้กับการใช้การ์ดจอ 2 ใบ หรือ 3 ใบมาประมวลผลร่วมกันได้ แต่เราจะไม่ค่อยเห็นเคสนี้ใช่ไหม
แต่ในการทำงานของระบบที่รัน Web App หรือ Web API การทำแบบนี้สามารถทำได้ครับ
แต่แทนที่ผู้ให้บริการ Cloud จะขับรถออกไปซื้อคอมจริงๆ มาเพิ่มให้เรา เขาจะสร้างส่ิงที่เรียกว่า Virtual Machine Instance ขึ้นมา (ระบบจำลองคอมพิวเตอร์เสมือน) ซึ่งสามารถทำได้ทันที่เรากดปุ่มยืนยันการ Scale
- Scale out สามารถทำด้วยการสั่งงานผ่านหน้าเว็บ (Manually)
- หรือจะตั้งเงื่อนไขเตรียมไว้ก่อนก็ได้ เรียกว่า Autoscaling ซึ่งเงื่อนไขจะถูกเรียกว่า Rule
- ใน Azure App Service แบบ Isolated tier จะสามารถ Scale-out ได้ถึง 100 VM Instances
นั่นล่ะ ภาพรวมของคำว่า Scaling Up/Down/Out/In
สนใจเรียนแบบเข้มข้น เข้าใจง่ายๆ สบายๆ กับโค้ชพลดูคอร์สได้ที่นี่ หรือติดต่อสอบถามบริการจัดอบรม In-house ตามข้อมูลด้านล่างครับ
- ติดตามจากแฟนเพจ Nextflow
- กดติดตามคลิปใหม่ๆ Subscribe YouTube Channel ของพลได้เลย
- โทรติดต่อบริการจัดอบรม 083-071-3373 คลิกโทรผ่านมือถือได้เลย
- สอบถามผ่านทาง LINE คลิก
- สอบถามผ่านทาง Facebook คลิก
