前のKCLバージョンにロールバックする - Amazon Kinesis Data Streams

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

前のKCLバージョンにロールバックする

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

  1. Migration KCL Tool を実行します。

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

ステップ 1: KCL移行ツールを実行する

以前のKCLバージョンにロールバックする必要がある場合は、KCL移行ツールを実行する必要があります。KCL Migration Tool は、次の 2 つの重要なタスクを実行します。

  • これにより、DynamoDB のリーステーブルのワーカーメトリクステーブルとグローバルセカンダリインデックスと呼ばれるメタデータテーブルが削除されます。これらの 2 つのアーティファクトは KCL 3.x によって作成されますが、以前のバージョンにロールバックするときには必要ありません。

  • これにより、すべてのワーカーが KCL 2.x と互換性のあるモードで実行され、以前のKCLバージョンで使用される負荷分散アルゴリズムの使用が開始されます。KCL 3.x の新しいロードバランシングアルゴリズムに問題がある場合、この問題はすぐに軽減されます。

重要

DynamoDB のコーディネーター状態テーブルが存在し、移行、ロールバック、ロールフォワードプロセス中に削除することはできません。

注記

コンシューマーアプリケーションのすべてのワーカーは、特定の時間に同じ負荷分散アルゴリズムを使用することが重要です。KCL Migration Tool は、KCL3.x コンシューマーアプリケーションのすべてのワーカーが KCL 2.x 互換モードに切り替え、ローリングの返済中にすべてのワーカーが同じ負荷分散アルゴリズムを実行できるようにしますKCL。

Migration KCL Tool は、KCL GitHubリポジトリ のスクリプトディレクトリでダウンロードできます。スクリプトは、コーディネーター状態テーブルへの書き込み、ワーカーメトリクステーブルの削除、リーステーブルの更新に必要なアクセス許可を持つ任意のワーカーまたは任意のホストから実行できます。スクリプトを実行するために必要なIAMアクセス許可IAM KCLコンシューマーアプリケーションに必要なアクセス許可については、「」を参照してください。スクリプトは、KCLアプリケーションごとに 1 回のみ実行する必要があります。KCL Migration Tool は、次のコマンドを使用して実行できます。

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_name: このパラメータは、DynamoDB メタデータテーブル (リーステーブル、コーディネーターステートテーブル、ワーカーメトリクステーブル) にデフォルト名を使用している場合に必要です。これらのテーブルにカスタム名を指定している場合は、このパラメータを省略できます。を実際のKCLアプリケーション名<applicationName>に置き換えます。カスタム名が指定されていない場合、ツールはこの名前を使用してデフォルトのテーブル名を取得します。

  • --lease_table_name (オプション): このパラメータは、KCL設定でリーステーブルのカスタム名を設定するときに必要です。デフォルトのテーブル名を使用している場合は、このパラメータを省略できます。をリーステーブルに指定したカスタムテーブル名leaseTableNameに置き換えます。

  • --coordinator_state_table_name (オプション): このパラメータは、KCL設定でコーディネーター状態テーブルのカスタム名を設定するときに必要です。デフォルトのテーブル名を使用している場合は、このパラメータを省略できます。をコーディネーター状態テーブルに指定したカスタムテーブル名<coordinatorStateTableName>に置き換えます。

  • --worker_metrics_table_name (オプション): このパラメータは、KCL設定でワーカーメトリクステーブルのカスタム名を設定するときに必要です。デフォルトのテーブル名を使用している場合は、このパラメータを省略できます。をワーカーメトリクステーブルに指定したカスタムテーブル名<workerMetricsTableName>に置き換えます。

ステップ 2: 以前のKCLバージョンでコードを再デプロイする (オプション)

ロールバックの KCL Migration Tool を実行すると、次のいずれかのメッセージが表示されます。

  • メッセージ 1: “ロールバックが完了しました。KCL アプリケーションは 2.x KCL 互換モードを実行していました。リグレッションの軽減が見られない場合は、以前のKCLバージョンでコードをデプロイして、以前のアプリケーションバイナリにロールバックしてください。

    • 必要なアクション: これは、ワーカーが 2.x KCL 互換モードで実行されていたことを意味します。問題が解決しない場合は、以前のKCLバージョンのコードをワーカーに再デプロイします。

  • メッセージ 2: “ロールバックが完了しました。KCL アプリケーションは 3.x KCL 機能モードを実行していました。5 分以内に問題の緩和策が表示されない限り、前のアプリケーションバイナリにロールバックする必要はありません。それでも問題が解決しない場合は、以前のKCLバージョンでコードをデプロイして、以前のアプリケーションバイナリにロールバックしてください。

    • 必要なアクション: これは、ワーカーが KCL 3.x モードで実行され、KCL移行ツールによってすべてのワーカーが 2.x KCL 互換モードに切り替えられたことを意味します。問題が解決した場合、以前のKCLバージョンでコードを再デプロイする必要はありません。問題が解決しない場合は、以前のKCLバージョンのコードをワーカーに再デプロイします。