สรุปเนื้อหา Building mission-critical workloads with containers on AWS ใน AWS Summit Bangkok 2025

สวัสดีครับผม ต้า ครับ

วันที่ 29 เมษายน 2025 ที่ผ่านมามีงาน AWS Summit Bangkok 2025 ซึ่งผมได้เข้าร่วมงานนี้มา และนี่เป็นเนื้อหาใน Session Building mission-critical workloads with containers on AWS จะมีเนื้อหาอย่างไรเชิญรับชมได้เลยครับ

Amazon ECS: บริการคอนเทนเนอร์ที่ยืดหยุ่นและทนทาน

Amazon Elastic Container Service (ECS) เป็นบริการจัดการคอนเทนเนอร์ของ AWS ที่มีการใช้งานอย่างแพร่หลายและมีการเติบโตอย่างต่อเนื่อง ในการนำเสนอที่ AWS Summit โซลูชั่นอาร์คิเทคจาก AWS ได้อธิบายว่า ECS สามารถถูกเลือกใช้งานได้หลากหลายรูปแบบ ไม่ว่าจะเป็นการ deploy บน EC2, บน Fargate ที่ไม่ต้องบริหารจัดการคอมพิวต์หลังบ้าน หรือแม้แต่การ deploy บนเดต้าเซ็นเตอร์ของตนเองในลักษณะไฮบริด

ความแตกต่างระหว่าง Availability และ Reliability

ใน Session ได้อธิบายความแตกต่างระหว่างสองคำสำคัญ:

• Availability (ความพร้อมใช้งาน): คือความสามารถในการให้บริการได้อย่างต่อเนื่อง เปรียบเทียบได้กับตู้ ATM ที่อาจมีการใช้งานไม่ได้บางครั้ง แต่โดยรวมยังมีความพร้อมใช้งานสูง (เช่น 98%)
• Reliability (ความน่าเชื่อถือ): คือความสามารถในการทนทานต่อความล้มเหลว เมื่อเกิดปัญหากับส่วนประกอบหนึ่ง ระบบยังสามารถทำงานต่อไปได้

โครงสร้างของ AWS Region และ Availability Zones

AWS สร้างบริการบนพื้นฐานของความทนทาน โดยแต่ละ Region ประกอบด้วย Availability Zones (AZ) อย่างน้อย 3 โซน แต่ละ AZ ทำงานอิสระจากกัน แต่เมื่อทำงานร่วมกันจะเป็นผืนเดียวกัน หากเกิดปัญหากับ AZ ใด AZ อื่นๆ จะไม่ได้รับผลกระทบและยังคงทำงานได้ตามปกติ

การออกแบบ Amazon ECS เพื่อความทนทาน

ECS มีหัวใจสำคัญคือ Control Plane ที่ทำหน้าที่จัดการการ deploy ต่างๆ โดย AWS ได้ออกแบบให้ Control Plane มีความทนทานสูง:

1. การกระจาย Control Plane: ECS Control Plane ถูก deploy แยกตาม Region เพื่อป้องกันไม่ให้ปัญหาใน Region หนึ่งส่งผลกระทบต่อ Region อื่น
2. การกระจายใน AZ: ภายในแต่ละ Region, Control Plane ถูก deploy ในทุก Availability Zone
3. การ Pre-scale: มีการเตรียมทรัพยากรสำรองเพื่อรองรับกรณีที่ AZ หนึ่งมีปัญหา โดย AZ ที่เหลือสามารถรองรับงานได้ 100%
4. การแบ่ง Partition: Control Plane ไม่ได้เป็นระบบใหญ่เพียงระบบเดียว แต่ถูกแบ่งเป็น partition ย่อยๆ หลายส่วน แต่ละส่วนมีขนาดเล็กลงแต่ยังคงฟังก์ชันการทำงานเหมือนเดิม แต่ละ partition รับผิดชอบแต่ละคลัสเตอร์ของ ECS แยกกัน
5. การ Deploy แบบทยอย: เมื่อมีการอัพเดต AWS จะ deploy ทีละคลัสเตอร์ หากเกิดปัญหากับ partition ใด จะไม่กระทบกับ partition อื่น

คำแนะนำสำหรับผู้ใช้ ECS

ผู้ใช้งาน ECS ควรทำตามแนวทางเหล่านี้:

1. กระจายการ Deploy: ควรกระจาย task ให้อยู่ในหลาย AZ ไม่ควรกระจุกตัวในโซนเดียว
2. ใช้ Fargate: Fargate จะช่วยบริหารจัดการการกระจาย task ในหลาย AZ
3. ใช้หลายคลัสเตอร์: ควร deploy แอปพลิเคชันในหลายคลัสเตอร์ เพื่อให้หากคลัสเตอร์หนึ่งมีปัญหา คลัสเตอร์อื่นยังทำงานได้

ขนาดและความซับซ้อนของ ECS

ECS เป็นซอฟต์แวร์ที่มีความซับซ้อนและขนาดใหญ่ การใช้งาน ECS ของ AWS เองในหนึ่งสัปดาห์มีการสร้าง task มากถึง 2,400 ล้าน task ซึ่งเทียบเท่ากับจำนวนประชากรของประเทศจีนรวมกับประเทศรัสเซีย แต่ AWS สามารถบริหารจัดการได้อย่างราบรื่น

กรณีศึกษา: สำนักงานพัฒนารัฐบาลดิจิทัล (DGA) กับแอปพลิเคชัน "ทางรัฐ"

จากสำนักงานพัฒนารัฐบาลดิจิทัล (DGA) ได้แบ่งปันประสบการณ์การใช้งาน ECS กับแอปพลิเคชัน "ทางรัฐ" ซึ่งเป็นแอปพลิเคชันที่รวบรวมบริการภาครัฐไว้ในที่เดียว:

ความท้าทาย:

• เดิมแอปพลิเคชันทางรัฐมีผู้ใช้งานประมาณ 5 แสนคน และมียอดการใช้งานสะสมประมาณ 14 ล้านครั้ง
• เมื่อรัฐบาลประกาศให้ประชาชนลงทะเบียนผ่านแอปพลิเคชันทางรัฐเพื่อรับสิทธิ์ดิจิทัลวอลเล็ต DGA ไม่ได้เตรียมตัวมาก่อน
• ระบบเดิมที่อยู่บนเซิร์ฟเวอร์ส่วนตัวรองรับธุรกรรมได้เพียง 50,000 รายการต่อวัน

การแก้ปัญหา:

1. ย้ายขึ้นคลาวด์: DGA ย้ายโครงสร้างพื้นฐานทั้งหมดขึ้นไปอยู่บนคลาวด์ภายในเวลา 2-3 เดือน
2. เริ่มใช้คอนเทนเนอร์: แม้ว่าในช่วงแรกยังใช้เทคโนโลยีเดิม แต่การย้ายขึ้นคลาวด์ช่วยให้รองรับธุรกรรมได้ 1-2 ล้านรายการต่อวัน
3. ปรับใช้ Container Service: ในที่สุด DGA ได้ย้ายบริการสำคัญมาอยู่บน ECS โดยรันประมาณ 1,800 container pods

ผลลัพธ์:

• สามารถรองรับผู้ใช้งานได้ถึง 18 ล้านคนในวันที่มีการลงทะเบียนสูงสุด
• ปัจจุบันมีผู้ใช้งานประมาณ 35 ล้านคน
• มีบริการกว่า 200 บริการจาก 100 หน่วยงาน
• มียอดการใช้งานสะสมกว่า 700 ล้านครั้ง
• ผู้ใช้งานได้รับการพิสูจน์และยืนยันตัวตนในระดับเดียวกับธนาคาร (IAL2.3)

ข้อดีของ Container Service เมื่อเทียบกับ Kubernetes:

• บริหารจัดการง่ายกว่า
• ไม่ต้องกังวลเรื่องจำนวนคลัสเตอร์และการจัดการคลัสเตอร์
• สามารถมองภาพรวมแบบเป็น serverless service ได้
• ประสิทธิภาพการทำงานใกล้เคียงกับ Kubernetes

อนาคตของแอปพลิเคชัน "ทางรัฐ"

DGA มีแผนพัฒนาแอปพลิเคชันทางรัฐให้เป็น "ซูเปอร์แอป" ของประเทศไทย โดยจะเพิ่มบริการใหม่ๆ เช่น:

• การใช้จ่ายเงินผ่านดิจิทัลวอลเล็ต
• การลงทะเบียนและใช้สิทธิ์รถไฟฟ้า 20 บาท
• การขยายบริการภาครัฐให้หลากหลายและใช้งานง่ายยิ่งขึ้น

การใช้ Container Service ช่วยให้ทีมพัฒนาลดความกังวลเรื่องระบบล่มเมื่อมีผู้ใช้งานจำนวนมาก เพราะมั่นใจได้ว่าระบบมีความทนทานและพร้อมรองรับการขยายตัวในอนาคต