Mục tiêu học tập
- So sánh toàn diện Kinesis Data Streams vs MSK theo các trục quyết định
- Ghép đúng dịch vụ với tín hiệu trong đề bài (exam cues)
- Nắm các kiến trúc streaming end-to-end tiêu biểu
- Ôn SQS/SNS/EventBridge để loại trừ đáp án nhiễu
1. Bảng so sánh tổng
| Trục | Kinesis Data Streams | Amazon MSK |
|---|---|---|
| Bản chất | Dịch vụ streaming native AWS | Apache Kafka managed |
| Đơn vị | Shard (hoặc on-demand) | Topic/partition, broker |
| Vận hành | Rất thấp (on-demand ≈ zero) | Trung bình (provisioned) / thấp (Serverless) |
| Client | AWS SDK/KPL/KCL | Kafka client chuẩn (mọi ngôn ngữ hệ Kafka) |
| Tích hợp AWS | Rất sâu: Lambda ESM, Firehose, Flink, EventBridge Pipes | Tốt nhưng qua connector/Firehose(MSK source)/Lambda ESM |
| Retention | 24h → 365 ngày | Tùy cấu hình; tiered storage → rất dài |
| Ordering | Theo partition key trong shard | Theo key trong partition |
| Exactly-once producer transactions | Không (at-least-once, tự dedupe) | Có (Kafka transactions/idempotent producer) |
| Ecosystem | AWS services | Kafka Connect, ksqlDB, Debezium, Schema Registry... |
| Migration từ Kafka có sẵn | Phải viết lại client | Giữ nguyên code |
| Pricing | Shard-hour hoặc GB (on-demand) | Broker-hour + storage, hoặc serverless theo dùng |
2. Exam cues — đọc đề đoán đáp án
| Tín hiệu trong đề | Chọn |
|---|---|
| "already uses Apache Kafka", "minimal application changes" | MSK |
| "Kafka Connect / Debezium / compacted topic / ecosystem" | MSK |
| "fully managed, integrates with Lambda, no infrastructure" | Kinesis Data Streams |
| "unpredictable throughput, no capacity management" | KDS on-demand (hoặc MSK Serverless nếu bắt buộc Kafka) |
| "deliver to S3/Redshift/OpenSearch, near real-time, least ops" | Firehose (không phải KDS/MSK) |
| "replay events for multiple consumers" | KDS (retention) hoặc MSK — loại Firehose/SQS |
| "simple decoupling, one consumer per message, no ordering need" | SQS (đáp án nhiễu thường gặp) |
| "fan-out notifications to email/SMS/Lambda" | SNS |
| "route events by pattern to many targets, SaaS events, cron" | EventBridge |
3. Loại trừ nhanh SQS / SNS / EventBridge
| SQS | SNS | EventBridge | KDS/MSK | |
|---|---|---|---|---|
| Mô hình | Queue (pull) | Pub/sub (push) | Event bus + rules | Stream (log) |
| Replay | Không | Không | Archive+replay có | Có |
| Nhiều consumer cùng đọc 1 message | Không (trừ fan-out qua SNS) | Có | Có | Có |
| Thứ tự | FIFO queue | FIFO topic | Không đảm bảo | Theo key/partition |
| Throughput analytics lớn | Hạn chế (FIFO) | Không dành cho data | Không dành cho volume lớn | Có |
Nguyên tắc: bài toán data analytics/pipeline khối lượng lớn → Kinesis/MSK/Firehose. Bài toán app integration/decoupling → SQS/SNS/EventBridge.
4. Kiến trúc streaming tiêu biểu
4.1 Clickstream analytics chuẩn AWS
4.2 CDC → lakehouse
(Hoặc: Debezium trên MSK Connect → MSK → sink connector/Firehose.)
4.3 Log analytics realtime
4.4 IoT
5. Checklist chọn dịch vụ streaming (dùng khi làm bài)
- Chỉ cần đưa dữ liệu tới đích (S3/Redshift/OpenSearch/Splunk)? → Firehose
- Cần xử lý realtime tùy ý / nhiều consumer / replay? → KDS (mặc định)
- Có ràng buộc Kafka (code sẵn, ecosystem, transactions)? → MSK
- Workload không dự đoán? → on-demand/serverless của lựa chọn trên
- Là app messaging, không phải data pipeline? → SQS/SNS/EventBridge
Câu hỏi ôn tập
-
Startup xây pipeline clickstream mới hoàn toàn trên AWS, đội chưa từng dùng Kafka, cần realtime aggregation + archive S3. Chọn stack nào?
Xem đáp án
Kinesis Data Streams (on-demand nếu traffic khó đoán) + Managed Service for Apache Flink cho aggregation realtime + Firehose consumer đổ S3 Parquet. Không có ràng buộc Kafka thì KDS thắng nhờ tích hợp native, vận hành thấp; MSK sẽ thêm chi phí vận hành/kiến thức không cần thiết.
-
Công ty migrate hệ thống Kafka on-prem lên AWS, hàng chục producer/consumer đang chạy, yêu cầu "minimal code changes" và giảm vận hành. Giải pháp?
Xem đáp án
Amazon MSK — Kafka managed, client giữ nguyên (đổi bootstrap + auth). Dùng MSK replicator/MirrorMaker 2 để đồng bộ dữ liệu khi cutover. Kinesis buộc viết lại toàn bộ client — sai yêu cầu. Nếu đề thêm "không muốn quản lý capacity" → MSK Serverless.
-
Yêu cầu: mỗi message chỉ được một worker xử lý một lần rồi biến mất, không cần thứ tự, không cần replay. Dịch vụ?
Xem đáp án
SQS (standard queue) — mô hình queue đúng nghĩa: message được một consumer nhận, xử lý, xóa. Kinesis/MSK là stream cho nhiều consumer + replay — thừa tính năng và consumer phải tự quản checkpoint. Đây là câu loại trừ "streaming vs queueing" kinh điển.
-
Pipeline cần đảm bảo exactly-once từ producer tới topic (không duplicate khi retry). Kinesis hay MSK?
Xem đáp án
MSK/Kafka — có idempotent producer và transactions hỗ trợ exactly-once semantics trong hệ Kafka. Kinesis producer là at-least-once (retry có thể tạo duplicate); consumer phải tự dedupe (vd theo unique ID). Đề nhấn exactly-once end-to-end nghiêng về Kafka (hoặc xử lý bằng Flink checkpointing + idempotent sink).
-
Dữ liệu sensor phải giữ được 90 ngày để consumer mới đọc lại từ đầu. Firehose có đáp ứng không? Cấu hình gì nếu dùng KDS?
Xem đáp án
Firehose không — không lưu trữ/replay. Dùng KDS với extended retention (24h mặc định → cấu hình tối đa 365 ngày; 90 ngày nằm trong long-term retention, tính phí lưu trữ thêm). Phương án khác: KDS retention ngắn + Firehose archive S3, consumer mới đọc lại từ S3 (backfill) — rẻ hơn cho 90 ngày.
Bài tập thực hành
- Tự vẽ lại 4 kiến trúc ở mục 4 từ trí nhớ và giải thích từng thành phần
- Với mỗi dịch vụ (KDS, Firehose, MSK, SQS, SNS, EventBridge) viết 1 câu "chọn khi..."
- Làm lại checklist mục 5 với 3 đề bài tự nghĩ
- Đọc Best practices for MSK ↔ Kinesis selection (AWS blog streaming)
Tài liệu tham khảo chính thức
Tiếp theo: Managed Service for Apache Flink - Streaming ETL