บันทึกการปรับปรุงสถาปัตยกรรมสำหรับไปป์ไลน์ข้อมูลเรียลไทม์แบบไร้ Lag

<p>บทความนี้ว่าด้วยความสัมพันธ์ระหว่างจำนวน Kafka consumer group กับ partition และความยากของการทำ auto scaling ที่เกิดจากเรื่องนี้ รวมถึงการนำสถาปัตยกรรมแบบใหม่มาใช้เพื่อแก้ปัญหา<br /> <br /> - แนะนำบริการ Airbridge และ workload<br /> - ปัญหาของสถาปัตยกรรมเดิม<br /> - ข้อเสนอสถาปัตยกรรมใหม่<br /> - แนวทางที่ 1: driver, executor model เช่นเดียวกับ Spark streaming<br /> - แนวทางที่ 2: decouple model ระหว่าง Kafka consumer กับ application server<br /> - เหตุผลที่เลือกแนวทางที่ 2<br /> - สถาปัตยกรรมแบบ Kafka consumer และ application server decouple model<br /> - ข้อควรพิจารณาในสถาปัตยกรรมใหม่<br /> - ความยากที่พบระหว่างดำเนินการ<br /> - ผลลัพธ์หลังนำสถาปัตยกรรมใหม่ไปใช้<br /> - สิ่งที่ยังต้องลองต่อไปในอนาคต</p>

[lamanus]

<p>ว้าว... ผมก็ใช้ ECS เหมือนกัน แต่ไม่เคยคิดลึกขนาดนี้มาก่อนเลย ดีมากครับ</p>

[lamanus]

<p>ดูเหมือนว่าระหว่างใช้ envoy คำขอเพื่อลดทราฟฟิกข้าม AZ ยังอยู่ในสถานะค้างไว้<br /> <br /> https://github.com/aws/aws-app-mesh-roadmap/issues/94</p>;