View a markdown version of this page

以前のバージョンにロールバックする - Amazon Kinesis Data Streams
フェーズ 1 から以前の KCL バージョンにロールバックするフェーズ 2 からフェーズ 1 にロールバックするステップ 1: KCL 移行ツールを実行するステップ 2: フェーズ 1 設定でコードを再デプロイする (オプション)

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

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

このトピックでは、KCL 3.5.x コンシューマーを以前のバージョンにロールバックする手順について説明します。ロールバックプロセスは、アプリケーションが現在どの移行フェーズにあるかによって異なります。

重要

KCL 移行ツールは、フェーズ 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) からフェーズ 1 () にロールバックする場合にのみ必要ですCLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1。アプリケーションがまだフェーズ 1 にある場合は、ツールを実行せずに以前のコードを再デプロイすることで、以前の KCL バージョンにロールバックできます。

フェーズ 1 から以前の KCL バージョンにロールバックする

アプリケーションがフェーズ 1 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1) にある場合は、以前のコードを再デプロイすることで、以前の KCL バージョンにロールバックできます。フェーズ 1 は以前の KCL バージョンと下位互換性があり、リーステーブルには移行固有のエントリを作成しません。移行ツールは必要ありません。

フェーズ 1 からロールバックするには:

  1. 以前の KCL バージョンのコードをすべてのワーカーに再デプロイします。

フェーズ 2 からフェーズ 1 にロールバックする

アプリケーションがフェーズ 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) にある場合は、KCL 移行ツールを使用してフェーズ 1 にロールバックする必要があります。これは 2 ステップのプロセスです。

  1. KCL 移行ツールを実行します。

  2. フェーズ 1 設定でコードを再デプロイします (オプション）。

重要

2 つのレベル (フェーズ 2 からフェーズ 1、そして以前の KCL バージョン) をロールバックすることはできません。KCL 移行ツールは、フェーズ 2 からフェーズ 1 へのロールバックのみを処理します。

注記

KCL 移行ツールは、リーステーブルからリース以外のエントリを削除しません。これらのエントリは以前の KCL バージョンと下位互換性がないため、フェーズ 2 から以前の KCL バージョンに直接 2 レベルロールバックすることはできません。

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

フェーズ 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) からフェーズ 1 にロールバックする必要がある場合は、KCL 移行ツールを実行します。このツールは、次のタスクを実行します。

  • これにより、DynamoDB のリーステーブルのグローバルセカンダリインデックス (LeaseOwnerToLeaseKeyIndex) が削除されます。このインデックスは KCL 3.5.x によって作成されますが、フェーズ 1 にロールバックするときには必要ありません。

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

重要

リーステーブルのコーディネーター状態エントリ (Migration3.0) は、移行、ロールバック、ロールフォワードプロセス中に削除しないでください。

注記

コンシューマーアプリケーションのすべてのワーカーは、特定の時間に同じ負荷分散アルゴリズムを使用する必要があります。KCL 移行ツールは、KCL 3.5.x コンシューマーアプリケーションのすべてのワーカーが KCL 2.x 互換モードに切り替えられるようにし、ローリングデプロイ中にすべてのワーカーが同じ負荷分散アルゴリズムを実行できるようにします。

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

python3 ./KclMigrationTool.py --region <region> --mode rollback [--application_name <applicationName>] [--lease_table_name <leaseTableName>]

パラメータ

  • --region: を <region> に置き換えます AWS リージョン。

  • --application_name: このパラメータは、リーステーブルのデフォルト名を使用している場合に必要です。リーステーブルにカスタム名を指定している場合は、このパラメータを省略できます。<applicationName> を実際の KCL アプリケーションの名前に置き換えます。カスタム名が指定されていない場合、ツールはこの名前を使用してデフォルトのテーブル名を取得します。

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

ステップ 2: フェーズ 1 設定でコードを再デプロイする (オプション)

フェーズ 2 からフェーズ 1 へのロールバック用に KCL 移行ツールを実行すると、次のいずれかのメッセージが表示されます。

  • メッセージ 1: "ロールバックが完了しました。アプリケーションはフェーズ 2 (2 倍互換) 機能を実行していました。フェーズ 1 設定で KCL 3.5.x アプリケーションをデプロイして、フェーズ 1 にロールバックしてください。」

    • 必要なアクション: ワーカーがフェーズ 2 (2 倍互換) モードで実行されていました。フェーズ 1 設定 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1) で KCL 3.5.x アプリケーションをワーカーに再デプロイします。

  • メッセージ 2: "ロールバックが完了しました。KCL アプリケーションがフェーズ 2 (3x) 機能を実行し、フェーズ 2 (2x 互換) モードにロールバックされました。短期間後に緩和策が表示されない場合は、フェーズ 1 の設定で KCL 3.5.x アプリケーションをデプロイして、フェーズ 1 にロールバックしてください。」

    • 必要なアクション: ワーカーがフェーズ 2 (3x) モードで実行され、KCL 移行ツールがそれらをフェーズ 2 (2x 互換) モードでロールバックしました。問題が解決した場合は、再デプロイする必要はありません。問題が解決しない場合は、フェーズ 1 設定 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1) の KCL 3.5.x アプリケーションをワーカーに再デプロイします。