SQS: standard vs FIFO
คิวข้อความที่ช่วยให้ระบบไม่ล่มเวลาโหลดพุ่ง
ลูกค้า (งาน) เข้ามาเยอะแค่ไหนก็รับบัตรคิวไปก่อน ครัว (worker) จะค่อย ๆ ทำตามคิวที่รับมา ทำให้คนไม่ล้นจนครัวพังหรือออเดอร์ตกหล่น
พื้นฐานที่ควรรู้: ในระบบแอปพลิเคชันที่มีการส่งต่อข้อมูลกันไปมา ถ้าเซิร์ฟเวอร์ฝั่งรับทำงานไม่ทัน เซิร์ฟเวอร์ฝั่งส่งก็จะต้องรอจนกว่าฝั่งรับจะว่าง ทำให้ระบบทั้งหมดช้าลง หรือถ้าฝั่งรับพัง ข้อมูลก็จะสูญหายไปเลย เราจึงต้องมี "คนกลาง" มารับข้อมูลไว้ให้ก่อน
SQS (Simple Queue Service - บริการคิวส่งข้อความแบบเรียบง่าย) คือบริการจัดการคิวข้อความ (Message Queue) ที่ช่วยทำ Decouple (การแยกการทำงานออกจากกัน) ระบบฝั่งส่งและฝั่งรับสามารถทำงานเป็นอิสระจากกัน ถ้าฝั่งรับช้าหรืองานล้น งานก็จะถูกพักรอกันอยู่ในคิวอย่างปลอดภัย (ไม่สูญหาย)
คิวคั่นกลาง: ฝั่งรับงานล่ม/ช้า ก็ไม่ทำให้ฝั่งส่งพัง
ถ้า worker ช้า งานค้างในคิว (ไม่หาย) · เพิ่ม worker เพื่อระบายคิวได้
- Standard Queue — ความเร็วในการรับส่ง (Throughput) สูงมาก, มีการส่งข้อมูลอย่างน้อยหนึ่งครั้ง (At-least-once - อาจมีข้อความซ้ำได้), ไม่การันตีลำดับการเข้าคิวเป๊ะๆ
- FIFO Queue (First-In-First-Out) — รักษาลำดับเป๊ะและรับประกันว่าจะไม่ซ้ำ (Exactly-once processing) แลกกับความเร็ว (Throughput) ที่จำกัดกว่าแบบ Standard
- ช่วยรองรับปริมาณงานที่พุ่งกระฉูด (Spike): งานค้างในคิวไว้ก่อน แล้วค่อยสเกลเพิ่ม Worker มาระบายทีหลังได้
- Visibility timeout (ระยะเวลาซ่อนข้อความ) — เมื่อ Worker ดึงงานไป ข้อความจะซ่อนตัวชั่วคราวเพื่อไม่ให้ Worker ตัวอื่นดึงซ้ำ ถ้าทำไม่เสร็จในเวลาที่กำหนด ข้อความจะเด้งกลับมาในคิว
- Dead-Letter Queue (DLQ) — คิวแยกพิเศษสำหรับเก็บข้อความที่ประมวลผลไม่สำเร็จตามจำนวนครั้งที่กำหนด เอาไว้ให้โปรแกรมเมอร์มาตรวจสอบทีหลัง
สรุป Key Takeaways
- SQS = คิว decouple ฝั่งส่ง/รับ รองรับ spike (งานไม่หาย)
- Standard = throughput สูงอาจซ้ำ; FIFO = ลำดับเป๊ะไม่ซ้ำ
- ใช้ DLQ จับงานที่ทำไม่สำเร็จ
คำถามที่พบบ่อย
Standard กับ FIFO queue เลือกยังไง
Standard = throughput แทบไม่จำกัด แต่ลำดับไม่การันตีและข้อความอาจซ้ำ (at-least-once) ส่วน FIFO = ลำดับเป๊ะและไม่ซ้ำ (exactly-once) แลกกับ throughput จำกัด — โจทย์ "ลำดับสำคัญ เช่น ธุรกรรมการเงิน" = FIFO, "เอาปริมาณ" = Standard
Visibility timeout คืออะไร ตั้งผิดเกิดอะไร
ช่วงเวลาที่ข้อความ "ถูกซ่อน" หลังมี consumer หยิบไปทำ — ถ้าทำเสร็จแล้วลบทัน ข้อความหาย แต่ถ้าตั้งสั้นเกินไป งานยังไม่เสร็จข้อความโผล่กลับมาให้ตัวอื่นหยิบซ้ำ = ประมวลผลซ้ำซ้อน ตั้งยาวเกินไป = งานที่พังต้องรอนานกว่าจะถูกลองใหม่ — ควรตั้งมากกว่าเวลาประมวลผลจริงเล็กน้อย
Dead Letter Queue มีไว้ทำไม
ที่พักข้อความที่ประมวลผลล้มเหลวซ้ำเกินกำหนด (maxReceiveCount) — กันข้อความเสียวนอุดคิวหลัก และเก็บไว้วิเคราะห์ทีหลังว่าทำไมพัง — โจทย์ "จัดการ message ที่ fail ซ้ำๆ" = DLQ เสมอ
ลองทำ Quiz ท้ายบท
คำถามแนวข้อสอบของโมดูลนี้ 5 ข้อ · เฉลยทันที