データ マイグレーション パターン   

本節では、データのマイグレーション パターンについて解説します。他の環境から Google Cloud へ移行する場合、どのような方法でデータを持ってくるのかは、重要な事項です。移行要件に応じて、どのような方法を選択できるのかを整理する必要があります。ここでは、データの特性や保管するデータベース、ストレージの種類に応じたマイグレーション パターンを記載します。

RDBMS データ マイグレーション パターン

解決する課題・使い所

ここでは、RDBMS のデータを Google Cloud へ移行するためのパターンを紹介します。RDBMS のデータを移行する上で考慮する必要があるのは、以下のポイントです。

アーキテクチャ

ここでは、はじめに、OLTP ワークロードを処理する RDBMS を Google Cloud へ移行する際の代表的なソリューションを紹介します。その上で、そのデータ移行パターンを整理します。

RDBMS を Google Cloud へ移行する際の選択肢

OLTP ワークロードを処理する RDBMS を Google Cloud へ移行する場合、以下の 3 つが代表的な選択肢となります。

導入作業や運用の負担軽減の観点から「マネージド サービスの利用」が推奨されますが、マネージド サービス特有の制限などから「RDBMS を Compute Engine に構築して運用」を選択するケースもあります。以下に、各ソリューションを選択する代表的な指針を示します。

データ移行パターンとそのアーキテクチャ

ここでは RDBMS のデータ移行パターンを分類し、それぞれのパターンに応じたアーキテクチャを図示します。なお Google Cloud ではサードパーティソフトウェアを利用した移行も可能ですが、ここでは Google Cloud のサービス自体の機能と RBDMS 自体の機能で可能な方法についてのみ言及します。

以下にデータ移行パターンを示します。RDBMS の移行方法は、同じデータベースへの移行であるか、異種データベースへの移行であるかによって異なります。同じデータベースの移行である場合は、移行のダウンタイムに関わる要件などによってさらに 2 つの選択肢があります。十分なダウンタイムを許容できる、あるいは、シンプルでより堅実な移行を実施したい場合は、「エクスポート / インポート移行」となり、できる限りダウンタイムを短くしたい場合は「レプリケーション」となります。異種データベースの移行の場合、「CSV アンロード / ロード」となります。

同種データベースの移行

（1）エクスポート / インポート移行

エクスポート / インポート移行では、RDBMS で提供されるダンプコマンド（例：PostgreSQL の pg_dump、MySQL の mysqldump など）を使用して、ソース データベース のデータをエクスポートします。次に、このデータをターゲット データベース管理レイヤに直接インポートします。これには通常、すべてのデータの同期を維持するために、移行期間の全体を通じてデータベースにダウンタイムが必要です。

（2）レプリケーション

レプリケーションによる移行では、RDBMS でサポートされるレプリケーション技術を利用して、ソース データベースからターゲット データベースにデータを連続的に転送します。この方法では、ターゲット データベースとソース データベースの同期が完了したら、アプリケーションの接続先をターゲット データベースに切り替えることで、ダウンタイムは短くなります。ただし、ソース データベースに対する変更量が非常に多い場合、ターゲット データベースへの同期が追いつかなくなる可能性もあるので事前の検証が重要になります。

異種データベースの移行

（1）CSV アンロード / ロード

異種データベースの移行では特定のデータベースに依存した形式のダンプファイルが利用できません。そのため、CSV ファイルでソース データベースからデータをアンロードし、ターゲット データベースへロードします。

利点


注意事項


関係するデザインパターン


参照ドキュメント