Autoscaling

ถ้าคุณโชคดีพอที่จะมีการ provisioning virtual host ที่ automate ได้เต็มรูปแบบ และสามารถ automate การ deploy microservice instance ของคุณได้เต็มรูปแบบ คุณก็มี building block ที่ช่วยให้คุณ scale microservice ของคุณโดยอัตโนมัติ

ตัวอย่างเช่น คุณสามารถให้ scaling ถูก trigger โดย trend ที่รู้จักกันดี คุณอาจรู้ว่าโหลด peak ของระบบคุณอยู่ระหว่าง 9 โมงเช้าถึง 5 โมงเย็น ดังนั้นคุณเปิด instance เพิ่มเติมตอน 8:45 น. และปิดพวกมันตอน 5:15 น. ถ้าคุณกำลังใช้บางอย่างเช่น AWS (ซึ่งมีการรองรับ autoscaling ในตัวที่ดีมาก) การปิด instance ที่คุณไม่ต้องการอีกต่อไปจะช่วยประหยัดเงิน คุณจะต้องมีข้อมูลเพื่อเข้าใจว่าโหลดของคุณเปลี่ยนแปลงอย่างไรเมื่อเวลาผ่านไป จากวันสู่วัน และจากสัปดาห์สู่สัปดาห์ ธุรกิจบางแห่งก็มี seasonal cycle ที่ชัดเจนด้วย ดังนั้นคุณอาจต้องมีข้อมูลย้อนหลังไปพอสมควรเพื่อตัดสินใจได้อย่างเหมาะสม

ในทางกลับกัน คุณสามารถเป็นแบบ reactive เปิด instance เพิ่มเติมเมื่อคุณเห็นโหลดเพิ่มขึ้นหรือ instance ล้มเหลว และเอา instance ออกเมื่อคุณไม่ต้องการมันอีกต่อไป การรู้ว่าคุณ scale up ได้เร็วแค่ไหนเมื่อคุณเห็น trend ขาขึ้นเป็นกุญแจสำคัญ ถ้าคุณรู้ว่าคุณจะได้แค่การแจ้งเตือนสองสามนาทีเกี่ยวกับโหลดที่เพิ่มขึ้น แต่การ scale up จะใช้เวลาอย่างน้อย 10 นาที คุณก็รู้ว่าคุณต้องเก็บ capacity สำรองไว้เพื่อเชื่อมช่องว่างนี้ การมีชุด load test ที่ดีแทบจะจำเป็นในที่นี้ คุณสามารถใช้พวกมันเพื่อทดสอบกฎ autoscaling ของคุณ ถ้าคุณไม่มีเทสต์ที่สามารถจำลองโหลดที่แตกต่างกันที่จะ trigger scaling คุณก็จะรู้ตัวว่าตั้งกฎผิดก็ต่อเมื่อไปเจอใน production เท่านั้น และผลกระทบของความล้มเหลวก็ไม่ดีเลย!

เว็บไซต์ข่าวเป็นตัวอย่างที่ดีของประเภทธุรกิจที่คุณอาจต้องการผสม predictive และ reactive scaling เข้าด้วยกัน ในเว็บไซต์ข่าวล่าสุดที่ผมทำงาน เราเห็น trend รายวันที่ชัดเจนมาก ที่ยอดวิวไต่ขึ้นจากตอนเช้าไปจนถึงเที่ยงแล้วเริ่มลดลง รูปแบบนี้เกิดซ้ำวันแล้ววันเล่า โดย traffic มักต่ำกว่าในวันหยุดสุดสัปดาห์ นั่นให้ trend ที่ค่อนข้างชัดเจนแก่เราที่สามารถขับเคลื่อนการ scale ทรัพยากรเชิงรุกได้ ไม่ว่าจะขึ้นหรือลง ในทางกลับกัน ข่าวใหญ่ตัวหนึ่งก็อาจทำให้เกิด spike ที่ไม่คาดคิด ต้องการ capacity มากขึ้นและมักจะเป็นแบบกะทันหัน

ผมเห็น autoscaling ถูกใช้เพื่อรับมือความล้มเหลวของ instance มากกว่าเพื่อตอบสนองต่อสภาพโหลดจริงๆ AWS ให้คุณระบุกฎอย่าง "ควรมี instance อย่างน้อยห้าตัวในกลุ่มนี้" ดังนั้นถ้า instance หนึ่งล่ม instance ใหม่จะถูกเปิดขึ้นโดยอัตโนมัติ ผมเคยเห็นวิธีนี้นำไปสู่เกม whack-a-mole ที่สนุกสนาน เมื่อใครสักคนลืมปิดกฎแล้วพยายามนำ instance ลงเพื่อบำรุงรักษา แต่กลับเห็นมันเปิดขึ้นมาใหม่เรื่อยๆ!

ทั้ง reactive และ predictive scaling ล้วนมีประโยชน์มาก และสามารถช่วยให้คุณคุ้มค่ากับต้นทุนมากขึ้นถ้าคุณใช้แพลตฟอร์มที่ให้คุณจ่ายแค่สำหรับทรัพยากร computing ที่คุณใช้ แต่พวกมันก็ต้องการการสังเกตข้อมูลที่มีให้คุณอย่างระมัดระวัง ผมขอ แนะนำให้ใช้ autoscaling สำหรับเงื่อนไขความล้มเหลวก่อนในขณะที่คุณเก็บข้อมูล เมื่อคุณต้องการเริ่ม autoscaling สำหรับโหลด มั่นใจว่าคุณระมัดระวังมากเกี่ยวกับการ scale down เร็วเกินไป ในสถานการณ์ส่วนใหญ่ การมีพลัง computing มากกว่าที่คุณต้องการดีกว่าการมีไม่พอมาก!