รูปแบบสถาปัตยกรรมแอปพลิเคชันบน AWS

การ Deploy แอปพลิเคชันบน AWS

Dunieski Otano

Amazon Web Services Solutions Architect

แนะนำผู้สอน

Dunieski Otano ผู้สอนประจำคอร์ส ซึ่งเป็น AWS Solutions Architect ที่มีประสบการณ์ด้านคลาวด์กว่า 10 ปี

ทำไมสถาปัตยกรรมที่เหมาะสมจึงสำคัญ

แผนภาพแบบ light theme แสดงโหนดการเลือกสถาปัตยกรรมที่แตกแขนงออกเป็น 3 ปัจจัย ได้แก่ coupling, state และ communication พร้อมไอคอนตาชั่งสำหรับ trade-off

สถาปัตยกรรมคือการแลกเปลี่ยน (trade-off) ไม่มีคำตอบที่ถูกต้องเพียงหนึ่งเดียว
- คำถาม 3 ข้อที่กำหนดทุกการตัดสินใจ:
  - องค์ประกอบต่างๆ ถูกผูกติดกัน (coupled) แน่นแค่ไหน?
  - state อยู่ที่ไหน?
  - การสื่อสารเป็นแบบ synchronous หรือ asynchronous?
- เลือก pattern ให้เหมาะกับ workload ไม่ใช่ตามกระแส

เหตุการณ์คืนวันศุกร์

Payment API ที่ช้าทำให้กระบวนการ checkout หยุดชะงัก
ทุก service รอแบบ synchronous
การแก้ปัญหาอยู่ที่สถาปัตยกรรม ไม่ใช่การทำให้ API เร็วขึ้น

เปรียบเทียบ service ที่ถูกผูกติดกันแน่นจนหยุดชะงัก กับ service ที่แยกออกจากกันด้วย message queue

สถาปัตยกรรมส่งผลต่อการ deploy อย่างไร

แผนภาพเปรียบเทียบสถาปัตยกรรมแบบ tightly coupled ที่เปราะบาง ซึ่ง service ที่ล้มเหลวหนึ่งตัวส่งผลลุกลามไปทุก service กับการออกแบบที่ยืดหยุ่นโดยใช้ queue buffer แยกความล้มเหลวออก ทำให้ service อื่นยังคงให้บริการได้

Pattern ที่เลือกกำหนดว่าแอปจะscale และล้มเหลวอย่างไร
- การออกแบบแบบ tightly coupled พังภายใต้โหลดสูง
Pattern ที่เหมาะสมทำให้การ deploy คาดการณ์ได้
- โค้ดเดิม แต่พฤติกรรมใน production ต่างกันมาก

รูปแบบสถาปัตยกรรมหลัก

Monolithic: หน่วย deploy เดียว เริ่มต้นง่าย
Microservices: service อิสระ deploy แยกกัน
Event-driven: องค์ประกอบตอบสนองต่อ event ไม่ใช่การเรียกตรง
- Fanout คือ sub-pattern ของ event-driven: event เดียวส่งถึงผู้รับหลายราย

รูปแบบสถาปัตยกรรมแอปพลิเคชัน 3 แบบเคียงกัน: monolithic เป็นบล็อกซ้อนกันหนึ่งชิ้น, microservices เป็น service อิสระที่ deploy แยกกัน และ event-driven ที่มี event bus โดย fanout แสดงเป็น sub-pattern ภายในแผง event-driven ที่ publish event เดียวไปยังผู้รับหลายราย

Stateful vs Stateless

Stateless: ไม่เก็บข้อมูล client ระหว่าง request
- instance ใดก็จัดการ request ใดก็ได้
Stateful: instance จำการโต้ตอบก่อนหน้า
Stateless ช่วยให้ขยายแนวนอน (scale horizontally) ได้
- ย้าย shared state ไปที่ DynamoDB หรือ ElastiCache

Stateless function instance ที่ request ใดก็เข้าถึงได้ทางซ้าย กับ stateful instance ที่ผูกกับ session ของ client รายเดียวทางขวา

Tight vs Loose Coupling

Tight coupling ที่ caller รอ callee ที่ช้าอยู่ทางซ้าย กับ loose coupling ที่มี SQS queue รับข้อความเพื่อให้ producer ทำงานต่อได้ทางขวา

Tight coupling: caller รอ callee ตอบกลับ
service ที่ช้าเพียงตัวเดียวทำให้ทั้งห่วงโซ่หยุดชะงัก
Loose coupling: queue ของ Amazon SQS คั่นระหว่าง service
producer ทำงานต่อได้แม้ consumer จะหยุด

Synchronous vs Asynchronous

Synchronous: caller หยุดรอผลลัพธ์
ใช้เมื่อ caller ต้องการคำตอบทันที
Asynchronous: caller ส่งงานแล้วกลับทันที
ใช้กับงานที่ช้า, มาเป็นชุด หรือไม่เร่งด่วน

Synchronous call ที่ caller รอจนได้ response ทางซ้าย กับ asynchronous handoff ที่คืนค่าทันทีและประมวลผลเบื้องหลังทางขวา

รูปแบบความยืดหยุ่นสำหรับการเรียก third-party

Retry with exponential backoff: รอนานขึ้นระหว่างการลองใหม่แต่ละครั้ง
Circuit breaker: หยุดเรียก service ที่ล้มเหลวชั่วคราว
Dead-letter queue: เก็บข้อความที่ล้มเหลวซ้ำๆ ไว้พัก
ใช้ร่วมกัน เพราะการ retry แบบไม่จำกัดยิ่งทำให้ outage รุนแรงขึ้น

รูปแบบความยืดหยุ่น 3 แบบ: กราฟ retry แบบ exponential backoff, circuit breaker ที่หยุดการเรียก service ที่ล้มเหลว และ dead-letter queue ที่จับข้อความซึ่งหมด retry แล้ว

มาฝึกกันเถอะ!

การ Deploy แอปพลิเคชันบน AWS