目次
どちらも広義なキュー(queue)。でもキューに期待するものが違う。
こんにちは。技術チームの岩谷です。最近、とあるかたから「Kinesisというキーワードを聞くけど、SQSに似ていませんか？違いは何なのでしょう？」という質問をいただきました。
SQSとKinesis、この両者は共にAWSのクラウドサービスで「広義のキューサービス」という意味では共通点があります。すなわち、
- データを投入する
- データを取り出す、またその際に順序性を制御する仕組みが備わっている
- 取出したデータは、即座もしくは短寿命で消去される
- データの「投入→取出」の動作がセットで利用される。
という利用方法は共通しています。これは「データの待ち行列」である「キュー」の概念と一致しています。しかしこの両者の具体的な機能や利用シーンは大きく異なります。今回はその違いを説明させてください。
わかりやすい違い：データを受ける能力
SQSには秒間数百を超えるようなデータを受ける能力はありません。対してKinesisはそれをはるかに超えるデータを受ける能力が備わっています。
この点が両者の機能的な違いを説明する上でもっともわかりやすい表現です。例えば「ビッグデータの待ち行列処理はKinesisを使う」というサービス選択になります。しかしこの説明だと「じゃあKinesisだけあればいいじゃないか？」と思いがちですがそうではありません。両者には利用シーンに応じた住み分けが存在します。
SQSにはコマンド(命令)を入れる
SQSはその名(Simple Queue Service)の通りシンプルなキューサービスを提供します。利用者がSQSに対して行う基本的な操作はデータ投入・取出・削除の3つだけです。キューに対してのチューニングもいらないので、SQSを利用するユーザは非常に簡単にキューサービスを利用する事が出来ます。この為、SQSは「プログラムAからプログラムBという別々のプログラムにコマンド(命令)を伝えるためのキュー」として利用されることが一般的です。
Kinesisにはデータそのものを入れる
対してKinesisは大量のデータを受け入れ可能なキューとして生まれました。巨大なデータをリアルタイムで格納・処理する為にEC2で仮想コンピュータを構築した場合、かなりの台数を用意しなければなりません。またクラウドストレージであるS3を利用した場合、リアルタイムでデータを処理するキューの仕組みを自前で構築するためには相当なコストがかかります。ユーザはKinesisに対してこうしたビッグデータを格納することで、これらの問題を解決する事が出来ます。
しかしながらKinesisの操作はSQSと比べた場合より多くの制御が必要になります。代表的な制御項目としては、
- キューの処理能力を決定する「シャード」の設定
- 投入したデータの一意性を識別する「シーケンス番号」の制御
が挙げられます。とくにbの「シーケンス番号」はユーザ側での番号管理が必要になる為、アプリケーションの設計も含めてSQSと比べた難易度が高くなる要因となっています。
ユーザは、SQSに「キューが簡単に操作できること」を期待している。対してKinesisには「キューが巨大なデータでも受け入れてくれること」と期待している。
上記の説明を「ユーザが求めるサービス」として整理してみると、SQSにはデータの「投入→取出」というキュー本来の機能をシンプルに提供してくれるサービスが求められており、対してKinesisには「巨大なデータであっても受け入れてくれる器」と「キューの機能」を備えた「ビックデータ処理基盤」としてのサービスが求められていることがわかります。両者が「広義のキューサービス」という意味での共通点を持ちながらもユーザの求めるサービスに応じて独立したサービスを提供することによりユーザに最適なサービスを提供していると言えるのではないでしょうか？
今回の記事が一見似ていると感じるSQSとKinesisのサービスの違いを理解することに役立てたのであれば幸いです。
追伸：
Kinesisに関してはこの「ビックデータ処理基盤」としての性格から「ストリームサービス＝(データの流れを制御するサービス)」と呼ばれます。
