Tại sao tôi nên sử dụng Amazon Kinesis mà không phải SNS-SQS?

Tôi có một trường hợp sử dụng trong đó sẽ có luồng dữ liệu đến và tôi không thể sử dụng nó với cùng tốc độ và cần một bộ đệm. Điều này có thể được giải quyết bằng cách sử dụng hàng đợi SNS-SQS. Tôi đã biết Kinesis giải quyết cùng một mục đích, vậy sự khác biệt là gì? Tại sao tôi nên thích (hoặc không nên thích) Kinesis?

Nhìn bề ngoài chúng giống nhau một cách mơ hồ, nhưng trường hợp sử dụng của bạn sẽ xác định công cụ nào là phù hợp. IMO, nếu bạn có thể nhận được bằng SQS thì bạn nên - nếu nó sẽ làm những gì bạn muốn, nó sẽ đơn giản và rẻ hơn, nhưng đây là một lời giải thích tốt hơn từ Câu hỏi thường gặp về AWS, ví dụ về các trường hợp sử dụng phù hợp cho cả hai công cụ giúp bạn quyết định:

Câu hỏi thường gặp

Hãy ghi nhớ câu trả lời này là chính xác cho tháng 6 năm 2015

Sau khi nghiên cứu vấn đề này một thời gian, có cùng một câu hỏi, tôi thấy rằng SQS (với SNS) được ưa thích cho hầu hết các trường hợp sử dụng trừ khi thứ tự của các tin nhắn là quan trọng đối với bạn (SQS không đảm bảo FIFO trên tin nhắn).

Có 2 ưu điểm chính cho Kinesis:

1. bạn có thể đọc cùng một tin nhắn từ một số ứng dụng
2. bạn có thể đọc lại tin nhắn trong trường hợp bạn cần.

Cả hai lợi thế đều có thể đạt được bằng cách sử dụng SNS như một fan hâm mộ cho SQS. Điều đó có nghĩa là nhà sản xuất tin nhắn chỉ gửi một tin nhắn tới SNS, sau đó người hâm mộ SNS gửi tin nhắn đến nhiều SQS, một tin nhắn cho mỗi ứng dụng khách hàng. Bằng cách này, bạn có thể có nhiều người tiêu dùng như bạn muốn mà không cần suy nghĩ về khả năng bảo vệ.

Hơn nữa, chúng tôi đã thêm một SQS được đăng ký vào SNS sẽ giữ tin nhắn trong 14 ngày. Trong trường hợp bình thường, không ai đọc được từ SQS này nhưng trong trường hợp có lỗi khiến chúng tôi muốn tua lại dữ liệu, chúng tôi có thể dễ dàng đọc tất cả các tin nhắn từ SQS này và gửi lại cho SNS. Trong khi Kinesis chỉ cung cấp duy trì 7 ngày.

Tóm lại, SNS + SQS dễ dàng hơn nhiều và cung cấp hầu hết các khả năng. IMO bạn cần một trường hợp thực sự mạnh mẽ để chọn Kinesis trên nó.

Kinesis hỗ trợ nhiều khả năng của người tiêu dùng, có nghĩa là các bản ghi dữ liệu giống nhau có thể được xử lý cùng lúc hoặc khác nhau trong vòng 24 giờ tại các người tiêu dùng khác nhau, hành vi tương tự trong SQS có thể đạt được bằng cách viết vào nhiều hàng đợi và người tiêu dùng có thể đọc từ nhiều hàng đợi. Tuy nhiên, viết lại vào nhiều hàng đợi sẽ thêm độ trễ phụ {vài mili giây} trong hệ thống.

Thứ hai, Kinesis cung cấp khả năng định tuyến cho các bản ghi dữ liệu định tuyến chọn lọc tới các phân đoạn khác nhau bằng cách sử dụng khóa phân vùng có thể được xử lý bởi các trường hợp EC2 cụ thể và có thể kích hoạt tính toán lô vi {Đếm & tổng hợp}.

Làm việc trên bất kỳ phần mềm AWS nào đều dễ dàng nhưng với SQS thì dễ nhất. Với Kinesis, cần phải cung cấp đủ số lượng mảnh vỡ trước thời hạn, tăng số lượng mảnh vỡ linh hoạt để quản lý tải trọng tăng đột biến và giảm để tiết kiệm chi phí cũng cần phải quản lý. đó là nỗi đau ở Kinesis, Không yêu cầu những thứ như vậy với SQS. SQS có khả năng mở rộng vô hạn.

Ngữ nghĩa của các công nghệ này là khác nhau vì chúng được thiết kế để hỗ trợ các kịch bản khác nhau:

• SNS / SQS: các mục trong luồng không liên quan với nhau
• Kinesis: các mục trong luồng có liên quan với nhau

Hãy hiểu sự khác biệt bằng ví dụ.

1. Giả sử chúng ta có một dòng đơn đặt hàng, cho mỗi đơn hàng, chúng ta cần đặt trước một số cổ phiếu và lên lịch giao hàng. Khi điều này hoàn tất, chúng ta có thể xóa mục đó khỏi luồng một cách an toàn và bắt đầu xử lý đơn hàng tiếp theo. Chúng tôi hoàn thành với đơn hàng trước khi bắt đầu kế tiếp.
2. Một lần nữa, chúng tôi có cùng một dòng đơn đặt hàng, nhưng bây giờ mục tiêu của chúng tôi là nhóm các đơn đặt hàng theo điểm đến. Khi chúng tôi có 10 đơn hàng đến cùng một địa điểm, chúng tôi muốn phân phối chúng cùng nhau (tối ưu hóa phân phối). Bây giờ câu chuyện đã khác: khi chúng tôi nhận được một mục mới từ luồng, chúng tôi không thể hoàn thành việc xử lý nó; thay vì chúng tôi "chờ" cho nhiều mặt hàng đến để đáp ứng mục tiêu của chúng tôi. Hơn nữa, nếu bộ xử lý gặp sự cố, chúng ta phải "khôi phục" trạng thái (vì vậy sẽ không có đơn hàng nào bị mất).

Sau khi xử lý một mục không thể tách rời khỏi xử lý một mục khác, chúng ta phải có ngữ nghĩa Kinesis để xử lý tất cả các trường hợp một cách an toàn.

Trích từ Tài liệu AWS :

Chúng tôi khuyên dùng Luồng Amazon Kinesis cho các trường hợp sử dụng với các yêu cầu tương tự như sau:

• Định tuyến các bản ghi liên quan đến cùng bộ xử lý bản ghi (như phát trực tuyến MapReduce). Ví dụ, đếm và tổng hợp đơn giản hơn khi tất cả các bản ghi cho một khóa đã cho được chuyển đến cùng một bộ xử lý bản ghi.

• Đặt hàng hồ sơ. Ví dụ: bạn muốn chuyển dữ liệu nhật ký từ máy chủ ứng dụng sang máy chủ lưu trữ xử lý / lưu trữ trong khi duy trì thứ tự của các báo cáo nhật ký.

• Khả năng cho nhiều ứng dụng để sử dụng cùng một luồng. Ví dụ: bạn có một ứng dụng cập nhật bảng điều khiển thời gian thực và một ứng dụng khác lưu trữ dữ liệu lên Amazon Redshift. Bạn muốn cả hai ứng dụng tiêu thụ dữ liệu từ cùng một luồng đồng thời và độc lập.

• Khả năng tiêu thụ hồ sơ theo thứ tự một vài giờ sau đó. Ví dụ: bạn có ứng dụng thanh toán và ứng dụng kiểm toán chạy sau ứng dụng thanh toán vài giờ. Vì Amazon Kinesis Stream lưu trữ dữ liệu trong tối đa 7 ngày, bạn có thể chạy ứng dụng kiểm toán tối đa 7 ngày sau ứng dụng thanh toán.

Chúng tôi khuyên dùng Amazon SQS cho các trường hợp sử dụng với các yêu cầu tương tự như sau:

• Ngữ nghĩa nhắn tin (chẳng hạn như ack / fail cấp độ tin nhắn) và thời gian chờ hiển thị. Ví dụ: bạn có một hàng các mục công việc và muốn theo dõi việc hoàn thành thành công từng mục một cách độc lập. Amazon SQS theo dõi ack / fail, vì vậy ứng dụng không phải duy trì điểm kiểm tra / con trỏ liên tục. Amazon SQS sẽ xóa các tin nhắn được đánh dấu và gửi lại các tin nhắn thất bại sau khi hết thời gian hiển thị được định cấu hình.

• Tin nhắn chậm trễ. Ví dụ, bạn có một hàng đợi công việc và cần lên lịch cho các công việc riêng lẻ với sự chậm trễ. Với Amazon SQS, bạn có thể định cấu hình các thư riêng lẻ để có độ trễ tối đa 15 phút.

• Tự động tăng đồng thời / thông lượng tại thời điểm đọc. Ví dụ: bạn có một hàng đợi công việc và muốn thêm nhiều người đọc cho đến khi tồn đọng được xóa. Với Luồng Amazon Kinesis, bạn có thể mở rộng tối đa số lượng phân đoạn (tuy nhiên, lưu ý rằng bạn sẽ cần cung cấp đủ số lượng phân đoạn trước thời hạn).

• Tận dụng khả năng mở rộng minh bạch của Amazon SQS. Ví dụ: bạn yêu cầu bộ đệm và tải thay đổi do kết quả của việc tăng tải thỉnh thoảng hoặc tăng trưởng tự nhiên của doanh nghiệp của bạn. Vì mỗi yêu cầu được đệm có thể được xử lý độc lập, Amazon SQS có thể mở rộng quy mô trong suốt để xử lý tải mà không cần bất kỳ hướng dẫn cung cấp nào từ bạn.

Lợi thế lớn nhất đối với tôi là Kinesis là một hàng đợi có thể phát lại, còn SQS thì không. Vì vậy, bạn có thể có nhiều người tiêu dùng của cùng một tin nhắn của Kinesis (hoặc cùng một người tiêu dùng vào các thời điểm khác nhau) trong đó với SQS, một khi một tin nhắn đã được gửi đi, nó sẽ đi từ hàng đợi đó. SQS tốt hơn cho hàng đợi công nhân vì điều đó.

Một điều nữa: Kinesis có thể kích hoạt Lambda, trong khi SQS thì không. Vì vậy, với SQS, bạn phải cung cấp một phiên bản EC2 để xử lý các thông báo SQS (và xử lý nếu không thành công) hoặc bạn phải có Lambda theo lịch trình (không tăng hoặc giảm quy mô - bạn chỉ nhận được một phút mỗi phút) .

Chỉnh sửa: Câu trả lời này không còn đúng nữa. SQS có thể kích hoạt trực tiếp Lambda kể từ tháng 6 năm 2018

https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html

Các mô hình định giá là khác nhau, do đó tùy thuộc vào trường hợp sử dụng của bạn, cái này hay cái kia có thể rẻ hơn. Sử dụng trường hợp đơn giản nhất (không bao gồm SNS):

• Tính phí SQS cho mỗi tin nhắn (mỗi 64 KB được tính là một yêu cầu).
• Kinesis tính phí trên mỗi phân đoạn mỗi giờ (1 phân đoạn có thể xử lý tối đa 1000 tin nhắn hoặc 1 MB / giây) và cũng cho lượng dữ liệu bạn đưa vào (cứ sau 25 KB).

Cắm vào giá hiện tại và không tính đến cấp miễn phí, nếu bạn gửi 1 GB tin nhắn mỗi ngày ở kích thước tin nhắn tối đa, Kinesis sẽ có giá cao hơn nhiều so với SQS (10,82 đô la / tháng cho Kinesis so với 0,20 đô la / tháng cho SQS) . Nhưng nếu bạn gửi 1 TB mỗi ngày, Kinesis có phần rẻ hơn (158 đô la / tháng so với 201 đô la / tháng đối với SQS).

Chi tiết: SQS tính phí $ 0,40 mỗi triệu yêu cầu (mỗi 64 KB), vì vậy $ 0,00655 mỗi GB. Với 1 GB mỗi ngày, đây chỉ dưới 0,20 đô la mỗi tháng; ở mức 1 TB mỗi ngày, nó lên đến hơn $ 201 mỗi tháng.

Kinesis tính phí 0,011 đô la mỗi triệu yêu cầu (mỗi yêu cầu 25 KB), vì vậy 0,00059 đô la mỗi GB. Ở mức 1 GB mỗi ngày, đây là dưới 0,02 đô la mỗi tháng; ở mức 1 TB mỗi ngày, nó là khoảng $ 18 mỗi tháng. Tuy nhiên, Kinesis cũng tính phí 0,015 đô la mỗi giờ. Bạn cần ít nhất 1 shard mỗi 1 MB mỗi giây. Với 1 GB mỗi ngày, 1 shard sẽ rất nhiều, do đó sẽ thêm 0,36 đô la mỗi ngày, với tổng chi phí là 10,82 đô la mỗi tháng. Với 1 TB mỗi ngày, bạn sẽ cần ít nhất 13 mảnh, cộng thêm 4,68 đô la mỗi ngày, với tổng chi phí là 158 đô la mỗi tháng.

Kinesis giải quyết vấn đề của phần bản đồ trong kịch bản giảm bản đồ điển hình để truyền dữ liệu. Trong khi SQS không chắc chắn về điều đó. Nếu bạn có dữ liệu phát trực tuyến cần được tổng hợp trên một khóa, kinesis đảm bảo rằng tất cả dữ liệu cho khóa đó sẽ chuyển đến một phân đoạn cụ thể và phân đoạn có thể được sử dụng trên một máy chủ duy nhất giúp việc tổng hợp trên khóa dễ dàng hơn so với SQS

Tôi sẽ thêm một điều nữa mà không ai khác đã đề cập - SQS là một số đơn đặt hàng lớn hơn đắt tiền.

Trường hợp sử dụng Kinesis

• Thu thập dữ liệu nhật ký và sự kiện
• Phân tích thời gian thực
• Ghi dữ liệu di động
• Internet của vạn vật dữ liệu thức ăn dữ liệu

Các trường hợp sử dụng SQS

• Tích hợp ứng dụng
• Decoupling microservice
• Phân bổ nhiệm vụ cho nhiều nút worker
• Decouple yêu cầu người dùng trực tiếp từ công việc nền chuyên sâu
• Tin nhắn hàng loạt để xử lý trong tương lai