SNS-SQSではなくAmazon Kinesisを使用する必要があるのはなぜですか？
データのストリームが来るユースケースがあり、同じペースで消費することができず、バッファが必要です。これは、SNS-SQSキューを使用して解決できます。 Kinesisが同じ目的を解決することを知ったので、違いは何ですか？ Kinesisを好む（または好まない）必要があるのはなぜですか？
表面上はあいまいに似ていますが、使用事例によって適切なツールが決まります。 IMO、SQSで問題がなければ、必要なことを行う場合は、よりシンプルで安価になりますが、AWS FAQからのより適切な使用例があります。 -決定を支援する両方のツールのケース：
この回答は2015年6月に正しかったことに留意してください
同じ問題を念頭に置いて問題をしばらく調査した後、メッセージの順序が重要でない限り、ほとんどのユースケースでSQS（SNSを使用）が好ましいことがわかりました（SQSはFIFOを保証しません）メッセージで）。
Kinesisには2つの主な利点があります（1）複数のアプリケーションから同じメッセージを読むことができます（2）必要に応じてメッセージを読み直すことができます。
両方の利点は、SNSをSQSのファンアウトとして使用することで実現できます。つまり、メッセージのプロデューサーは1つのメッセージのみをSNSに送信し、その後、SNSは各コンシューマアプリケーションに1つずつ、複数のSQSにメッセージをファンアウトします。このようにして、シャーディングキャパシティを考慮することなく、必要なだけ消費者を確保できます。
さらに、14日間メッセージを保持するSNSにサブスクライブされるSQSをもう1つ追加しました。通常、誰もこのSQSから読み取ることはありませんが、データを巻き戻したいバグの場合、このSQSからすべてのメッセージを簡単に読み取り、それらをSNSに再送信できます。 Kinesisは7日間の保存期間のみを提供します。
結論として、SNS + SQSははるかに簡単で、ほとんどの機能を提供します。 IMOでは、Kinesisを選択するには本当に強力なケースが必要です。
Kinesisは複数のコンシューマー機能をサポートします。つまり、同じデータレコードを異なるコンシューマーで同時にまたは24時間以内に異なる時間で処理できます.SQSの同様の動作は、複数のキューに書き込むことで実現でき、コンシューマーは複数のキューから読み取ることができます。ただし、複数のキューに再度書き込むと、システムでサブ秒{fewミリ秒}のレイテンシが追加されます。
第二に、Kinesisは、特定のEC2インスタンスで処理でき、マイクロバッチ計算{Counting＆Aggregation}を有効にできるパーティションキーを使用して、選択したルートデータレコードを異なるシャードにルーティングするルーティング機能を提供します。
AWSソフトウェアでの作業は簡単ですが、SQSを使用するのが最も簡単です。 Kinesisでは、事前に十分なシャードをプロビジョニングし、スパイク負荷を管理するためにシャードの数を動的に増やし、管理に必要なコストを削減するために減らす必要があります。 Kinesisの痛みです。SQSではそのようなことは必要ありません。 SQSは無限にスケーラブルです。
これらのテクノロジーのセマンティクスは、さまざまなシナリオをサポートするように設計されているため異なります。
- SNS/SQS：ストリーム内の項目ではない相互に関連
- Kinesis：ストリーム内の項目are相互に関連
例で違いを理解しましょう。
- 注文のストリームがあるとします。注文ごとに在庫を予約し、配送をスケジュールする必要があります。これが完了すると、ストリームからアイテムを安全に削除し、次の注文の処理を開始できます。次の順序を開始する前に、前の順序で完全にdoneです。
- 繰り返しますが、注文のストリームは同じですが、目標は目的地ごとに注文をグループ化することです。たとえば、同じ場所に10件の注文ができたら、それらを一緒に配信します（配信の最適化）。ストーリーは異なります。ストリームから新しいアイテムを取得すると、処理を終了できません。むしろ、目標を達成するためにより多くのアイテムが来るのを「待ち」ます。さらに、プロセッサプロセスがクラッシュした場合、状態を「復元」する必要があります（したがって、順序が失われることはありません）。
あるアイテムの処理を別のアイテムの処理から分離できない場合、すべてのケースを安全に処理するためにKinesisセマンティクスが必要です。
私にとっての最大の利点は、Kinesisは再生可能なキューであり、SQSはそうではないという事実です。そのため、SQSを使用すると、Kinesisの同じメッセージの複数のコンシューマー（または異なるコンシューマーの同じコンシューマー）がいることができます。そのため、SQSはワーカーキューに適しています。
AWSドキュメント からの抜粋：
次のような要件を持つユースケースにはAmazon Kinesis Streamsをお勧めします：
関連レコードを同じレコードプロセッサにルーティングする（ストリーミングMapReduceの場合と同様）。たとえば、特定のキーのすべてのレコードが同じレコードプロセッサにルーティングされると、カウントと集計がより簡単になります。
レコードの順序。たとえば、ログステートメントの順序を維持したまま、アプリケーションホストから処理/アーカイブホストにログデータを転送したいとします。
複数のアプリケーションが同じストリームを同時に消費する機能。たとえば、リアルタイムダッシュボードを更新するアプリケーションと、データをAmazon Redshiftにアーカイブするアプリケーションがあります。両方のアプリケーションが同じストリームからのデータを同時に独立して消費するようにします。
数時間後に同じ順序でレコードを消費する機能。たとえば、請求アプリケーションと、請求アプリケーションよりも数時間遅れて実行される監査アプリケーションがあるとします。 Amazon Kinesis Streamsは最大7日間データを保存するため、請求アプリケーションよりも最大7日間遅れて監査アプリケーションを実行できます。
次のような要件を持つユースケースにはAmazon SQSをお勧めします：
メッセージングセマンティクス（メッセージレベルのack/failなど）および可視性タイムアウト。たとえば、作業項目のキューがあり、各項目が正常に完了したことを個別に追跡したい場合。 Amazon SQSはack/failを追跡するため、アプリケーションは永続的なチェックポイント/カーソルを維持する必要がありません。 Amazon SQSは、設定された可視性タイムアウト後に、確認されたメッセージを削除し、失敗したメッセージを再配信します。
個々のメッセージの遅延。たとえば、ジョブキューがあり、個々のジョブを遅延してスケジュールする必要があるとします。 Amazon SQSを使用すると、個々のメッセージに最大15分の遅延を設定できます。
読み取り時の同時実行性/スループットの動的増加。たとえば、作業キューがあり、バックログがクリアされるまでリーダーをさらに追加したいとします。 Amazon Kinesis Streamsでは、十分な数のシャードにスケールアップできます（ただし、事前に十分なシャードをプロビジョニングする必要があることに注意してください）。
透過的にスケーリングするAmazon SQSの機能を活用します。たとえば、リクエストをバッファリングし、時々発生する負荷の急増やビジネスの自然な成長の結果として負荷が変化します。バッファリングされた各リクエストは独立して処理できるため、Amazon SQSは透過的にスケーリングして、プロビジョニングの指示なしで負荷を処理できます。
もう1つ：KinesisはLambdaをトリガーできますが、SQSはトリガーできません。したがって、SQSを使用すると、SQSメッセージを処理するEC2インスタンスを提供する必要があります（失敗した場合は処理します）。 。
価格設定モデルは異なるため、ユースケースに応じてどちらかがより安くなる場合があります。最も単純な場合（SNSを含まない）：
- メッセージごとのSQS課金（各64 KBは1つのリクエストとしてカウントされます）。
- 1時間あたりのシャードあたりのKinesis料金（1つのシャードは最大1000のメッセージまたは1 MB /秒を処理できます）および入力したデータ量（25 KBごと）に対しても課金されます。
無料枠を考慮せずに現在の価格を差し込むと、最大メッセージサイズで1日あたり1 GBのメッセージを送信する場合、KinesisはSQSをはるかに上回ります（Kinesisの場合は月額10.82ドル、SQSの場合は月額0.20ドル）。 。ただし、1日に1 TBを送信する場合、Kinesisの方がいくぶん安くなります（SQSの場合は201ドル/月に対して158ドル/月）。
詳細：SQSは、100万リクエストあたり0.40ドル（各64 KB）を請求するため、GBあたり0.00655ドルです。 1日あたり1 GBで、これは月額0.20ドル弱です。 1日1 TBで、月額201ドル強になります。
Kinesisは、リクエスト100万件あたり0.014ドル（各25 KB）を請求するため、GBあたり0.00059ドルです。 1日あたり1 GBで、これは1か月あたり0.02ドル未満です。 1日1 TBで、月額約18ドルです。ただし、Kinesisはシャード時間あたり0.015ドルも請求します。 1 MB /秒あたり少なくとも1つのシャードが必要です。 1日あたり1 GBの場合、1つのシャードで十分になるため、1日あたり0.36ドルが追加され、1か月あたりの合計費用は10.82ドルになります。 1 TBで1日に少なくとも13のシャードが必要になり、1日に$ 4.68が追加され、1か月に合計158ドルのコストがかかります。
Kinesisは、ストリーミングデータの一般的なmap-reduceシナリオでマップパーツの問題を解決します。 SQSはそれを確認しませんが。キーで集約する必要があるストリーミングデータがある場合、kinesisにより、そのキーのすべてのデータが特定のシャードに送られ、シャードが単一のホストで消費され、SQSと比較してキーの集約が容易になります。
誰も言及していないことをもう1つ追加します。SQSは数桁高価です。