1. Section Introduction.
Khi triển khai nhiều ứng dụng, chúng ta không thể tránh khỏi việc các ứng dụng cần phải giao tiếp với nhau để có thể hoạt động một cách hiệu quả. Việc giao tiếp này có thể được thực hiện bằng hai mô hình chính, đó là:
- Request-Response Pattern (Mô hình Yêu Cầu – Phản hồi): Mô hình này là phổ biến nhất trong việc giao tiếp giữa các ứng dụng. Theo đó, một ứng dụng sẽ gửi một yêu cầu đến ứng dụng khác, và ứng dụng nhận yêu cầu sẽ xử lý và trả về phản hồi cho ứng dụng ban đầu. Mô hình này phù hợp cho các ứng dụng có tính chất đồng bộ, nghĩa là các ứng dụng phải chờ đợi phản hồi trước khi có thể tiếp tục hoạt động. Mô hình yêu cầu – phản hồi thường được sử dụng trong các ứng dụng web, trong đó người dùng sẽ gửi yêu cầu đến máy chủ, máy chủ xử lý yêu cầu và trả về kết quả.
- Publish-Subscribe Pattern (Mô hình Xuất bản – Đăng ký): Mô hình này được sử dụng khi các ứng dụng cần phải giao tiếp theo kiểu bất đồng bộ. Theo đó, một ứng dụng sẽ xuất bản thông tin lên một kênh (channel), và các ứng dụng khác có thể đăng ký (subscribe) để nhận các thông tin này. Khi có thông tin mới được xuất bản trên kênh, các ứng dụng đã đăng ký sẽ nhận được thông tin này và tiếp tục xử lý. Mô hình này phù hợp với các ứng dụng có tính chất bất đồng bộ, nghĩa là các ứng dụng có thể tiếp tục hoạt động mà không cần phải chờ đợi phản hồi. Mô hình xuất bản – đăng ký thường được sử dụng trong các hệ thống tương tác thời gian thực như các hệ thống đánh giá người dùng, các hệ thống phân tích dữ liệu, v.v.
– Synchronous communications (application to application)
Trong giao tiếp đồng bộ (synchronous communication) giữa các ứng dụng, một ứng dụng sẽ gửi yêu cầu đến ứng dụng khác và đợi đến khi nhận được phản hồi trước khi tiếp tục hoạt động. Mô hình này thường được sử dụng trong các ứng dụng web, trong đó người dùng sẽ gửi yêu cầu đến máy chủ, máy chủ xử lý yêu cầu và trả về kết quả.
Ví dụ, trong một ứng dụng bán hàng, khi khách hàng đặt hàng, ứng dụng BuyingService sẽ gửi yêu cầu đến ứng dụng ShippingService để lấy thông tin về phương tiện vận chuyển, địa chỉ giao hàng, v.v. Sau khi nhận được phản hồi từ ShippingService, BuyingService sẽ tiếp tục xử lý đơn hàng của khách hàng và trả về thông tin đơn hàng cho người dùng.
Tuy nhiên, mô hình giao tiếp đồng bộ có thể gây ra các vấn đề về hiệu suất nếu ứng dụng cần chờ đợi phản hồi từ ứng dụng khác trong một khoảng thời gian dài. Do đó, trong một số trường hợp, mô hình giao tiếp bất đồng bộ (asynchronous communication) có thể được sử dụng để giải quyết vấn đề hiệu suất.
– Asynchronous / Event based (application to queue to application).
Trong giao tiếp bất đồng bộ / Event based (asynchronous communication), ứng dụng sẽ gửi các yêu cầu đến hàng đợi (queue) để xử lý. Sau đó, ứng dụng sẽ tiếp tục hoạt động mà không phải chờ đợi phản hồi từ ứng dụng khác. Ứng dụng có thể lấy kết quả từ hàng đợi sau khi yêu cầu đã được xử lý.
Ví dụ, trong một ứng dụng bán hàng, khi khách hàng đặt hàng, ứng dụng BuyingService sẽ gửi yêu cầu đến hàng đợi để xử lý đơn hàng. Sau đó, ứng dụng sẽ tiếp tục xử lý các yêu cầu khác trong khi đơn hàng đang được xử lý. Khi đơn hàng đã được xử lý hoàn tất, kết quả sẽ được gửi đến hàng đợi, và ứng dụng ShippingService sẽ lấy thông tin về đơn hàng từ hàng đợi để tiếp tục xử lý.
Mô hình giao tiếp bất đồng bộ thường được sử dụng trong các ứng dụng lớn, với nhiều công việc cần xử lý và nhiều ứng dụng cần truy cập vào cùng một hàng đợi. Tuy nhiên, việc quản lý hàng đợi và xử lý lỗi có thể là một thách thức và cần được xử lý một cách chính xác để đảm bảo tính nhất quán và độ tin cậy của ứng dụng.
Nếu có đột ngột gia tăng lưu lượng truy cập giữa các ứng dụng, việc sử dụng giao tiếp đồng bộ có thể gây ra các vấn đề hiệu suất, làm giảm tính khả dụng và tính mở rộng của ứng dụng. Trong trường hợp này, tốt hơn là sử dụng các dịch vụ được tách rời khỏi ứng dụng, như Amazon SQS (hàng đợi), Amazon SNS (mô hình xuất bản/đăng ký), hoặc Amazon Kinesis (mô hình truyền dữ liệu thời gian thực).
Các dịch vụ này cho phép các ứng dụng trao đổi thông tin một cách không đồng bộ, giúp giảm thiểu tối đa tác động đến hiệu suất và khả năng mở rộng của ứng dụng.
- SQS (Simple Queue Service): là một dịch vụ hàng đợi đơn giản và mạnh mẽ, cho phép các ứng dụng gửi và nhận thông điệp theo cơ chế hàng đợi (queue). SQS cho phép các ứng dụng xử lý hàng loạt thông điệp một cách hiệu quả, đồng thời cho phép ứng dụng mở rộng dễ dàng và linh hoạt.
- SNS (Simple Notification Service): là một dịch vụ xuất bản/đăng ký, cho phép các ứng dụng phát thông báo đến các kênh đăng ký một cách độc lập. SNS giúp các ứng dụng tách biệt và độc lập với nhau, đồng thời cho phép các ứng dụng nhận thông báo theo cơ chế “một lần và nhiều nơi” (fan-out) một cách hiệu quả.
- Kinesis: là một dịch vụ truyền dữ liệu thời gian thực, cho phép các ứng dụng thu thập và xử lý dữ liệu liên tục. Kinesis giúp các ứng dụng xử lý lưu lượng dữ liệu lớn một cách hiệu quả, đồng thời cho phép các ứng dụng mở rộng và linh hoạt.
Các dịch vụ này có thể tự động mở rộng và điều chỉnh khả năng mở rộng của chúng một cách linh hoạt, tách rời khỏi các ứng dụng của bạn, giúp đảm bảo hiệu suất và tính sẵn sàng cao của hệ thống.
2. SQS – Producing Messages.
Amazon SQS (Simple Queue Service) là một dịch vụ hàng đợi đơn giản và mạnh mẽ của Amazon Web Services, cho phép các ứng dụng gửi và nhận thông điệp theo cơ chế hàng đợi (queue).
Một hàng đợi (queue) trong SQS là một điểm trung tâm để các ứng dụng gửi và nhận các thông điệp (message). Khi một ứng dụng gửi thông điệp đến hàng đợi, SQS sẽ lưu trữ thông điệp vào hàng đợi và gửi một xác nhận (acknowledgement) trở lại cho ứng dụng. Các ứng dụng khác có thể đọc các thông điệp từ hàng đợi theo cơ chế first-in, first-out (FIFO).
SQS giúp các ứng dụng xử lý hàng loạt thông điệp một cách hiệu quả và độc lập với nhau. SQS cung cấp các tính năng như đảm bảo tính toàn vẹn của thông điệp, tự động mở rộng khả năng xử lý và tích hợp với các dịch vụ khác của AWS. SQS cũng hỗ trợ nhiều loại hàng đợi, bao gồm hàng đợi chuẩn và hàng đợi FIFO, tùy thuộc vào nhu cầu sử dụng của ứng dụng.
Với SQS, các ứng dụng có thể trao đổi thông tin một cách không đồng bộ, giảm thiểu tối đa tác động đến hiệu suất và khả năng mở rộng của ứng dụng. SQS là một công cụ mạnh mẽ để xây dựng các ứng dụng phân tán, hệ thống xử lý hàng loạt và các ứng dụng thời gian thực.
3. Amazon SQS – Standard Queue.
Amazon SQS Standard Queue là một trong những loại hàng đợi được cung cấp bởi dịch vụ Simple Queue Service của Amazon. Đây là loại hàng đợi được phát triển đầu tiên của SQS, được sử dụng để tách biệt các ứng dụng và giúp chúng giao tiếp với nhau một cách hiệu quả.
SQS Standard Queue là một dịch vụ quản lý đầy đủ, do đó không yêu cầu quản trị viên phải quản lý hoặc triển khai bất kỳ phần mềm nào. Với SQS Standard Queue, người dùng có thể gửi và nhận thông điệp bất kỳ lúc nào, đồng thời được hỗ trợ khả năng xử lý không giới hạn và số lượng thông điệp trong hàng đợi không giới hạn.
Tính năng của SQS Standard Queue bao gồm:
- Khả năng xử lý thông điệp không giới hạn
- Số lượng thông điệp trong hàng đợi không giới hạn
- Thời gian lưu trữ thông điệp mặc định là 4 ngày, tối đa là 14 ngày
- Độ trễ thấp (ít hơn 10ms khi gửi và nhận thông điệp)
- Giới hạn kích thước thông điệp là 256KB
- Có thể có thông điệp trùng lặp (giao hàng ít nhất một lần, đôi khi)
- Có thể có thông điệp không theo thứ tự (sắp xếp theo nỗ lực tốt nhất)
Với những tính năng trên, SQS Standard Queue là một lựa chọn tốt để xây dựng các hệ thống phân tán, xử lý hàng loạt và các ứng dụng thời gian thực.
Bây giờ để demo chúng ta vào Amazon SQS > Queues > Create queue và ở bài này mình sẽ lựa chọn type là Standard. Nhớ đặt tên cho nó và kéo xuống dưới.
Kéo xuống phần Configuration, tại đây mình chỉ thay đổi 2 tuỳ chọn đó là Message retention period và Visibility timeout, giải thích chút xíu về 5 trường này như sau. Visibility timeout, Message retention period, Delivery delay, Maximum message size và Receive message wait time là năm thuật ngữ quan trọng trong Amazon Simple Queue Service (SQS), được sử dụng để quản lý và xử lý các tin nhắn trong hàng đợi.
- Visibility timeout: Visibility timeout là khoảng thời gian mà một tin nhắn trong hàng đợi SQS sẽ không được consumer (người tiêu thụ) nhận và xử lý sau khi đã được một consumer yêu cầu để xử lý tin nhắn đó. Trong thời gian này, tin nhắn sẽ vẫn còn trong hàng đợi nhưng không có consumer nào có thể nhận và xử lý tin nhắn đó. Mục đích của Visibility timeout là để đảm bảo rằng một tin nhắn chỉ được xử lý bởi một consumer duy nhất, tránh trường hợp xử lý trùng lặp và đảm bảo tính nhất quán trong dữ liệu. Trong quá trình xử lý tin nhắn, nếu consumer không hoàn thành việc xử lý trong khoảng thời gian của Visibility timeout, tin nhắn đó sẽ trở lại trong hàng đợi và sẵn sàng cho consumer khác tiếp tục xử lý.
- Message retention period: Message retention period là thời gian tối đa mà một tin nhắn trong hàng đợi SQS có thể tồn tại trước khi bị xóa. Mặc định, Message retention period của Amazon SQS là 4 ngày, nghĩa là tin nhắn sẽ tồn tại trong hàng đợi trong 4 ngày trước khi bị xóa. Nếu tin nhắn không được consumer xử lý trong thời gian của Visibility timeout và Message retention period đã hết, tin nhắn đó sẽ bị xóa khỏi hàng đợi và sẽ không còn khả dụng để xử lý nữa. Việc thiết lập Message retention period có thể giúp bạn quản lý các tin nhắn trong hàng đợi của mình và đảm bảo rằng dữ liệu được giữ lại chỉ trong khoảng thời gian cần thiết. Nếu bạn muốn tin nhắn được giữ lại trong thời gian lâu hơn hoặc ngắn hơn, bạn có thể điều chỉnh Message retention period cho phù hợp với nhu cầu của bạn.
- Delivery delay: Delivery delay là khoảng thời gian mà một tin nhắn mới được thêm vào hàng đợi SQS sẽ bị trì hoãn trước khi trở thành khả dụng để consumer nhận và xử lý. Mục đích của Delivery delay là để đảm bảo rằng tin nhắn mới được thêm vào hàng đợi chỉ được consumer nhận và xử lý khi nó đã được chuẩn bị đầy đủ. Ví dụ, nếu bạn muốn chạy một batch job vào lúc 2 giờ sáng mỗi ngày, bạn có thể sử dụng Delivery delay để đặt một khoảng thời gian trì hoãn cho các tin nhắn mới được thêm vào hàng đợi, đảm bảo rằng chúng chỉ được consumer nhận và xử lý vào lúc 2 giờ sáng.
- Maximum message size: Maximum message size là kích thước tối đa cho một tin nhắn trong hàng đợi SQS. Nếu một tin nhắn vượt quá kích thước tối đa, nó sẽ bị từ chối và không được thêm vào hàng đợi. Nếu bạn cần gửi các tin nhắn lớn hơn kích thước tối đa, bạn có thể tách chúng thành các phần nhỏ hơn và gửi chúng dưới dạng các tin nhắn riêng lẻ.
- Receive message wait time: Receive message wait time là khoảng thời gian mà consumer được phép chờ đợi để nhận tin nhắn trong hàng đợi SQS. Nếu không có tin nhắn nào trong hàng đợi, consumer sẽ chờ đợi trong khoảng thời gian này trước khi quyết định kết thúc yêu cầu nhận tin nhắn. Nếu có tin nhắn trong hàng đợi, consumer sẽ nhận tin nhắn đầu tiên trong hàng đợi và tiếp tục xử lý tin nhắn đó. Nếu consumer không hoàn thành việc xử lý trong khoảng thời gian của Visibility timeout, tin nhắn đó sẽ trở lại trong hàng đợi và sẵn sàng cho consumer khác tiếp tục xử lý. Nếu bạn muốn consumer nhận tin nhắn ngay lập tức khi nó có sẵn trong hàng đợi, bạn có thể thiết lập Receive message wait time là 0. Nếu bạn muốn consumer chờ đợi trong khoảng thời gian nhất định trước khi nhận tin nhắn, bạn có thể
Kéo xuống Access policy ta có 1 số tuỳ chọn sau, tại tuỳ chọn Basic.
“Only the queue owner”, “Only the specified AWS accounts, IAM users and roles” là các tùy chọn để xác định ai được phép truy cập vào queue trong Amazon Simple Queue Service (SQS).
- Only the queue owner: Tùy chọn này chỉ cho phép chủ sở hữu của queue được phép truy cập vào queue đó. Các tài khoản AWS khác sẽ không được phép truy cập vào queue.
- Only the specified AWS accounts, IAM users and roles: Tùy chọn này cho phép bạn chỉ định các tài khoản AWS cụ thể được phép truy cập vào queue. Bạn cần cung cấp danh sách các tài khoản AWS, và chỉ các tài khoản này mới được phép truy cập vào queue. IAM users and roles cho phép bạn xác định quyền truy cập vào queue cho các người dùng và vai trò được xác định trong IAM. Bạn có thể cung cấp các quyền truy cập khác nhau cho các người dùng và vai trò khác nhau thông qua thiết lập IAM policies. Ví dụ, bạn có thể cho phép một số người dùng có quyền gửi tin nhắn vào queue, trong khi các người dùng khác chỉ được phép nhận tin nhắn.
Khi thiết lập quyền truy cập cho queue trong SQS, bạn có thể chọn một trong các tùy chọn trên để giới hạn người dùng và tài khoản được phép truy cập vào queue. Nếu bạn chỉ muốn chủ sở hữu queue được phép truy cập vào queue, tùy chọn “Only the queue owner” là lựa chọn tốt nhất. Nếu bạn muốn cho phép một số tài khoản AWS cụ thể truy cập vào queue, bạn nên chọn tùy chọn “Only the specified AWS accounts”. Nếu bạn muốn xác định các quyền truy cập chi tiết hơn cho các người dùng và vai trò được xác định trong IAM, tùy chọn “IAM users and roles” là lựa chọn phù hợp nhất.
Tại tuỳ chọn Advanced.
Trong Amazon Simple Queue Service (SQS), bạn có thể sử dụng một đối tượng JSON để định nghĩa một chính sách truy cập nâng cao cho hàng đợi của mình. Tùy chọn này được gọi là “Advanced access policy” và cho phép bạn xác định các quyền truy cập chi tiết hơn cho các tài khoản và người dùng.
Để định nghĩa một chính sách truy cập nâng cao, bạn cần tạo một đối tượng JSON chứa các thuộc tính sau:
- “Version”: Phiên bản của chính sách truy cập. Hiện tại, phiên bản được hỗ trợ là “2012-10-17”.
- “Id”: Một ID duy nhất cho chính sách truy cập của bạn. Giá trị này có thể là bất kỳ chuỗi nào.
- “Statement”: Một mảng các tuyên bố truy cập. Mỗi tuyên bố xác định các quyền truy cập cho một nhóm tài khoản hoặc người dùng cụ thể.
Mỗi tuyên bố truy cập trong mảng “Statement” cần có các thuộc tính sau:
- “Sid”: Một ID duy nhất cho tuyên bố truy cập. Giá trị này có thể là bất kỳ chuỗi nào.
- “Effect”: Xác định xem tuyên bố này có hiệu lực hay không. Giá trị của thuộc tính này có thể là “Allow” hoặc “Deny”.
- “Principal”: Xác định các tài khoản hoặc người dùng có quyền truy cập vào hàng đợi. Giá trị của thuộc tính này có thể là “*” (tất cả các tài khoản hoặc người dùng), một tài khoản hoặc người dùng cụ thể hoặc một nhóm tài khoản hoặc người dùng được định nghĩa trước đó.
- “Action”: Xác định các hành động được phép cho các tài khoản hoặc người dùng được định nghĩa trong thuộc tính “Principal”. Giá trị của thuộc tính này có thể là “*” (tất cả các hành động) hoặc một hành động cụ thể.
- “Resource”: Xác định tài nguyên mà tuyên bố truy cập này áp dụng. Trong trường hợp này, tài nguyên là hàng đợi SQS. Giá trị của thuộc tính này là ARN (Amazon Resource Name) của hàng đợi.
Tại phần Encryption mình sẽ Enable tính năng này lên.
Giải thích về CMK.
CMK là viết tắt của “Customer Master Key” và là một khóa mã hóa được quản lý bởi khách hàng trên AWS Key Management Service (KMS).
Khi sử dụng dịch vụ AWS như S3, EC2, RDS, DynamoDB… để lưu trữ hoặc truy cập dữ liệu, khách hàng có thể sử dụng CMK để mã hóa hoặc giải mã dữ liệu của mình. KMS hỗ trợ tạo và quản lý các khóa mã hóa, bảo vệ chúng và theo dõi việc sử dụng chúng.
CMK được tạo ra bởi khách hàng hoặc bởi AWS KMS. Khi khách hàng tạo CMK của riêng mình, họ có thể kiểm soát toàn bộ quá trình tạo và quản lý khóa, bao gồm việc cấp phép quyền truy cập cho người dùng hoặc dịch vụ khác trên AWS. CMK của khách hàng được lưu trữ trên KMS và chỉ có thể truy cập được khi được xác thực đúng và được ủy quyền.
Một số trường hợp sử dụng CMK bao gồm:
- Mã hóa dữ liệu của khách hàng khi lưu trữ trên S3.
- Mã hóa ổ đĩa của EC2 instances.
- Mã hóa bản sao lưu của RDS databases.
- Mã hóa dữ liệu của DynamoDB tables.
- Mã hóa các file cấu hình, chứng chỉ SSL, private keys trên Elastic Load Balancer.
Việc sử dụng CMK giúp bảo vệ dữ liệu của khách hàng và tuân thủ các quy định bảo mật như HIPAA, PCI-DSS, GDPR.
Giải thích về Data key reuse period.
Data key reuse period là khoảng thời gian giữa hai lần sử dụng lại một khóa dữ liệu (data key) trong quá trình mã hóa hoặc giải mã dữ liệu trên AWS Key Management Service (KMS).
Khi khách hàng sử dụng một CMK trên KMS để mã hóa hoặc giải mã dữ liệu của mình, KMS sẽ sinh ra các khóa dữ liệu để sử dụng tạm thời trong quá trình này. Các khóa dữ liệu này được gọi là “data key”. Tuy nhiên, việc sử dụng lại một data key có thể gây ra rủi ro bảo mật nếu bị tấn công bởi kẻ xấu.
Vì vậy, AWS KMS hỗ trợ chức năng data key reuse period để giới hạn việc sử dụng lại một data key. Nếu khách hàng đặt giá trị data key reuse period, KMS sẽ tự động hủy bỏ data key sau thời gian đó, đồng thời sinh ra một data key mới để sử dụng cho quá trình mã hóa hoặc giải mã dữ liệu tiếp theo.
Tùy thuộc vào từng khóa mã hóa, khách hàng có thể đặt giá trị data key reuse period khác nhau để đảm bảo an toàn thông tin và tuân thủ các quy định bảo mật. Việc sử dụng chức năng này có thể giúp ngăn chặn các cuộc tấn công từ kẻ xấu và đảm bảo tính toàn vẹn dữ liệu của khách hàng trên KMS.
Kéo xuống dưới và bấm Create queue và bạn có kết quả, bây giờ hãy bấm vào Send and receive messages.
Để kiểm tra mình gửi một tin nhắn với nội dung hello world! và bấm Send message, bạn hãy để ý trước lúc bấm Send message thì Message available đang là 0.
Thông báo “Your message has been sent and ready to be received.” cho thấy bạn đã gửi tin nhắn thành công và tại Messages available đã thay đổi từ 0 sang 1.
Bạn để ý tại Receive count đang nhận là 1, bây giờ hãy bấm Poll for messages. Vậy Poll for messages là gì?
Poll for messages là một chức năng trong Amazon Simple Queue Service (SQS) cho phép các ứng dụng lấy các thông điệp từ hàng đợi SQS để xử lý. Thay vì phải liên tục gửi yêu cầu tới SQS để lấy thông điệp mới, ứng dụng có thể sử dụng chức năng Poll for messages để lấy thông điệp một cách hiệu quả và tiết kiệm tài nguyên.
Cách thức hoạt động của Poll for messages như sau: Ứng dụng sẽ gửi một yêu cầu Poll request đến SQS, sau đó SQS sẽ kiểm tra hàng đợi và trả về một hoặc nhiều thông điệp cho ứng dụng. Trong quá trình này, SQS sẽ giữ các thông điệp còn đang chờ xử lý trong hàng đợi.
Sau khi ứng dụng đã xử lý các thông điệp được nhận, nó có thể gửi một yêu cầu Delete message đến SQS để xóa các thông điệp đã được xử lý. Nếu các thông điệp không được xóa, chúng sẽ tiếp tục được giữ trong hàng đợi và có thể được trả về trong các lần yêu cầu Poll request tiếp theo.
Poll for messages là một chức năng quan trọng trong SQS, giúp các ứng dụng lấy thông điệp từ hàng đợi một cách hiệu quả và tiết kiệm tài nguyên, đồng thời đảm bảo tính toàn vẹn và tin cậy của thông điệp trong quá trình truyền tải và xử lý.
Khi bạn bấm vào MessageID: 1cbe8079-fdb2-4950-a380-169c5a5f7244 bạn sẽ thấy thông tin chi tiến Message.
Bấm qua thẻ Body bạn sẽ thấy nội dung Message.
Nếu bạn có config thuộc tính thì bạn có thể xem ở thẻ Attributes.
Sau khi xem một số thông tin xong, tại Receive count bạn thấy giá trị đã tăng từ 1 lên 3, lý do là trong vòng 30s bạn không xử lý tin nhắn thì nó sẽ gửi lại cho bạn.
Bây giờ mình sẽ dùng hành động xoá tin nhắn này xem như mình đã xử lý tin nhắn.
Sau khi xoá xong tin nhắn bạn sẽ không còn nhận được tin nhắn nào nữa sau 30s vì hành động xoá của bạn đã xử lý tin nhắn này.
4. SQS – Producing Messages.
Để gửi thông điệp đến SQS, người dùng có thể sử dụng SDK cung cấp bởi Amazon để gọi API SendMessage. Khi gửi thông điệp, nó sẽ được lưu trữ trong SQS cho đến khi một consumer xử lý nó hoặc xóa nó.
Thông điệp được lưu trữ trong SQS trong khoảng thời gian được quy định bởi message retention, mặc định là 4 ngày và tối đa là 14 ngày. Việc lưu trữ thông điệp cho đến khi consumer xử lý nó giúp đảm bảo rằng thông điệp không bị mất và consumer có thể xử lý nó bất cứ khi nào.
Ví dụ, khi muốn gửi một đơn hàng để được xử lý, người dùng có thể sử dụng API SendMessage để gửi thông điệp với các thuộc tính như order id, customer id và các thuộc tính khác.
SQS Standard có khả năng xử lý không giới hạn, cho phép người dùng gửi thông điệp với tốc độ cao và số lượng lớn mà không cần lo lắng về giới hạn về thời gian hay số lượng thông điệp.
5. SQS – Consuming Messages.
Để tiêu thụ thông điệp từ SQS, người dùng có thể triển khai các consumers chạy trên các EC2 instances, máy chủ hoặc AWS Lambda. Consumer sẽ liên tục kiểm tra SQS để lấy các thông điệp mới (lên tới 10 thông điệp mỗi lần nhận). Sau khi lấy được thông điệp, consumer sẽ xử lý nó (ví dụ: chèn thông điệp vào cơ sở dữ liệu RDS). Khi consumer xử lý xong thông điệp, nó sẽ sử dụng API DeleteMessage để xóa thông điệp đã xử lý để tránh consumer khác xử lý lại thông điệp đã xử lý.
Các consumers có thể được triển khai trên nhiều loại máy chủ, tùy thuộc vào yêu cầu của ứng dụng. Nếu ứng dụng của bạn có nhu cầu xử lý thông điệp liên tục mà không cần phải duy trì các máy chủ, bạn có thể sử dụng AWS Lambda để tạo các hàm xử lý thông điệp.
Việc sử dụng SQS cho phép người dùng xử lý thông điệp một cách linh hoạt và mạnh mẽ, với khả năng xử lý thông điệp lên tới hàng triệu thông điệp mỗi giây.
6. SQS – Multiple EC2 Instances Consumers.
Khi sử dụng SQS, người dùng có thể triển khai nhiều consumers trên nhiều EC2 instances để xử lý thông điệp một cách song song, giúp cải thiện khả năng xử lý và tăng thời gian đáp ứng của ứng dụng.
Việc triển khai nhiều consumers giúp tăng khả năng xử lý thông điệp một cách đồng thời. Tuy nhiên, vì SQS hỗ trợ tính năng “at least once delivery” và “best-effort message ordering”, nên có thể xuất hiện tình trạng các thông điệp bị trùng lặp hoặc các thông điệp bị xếp theo thứ tự không chính xác trong quá trình xử lý.
Sau khi xử lý xong, consumers sẽ sử dụng API DeleteMessage để xóa thông điệp đã được xử lý để tránh consumer khác xử lý lại thông điệp đã xử lý.
Việc triển khai nhiều consumers có thể giúp tăng khả năng xử lý của ứng dụng. Việc triển khai nhiều consumers có thể được thực hiện bằng cách sử dụng các công cụ của AWS như Auto Scaling hoặc EC2 Container Service để tự động mở rộng hoặc thu hẹp số lượng consumers tùy thuộc vào tải của hệ thống.
7. SQS with Auto Scaling Group (ASG).
Khi sử dụng SQS với Auto Scaling Group (ASG), người dùng có thể tự động mở rộng hoặc thu hẹp số lượng EC2 instances dựa trên lượng thông điệp trong hàng đợi SQS.
Cơ chế hoạt động như sau:
- ASG được cấu hình để sử dụng AMI (Amazon Machine Image) chứa các ứng dụng và dependencies để xử lý các thông điệp từ SQS.
- ASG sử dụng một Launch Configuration để khởi tạo một hoặc nhiều EC2 instances.
- Mỗi EC2 instance chạy một hoặc nhiều consumers để poll messages từ SQS queue và xử lý các messages đó.
- AWS CloudWatch Metrics được sử dụng để theo dõi chiều dài của hàng đợi SQS thông qua độ chính xác số lượng thông điệp (ApproximateNumberOfMessages) trong hàng đợi.
- Nếu độ chính xác số lượng thông điệp trong hàng đợi vượt quá ngưỡng được thiết lập trong cảnh báo, một cảnh báo sẽ được kích hoạt và gửi thông báo đến các thành viên trong nhóm SNS để cảnh báo về sự cố.
- CloudWatch Alarm sẽ kích hoạt một hành động tự động để thêm EC2 instances mới vào ASG hoặc loại bỏ instances hiện có khỏi ASG để đáp ứng với lượng lớn hơn hoặc ít hơn của thông điệp trong hàng đợi SQS.
Với cách tiếp cận này, người dùng có thể tăng hoặc giảm số lượng EC2 instances để xử lý lượng thông điệp lớn hơn hoặc nhỏ hơn mà không cần can thiệp vào hệ thống thủ công.
8. SQS to decouple between application tiers.
Trong kiến trúc ứng dụng phân tầng, thường có nhiều tầng ứng dụng khác nhau. Điều này dẫn đến việc cần phải truyền thông tin giữa các tầng để chúng có thể hoạt động cùng nhau. Tuy nhiên, việc truyền thông tin trực tiếp giữa các tầng ứng dụng có thể gây ra các vấn đề độc lập về quy mô, độ trễ, khả năng mở rộng và độ tin cậy.
Để giải quyết vấn đề này, Amazon Simple Queue Service (SQS) được sử dụng để tạo một hàng đợi giữa các tầng ứng dụng, làm nhiệm vụ đóng vai trò như một trung gian. Cụ thể, khi một yêu cầu được gửi từ phía người dùng thông qua giao diện người dùng, tầng ứng dụng giao diện người dùng sẽ gửi yêu cầu đó tới SQS thông qua phương thức gửi tin nhắn (SendMessage API).
Các tin nhắn này sẽ được lưu trữ trong hàng đợi SQS cho đến khi tầng ứng dụng xử lý được nó. Các tầng ứng dụng xử lý này có thể là các tầng ứng dụng chạy trên các EC2 instances, máy chủ hoặc hàm Lambda của AWS. Chúng sẽ liên tục kiểm tra hàng đợi SQS để lấy tin nhắn. Khi lấy được tin nhắn, chúng sẽ xử lý nó và xóa tin nhắn đó từ hàng đợi bằng cách sử dụng phương thức xóa tin nhắn (DeleteMessage API).
Trong trường hợp sử dụng Auto Scaling Group (ASG), các EC2 instances sẽ tự động mở rộng hoặc thu hẹp để đáp ứng với số lượng tin nhắn đến. Để giám sát số lượng tin nhắn trong hàng đợi, ta có thể sử dụng CloudWatch Metric và thiết lập cảnh báo bằng CloudWatch Alarm khi có dấu hiệu vượt quá giới hạn cho phép. Khi cảnh báo được kích hoạt, ASG sẽ tự động tạo ra thêm các EC2 instances để xử lý số lượng tin nhắn lớn hơn.
9. Amazon SQS – Security.
SQS cung cấp nhiều cơ chế bảo mật, bao gồm:
- Mã hóa trong quá trình truyền: SQS sử dụng giao thức HTTPS để mã hóa thông điệp trong quá trình truyền.
- Mã hóa ở nơi lưu trữ: SQS hỗ trợ việc mã hóa dữ liệu lưu trữ bằng cách sử dụng AWS Key Management Service (KMS) để tạo và quản lý các khóa mã hóa. Khi bạn sử dụng KMS để mã hóa hàng đợi SQS, thông điệp sẽ được mã hóa trước khi lưu trữ và giải mã sau khi nhận được.
- Mã hóa phía client: SQS cũng cho phép mã hóa phía client, cho phép khách hàng tự thực hiện mã hóa/giải mã.
- Kiểm soát truy cập: SQS sử dụng IAM policies để kiểm soát quyền truy cập đến API SQS. Bằng cách này, bạn có thể quản lý các người dùng AWS có thể truy cập vào hàng đợi SQS của bạn.
- SQS Access Policies: Các chính sách truy cập SQS (tương tự như các chính sách xếp hạng S3) cho phép bạn cấu hình quyền truy cập đến hàng đợi SQS của bạn cho các tài khoản AWS khác hoặc các nguồn khác. Điều này hữu ích khi bạn muốn cho phép các dịch vụ khác (ví dụ như SNS, S3…) ghi vào hàng đợi SQS của mình.
