翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# KCL における DynamoDB メタデータテーブルと負荷分散
KCL は、リースやワーカーの CPU 使用率メトリクスといったメタデータを管理します。KCL はこれらのメタデータを DynamoDB テーブルを使用して追跡します。Amazon Kinesis Data Streams アプリケーションごとに、KCL はメタデータを管理するために、リーステーブル、ワーカーメトリクステーブル、コーディネーター状態テーブルという 3 つの DynamoDB テーブルを作成します。
**注記**
KCL 3.x では、新たにワーカーメトリクステーブルとコーディネーター状態テーブルの 2 つのメタデータテーブルが追加されました。****
**重要**
KCL アプリケーションが DynamoDB 内でメタデータテーブルを作成し管理できるようにするためには、適切な権限を付与する必要があります。詳細については、「[KCL コンシューマーアプリケーションに必要な IAM アクセス許可](kcl-iam-permissions.md)」を参照してください。
KCL コンシューマーアプリケーションは、これら 3 つの DynamoDB メタデータテーブルを自動的には削除しません。不要なコストを回避するため、コンシューマーアプリケーションを廃止するときには、KCL コンシューマーアプリケーションによって作成されたこれらの DynamoDB メタデータテーブルを必ず削除してください。
## リーステーブル
リーステーブルは、KCL コンシューマーアプリケーションのスケジューラによってリースされ、処理されているシャードを追跡するために使用される、専用の Amazon DynamoDB テーブルです。各 KCL コンシューマーアプリケーションは、独自のリーステーブルを作成します。KCL はデフォルトで、コンシューマーアプリケーションの名前をリーステーブル名として使用します。設定を使用してカスタムテーブル名を設定できます。また、KCL は効率的なリース検出のため、リーステーブルに leaseOwner をパーティションキーとする[グローバルセカンダリインデックス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html)を作成します。グローバルセカンダリインデックスは、ベースとなるリーステーブルの leaseKey 属性をミラーします。アプリケーションの起動時にKCL コンシューマーアプリケーションのリーステーブルが存在しない場合は、いずれかのワーカーがご使用のアプリケーションのリーステーブルを作成します。
コンシューマーアプリケーションの実行中に、[Amazon DynamoDB コンソール](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ConsoleDynamoDB.html)を使用してリーステーブルを表示できます。
**重要**
各 KCL コンシューマーアプリケーション名は、リーステーブル名の重複を防ぐために一意でなければなりません。
アカウントには、Kinesis Data Streams 自体に関連するコストに加えて、DynamoDB テーブルに関連するコストが発生します。
リーステーブルの各行は、コンシューマーアプリケーションのスケジューラによって処理中のシャードを表します。主要なフィールドは以下のとおりです。
+ **leaseKey:** 単一ストリーム処理の場合、これはシャード ID です。KCL を使用したマルチストリーム処理の場合は、`account-id:StreamName:streamCreationTimestamp:ShardId` の形式で構成されます。leaseKey はリーステーブルのパーティションキーです。マルチストリーム処理の詳細については、[KCL を使用したマルチストリーム処理](kcl-multi-stream.md) を参照してください。
+ **checkpoint:** シャードの最新チェックポイントのシーケンス番号。
+ **checkpointSubSequenceNumber:** Kinesis Producer Library の集約機能を使用する場合、これは Kinesis レコード内の個々のユーザレコードを追跡する**チェックポイント**の拡張です。
+ **leaseCounter:** ワーカーが現在そのリースを積極的に処理しているかどうかを確認するために使用されます。リースの所有権が別のワーカーに移った場合、leaseCounter は増加します。
+ **leaseOwner:** このリースを現在保持しているワーカー。
+ **ownerSwitchesSinceCheckpoint:** 最後のチェックポイント以降、このリースの担当ワーカーが何回変更されたかを示します。
+ **parentShardId:** このシャードの親シャードの ID。親シャードが完全に処理されるまで子シャードの処理が開始されないようにすることで、レコード処理の正しい順序を維持します。
+ **childShardId:** このシャードの分割または結合によって生成された子シャード ID の一覧。リシャーディング処理におけるシャードの系統を追跡し、処理順序を管理するために使用されます。
+ **startingHashKey:** このシャードのハッシュキー範囲の下限。
+ **endingHashKey:** このシャードのハッシュキー範囲の上限。
マルチストリーム処理を KCL で使用している場合、リーステーブルには次の 2 つの追加フィールドが表示されます。詳細については、「[KCL を使用したマルチストリーム処理](kcl-multi-stream.md)」を参照してください。
+ **shardID:** シャードの ID。
+ **streamName:** 以下の形式のデータストリームの識別子: `account-id:StreamName:streamCreationTimestamp`。
## ワーカーメトリクステーブル
ワーカーメトリクステーブルは、各 KCL アプリケーションに対して固有の Amazon DynamoDB テーブルであり、各ワーカーからの CPU 使用率メトリクスを記録するために使用されます。これらのメトリクスは、KCL が効率的なリース割り当てを行い、ワーカー間でリソース利用を均等化するために利用されます。KCL は、このワーカーメトリクステーブルの名前としてデフォルトで、 `KCLApplicationName-WorkerMetricStats` を使用します。
## コーディネーター状態テーブル
コーディネーター状態テーブルは、各 KCL アプリケーションに対して固有の Amazon DynamoDB テーブルであり、ワーカーの内部状態情報を保存するために使用されます。たとえば、コーディネーター状態テーブルには、リーダー選出に関するデータや、KCL 2.x から KCL 3.x へのインプレース移行に関連するメタデータが保存されます。KCL は、このコーディネーター状態テーブルの名前としてデフォルトで `KCLApplicationName-CoordinatorState` を使用します。
## KCL が作成するメタデータテーブルの DynamoDB キャパシティモード
Kinesis Client Library (KCL) は、リーステーブル、ワーカーメトリクステーブル、コーディネーター状態テーブルといった DynamoDB のメタデータテーブルを、デフォルトで[オンデマンドキャパシティモード](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/on-demand-capacity-mode.html)で作成します。このモードでは、容量計画を行う必要がなく、トラフィックに応じて読み込み容量および書き込み容量が自動的にスケーリングします。これらのメタデータテーブルをより効率的に運用するため、キャパシティモードはオンデマンドのまま使用することを強くお勧めします。
リーステーブルを[プロビジョンドキャパシティモード](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/provisioned-capacity-mode.html)に切り替える場合は、次のベストプラクティスに従ってください。
+ 使用パターンを分析する:
+ Amazon CloudWatch メトリクスを使用して、アプリケーションの読み取りおよび書き込みパターン (RCU、WCU) と使用状況をモニタリングします。
+ ピーク時および平均的なスループット要件を把握します。
+ 必要なキャパシティを算出する:
+ 分析結果に基づいて、必要な読み込み容量ユニット (RCU) と書き込み容量ユニット (WCU) を見積もります。
+ シャード数、チェックポイント頻度、ワーカー数といった要素も考慮します。
+ 自動スケーリングを実装する:
+ [DynamoDB 自動スケーリング](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/provisioned-capacity-mode.html#ddb-autoscaling)を使用して、プロビジョンドキャパシティを自動的に調整し、適切な最小キャパシティの下限および最大キャパシティの上限を設定します。
+ DynamoDB 自動スケーリングを使用することで、KCL のメタデータテーブルがキャパシティ制限に達してスロットリングされる事態を防ぐことができます。
+ 定期的なモニタリングと最適化:
+ `ThrottledRequests` に関する CloudWatch メトリクスを継続的にモニタリングします。
+ ワークロードの経時変化に応じて、キャパシティを調整します。
KCL コンシューマーアプリケーションのメタデータ用 DynamoDB テーブルで `ProvisionedThroughputExceededException` が発生した場合は、DynamoDB テーブルのプロビジョンドスループットキャパシティを増やす必要があります。コンシューマーアプリケーションを最初に作成した際に特定の読み込み容量ユニット (RCU) および書き込み容量ユニット (WCU) を設定していても、使用量が増えるにつれてそれだけでは不十分になる可能性があります。たとえば、KCL コンシューマーアプリケーションが頻繁にチェックポイントを実行する場合や、多数のシャードを持つストリームを処理する場合は、より多くの容量ユニットが必要になることがあります。DynamoDB のプロビジョンドスループットについての詳細は、Amazon DynamoDB デベロッパーガイドの [DynamoDB のスループットキャパシティ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/capacity-mode.html)と[テーブルの更新](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.Basics.html#WorkingWithTables.Basics.UpdateTable)を参照してください。
## KCL がワーカーにリースを割り当て、負荷を分散する方法
KCL は、ワーカーを実行しているコンピューティングホストの CPU 使用率メトリクスを継続的に収集してモニタリングし、ワークロードが均等に分散されるようにします。これらの CPU 使用率メトリクスは、DynamoDB のワーカーメトリクステーブルに保存されます。KCL は、一部のワーカーの CPU 使用率が他と比べて高くなっていることを検出すると、負荷の高いワーカーの負荷を下げるために、ワーカー間でリースを再割り当てします。目的は、コンシューマーアプリケーションフリート全体でワークロードをより均等に分散し、特定のワーカーに過度な負荷が集中するのを防ぐことです。KCL がコンシューマーアプリケーションフリート全体で CPU 使用率を分散するため、適切なワーカー数を選択することでコンシューマーアプリケーションフリートのキャパシティを適正化できます。また、自動スケーリングを使用してコンピューティングキャパシティを効率的に管理し、コストを削減することも可能です。
**重要**
KCL がワーカーから CPU 使用率メトリクスを収集できるのは、特定の前提条件が満たされている場合のみです。詳細については、「[前提条件](develop-kcl-consumers-java.md#develop-kcl-consumers-java-prerequisites)」を参照してください。KCL がワーカーから CPU 使用率メトリクスを収集できない場合、ワーカーごとのスループットに基づいてリースを割り当て、フリート内のワーカー間で負荷を分散する方式にフォールバックします。KCL は、各ワーカーがある時点で受け取っているスループットをモニタリングし、割り当てられたリースから得られる総スループット量が均等になるようにリースを再割り当てします。