Amazon Kinesis Data Streams のよくある質問

シャードには、ストリーム内の一連のデータレコードがあります。これは、Kinesis データストリームの基本スループットユニットとして機能します。シャードは、書き込みの場合は 1 MB/秒および 1,000 レコード/秒、読み取りの場合は 2 MB/秒をサポートします。シャード制限はパフォーマンスが確実に予測可能であるようにします。これにより、信頼性の高いデータストリーミングワークフローの設計と運用が容易になります。プロデューサーはデータレコードをシャードに格納し、コンシューマーはシャードからデータレコードを取得します。コンシューマーは、データの並列処理と、データが保存されている正確な順序でデータを消費するためにシャードを使用します。書き込みと読み取りがシャードの制限を超えると、プロデューサーアプリケーションとコンシューマーアプリケーションはスロットルを受け取ります。これは再試行によって処理できます。

レコードとは、Amazon Kinesis データストリームに保存されるデータの単位です。レコードは、シーケンス番号、パーティションキー、データ BLOB で構成されています。データ BLOB はデータプロデューサーがデータストリームに追加する、処理対象のデータです。データ BLOB（Base64 エンコーディング前のデータペイロード）の最大サイズは、1 メガバイト (MB) です。

パーティションキーは、レコードを分離してデータストリームの異なるシャードにルーティングするために使用されます。パーティションキーは、データを Kinesis データストリームに追加するときにデータプロデューサーによって指定されます。例えば、2 つのシャード (シャード 1 とシャード 2) で構成されるデータストリームがあるものとします。2 つのパーティションキー（キー A とキー B）を使用し、キー A のレコードはすべてシャード 1 に追加され、キー B のレコードはすべてシャード 2 に追加されるように、データ生成元を設定できます。

シーケンス番号とは、各レコードの一意の識別子です。データプロデューサーが PutRecord または PutRecords オペレーションを呼び出してデータを Amazon Kinesis データストリームに追加すると、Amazon Kinesis によってシーケンス番号が割り当てられます。同じパーティションキーのシーケンス番号は一般的に、時間の経過と共に大きくなります。PutRecord または PutRecords リクエスト間の期間が長くなるほど、シーケンス番号は大きくなります。

Kinesis Data Streams の容量モードは、容量の管理方法とデータストリームの使用量の課金方法を決定します。プロビジョンドモードとオンデマンドモードのどちらかを選択できます。プロビジョンドモードでは、データストリームのシャードの数を指定します。データストリームの合計容量は、そのシャードの容量の合計です。必要に応じて、データストリーム内のシャードの数を増減でき、シャードの数について 1 時間ごとの料金を支払います。オンデマンドモードでは、AWS がシャードを管理して必要なスループットを提供します。使用した実際のスループットの料金のみをお支払いいただきます。また、Kinesis Data Streams は、ワークロードのスループットのニーズが増減するときに自動的に対応します。すべての Kinesis Data Streams の書き込みおよび読み取り API は、拡張保持や拡張ファンアウトなどのオプション機能とともに、両方の容量モードでサポートされています。

オンデマンドモードは、予測不能で変動性の高いトラフィックパターンを持つワークロードに最適です。AWS がお客様にために容量を管理することを希望する場合、またはスループットごとの支払いを希望する場合は、このモードを使用する必要があります。プロビジョンドモードは、容量要件を簡単に予測できる予測可能なトラフィックに最適です。データがシャード全体でどのように分散されるかをきめ細かく制御する場合は、プロビジョンドモードの使用を検討する必要があります。プロビジョンドモードは、消費アプリケーションの読み取りスループットを向上させて処理全体を高速化できるよう、追加のシャードをプロビジョニングする場合にも適しています。

はい。オンデマンドモードとプロビジョンドモードは 1 日に 2 回切り替えることができます。プロビジョンドモードからオンデマンドモードに、またはその逆に切り替えても、データストリームのシャードカウントは同じままです。プロビジョンドモードからオンデマンド容量モードに切り替えると、データストリームは、移行前のシャードカウントを保持します。ただし、その時点から、Kinesis Data Streams はデータトラフィックをモニタリングし、トラフィックの増減に応じて、このオンデマンドデータストリームのシャード数をスケールアップまたはスケールダウンします。

Kinesis データストリームには、PutRecord オペレーションと PutRecords オペレーション、KPL、または Amazon Kinesis エージェントを使用してデータを追加できます。

PutRecord オペレーションは 1 度の API 呼び出しで単一のデータレコードを許可し、PutRecords オペレーションは 1 度の API 呼び出しで複数のデータレコードを許可します。詳細については、「PutRecord」 と 「PutRecords」 をご覧ください。

Amazon Kinesis データストリームにデータを格納するのに役立つ、使いやすく、高度な設定が可能なライブラリです。KPL は、最低限のクライアントリソースを使用して、高いプロデューサースループットを素早く実現できる、シンプルで非同期の、信頼のおけるインターフェイスを提供します。

Amazon Kinesis Agent は、データの収集および Amazon Kinesis データストリームへのデータの送信を容易にする、構築済みの Java アプリケーションです。このエージェントは、ウェブサーバー、ログサーバー、データベースサーバーなど、Linux ベースのサーバー環境にインストールできます。エージェントによって特定のファイルがモニタリングされ、継続的にデータがデータストリームに送られます。詳細については、「Writing with Agents」を参照してください。

データ BLOB、パーティションキー、およびデータストリーム名は、PutRecord または PutRecords の呼び出しに必要なパラメータです。データ BLOB のサイズ (Base64 エンコーディングの前に)、およびパーティションキーのサイズが、Amazon Kinesis データストリームのデータスループットに対してカウントされます。これは、データストリーム内のシャードの数によって決まります。

コンシューマーは、Kinesis データストリームからのすべてのデータを処理するアプリケーションです。共有ファンアウトと拡張ファンアウトのいずれかのコンシューマータイプを選択して、Kinesis データストリームからデータを読み取ることができます。共有ファンアウトコンシューマーはすべて、シャードの 2 MB/秒の読み取りスループットと 1 秒あたり 5 トランザクションの制限を共有し、GetRecords API の使用を要求します。拡張ファンアウトコンシューマーは、独自の 2 MB/秒の読み取りスループットの割り当てを取得します。これにより、複数のコンシューマーは、他のコンシューマーと読み取りスループットについて競合することなく、同じストリームからデータを並行して読み取ることができます。拡張ファンアウトコンシューマーで SubscribeToShard API を使用する必要があります。データストリームに複数のコンシューマーを追加する場合は、拡張ファンアウトコンシューマーを使用することをお勧めします。

AWS Lambda、Amazon Managed Service for Apache Flink、AWS Glue などのマネージドサービスを使用して、Kinesis Data Streams に保存されているデータを処理できます。これらのマネージドサービスは、基盤となるインフラストラクチャのプロビジョニングと管理を処理するため、お客様はビジネスロジックの作成に集中できます。また、Kinesis Data Firehose との事前構築された統合を使用して、Kinesis Data Streams に保存されているデータを Amazon S3、Amazon OpenSearch Service、Amazon Redshift、およびカスタム HTTP エンドポイントに配信することもできます。Amazon Kinesis Client Library、構築済みライブラリ、または Amazon Kinesis Data Streams API を使用してカスタムアプリケーションを構築することもできます。

Java、Python、Ruby、Node.js、および .NET 向けの Amazon Kinesis Client Library (KCL) は構築済みのライブラリです。これは、Amazon Kinesis データストリームからデータを読み取って処理する Amazon Kinesis アプリケーションを簡単に構築するのに役立ちます。

KCL は、データストリームボリュームの変化への適応、ストリーミングデータのロードバランス、分散サービスの調整、データ処理の耐障害性などの複雑な問題に対応します。KCL を利用することで、アプリケーションの構築中にビジネスロジックに集中できます。 KCL の詳細については、こちらの Kinesis Data Streams のドキュメントをご覧ください。

SubscribeToShard API は、クライアントからのリクエストサイクルを持たない永続的な接続を介してシャードからコンシューマーへデータをプッシュする高性能ストリーミング API です。SubscribeToShard API は新しいデータがシャードに到達すると、HTTP/2 プロトコルを使用して通常 70 ミリ秒以内に登録コンシューマーへデータを提供します。GetRecords API に比べて最大約 65% 速く提供します。複数の登録されたコンシューマーが同じシャードから読み取ると、コンシューマーはすばやい提供を受けることができます。

拡張ファンアウトとは、コンシューマーとシャード間に論理的な 2 MB/秒スループットパイプを提供する Kinesis Data Streams コンシューマーのオプション機能です。これにより、高度なパフォーマンスを維持しつつ、並行してデータストリームから読み取るコンシューマーの数をスケールできます。

複数のコンシューマーが並行してストリームからデータを取得する場合、もしくはそうした状況が想定される場合、または SubscribeToShard API を使用してプロデューサーとコンシューマー間で 200 ミリ秒未満のデータ提供速度を提供する必要があるコンシューマーが 1 つ以上ある場合は、拡張ファンアウトを使用する必要があります。

コンシューマーは、SubscribeToShard API でデータを取得することで拡張ファンアウトを利用します。登録されたコンシューマーの名前は SubscribeToShard API 内で使用され、登録コンシューマーに提供される拡張ファンアウトのメリットを享受できます。

はい。拡張ファンアウトを使用する複数のコンシューマーと、拡張ファンアウトを使用しないコンシューマーを同時に持つことができます。拡張ファンアウトの使用は、従来の GetRecords 利用のシャード制限に影響しません。

はい。SubscribeToShard を使用するには、コンシューマーを登録する必要があります。これにより、拡張ファンアウトが有効化されます。デフォルトで、コンシューマーは SubscribeToShard を通じてデータを取得するとき、自動的に拡張ファンアウトを利用します。

オンデマンドモードで作成された新しいデータストリームには、書き込みについて 4 MB/秒および 4,000 レコード/秒のクオータがあります。デフォルトでは、書き込みについては、これらのストリームは自動的に最大 200 MB/秒および 200,000 レコード/秒にスケールアップします。

オンデマンドモードのデータストリームは、過去 30 日間に観察された以前のピーク書き込みスループットの最大 2 倍に対応します。データストリームの書き込みスループットが新しいピークに達すると、Kinesis Data Streams はストリームの容量を自動的にスケールします。例えば、データストリームの書き込みスループットが 10 MB/秒から 40 MB/秒の間で変動する場合、Kinesis Data Streams を使用すると、簡単にバーストして 2 倍のピークスループット (80 MB/秒) にすることができます。その後、同じデータストリームが 50 MB/秒の新しいピークスループットを維持する場合、Data Streams は、100 MB/秒の書き込みスループットを取り込むのに十分な容量が確実にあるようにします。ただし、トラフィックが 15 分以内に前のピークの 2 倍を超えて増加した場合は、「ProvisionedThroughputExceeded」例外が表示されます。これらのスロットリングされたリクエストを再試行する必要があります。

オンデマンドモードの読み取り容量の総量は書き込みスループットに比例して増加し、消費アプリケーションが受信データをリアルタイムで処理するのに十分な読み取りスループットを常に確保できるようにします。GetRecords API を使用してデータを読み取るために、少なくとも 2 倍の書き込みスループットを取得します。アプリケーションがダウンタイムから回復する必要があるときに追いつくのに十分なスペースがあるように、GetRecord API で 1 つのコンシューマーを使用することをお勧めします。複数の消費アプリケーションを追加するには、拡張ファンアウトを使用する必要があります。これは、SubscribeToShard API を使用して、それぞれが専用のスループットを持つ最大 20 のコンシューマーをデータストリームに追加することをサポートします。

プロビジョンドモードの Kinesis データストリームのスループットは、データストリーム内のシャードの数を増やすことによって制限なしにスケールするよう設計されています。

SplitShard API を使用して既存のシャードを分割することにより、プロビジョンドモードで Kinesis データストリームの容量をスケールアップできます。MergeShard API を使用して 2 つのシャードをマージすることにより、容量をスケールダウンできます。または、UpdateShardCount API を使用して、ストリーム容量を特定のシャードカウントにスケールアップ (またはスケールダウン) することもできます。

Kinesis データストリームのスループットは、データストリーム内のシャードの数によって決まります。プロビジョンドモードでデータストリームで必要なシャードの数の初期値を推定する手順を次に説明します。リシャーディングを通じてデータストリーム内のシャードの数を動的に調整できます。

データストリームに書き込まれるレコードの平均サイズをキロバイト (KB) 単位で推定し、最近接の 1 KB に切り上げます。(average_data_size_in_KB)

1 秒あたりにデータストリームに書き込まれるレコード数を推定します。(number_of_records_per_second)

データストリームからのデータを同時に独立して使用する Amazon Kinesis アプリケーションの数を決定します。(number_of_consumers)

入力書き込み帯域幅の KB 数を計算します (incoming_write_bandwidth_in_KB) 。これは、average_data_size_in_KB に number_of_records_per_second を乗じて算出された値です。

出力読み取り帯域幅の KB 数を計算します（outgoing_read_bandwidth_in_KB）。これは、incoming_write_bandwidth_in_KB と number_of_consumers を掛け合わせた値です。

その後、number_of_shards = max (incoming_write_bandwidth_in_KB/1000, outgoing_read_bandwidth_in_KB/2000) という式を使用して、データストリームに必要なシャードの初期数 (number_of_shards) を計算できます。

Kinesis データストリームのスループットは、制限なしにスケールするよう設計されています。デフォルトのシャードクォータは、米国東部 (バージニア北部)、米国西部 (オレゴン)、および欧州 (アイルランド) といった AWS リージョンについては、ストリームあたり 500 シャードです。他のすべてのリージョンでは、デフォルトのシャードクォータはストリームごとに 200 シャードです。AWS Service Quotas コンソールを使用して、シャードクォータの増加をリクエストすることができます。

プロビジョンドモードでは、Kinesis データストリームの容量制限は、データストリーム内のシャードの数によって決定されます。データスループットまたは PUT レコードの数のいずれかによって、この制限を超える可能性があります。容量制限を超えている間、PUT データの呼び出しは ProvisionedThroughputExceeded 例外で拒否されます。このような状況がデータストリームの入力データ速度の一時的な上昇によるものである場合は、データプロデューサーが再試行することによって最終的にリクエストは完了します。一方、データストリームの入力データ速度が高い状態が継続している場合は、データストリーム内のシャードの数を増やして、PUT データの呼び出しが常に成功するのに十分な容量を提供する必要があります。いずれの場合も、Amazon CloudWatch メトリクスを使用することで、データストリームの入力データ速度の変化および ProvisionedThroughputExceeded の例外の発生を把握できます。

プロビジョンドモードでは、Kinesis データストリームの容量制限は、データストリーム内のシャードの数によって決定されます。データスループットまたは READ データの呼び出しの数のいずれかによって、この制限を超える可能性があります。容量制限を超えている間、READ データの呼び出しは ProvisionedThroughputExceeded 例外で拒否されます。このような状況がデータストリームの出力データ速度の一時的な上昇によるものである場合は、Amazon Kinesis アプリケーションで再試行されることによって最終的にリクエストは完了します。一方、データストリームの出力データ速度が高い状態が継続している場合は、データストリーム内のシャードの数を増やして、READ データの呼び出しが常に成功するのに十分な容量を提供する必要があります。いずれの場合も、Amazon CloudWatch メトリクスを使用することで、データストリームの出力データ速度の変化および ProvisionedThroughputExceeded 例外の発生を把握できます。

デフォルトの保持期間である 24 時間は、処理の断続的な遅延がリアルタイムデータに追いつく必要があるシナリオに対応しています。7 日間の保持により、最長で 7 日間のデータを再処理して潜在的なダウンストリームデータの損失を解決できます。7 日を超え 365 日までの長期データ保持により、アルゴリズムのバックテスト、データストアのバックフィル、監査などのユースケースのために古いデータを再処理することができます。

はい。同じ getShardIterator、GetRecords、SubscribeToShard の API を使用して、7 日を超える期間にわたって保持されているデータを読み取ることができます。コンシューマーは、イテレーターをストリーム内の目的の場所に移動し、シャードマップ (開いているものと閉じているものの両方を含む) を取得して、レコードを読み取ることができます。

はい。ListShards、GetRecords、SubscribeToShard の 各 API には API の機能強化があります。ListShards API で利用可能な TimeStamp パラメータで新しいフィルタリングオプションを使用して、シャードマップを効率的に取得し、古いデータの読み取りのパフォーマンスを向上させることができます。TimeStamp フィルターを使用すると、アプリケーションは、データを再処理する時点からシャードを検出して列挙し、トリムホライズンから開始する必要がなくなります。GetRecords と SubscribeToShards には新しいフィールドである ChildShard があります。ChildShard を使用すると、アプリケーションが閉じたシャードからのデータの読み取りを終了したときに、シャードマップを再度トラバースする代わりに、子シャードをすばやく検出できます。シャードを速やかに見つけられるので、データの保持期間に関係なく、あらゆるサイズのストリームでアプリケーションのコンピューティングリソースを効率的に利用できます。

データをより長く保持し、ストリームの容量を定期的に拡張する場合、API の機能強化の使用を検討する必要があります。ストリームのスケーリングオペレーションによって、既存のシャードを閉じ、新しい子シャードを開きます。すべてのオープンシャードとクローズシャードのデータは、保持期間が終了するまで保持されます。したがって、シャードの総数は、保持期間が長くなり、複数のスケーリングオペレーションが行われるにつれて直線的に増加します。シャードマップにおけるこの増加により、データ取得用のシャードを効率的に検出するには、TimeStamp フィルターを備えた ListShards、GetRecords の ChildShards フィールド、SubscribeToShard API を使用する必要があります。これらの機能については、KCL を最新バージョン (標準コンシューマーは 1.x、拡張ファンアウトコンシューマーは 2.x) にアップグレードする必要があります。

はい。Kinesis データストリームをご利用のお客様は、AWS Glue のサーバーレス機能である AWS Glue スキーマレジストリを、Kinesis Producer Library (KPL) と Kinesis Client Libraries (KCL) を介して、または AWS Java SDK の AWS Glue スキーマレジストリ API を介して使用できます。スキーマレジストリは追加料金なしでご利用いただけます。 

詳細をご確認の上で使用を開始していただくには、スキーマレジストリのユーザードキュメントをご覧ください。

データストリームのスループットを変更するには 2 つの方法があります。UpdateShardCount API または AWS マネジメントコンソールを使用して、データストリーム内のシャードの数をスケールするか、データストリーム内のシャードの数を調整 (リシャーディング) することで Amazon Kinesis データストリームのスループットを変更できます。

通常のスケールリクエストの場合は、数分で完了します。大きなスケールリクエストの方が小さいものより長く時間がかかります。

はい。UpdateShardCount もしくはリシャードを使用してデータストリームのスループットを変更している間、または Kinesis Data Streams がオンデマンドモードで自動的に当該変更を実行する際であっても、Kinesis データストリームへのデータの追加と Kinesis データストリームからのデータの読み取りを続行できます。

Amazon Kinesis Data Streams マネジメントコンソールには、Kinesis データストリームのデータの入力および出力のスループットなど、動作とパフォーマンスの重要なメトリクスが表示されます。また、Kinesis データストリームは Amazon CloudWatch とも統合できるため、データストリームおよびデータストリーム内のシャードの CloudWatch メトリクスの収集、表示、分析を実行できます。Kinesis Data Streams のメトリクスの詳細については、「Amazon CloudWatch による Amazon Kinesis Data Streams のモニタリング」を参照してください。

すべてのストリームレベルのメトリクスは無料であることにご注意ください。すべての有効なシャードレベルのメトリクスは Amazon CloudWatch 料金に基づいて請求されます。

Amazon Kinesis データストリームは、AWS Identity and Access Management (IAM) と統合されています。IAM は、AWS の各種サービスとリソースへのユーザーアクセスを安全に制御するサービスです。例えば、特定のユーザーまたはグループのみが Kinesis データストリームにデータを追加できるようにするポリシーを作成できます。また、リソースベースのポリシーをデータストリームまたは登録コンシューマーにアタッチして、リソースレベルでアクセスを制御することもできます。データストリームのアクセスの管理と制御に関する詳細については、「IAM により Amazon Kinesis Data Streams リソースへのアクセスを制御する」を参照してください。

IAM ロールまたはリソースベースのポリシーを使用して、別のアカウントとアクセスを共有できます。クロスアカウントの AWS Lambda 関数とアクセスを共有するには、リソースベースのポリシーをデータストリームまたはコンシューマーにアタッチして、Lambda 関数の実行ロールへのアクセスを許可します。 詳細については、「Amazon Kinesis で AWS Lambda を使用する」を参照してください。

Kinesis Data Streams は Amazon CloudTrail と統合されています。Amazon CloudTrail は、ユーザーのアカウントに対する AWS API コールを記録してログファイルを提供するサービスです。API コールのログ記録およびサポートされる Amazon Kinesis API オペレーションのリストの詳細については、「Amazon CloudTrail を使用した Amazon Kinesis API コールのログ記録」を参照してください。

Kinesis Data Streams では、リソースとコストの管理が容易になるように Kinesis データストリームにタグを付けることができます。タグは、AWS リソースの整理に役立つ、キーと値のペアとして表されるユーザー定義のラベルです。例えば、コストセンター別にデータストリームをタグ付けすることにより、コストセンターに基づいて Kinesis データストリームのコストを分類および追跡できます。Amazon Kinesis Data Streams のタグ付けの詳細については、「Amazon Kinesis Data Streams のタグ付け」を参照してください。

Amazon Kinesis はデフォルトで安全に保護されています。アカウントとデータストリームの所有者のみが、自分が作成した Kinesis リソースにアクセスできます。Kinesis は、データへのアクセスを制御するためにユーザー認証をサポートしています。IAM ポリシーを使用して、ユーザーおよびユーザーのグループに選択的に権限を付与できます。HTTPS プロトコルを使用して SSL エンドポイント経由で、Kinesis からのデータの格納と取得を安全に行うことができます。セキュリティをより高める必要がある場合は、AWS Key Management Service (AWS KMS) キーでサーバー側の暗号化を使用して、データストリームに保存されているデータを暗号化できます。AWS KMS を使用すると、AWS で生成された KMS キーを暗号化に使用できます。また、必要に応じて、独自の KMS キーを AWS KMS で使用することもできます。最後に、独自の暗号化ライブラリを使用して、データを Kinesis に格納する前にクライアント側のデータを暗号化することができます。

はい。VPC エンドポイントを作成すると、Amazon VPC から Kinesis Data Streams API にプライベートにアクセスできます。VPC エンドポイントを使うと、VPC と Kinesis Data Streams の間のルーティングが AWS ネットワークによって処理されます。インターネットゲートウェイ、NAT ゲートウェイ、VPN 接続は必要ありません。Kinesis Data Streams で使用される VPC エンドポイントの最新世代では、AWS PrivateLink が使用されています。AWS PrivateLink は、VPC でのプライベート IP と Elastic Network Interface (ENI) を使用することにより、AWS のサービス間でのプライベート接続を実現するテクノロジーです。PrivateLink の詳細については、PrivateLink のドキュメントを参照してください。

はい。暗号化については 2 つのオプションがあります。サーバー側の暗号化を使用できます。これは、データストリームからデータの格納と取得を行う際に自動的にデータを暗号化および復号するフルマネージド機能です。クライアント側で暗号化と復号を実行することで、暗号化されたデータをデータストリームに書き込むこともできます。

次のいずれかの理由で、クライアント側の暗号化よりもサーバー側の暗号化を選択する場合があります。

• クライアント側の暗号化を強制するのが難しい。
• クライアント側の暗号化に加えて 2 つ目のセキュリティレイヤーが必要。
• クライアント側のキー管理スキームを実装するのが難しい。

Kinesis Data Streams のサーバー側の暗号化は、ユーザーが指定した AWS KMS キーを使用して自動的にデータを暗号化してから、データストリームストレージレイヤーに書き込み、ストレージから取得した後でデータを復号化します。データストリームの書き込みや読み取りを行うユーザーが、データストリームでの暗号化のために選択されたキーを使用する権限を持っている場合を除き、暗号化によって書き込みが不可能になり、ペイロードとパーティションキーは判読不能になります。その結果、サーバー側の暗号化によって、データを管理する社内のセキュリティおよびコンプライアンス要件を容易に満たすことができます。

サーバー側の暗号化を使用すれば、クライアント側のアプリケーション (プロデューサーとコンシューマー) が暗号化を認識する必要がなく、KMS キーや暗号化のオペレーションを管理する必要がありません。データは Kinesis Data Streams サービス内で保管中も移動中も暗号化されています。サーバー側の暗号化機能で使用される KMS キーはすべて、AWS KMS によって提供されます。AWS KMS を使用すると、AWS マネージドの Kinesis 用の KMS キー (「ワンクリック」暗号化方式)、お客様独自の AWS KMS のカスタマーマネージドキー、または暗号化のためにインポートした KMS キーを簡単に使用できます。

はい。ユーザードキュメントの中に入門ガイドがあります。

その可能性はあります。これは、暗号化に使用するキーと、そのキーへのアクセスを制御する許可によって異なります。

• AWS マネージドの Kinesis 用の KMS キー (キーエイリアス = aws/ Kinesis) を使用する場合、このキーを使用して暗号化を有効または無効にすることで、アプリケーションは影響を受けません。
• 独自の AWS KMS キーや AWS KMS サービスにインポートしたマスターキーなどの異なる KMS キーを使用する場合と、データストリームのプロデューサーとコンシューマーが暗号化に使用する KMS キーを使用する許可を持っていない場合、PUT リクエストと GET リクエストは失敗します。サーバー側の暗号化を使用するには、AWS KMS キーのポリシーを、メッセージの暗号化と復号化を許可するように設定する必要があります。AWS KMS の権限の例と詳細については、「AWS Key Management Service デベロッパーガイド」の「 AWS KMS API のアクセス権限: アクションとリソースのリファレンス」、または Kinesis Data Streams の「サーバー側の暗号化のユーザードキュメント」の「アクセス権限のガイドライン」を参照してください。

はい。ただし、AWS マネージドの Kinesis 用の KMS キーを使用しており、KMS API 使用料金の AWS 無料利用枠を超えていない場合、サーバー側の暗号化の使用は無料です。次に、リソース別のコストについて説明します。

キー:

AWS で管理された Kinesis 用の KMS キー (エイリアス= "aws/kinesis") は無料です。
お客様が管理する KMS キーは、KMS キー料金の対象となります。 詳細はこちらをご覧ください。

KMS API の使用:

API 使用料金は、カスタム KMS キーを含め、すべての KMS キーに適用されます。データキーをローテーションしている場合は、Kinesis Data Streams により約 5 分ごとに KMS が呼び出されます。1 か月を 30 日とした場合、Kinesis データストリームにより開始される KMS API コールの料金の合計は、数ドル未満の金額となります。この料金は、データプロデューサーとデータコンシューマーで使用するユーザー認証情報の数に応じてスケールされます (ユーザー認証情報ごとに AWS KMS に対する一意の API コールが必要なため)。IAM ロールを認証に使用する場合、各 assume-role コールにより一意のユーザー認証情報が生成されます。assume-role コールで返されるユーザー認証情報をキャッシュして、KMS の料金を節約することができます。

Kinesis データストリームのサーバー側の暗号化は、AWS GovCloud リージョンと、中国 (北京) リージョンを除くすべてのパブリックリージョンでご利用いただけます。

これらのオペレーションはすべて、AWS マネジメントコンソールまたは AWS SDK を使用して実行できます。詳細については、「Kinesis Data Streams のサーバー側の暗号化の入門ガイド」を参照してください。

Kinesis Data Streams は、暗号化に AES-GCM 256 アルゴリズムを使用します。

いいえ。データストリームに新しく書き込まれたデータのみが、新しい暗号化アプリケーションによって暗号化されます (または、復号されたままになります)。

サーバー側の暗号化によって、メッセージのペイロードと、データストリームプロデューサーアプリケーションによって指定されたパーティションキーが暗号化されます。

サーバー側の暗号化はストリーム固有の機能です。

はい。AWS マネジメントコンソールまたは AWS SDK を使用すると、特定のデータストリームに適用する新しい KMS キーを選択できます。

いいえ。現在、Amazon Kinesis データストリームは AWS 無料利用枠の対象になっていません。AWS 無料利用枠は、AWS サービスのグループの試用を無料で提供するプログラムです。AWS 無料利用枠の詳細については、「AWS 無料利用枠」をご覧ください。

Kinesis データストリーム SLA では、Kinesis データストリームについて少なくとも 99.9% の月間稼働率が保証されます。

同じリージョン内の複数のアベイラビリティーゾーンでタスクを実行しており、任意の月次請求サイクル中に月間稼働率が 99.9% 未満であった場合、Kinesis データストリーム SLA に基づいて Kinesis データストリームについての SLA クレジットを受け取る要件を満たします。

SLA のすべての利用規約に関する詳細、および請求の提出方法の詳細については「、Amazon Kinesis Data Streams SLA」をご覧ください。

Kinesis Data Streams ではシンプルな従量制料金を使用しています。初期費用や最低料金はなく、使用したリソース分のみをお支払いいただきます。Kinesis データストリームには、オンデマンドとプロビジョンドの 2 つの容量モードがあり、どちらにも固有の請求オプションがあります。

オンデマンド容量モードでは、アプリケーションによる実行が想定される読み取りおよび書き込みスループットを指定する必要はありません。このモードでは、料金は取り込み、および取得したデータの量に基づき、アカウント内の各データストリームの 1 時間あたりの料金とともに請求されます。拡張データ保持 (最初の 24 時間を超えて最初の 7 日以内)、長期データ保持 (7 日を超えて最長 1 年)、および拡張ファンアウトといったオプション機能には追加料金がかかります。Kinesis Data Streams の費用の詳細については、「Amazon Kinesis Data Streams の料金」を参照してください。

プロビジョンド容量モードでは、書き込みおよび読み取りリクエストレートに基づいて、アプリケーションに必要なシャードの数を指定します。シャードは、全体で 1 MB/秒の書き込みと 2 MB/秒の読み取りを提供する容量の単位です。各シャードについて、1 時間あたりの料金に基づいて請求されます。また、Kinesis データストリームに書き込まれたレコードの料金もお支払いいただきます。拡張保持や拡張ファンアウトなどのオプション機能を使用すると、追加料金が発生します。

以下は、Kinesis Data Streams プロビジョンドモードの 2 つのコアディメンションと 3 つのオプションのディメンションです。

• Amazon Kinesis データストリーム内のシャードの数によって決まる、時間あたりのシャード費用。
• データプロデューサーがデータストリームに追加する 25 KB のペイロードユニット数によって決まる、PUT ペイロードユニットの費用。

オプション:

• 拡張データ保持は、データストリームによって発生するシャード時間数に基づいて決まるオプション費用です。拡張データ保持が有効化されている場合、ストリームの各シャードに対する拡張保持レートを支払います。
• 長期データ保持はオプションのコストであり、長期データ保持と長期データ取得という 2 つのコストの側面があります。長期データストレージは、7 日を超えて 365 日までの期間にデータが保存された GB-月数を反映します。長期データ取得は、7 日を超える期間にわたって保存された取得データの GB 数を反映しています。
• 拡張ファンアウトは、2 つのコストディメンション (コンシューマー-シャード時間とデータ取得) を持つオプション費用です。コンシューマー-シャード時間は、拡張ファンアウトを使用するコンシューマーの数とストリーム内のシャード数を乗算して算出します。データ取得は、拡張ファンアウトを使用するコンシューマーに提供される GB 数によって決まります。

Kinesis Data Streams の費用の詳細については、「Amazon Kinesis Data Streams の料金」を参照してください。

コンシューマー-シャード時間は、登録されたストリームコンシューマーの数とストリーム内のシャード数を乗算して算出します。また、拡張ファンアウトの使用のためにコンシューマーが登録された時間の割合についての料金のみをお支払いいただきます。例えば、10 シャードデータストリームに対してコンシューマー-シャード時間あたり 0.015 USD の場合、拡張ファンアウトを使用するこのコンシューマーは 10 シャードから読み取ることができ、1 時間あたり 0.15 USD のコンシューマー-シャード時間の請求が発生します (1 コンシューマー * 10 シャード * コンシューマー-シャード時間あたり 0.015 USD)。拡張ファンアウトを使用する登録コンシューマーが同時に 2 つ存在する場合、コンシューマー-シャード時間の合計請求額は時間あたり 0.30 USD になります (2 コンシューマー * 10 シャード * 0.015 USD)。

Kinesis データストリームと Amazon MSK はどちらも人気のあるデータストリーミングプラットフォームであり、特殊なニーズに合わせてデータを処理する独自のストリーミングワークロードを構築するのに役立ちます。どちらのサービスもスケーラブルで、安全で、可用性が高いです。どちらも、リアルタイムのウェブ分析やログ分析、顧客体験のパーソナライズ、イベント主導型アーキテクチャ、IoT 分析、リアルタイムの不正検出などのストリーミングユースケースを実行するために導入できます。どちらかを選ぶ際には、具体的なユースケースと要件を考慮することが重要です。考慮すべき要素は次のとおりです。

親しみやすさ

•  ストリーミング技術に慣れていない場合は、Kinesis データストリームを使用してください。
• Apache Kafka で実行されている既存のアプリケーションがある場合は、MSK を使用してください。MSK には既存の Kafka 移行プログラム (KMP) と移行ガイドがあり、移行を簡単に行えます。

オープンソースを好む

• オープンソーステクノロジーの使用を希望する場合は、MSK を使用することをお勧めします。MSK と MSK Connect はどちらも、それぞれオープンソースの Apache Kafka と Kafka Connect と完全に互換性があります。

Amazon Kinesis データストリームでは、ビッグデータのストリーミングをリアルタイムで処理できます。レコードを並べ替えることができ、複数の Amazon Kinesis アプリケーションに対して同じ順序でレコードを読み取ったり再生したりできます。Amazon Kinesis Client Library (KCL) は特定のパーティションキーに対するすべてのレコードを同じレコードプロセッサに提供し、同じ Kinesis データストリームから読み取る複数のアプリケーションの構築を容易にします (カウント、集計、フィルタリングの実行など)。Amazon Simple Queue Service (Amazon SQS)は、コンピュータ間でやり取りされるメッセージを格納するための、信頼性のある、拡張性の高い、ホスティングされたキューを提供しています。Amazon SQS を使用すると、分散したアプリケーションコンポーネント間でデータを簡単に移動でき、自動化されたワークフローのようなメッセージレベルでの確認/失敗セマンティクスを備えたメッセージを独立して処理するアプリケーションを構築できます。

Kinesis データストリームは次のような要件を満たす必要があるユースケースにお勧めします。

• 関連性のあるレコードを同じレコードプロセッサにルーティングする場合 (MapReduce のストリーミングなど) 。 たとえば、特定のキーに対するすべてのレコードを同じレコードプロセッサにルーティングすると、カウントや集計が簡単になります。
• レコードを並べ替える場合。 例えば、ログステートメントの順序を維持しながら、アプリケーションホストから処理/アーカイブホストにログデータを転送できます。
• 複数のアプリケーションが同じストリームを同時に使用する機能。 例えば、リアルタイムダッシュボードを更新するアプリケーションと、データを Amazon Redshift にアーカイブするアプリケーションがあるものとします。両方のアプリケーションで、同じストリームからのデータを同時に、独立して使用できます。
• レコードを数時間後に同じ順序で使用する機能。 例えば、請求アプリケーションと、請求アプリケーションから何時間か後に実行する監査アプリケーションがあるものとします。Kinesis Data Streams ではデータが最長で 365 日間保存されるため、請求アプリケーションより最長で 365 日間後に監査アプリケーションを実行できます。

Amazon SQS は次のような要件のユースケースに推奨されます。

• メッセージングセマンティクス (メッセージレベルの確認/失敗など) および可視性タイムアウト。 例えば、作業項目のキューがあり、各項目の正常な完了を個別に追跡するものとします。Amazon SQS は確認/失敗を追跡するので、アプリケーションでは永続的なチェックポイント/カーソルを維持する必要がありません。Amazon SQS は、確認されたメッセージを削除し、失敗したメッセージは設定されている可視性タイムアウトの後で再配信します。
• 個別メッセージの遅延。 例えば、ジョブキューがあり、遅延のある個別のジョブをスケジュールする必要があるものとします。Amazon SQS では、個々のメッセージに最大で 15 分の遅延を設定できます。
• 読み取り時における同時性/スループットの動的な拡張。 例えば、作業キューがあり、バックログが解消されるまでリーダーを追加する必要があるものとします。Kinesis Data Streams では、十分な数のシャードにスケールアップできます (ただし、前もって十分なシャードをプロビジョニングしておく必要があります)。
• Amazon SQS の機能を使用して透過的にスケーリングします。 例えば、負荷の一時的な上昇や事業の自然な成長の結果として、バッファ要求や負荷が変化するような場合です。各バッファ要求は個別に処理できるので、ユーザーがプロビジョニングを指示しなくても、Amazon SQS は透過的に拡張して負荷を処理できます。