Trang chủ/Chương 12

Chương 12: Decoupling & Messaging

Tổng Quan

Khi ứng dụng lớn lên, các thành phần cần giao tiếp theo kiểu lỏng lẻo (loosely coupled) để tăng khả năng chịu lỗi và scale độc lập. AWS cung cấp nhiều dịch vụ messaging để thực hiện điều này.

1. Amazon SQS (Simple Queue Service)

1.1 Đặc điểm

  • Hàng đợi (queue) giữ messages chờ xử lý.
  • Fully managed, auto-scaling.
  • Retention: 4 ngày (mặc định) → tối đa 14 ngày.
  • Message size: tối đa 256 KB.

1.2 Standard vs FIFO

StandardFIFO
ThroughputUnlimited300 msg/s (hoặc 3,000 với batching)
OrderBest-effort (có thể lộn xộn)Đúng thứ tự (First-In-First-Out)
DuplicateCó thể trùng (at-least-once)Exactly-once processing
Queue nameBất kỳPhải kết thúc .fifo

1.3 Visibility Timeout

  • Sau khi consumer nhận message, message bị ẩn khỏi queue trong thời gian này.
  • Mặc định: 30 giây. Tối đa: 12 giờ.
  • Nếu consumer xử lý xong → delete message. Nếu timeout → message xuất hiện lại cho consumer khác.

1.4 Dead-Letter Queue (DLQ)

  • Messages thất bại sau X lần xử lý → chuyển vào DLQ để debug.
  • maxReceiveCount = số lần thử trước khi chuyển vào DLQ.

1.5 SQS + Auto Scaling

  • Dùng CloudWatch metric ApproximateNumberOfMessages + ASG để auto-scale consumers.
Producers ──▶ [SQS Queue] ──▶ Consumer EC2s (ASG)
                                    │
                   Queue dài → CloudWatch Alarm → Scale Out

2. Amazon SNS (Simple Notification Service)

2.1 Đặc điểm

  • Mô hình Pub/Sub (Publisher → Topic → Subscribers).
  • 1 message gửi đến tất cả subscribers cùng lúc.
  • Subscribers: SQS, Lambda, Email, SMS, HTTP/HTTPS.
  • Tối đa 12.5 triệu subscriptions per topic.

2.2 SNS + SQS Fan-Out Pattern

  • 1 SNS Topic → nhiều SQS Queues → mỗi queue xử lý riêng biệt.
  • Use case: 1 đơn hàng cần gửi email + ghi log + cập nhật kho cùng lúc.
Order Service ──▶ SNS Topic
                    ├──▶ SQS Queue 1 → Email Service
                    ├──▶ SQS Queue 2 → Inventory Service
                    └──▶ SQS Queue 3 → Analytics Service

2.3 SNS FIFO

  • Kết hợp với SQS FIFO để đảm bảo thứ tự và exactly-once delivery.

3. Amazon EventBridge

3.1 Đặc điểm

  • Event bus thế hệ mới (thay thế CloudWatch Events).
  • Nhận events từ: AWS services, SaaS partners, custom apps.
  • Lọc events bằng rules → route đến targets (Lambda, SQS, Step Functions...).

3.2 Ưu điểm so với SNS

  • Schema Registry: Tự động phát hiện cấu trúc event.
  • Archive & Replay: Lưu trữ và replay events cũ.
  • Tích hợp SaaS: Zendesk, Datadog, Shopify...

4. Amazon Kinesis

Dùng để thu thập, xử lý, phân tích streaming data theo thời gian thực.

Dịch vụMô tả
Kinesis Data StreamsThu thập data real-time với shards. Retention 1-365 ngày. Consumer tự xử lý.
Kinesis Data FirehoseLoad streaming data vào S3, Redshift, OpenSearch, HTTP. Near real-time (60s buffer). Fully managed.
Kinesis Data AnalyticsPhân tích streams bằng SQL hoặc Apache Flink.

Kinesis Data Streams vs SQS

Kinesis Data StreamsSQS
Use caseReal-time streaming, big dataDecoupling, async processing
ConsumerNhiều consumers đọc cùng data1 consumer per message
OrderingPer shardFIFO queue
Data retention1-365 ngày4-14 ngày
ThroughputProvision shardsUnlimited (Standard)

5. Amazon MQ

  • Managed broker cho ActiveMQ và RabbitMQ.
  • Dùng khi migrate ứng dụng on-premises đang dùng messaging protocols (MQTT, AMQP, STOMP).
  • KHÔNG nên dùng cho ứng dụng mới trên cloud → dùng SQS/SNS thay thế.

Exam Tips 💡

  1. SQS = Decoupling (producer-consumer). SNS = Pub/Sub (1-to-many).
  2. Fan-Out = SNS + SQS. Gửi 1 message đến nhiều queues.
  3. SQS FIFO khi cần đúng thứ tự + exactly-once.
  4. Kinesis Data Streams cho real-time streaming (IoT, clickstream).
  5. Kinesis Firehose cho load data vào S3/Redshift (near real-time, managed).
  6. EventBridge khi cần event routing phức tạp hoặc tích hợp SaaS.
  7. Amazon MQ chỉ khi migrate từ on-premises messaging (ActiveMQ/RabbitMQ).

Câu Hỏi Ôn Tập 📝

Câu 1: Khi có đơn hàng mới, cần đồng thời: gửi email, cập nhật kho, ghi log. Kiến trúc nào phù hợp?

Xem đáp án

SNS + SQS Fan-Out. Publish message vào SNS Topic → 3 SQS Queues (email, inventory, logging) subscribe topic đó. Mỗi queue xử lý độc lập.

Câu 2: Cần thu thập và phân tích clickstream data real-time từ hàng triệu users. Dùng gì?

Xem đáp án

Amazon Kinesis Data Streams để thu thập real-time data, kết hợp Kinesis Data Analytics để phân tích bằng SQL/Flink.

Câu 3: Messages trong SQS queue liên tục thất bại xử lý. Làm sao debug hiệu quả?

Xem đáp án

Cấu hình Dead-Letter Queue (DLQ). Sau X lần thất bại (maxReceiveCount), messages tự động chuyển vào DLQ để inspect và debug.

⬅️ Chương 11: Containers | Chương 13: Security & Encryption ➡️

← Chương trước Containers