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

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

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

KCL は、ワーカーからのリースやCPU使用率メトリクスなどのメタデータを管理します。KCL は、DynamoDB テーブルを使用してこれらのメタデータを追跡します。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 は、デフォルトでリーステーブルの名前にコンシューマーアプリケーションの名前を使用します。設定を使用してカスタムテーブル名を設定できます。KCL は、効率的なリース検出 leaseOwner のために、 パーティションキー を使用して、リーステーブルにグローバルセカンダリインデックスも作成します。グローバルセカンダリインデックスは、ベースリーステーブルの 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ために使用されます。KCL は、デフォルトでワーカーメトリクステーブルの名前KCLApplicationName-WorkerMetricStatsに を使用します。

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

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

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

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

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

  • 使用状況パターンの分析：

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

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

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

    • 分析に基づいて、読み取り容量単位 (RCUs) と書き込み容量単位 (WCUs) を推定します。

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

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

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

    • DynamoDB 自動スケーリングは、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 は、各ワーカーが特定の時間に受け取るスループットをモニタリングし、リースを再割り当てして、各ワーカーが割り当てられたリースから同様の合計スループットレベルを取得するようにします。