データベースの移行: コンセプトと原則（パート 1）

Last reviewed 2024-03-07 UTC

このドキュメントでは、オンプレミスまたは他のクラウド環境から Google Cloud にデータベースを移行するクラウドアーキテクト向けに、ダウンタイムがほぼゼロのデータベース移行のコンセプト、原則、用語、アーキテクチャについて説明します。

このドキュメントは 2 部構成の前半です。後半では、障害シナリオを含め、移行プロセスの設定と実行について説明します。

データベース移行は、データベース移行サービスを使用して 1 つ以上のソースデータベースから 1 つ以上のターゲットデータベースにデータを移行するプロセスです。移行の完了後、（再構築される場合があるものの）ソースデータベースのデータセットは完全にターゲットデータベースに移動されます。ソースデータベースにアクセスしたクライアントはターゲットデータベースにリダイレクトされ、ソースデータベースは停止されます。

次の図は、このデータベース移行プロセスを示しています。

移行サービスを介したソースデータベースからターゲットデータベースへのデータの流れ。

このドキュメントでは、アーキテクチャの観点からのデータベースの移行について説明します。

データベース移行に関連するサービスとテクノロジー。
同機種のデータベース移行と異機種のデータベース移行の違い。
移行のダウンタイム許容範囲のトレードオフと選択。
移行中に予期しないエラーが発生した場合のフォールバックをサポートする設定アーキテクチャ。

このドキュメントでは、具体的なデータベース移行テクノロジーの設定方法については説明しません。代わりに、基本的、概念的、原則的な用語を使用してデータベース移行について説明します。

アーキテクチャ

次の図は、一般的なデータベース移行アーキテクチャを示しています。

ソースデータベースとターゲットデータベースにアクセスする移行サービスのアーキテクチャ。

データベース移行サービスは Google Cloud 内で実行され、ソースデータベースとターゲットデータベースの両方にアクセスします。ここでは、2 つのバリアントがあります。(a) は、オンプレミスデータセンターやリモートクラウドのソースデータベースから Spanner などのマネージドデータベースへの移行を、(b) は、Compute Engine 上のデータベースへの移行を示しています。

ターゲットデータベースのタイプ（マネージドと非マネージド）や設定は異なりますが、データベース移行のアーキテクチャと構成はどちらの場合も同じです。

用語

このドキュメントで最も重要なデータ移行に関する用語は、次のように定義されています。

ソースデータベース: 1 つ以上のターゲットデータベースに移行するデータを含むデータベース。

ターゲットデータベース: 1 つ以上のソースデータベースから移行されたデータを受け取るデータベース。

データベースの移行: 移行完了後にソースデータベースシステムを停止することを目的とした、ソースデータベースからターゲットデータベースへのデータの移行。データセット全体またはサブセットが移行されます。

同機種の移行: ソースデータベースとターゲットデータベースでデータベース管理システムとそのプロバイダが同じ場合の、ソースデータベースからターゲットデータベースへのデータの移行。

異機種の移行: ソースデータベースとターゲットデータベースでデータベース管理システムとそのプロバイダが異なる場合の、ソースデータベースからターゲットデータベースへのデータの移行。

データベース移行システム: ソースデータベースとターゲットデータベースに接続し、ソースからターゲットにデータを移行するソフトウェアシステムまたはサービス。

データ移行プロセス: ソースデータベースからターゲットデータベースにデータを転送し場合に応じて転送中にデータを変換する、構成または実装されたプロセス。データ移行システムによって実行される。

データベースレプリケーション: ソースデータベースを停止することを目的としない、ソースデータベースからターゲットデータベースへのデータの連続的な転送。データベースレプリケーション（データベースストリーミングとも呼ばれます）は、連続的なプロセスです。

データベース移行の分類

データベース移行はいくつかの種類に分類されます。このセクションでは、これらの分類を定義する基準について説明します。

レプリケーションと移行

データベースの移行では、ソースデータベースからターゲットデータベースにデータを移動します。データの移行が完了したら、ソースデータベースを削除し、クライアントアクセスをターゲットデータベースにリダイレクトします。ターゲットデータベースで予期しない問題が発生した場合に、代替データベースとしてソースデータベースを保持する場合もあります。ただし、ターゲットデータベースが正常に動作する場合は、最終的にソースデータベースを削除します。

対してデータベースレプリケーションでは、ソースデータベースを削除せずに、ソースデータベースからターゲットデータベースにデータを連続的に転送します。データベースレプリケーションは、データベースストリーミングと呼ばれることもあります。データベースレプリケーションの開始時間は定義されますが、完了時間は通常定義されません。レプリケーションが停止することや、レプリケーションが移行になることもあります。

このドキュメントでは、データベースの移行についてのみ説明します。

部分移行と完全移行

データベースの移行は、データの完全で一貫した転送であるとみなされます。転送する最初のデータセットは、完全なデータベース、あるいは部分的なデータベース（データベース内のデータのサブセット）のいずれかに、その後にソースデータベースシステムで commit されたすべての変更を加えたものとして定義されます。

異機種および同機種の移行

同機種のデータベース移行とは、同じデータベーステクノロジーを使用するソースデータベースとターゲットデータベースの間のデータの移行です。たとえば、MySQL データベースから MySQL データベース、Oracle® データベースから Oracle データベースなどです。同機種の移行には、PostgreSQL などのセルフホストのデータベースシステムと Cloud SQL for PostgreSQL や AlloyDB for PostgreSQL などのマネージドバージョンとの移行も含まれます。

同機種のデータベースの移行では、ソースデータベースとターゲットデータベースのスキーマは同じであることが多いです。スキーマが異なる場合は、移行中にソースデータベースのデータを変換する必要があります。

異機種のデータベース移行とは、異なるデータベーステクノロジーを使用するソースデータベースとターゲットデータベースの間のデータの移行です。たとえば、Oracle データベースから Spanner への移行などです。異機種のデータベース移行は、同じデータモデル間（たとえば、リレーショナルからリレーショナル）、および異なるデータモデル間（たとえば、リレーショナルから Key-Value）で行うことができます。

異なるデータベーステクノロジー間での移行は、必ずしも異なるデータモデルを伴うわけではありません。たとえば、Oracle、MySQL、PostgreSQL、Spanner はすべてリレーショナルデータモデルをサポートしています。ただし、Oracle、MySQL、PostgreSQL などのマルチモデルデータベースは、さまざまなデータモデルをサポートしています。マルチモデルデータベースに JSON ドキュメントとして保存されたデータは、ソースデータベースとターゲットデータベースでデータモデルが同じであるため、変換をほとんど、またはまったく必要とせずに MongoDB に移行できます。

同機種の移行と異機種の移行の分類の基準はデータベーステクノロジーですが、データベースモデルを基準として分類する場合もあります。たとえば、Oracle データベースから Spanner への移行は、両方がリレーショナルデータモデルを使用する場合は同機種の移行になります。JSON オブジェクトとして Oracle に保存されているデータが Spanner のリレーショナルモデルに移行される場合、異機種の移行になります。

データモデルで移行を分類する場合、関与するデータベースシステムに基づいて分類する場合よりも、データの移行に必要な複雑さと労力がより正確に表現されます。ただし、業界で一般的に使用されている分類方法は、関与するデータベースシステムに基づいたものであるため、残りのセクションではその分類方法に基づいています。

移行のダウンタイム: ゼロ、ほぼゼロ、大幅の違い

データセットをソースデータベースからターゲットデータベースに正常に移行したら、クライアントアクセスをターゲットデータベースに切り替えて、ソースデータベースを削除します。

クライアントをソースデータベースからターゲットデータベースに切り替えるには、いくつかの手順を踏む必要があります。

処理を続行する場合、クライアントはソースデータベースへの既存の接続を閉じ、ターゲットデータベースへの新しい接続を作成する必要があります。理想的には、接続を閉じることが適切です。すなわち、進行中のトランザクションを不必要にロールバックしないようにします。
ソースデータベースの接続を閉じた後、残りの変更をソースデータベースからターゲットデータベースに移行（ドレインと呼ばれます）して、すべての変更が確実にキャプチャされるようにする必要があります。
ターゲットデータベースをテストして、これらのデータベースが機能していること、クライアントが機能していて、定義されたサービスレベル目標（SLO）内で動作していることを確認する必要がある場合があります。

移行において、クライアントでダウンタイムが発生しないようにすることはできません。クライアントがリクエストを処理できない時間が必ず発生するためです。ただし、複数の方法で、クライアントがリクエストを処理できない期間を最小化（ダウンタイムがほぼゼロ）することはできます。

クライアントを切り替えるよりもさらに前に、ターゲットデータベースに対して読み取り専用モードでアクセスをテストできます。このアプローチでは、テストは移行と同時に行われます。
切り替え期間が近づいたときに移行されるデータ（ソースデータベースとターゲットデータベース間で送信されるデータ）の量をできるだけ少なくするように構成できます。この手順によって、ソースデータベースとターゲットデータベースの差が小さくなるため、ドレインの時間を短縮できます。
新しいクライアントのターゲットデータベースへの接続を、既存のクライアントのソースデータベースへの接続と同時に開始できる場合、切り替えの時間を短縮できます。これは、新しいクライアントが、データがすべてドレインされた後にすぐにターゲットデータベースを利用できるようになるためです。

切り替え時のダウンタイムをゼロにすることは非現実的です。ただし可能な場合は、データ移行の実行と同時にアクティビティを開始することで、ダウンタイムを最小化できます。

一部のデータベース移行シナリオでは、大幅なダウンタイムが許容されます。通常、この許容範囲はビジネス要件に依存します。このように、大幅なダウンタイムが許容される場合はアプローチを簡素化できます。たとえば、同機種のデータベース移行では、データの変更が不要な場合があります。「エクスポートとインポート」や「バックアップと復元」が最適なアプローチです。異機種の移行においては、移行中にデータベース移行システムでソースデータベースシステムの更新を処理する必要がなくなります。

ただし、データベースの移行とフォローアップテストを行うのに十分な、許容範囲内のダウンタイムを確保する必要があります。このダウンタイムを明確に確立できない場合や、許容できないほど長い場合は、最小限のダウンタイムを伴う移行を計画する必要があります。

データベース移行のカーディナリティ

多くの場合、データベースの移行は単一のソースデータベースと単一のターゲットデータベースの間で行われます。その場合、カーディナリティは 1:1（直接マッピング）です。つまり、ソースデータベースが変更なしでターゲットデータベースに移行されます。

ただし、直接マッピング以外のものもあります。その他のカーディナリティには次のものがあります。

統合（n:1）。統合では、複数のソースデータベースからより少数のターゲットデータベース（または 1 つのターゲット）にデータを移行します。このアプローチは、データベース管理を簡素化したり、拡張可能なターゲットデータベースを導入したりする場合などに使用できます。
分散（1:n）。分散では、1 つのソースデータベースから複数のターゲットデータベースにデータを移行します。たとえば、地域データを含む大規模な集中型データベースを、複数の地域別のターゲットデータベースに移行する必要がある場合に、このアプローチを使用できます。
再分散（n:m）再分散では、複数のソースデータベースから複数のターゲットデータベースにデータを移行します。このアプローチは、ソースデータベースが異なるサイズのシャードにシャーディングされている場合に使用できます。再分散では、シャーディングされたデータが、シャードに対応する複数のターゲットデータベースに均等に分散されます。

データベース移行では、データの移行だけでなく、データベースアーキテクチャの再設計と実装が可能になります。

移行における整合性

データベース移行において、整合性があることが求められます。移行における整合性とは、次のことを意味します。

完全性。移行対象として指定されるすべてのデータは実際に移行されます。指定されるデータは、ソースデータベース内のすべてのデータか、データのサブセットです。
重複がない。各データは 1 回だけ移行されます。ターゲットデータベースに重複するデータが導入されることはありません。
正しい順序。ソースデータベースのデータ変更は、ソースデータベースで行われた変更と同じ順序でターゲットデータベースに適用されます。この点は、データの整合性を確保するために不可欠です。

移行の完了後、ソースデータベースとターゲットデータベースのデータ状態が同等であるかどうかが、移行の整合性を表す別の方法です。たとえば、リレーショナルデータベースの直接マッピングが行われる同機種の移行では、ソースデータベースとターゲットデータベースに同じテーブルと行が存在する必要があります。

すべてのデータ移行が、ソースデータベースのトランザクションをターゲットデータベースに順次適用することに基づいているわけではないため、移行の整合性を表すためのこの方法は重要になります。たとえば、大幅なダウンタイムが許容できる場合に、ソースデータベースをバックアップし、そのバックアップを使用してソースデータベースのコンテンツをターゲットデータベースに復元する場合があります。

アクティブ - パッシブ移行とアクティブ - アクティブ移行

主な分類基準は、ソースデータベースとターゲットデータベースの両方がクエリ処理の変更に対してオープンであるかどうかです。アクティブ - パッシブデータベース移行では、移行中にソースデータベースを変更できますが、ターゲットデータベースは読み取りのみ許可されます。

アクティブ - アクティブ移行では、移行中のソースデータベースとターゲットデータベースの両方への書き込みが許可されます。このタイプの移行では、競合が発生する可能性があります。たとえば、ソースデータベースとターゲットデータベースの同じデータ項目が意味的に競合するように変更された場合に、競合解決ルールを実行して競合を解決する必要がある場合があります。

アクティブ - アクティブ移行では、競合解決ルールを使用してすべてのデータ競合を解決できるようにする必要があります。それができない場合、データに不整合が生じる可能性があります。

データベース移行アーキテクチャ

データベース移行アーキテクチャは、データベース移行を行うために必要なさまざまなコンポーネントを記述します。このセクションでは、一般的なデプロイアーキテクチャを紹介し、データベース移行システムを個別のコンポーネントとして扱います。また、データ移行をサポートするデータベース管理システムの機能や、多くのユースケースで重要となる、機能以外に関するプロパティについても説明します。

デプロイアーキテクチャ

オンプレミスや別のクラウドなど、あらゆる環境にあるソースデータベースとターゲットデータベースの間でのデータベースの移行が考えられます。各ソースデータベースとターゲットデータベースは、異なる環境にあってもかまいません。すべてを同じ環境に配置する必要はありません。

次の図は、複数の環境が関与するデプロイアーキテクチャの例を示しています。

クラウドとオンプレミスのデータセンターが関与する移行アーキテクチャ。

DB1 と DB2 の 2 つはソースデータベースで、DB3 と Spanner はターゲットデータベースです。このデータベース移行では、2 つのクラウドと 2 つのオンプレミスデータセンターが関与します。矢印は呼び出し関係を表します。データベース移行サービスは、すべてのソースデータベースとターゲットデータベースのインターフェースを呼び出します。

ここで説明されていない特殊なケースとして、あるデータベースからそれと同じデータベースへのデータの移行があります。この特殊なケースでは、データベース移行システムをデータ変換の目的でのみ使用します。異なる環境の異なるシステム間でデータを移行するためには使用されません。

基本的に、データベースの移行には 3 つの方法があります。これらの方法について、このセクションで説明します。

データベース移行システムを使用する
データベース管理システムのレプリケーション機能を使用する
カスタムデータベース移行機能を使用する

データベース移行システム

データベース移行システムは、データベースの移行における中核です。データベース移行システムは、ソースデータベースから実際のデータ抽出を実行し、そのデータをターゲットデータベースに転送し、場合に応じて転送中にデータを変更します。このセクションでは、基本的なデータベース移行システムの機能全般について説明します。データベース移行システムの例として、Database Migration Service、Striim、Debezium、tcVision、Cloud Data Fusion などがあります。

データ移行プロセス

データ移行プロセスは、データベース移行システムの中核となる技術的構成要素です。データ移行プロセスはデベロッパーにより指定されるもので、データの抽出元となるソースデータベース、データの移行先となるターゲットデータベース、移行中にデータに適用されるデータ変更ロジックを定義します。

1 つ以上のデータ移行プロセスを指定し、移行のニーズに応じて順次的に実行することも、同時に実行することもできます。たとえば、独立したデータベースを移行する場合に、対応する複数のデータ移行プロセスを同時に実行できます。

データの抽出と挿入

データベースシステムでの変更（挿入、更新、削除）は、トランザクションログに基づいた、データベースでサポートされる変更データキャプチャ（CDC）と、データベース管理システムのクエリインターフェースを使用したデータ自体の差分クエリの 2 つの方法で検出できます。

トランザクションログに基づいた CDC

データベースでサポートされる CDC は、クエリインターフェースとは異なるデータベース管理機能に基づいています。このアプローチのうちの 1 つは、MySQL のバイナリログなど、トランザクションログに基づいています。トランザクションログには、データに加えられた変更が正しい順序で含められます。トランザクションログは継続的に読み取られるため、すべての変更をモニタリングできます。データベース移行において、このロギングが非常に役立ちます。CDC で各変更を表示し、正しい順序でデータの損失を発生させることなくターゲットデータベースにデータを移行できます。

CDC は、データベース管理システムの変更の取得で推奨されるアプローチです。CDC はデータベース自体に組み込まれており、システムへの負荷の影響が最も少ないアプローチです。

差分クエリ

すべての変更を正しい順序でモニタリングできるデータベース管理システム機能が存在しない場合は、代替手段として差分クエリを使用できます。このアプローチでは、データベース内の各データ項目に、タイムスタンプまたはシーケンス番号を含む追加の属性を付与します。データ項目が変更されるたびに、変更タイムスタンプが追加されるか、シーケンス番号が増分されます。ポーリングアルゴリズムが、最後にタイムスタンプが追加されたとき以降の、あるいは最後に使用されたシーケンス番号以降のすべてのデータ項目を読み取ります。ポーリングアルゴリズムにより変更が検出されると、現在の時刻またはシーケンス番号が内部状態に記録され、変更がターゲットデータベースに渡されます。

このアプローチは挿入と更新で問題なく機能しますが、削除の場合はデータ項目がデータベースから削除されるため、削除に関しては慎重に設計する必要があります。データが削除された後、ポーラーは削除が発生したことを検出できません。削除は、データが削除されたことを示す追加のステータスフィールド（論理削除フラグ）を使用して実装できます。また、削除されたデータ項目を 1 つ以上のテーブルに収集し、ポーラーでそれらのテーブルにアクセスすることで、削除が発生したかどうかを判定することもできます。

差分クエリのバリアントについては、変更データキャプチャをご覧ください。

差分クエリは、スキーマと機能の変更を伴うため、最も推奨されないアプローチです。データベースにクエリを実行すると、クライアントロジックの実行に関係のないクエリ負荷も追加されます。

アダプタとエージェント

データベース移行システムは、ソースとデータベースシステムにアクセスする必要があります。アダプタは、アクセス機能をカプセル化した抽象化機能です。最も単純な形式では、JDBC をサポートするターゲットデータベースにデータを挿入する JDBC ドライバをアダプタとして使用できます。より複雑なケースでは、アダプタはターゲット（エージェントとも呼ばれます）の環境で実行され、ログファイルなどの組み込みのデータベースインターフェースにアクセスします。さらに複雑なケースでは、アダプタやエージェントがさらに別のソフトウェアシステムと接続され、そこからデータベースにアクセスします。たとえば、エージェントが Oracle GoldenGate にアクセスし、そこから Oracle データベースにアクセスする場合などです。

ソースデータベースにアクセスするアダプタまたはエージェントは、データベースシステムの設計に応じて、CDC インターフェースまたは差分クエリインターフェースを実装します。どちらのケースでも、アダプタやエージェントによりデータベース移行システムに変更内容が提供されます。データベース移行システムは、変更が CDC と差分クエリのどちらによってキャプチャされたかを認識しません。

データの変更

一部のユースケースでは、データは変更されずにソースデータベースからターゲットデータベースに移行されます。これらのストレートスルーな移行は通常、同機種の移行になります。

しかし多くのユースケースでは、移行プロセス中にデータを変更する必要があります。通常、スキーマやデータ値に違いがある場合や、移行中にデータをクリーンアップする機会がある場合には、変更が必要です。

次のセクションでは、データ移行で必要となる可能性があるいくつかのタイプの変更（データの変換、データ拡充または相関、データの削減またはフィルタリング）について説明します。

データの変換

データの変換は、ソースデータベースの一部またはすべてのデータ値を変換します。以下はその一例です。

データ型の変換。ソースデータベースとターゲットデータベース間で、データ型が同等ではない場合があります。このような場合、データ型変換が型変換ルールに基づいてソース値をターゲット値にキャストします。たとえば、ソースのタイムスタンプ型がターゲットで文字列型に変換されることがあります。
データ構造の変換。データ構造の変換は、同じデータベースモデル内、または異なるデータベースモデル間の構造を変更します。たとえば、リレーショナルシステムで、1 つのソーステーブルが 2 つのターゲットテーブルに分割されたり、複数のソーステーブルが結合を使用して 1 つのターゲットテーブルに非正規化されたりすることがあります。ソースデータベースの 1:n 関係が、Spanner では親子関係に変換される場合があります。ソースドキュメントデータベースシステムのドキュメントが、ターゲットシステムでは一連のリレーショナル行に分解される場合があります。
データ値の変換。データ値の変換は、データ型の変換とは異なります。データ値の変換は、データ型を変更せずに値を変更します。たとえば、ローカルタイムゾーンが協定世界時（UTC）に変換される場合などがあります。また、文字列で表される短い郵便番号（5 桁）が、長い郵便番号（5 桁の後にダッシュと 4 桁が続く。ZIP+4 とも呼ばれる）に変換される場合もあります。

データの拡充と相関

データ変換は、追加の関連する参照データを参照せずに既存のデータに適用されます。データの拡充では、追加のデータがクエリされ、ソースデータがターゲットデータベースに格納される前に拡充されます。

データ相関。ソースデータは関連付けることができます。たとえば、2 つのソースデータベースの 2 つのテーブルのデータを組み合わせることができます。たとえば、顧客データと注文データを 2 つの異なるデータベースから取得し、顧客データをオープン、完了、キャンセル済みの 3 つの注文すべてに関連付け、単一のターゲットデータベースに格納できます。
データ拡充。データ拡充は参照データを追加します。たとえば、郵便番号のみを含むレコードに郵便番号と対応する市区町村名を追加することで、レコードを拡充できます。郵便番号と対応する市区町村名を含む参照テーブルは、このユースケースでアクセスされる静的データセットです。また、参照データは動的にすることもできます。たとえば、すべての既知の顧客のリストを参照データとして使用できます。

データの削減とフィルタリング

ターゲットデータベースに移行する前にソースデータを削減またはフィルタリングするデータ変換もあります。

データの削減。データの削減は、データ項目から属性を削除します。たとえば、データ項目に郵便番号が含まれていて、再計算できる、必要がなくなったなどの理由で対応する市区町村名が不要になった場合に、市区町村名を削除できます。またこの情報が、（年月を経て市区町村名が変わる場合でも）ユーザーが入力した市区町村名を記録するための履歴として保持されることもあります。
データのフィルタリング。データのフィルタリングは、データ項目を完全に削除します。たとえば、キャンセルされたすべての注文データを削除して、ターゲットデータベースに移行しないようにすることができます。

データの結合と再結合

データが異なるソースデータベースから異なるターゲットデータベースに移行される場合に、ソースデータベースとターゲットデータベースの間でデータを異なる方法で結合する必要性が生じることがあります。

たとえば、顧客データと注文データが 2 つの異なるソースデータベースに格納されているとします。片方のソースデータベースにはすべての注文データが含まれ、もう片方のソースデータベースにはすべての顧客データが含まれます。移行後、顧客データとその注文データは 1 つのターゲットデータベーススキーマ内で 1:n の関係で格納されます。ただし、1 つのターゲットデータベースではなく、それぞれにデータのパーティションが含まれる複数のターゲットデータベースに格納されます。各ターゲットデータベースはリージョンを表し、そのリージョン内のすべての顧客データとその注文データが含まれます。

ターゲットデータベースのアドレス指定

ターゲットデータベースが 1 つだけの場合を除き、移行する各データ項目は適切なターゲットデータベースに送信する必要があります。ターゲットデータベースのアドレス指定の方法には、次の 2 つがあります。

スキーマベースのアドレス指定。スキーマベースのアドレス指定は、スキーマに基づいてターゲットデータベースを決定します。たとえば、一連の顧客情報にあるすべてのデータ項目や顧客テーブルのすべての行は、複数のソースデータベースに分散されていたとしても、顧客情報を格納する同じターゲットデータベースに移行されます。
コンテンツベースのルーティング。コンテンツベースのルーターなどを使用して行うコンテンツベースのルーティングは、データ値に基づいてターゲットデータベースを決定します。たとえば、ラテンアメリカリージョンの顧客データのすべてを、そのリージョンを表す特定のターゲットデータベースに移行できます。

データベースの移行では、両方のアドレス指定方法を同時に使用できます。使用されるアドレス指定方法に関係なくデータ項目が格納されるように、ターゲットデータベースには正しいスキーマが必要です。

転送中データの永続性

データベース移行システム、あるいはそれらが実行される環境で移行中に障害が発生し、転送中のデータが失われる場合があります。障害が発生した場合は、データベース移行システムを再起動し、ソースデータベースに保存されているデータがターゲットデータベースに整合性のある形で完全に移行されているかを確認する必要があります。

復元の一環として、データベース移行システムで最後に正常に移行されたデータ項目を特定して、ソースデータベースからの抽出を開始する場所を決定する必要があります。障害が発生した時点から再開するには、システムで移行の進行状況に関する内部状態を保持する必要があります。

状態を保持する方法は複数あります。

データベースを変更する前に、抽出したすべてのデータ項目をデータベース移行システムに保存し、変更後のバージョンが正常にターゲットデータベースに保存された後にデータ項目を削除します。このアプローチにより、データベース移行システムは、どの項目が抽出され保存されているかを正確に特定できるようになります。
転送中のデータ項目への参照リストは保持できます。各データ項目の主キーなど、一意の識別子をステータス属性とともに保持することが 1 つの方法です。障害の発生後は、この状態がシステムを整合性のある形で復元するための基盤になります。
障害発生後にソースデータベースとターゲットデータベースにクエリを実行して、ソースデータベースシステムとターゲットデータベースシステムの違いを判断できます。次に抽出されるデータ項目を、この差に基づいて決定できます。

状態を保持する他の方法は、ソースデータベースによって異なります。たとえば、データベース移行システムでは、ソースデータベースから取得されるトランザクションログエントリや、ターゲットデータベースに挿入されるトランザクションログエントリをトラックできます。障害が発生した場合、最後に正常に挿入されたエントリから移行を再開できます。

転送中データの永続性は、エラーや障害以外の理由でも重要となります。たとえば、ソースデータベースのデータをクエリしてその状態を判断できない場合があります。たとえば、ソースデータベースにキューが含まれていた場合、そのキュー内のメッセージがいずれかの時点で削除された可能性があります。

転送中データの永続性のもう 1 つのユースケースは、データの大規模なウィンドウ処理です。データの変更中、データ項目を互いに独立して変換できます。ただし、データの変更が複数のデータ項目に依存している場合があります（たとえば、毎日 0 から開始され処理されるデータ項目の番号付け）。

転送中データの永続性の最後のユースケースは、データベースシステムがソースデータベースに再度アクセスできない場合のデータ変更中に、データの再現性を提供することです。たとえば、異なる変更ルールを使用してデータ変更を再実行し、その結果を検証して、初期のデータ変更と比較する必要がある場合があります。不適切なデータ変更のために生じたターゲットデータベースの不整合をトラックする必要がある場合、このアプローチが必要になることがあります。

完全性と整合性の検証

データベースの移行が完全で、整合性があることを確認する必要があります。このチェックにより、各データ項目が一度だけ移行され、ソースデータベースとターゲットデータベースのデータセットが同一であり、移行が完了していることを確認できます。

データ変更ルールによっては、データ項目が抽出されたとしてもターゲットデータベースに挿入されない場合があります。そのため、ソースデータベースとターゲットデータベースを直接比較することは、完全性と整合性を検証するための確実なアプローチにはなりません。ただし、データベース移行システムによりフィルタで除外された項目がトラックされている場合は、除外された項目を加味することでソースデータベースとターゲットデータベースを比較できます。

データベース管理システムのレプリケーション機能

同機種の移行における特殊なユースケースとして、ターゲットデータベースがソースデータベースのコピーである場合があります。具体的には、ソースデータベースとターゲットデータベースのスキーマが同じで、データ値が同じで、各ソースデータベースがターゲットデータベースに直接マッピング（1:1）される場合です。

この場合、ほとんどのデータベース管理システムに組み込まれているレプリケーション機能を使用して、データベースを別のデータベースに複製できます。

データレプリケーションには、論理と物理の 2 種類があります。

論理レプリケーション: 論理レプリケーションの場合、データベースオブジェクトの変更はレプリケーション識別子（通常は主キー）に基づいて転送されます。論理レプリケーションのメリットは、柔軟性が高く、きめ細かいこと、またカスタマイズできることです。場合によっては、論理レプリケーションを使用して、異なるデータベースエンジンバージョン間で変更を複製できます。多くのデータベースエンジンは論理レプリケーションフィルタをサポートしています。このフィルタでは、複製するデータセットを定義できます。主なデメリットは、論理レプリケーションではパフォーマンスのオーバーヘッドが生じる可能性があることです。また、このレプリケーション方法のレイテンシは通常、物理レプリケーションのレイテンシよりも高くなります。
物理レプリケーション: 一方、物理レプリケーションはディスクブロックレベルで動作し、レプリケーションレイテンシが低いため、パフォーマンスが向上します。大規模なデータセットの場合、特に非リレーショナルデータ構造の場合、物理レプリケーションはより簡単で効率的です。ただし、カスタマイズはできず、データベースエンジンのバージョンに大きく依存します。

レプリケーション機能には、MySQL レプリケーション、PostgreSQL レプリケーション（pglogical もご覧ください）、Microsoft SQL Server レプリケーションなどがあります。

ただし、データの変更が必要な場合や、直接マッピング以外のカーディナリティがある場合は、このようなユースケースに対処するためにデータベース移行システムの機能が必要です。

カスタムデータベース移行機能

データベース移行システムやデータベース管理システムを使用する代わりに、データベース移行機能を構築する理由には以下のようなものがあります。

あらゆる箇所を完全に制御する必要がある場合。
データベース移行機能を再利用したい場合。
コストの削減や、技術的なフットプリントの簡素化を行いたい場合。

移行機能を構築するための構成要素には、以下のものがあります。

エクスポートとインポート: 同機種のデータベースの移行でダウンタイムが問題にならない場合は、データベースのエクスポートとインポートを使用して、データを移行できます。ただし、エクスポートとインポートでは、データをエクスポートする前にソースデータベースを停止して更新を止める必要があります。そうしないと、変更がエクスポートでキャプチャされず、ターゲットデータベースがソースデータベースの正確なコピーにならない場合があります。
バックアップと復元: エクスポートとインポートの場合と同様に、バックアップと復元ではダウンタイムが発生します。バックアップにすべてのデータと最新の変更を含めるためにソースデータベースを停止する必要があるからです。このダウンタイムは、ターゲットデータベースで復元が正常に完了するまで続きます。
差分クエリ: データベーススキーマを変更できる場合に、スキーマを拡張して、クエリインターフェースでデータベースの変更を照会できるようにします。この場合、最後の変更時刻を示す追加のタイムスタンプ属性が付与されます。追加の削除フラグを加えて、データ項目が削除されたかどうか（論理削除）を表すこともできます。これら 2 つの変更を加えることで、一定間隔で実行されるポーラーで、最後にポーラーが実行された時点以降のすべての変更をクエリできます。これらの変更はすべてターゲットデータベースに適用されます。その他のアプローチについては、変更データキャプチャをご覧ください。

これらは、カスタムデータベース移行を構築するために利用できるオプションのごく一部です。カスタムソリューションは実装を最も柔軟に制御できますが、バグやスケーラビリティの制限など、データベースの移行中に発生する可能性がある問題に対処するための、定期的なメンテナンスが必要となります。

データベース移行に関するその他の考慮事項

以下のセクションでは、データベースの移行において重要な機能以外の点について簡単に説明します。これらの点として、エラー処理、スケーラビリティ、高可用性、障害復旧などがあります。

エラー処理

データベースの移行中に障害が発生しても、データが失われたり、データベースの変更処理の順序が変わったりすることはあってはなりません。データの整合性は、障害の原因（システムのバグ、ネットワークの中断、VM のクラッシュ、ゾーンの障害など）に関係なく保持されなければなりません。

データ損失は、移行システムがソースデータベースからデータを取得し、なんらかのエラーのためにターゲットデータベースに保存しない場合に発生します。データが失われた場合、ターゲットデータベースはソースデータベースと一致しないため、整合性がなく不完全になります。完全性と整合性の検証機能では、この状態にフラグが立てられます（完全性と整合性の検証）。

スケーラビリティ

データベースの移行において、移行時間は重要な指標です。ゼロダウンタイム（正確には最小のダウンタイム）の移行では、ソースデータベースが変更されている間にデータの移行が行われます。（特にソースデータベースシステムが大規模な場合に）適切な時間枠で移行するには、データ転送速度がソースデータベースシステムの更新速度よりも大幅に高速でなければなりません。転送速度が高いほど、データベースの移行を迅速に完了できます。

ソースデータベースシステムが停止していて変更されていない場合は、組み込む変更がないため、移行が速くなる可能性があります。同機種のデータベースでは、「バックアップと復元」機能や「エクスポートとインポート」機能を使用でき、またファイル転送がスケーリングされるため、移行時間を大幅に短縮できる場合があります。

高可用性と障害復旧

一般に、ソースデータベースとターゲットデータベースは高可用性向けに構成されています。プライマリデータベースには、障害発生時にプライマリデータベースとして昇格される、対応するリードレプリカがあります。

ゾーンに障害が発生した場合、ソースデータベースまたはターゲットデータベースは別のゾーンにフェイルオーバーするため、継続的に使用できます。データベースの移行中にゾーン障害が発生すると、ソースデータベースまたはターゲットデータベースの一部にアクセスできなくなるため、移行システムそのものが影響を受けます。移行システムは、障害発生後に実行される、新たに昇格したプライマリデータベースに再接続する必要があります。データベース移行システムが再接続されたら、移行そのものを復元して、ターゲットデータベース内のデータの完全性と整合性を確保する必要があります。移行システムは、再開する場所を確立するために、最後に行われた整合性のある転送を特定する必要があります。

実行されているゾーンにアクセスできなくなった場合など、データベース移行システム自体に障害が発生した場合、システムを復旧する必要があります。復旧アプローチの 1 つに、コールドリスタートがあります。このアプローチでは、データベース移行システムが運用ゾーンにインストールされ、再起動されます。移行システムで、障害発生前の最後の整合性のあるデータ転送を特定し、その時点から再開して、ターゲットデータベースのデータの完全性と整合性を確保できるようにすることが最も重要です。

データベース移行システムで高可用性が有効になっている場合は、フェイルオーバーを行い処理を続行できます。データベース移行システムのダウンタイムを短縮することが重要となる場合は、データベースを選択して高可用性を実装する必要があります。

データベース移行の復元という点において、障害復旧は高可用性と非常に似ています。別のゾーンで新しく昇格したプライマリデータベースに再接続する代わりに、データベース移行システムは別のリージョン（フェイルオーバーリージョン）のデータベースに再接続する必要があります。同じことがデータベース移行システムそのものにも当てはまります。データベース移行システムが実行されているリージョンにアクセスできなくなった場合、データベース移行システムは別のリージョンにフェイルオーバーし、最後に整合性のあるデータ転送が行われた時点から続行する必要があります。

注意点

ターゲットデータベースでデータの不整合を引き起こす可能性がある注意点がいくつかあります。よくある問題は次のとおりです。

順序の違反。スケールアウトによって移行システムのスケーラビリティが実現されている場合、複数のデータ転送プロセスが同時に（並行で）実行されます。ソースデータベースシステムの変更は、commint されたトランザクションに応じて順序付けられます。トランザクションログから変更が取得される場合は、移行全体を通じてその順序が保持される必要があります。並列データ転送では、基盤のプロセス間で速度が異なるため、順序が変わる可能性があります。データがソースデータベースから受信される順序と同じ順序でターゲットデータベースに挿入されるようにする必要があります。
整合性の違反。差分クエリの場合、ソースデータベースには commit タイムスタンプなどを含む追加のデータ属性が付与されています。commit タイムスタンプは、ソースデータベースでチェンジマネジメントを行うためにのみ使用されるため、ターゲットデータベースには commit タイムスタンプがありません。ターゲットデータベースに挿入されるデータが、タイムスタンプの点で整合性のある状態にすることが重要です。つまり、同じタイムスタンプを持つすべての変更が、同じ insert、update、upsert トランザクション内にある必要があります。そのようにしない場合、一部の変更が挿入され、同じタイムスタンプを持つ他の変更が挿入されない状況が発生し、ターゲットデータベースの状態が一時的に不整合な状態になる可能性があります。この一時的な不整合状態は、ターゲットデータベースが処理のためにアクセスされない場合は問題になりません。ただし、ターゲットデータベースがテストで使用される場合は、整合性が最も重要になります。別の側面は、ソースデータベースでのタイムスタンプ値の作成と、それらが設定されているトランザクションの commit 時間との関係です。トランザクションの commit の依存関係のため、タイムスタンプが早いトランザクションは、タイムスタンプが遅いトランザクションの後に表示される可能性があります。2 つのトランザクション間で差分クエリが実行された場合、タイムスタンプが古いトランザクションは確認されないため、ターゲットデータベースで不整合が発生します。
データの欠落や重複。フェイルオーバーの発生時、プライマリとフェイルオーバーレプリカの間で一部のデータが複製されない場合、慎重に復元する必要があります。たとえば、ソースデータベースがフェイルオーバーしていて、すべてのデータがフェイルオーバーレプリカに複製されていないとします。また、データは障害が発生する前にターゲットデータベースにすでに移行されているとします。フェイルオーバー後に新たに昇格したプライマリデータベースは、ターゲットデータベースに加えられたデータ変更の点で遅れています（フラッシュバックと呼ばれます）。移行システムでこの状況を認識し、ターゲットデータベースとソースデータベースで整合性のとれた状態に戻るように復元する必要があります。
ローカルトランザクション。ソースデータベースとターゲットデータベースに同じ変更を適用する場合、データ移行システムを使用せずに、ソースデータベースとターゲットデータベースの両方に書き込む方法が一般的です。このアプローチにはいくつかの注意点があります。1 つ目の注意点は、2 つのデータベース書き込みが 2 つの別々のトランザクションであるということです。1 つ目の書き込みが終了してから 2 つ目が終了するまでに障害が発生する可能性があります。このシナリオではデータの整合性が失われるため、そこから復元する必要があります。また、たいていの場合クライアントは複数存在しており、クライアント同士に連係はありません。クライアントはソースデータベーストランザクションの commit 順序を把握できないため、そのトランザクション順序を反映しているターゲットデータベースに書き込むことはできません。クライアントにより順序が変更される可能性があり、これによりデータの不整合が発生する可能性があります。すべてのアクセスが連係のあるクライアントを経由していて、すべてのクライアントがターゲットトランザクションの順序を把握できる場合を除き、このアプローチではターゲットデータベースとの不整合が発生する可能性があります。

他にも、一般的な注意点があります。データの不整合につながる可能性のある問題を見つける最適な方法は、考えられるすべての障害シナリオを繰り返す完全な障害分析を行うことです。データベース移行システムで同時実行が実装されている場合、考えられるすべてのデータ移行プロセスの実行順序を調べて、データの整合性が維持されるようにする必要があります。高可用性や障害復旧（あるいはその両方）が実装されている場合は、考えられるすべての障害の組み合わせを調べる必要があります。

次のステップ

データベースの移行: コンセプトと原則（パート 2）を読む。
データベースの移行については、次のドキュメントをご覧ください。
データベースの移行で、その他のデータベースへの移行方法を確認する。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターをご覧ください。