KinesisとSQSはとても似ているサービスで、どのように使い分けたらよいか、どんな違いがあるのかが
気になっていました。
そんな時、以下の記事を見つけました。
とても良い記事なので、翻訳記事を紹介します。
以下翻訳記事：
私達がWorkviaのメッセージングシステムを設計する際、Kinesisをメッセージストレージ及びデリバリメカニズムとして利用することを検討しました。
最初は、kinesisはどのような課題も解決できる特徴を持っているように見えました。
Kinesisはテラバイト級のデータを保管でき、古いメッセージの再送をする機能を持っていて、複数のメッセージコンシューマを利用することをサポートしていたからです。
しかし、もう少し細かな点まで確認していくと、Kinesisは特別なユースケースにはとても適していることがわかりました。
そしてあなたのアプリケーションがそのユースケースに適合しなかった場合、Kinesisが持つ価値よりもおおくのトラブルを生むことになるでしょう。
この記事では、KinesisとAmazonのSimple Queue Service(SQS)を比較した結果を
それぞれのメリット・デメリット、データストリームとキューイングの違いにフォーカスしながら説明します。
この記事を通して、なぜ私達がなぜ堅牢なメッセージングシステムを作るためにSQSを使ったか、あなたのシステムがSQSを使うことによって恩恵を受けることができるかについて明らかにします。
データストリーム - Kinesisのスイートスポット
Kinesisの最もメジャーなユースケースは、継続的なデータストリームからのリアルタイムなデータの収集・保管です。
データストリームはいくつものデータソースから継続的に生み出されるデータのことを指します。これらのデータは一般的にはデータレコードの中に同時に含まれ、個々のサイズが小さいことが特徴です。（１データ数キロバイト程度）
一般的なデータストリームは、eコマース解析のためやゲームプレーヤのアクティビティ、ソーシャル・ネットワーク上の情報といったのログファイルのことを指します。Workivaでは、これらの情報の収集及び処理ではKinesisを利用しています。
このような用途には、Kinesisはとても良い選択肢です。
Kinesisは、大きなスケールのデータ処理を前提として設計されており、ボリュームの大きなデータの処理でも高いスループットを出す能力を備えています。
kinesisのユースケース
- ログデータやイベントデータの収集
- リアルタイム解析
- モバイルデータキャプチャ
- "Internet of Things"のデータフィード
Kinesisのベネフィット（利点）
リアルタイム
もし、あなたがデータ取り込み及び処理のスループットの最大化が優先事項であると考えているなら、Kinesisを使うのが良いでしょう。Kinesisを使えば、データのストリームへの書き込みとそれを読み取れるようになるまでの遅延は、たとえ多くのデータを処理しないといけなかったとしても、多くの場合１秒以下になります。
"Big Data"
もしあなたがテラバイト級のデータを毎日一つのストリームで処理しなくてはならない場合、Kinesisがそれを行ってくれます。Kinesisがあれば、データが発生時にデータプロデューサーを使ってそのデータをストリームに登録できます。
これらのデータは、後のデータ処理のためにとって置くこともできますし、リアルタイムに処理をすることもできます。
Kinesisの欠点
Shardの管理
Kinesisの利用を開始するのは簡単なのですが、その後データのためにShardの管理をしなくてはならないという運用上の負担を生みます。
新たなストリームを作る際、ストリーム内のShard数を指定します。ーそれぞれのshardはデータレコードのグループとして機能します。
読み込みと書き込みはshardに対して提供されるため、最大のスループットはストリーム内のshard数によって決まります。今の時点では、Kinesisはオートスケーリングをサポートしていないので、開発者がshardの利用状況をチェックしてストリーム内のshard数を調整する必要があります。
読み取りスループットの上限
Kinesisには一秒間に１つのshardから５つの読み込みまで、また、一秒間に2MBまでという制限があります。そのため、もしも一つのshardから５つのConsumerに同じメッセージを読ませたい場合、すでにKinesisのfan-outリミットに達してしまっています。
このような場合、さらに多くのConsumerからの読み取りを許可するためには、shardの追加が必要になります。
複雑なProduceとConsumerライブラリ
パフォーマンスを最大にするために、KinesisはProducerとConsumerライブラリを利用することを必要とします。
Producer側では、Kinesisストリームを読み書きするためにJavaインターフェースを備えたC++ライブラリのデプロイが必要になります。
Consumer側では、他のプログラム言語とShellの標準入出力インターフェースを使ってやり取りができるJavaアプリケーションのデプロイが必要となります。
これらのどちらのケースでもproducerまたはconsumerをKinesisストリームに新たに追加する場合、メンテナンスや開発の投資が必要になります。
メンテナンス状態
Kinesisは、それぞれのConsumerに対してそれぞれ独立した読み込みを行うことを許可しています。
この仕様は、それぞれのconsumer側で、自分のストリーム内の位置をマークしておき、ストリームのどこまでを読んだかを把握しておく必要が生じます。
複数のConsumerに負荷分散する場合、それぞれのConsumerがどのレコードが読まれたかのセットをしなくてはなりません。
Kinesis Consumer LibraryはDynamoDbテーブルにConsumerメタデータを格納することにより実現しています。
この処理はStream内のConsumerの数をスケールアウトするのに役立ちますが、追加のロジックとリソースを必要とします。
キュー ─ メッセージのパンとバター
メッセージキューを使用すると、マイクロサービスや分散システム、サーバレスアプリケーションを簡単に疎結合化及びスケールできます。
キューを使用すると、メッセージを失ったり別のサービスを常時可動させたりすることなく任意のボリュームのソフトウェアコンポーネント間のメッセージの送信、保管、受信ができます。
それぞれが個別の機能を実行するコンポーネントからアプリケーションを構築すると、拡張性と信頼性を向上します。
そしてこれは現代のベストプラクティスアプリケーションです
信頼できるキューがコンポーネント間にあることで、サービスを接続するための多くの統合パターンを活用することができます。
もし、あなたがメッセージキューシステムを探しているなら、SQSはその役割にフィットするでしょう。SQSはメッセージ管理のためのミドルウェアのオーバーヘッドなしに信頼性、拡張性の高いメッセージキューを提供します。サービス指向またはマイクロサービスアーキテクチャ内でサービスを確実に接続するために必要な配管を提供します。
SQSのユースケース
- アプリケーション統合
- マイクロサービスの分割
- 複数のワーカーノードへのタスクの配置
- 多くのバックグラウンド処理からのユーザリクエストの切り離し
- 先の処理のためのバッチメッセージ
SQSの利点
簡単に使える
SQSを使うのはとても簡単で、キューを簡単に作ってそこにメッセージを送ることができます。また、Kinesisとは対象的に、SQSキューからの読み出し、書き出しには特別なライブラリを必要としません。
また、consumer間のコーディネートを行ったりスケールアウトを管理する必要もありません。
SQSは信頼できる暗号化をサポートしており、またスケールが可能です。
読み込みのスループット
SQSは大きなボリュームのメッセージを捌くために、ユーザの介入なしに容易に拡張できます。
キューから読み込みを行うタスクの数をスケーリングすることで、動的にリードスループットを増大することを可能にします。
これはAWSリソースの前持ったプロビジョニングやスケールアウトを必要としません
SQSは負荷の急激な増加を透過的に処理する要求をバッファリングします。
SQSの欠点
一つのコンシューマー
SQSでは、コンシューマがキューからのメッセージを一旦処理するとそのメッセージは削除され、他のコンシューマは参照できなくなります。
これはつまり、SQSは複数のコンシューマをもち、同じメッセージを同じキューから読み込むようなアプリケーションをサポートしていないということになります。
このような機能を実現するためには、メッセージを複数のキューに複製するためにSNSやその他の一斉配信の仕組みなどを使って複数のキューにメッセージを書く必要があります。
メッセージの再送信能力
メッセージは処理されるた後で削除されるため、SQSはすでに配信されたメッセージを再度配信するような機能はサポートしていません。
このような再送信機能を行う必要がある場合、メッセージ配信時に外の代替ストアなどに書き込みを行い、必要なコンシューマに配信を行う必要があります。
サマリー
アプリケーションを構築するために、クラウドプロバイダーから豊富なツール提供されていますが、クラウドを活用するためのソフトウェアのデザインの半分の仕事はツールを研究し、それらをどのように展開できるかを理解することです。この記事ではSQSとKinesisを比較しましたが、一見似たような技術でもユースケースが大きく異なります。
もしあなたの問題を解決するためにKinesisの採用を検討しているのなら、あなたの取り扱うデータがとても大きなサイズの継続的なデータストリームなのかどうかを考えてみてください。もしそうなら、Kinesisが正しい選択肢です。もしそうでないならSQSの採用を検討してみてください。
出典：SQS or Kinesis? Comparing Apples to Oranges
https://sookocheff.com/post/aws/comparing-kinesis-and-sqs/