Tìm hiểu vì sao các ứng dụng trên cloud không nên "gọi trực tiếp" nhau, và cách AWS cung cấp các dịch vụ hàng đợi, thông báo và streaming để giao tiếp bất đồng bộ, chịu tải tốt và tách rời (decoupled) giữa các thành phần hệ thống.
Khi bạn triển khai nhiều ứng dụng trên AWS, chúng hầu như không bao giờ hoạt động độc lập hoàn toàn — chúng cần "nói chuyện" với nhau. Ví dụ, một hệ thống bán hàng trực tuyến có thể gồm: dịch vụ Đặt hàng (Buying Service), dịch vụ Giao hàng (Shipping Service), dịch vụ chống gian lận (Fraud Service), dịch vụ gửi email... Câu hỏi đặt ra là: các dịch vụ này nên giao tiếp với nhau theo cách nào?
Có hai mô hình giao tiếp chính giữa các ứng dụng:
Hãy tưởng tượng giao tiếp đồng bộ như việc bạn gọi điện thoại trực tiếp cho một người bạn để nhờ việc: nếu người đó đang bận (không nghe máy, đường truyền quá tải), bạn phải chờ hoặc gọi lại — công việc của bạn bị chặn lại (blocked). Giao tiếp bất đồng bộ giống như việc bạn gửi một tin nhắn hoặc email: bạn cứ gửi, và người nhận sẽ đọc và xử lý khi họ có thời gian, không làm bạn phải chờ đợi ngay lúc đó.
Vấn đề của giao tiếp đồng bộ là nó rất dễ "vỡ trận" khi có sự tăng tải bất thường (traffic spike). Ví dụ điển hình: bình thường hệ thống của bạn cần mã hóa (encode) 10 video mỗi giờ, nhưng bất ngờ có một sự kiện khiến số lượng video cần xử lý tăng vọt lên 1000 video. Nếu dịch vụ xử lý video được gọi trực tiếp (đồng bộ) bởi dịch vụ upload, thì dịch vụ upload sẽ bị "nghẽn" theo — người dùng phải chờ rất lâu, hoặc hệ thống bị lỗi timeout, thậm chí sập cả hai dịch vụ.
Giải pháp cho vấn đề này là tách rời (decouple) các ứng dụng khỏi nhau bằng các dịch vụ trung gian chuyên dụng của AWS, giúp mỗi thành phần có thể co giãn quy mô (scale) một cách độc lập với các thành phần khác. Ba dịch vụ chính cho việc này là:
SQS (Simple Queue Service) là dịch vụ hàng đợi thông điệp (message queue) hoàn toàn được quản lý bởi AWS. Để hiểu SQS, trước tiên hãy hiểu "hàng đợi" (queue) là gì trong ngữ cảnh phần mềm: đó là một cấu trúc dữ liệu giống như một dòng người đang xếp hàng chờ tại quầy — người vào trước sẽ đứng ở đầu hàng, và người đến sau xếp vào cuối hàng.
Trong SQS có hai vai trò chính:
Điểm mấu chốt là Producer và Consumer hoàn toàn không biết đến sự tồn tại của nhau — chúng chỉ biết đến hàng đợi SQS ở giữa. Điều này chính là bản chất của việc "tách rời" (decoupling): nếu Consumer đang xử lý chậm hoặc tạm thời offline, các message vẫn an toàn nằm trong hàng đợi chờ được xử lý, Producer vẫn tiếp tục gửi message bình thường mà không bị ảnh hưởng.
SQS Standard Queue là loại hàng đợi cơ bản và cũng là dịch vụ tích hợp lâu đời nhất của AWS (đã tồn tại hơn 10 năm) — điều này cho thấy đây là một dịch vụ rất ổn định, được kiểm chứng qua thời gian và được sử dụng rộng rãi trong ngành.
Các đặc điểm quan trọng của SQS Standard Queue:
| Đặc điểm | Giá trị |
|---|---|
| Retention mặc định | 4 ngày |
| Retention tối đa | 14 ngày |
| Độ trễ publish/receive | Dưới 10ms |
| Thông lượng | Từ 1 đến hàng chục nghìn message/giây |
| Giới hạn số message trong queue | Không giới hạn |
Một ví dụ kinh điển thể hiện rõ giá trị của SQS: hệ thống có một tầng Web Server (chạy trong một Auto Scaling Group gồm các EC2 Instance) nhận các yêu cầu từ người dùng — ví dụ yêu cầu xử lý (encode) video vừa tải lên. Thay vì Web Server tự xử lý video ngay (rất tốn tài nguyên và mất thời gian), nó chỉ đơn giản đẩy (PUT) một message vào SQS Queue mô tả công việc cần làm, rồi trả lời ngay cho người dùng là "đã nhận yêu cầu, đang xử lý".
Sau đó, một tầng khác — Auto Scaling Group riêng biệt gồm các EC2 Instance chuyên xử lý video (Video Processing) — sẽ tự động co giãn số lượng instance dựa trên độ sâu (depth = số lượng message đang chờ) của hàng đợi, và liên tục kéo (pull) công việc từ hàng đợi ra để xử lý.
Lợi ích của mô hình này:
SQS Standard Queue có một hạn chế: nó không đảm bảo thứ tự các message được xử lý (message có thể đến trước nhưng lại được consumer xử lý sau, do tính chất phân tán và khả năng scale cao). Với đa số ứng dụng điều này không sao, nhưng có những trường hợp thứ tự lại rất quan trọng.
FIFO là viết tắt của "First In First Out" — nghĩa là thông điệp nào được gửi vào hàng đợi trước sẽ được lấy ra và xử lý trước, giống như việc xếp hàng: ai đến trước, được phục vụ trước.
Ví dụ: nếu Producer gửi các message theo thứ tự 1, 2, 3, 4 vào một FIFO Queue, thì Consumer khi polling/nhận message sẽ luôn nhận được chúng đúng theo thứ tự 1, 2, 3, 4 — không bị xáo trộn. Điều này đảm bảo rằng các message được xử lý theo đúng trình tự mà chúng được tạo ra.
Đối với kỳ thi CLF-C02, bạn chỉ cần nhớ một câu ngắn gọn: Kinesis = giải pháp truyền dữ liệu lớn theo thời gian thực (real-time big data streaming). Đây là dịch vụ được quản lý hoàn toàn (managed service), dùng để thu thập (collect), xử lý (process) và phân tích (analyze) dữ liệu dạng luồng (streaming data) theo thời gian thực, ở bất kỳ quy mô nào — từ vài bản ghi mỗi giây đến hàng trăm nghìn nguồn gửi dữ liệu liên tục.
Khác với SQS (dùng cho các message rời rạc, mỗi message xử lý một lần và bị xóa sau đó), Kinesis phù hợp với các luồng dữ liệu liên tục, khối lượng lớn, cần được xử lý và phân tích gần như ngay lập tức khi dữ liệu vừa sinh ra — ví dụ dữ liệu click chuột trên website, dữ liệu từ thiết bị IoT, hoặc log & metrics hệ thống.
Trong hệ sinh thái Kinesis có nhiều thành phần, nhưng hai cái quan trọng để biết ở mức tổng quan là:
Luồng dữ liệu tổng quát của Kinesis diễn ra như sau: các nguồn dữ liệu (Click Streams từ website, thiết bị IoT, Metrics & Logs hệ thống) → chảy vào Amazon Kinesis Data Streams → được Amazon Data Firehose lấy ra → đưa tới các đích lưu trữ/phân tích như Amazon S3, Amazon Redshift...
SQS giải quyết bài toán "một message được xử lý bởi một trong nhiều consumer" (mỗi message chỉ được một consumer xử lý và xóa). Nhưng có một bài toán khác: điều gì xảy ra nếu bạn muốn một message được gửi đến NHIỀU người nhận cùng lúc, và mỗi người nhận đều phải nhận được đầy đủ toàn bộ message đó?
Đây chính là bài toán mà Amazon SNS (Simple Notification Service) giải quyết, dựa trên mô hình Publish/Subscribe (Pub/Sub) — nghĩa là "xuất bản và đăng ký".
Ví dụ: dịch vụ Buying Service khi có đơn hàng mới sẽ "publish" (xuất bản/gửi) một message vào một SNS Topic duy nhất. Topic này đã có sẵn nhiều "subscriber" (người đăng ký nhận thông báo) đăng ký lắng nghe, ví dụ: Shipping Service, dịch vụ gửi Email thông báo, Fraud Service (dịch vụ chống gian lận). Ngay khi message được publish vào topic, TẤT CẢ các subscriber này đều nhận được đầy đủ nội dung message đó cùng lúc.
So sánh với cách làm truyền thống là "Direct integration" — Buying Service phải tự gọi trực tiếp lần lượt đến từng dịch vụ (Shipping Service, Email Service, Fraud Service...): cách này khiến Buying Service phải biết và quản lý kết nối tới từng dịch vụ, rất cồng kềnh và khó mở rộng khi có thêm subscriber mới. Với SNS, Buying Service chỉ cần biết đến MỘT topic duy nhất, việc thêm/bớt subscriber không ảnh hưởng gì đến Buying Service.
Một điểm rất thường gặp trong thực tế và trong đề thi là mô hình "SNS + SQS Fan-out": SNS Topic có thể "fan out" (phân tán) message ra thành nhiều SQS Queue riêng biệt cho mỗi subscriber, thay vì gửi trực tiếp đến ứng dụng của subscriber. Lý do là vì SNS không lưu trữ lại message (không có retention) — nếu subscriber tạm thời offline khi message được gửi, nó sẽ mất message đó vĩnh viễn. Nhưng nếu subscriber là một SQS Queue, message sẽ được lưu an toàn trong queue đó cho đến khi được xử lý, đảm bảo tính durable (bền vững, không mất dữ liệu).
Một số thông tin chi tiết khác về SNS:
| Tiêu chí | Amazon SQS | Amazon SNS |
|---|---|---|
| Mô hình | Hàng đợi (Queue) – Point to point | Xuất bản/Đăng ký (Pub/Sub) |
| Số người nhận mỗi message | 1 consumer (rồi bị xóa khỏi queue) | Nhiều subscriber (mỗi subscriber nhận đủ) |
| Lưu trữ message (retention) | Có, tối đa 14 ngày | Không có retention |
| Đảm bảo thứ tự | Có (bản FIFO) | Có (bản FIFO topic) |
| Vai trò điển hình | Phân phối công việc, tách rời tầng ứng dụng | Thông báo/phát tán một sự kiện đến nhiều bên |
SQS và SNS là các dịch vụ "cloud-native" — nghĩa là chúng được AWS thiết kế riêng, sử dụng các giao thức (protocol) độc quyền (proprietary) của AWS thông qua API riêng. Điều này rất tối ưu cho các ứng dụng được xây dựng mới trên cloud, nhưng lại là một vấn đề đối với các ứng dụng cũ (legacy) đang chạy on-premises (tại trung tâm dữ liệu riêng của doanh nghiệp).
Các ứng dụng truyền thống đó thường sử dụng các giao thức message broker mở (open protocol) như MQTT, AMQP, STOMP, OpenWire, WSS — đây là các chuẩn giao tiếp được nhiều hệ thống message broker phổ biến như ActiveMQ, RabbitMQ hỗ trợ từ trước khi có cloud.
Khi một doanh nghiệp muốn di trú (migrate) ứng dụng loại này lên AWS, thay vì phải viết lại (re-engineer) toàn bộ ứng dụng để chuyển sang dùng SQS/SNS (tốn thời gian, chi phí, rủi ro), AWS cung cấp Amazon MQ — một dịch vụ message broker được quản lý (managed message broker service), hỗ trợ trực tiếp các giao thức mở nói trên, giúp ứng dụng gần như không cần sửa đổi gì khi chuyển lên cloud.
Một vài điểm khác biệt quan trọng của Amazon MQ so với SQS/SNS: