同種データベースの移行のためのベスト プラクティス
Google Cloud Japan Team
※この投稿は米国時間 2020 年 11 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。
Google Cloud へのアプリケーションの移行は、バッキング データベースも Google Cloud に移行すると最も効果的です。結果として、パフォーマンスの向上と費用の低減がもたらされ、管理と運用が容易になります。
これらの移行をさらに容易にするため、Google は新たに Database Migration Service（DMS）を発表しました。これは、使いやすいサーバーレス移行ツールで、Cloud SQL for MySQL（プレビュー中）と Cloud SQL for PostgreSQL（非公開プレビュー中 - ご登録はこちらから）への最小のダウンタイムでのデータベースの移行を可能とします。
DMS は現在、同種の移行を対象としています。つまり、移行元から移行先へのスキーマなどの変換を必要としない、互換性のあるデータベース エンジン間の移行です。この場合、移行の目標は、移行されるデータベースを移行元データベースのコピーに可能な限り近づけながら、Cloud SQL の移行先で使用できるようにすることです。
このブログでは、Cloud SQL for MySQL に同種のデータベースを移行するためのベスト プラクティス、および DMS を使った安全で簡単なデータベースの方法について概説します。
Database Migration Service の利点
DMS は、サーバーレス サービスとして同種のデータベースの移行をサポートします。データベース エンジンの独自のネイティブなレプリケーション技術を活用して、DMS は、移行元から移行先への継続的なレプリケーションをサポートします。これによりデータベースが常に同期されるため、転送するデータの忠実性を最大限向上できます。最小限のダウンタイムでカットオーバーを行うことができるため、新しい Cloud SQL インスタンスで自分のアプリケーションを使用可能です。
DMS は、いくつかの主要な機能を使用してデータベースの移行を簡素化し、信頼性を高めています。
ガイド付きで、検証された設定フロー移行ジョブ作成フローには、組み込みソース構成ガイダンスおよび安全な接続サポート（以下のスクリーンショットを参照）という独自の機能があり、移行の設定時の特に複雑な操作で役立ちます。フローの中で、設定と構成を検証することで、データベースの移行の設定が問題なく確実にできるようにします。
接続プロファイルのモジュール化と再利用。移行元データベースへの接続は別個に指定されるため、定義、テスト、実行の各フェーズを通じて再利用でき、構成値を再入力する必要はありません。これにより、チーム間のオーナー権限の分離も可能となり、接続の定義と移行の実行の担当者が分離されます。
モニタリングされるネイティブな移行。 DMS は、オープンソース データベース独自のネイティブなレプリケーション技術を利用し、信頼性と忠実性の高い移行を実現します。移行中は、移行の遅延のトラッキングを含め、UI と API を介してモニタリングできます（下の 2 番目のスクリーンショットをご覧ください）。
移行リソースの自動管理。サーバーレス サービスとして、必要な移行リソースは DMS によって自動的に管理されます。ユーザーによるプロビジョニングや管理が必要なリソースはなく、移行ごとに異なるリソースのモニタリングも不要です。
DMS のユーザー インターフェースでは、移行ジョブを構造化されたプロセスで作成できます。
Database Migration Service を使用した移行の工程
データベースを移行する際の全工程をフェーズごとに説明し、そのプロセスで DMS を活用する方法に関するガイダンスを提示します。
評価と計画
データベースの移行における評価フェーズの目的は、Google Cloud への移行の候補として特定した移行元データベースを収集し、確認することです。次の計画フェーズでは全体の移行計画を作成します。計画に含まれるタスクは、移行ジョブの実装とテスト、本番環境データベースの実際の移行（データベースのプロモーションとアプリケーションのカットオーバーを含む）などです。
この投稿では、DMS を使用したデータベースの移行を中心に説明し、データベースにアクセスするアプリケーションの移行については扱いません。アプリケーションの移行について詳しくは、Google Cloud ソリューションへの移行をご覧ください。
移行元データベースの評価
一般的なデータベースの移行では、アプリケーションが複数のデータソースを利用したり、複数のアプリケーションが相互関連したりすることがあるため、複数のデータベースが一緒に移行されます。このプロセスの最初のステップは、1 回の移行に含めるすべてのデータベースを収集することです。データベースのそれぞれについて、それが Google Cloud 内の同じ互換性のあるデータベース エンジンへの同種移行で、DMS の現行の機能に適合するかどうかを判定します。
分析において特に重要な点は次のとおりです。
前提条件。データベースを移行するには、特定の要件を満たす必要があります。たとえば、特定の移行元データベースの構成を実行し（例: バイナリ ロギングの有効化）、組織のセキュリティ体制と要件に適合するネットワーク接続を準備することなどが必要です。プロセスを合理化して移行の設定を簡素化するため、Database Migration Service で移行元の構成とネットワーク設定を変更すると、これらの要件を満たすことができます。
サイズ。移行のスケジュールを計画する際の情報となるデータベースのサイズを特定します。データベースが大きいほど、最初のスナップショットの移行、本番環境の Google Cloud への移行の一環として行う移行テストにかかる時間が増加します。
以下の説明では、わかりやすくするため、1 つのデータベースのみを使用します。複数のデータベースを移行する場合、移行に関するすべてのタスクは、データベースごとに並行して実施できます。
データベース移行計画
データベース移行計画の目的は、移行を本番環境プロモーションまで問題なく実施するために必要なすべてのタスクのリストを作成することです。時系列のプロジェクト計画により、さまざまなタスクの時間と順序が明らかになります。テストや移行タスクなど多くの場合、各タスクにかかる時間は、データベースのサイズだけでなく、チームの空き状況やアプリケーションの使用状況といったその他の要因にも影響されます。
複数のデータベースを複数回に分けて移行する場合は、移行計画を段階ごと作成し、それを組み立てて全体的な計画とすることをおすすめします。DMS とデータベース移行プロセスに慣れるため、ミッション クリティカルでない小規模のデータベースから始めることをおすすめします。
単一データベース向けの移行計画に盛り込む基本的要素は、次のとおりです。
移行スケジュール開始日と予想される終了日があるスケジュールで、全体の期間が規定されます。また、達成すべきすべてのタスクが含まれます。
準備タスク。準備タスクでは、データベースのサイズを規定し、すべての前提条件が満たされていることを確認します（上述のとおり）。また、移行に備えて移行元データベースに対して必要な変更も行う必要があります。
実行タスク。このタスクでは、DMS の移行ジョブを実装します。準備の詳細および移行ジョブの詳細情報は、すべての必要なナレッジと背景情報を一元化しているユーザー インターフェースで提供されます。
テスト。概念実証の観点から移行をテストすることは、最重要タスクの一つです。移行プロセスに慣れる過程では、最初のデータベースに対してのみテストを実施してもよいでしょう。もちろん、移行されるすべてのデータベースに対してテストを実施することもできます。テストでは、データベースを Google Cloud に完全に移行して検証を実施しますが、本番環境アプリケーションのワークロードはまだ Google Cloud に移行しません。テストの目的は、Google Cloud に移行したデータベースに問題がないこと、本番環境の移行が正常に行われることを確認することです。アプリケーションが移行したデータベースを使って正常に動作するかどうかを厳密にテストします。さらに、整合性を確保するために、移行したデータベースに対して想定されるクエリをスポットテストすることも、多くの場合プロセスの一部に組み込まれます。
最終的な移行とプロモーション。本番環境移行の日時を設定して、周知する必要があります。ダウンタイムが生じるため、通常はアプリケーションがあまり使われていない時を選択します。設定した日時に、DMS 移行ジョブを実行します。移行は継続して行われますが、移行元と Cloud SQL 間のラグがごく小さくなったら、データベースをプロモートしてアプリケーションのカットオーバーを行うことができます。DMS によってアプリケーションがシャットダウンし、保留中の変更が Cloud SQL に移行されます。Cloud SQL インスタンスのプロモーションが開始され、未処理の検証が実施されます。アプリケーションはカットオーバー、再起動され、新しい Cloud SQL インスタンスに対して実行されます。
データベースの調整。アプリケーションが Google Cloud で実行され、新しい Cloud SQL インスタンスに対して稼働したら、データベースを調整して、さらにパフォーマンスを向上させることができます。
移行計画は、複数のステップからなる詳細なプロセスです。移行はほとんどの場合、問題なく行われますが、一般的には、デバッグのために追加の時間が必要な場合（接続の確立などのため）や、移行で再起動が必要となった場合など、不測の事態に対する計画も立てておくことをおすすめします。
実装、テスト、実行、カットオーバー
評価と計画の完了後は、実装、移行のテスト、カットオーバーを開始できます。
実装
実装は、関連するシステムに対応する 3 つのリソースで構成されます。
ソース接続プロファイル。移行元データベースの接続情報を表す接続プロファイルを定義します。これは、移行ジョブで使用されます。移行はプライマリ データベースに対して直接開始される場合が多いですが、プライマリ データベースが負荷の影響を受けやすい場合や、多くの DDL がプライマリ データベースで実行されている場合は、リードレプリカに接続することをおすすめします。
移行先データベース。移行先 Cloud SQL インスタンスは、移行ジョブ作成中に作成されます。インスタンスへの接続プロファイルは、移行ジョブの移行先情報を提供するために、インスタンス作成時にバックエンドで自動的に作成されます。
移行ジョブ。移行ジョブは、ユーザー インターフェースを介して、または作成された接続プロファイルを使用する API を介して指定されます（ユーザー インターフェース フローの概要は上のスクリーンショットを参照）。ユーザー インターフェースを使用する場合、入力した構成値は、別の移行ジョブを指定するために再度必要となる場合に備えてコピーできます。特に重要なのは、移行ジョブ作成の一環としてジョブテスト機能を使用して、完全で一貫性のある移行ジョブ実装を確実に行うことです。
制限事項: 現時点の Database Migration Service は、MySQL ユーザー管理と権限管理の移行先データベースへの移行をサポートしていません。新しい Cloud SQL インスタンスでは、ユーザーと権限を手動で設定することが必要となりますが、これは移行先データベースが作成され次第可能となります。移行の制限事項の詳細をご覧ください。
実装の完了後は、テストを開始できます。
移行のテスト
テストは、アプリケーションの移行やテストを始めとするあらゆる点で移行が問題なく行われていることを確認する、データベースの移行作業で非常に重要な段階です。
効率よくテストを行うため、まずは移行ジョブをすべて完了することをおすすめします。想定するパフォーマンスと結果を確保するには、移行ジョブを開始し、移行ジョブが継続的なレプリケーション（CDC）フェーズに入ってラグがごく小さくなってから、移行先データベースをプロモートして Google Cloud でのアプリケーションのテストに使用します。
移行テスト中にエラーが発生した場合は、エラーを分析し、移行元データベースまたは移行ジョブに対して必要な修正を行います。修正を行った場合は、想定する結果を確保するために、すべてのテストを再度実施します。
本番環境の移行
テストの完了後、本番環境データベースとアプリケーションを移行します。この時点で、本番環境への移行の日時を最終決定する必要があります。アプリケーションがあまり使用されていない時が理想的です。また、関与する必要があるすべての関係者が対応可能で準備が整っている必要があります。
本番環境への移行が開始されると、順調に進行していることを確認するために緊密なモニタリングが必要です。プロモーション時にレプリケーション ラグが低いことを確認するために、このフェーズでは DMS のモニタリング ユーザー インターフェースが重要になります。
移行が完了したら、移行先データベースの整合性を検証し、アプリケーションをサポートできることを確認します。
データベースとアプリケーションのカットオーバー
アプリケーションを接続する前に、新しいプライマリ データベースのための一貫性のある開始点として、移行先データベースのバックアップを作成することをおすすめします。
バックアップを取ったら、Cloud SQL データベースを今後の新しいプライマリ データベースにプロモートします。依存関係のあるすべてのアプリケーションに対してカットオーバーを行って新しいプライマリ データベースにアクセスし、本番環境で使用するアプリケーションを開きます。
アプリケーションが Cloud SQL で実行されたら、データベースのパフォーマンスを詳細にモニタリングし、パフォーマンスの調整が必要かを確認します。Cloud SQL 上ではアプリケーションが事前に実行されないため、アプリケーションのパフォーマンスを最適化できる調整オプションが用意されています。こちらおよびこちらをご覧ください。
次のステップ
DMS のドキュメントをご確認ください
Google Cloud Console で DMS をお試しください。Cloud SQL へのネイティブのリフト＆シフトの移行には追加料金なしで利用できます。
-Google Cloud ソリューション アーキテクト Christoph Bussler
