AWS DMS を使用した移行からのロールバック

AWS Database Migration Service (DMS) を使用してデータベースを新しいシステムに移行する場合、新しいシステムが想定どおりに機能しない場合に備えてフォールバック戦略を立てることが賢明です。概要として、移行からロールバックするためには、4 つの基本的な戦略があります。すなわち、基本的なフォールバック、フォールフォワード、デュアル書き込み、双方向レプリケーションです。特定の状況に応じて、これらの戦略の 1 つまたは複数を用いることができる場合があります。

この投稿では、各戦略を定義し、その戦略が適切であると思われる状況の概要を説明します。一般的には、データベースシステムの整合性を維持しながら、最小限の労力とコストを必要とする戦略または戦略の組み合わせをデプロイすべきです。

基本的なフォールバック

ソース A からターゲット B に移行する場合の最も簡単なフォールバック戦略は、アプリケーションを元のソース A に戻すことです。この戦略は、あまり生じないかもしれませんが、以下の状況では合理的です。

読み取り専用システムを移行していて、新しいターゲットが新しいトランザクションを取得していない。
システムは「バッチ」タイプのシステムであり、新しいターゲットにまだトランザクションを適用していない。
古いシステムにロールバックした後は、新しいシステムでトランザクションを使用する必要がいない。(一部のロギングシステムはこのパターンである場合があります。)
ロールバックの前または後に、新しいシステムで使用されたトランザクションを元のシステムに再生成またはコピーすることができる。(ロギングシステムまたは挿入のみのシステムは、このパターンである場合があります。)
元のシステムにロールバックした後、新しいシステムにトランザクションを適用する必要はない。

カットオーバーの前に、DMS タスクはデータを A から B にレプリケートします。B に「フリップ」されるアプリケーションは、引き続き A とインタラクションします。次の図は、このアーキテクチャを示しています。

カットオーバー時にレプリケーションタスクが停止し、アプリケーションがフリップされて B とインタラクションします。次の図は、この変更を示しています。

ロールバックが必要な場合、アプリケーションはフリップされて A に戻ります。B のカットオーバー後に発生した変更は、無視され、または失われます。下図を参照してください。

デュアル書き込み

場合によっては、移行の一環として、デュアル書き込み戦略が使用されます。たとえば、データベース A をデータベース B に移行する場合の状況を考えてみます。デュアル書き込み戦略では、両方のデータベースにトランザクションを同時に書き込むことができるようにアプリケーションコードを変更します。デュアル書き込み戦略の採用は、アプリケーションへの (通常は重要な) 変更を伴うため、より複雑で時間のかかるフォールバックアプローチの 1 つです。ただし、ターゲットデータベース B への書き込みを停止するだけなので、デュアル書き込み構成からのフォールバックは簡単です。次の状況では、デュアル書き込み戦略が適切な場合があります。

データが (おそらく顧客ごとに) 分割されており、アプリケーションの移行に段階的なアプローチを採用している。このシナリオでは、DMS を使用して新しいターゲットをハイドレートし、ソースと同期させます。カットオーバーでは通常、デュアル書き込み機能を有効にし、DMS レプリケーションタスクを無効にします。フォールバックでは、デュアル書き込みを無効にします (また、DMS タスクの再開が含まれる場合があります)。
他のフォールバック戦略がどれもうまくいかない。

次のデュアル書き込み構成では、DMS を使用して、アプリケーションが B をポイントするまで A と B の同期を維持します。次の図は、このアーキテクチャを示しています。

アプリケーションが B をポイントすると、DMS タスクが停止し、アプリケーションは引き続き A への変更を書き込みます。次の図は、構成の変化を示しています。

ロールバックが必要な場合、アプリケーションは B への書き込みを停止するか、アプリケーション自体が非デュアル書き込みバージョンにロールバックします。次の図は、構成の変化を示しています。

ロールバックの理由によっては、レプリケーションタスクを再インスタンス化して、A と B の同期を維持したい場合があります。たとえば、問題がパフォーマンスに関連していて、B を調整したり、B のホストをスケールアップしたりできる場合は、後で移行するために B が A と同期した状態を維持しておくことが望ましいでしょう。下図を参照してください。

フォールフォワード

フォールフォワードアプローチでは、元のソースデータベースのレプリカである 3 つ目のデータベースを作成します。次に、元のソース A から、新しいターゲット B、そして A’ と呼ばれる A のレプリカ (たとえば、A → B → A’) へのレプリケーションタスクを作成します。カットオーバー時に、アプリケーションはデータベース A への書き込みを停止し、データベース B への書き込みを開始します。データベース B からデータベース A’ へのレプリケーションストリームは、A’ が B と同期した状態を維持します。移行を中止する必要がある場合は、データベース B への書き込みを停止し、アプリケーションをデータベース A’ にポイントします。データベース A’ は、移行の一環として、データベース B に書き込まれたトランザクションを使用しています。

このフォールフォワードアプローチでは、「元のカットオーバーの一部として、ターゲット B からソース A への 2 つ目のレプリケーションタスクを作成しないのはなぜですか?」という質問が呈されます。この方法は、データベース B からデータベース A へのレプリケーションストリームをテストできないためお勧めできません。さらに、A で発生したトランザクションが B にレプリケートされ、ループバックして、B から A への変更ストリームの一部として再び A に適用される、いわゆる「ループバック」効果を防ぐためのメカニズムが必要になります。

フォールフォワードアプローチでは、システムをエンドツーエンドでテストできます。この方法は、データベース A とデータベース B が Oracle や PostgreSQL などの異なるエンジンを使用している異種移行のシナリオで特に重要です。

次のシナリオでは、移行をロールバックするフォールフォワードアプローチが適切です。

ロールバック先のシステムがターゲットシステムと同期していることを確認して、ロールバックが可能な限り迅速かつ簡単になるようにする必要がある。
アーキテクチャが複雑なため、ロールバックメカニズムで特別な考慮を必要としない異種移行を実行している。言い換えると、基本的なフォールバック (前述) が不可能な場合は、ロールフォワードアプローチが推奨されます。
DMS などの論理レプリケーションツールを使用して同種移行を実行しており、ロールバックメカニズムに特別な考慮を要しない。

フォールフォワードアプローチでは、新しいターゲット B に加えて、A のコピーも作成されます (下図の A’)。次に、変更が A から B に、および B から A’ にレプリケートされます。これにより、A から B へのレプリケーションストリームに加えて、B から A’ へのレプリケーションストリームを徹底的にテストできます。次の図は、この構成を示しています。

カットオーバー時に、アプリケーションはターゲット B をポイントし、A から B へのレプリケーションストリームは削除されます (または休止状態になります)。ロールバックが必要な場合に備えて、B から A’ へのレプリケーションストリームは引き続き実行されます。次の図は、構成の変化を示しています。

ロールバックを実行する必要がある場合、アプリケーションはデータベース A’ にロールフォワードします。これは、データベース B で発生した変更を含む A のコピーです。次の図を参照してください。

より複雑なアーキテクチャ

多くの状況で、移行では、データベースシステム全体またはアーキテクチャ的に分離されたデータベースシステムの移動が行われます。状況によっては、データベースシステムの一部、またはマルチマスターレプリケーションアーキテクチャの一部であるデータベースなど、相互に依存するより大きなシステムの一部であるデータベースシステムを移行することが望ましい場合があります。

システムの一部の移行または漸次的な移行

大規模なマルチテナントデータベースの移行を、長期間にわたってステージングできる小さなコンポーネントに分割することが望ましい場合がよくあります。このアプローチは、問題が発生した場合のリスクを軽減できますが、ロールバックアーキテクチャを複雑にする可能性もあります。データベースシステム全体をロールバックする代わりに、システムの一部をロールバックする必要があります。これを実現する 1 つの方法はデュアル書き込み戦略ですが、アプリケーションの変更とカットオーバー時の慎重な調整を要します。

マルチテナントシステムを分割する場合、個々の移行は通常、特定のアプリケーションまたは一連のアプリケーションに関連付けられます。多くの場合、これらのアプリケーションに関連付けられたデータを物理的または論理的に分離できます。その場合、フォールフォワードアーキテクチャを使用できます。これは、ソース A、ターゲット B、および A のレプリカ (A’) で構成されます。前述の場合と同様に、A から B へ、および B から A’ へデータをレプリケートします。なお、A からのすべてのデータを B にレプリケートすることを希望しない場合もあるかもしれませんが、A および B からのデータのスーパーセットを最終的に A’ に置く必要があります。これは、A → B → A’ および A → A’ の 3 つのレプリケーションストリームを作成することで実現できます。A から B へのレプリケーションストリームは、B に移行するアプリケーションに関連付けられたデータのみをレプリケートします。A から A’ へのレプリケーションストリームは、B に移行するアプリケーションに関連付けられていないすべてのデータをレプリケートします。

以下のアーキテクチャでは、データを B に書き込むアプリケーションを切り分けることが目的です。データベース B には、すべてのアプリケーションから分割されたアプリケーション B に関連付けられたデータのみが含まれます。データベース A’ には、すべてのアプリケーションのデータが含まれています。レプリケーションタスク DMS 1 は、アプリケーション B に関連付けられたデータを A から B および B から A’ (フォールフォワードデータベース) にレプリケートします。レプリケーションタスク DMS 2 は、アプリケーション B に関連付けられていないデータをデータベース A’ にレプリケートします。

カットオーバー時に、アプリケーション B はデータベース B に転送され、A から B への DMS 1 タスクは削除されます。元のデータベースのデータの B スライスへの書き込みを担当するアプリケーションは、停止するか、データベース A にデータを書き込まないように変更されます。次の図は、このアーキテクチャを示しています。

ロールバックが必要な場合は、アプリケーション B が停止し、すべてのアプリケーション (元々 A のデータの B スライスの書き込みを担当していたアプリケーションを含む) が再開され、データベース A’ への書き込みにリダイレクトされます。この時点で、すべての DMS タスクが削除されるか、休止状態のままになります。次の図は、この構成を示しています。

上記の戦略は、マルチテナントシステムを複数の独立したシステムに分割することを想定しています。大規模なシステムのサブコンポーネントを段階的に新しいシステムに移行する場合も、これらの概念を適用できます。これは、前述のマルチテナントの例の特殊なケースとして実行できます。最初の移行後、データベース B とデータベース A のロールフォワードシステムを段階的に作成する必要があります。

システム全体を段階的に移行することもできます。たとえば、新しいシステムを拡張する方法を学ぶときに、潜在的な影響を最小限に抑えるために、一度に数人の顧客を顧客管理システムに移行することができます。このシナリオでは、顧客または一連の顧客を管理する責任をすべてのアプリケーションからアプリケーション B に移すことができます。ロールバックを実行する必要がある場合は、すべての顧客をロールフォワードシステムにロールフォワードできます。問題が発生した一連の顧客のみをロールバックし、正常な顧客の移行のためにシステム B を保持したい場合は、システム B のロールフォワードインスタンスを作成し、移行の各ステージに新しいロールフォワード A’ を作成する必要があります。次の図は、このアーキテクチャを示しています。

この段階的な移行では、アプリケーション B はすでに移行されており、システムはアプリケーション C の移行の準備のためにセットアップされています。ロールフォワードデータベース A’ と DMS タスク (DMS 3) はなお存在しており、C に関連付けられていないデータを A’ に移動します。アプリケーション C に関連付けられたデータを A から新しいデータベース B、C に移動し、そこからロールフォワードインスタンス A’ に移動するための DMS タスクの別のセット (DMS 1) があります。追加のロールフォワードデータベース B’ と DMS タスク (DMS 2) があり、アプリケーション C に関連付けられていないデータを B から B’ に移動します。

カットオーバー時に、データを A から B、C に移動する DMS タスクが停止します。アプリケーション C はデータベース B、C にリダイレクトされます。次の図は、このアーキテクチャを示しています。

ロールバックが必要な場合、アプリケーション B は B’ をポイントし、他のアプリケーション (アプリケーション C を含む) は A’ にリダイレクトされます。すべての DMS タスクは、削除されるか、休止状態になります。次の図は、この構成の変化を示しています。

システムの統合

状況によっては、複数のシステムを単一のシステムに移行したい場合があります。たとえば、MySQL シャードのシステムを単一またはより小さなセットの Aurora MySQL データベースに移行することはよく見られます。システム統合のロールフォワードアーキテクチャは、段階的な移行の場合に類似しています。

最初の統合データベース B は、1 つ、2 つ、またはそれ以上のシャードで開始できます。このシナリオでは、DMS タスクは統合システム B をインスタンス化し、1A と 2A の 2 つのシャードと同期します。システム 1A’ および 2A’ は、フォールフォワードオプションとして作成されます。DMS タスクは、1A’ と 2A’ をシステム B と同期させます。次の図は、このアーキテクチャを示しています。

カットオーバー時に、アプリケーションはデータベース B を使用して、以前にシャード 1A および 2A に保存されたデータを取得します。1A から B および 2A から B にデータを移動する DMS タスクは、削除されるか、休止状態のままになります。データベース 1A および 2A は不要になりました。次の図は、この変化を示しています。

ロールバックを実行する必要がある場合、アプリケーションは、シャード 1 と 2 に関連付けられたデータに 1A’ と 2A’ をそれぞれ使用します。すべての DMS タスクは、削除されるか、休止状態になります。次の図は、この構成の変化を反映しています。

シャード 1 と 2 の統合が成功したことを前提として、シャードを一度に 1 つ以上統合し続けることができます。上記の例では、さらに 2 つのシャードを追加しています。次の図は、2 つのシャードの追加を示しています。フォールフォワードインスタンス (1B、2B)’ は、統合システムのフォールフォワードデータベースとして追加されます。

この戦略を使用して、単一のマルチテナントデータベース、複数の独立したデータベース、またはマルチテナントデータベースを単一のデータベースに段階的に移行できます。複数のシステムを Amazon Aurora データベースに統合する場合、これはかなり一般的なパターンです。

データベースの相互依存システムの移行

一部のアーキテクチャでは、独立したデータベースまたはデータベースシステム間に依存関係が存在します。たとえば、一部のデータベースは、マルチマスターレプリケーションを使用して、システムの異なるノード間で一部 (またはすべて) のデータを同期します。場合によっては、システム全体を移行できます。他の状況では、システム全体を一度に移行することは実用的ではないか、リスクが高すぎます。いずれにしても、移行の前にロールバック戦略を備えておくことが重要です。

次の図は、データベースタイプ A で実行されている 4 つのノードのマルチマスターデータベース構成を示しています。ノード間の矢印は、ノードペア間の双方向のレプリケーションを示しています。マルチマスターレプリケーションは、サードパーティーのソフトウェアまたは対象のデータベースシステムにネイティブなソフトウェア (DMS ではありません) を使用して実現されます。

次の図は、システム全体をデータベースタイプ A からデータベースタイプ B に移行するためのロールフォワード機能を含むアーキテクチャを示しています。データベースタイプ B のノード 1〜4 で構成される新しいデータベースシステムがインスタンス化され、DMS を使用して、対応するノード間のレプリケーションが確立されます。タイプ A のフォールフォワードデータベースが各ノード (1〜4 A’) に確立され、DMS レプリケーションが B ノードから A’ ノードに確立されます。この時点で、B ノードと A’ ノード間のマルチマスターレプリケーションがインスタンス化され、徹底的にテストされます。

カットオーバー時に、アプリケーションはデータベースタイプ B のノード 1〜4 をポイントします。A ノードから B ノードにデータをレプリケートする DMS タスクは、削除されるか、休止状態になります。データベース 1A〜4A は廃止されます。次の図は、この構成の変化を示しています。

ロールバックを実行する必要がある場合、アプリケーションはノード 1A’～4A’ をポイントします。すべての DMS タスクは、削除されるか、休止状態になります。データベース 1B〜4B は廃止されます。下図を参照してください。

このシナリオは、状況によって、実用的である場合とそうでない場合があります。たとえば、システム全体を一気に動かすリスクを許容できない場合があります。あるいは、ロールフォワードインスタンスに Amazon RDS または Amazon EC2 を使用できず、完全なロールフォワードシステムを作成するために使用できるハードウェアがない場合もあります。

次の図は、一度に 1 つのノードでマルチマスターシステムの移行をサポートするロールフォワードアーキテクチャの概要を示しています。移行する最初のノードはノード 2 です。ノード 2 のデータは、データベース 2B とデータベース 2A’ にコピーされます。DMS レプリケーションタスクは、2B を 2A と同期させ、2A’ を 2B と同期させます。

カットオーバー時に、以前に 2A に送信されたワークロードは 2B にリダイレクトされます。フォールフォワードノード 2A’ は、マルチマスターグループのメンバーとしてインスタンス化されます。2A から 2B への DMS タスクは、削除されるか、休止状態になります。次の図では、ノード 2A’ は、ノード 4A とのみレプリケーションに参加しています。ノード 4A は、グループ 2A’ の変更をグループの他のノードと調整します。マルチマスター構成によっては、2A’ をグループの適切なメンバーとして追加し、ノード 1A および 3A に接続する必要がある場合があります。

移行を中止する必要がある場合、ノード 2B 向けのワークロードはノード 2A’ を使用するようにリダイレクトされます。また、ノード 2A’ をノード 1A およびノード 3A に接続する必要があるか、それを希望する場合があります。次の図は、この構成の変化を示しています。

次の図は、ノード 2A から 2B への移行が成功し、ノード 1A を移行するようにセットアップしていることを示しています。ノード 2A’ は、変更を 2B から最初のマルチマスターグループに転送しているため、引き続き必要です。(ノード 2B を元のマルチマスターグループに含めることが可能な場合は、含めることができ、ノード 2A’ を必要としないことができます。) ノード 1B と 1A’ には 1A からのデータがロードされ、DMS タスクは 1B を 1A と同期し、1A’ を 1B と同期します。

カットオーバー時に、1A を対象としたワークロードは、ノード 1B を使用するようにリダイレクトされます。ノード 1B と 2B の間でマルチマスター接続がインスタンス化されます。1A と 1B の間の DMS タスクは、削除されるか、休止状態になり、ノード 1A は廃止されます。ノード 1A’ とノード 4A の間にマルチマスターレプリケーションタスクが作成されます。必要に応じて (または希望に応じて)、ノード 1A’ と、ノード 3A および 2A’ との間でマルチマスター接続が行われます。ノード 1B のロールフォワード手順は、ノード 2B で概説したロールフォワード手順と同様です。下図を参照してください。

フォールフォワードが不可能な場合

少し考えて工夫することで、ロールバック計画を必要とするほとんどの移行プロジェクトに対応できるフォールフォワードアーキテクチャを考案できます。ただし、たとえば、マルチマスター構成に参加している単一ノードのサブセットまたはコンポーネントを移行する場合など、状況によっては、フォールフォワードアーキテクチャの作成が複雑すぎるか、不可能です。

これらの状況に対処するために、DMS には双方向レプリケーションが含まれています。双方向レプリケーションは、A で発生したトランザクションが B から A へのレプリケーションストリームの一部としてループして A に戻ること (およびその逆の状況) を防ぎつつ、システム A から B へ、および B から A へデータをレプリケートできます。

ロールバックメカニズムとして双方向レプリケーションを使用する場合の問題は、B から A へのレプリケーションストリームを B へのカットオーバー後までテストできないことです。論理レプリケーションをスムーズに機能させるには、(特に A と B が異なるデータベースエンジンを使用する異種の移行では) かなりの作業が必要になるため、これは危険です。次のアーキテクチャは、ロールバックメカニズムとして双方向レプリケーションを必要とするシステムで B から A へのレプリケーションストリームのベストエフォートテストを実行する方法の概要を示しています。下図を参照してください。

このシナリオでは、マルチテナントデータベース A1 からアプリケーション B を抽出し、データベース A1 とは異なるエンジンを実行する新しいデータベース B を使用させる必要があります。A1 は、複雑なマルチマスターレプリケーション構成の参加ノードです。

このシナリオのフォールフォワードアーキテクチャの作成は複雑になります。アプリケーション B がデータベース A1 を使用する他のアプリケーションよりも比較的小さいか、重要度が低い場合、双方向レプリケーションによってシステム全体のリスクが低下する可能性があります。

次の図は、アプリケーション B がデータベース A1 から必要とするデータのサブセットを使用して作成およびロードされたデータベース B を示しています。この意図は、アプリケーション B を移行してデータベース B を使用することにあります。双方向レプリケーションは、DMS タスク 1 と 2 を使用して A1 と B の間で構成されます。データベース B は AWS にあります。A1 は AWS にありません。カットオーバー時に、アプリケーションはデータベース B の使用を開始し、DMS 1 は関連する変更を A1 から B にプッシュし、DMS 2 は変更を B から A1 にプッシュします。

前示の図において、データベース B が A1 と同期した状態を維持するために DMS 1 を使用したため、DMS 1 がうまく機能することは明らかです。しかし、データベース B はカットオーバー後までアプリケーション B からトランザクションを受信しないため、DMS 2 のテストは行っていません。前述のように、特に異なるエンジンを実行しているデータベース間で論理レプリケーションを正しく機能させるには、かなりの労力を要する可能性があるため、これはフォールバック戦略に重大なリスクをもたらします。

テストされていない DMS タスクの使用に関連するリスクを軽減するために、エンジン A にデータベース B のコピーを作成し、2 つが同期している状態を維持するために DMS タスク (T) を作成できます。カットオーバー後に B から A1 にデータをプッシュするタスクに DMS T からの構成を使用できます。次の図は、このアーキテクチャを示しています。

B のコピーでは、DMS T がデータの既存の相互依存関係で機能することを確認するために、A1 からのデータの一部またはすべてが必要になる場合があります。一部のシナリオでは、A1 の完全なコピーが必要になる場合があります。

ここまでは、すべてのフォールバック構成のレプリケーションパイプラインをテストできるため、移行に関与するシステムのロケーションを省略しました。双方向レプリケーションでは、ターゲット (B) からソース (A1) に戻るレプリケーションパイプラインを完全にテストすることはできません。より具体的には、ネットワーク構成が双方向レプリケーションをサポートしていることを確認する必要があります。したがって、DMS T をテストする場合、データベース B のコピーである A のロケーションが、データベース A1 と同一または類似のネットワーク構成で、同じロケーションにあることが重要です。次の図は、このアーキテクチャを示しています。

最終的な構成は、データベース B と DMS タスクの双方向ペアで構成されます。タスク DMS 2T は、B から A のコピーにデータを移動するために徹底的にテストされたタスクと同じように構成されています。次の図を参照してください。

カットオーバー時に、アプリケーション B に新しいデータベース B を使用するように指示します。DMS 2T は、データベース B の変更をデータベース A1 にプッシュします。次の図は、この変化を示しています。

ロールバックする必要がある場合は、アプリケーション B がデータベース A1 を使用するように戻すだけです。DMS タスクは、削除されるか、休止状態になり、データベース B は廃止されます。次の図は、この変化を示しています。

まとめ

論理レプリケーションの使用がデータベース移行戦略の不可欠な部分となっている状況が多くあります。あらゆる移行において、移行を中止する必要がある場合に備えて、ロールバック戦略を立てておくことが重要です。移行戦略の一部として論理レプリケーションを使用することで、移行と移行のロールバックに関連する停止を最小化できます。

移行を中止するフォールフォワードアプローチを含む移行アーキテクチャを作成することで、移行からのロールバックに必要な時間が短縮されます。ロールフォワードアプローチが不可能な場合は、ロールバック戦略の一部として使用されるレプリケーションパイプラインをテストする必要があります。

いつものように、AWS はフィードバックを歓迎します。以下からコメントをお寄せください。

著者について

Ed Murray 氏は、アマゾンウェブサービスのプリンシパルデータベースエンジニアです。

Amazon Web Services ブログ