での DynamoDB メタデータテーブルとロードバランシング KCL - Amazon Kinesis Data Streams
リーステーブルワーカーメトリクステーブルコーディネーター状態テーブルによって作成されたメタデータテーブルの DynamoDB キャパシティモード KCLがワーカーにリースをKCL割り当て、負荷のバランスをとる方法

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

での DynamoDB メタデータテーブルとロードバランシング KCL

KCL は、ワーカーからのリースやCPU使用率メトリクスなどのメタデータを管理します。 は、DynamoDB テーブルを使用してこれらのメタデータKCLを追跡します。Amazon Kinesis Data Streams アプリケーションごとに、 KCLは 3 つの DynamoDB テーブルを作成してメタデータを管理します。リーステーブル、ワーカーメトリクステーブル、コーディネーター状態テーブルです。

注記

KCL 3.x では、ワーカーメトリクスとコーディネーター状態テーブルの 2 つの新しいメタデータテーブルが導入されました。

重要

DynamoDB でメタデータテーブルを作成および管理するには、KCLアプリケーションに適切なアクセス許可を追加する必要があります。詳細については、「IAM KCLコンシューマーアプリケーションに必要な アクセス許可」を参照してください。

KCL コンシューマーアプリケーションは、これら 3 つの DynamoDB メタデータテーブルを自動的に削除しません。不要なコストを避けるため、KCLコンシューマーアプリケーションを廃止する際は、コンシューマーアプリケーションによって作成されたこれらの DynamoDB メタデータテーブルを削除してください。

リーステーブル

リーステーブルは、KCLコンシューマーアプリケーションのスケジューラによってリースおよび処理されるシャードを追跡するために使用される一意の Amazon DynamoDB テーブルです。各KCLコンシューマーアプリケーションは、独自のリーステーブルを作成します。 は、デフォルトでリーステーブルの名前にコンシューマーアプリケーションの名前KCLを使用します。設定を使用してカスタムテーブル名を設定できます。 は、効率的なリース検出 leaseOwner のために、パーティションキー を使用してリーステーブル上にグローバルセカンダリインデックスKCLも作成します。グローバルセカンダリインデックスは、基本リーステーブルの leaseKey 属性をミラーリングします。アプリケーションの起動時にKCLコンシューマーアプリケーションのリーステーブルが存在しない場合、ワーカーの 1 人がアプリケーションのリーステーブルを作成します。

コンシューマーアプリケーションの実行中に、Amazon DynamoDB コンソールを使用してリーステーブルを表示できます。

重要

  • リーステーブル名が重複しないように、各KCLコンシューマーアプリケーション名は一意である必要があります。

  • アカウントには、Kinesis Data Streams 自体に関連するコストに加えて、DynamoDB テーブルに関連するコストが発生します。

リーステーブルの各行は、コンシューマーアプリケーションのスケジューラによって処理されているシャードを表します。主なフィールドは次のとおりです。

  • leaseKey： シングルストリーム処理の場合、これはシャード ID です。を使用したマルチストリーム処理の場合KCL、 として構造化されますaccount-id:StreamName:streamCreationTimestamp:ShardId。 leaseKey はリーステーブルのパーティションキーです。マルチストリーム処理の詳細については、「」を参照してくださいを使用したマルチストリーム処理 KCL 。

  • checkpoint: シャードの最新チェックポイントのシーケンス番号。

  • checkpointSubSequence数値： Kinesis プロデューサーライブラリの集約機能を使用する場合、これは Kinesis レコード内の個々のユーザーレコードを追跡するチェックポイントの拡張機能です。

  • leaseCounter： ワーカーが現在リースをアクティブに処理しているかどうかを確認するために使用されます。リース所有権が別のワーカーに移管されると leaseCounter 、 が増加します。

  • leaseOwner： このリースを保持している現在のワーカー。

  • ownerSwitchesSinceチェックポイント： このリースが最後のチェックポイント以降にワーカーを変更した回数。

  • parentShardId： このシャードの親の ID。子シャードで処理を開始する前に、親シャードが完全に処理され、正しいレコード処理順序が維持されていることを確認します。

  • childShardId： このシャードの分割またはマージIDsに起因する子シャードのリスト。リシャーディングオペレーション中にシャード系統を追跡し、処理順序を管理するために使用されます。

  • startingHashKey： このシャードのハッシュキー範囲の下限。

  • endingHashKey： このシャードのハッシュキー範囲の上限。

でマルチストリーム処理を使用する場合KCL、リーステーブルに次の 2 つの追加フィールドが表示されます。詳細については、「を使用したマルチストリーム処理 KCL 」を参照してください。

  • shardID: シャードの ID。

  • streamName： 形式 のデータストリームの識別子account-id:StreamName:streamCreationTimestamp。

ワーカーメトリクステーブル

ワーカーメトリクステーブルは、各KCLアプリケーションの一意の Amazon DynamoDB テーブルであり、各ワーカーのCPU使用率メトリクスを記録するために使用されます。これらのメトリクスは、効率的なリース割り当てを実行するKCLために によって使用され、ワーカー間でリソース使用率のバランスが取れます。 はデフォルトでワーカーメトリクステーブルの名前KCLApplicationName-WorkerMetricStatsに KCLを使用します。

コーディネーター状態テーブル

コーディネーター状態テーブルは、KCLアプリケーションごとに一意の Amazon DynamoDB テーブルであり、ワーカーの内部状態情報を保存するために使用されます。例えば、コーディネーター状態テーブルには、リーダーの選択に関するデータや、2.x から 3KCL.x KCL へのインプレース移行に関連するメタデータが保存されます。 は、デフォルトでコーディネーター状態テーブルの名前KCLApplicationName-CoordinatorStateに KCLを使用します。

によって作成されたメタデータテーブルの DynamoDB キャパシティモード KCL

デフォルトでは、Kinesis Client Library (KCL) は、オンデマンドキャパシティモードを使用して、リーステーブル、ワーカーメトリクステーブル、コーディネーター状態テーブルなどの DynamoDB メタデータテーブルを作成します。このモードは、キャパシティプランニングを必要とせずに、トラフィックに対応するために読み取りおよび書き込みキャパシティを自動的にスケーリングします。これらのメタデータテーブルをより効率的に操作できるように、キャパシティモードをオンデマンドモードとして維持することを強くお勧めします。

リーステーブルをプロビジョンドキャパシティモードに切り替える場合は、次のベストプラクティスに従ってください。

  • 使用パターンを分析する：

    • Amazon CloudWatch メトリクスを使用して、アプリケーションの読み取りおよび書き込みパターンと使用状況 (RCU、WCU) をモニタリングします。

    • ピークスループットと平均スループットの要件を理解します。

  • 必要な容量を計算します。

    • 分析に基づいて、読み込みキャパシティーユニット (RCUs) と書き込みキャパシティーユニット (WCUs) を推定します。

    • シャードの数、チェックポイントの頻度、ワーカー数などの要因を考慮してください。

  • 自動スケーリングを実装します。

    • DynamoDB Auto Scaling を使用して、プロビジョニングされた容量を自動的に調整し、適切な最小容量制限と最大容量制限を設定します。

    • DynamoDB Auto Scaling は、KCLメタデータテーブルが容量制限に達し、スロットリングされるのを防ぐのに役立ちます。

  • 定期的なモニタリングと最適化：

    • の CloudWatch メトリクスを継続的にモニタリングしますThrottledRequests。

    • ワークロードが時間の経過とともに変化するにつれて容量を調整します。

KCL コンシューマーアプリケーションのメタデータ DynamoDB テーブルProvisionedThroughputExceededExceptionで が発生した場合は、DynamoDB テーブルのプロビジョニングされたスループットキャパシティを増やす必要があります。コンシューマーアプリケーションを初めて作成するときに、特定のレベルの読み込みキャパシティーユニット (RCU) と書き込みキャパシティーユニット (WCU) を設定した場合、使用量が増えるにつれて十分ではない可能性があります。例えば、KCLコンシューマーアプリケーションが頻繁にチェックポイントを実行したり、シャードが多いストリームで動作したりする場合、より多くのキャパシティーユニットが必要になることがあります。DynamoDB のプロビジョニングされたスループットの詳細については、「Amazon DynamoDB デベロッパーガイド」の「DynamoDB スループットキャパシティとテーブルの更新」を参照してください。 DynamoDB

がワーカーにリースをKCL割り当て、負荷のバランスをとる方法

KCL は、ワーカーを実行しているコンピューティングホストからCPU使用率メトリクスを継続的に収集してモニタリングし、ワークロードの均等な分散を確保します。これらのCPU使用率メトリクスは、DynamoDB のワーカーメトリクステーブルに保存されます。は、一部のワーカーが他のワーカーよりも高いCPU使用率を示していることをKCL検出した場合、ワーカー間でリースを再割り当てして、使用率の高いワーカーの負荷を軽減します。目標は、コンシューマーアプリケーションフリート間でワークロードをより均等に分散し、単一のワーカーが過負荷にならないようにすることです。がコンシューマーアプリケーションフリート全体にCPU使用率をKCL分散するため、適切なワーカー数を選択するか、自動スケーリングを使用してコンピューティングキャパシティを効率的に管理することで、コンシューマーアプリケーションフリートの容量を適切なサイズにすることができます。

重要

KCL は、特定の前提条件が満たされている場合にのみ、ワーカーからCPU使用率メトリクスを収集できます。詳細については、「前提条件」を参照してください。がワーカーからCPU使用率メトリクスを収集KCLできない場合、 KCLはワーカーごとのスループットを使用してリースを割り当て、フリート内のワーカー間で負荷を分散します。 KCL は、各ワーカーが特定の時間に受け取るスループットをモニタリングし、リースを再割り当てして、各ワーカーが割り当てられたリースとほぼ同じ合計スループットレベルになるようにします。