View a markdown version of this page

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

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

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

フェーズ 1 から KCL 1.x にロールバックする

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

重要

フェーズ 2 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X) はロールバックに関する重大な変更です。アプリケーションがフェーズ 2 に入ると、KCL 1.x と下位互換性のないリース以外のエントリ (WORKER_METRIC_STATS および Migration3.0) がリーステーブルに書き込まれます。これにより、KCL 1.x への直接的なロールバックが恒久的に防止されます。フェーズ 2 に進む前に安定性を検証するために、フェーズ 1 でアプリケーションを長期間ベイクすることを強くお勧めします。

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

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

  1. GitHub ウェブサイトの KCL 移行ツールを実行します。

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

重要

2 段階ロールバックすること (フェーズ 2 からフェーズ 1 へ、さらに KCL 1.x へロールバックすること) はできません。KCL 移行ツールは、フェーズ 2 からフェーズ 1 へのロールバックのみを処理します。このツールは、リーステーブルからリース以外のエントリを削除しません。これらのエントリは KCL 1.x と下位互換性がないため、フェーズ 2 から KCL 1.x に直接 2 段階ロールバックすることはできません。

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

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

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

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

重要

リーステーブル内のコーディネーター状態エントリ (Migration3.0) は、移行、ロールバック、ロールフォワードプロセス中に削除してはなりません。

注記

コンシューマーアプリケーションのすべてのワーカーが、一度に同じ負荷分散アルゴリズムを使用する必要があります。KCL 移行ツールを使用すると、KCL 3.5.x 以降のコンシューマーアプリケーション内のすべてのワーカーが KCL 1.x 互換モードに切り替えられ、フェーズ 1 へのローリングデプロイによるロールバック中も、すべてのワーカーが同じ負荷分散アルゴリズムで動作するようにします。

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

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

パラメータ

--region

リージョンをお客様の AWS リージョンに置き換えてください。

--application_name

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

--lease_table_name

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

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

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

メッセージ 1

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

必要なアクション: ワーカーが KCL 1.x 互換モードで実行されていました (フェーズ 2 から完全な 3.x の負荷分散に自動的に移行されていません)。フェーズ 1 の設定 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1) を使用して KCL 3.5.x 以降のアプリケーションをワーカーに再デプロイします。

メッセージ 2

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

必要なアクション: ワーカーは完全な KCL 3.x の負荷分散に自動的に移行していましたが、KCL 移行ツールによって KCL 1.x 互換モードに切り替えられました。問題が解決した場合は、再デプロイする必要はありません。問題が解決しない場合は、フェーズ 1 の設定 (CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1) を使用して KCL 3.5.x 以降のアプリケーションをワーカーに再デプロイします。