Amazon Kinesis Data Streams に新しい機能が加わりました。

数週間前に、当社は2つの重要なパフォーマンス改善機能をAmazon Kinesis Data Streams (KDS):に追加しました。拡張ファンアウトと HTTP/2 データ取得 API です。拡張ファンアウトは、開発者が各ストリームコンシューマーにそれぞれの読み取り処理量を提供することにより、ストリームコンシューマー (リアルタイムでのストリームからのアプリケーションの読み取りデータ) の数を増加させることができます。HTTP/2データ取得APIは、一般的なシナリオでデータをプロデューサーからコンシューマーに70ミリ秒以内に配信できるようになります (65%の向上)。これらの新しい機能により、開発者は Amazon Kinesis Data Streams 上でより高速で、より反応性、並列性に優れ、レイテンシに敏感なアプリケーションを構築できるようになります。

Kinesis は実際に、次のストリーミングサービスのファミリを指します。 Kinesis Video Streams、Kinesis Data Firehose、Kinesis Data Analytics、および本日のブログ投稿のトピックである、 Kinesis Data Streams (KDS)。Kinesis Data Streams では、完全に管理され、大規模にスケーラブルなサービスを利用して、開発者は容易に、かつ継続的にストリーミングデータをリアルタイムで収集、処理、および分析できるようになります。KDS は何十万にも上るソースから 1 秒当たりの数ギガバイトのデータを取り込むことができます。ウェブサイトのクリックストリームやソーシャルメディアのフィードから財務取引や位置情報データに至るまであらゆるものを対象としています。

Kinesis Data Streams は、シャード (shard) の概念を使用してスケールされます。1 個のシャードは、1MB / 秒または 1000 レコード / 秒のインジェスト容量と 2MB / 秒の出力容量を提供します。顧客が数千から数万個のシャードを持ち、毎秒数十ギガバイトの入出力をサポートすることは珍しいことではありません。ファンアウト機能を強化する前に、2MB / 秒 / シャードがストリームからのデータを消費するすべてのアプリケーションの間で共有されます。拡張ファンアウトでは、開発者はストリームコンシューマーを拡張ファンなうとを使用し、シャード当たり 2MB / 秒のパイプの読み取り処理量を受け取るために登録することができ、この処理量が自動的にストリームのシャードの数をスケールします。拡張ファンアウトの開始の前に、顧客は頻繁にデータを複数のストリームに送出して、下流のアプリケーションに対する希望の読み取り処理量をサポートします。これは、私たちにとって差別化されていない重い負担のように感じられますが、私たちが決めたことなので、顧客は心配する必要はありません。顧客は拡張ファンアウトを使用してストリームから取得されたデータの量とシャードごとに登録されたコンシューマーに数に基づいて、拡張ファンアウトに対して支払います。料金表のページで追加情報をご覧ください。

新しい API の説明に進む前に、HTTP/2 の簡単な説明と新しい SubscribeToShard API で使用する方法について見てみましょう。

HTTP/2

HTTP/2 はクライアントとサーバーの間のデータのフレーミングと移動のための新しい方法を導入する HTTP ネットワーク プログラムの重要な改訂です。これは、バイナリー プロトコルです。レイテンシーの減少と処理量の増大に焦点を当てた多くの新しい機能を有効にします。最初の利得は、HPACK を使用して、ヘッダーを圧縮することです。もう一つの便利な機能は、複数の並列非ブロック要求に対して単一の TCP 接続を使用できるようにする接続マルチプレクシングです。さらに、HTTP の従来の要求-応答セマンティクスの代わりに、通信パイプは双方向になります。HTTP/2 を使用するサーバーは、クライアントがリソースを要求するのを待たなくても、複数の応答をプッシュできます。Kinesis の SubscribeToShard API は新しいレコードを受け取り、フロー制御と呼ばれる別の HTTP/2 を利用するために、このサーバー プッシュ機能を利用します。Kinesis はデータをコンシューマーにプッシュして、未確認になっているバイト数をトラッキングします。クライアントは、WINDOW_UPDATE フレームをサーバーに送信することにより、バイトを確認します。クライアントがデータのレートを扱うことができない場合、Kinesis は新しい WINDOW_UPDATE フレームが受け取られるまで、または 5 分のサブスクリプションが失効するまで、データのフローを停止します。

これで、SubscribeToShard と HTTP/2 については理解しましたので、拡張ファンアウトを利用するために、これを使用する方法について見てみましょう。

拡張ファンアウトの使用

拡張ファンアウトを利用するための最も簡単な方法は、更新された Kinesis Client Library 2.0 (KCL) を使用することです。KCL は自動的にストリームのコンシューマーとして自身を登録します。 その後、KCL はシャードを列挙して、新しい SubscribeToShard API を使用してそれらにサブスクライブします。また、基礎の接続が終端するまで、継続的に SubscribeToShard をコールします。AWS アカウントで作成した Amazon DynamoDBテーブルを使用して、分散アプリケーションのチェックポイントと状態管理を処理します。この例については、ドキュメント をご覧ください。

拡張ファンアウトを使用するための一般的プロセス:

1. RegisterStreamConsumer をコールして、StreamARN および ConsumerName を指定します (通常はアプリケーション名)。この API コールにより返される ConsumerARN を保存します。コンシューマーが登録されるとすぐに、拡張ファンアウトが有効になり、consumer-shard-hours の課金が始まります。
2. ストリームシャードを列挙し、ConsumerARN returned by RegisterStreamConsumer により返された ConsumerARN でそれぞれの SubscribeToShard をコールします。これにより、HTTP/2 接続が確立され、KDS は SubscribeToShardEvents をリスニング クライアントにプッシュします。これらの接続は、5 分ごとに KDS により終端されるため、クライアントはイベントの受信を継続する場合は、SubscribeToShard を再びコールする必要があります。拡張ファンアウトを使用してクライアントにプッシュされたバイトは、拡張ファンアウトデータ取得レートの下で課金されます。
3. 最終的に、コンシューマーを使用しなくなったときに DeregisterStreamConsumer をコールするのを忘れないでください。関連コストがかかるからです。

ドキュメント でこのプロセスを順を追ってみていくことで、サンプルコードをいくつか見ていきましょう。.

Amazon CloudWatch メトリックスを確認して、コンソールのコンシューマーアプリケーションの登録解除も含めて、管理します。

今すぐ利用可能

拡張ファンアウトと新しい HTTPS/2 SubscribeToShard API は、新しいストリームと既存のストリームの両方のリージョンで利用可能になりました。ドキュメント のブログ投稿で取り上げているものよりも、もっと多くの情報があります。.ストリームごとにすべてのシャードから読み取られるコンシューマーアプリケーションに 5 個の制限がありますが、これはサポートチケットで増加できます。これらの新機能の利用して、複数のストリームコンシューマを管理する複雑さを軽減し、リアルタイムアプリケーションの速度と並列性を向上させることができます。

いつでも、お気軽に以下または Twitter にコメントを残してください。

– Randall