AWS Summit Bangkok 2025 : สร้าง EDA ด้วย containers (Building event-driven architectures with containers)
2025.06.25สวัสดีค่ะผู้อ่าน DevelopersIO ทุกคน เฟินจาก Classmethod Thailand ค่ะ
วันนี้จะมาแชร์ข้อมูลจากเซสชั่นที่ได้เข้าร่วมฟังมาเมื่อวันที่ 29 เมษายนที่งาน AWS Summit Bangkok 2025 ที่ผ่านมาค่า
“Building event-driven architectures with containers” หรือภาษาไทยก็คือ “สร้าง EDA ด้วย containers ”
Event-driven architecture หรือ EDA คืออะไร
__อันดับแรกที่ควรรู้ในการทำความเข้าใจ EDA ได้แก่ Event __
Even คือ Signal บางอย่างของเหตุการณ์ที่เกิดขึ้นในระบบและเป็นสิ่งที่ ”เกิดขึ้นแล้ว” ไม่สามารถเปลี่ยนแปลงได้โดย format เกิดจากตามที่ตกลงกันไว้แล้ว
คำนิยามของ Event-driven architecture
Something happens -> We react
มีบางอย่างเกิดขึ้นในระบบ และมีบางส่วนในระบบตอบสนองกับมัน
มาดูตัวอย่างให้เห็นภาพกันค่ะ
ในระบบที่เป็น Non-EDA หากเรามี producer ที่สร้าง event ออกมาแล้วต้องสื่อสารกับ consumer ว่าเกิดอะไรขึ้นมาแล้วและจะเรียกยังไง ในส่วนนี้จะเกิดสิ่งที่เรียกว่า "Tight Coupling" เพราะ producer ต้องรู้จัก consumer
แต่ในโลกของ EDA ตัว Producer รู้ว่าเกิด event แต่ไม่จำเป็นต้องรู้จัก consumer ตรงนี้ทำให้เกิดการ decoupling
Integration patterns
การสื่อสารระหว่าง component
Synchronous request response model
แพทเทิร์นแรกเป็น Standard ที่ developers ทุกท่านน่าจะคุ้นเคย
producer ส่ง request ไปและทาง consumer ส่ง response กลับมา
เป็นแพทเทิร์นที่ง่ายๆ latency ไม่เยอะและถ้า fail เราก็รู้ได้ แต่ชาเลนจ์ของแพทเทิร์นนี้ในกรณีที่เรามี request เยอะมากๆทำให้ response ไม่ทันทำให้ Throttling ได้
Asynchronous communication
เป็นแพทเทิร์นที่ใช้งานค่อนข้างเยอะใน EDA
การแก้ไขปัญหาที่เจอในการใช้ Synchronous โดยการเปลี่ยนมาใช้ Asynchronous communication และใส่ Broker เข้าไปตรงกลางที่จะช่วยให้ producer ไม่ต้องรู้เรื่องราวของ consumer ก็ได้รู้แค่ว่า Broker ได้รับ request หรือยัง
ในเซสชั่นนี้พูดถึงแพทเทิร์นของ Broker ใหญ่ๆ ได้แก่
1. Event Routers
・route ได้ทีละ 1 event
1.1 Event Routers - Event buses
ความสามารถพิเศษคือสามารถสร้าง rule หรือ logic ในการ route event ที่ตัว event buses เอง ตัวเซอร์วิสของ AWS ที่ซัพพอร์ทการใช้งานแพทเทิร์นนี้ก็คือ Amazon EventBridge
1.2 Event Routers - Event Topics
ต่างกับ event buses ตรงที่ Event Topics จะแบ่ง event ออกมาเป็น topic consumer อยากได้ event ตรงไหนก็เลือกเอาจาก Topics ตัวเซอร์วิสของ AWS ที่ซัพพอร์ทการใช้งานแพทเทิร์นนี้ก็คือ Amazon SNS(Amazon Simple Notification Service)
2. Event Stores
การรัน Event ด้วย Batch
2.1 Event Stores - Queues
Consumer ทุกตัวไม่จำเป็นต้องได้รับเมสเสจเดียวกันแต่จะใช้ Consumer 1 ตัวในการโพรเซสตัวเดต้า
โดยตัวเซอร์วิสของ AWS ที่ซัพพอร์ทการใช้งานแพทเทิร์นนี้ก็คือ Amazon SQS (Amazon Simple Queue Service) และ Amazon MQ
2.2 Event Stores - Stream
ตัวนี้จะต่างกับ Queue ตรงที่ Consumer ทุกตัวจะได้รับทุก Event การ Filtering ต่างๆต้องทำที่ตัว Consumer เอง
โดยตัวเซอร์วิสของ AWS ที่ซัพพอร์ทการใช้งานแพทเทิร์นนี้ก็คือ Amazon Kinesis Data Streams และ Amazon MSK
เซอร์วิสทั้งหมดที่ได้พูดถึงไปทั้งหมดใช้ในการ Integration เพื่อเชื่อมต่อระหว่าง distributed components กับ microservice
ต่อมาเราจะมาดูที่ตัว distributed components ที่สามารถสร้างในลักษณะ Container ได้ค่อนข้างสะดวก
บริการ Container ของ AWS มีหลายตัวแต่ในเซสชั่นนี้จะนำเสนอ AWS Fargate
Amazon ECS on AWS Fargate
AWS Fargate เป็นบริการ serverless compute engine ที่จะช่วยให้เราใช้งาน container ได้โดยไม่ต้องดูแลในส่วนของอินฟราเอง เราแค่สร้าง container image กำหนด task ว่าต้องการ task แบบไหน แค่นี้ตัว Fargate ก็จะสร้างโค๊ดตามที่เราตั้งค่าออกมา
แพทเทิร์นในการรัน Fargate
1.Running as Standalone Task
・รันใช้งานเวลาที่ต้องการใช้งาน
・เรากำหนด task ให้ Amazon ECS หลังจากนั้น ECS จะสร้าง Task ขึ้นมาและส่งให้ Fargate รันต่อ
2.Running as service
・รัน workload ของ webservice, API etc.
・เรากำหนดให้ Amazon ECS เราต้องการกี่ Replica ของ task service และ ECS จะช่วย maintain ตามที่เราต้องการ
EDA journey from ascend money
พาร์ทหลังจะเป็นในส่วนของทาง ascend money ผู้ให้บริการ financial service และที่เรารู้จักกันเป็นอย่างดีนั่นก็คือแอปทรูมันนี่ มาแชร์ประสบการณ์การใช้งานบริการ container นะคะ
ปัจจุบันเบื้องหลังของแอปทรูมันนี่รันอยู่บน EKS มี microservice มากกว่า 700 โดยใช้ตัว event และ message broker จาก AWS เช่นกัน
อดีตทางทีมเองก็ใช้แพทเทิร์นดั้งเดิมอย่าง Synchronous เหมือนกัน แต่ตัว payment service ต้องเข้าใจ behavior ทั้งหมด เมื่อมี user เพิ่มขึ้นและตัวแอปต้องสเกลให้ทันตาม transaction ทางทีมจึงเริ่มเอา EDA มาใช้งาน
pain point ที่เจอ
・เวลามี change ที่ microservice บางตัว อาจจะ impact กับ microservice ตัวอื่น หรือ เมื่อ microservice ตัวนึงมีปัญหาทำให้เกิดปัญหากับ payment ทั้งระบบ
จากเดิมที่ payment ต้องเรียกไปหา user มีการใช้ queue มาคั่นระหว่าง service และใส่ message request เข้าไปใน queue ทำให้ user ไป consume ตัว message มาจาก queue แทนที่จะรอรับ API ทำให้เกิดการ Decoupling เซอร์วิสจากกัน โดยเทคโนโลยีที่นำมาใช้ได้แก่ Amazon MQ และ Amazon MSK ที่ช่วยให้ MQ และ ฺBroker ทำงานได้ดีขึ้น
สรุป
ข้อดีของการใช้ container กับ EDA
・สามารถใช้ ci/cd pipeline เดียวกับหลาย ๆ application ได้
・scale up/down ได้ง่าย
・ลดค่าใช้จ่ายได้ เช่น รัน database บน container ถูกกว่าสร้าง database จริง ๆ ขึ้นมา
ถ้าใช้ container แนะนำให้ใช้ ecs
・ecs integrate กับ aws service อื่นได้ง่าย
・มี autoscaling ให้
ถ้าใช้ ecs แนะนำให้ใช้ fargate
・เป็น serverless ลด overhead ในการจัดการ server แบบ manual
・ยืดหยุ่นกว่า สามารถ scale up/down ได้ง่าย เร็ว ไม่ต้องรอสร้าง ec2 เอง ถูกกว่า จ่ายเท่าที่ใช้
สำหรับท่านที่สนใจเนื้อหาบริการ container ของ AWS สามารถดูเพิ่มเติมได้ที่หน้าเว็บของ AWS ด้านล่างนี้ได้เลยค่า
