デベロッパー

新しい Database Migration Service でリフト&シフトの負担を軽減

※この投稿は米国時間 2021 年 4 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

「データベースの移行は楽しい」- なんて誰も言わない

No one ever.

データベースをプラットフォーム間で移動する際には、多大な負担がかかります。Google Cloud へのリフト&シフトを実行する場合、次に示すような複雑性に対処する際に、クラウド機能を活用する効率が低下します。

  1. 安全かつ効率的に(ダウンタイムを管理しながら)データを移行するための移行戦略を考案

  2. 移行の影響を評価

  3. データベースを準備

  4. 保護された接続を設定

  5. データ レプリケーション

  6. 移行検証

それ以外にも、データベースのコードを新しいエンジン用に書き換えたり、アプリケーションを書き換えたりする手作業や、パフォーマンスへの影響などを深く検証を行う場合もあります。

言うまでもなく、クラウドへの移行は、多くの流動的な要素や、VPN などのインフラストラクチャやセキュリティ要件を考慮するネットワーク管理者など多くの人員が関与する複雑なプロセスです。多くの DBA は、データベースを移行する際の最大のリスクの一つがダウンタイムであると理解していて、企業がクラウド移行という難作業を避ける大きな理由になっています。通常の流れとしては、アプリケーションをシャットダウンし、現在のデータベース スキーマのバックアップを作成し、移行ツールを使用して必要なすべての更新操作を行い、アプリケーションを再起動してから、すべてがうまく動作するよう願います。

ですが、ダウンタイムを許容できない場合、状況は変わります。たとえば、PostgreSQL ユーザーは非常に大きなデータベースを持っていることが多く、何時間ものダウンタイムに直面することになりますが、これはほとんどの企業にとって現実的ではありません。

迅速化手段としての移行ツール

ある種類のデータベースから別のデータベースにデータを移動したり、データ ウェアハウスやデータレイクのような別の目的地にデータを移動したりすることに役立つツールがいくつも用意されています。重要なデータセット(データベース全体)を移動するには、データ レプリケーションの処理を簡単にでき、セキュリティを強化した最新のクラウドベースの移行ツールが必要です。AloomaMatillionSnaplogic といったクラウドベースの移行ツールがありますが、クラウド移行ツールはソースシステムとターゲット システムの両方とうまく統合し、最小限の労力、ダウンタイム、オーバーヘッドでデータベースを移行する必要があることも Google は理解しています。

Alooma は 2019 年に Google Cloud に加わりました。これによって、Google Cloud の技術に強化された完全なセルフサービスのデータベース移行エクスペリエンスの実現に一歩近づきました。Alooma は、複数のソースから単一のデータ ウェアハウスへのデータ移行を簡素化するデータ パイプライン ツールにより、クラウド上でのデータベースの移行を効率化し、エンタープライズ企業を支援します。Alooma とそのエンタープライズおよびオープンソースのデータベースに関する専門知識が加わったことで、Google Cloud に重要な移行機能が追加されました。そして 2020 年 11 月、Google Cloud は、ユーザー フレンドリーで高速かつ信頼性の高い Cloud SQL への移行方法を求める最新のニーズに応えるための Google のビジョンの一環として、サーバーレスの新しい Database Migration Service(DMS)を発表しました。Alooma は、データ エンジニアが分析用のクラウド データ ウェアハウスへの柔軟なストリーミング データ パイプラインを構築するための ETL プラットフォームであるのに対し、DMS は、DBA や IT プロフェッショナルがより大きな移行目標の一環としてデータベースをクラウドに移行するためのデータベース移行サービスです。

Database Migration Service の一般提供を開始

Database Migration Service を使用することで、データを簡単に Google Cloud に移行できます。このサービスは、MySQL と PostgreSQL のワークロードを Cloud SQL にリフト&シフトするためのフルマネージド サービスです。オンプレミス、Google Cloud の自己ホスト、他のクラウドから移行することができ、Cloud SQL のメリットを直接得ることができます。DMS では、データベース スキーマ、メタデータ、データ自体の移行を管理することに重点を置いています。このサービスは、ネットワークのワークフローを合理化、最初のスナップショットと継続的なレプリケーションを管理、移行作業の進捗状況を可視化、1 回限りの移行および継続的な移行をサポートします。これらの機能によって、最小限のダウンタイムでカットオーバーできます。

一度には覚えられないかと思いますので、ここでは 3 つの主要ポイントをご紹介します。

  1. DMS では、移行のすべての手順をガイドする、シンプルで統合されたエクスペリエンスを得ることができます(評価および移行を実行するためのツールをまとめただけではありません)。

  2. DMS はサーバーレスです。移行を実行するインスタンスを展開、管理、モニタリングする必要はありません。適切なサイジングを決定する、インスタンスをモニタリングする、コンピューティングとストレージが十分であることを確認する責任は、Google Cloud にあります。サーバーレスで移行することにより、予期せぬ事態を回避し、規模が大きくてもパフォーマンスを維持します。

  3. 無料でご利用いただけます。

MySQL

次のソース データベースをサポートしています。

  • AWS RDS 5.6、5.7、8.0

  • セルフマネージド(オンプレミス上または任意のクラウド VM 上)の 5.5、5.6、5.7、8.0

  • Cloud SQL 5.6、5.7、8.0

  • Amazon Aurora 5.6、5.7

次の移行先データベースをサポートしています。

  • Cloud SQL for MySQL 5.6、5.7、8.0

PostgreSQL

次のソース データベースをサポートしています。

  • RDS 9.6.10+、10.5+、11.1+、12

  • セルフマネージド(オンプレミス上または任意のクラウド VM 上)の 9.4、9.5、9.6、10、11、12、13

次の移行先データベースをサポートしています。

  • PostgreSQL

Cloud SQL のデベロッパー アドボケイトである Gabe Weiss は、さまざまな移行シナリオ、DMS の仕組み、移行のために Postgres インスタンスを準備する方法などを詳しく説明しています。Weiss のコンテンツや、同種移行に関するベスト プラクティスをご覧ください。ここでは、新しい移行ジョブに関する DMS の基本機能を簡単にご説明します。

DMS を体験する

DMS には、Google Cloud Console の [データベース] からアクセスできます。まず始めに、移行ジョブを作成します。これは、ソース データベースを Cloud SQL の移行先に移行するエンドツーエンドのプロセスを表しています。

移行ジョブを定義する

まず、ジョブがどのような移行を実行するのかを明確にしましょう。Google Compute Engine で運用している MySQL データベースを、Cloud SQL に移行したいと考えています。1 回限りのレプリケーションか、継続的なレプリケーションかを選択できます。ダウンタイムを最小限とするために、今回は継続的なレプリケーションを選択します。ジョブを定義すると、DMS はソース データベースに接続して移行するために必要なソースと接続性の設定を表示します。

dms

DMS では、UI で前提条件を直接示すことで、必要なことを明確に説明しています。

b
*この手順は必ず行ってください。これらの前提条件を確認することで、接続性テストの際に頭を悩ませる必要がなくなります。

ソースを定義する

まず、データベースに接続するために必要な情報を表すリソースである接続プロファイルを作成する必要があります。これらのプロファイルは、個々の移行に固定されるものではありません。つまり、移行を最初にテストする場合や、組織内の他の人がデータベースへの接続を担当する場合に再利用できるのです。

  • 自己ホスト型のデータベースからレプリケーションを行う場合は、ホストにアクセスするためのホスト名または IP アドレス(ドメインまたは IP)とポートを入力します。

  • Cloud SQL データベースからレプリケーションを行う場合は、プルダウン リストから Cloud SQL インスタンスを選択します。

mj

移行先の作成

次のステップでは、データベースの移行先となる Cloud SQL インスタンスを作成します。Cloud SQL インスタンスを作成したことがある方にはおなじみの内容でしょう。接続性やマシンの構成など、同じオプションがいくつも表示されます。DMS は Database Engine のレプリケーション技術に依存しているため、Cloud SQL インスタンス以外のリソースを作成する必要はありません。

mt

ソースをターゲットに接続する

接続性の確立は非常に難しいと思われていますが、ここでは違います。ソース データベースの種類や場所に応じて、接続方法を次の 4 種類から選択できます。

  • IP 許可リスト - ソース データベースが Google Cloud の外部にある場合に使用します。

  • リバース SSH トンネル - プロジェクト内の VM でリバース SSH トンネルによるプライベート接続を設定するために使用します。

  • VPN 経由の VPC - ソース データベースが VPN の内部(AWS やオンプレミスの VPN など)にある場合に使用します。

  • VPC ピアリング - ソース データベースが Google Cloud の同じ VPC にある場合に使用します。

cm

今回のソース VM は Google Cloud にあるため、VPC ピアリングを設定しました。ピアリングを設定する際には、特定のサービスに必要なネットワーク構成を自動的に管理する Service Networking API を必ず有効にしてください。

移行ジョブを検証する

これで完了です。ソースを設定し、Cloud SQL の移行先を作成して、両者の間に接続を確立しました。残る作業は、移行ジョブの設定を検証して、移行を開始することだけです。ジョブの検証が終われば、移行が円滑に実行されると確信が得られます。

cmj
tm

すぐにジョブを開始して実行できます。移行ジョブが開始されると、その進捗状況をモニタリングして、問題が発生していないかどうかを確認できます。DMS は、まず既存のデータの最初のスナップショットを転送し、その後、変更があった場合は継続的に複製します。

最初のスナップショットが移行され、継続的なレプリケーションが維持されている場合、Cloud SQL インスタンスをプライマリ インスタンスとしてプロモートして、アプリケーションを直接そのインスタンスに対して動作させることができます。

tmj

DMS は、プロセスを順番に案内し、柔軟なオプションを使用してソースと Cloud SQL インスタンス間の接続を管理します。移行をテストすることで、最小限のダウンタイムでマネージド Cloud SQL インスタンスに移行する確実な方法を得られます。DMS はサーバーレスで高いパフォーマンスを発揮し、無料で使用できます。お試しになりたい方は、クイックスタートおよび移行ソリューション ガイドをご覧になり、ご意見やフィードバックをお聞かせください。

SQL Server の移行について詳細を確認する場合は、SQL Server のプレビューに参加するためのアクセスを要求できます。

Twitter(@stephr_wong)もご覧ください。

Stephanie Wong, Developer Advocate