データ マイグレーション パターン
本節では、データのマイグレーション パターンについて解説します。他の環境から Google Cloud へ移行する場合、どのような方法でデータを持ってくるのかは、重要な事項です。移行要件に応じて、どのような方法を選択できるのかを整理する必要があります。ここでは、データの特性や保管するデータベース、ストレージの種類に応じたマイグレーション パターンを記載します。
RDBMS データ マイグレーション パターン
解決する課題・使い所
ここでは、RDBMS のデータを Google Cloud へ移行するためのパターンを紹介します。RDBMS のデータを移行する上で考慮する必要があるのは、以下のポイントです。
- 同種データベース へのデータ移行
同種データベース移行とは、同じデータベース テクノロジーを使用するソース データベースとターゲット データベースの間のデータの移行です。例えば、PostgreSQL データベースから Compute Engine 上に構築した PostgreSQL データベースへの移行、MySQL データベースから Cloud SQL for MySQL への移行などです。
- 異種データベース へのデータ移行
異種データベース移行とは、異なるデータベース テクノロジーを使用するソース データベースとターゲット データベースの間のデータの移行です。たとえば、Oracle データベースから Cloud SQL for PostgreSQL への移行、Oracle データベースから Spanner への移行などです。本項では対象外としますが、異種データベースへの移行にはスキーマの変換、アプリケーションポーティング（SQL の書き換えなど）といったデータ移行以外の考慮事項もあるのでご注意ください。
- ダウンタイムの短縮
データを移行する際にはダウンタイムへの考慮が必要となります。本項では、よりダウンタイムを短くするパターンや、それぞれのパターン内でダウンタイムを短くするための考慮事項を記載します。
- Google Cloud でのデータベース ソリューションの選択
Google Cloud では様々なデータベース ソリューションが提供されています。本項では、OLTP ワークロードを処理する RDBMS を Google Cloud へ移行する際の代表的なソリューションの選択指針を記載します。
アーキテクチャ
ここでは、はじめに、OLTP ワークロードを処理する RDBMS を Google Cloud へ移行する際の代表的なソリューションを紹介します。その上で、そのデータ移行パターンを整理します。
RDBMS を Google Cloud へ移行する際の選択肢
OLTP ワークロードを処理する RDBMS を Google Cloud へ移行する場合、以下の 3 つが代表的な選択肢となります。
- RDBMS を Compute Engine に構築して運用
- マネージドサービス（Cloud SQL）の利用
- マネージドサービス（Cloud Spanner）の利用
導入作業や運用の負担軽減の観点から「マネージド サービスの利用」が推奨されますが、マネージド サービス特有の制限などから「RDBMS を Compute Engine に構築して運用」を選択するケースもあります。以下に、各ソリューションを選択する代表的な指針を示します。
- RDBMS を Compute Engine に構築して運用
- 極力現状の運用手法を維持したい
- OS に対しての操作が必要となる
- Cloud SQL でサポートされていない RDBMS、バージョンを選択したい
- Cloud SQL でサポートされていないエンジン固有の機能、オプション、拡張モジュールを使いたい
- Cloud SQL でサポートされるマシンリソース（CPU, メモリ、ストレージ）では、要件を満たせない
- メンテナンス時間を極力ユーザ側でコントロールしたい
- マネージドサービス（Cloud SQL）の利用
- 導入作業の負担を軽減したい
- 運用の負担を軽減したい
- 高可用性設定
- ストレージの自動スケール
- 自動バックアップ
- 自動メンテナンス
- リードレプリカによる読み取り性能向上 （Cloud Spanner の利用と比べて）移行の工数を抑えたい
- これまで利用してきたデータベース エンジンを利用したい
- 移行によりアプリケーションへの影響範囲を小さくしたい
- マネージド サービス（Cloud Spanner）の利用
- 高いスケーラビリティが必要である
- マルチリージョン レベルの高い可用性が必要である
- メンテナンスによるダウンタイムを無くしたい
- Cloud Spanner のメリットを教授するため、アプリケーションの見直しや書き換えを許容できる
データ移行パターンとそのアーキテクチャ
ここでは RDBMS のデータ移行パターンを分類し、それぞれのパターンに応じたアーキテクチャを図示します。なお Google Cloud ではサードパーティソフトウェアを利用した移行も可能ですが、ここでは Google Cloud のサービス自体の機能と RBDMS 自体の機能で可能な方法についてのみ言及します。
以下にデータ移行パターンを示します。RDBMS の移行方法は、同じデータベースへの移行であるか、異種データベースへの移行であるかによって異なります。同じデータベースの移行である場合は、移行のダウンタイムに関わる要件などによってさらに 2 つの選択肢があります。十分なダウンタイムを許容できる、あるいは、シンプルでより堅実な移行を実施したい場合は、「エクスポート / インポート移行」となり、できる限りダウンタイムを短くしたい場合は「レプリケーション」となります。異種データベースの移行の場合、「CSV アンロード / ロード」となります。
同種データベースの移行
(1)エクスポート / インポート移行
エクスポート / インポート移行では、RDBMS で提供されるダンプコマンド（例：PostgreSQL の pg_dump、MySQL の mysqldump など）を使用して、ソース データベース のデータをエクスポートします。次に、このデータをターゲット データベース管理レイヤに直接インポートします。これには通常、すべてのデータの同期を維持するために、移行期間の全体を通じてデータベースにダウンタイムが必要です。
- Cloud SQL
Cloud SQL は、Cloud Storage からダンプファイルをインポートすることが可能です。そのため、ダンプファイルを Cloud Storage へ転送し、Cloud SQL へインポートします。 - Compute Engine
Compute Engine 上の RDBMS へダンプファイルをインポートする場合、Compute Engine 自体にダンプファイルを転送してインポートします。
（2）レプリケーション
レプリケーションによる移行では、RDBMS でサポートされるレプリケーション技術を利用して、ソース データベースからターゲット データベースにデータを連続的に転送します。この方法では、ターゲット データベースとソース データベースの同期が完了したら、アプリケーションの接続先をターゲット データベースに切り替えることで、ダウンタイムは短くなります。ただし、ソース データベースに対する変更量が非常に多い場合、ターゲット データベースへの同期が追いつかなくなる可能性もあるので事前の検証が重要になります。
- Cloud SQL
Cloud SQL では外部のデータベース サーバーとのレプリケーションを構成することができます（2020/10/16 現在 Cloud for MySQL でサポート）。これにより、ソース データベースのデータを同期し、レプリカとなっている Cloud SQL をプロモートして移行を完了させることができます。 - Compute Engine
Compute Engine 上の RDBMS へレプリケーションする場合、RDBMS でサポートされるレプリケーション技術を使用します。これにより、ソース データベースとのレプリケーションを構成し、レプリカとなっている Compute Engine 上のデータベース をプロモートして移行を完了させることができます。 - Cloud Interconnect
Cloud Interconnect は、オンプレミス ネットワークと Google Cloud Virtual Private Cloud（VPC）ネットワークの間を専用接続で通信させるサービスです。レプリケーションによる移行では、データ転送中のネットワークについての考慮が必要です。Cloud Interconnect を利用することでより一貫した通信が期待できます。
異種データベースの移行
（1）CSV アンロード / ロード
異種データベースの移行では特定のデータベースに依存した形式のダンプファイルが利用できません。そのため、CSV ファイルでソース データベースからデータをアンロードし、ターゲット データベースへロードします。
- Cloud SQL
Cloud SQL は、Cloud Storage から CSV ファイルをインポートすることが可能です。そのため、CSV ファイルを Cloud Storage へ転送し、Cloud SQL へインポートします。 - Compute Engine
Compute Engine 上の RDBMS へ CSV ファイルをインポートする場合、Compute Engine 自体に CSV ファイルを転送してインポートします。
利点
- エクスポート / インポート移行
- 設定など移行に伴う作業が最もシンプルであるため、移行の負担が小さい。
- レプリケーション
- 移行に伴うダウンタイムを最小化できる。
- CSV アンロード / ロード
- 異種データベースのデータベースに移行できる。
注意事項
- データ移行では事前の検証が重要です。検証により選択したソリューションで要件を満たせるか、万が一の場合の切り戻しのタイミングなどを確認します。
- 移行を一度に実施する「一括移行」か、初期データを事前にロードしておき、その後最新データをロードあるいは、レプリケーションさせる「段階的移行」かを選択することが可能です。最後の移行作業にかかる時間やダウンタイムを短くしたい場合、「段階的移行」が推奨されます。
- 「段階的移行」において、事前にロードするとよいのは、変更の少ないマスタデータや更新日時などのカラムを持っており、事前ロード後に変更された最新データを抽出することができるテーブルです。
- ビジネス要件上、許容できるダウンタイムは、ソリューションの選択に影響を与えます。各ソリューションのダウンタイムを考慮する際は、データのロード時間やソース データベースとターゲット データベースの接続先切り替え時間だけではなく、移行後のデータのテスト（データの漏れがないかなどの確認）にかかる時間の考慮も必要です。
- 非常に大きいサイズのデータを転送する場合や、レプリケーションを実施する場合は、ネットワークに関する考慮も必要です。一貫したネットワークが必要な場合、Cloud Interconnect の利用も検討しましょう。
- 特にソース データベースをアクティブにしたまま移行するレプリケーションを実施する場合、ソース データベースに対する負荷に注意してください。ソース データベースのリソースが逼迫する可能性がある場合、事前にソース データベースに対するアクセスを制限するなどの考慮が必要です。
- 利用する RDBMS でデータロードを並列プロセス / スレッドで行える機能がある場合は、データ移行の時間を短縮させるために利用を検討します。
- データ移行の時間を短縮させるために、データのインポート / レプリケーション中はターゲット データベースの設定にも注意が必要です。例えば、バックアップなどの設定を一時的にオフにするなど、ターゲット データベースのリソースを消費する可能性のある要素を排除します(移行完了後に設定を行い、運用に備えます)。
- Cloud SQL へのレプリケーションに対応しているのは、2020/10/16 現在 Cloud for MySQL のみです。