สถาปัตยกรรมเหมือนกัน ทำไมรูปแบบทราฟฟิกถึงสำคัญกว่าไดอะแกรม
เรียนรู้เหตุผลที่โปรเจกต์ไอทีสองงานอาจใช้สถาปัตยกรรมแบบเดียวกันแต่ต้องการการปรับใช้ต่างกัน พร้อมเจาะลึกการเลือกใช้ EC2 ร่วมกับ Ansible สำหรับรับมือทราฟฟิกพุ่งสูง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- สถาปัตยกรรมและไดอะแกรมเหมือนกันไม่ได้หมายความว่าต้องใช้วิธีการปรับใช้ (deployment) แบบเดียวกัน
- รูปทรงของทราฟฟิกและลักษณะการใช้งานของแอปพลิเคชันคือตัวตัดสินใจเลือกโครงสร้างพื้นฐานที่แท้จริง
- การเลือกใช้ EC2 ร่วมกับ Auto Scaling และ Ansible ช่วยประหยัดต้นทุนสำหรับโปรเจกต์ที่มีช่วงทราฟฟิกพุ่งสูงตามกำหนดการ
- การเตรียมความพร้อมในระดับโค้ดและการทดสอบโหลด (load test) สำคัญกว่าการพึ่งพาบริการบนคลาวด์เพียงอย่างเดียว
คำแนะนำในการปรับใช้ระบบส่วนใหญ่มักเริ่มต้นที่สถาปัตยกรรม การวาดกล่อง เลือกบริการ และนำระบบขึ้นใช้งานคือกิจวัตรทั่วไปที่วิศวกรคุ้นเคย จนกระทั่งโปรเจกต์ของลูกค้างานหนึ่งได้เปลี่ยนแปลงมุมมองนั้นไปโดยสิ้นเชิง
โปรเจกต์สองงานสามารถมีแผนผัง, ไดอะแกรมสถาปัตยกรรม และโครงสร้างที่เหมือนกันทุกประการ แต่ยังคงต้องการการปรับใช้ที่แตกต่างกันอย่างสิ้นเชิง สิ่งที่เป็นตัวชี้วัดความแตกต่างนี้คือฟีเจอร์ของแอปพลิเคชันและรูปทรงของทราฟฟิก (traffic shape) ที่วิ่งเข้ามาใช้งาน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ผู้พัฒนาซอฟต์แวร์รายหนึ่งได้เข้ามาดูแลโปรเจกต์และตัดสินใจย้ายระบบไปไว้บน AWS EC2 เป็นอันดับแรก โดยมีโจทย์สั้นๆ ว่าต้องรักษาความปลอดภัยให้รัดกุมและป้องกันไม่ให้ระบบล่มเมื่อทราฟฟิกพุ่งกระโดด ทราฟฟิกของระบบไม่ได้มีปริมาณมหาศาลนัก โดยอยู่ที่ประมาณ 3,000 User ต่อวัน แต่จุดที่น่าสนใจคือรูปแบบการเคลื่อนไหวของปริมาณการใช้งานที่มีช่วงเวลาพุ่งสูงขึ้นอย่างชัดเจน ซึ่งสามารถรับรู้ล่วงหน้าได้จากกำหนดการของอีเวนต์และเดือนธันวาคม หากเลือกใช้เซิร์ฟเวอร์แบบตายตัว (fixed servers) ระบบจะต้องแบกรับต้นทุนที่สูงเกินความจำเป็นตลอดทั้งปี หรือไม่ก็มีขนาดเล็กเกินไปในวันที่มีการปล่อยผลิตภัณฑ์ใหม่
การวิเคราะห์เพิ่มเติม: ปัญหาสถาปัตยกรรมคลาวด์มักไม่ได้เกิดจากตัวระบบ AWS เอง แต่ส่วนใหญ่มักมีรากฐานมาจากโค้ดภายในแอปพลิเคชันและการจัดการทราฟฟิกที่ไม่สอดคล้องกัน การเลือกใช้บริการที่มีราคาสูงอย่าง Fargate ตลอดทั้งปีอาจไม่ใช่คำตอบที่ดีที่สุด หากเราสามารถคาดการณ์ช่วงเวลาที่ทราฟฟิกจะพุ่งสูงล่วงหน้าได้ การวางแผนปรับขนาดอัตโนมัติตามกำหนดการ (scheduled scaling) จึงเป็นทางออกที่คุ้มค่ากว่าในแง่ของงบประมาณองค์กร
ในการตัดสินใจเลือกใช้ EC2 ร่วมกับ Auto Scaling มีเหตุผลหลักอยู่ 3 ประการ ได้แก่ ปริมาณทราฟฟิกยังอยู่ในระดับน้อย, ทราบวันที่ทราฟฟิกจะพุ่งสูงล่วงหน้าอย่างชัดเจน, และมีบทบาทการตั้งค่าระบบ (Ansible roles) ที่เตรียมไว้เรียบร้อยแล้ว การปรับขนาดตามกำหนดการช่วยรองรับช่วงที่ทราฟฟิกพีคโดยไม่ต้องจ่ายค่าบริการราคาสูงของ Fargate ตลอดทั้งปี ยกเว้นแต่ในกรณีที่ทีมงานไม่มีใครต้องการดูแลเรื่องการแพทช์ระบบ ทางเลือกอย่าง Fargate จึงจะถูกนำมาพิจารณาแทน
แนวทางปฏิบัติในการตั้งค่าระบบเพื่อป้องกันปัญหา ได้แก่ การรักษากำลังการผลิตขั้นต่ำด้วยอินสแตนซ์จำนวน 2 ตัวใน 2 โซนความพร้อม (availability zones) เพื่อให้ระบบยังคงทำงานต่อได้หากมีตัวใดตัวหนึ่งล่ม, การใช้กฎการปรับขนาดแบบติดตามเป้าหมาย (target tracking) ที่ระดับ CPU ประมาณ 60% หรือใช้คำขอต่อเป้าหมาย (requests per target) ตามปริมาณการใช้งานจริง, และการตั้งค่าการกระทำตามกำหนดการล่วงหน้าก่อนวันปล่อยผลิตภัณฑ์ เนื่องจากอินสแตนซ์ใหม่ต้องใช้เวลาหลายนาทีกว่าพร้อมใช้งาน การรอให้ทราฟฟิกพุ่งเข้ามาเสียก่อนจึงสายเกินไป
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ในส่วนของการจัดการฐานข้อมูลและการตั้งค่าโค้ด สิ่งที่ต้องระวังเป็นพิเศษคือการเปรียบเทียบจำนวนการเชื่อมต่อสูงสุด (maximum connections) กับจำนวนอินสแตนซ์คูณด้วยขนาดพูล (pool size) ซึ่งมักเป็นเรื่องเซอร์ไพรส์ที่พบบ่อยที่สุดเมื่อแอปพลิเคชัน Node.js ขยายขนาดออกไป นอกจากนี้ Node.js ทำงานบน 1 คอร์ต่อ 1กระบวนการ (process) บนอินสแตนซ์ 2-vCPU การใช้งาน CPU จึงอาจไม่เกิน 50% ทำให้กฎที่อิงตาม CPU ทำงานไม่ถูกต้อง การใช้งาน PM2 cluster mode หรือการปรับขนาดตามคำขอจึงเป็นทางออกที่เหมาะสมกว่า
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น