View a markdown version of this page

KCL の単一テーブル形式 - Amazon Kinesis Data Streams
単一テーブル形式の仕組み単一テーブル形式を設定する移行状態ロールバックに関する考慮事項ベストプラクティス

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

KCL の単一テーブル形式

KCL 3.5 以降では、単一のテーブル形式を使用して、すべての DynamoDB メタデータを単一のリーステーブルに統合できます。 デフォルトでは、KCL 3.x はアプリケーションごとにリーステーブル、ワーカーメトリクステーブル、コーディネーター状態テーブルの 3 つの DynamoDB テーブルを作成します。単一のテーブル形式では、これら 3 つのテーブルが 1 つに減るため、DynamoDB アカウントレベルのテーブル制限を回避できます。

単一テーブル形式の仕組み

単一テーブル形式では、KCL はワーカーメトリクスとコーディネーター状態エントリをリースエントリとともにリーステーブルに保存します。各項目には、異なるレコードタイプを区別するentityType属性が含まれています。

ワーカーメトリクスとコーディネーター状態項目は、リーステーブルと同じプライマリキー構造を使用しますが、個別のentityType値が含まれます。この属性により、KCL はテーブルスキャン中に各項目の目的を識別できます。

KCL の各コンポーネントは、 entityType 属性に基づいてビジネスロジックに必要なエントリを除外します。たとえば、リース割り当てマネージャー (LAM) はリースとワーカーのメトリクスエントリをフィルタリングしてリース割り当てを実行します。

単一テーブル形式を設定する

単一テーブル形式を有効にする方法は、現在の KCL バージョンによって異なります。

  • KCL 2.x を使用している場合: 更新された移行ガイドに従って KCL 3.5 にアップグレードします。2.x から 3.5 への新しい移行には、デフォルトで単一テーブル形式が使用されます。

  • KCL 3.0～3.4 を使用している場合: 単一テーブル形式に移行するには、2 フェーズのデプロイを実行する必要があります。以下の設定と移行の手順を参照してください。

既存の KCL 3.x のお客様の場合は、 でmigrateAllEntitiesToLeaseTable設定オプションを設定しますCoordinatorConfig。このオプションは、KCL がすべてのメタデータエンティティタイプをリーステーブルに保存するかどうかを制御します。

の設定値 migrateAllEntitiesToLeaseTable
値 デフォルト 効果
false はい

KCL は、ワーカーメトリクスとコーディネーターの状態に対して個別のテーブルを使用します。アプリケーションコードは単一のテーブル形式をサポートしていますが、アクティブ化されません。
true いいえ

KCL は、ワーカーメトリクスとコーディネーター状態データのリーステーブルへの書き込みを開始します。TableMigrationStatus が到達しDEPLOYED、リグレッションなしでベイクした後、フェーズ 2 デプロイでこの値を設定します。

KCL 3.x から単一テーブル形式に移行するには、2 フェーズのデプロイが必要です。

  1. フェーズ 1: を false (デフォルト) migrateAllEntitiesToLeaseTableに設定して、更新された KCL 3.5 コードをデプロイします。これにより、単一のテーブル形式をサポートする新しいコードがインストールされますが、移行はアクティブ化されません。

  2. フェーズ 2: すべてのワーカーが新しいコードを実行しDEPLOYED、 が TableMigrationStatusに達し、リグレッションがないことを確認したら、 を migrateAllEntitiesToLeaseTableに設定して再度デプロイtrueし、移行を開始します。

移行状態

は、マルチテーブル形式から単一テーブル形式への移行TableMigrationStateMachineを管理します。KCL は、コーディネーター状態テーブルの という別のコーディネーター状態エントリTableMigration3.5で現在の移行状態を追跡します。状態、遷移、および説明の完全なリストについては、「KCL シングルテーブルの移行状態」を参照してください。

単一テーブル形式の移行状態
State 説明 移行条件
INIT

初期状態。すべてのワーカーは、ワーカーメトリクス統計で最小サポートコードを出力しています。ワーカーは引き続きワーカーメトリクスをレガシーテーブルに出力し、ワーカーメトリクスとコーディネーターの状態をレガシーテーブルとリーステーブルの両方から読み取ります。機能的には、INIT と DEPLOYED に違いはありません。

すべてのワーカーは、ベイク時間の間、最小サポートコードを着実に出力します。アプリケーションはフェーズ 2 デプロイに移行する準備ができています。
DEPLOYED

すべてのワーカーが新しいコードでデプロイされました (フェーズ 1 が完了）。アプリケーションは単一のテーブル形式をサポートしていますが、アクティブ化されていません。

フェーズ 2 のデプロイは、 を migrateAllEntitiesToLeaseTableに設定して開始しますtrue。
PENDING

すべてのワーカーが新しいコードを実行します。KCL は、ワーカーメトリクスとコーディネーター状態テーブルからリーステーブルにデータを移行します。

移行が完了すると、24 時間のデフォルトのベイク時間が経過します。
COMPLETE

移行が完了しました。KCL は、すべての読み取りと書き込みにのみリーステーブルを使用します。古いワーカーメトリクスとコーディネーター状態テーブルは使用されなくなりました。

ターミナルの状態。それ以上の移行は行われません。

各状態、移行条件、および完全なステートマシンの動作の詳細については、「KCL シングルテーブル移行ステートマシン」を参照してください。

注記

PENDING 状態と COMPLETE 状態の間のデフォルトのベイク時間は 24 時間ですが、最大 1 週間まで設定できます。この期間中、KCL はすべての読み取りと書き込みにリーステーブルを使用しますが、古いテーブルは削除しません。移行が成功したことを確認したら、古いワーカーメトリクスとコーディネーター状態テーブルを手動で削除する必要があります。KCL はこれらのテーブルを自動的に削除しません。

ロールバックに関する考慮事項

ロールバックのサポートは、現在の によって異なりますTableMigrationStatus。

  • フェーズ 1 (TableMigrationStatus が未設定DEPLOYEDまたは未設定): 以前のバージョンに安全にロールバックできます。新しいコードは下位互換性モードで実行され、リーステーブルの非リースエントリにデータが書き込まれていません。

  • フェーズ 2 ( は DEPLOYEDまたは PENDING): フェーズ 1 にロールバックできます。TableMigrationStatusワーカーは、ワーカーメトリクスとコーディネーター状態のレガシーテーブル (マルチテーブル形式) の使用に戻ります。移行は元に戻されます。

  • COMPLETE 状態後: ロールバックはサポートされていません。KCL は、すべてのエンティティに対してリーステーブルのみを使用します。コードがフェーズ 1 にロールバックしても、ワーカーはすべてのエンティティのリーステーブルを使用し続け、設定は無視されます。

警告

移行が COMPLETE 状態になると、アプリケーションは単一テーブルモードでのみ動作します。migrateAllEntitiesToLeaseTable 設定は無視され、KCL は個別のテーブルの使用に戻されません。COMPLETE に移行する前にベイク時間が十分であることを確認してください。その後、コードロールバックでも複数のテーブルに切り替わらないためです。

ベストプラクティス

単一テーブル形式を採用する場合は、次のベストプラクティスに従ってください。

  • フェーズ 1 のデプロイ後、コーディネーター状態エントリが DEPLOYED ステータスTableMigration3.5に達していることを確認します。フェーズ 2 に進む前に、リグレッションがないことを確認します。

  • TableMigration3.5 コーディネーター状態エントリTableMigrationStatusの をモニタリングして、DEPLOYED、PENDING、COMPLETE の各状態の進行状況を追跡します。ステータスは、移行が COMPLETE に達するまで、（リーステーブルではなく) 別のエントリとしてコーディネーター状態テーブルに保存されます。

  • COMPLETE に移行する前にベイク時間が十分であることを確認してください。その後、コードロールバックでも複数のテーブルに切り替わらないためです。アプリケーションは単一テーブルモードでのみ機能します。

  • 移行が COMPLETE に達したら、古いワーカーメトリクスとコーディネーター状態テーブルを手動で削除します。KCL はこれらのテーブルを自動的に削除せず、使用を停止するだけです。

  • CoordinatorConfig.coordinatorStateTableConfig または を設定している場合はLeaseManagementConfig.workerUtilizationAwareAssignmentConfig.workerMetricsTableConfig、移行の完了後にこれらの設定を削除できます。これらの設定は KCL 3.5 以降では廃止されています。