</>Học Dev
Bài học

Tuần 3 - Ngày 3: Amazon MSK và MSK Serverless

Tuần 3 – Ngày 3

Mục tiêu học tập

  • Ôn khái niệm Kafka: topic, partition, consumer group, offset
  • Hiểu MSK provisioned: broker, storage, HA multi-AZ
  • Biết MSK Serverless và MSK Connect
  • Nắm các phương án bảo mật và tình huống chọn MSK

1. Kafka căn bản (đủ cho đề thi)

PRODUCERS──►TOPIC(chiathànhPARTITIONS,replicategiữabrokers)│partition=đơnvịsongsong+thứtự▼CONSUMERGROUPA(mỗipartition→1consumertronggroup)CONSUMERGROUPB(đọcđộclập,offsetriêng)
  • Topic chia thành partition; message có offset trong partition; thứ tự đảm bảo trong một partition
  • Consumer group: các consumer chia nhau partition; nhiều group đọc độc lập (giống fan-out)
  • Replication factor (thường 3): partition có leader + replicas trên broker khác → chịu lỗi broker
  • Retention theo cấu hình (giờ/ngày/không giới hạn với tiered storage)

Ánh xạ khái niệm với Kinesis: topic ≈ stream, partition ≈ shard, offset ≈ sequence number, consumer group ≈ ứng dụng consumer (KCL).

2. Amazon MSK (provisioned)

Managed Apache Kafka: AWS vận hành control plane (provisioning, patching, metrics, phục hồi broker), bạn kiểm soát cấu hình Kafka.

  • Cluster nhiều broker trải trên 2-3 AZ (khuyến nghị 3) trong VPC của bạn
  • Chọn instance type (kafka.m5/m7g...), số broker, EBS storage per broker (+ auto-scaling storage)
  • Tiered storage: đẩy dữ liệu cũ sang tầng rẻ hơn, retention gần như không giới hạn
  • Client tự quản: producer/consumer là ứng dụng Kafka chuẩn (chạy trên EC2/ECS/EKS/Lambda*)
  • Bạn vẫn phải: chọn size, số partition, cân bằng (Cruise Control), quản lý client

Bảo mật MSK

LớpLựa chọn
Encryption in-transitTLS (client-broker, broker-broker)
Encryption at-restKMS trên EBS
AuthN/AuthZIAM access control (đơn giản nhất, khuyến nghị), SASL/SCRAM (user/pass trong Secrets Manager), mTLS (Private CA); ACL Kafka
NetworkCluster trong VPC, security groups; multi-VPC private connectivity/PrivateLink cho cross-account

3. MSK Serverless

  • Không chọn broker/storage — trả theo cluster-hour + partition-hour + GB in/out/storage
  • Tự scale capacity; phù hợp workload không dự đoán được hoặc team không muốn size cluster
  • Giới hạn cấu hình so với provisioned (retention tối đa, throughput per partition...) — đề chỉ cần biết: "Kafka mà không muốn quản capacity" → MSK Serverless
  • AuthN: chỉ IAM access control

4. MSK Connect

Managed Kafka Connect: chạy các connector đưa dữ liệu vào/ra Kafka mà không quản worker:

  • Source connector: vd Debezium CDC từ database → topic
  • Sink connector: topic → S3, OpenSearch, Redshift (qua connector cộng đồng/Confluent)
  • Auto scaling worker; trả theo worker-hour

Ngoài ra: Firehose đọc được từ MSK → deliver vào S3 (ít vận hành hơn dựng sink connector khi đích là S3).

5. Khi nào chọn MSK? (chuẩn bị cho bài so sánh ngày mai)

Chọn MSK khi đề có các tín hiệu:

  • Đã dùng Apache Kafka on-prem/self-managed → migrate "minimal code changes" (client giữ nguyên)
  • Cần hệ sinh thái Kafka: Kafka Connect, Schema Registry bên thứ ba, exactly-once transactions của Kafka, compacted topics
  • Cần retention rất dài với tiered storage, hoặc throughput per partition tùy chỉnh
  • Multi-cloud/portability (tránh lock-in API)

Chọn Kinesis khi: muốn serverless native AWS, tích hợp thẳng Lambda/Firehose, đội không có kinh nghiệm Kafka (chi tiết ngày mai).

Câu hỏi ôn tập

  1. Công ty chạy Kafka self-managed trên EC2, tốn công vận hành. Muốn giảm vận hành mà KHÔNG đổi code producer/consumer. Giải pháp?

    Xem đáp án

    Amazon MSK — Kafka thật, client tương thích hoàn toàn: chỉ đổi bootstrap servers + cấu hình auth. Chuyển sang Kinesis đòi viết lại producer/consumer (API khác) — vi phạm "minimal code changes". Nếu thêm yêu cầu không muốn size cluster → MSK Serverless.

  2. Thứ tự message trong Kafka được đảm bảo ở phạm vi nào? Muốn giữ thứ tự per-customer thì làm gì?

    Xem đáp án

    Thứ tự chỉ đảm bảo trong một partition. Để giữ thứ tự per-customer: dùng customer_id làm message key — Kafka hash key về cùng partition, mọi message của một customer nằm đúng thứ tự. Giống hệt logic partition key của Kinesis.

  3. MSK Serverless khác MSK provisioned thế nào và khi nào chọn?

    Xem đáp án

    Serverless: không chọn broker/storage, tự scale, trả theo sử dụng (cluster-hour + partition-hour + GB), auth chỉ IAM — chọn khi workload không dự đoán được hoặc muốn "least operational overhead". Provisioned: kiểm soát instance/storage/cấu hình Kafka sâu (tiered storage, custom config), thường rẻ hơn với throughput cao ổn định — chọn cho workload lớn, đều, cần tính năng đầy đủ.

  4. Cần CDC từ MySQL vào Kafka topic mà không tự vận hành Kafka Connect worker. Giải pháp?

    Xem đáp án

    MSK Connect chạy Debezium MySQL source connector managed: AWS quản worker, auto scaling. (Phương án khác tùy đề: DMS với target Kinesis/Kafka.) Nếu đích cuối là S3 và không bắt buộc qua Kafka thì DMS → S3 trực tiếp còn ít vận hành hơn.

  5. Các phương án authentication cho client MSK? Phương án nào ít vận hành nhất?

    Xem đáp án

    (1) IAM access control — auth/authz bằng IAM policy, không quản credential riêng, ít vận hành nhất (và là lựa chọn duy nhất trên MSK Serverless); (2) SASL/SCRAM — user/password lưu Secrets Manager; (3) mutual TLS — certificate từ ACM Private CA, phức tạp nhất. Tất cả đều đi kèm TLS in-transit.

Bài tập thực hành

  • Vẽ mapping khái niệm Kafka ↔ Kinesis (topic/stream, partition/shard, offset/sequence, consumer group)
  • Đọc pricing MSK Serverless và ước tính chi phí cho 10 partition, 1MB/s
  • Phác thảo pipeline: Debezium (MSK Connect) → MSK → Firehose → S3 Parquet
  • Đọc MSK security

Tài liệu tham khảo chính thức

Tiếp theo: Kinesis vs MSK - chọn công nghệ streaming