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

# 以前のバージョンにロールバックする
<a name="kcl-migration-rollback"></a>

このトピックでは、コンシューマーを前のバージョンにロールバックする手順について説明します。ロールバックが必要な場合は、次の 2 ステップのプロセスを実行します。

1. [KCL 移行ツール](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/scripts/KclMigrationTool.py)を実行します。

1. 以前の KCL バージョンコードを再デプロイします (オプション)。

## ステップ 1: KCL 移行ツールを実行する
<a name="kcl-migration-rollback-tool"></a>

以前の KCL バージョンにロールバックする必要がある場合は、KCL 移行ツールを実行する必要があります。KCL 移行ツールは 2 つの重要なタスクを実行します。
+ これにより、DynamoDB のワーカーメトリクステーブルと呼ばれるメタデータテーブルとリーステーブルのグローバルセカンダリインデックスが削除されます。これら 2 つのアーティファクトは KCL 3.x によって作成されますが、以前のバージョンにロールバックするときには必要ありません。
+ これにより、すべてのワーカーが KCL 2.x と互換性のあるモードで実行され、以前の KCL バージョンで使用される負荷分散アルゴリズムの使用が開始されます。KCL 3.x の新しい負荷分散アルゴリズムに問題がある場合、この問題はすぐに軽減されます。

**重要**  
DynamoDB のコーディネーター状態テーブルが存在し、移行、ロールバック、ロールフォワードプロセス中に削除されていない必要があります。

**注記**  
コンシューマーアプリケーションのすべてのワーカーが、一度に同じ負荷分散アルゴリズムを使用することが重要です。KCL 移行ツールを使用すると、KCL 3.x コンシューマーアプリケーション内のすべてのワーカーが KCL 2.x 互換モードに切り替えられ、前の KCL バージョンにロールバックしている間、すべてのワーカーが同じ負荷分散アルゴリズムで動作するようにします。

[KCL 移行ツール](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/scripts/KclMigrationTool.py)は、[KCL GitHub リポジトリ](https://github.com/awslabs/amazon-kinesis-client/tree/master)のスクリプトディレクトリでダウンロードできます。このスクリプトは、コーディネーター状態テーブルへの書き込み、ワーカーメトリクステーブルの削除、およびリーステーブルの更新を行うための必要な権限を持つ任意のワーカー、または任意のホストから実行できます。スクリプトの実行に必要な IAM アクセス許可については、[KCL コンシューマーアプリケーションに必要な IAM アクセス許可](kcl-iam-permissions.md) を参照してください。このスクリプトは、KCL アプリケーションごとに 1 回だけ実行する必要があります。KCL 移行ツールは、以下のコマンドで実行できます。

```
python3 ./KclMigrationTool.py --region <region> --mode rollback [--application_name <applicationName>] [--lease_table_name <leaseTableName>] [--coordinator_state_table_name <coordinatorStateTableName>] [--worker_metrics_table_name <workerMetricsTableName>]
```

**パラメータ**
+ --region: を `<region>` に置き換えます AWS リージョン。
+ --application\$1name: このパラメータは、DynamoDB メタデータテーブル (リーステーブル、コーディネーター状態テーブル、ワーカーメトリクステーブル) にデフォルト名を使用している場合に必要です。これらのテーブルにカスタム名を指定している場合は、このパラメータを省略できます。`<applicationName>` を実際の KCL アプリケーションの名前に置き換えます。カスタム名が指定されていない場合、ツールはこの名前を使用してデフォルトのテーブル名を取得します。
+ --lease\$1table\$1name (オプション): このパラメータは、KCL 設定でリーステーブルのカスタム名を設定している場合に必要です。デフォルトのテーブル名を使用している場合は、このパラメータを省略できます。`leaseTableName` をリーステーブルに指定したカスタムテーブル名に置き換えます。
+ --coordinator\$1state\$1table\$1name (オプション): このパラメータは、KCL 設定でコーディネーター状態テーブルのカスタム名を設定している場合に必要です。デフォルトのテーブル名を使用している場合は、このパラメータを省略できます。`<coordinatorStateTableName>` を、コーディネーター状態テーブルに指定したカスタムテーブル名に置き換えます。
+ --worker\$1metrics\$1table\$1name (オプション): このパラメータは、KCL 設定でワーカーメトリクステーブルのカスタム名を設定している場合に必要です。デフォルトのテーブル名を使用している場合は、このパラメータを省略できます。`<workerMetricsTableName>` を、ワーカーメトリクステーブルに指定したカスタムテーブル名に置き換えます。

## ステップ 2: 以前の KCL バージョンでコードを再デプロイする (オプション)
<a name="kcl-migration-rollback-redeploy"></a>

 ロールバック用に KCL 移行ツールを実行すると、次のいずれかのメッセージが表示されます。
+ **メッセージ 1:** 「ロールバックが完了しました。お使いの KCL アプリケーションは KCL 2.x 互換モードで動作していました。問題が改善されない場合は、以前の KCL バージョンでコードをデプロイして、元のアプリケーションバイナリにロールバックしてください」。
  + **必要なアクション: **これは、ワーカーが KCL 2.x 互換モードで実行されていたことを意味します。問題が解決しない場合は、以前の KCL バージョンのコードをワーカーに再デプロイしてください。
+ **メッセージ 2:** 「ロールバックが完了しました。お使いの KCL アプリケーションは KCL 3.x の機能モードで動作していました。問題について 5 分以内に問題が緩和されない場合を除き、以前のアプリケーションバイナリへのロールバックは不要です。問題が解決しない場合は、以前の KCL バージョンでコードをデプロイして、以前のアプリケーションバイナリにロールバックしてください」。
  + **必要なアクション: **ワーカーが KCL 3.x モードで実行され、KCL 移行ツールがすべてのワーカーを KCL 2.x 互換モードに切り替えたことを意味します。問題が解決した場合は、以前の KCL バージョンのコードをワーカーに再デプロイする必要はありません。問題が解決しない場合は、以前の KCL バージョンのコードをワーカーに再デプロイしてください。