翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
KCL は、ワーカーからのリースや CPU 使用率メトリクスなどのメタデータを管理します。KCL は、DynamoDB テーブルを使用してこれらのメタデータを追跡します。Amazon Kinesis Data Streams アプリケーションごとに、KCL は 3 つの DynamoDB テーブルを作成してメタデータを管理します。リーステーブル、ワーカーメトリクステーブル、コーディネーター状態テーブルです。
注記
KCL 3.x では、ワーカーメトリクスとコーディネーター状態テーブルの 2 つの新しいメタデータテーブルが導入されました。
重要
DynamoDB でメタデータテーブルを作成および管理するには、KCL アプリケーションに適切なアクセス許可を追加する必要があります。詳細については、「KCL コンシューマーアプリケーションに必要な IAM アクセス許可」を参照してください。
KCL コンシューマーアプリケーションは、これらの 3 つの DynamoDB メタデータテーブルを自動的に削除しません。不要なコストを避けるため、コンシューマーアプリケーションを廃止する際は、KCL コンシューマーアプリケーションによって作成されたこれらの DynamoDB メタデータテーブルを削除してください。
リーステーブル
リーステーブルは、KCL コンシューマーアプリケーションのスケジューラによってリースおよび処理されるシャードを追跡するために使用される一意の Amazon DynamoDB テーブルです。各 KCL コンシューマーアプリケーションは、独自のリーステーブルを作成します。KCL はデフォルトでリーステーブルの名前にコンシューマーアプリケーションの名前を使用します。設定を使用してカスタムテーブル名を設定できます。KCL は、効率的なリース検出のために leaseOwner のパーティションキーを使用して、リーステーブルにグローバルセカンダリインデックスも作成します。グローバルセカンダリインデックスは、基本リーステーブルの leaseKey 属性をミラーリングします。アプリケーションの起動時に KCL コンシューマーアプリケーションのリーステーブルが存在しない場合、ワーカーの 1 人がアプリケーションのリーステーブルを作成します。
コンシューマーアプリケーションの実行中に、Amazon DynamoDB コンソールを使用してリーステーブルを表示できます。
重要
-
リーステーブル名が重複しないように、各 KCL コンシューマーアプリケーション名は一意である必要があります。
-
アカウントには、Kinesis Data Streams 自体に関連するコストに加えて、DynamoDB テーブルに関連するコストが発生します。
リーステーブルの各行は、コンシューマーアプリケーションのスケジューラによって処理されているシャードを表します。キーフィールドには以下が含まれます。
-
leaseKey: シングルストリーム処理の場合、これはシャード ID です。KCL によるマルチストリーム処理の場合、 として構造化されます
account-id:StreamName:streamCreationTimestamp:ShardId。 leaseKey はリーステーブルのパーティションキーです。マルチストリーム処理の詳細については、「」を参照してくださいKCL によるマルチストリーム処理 。 -
checkpoint: シャードの最新チェックポイントのシーケンス番号。
-
checkpointSubSequenceNumber: Kinesis Producer Library の集約機能を使用する場合、これは Kinesis レコード内の個々のユーザレコードを追跡するチェックポイントの拡張です。
-
leaseCounter: ワーカーが現在リースをアクティブに処理しているかどうかをチェックするために使用されます。リース所有権が別のワーカーに移管されると leaseCounter は増加します。
-
leaseOwner: このリースを保持している現在のワーカー。
-
ownerSwitchesSinceCheckpoint: このリースが最後のチェックポイント以降にワーカーを変更した回数。
-
parentShardId: このシャードの親の ID。子シャードで処理を開始する前に、親シャードが完全に処理され、正しいレコード処理順序が維持されていることを確認します。
-
childShardId: このシャードの分割またはマージによって生成された子シャード IDs のリスト。シャードリネージを追跡し、リシャーディングオペレーション中に処理順序を管理するために使用されます。
-
startingHashKey: このシャードのハッシュキー範囲の下限。
-
endingHashKey: このシャードのハッシュキー範囲の上限。
KCL でマルチストリーム処理を使用する場合、リーステーブルに次の 2 つの追加フィールドが表示されます。詳細については、「KCL によるマルチストリーム処理 」を参照してください。
-
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 メタデータテーブルを作成します。このモードは、容量計画を必要とせずにトラフィックに対応するために、読み取りおよび書き込み容量を自動的にスケーリングします。これらのメタデータテーブルをより効率的に操作できるように、キャパシティモードをオンデマンドモードとして維持することを強くお勧めします。
リーステーブルをプロビジョンドキャパシティモードに切り替える場合は、次のベストプラクティスに従ってください。
-
使用パターンを分析します。
-
Amazon CloudWatch メトリクスを使用して、アプリケーションの読み取り/書き込みパターンと使用状況 (RCU、WCU) をモニタリングします。
-
ピークスループットと平均スループットの要件を理解します。
-
-
必要な容量を計算します。
-
分析に基づいて、読み込みキャパシティーユニット (RCUs) と書き込みキャパシティーユニット (WCUs見積もります。
-
シャードの数、チェックポイントの頻度、ワーカー数などの要因を考慮してください。
-
-
自動スケーリングを実装します。
-
DynamoDB 自動スケーリングを使用して、プロビジョニングされた容量を自動的に調整し、適切な最小容量制限と最大容量制限を設定します。
-
DynamoDB Auto Scaling は、KCL メタデータテーブルが容量制限に達してスロットリングされるのを防ぐのに役立ちます。
-
-
定期的なモニタリングと最適化：
-
の CloudWatch メトリクスを継続的にモニタリングします
ThrottledRequests。 -
ワークロードが時間の経過とともに変化するにつれて容量を調整します。
-
KCL コンシューマーアプリケーションのメタデータ DynamoDB テーブルProvisionedThroughputExceededExceptionで が発生した場合は、DynamoDB テーブルのプロビジョニングされたスループット容量を増やす必要があります。コンシューマーアプリケーションを初めて作成するときに、特定のレベルの読み込みキャパシティーユニット (RCU) と書き込みキャパシティーユニット (WCU) を設定した場合、使用量が増えるにつれて十分ではない可能性があります。例えば、KCL コンシューマーアプリケーションが頻繁にチェックポイントを実行したり、シャードが多いストリームで動作したりする場合、より多くのキャパシティユニットが必要になることがあります。DynamoDB のプロビジョニングされたスループットの詳細については、「Amazon DynamoDB デベロッパーガイド」の「DynamoDB スループットキャパシティとテーブルの更新」を参照してください。 DynamoDB
KCL がワーカーにリースを割り当て、負荷のバランスを取る方法
KCL は、ワーカーを実行しているコンピューティングホストから CPU 使用率メトリクスを継続的に収集してモニタリングし、ワークロードの均等な分散を確保します。これらの CPU 使用率メトリクスは、DynamoDB のワーカーメトリクステーブルに保存されます。KCL は、一部のワーカーが他のワーカーよりも高い CPU 使用率を示していることを検出した場合、ワーカー間のリースを再割り当てして、高使用率ワーカーの負荷を軽減します。目標は、コンシューマーアプリケーションフリート間でワークロードをより均等に分散し、単一のワーカーが過負荷にならないようにすることです。KCL が CPU 使用率をコンシューマーアプリケーションフリート全体に分散させるため、適切なワーカー数を選択するか、自動スケーリングを使用してコンピューティングキャパシティを効率的に管理することで、コンシューマーアプリケーションフリートの容量を適切なサイズに調整してコストを削減できます。
重要
KCL は、特定の前提条件が満たされている場合にのみ、ワーカーから CPU 使用率メトリクスを収集できます。詳細については、「前提条件」を参照してください。KCL がワーカーから CPU 使用率メトリクスを収集できない場合、KCL はワーカーあたりのスループットを使用してリースを割り当て、フリート内のワーカー間で負荷を分散します。KCL は、各ワーカーが特定の時間に受け取るスループットをモニタリングし、リースを再割り当てして、各ワーカーが割り当てられたリースから同様の合計スループットレベルを取得することを確認します。
