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

# KCL の単一テーブル形式
<a name="kcl-single-table-format"></a>

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

## 単一テーブル形式の仕組み
<a name="kcl-single-table-how-it-works"></a>

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

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

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

## 単一テーブル形式を設定する
<a name="kcl-single-table-config"></a>

単一テーブル形式を有効にする方法は、現在の 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 コードをデプロイします。これにより、単一のテーブル形式をサポートする新しいコードがインストールされますが、移行はアクティブ化されません。

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

## 移行状態
<a name="kcl-single-table-states"></a>

は、マルチテーブル形式から単一テーブル形式への移行`TableMigrationStateMachine`を管理します。KCL は、コーディネーター状態テーブルの という別のコーディネーター状態エントリ`TableMigration3.5`で現在の移行状態を追跡します。状態、遷移、および説明の完全なリストについては、[「KCL シングルテーブルの移行状態](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/coordinator/migration/TableMigrationStatus.java)」を参照してください。


**単一テーブル形式の移行状態**  

| State | 説明 | 移行条件 | 
| --- | --- | --- | 
| INIT | 初期状態。すべてのワーカーは、ワーカーメトリクス統計で最小サポートコードを出力しています。ワーカーは引き続きワーカーメトリクスをレガシーテーブルに出力し、ワーカーメトリクスとコーディネーターの状態をレガシーテーブルとリーステーブルの両方から読み取ります。機能的には、INIT と DEPLOYED に違いはありません。 | すべてのワーカーは、ベイク時間の間、最小サポートコードを着実に出力します。アプリケーションはフェーズ 2 デプロイに移行する準備ができています。 | 
| DEPLOYED | すべてのワーカーが新しいコードでデプロイされました (フェーズ 1 が完了）。アプリケーションは単一のテーブル形式をサポートしていますが、アクティブ化されていません。 | フェーズ 2 のデプロイは、 を `migrateAllEntitiesToLeaseTable`に設定して開始します`true`。 | 
| PENDING | すべてのワーカーが新しいコードを実行します。KCL は、ワーカーメトリクスとコーディネーター状態テーブルからリーステーブルにデータを移行します。 | 移行が完了すると、24 時間のデフォルトのベイク時間が経過します。 | 
| COMPLETE | 移行が完了しました。KCL は、すべての読み取りと書き込みにのみリーステーブルを使用します。古いワーカーメトリクスとコーディネーター状態テーブルは使用されなくなりました。 | ターミナルの状態。それ以上の移行は行われません。 | 

各状態、移行条件、および完全なステートマシンの動作の詳細については、[「KCL シングルテーブル移行ステートマシン](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/coordinator/migration/TableMigrationStatus.java)」を参照してください。

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

## ロールバックに関する考慮事項
<a name="kcl-single-table-rollback"></a>

ロールバックのサポートは、現在の によって異なります`TableMigrationStatus`。
+ **フェーズ 1** (`TableMigrationStatus` が未設定`DEPLOYED`または未設定): 以前のバージョンに安全にロールバックできます。新しいコードは下位互換性モードで実行され、リーステーブルの非リースエントリにデータが書き込まれていません。
+ **フェーズ 2 ( **は `DEPLOYED`または `PENDING`): フェーズ 1 にロールバックできます。`TableMigrationStatus`ワーカーは、ワーカーメトリクスとコーディネーター状態のレガシーテーブル (マルチテーブル形式) の使用に戻ります。移行は元に戻されます。
+ **COMPLETE 状態後**: ロールバックはサポートされていません。KCL は、すべてのエンティティに対してリーステーブルのみを使用します。コードがフェーズ 1 にロールバックしても、ワーカーはすべてのエンティティのリーステーブルを使用し続け、設定は無視されます。

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

## ベストプラクティス
<a name="kcl-single-table-best-practices"></a>

単一テーブル形式を採用する場合は、次のベストプラクティスに従ってください。
+ フェーズ 1 のデプロイ後、コーディネーター状態エントリが `DEPLOYED` ステータス`TableMigration3.5`に達していることを確認します。フェーズ 2 に進む前に、リグレッションがないことを確認します。
+ `TableMigration3.5` コーディネーター状態エントリ`TableMigrationStatus`の をモニタリングして、DEPLOYED、PENDING、COMPLETE の各状態の進行状況を追跡します。ステータスは、移行が COMPLETE に達するまで、（リーステーブルではなく) 別のエントリとしてコーディネーター状態テーブルに保存されます。
+ COMPLETE に移行する前にベイク時間が十分であることを確認してください。その後、コードロールバックでも複数のテーブルに切り替わらないためです。アプリケーションは単一テーブルモードでのみ機能します。
+ 移行が COMPLETE に達したら、古いワーカーメトリクスとコーディネーター状態テーブルを手動で削除します。KCL はこれらのテーブルを自動的に削除せず、使用を停止するだけです。
+ `CoordinatorConfig.coordinatorStateTableConfig` または を設定している場合は`LeaseManagementConfig.workerUtilizationAwareAssignmentConfig.workerMetricsTableConfig`、移行の完了後にこれらの設定を削除できます。これらの設定は KCL 3.5 以降では廃止されています。