SQS และ SNS สำหรับการส่งข้อความคืออะไร?

Question

Accepted Answer

**SQS** (Simple Queue Service) และ **SNS** (Simple Notification Service) เป็นบริการ messaging ของ AWS ที่ช่วยให้องค์ประกอบต่าง ๆ ของแอปพลิเคชันสื่อสารกันแบบ **decoupled และ asynchronous** SQS เป็นคิวข้อความ (ประมวลผลแบบ one-to-one) ส่วน SNS เป็น pub/sub (กระจายแบบ one-to-many)

## SQS — message queue (การ decouple, การประมวลผลแบบ async)

```text
SQS is a managed message QUEUE: producers send messages, consumers process them:
  → producer → [QUEUE] → consumer(s) process messages (at their own pace)
  → DECOUPLES components (producer doesn't wait for/depend on the consumer)
  → BUFFERS load (queue absorbs spikes; consumers process steadily)
  → RELIABLE (messages persist until processed; retries; dead-letter queues for failures)
  → SCALABLE (add more consumers to process faster)
→ Use for: async task processing, decoupling services, smoothing load spikes
```

## SNS — pub/sub (การกระจายแบบ one-to-many)

```text
SNS is PUBLISH/SUBSCRIBE: publish a message to a TOPIC → ALL subscribers receive it:
  → publisher → [TOPIC] → fans out to MANY subscribers (one-to-many)
  → subscribers: SQS queues, Lambda functions, HTTP endpoints, email, SMS
  → use for: notifications, fan-out, broadcasting events to multiple consumers
```

## รูปแบบ fan-out (SNS + SQS ทำงานร่วมกัน)

```text
SNS topic → fans out to MULTIPLE SQS queues → each processed independently:
  Event → SNS topic → ┬→ SQS queue A → service A processes
                      ├→ SQS queue B → service B processes
                      └→ Lambda → does something else
→ One event triggers multiple independent processing pipelines (common architecture).
```

## ทำไมจึงสำคัญ

การเข้าใจ SQS และ SNS มีคุณค่าเพราะ **การส่งข้อความแบบ decoupled และ asynchronous เป็นรูปแบบพื้นฐานของสถาปัตยกรรมที่ scalable และยืดหยุ่นต่อความล้มเหลว** และทั้งสองเป็นบริการ messaging หลักของ AWS จึงเป็นความรู้ที่สำคัญสำหรับสถาปัตยกรรมคลาวด์ **SQS** (message queue) ช่วยให้เกิดรูปแบบสำคัญคือ **การ decouple องค์ประกอบต่าง ๆ** เพื่อให้ producer ไม่ต้องพึ่งพาหรือรอ consumer โดย producer ส่งข้อความไปยังคิว และ consumer ประมวลผลตามจังหวะของตัวเอง ซึ่งช่วย **รองรับโหลด** (คิวดูดซับการพุ่งขึ้นของทราฟฟิกในขณะที่ consumer ค่อย ๆ ประมวลผลอย่างสม่ำเสมอ) ให้ **ความน่าเชื่อถือ** (ข้อความคงอยู่จนกว่าจะถูกประมวลผล พร้อมการ retry และ dead-letter queue สำหรับกรณีล้มเหลว) และเปิดทาง **การขยายตัว** (เพิ่ม consumer เพื่อประมวลผลให้เร็วขึ้น)

สิ่งนี้จำเป็นต่อการประมวลผลงานแบบ async การ decouple บริการต่าง ๆ และการรับมือกับโหลดที่ผันผวนได้อย่างนุ่มนวล **SNS** (pub/sub) ช่วยให้เกิด **การกระจายแบบ one-to-many** คือการ publish ข้อความไปยัง topic ที่กระจายต่อไปยัง subscriber จำนวนมาก (คิว ฟังก์ชัน Lambda, endpoint, email/SMS) ซึ่งมีประโยชน์สำหรับการแจ้งเตือนและการกระจายอีเวนต์ไปยัง consumer หลายราย

การเข้าใจรูปแบบ **fan-out** อันทรงพลัง (การผสาน SNS และ SQS เพื่อให้อีเวนต์หนึ่งเหตุการณ์กระตุ้น pipeline การประมวลผลอิสระหลายชุดผ่านการที่ SNS กระจายไปยังหลาย SQS queue) สะท้อนสถาปัตยกรรมที่พบบ่อยและสำคัญสำหรับระบบที่ขับเคลื่อนด้วยอีเวนต์

บริการและรูปแบบเหล่านี้เป็นรากฐานของการสร้างแอปพลิเคชันที่ **loosely-coupled, scalable และยืดหยุ่นต่อความล้มเหลว** ซึ่งเป็นหลักการสำคัญของสถาปัตยกรรมคลาวด์ที่ดี (หลีกเลี่ยงการเชื่อมโยงแบบแน่นและการพึ่งพาแบบ synchronous ที่ก่อให้เกิดความเปราะบางและคอขวด)

เนื่องจากการสื่อสารแบบ asynchronous ที่ decoupled เป็นพื้นฐานของระบบที่ scalable และยืดหยุ่น และ SQS/SNS เป็นบริการหลักของ AWS สำหรับเรื่องนี้ (โดยมีรูปแบบ fan-out เป็นสถาปัตยกรรมที่พบบ่อย) การเข้าใจ SQS และ SNS จึงเป็นความรู้ AWS ที่มีคุณค่าและสำคัญในทางปฏิบัติสำหรับการออกแบบแอปพลิเคชันคลาวด์ที่ well-architected ซึ่งเป็นองค์ประกอบสำคัญของรูปแบบ decoupled, event-driven และ asynchronous ที่ทำให้ระบบกระจายมีความ scalable และทนทาน