Kinesis Data Streams のシャード管理に関する考慮事項
Kinesis データストリームは、シャードでスループットをカウントします。Amazon Kinesis Data Streams では、データストリームにオンデマンドモードとプロビジョンドモードのどちらかを選択できます。
DynamoDB の書き込みワークロードが大きく変動しやすく予測不可能な場合は、Kinesis データストリームにオンデマンドモードを使用することをお勧めします。オンデマンドモードでは、Kinesis Data Streams が必要なスループットを提供するためにシャードを自動的に管理するため、キャパシティプランニングは必要ありません。
予測可能なワークロードの場合は、Kinesis データストリームにプロビジョニングモードを使用できます。プロビジョンドモードでは、DynamoDB からの変更データ取得レコードを格納するためのデータストリームのシャード数を指定する必要があります。Kinesis データストリームが DynamoDB テーブルをサポートするために必要なシャードの数を決定するには、次の入力値が必要です。
-
DynamoDB テーブルのレコードの平均サイズ (バイト単位、
average_record_size_in_bytes
)。 -
DynamoDB テーブルで実行される 1 秒あたりの書き込み操作の最大数。これには、アプリケーションで実行される作成、削除、更新操作のほか、Time to Live で生成された削除操作 (
write_throughput
) などの自動生成された操作も含まれます。 -
テーブルに対して実行する作成操作や削除操作と比較した、更新操作と上書き操作の割合 (
percentage_of_updates
)。更新操作と上書き操作では、変更された項目の古いイメージと新しいイメージの両方がストリームにレプリケートされることに留意してください。これにより、DynamoDB 項目のサイズが 2 倍になります。
Kinesis データストリームに必要なシャードの数 (number_of_shards
) を計算するには、入力値を以下の式にあてはめます。
number_of_shards = ceiling( max( ((write_throughput * (4+percentage_of_updates) * average_record_size_in_bytes) / 1024 / 1024), (write_throughput/1000)), 1)
例えば、書き込み操作の最大スループットが 1,040 回/秒で (write_throughput
)、平均レコードサイズが 800 バイト (average_record_size_in_bytes)
であるとします。 この書き込み操作の 25% が更新操作 (percentage_of_updates
) である場合、DynamoDB ストリーミングスループットに対応するために 2 つのシャード (number_of_shards
) が必要になります。
ceiling( max( ((1040 * (4+25/100) * 800)/ 1024 / 1024), (1040/1000)), 1).
式を使用して Kinesis データストリームのプロビジョニングモードで必要なシャード数を計算する前に、次の点を考慮してください。
-
この式では、DynamoDB 変更データレコードを格納するのに必要なシャードの数を見積もることができます。これは、追加の Kinesis データストリームのコンシューマーをサポートするために必要なシャードの数など、Kinesis データストリームで必要なシャードの総数を表すものではありません。
-
ピークスループットを処理するようにデータストリームを設定しないと、プロビジョンドモードで読み取りおよび書き込みのスループットの例外が発生する可能性があります。この場合、データトラフィックに対応するようにデータストリームを手動でスケーリングする必要があります。
-
この式では、変更ログデータレコードを Kinesis Data Stream にストリーミングする前に DynamoDB によって生成される追加の肥大化を考慮に入れています。
Kinesis データストリームのキャパシティモードの詳細については、「データストリームのキャパシティモードの選択」を参照してください。さまざまなキャパシティモード間の料金の違いについて詳しくは、「Amazon Kinesis Data Streams の料金
Kinesis Data Streams を使用した変更データキャプチャのモニタリング
DynamoDB には、Kinesis への変更データキャプチャのレプリケーションをモニタリングするのに役立つ複数の Amazon CloudWatch メトリクスが用意されています。CloudWatch メトリクスの詳細な一覧については、「DynamoDB のメトリクスとディメンション」を参照してください。
ストリームに十分な容量があるかどうかを判断する場合は、ストリームの有効化時と実稼働時の両方で次の項目をモニタリングすることをお勧めします。
-
ThrottledPutRecordCount
: Kinesis データストリームのキャパシティが不足しているために、Kinesis データストリームによってスロットリングされたレコードの数。例外的な使用量のピーク時にスロットリングが発生する可能性がありますが、ThrottledPutRecordCount
は可能な限り低く保つ必要があります。DynamoDB は、スロットリングされたレコードを Kinesis データストリームに再送信しますが、これによりレプリケーションのレイテンシーが高くなる可能性があります。過剰で定期的なスロットリングが発生した場合は、テーブルで観測された書き込みスループットに比例して Kinesis ストリーミングシャードの数を増やす必要があります。Kinesis Data Streams のサイズ決定の詳細については、「Kinesis Data Streams の初期サイズの決定」を参照してください。
-
AgeOfOldestUnreplicatedRecord
: Kinesis Data Streams にまだレプリケートされていない最も古い項目レベルの変更からの経過時間が DynamoDB テーブルに表示されました。通常のオペレーションでは、AgeOfOldestUnreplicatedRecord
はミリ秒単位で順序を指定しなければなりません。この数字は、カスタマー管理設定上の選択が原因で失敗したレプリケーションの試行回数に基づいて増加します。AgeOfOldestUnreplicatedRecord
メトリクスが 168 時間を超えると、DynamoDB テーブルから Kinesis データストリームへの項目レベルの変更のレプリケーションは自動的に無効になります。カスタマー管理設定でレプリケーション試行の失敗の原因になる例として、Kinesis データストリームキャパシティーのプロビジョニングが不足していたために過剰なスロットリングにつながった場合や、Kinesis データストリームのアクセスポリシーを手動で更新したために DynamoDB がデータストリームにデータを追加できなくなった場合が挙げられます。このメトリクスを可能な限り低く保つために、Kinesis データストリームキャパシティーを十分にプロビジョニングし、DynamoDB のアクセス許可が変更されていないことを確認する必要があります。
-
FailedToReplicateRecordCount
: DynamoDB が Kinesis データストリームにレプリケートできなかったレコードの数。34 KB を超える特定の項目はサイズが拡張されて、Kinesis Data Streams の項目サイズ制限 1MB を超えるデータレコードが変更される場合があります。このサイズの拡張は、34 KB を超えるこれらの項目に多数のブール値や空の属性値が含まれる場合に発生します。ブール値と空の属性値は、DynamoDB に 1 バイトで格納されますが、Kinesis Data Streams レプリケーションで標準 JSON を使用してシリアル化すると、最大 5 バイトまで拡張されます。DynamoDB は、このような変更レコードを Kinesis データストリームにレプリケートできません。DynamoDB は、これらの変更データレコードをスキップし、後続のレコードを自動的にレプリケートします。
前述のメトリクスのいずれかが特定のしきい値を超えた場合に通知するために、Amazon Simple Notification Service (Amazon SNS) メッセージを送信する Amazon CloudWatch アラームを作成できます。