KinesisとSQSの比較検討のため、Amazon Kinesis Data Streams のチュートリアルをやってみた
モバイルアプリサービス部の五十嵐です。
KinesisとSQSの比較検討のため、Kinesisをより知るために公式のチュートリアルをさわってみました。
前提知識として
前提知識として、ストリームとシャード、プロデューサーとコンシューマーなどの用語の意味を抑えておくといいと思います。AWS Black Belt Online Seminarのスライドがわかりやすかったので紹介しておきます。
AWS Black Belt Online Seminar 2017 Amazon Kinesis
チュートリアル
チュートリアル: Amazon Kinesis Data Streams を使用したウェブトラフィックの可視化 - Amazon Kinesis Data Streams
概要
このサンプルアプリケーションは、さまざまな URL からのシミュレート上の閲覧者の数を Kinesis data stream に投入するデータプロデューサーを作成します。ストリームはそれらのデータレコードを受け取った順に保持します。データコンシューマーは、ストリームからこれらのレコードを取得し、特定の URL からの閲覧者の数を計算します。最後に、単純なウェブアプリケーションは計算結果をリアルタイムでポーリングし、計算結果を可視化します。
チュートリアル: Amazon Kinesis Data Streams を使用したウェブトラフィックの可視化 - Amazon Kinesis Data Streams より抜粋
実践
必要なリソースは全てCloudFormationに定義されているので、手順に従いCloudFormationのStackを作成します。
Stackの作成により、EC2インスタンスにアプリケーション（Amazon Kinesis Data Visualization Sample Application）がデプロイされます。
このアプリケーションが、ストリームにデータをPUTするプロデューサーと、ストリームからデータをGETするコンシューマーと、コンシューマーが集計して保存したデータを可視化するアプリケーションの３つの役割を含んでいます。
その他にDynamoDBのテーブルが2つ作成されます。1つはシャードイテレーターと呼ばれるもので、コンシューマーがストリームのシャードをどこまで読み込んだかが記録されるテーブルです。もう1つはコンシューマーがストリームから取得するデータを格納するためのテーブルで、可視化アプリケーションが参照します。
リソースの全貌
Kinesisに対する気づき
- SQSはキューサービスなのでレコードを取り出して削除するまでがクライアントの役割なのに対し、Kinesisはストリームサービスなのでクライアントはどこまで処理したかを記憶しておくだけでレコードを削除するという考え方はない。（どちらもレコードにTTLがあるのは同じだけど）
- プロデューサーからの大量のインプットをさばくためには、コンシューマーも並列数を増やす必要があり分散コンピューティングなどの技術が求められることがある。それをサポートするためにKinesis Client Library（KCL）というライブラリが提供されている。
- それでもコンシューマーを作るのはそれなりに難しそうだから、できるだけLambdaを使って楽をしたい。
- レコードを加工する必要がないのであれば、Kinesis Firehoseを使って直接データストアに格納するのが良い。Kinesis Firehose のありがたみが理解できた。
- Kinesis Analyticsを使うと、ストリームのデータをそのままSQLのインターフェイスで集計できる。すごい。
Kinesis Data StreamsとSQSの比較
以下は、2018/04/01時点で筆者が調べた情報です。必ず一次情報を確認してください。
| 項目 | Kinesis Data Streams | SQS |
|---|---|---|
| 耐久性 | 3つのAZでデータが同期的にレプリケートされる | 単一リージョンの複数AZに保存 |
| スループット | シャード単位 書込み:1秒あたり1,000レコード 読み取り:1秒あたり5 件のトランザクション |
標準キュー:制限なし FIFOキュー: 1 秒あたり300件のオペレーション オペレーションあたり最大10件なので3,000件 |
| レコードの保持期間 | 24時間~7日間 | 1 分間～14 日間 |
| レコードのサイズ | 1MB | 1KB~256KB |
| レコードの容量制限 | シャードの数による | 無制限 転送中メッセージの数については - 標準キューで 120,000 - FIFO キューで 20,000 |
| 順序保証 | ミリ秒精度のタイムスタンプで並べ替えが可能 | 標準キュー: ベストエフォート FIFOキュー: 厳密な順序 |
| レコード配信の重複 | 不明 | 標準キュー: 少なくとも1回 FIFOキュー: 確実に1回 |
| レコード配信のレイテンシ | 1秒未満 | 不明 （筆者の体感的には即時） |
| リクエストのレイテンシ | 不明 | 数十ミリ秒～数百ミリ秒 |
| 料金体系 | シャード時間＋PUT ペイロードユニット 拡張データ保持期限は追加料金 |
100 万件のリクエストあたりの料金 |
また、Amazon Kinesis Data Streams と Amazon SQS の違いについては、 Amazon Kinesis Data Streams – よくある質問 でも詳しく言及されています。
まとめ
Amazon Kinesisはこれまで業務で使う機会がなかったのでなんとなくのイメージしかありませんでしたが、チュートリアルを通じてさわってみることで基本的な知識を体得できました。AWSにはすばらしいチュートリアルやドキュメントが用意されているので、活用してみてはいかがでしょうか。
