SQL Server から Cloud SQL への移行を計画する方法
Google Cloud Japan Team
※この投稿は米国時間 2023 年 1 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。
SQL Server の DBA には、1 つの SQL Server インスタンスから新しい環境にデータを転送する際に選択できるオプションが多数あります。その数は多すぎて圧倒されるほどです。このブログの目的は、特定の移行シナリオにどのオプションを選択すればいいのかを判断できるようにすることです。それでは移行計画を決定するための手順を紹介していきます。
アプリケーションとデータベースの移行要件の評価
移行方法 - 継続的と 1 回限りの比較
さまざまな移行パスの詳細な説明
アプリケーションとデータベースの移行ニーズの評価
最初に、アプリケーション固有のさまざまな要因を定義する必要があります。これが移行方法を選択するうえで役立ちます。お客様から受ける「よくある質問」には、以下のようなものがあります。
移行にはどのくらい期間がかかりますか？
移行中も引き続きアプリは機能しますか？
こうした移行のサポートはどのくらい複雑で、ロールバック プロセスはどのくらい簡単ですか？
こうした質問に答えるには、アプリケーションとデータベースを評価し、移行プロセスを深く理解して決定を下す必要があります。
許容されるダウンタイムはどの程度か。
アプリケーションによっては、変更リクエスト スケジュールが明確に定義されていて、これを移行に使用できるものもありますが、24 時間年中無休という高い稼働時間で実行するように開発されているものもあります。許容可能なダウンタイムを知ることで、継続的な移行方法の複雑さと 1 回限りの移行方法の簡単さを比較できます。データベースの大きさはどの程度か。
大規模なデータベースの移行には、他の課題が伴う場合があります。たとえば、移行をサポートするオンプレミス サーバーでのリソース使用率の増加が長期間に及ぶことや、トランザクション レプリケーションでデータベース スナップショットを配信する方法などです。表面上は単純に見える転送速度も、数テラバイトのバックアップをクラウドにアップロードする際に直面するさまざまな課題を考慮すると、単純ではなくなります。データベースの毎日の更新サイズはどのくらいか。
毎日の更新サイズと、それら更新間の純増減の両方が、1 回限りの移行方法と継続的な移行方法のどちらにするかという判断に大きな影響を与える可能性があります。たとえば、ワークロードが同じ行セットに対して複数の変更を行うことでデータベースの大幅な部分を更新する場合、またはワイプ アンド ロードのデータ更新戦略に従う場合に、正味のデータベース サイズがすべての変更のログよりも小さければ、継続的な移行ではなく、1 回限りの移行をスケジュールできます。 一方、変更が限定的で、長期間表示される場合は、オンライン移行を検討することをおすすめします。
移行方法
移行方法は、1 回限りの移行と継続的な移行の 2 種類に分類されます。 1 回限りの移行では、移行元データベースのコピーを取得し、それを移行先インスタンスに転送してから、アプリケーションを切り替えて新しいインスタンスを指すようにします。 継続的な移行では、データは、移行元インスタンスから移行先インスタンスに継続的に（最初のデータロードから開始され）コピーされます。アプリケーションは、数日、数週間、または数か月かけて、徐々に切り替わる場合があります。
許容されるダウンタイムに応じて、またはデータベースの更新頻度が低い場合は、1 回限りの移行を選択できます。この方法では複数のオプションを採用しており、プロセスの複雑さはさまざまです。データベース バックアップをインポートするという非常に単純なものから、スナップショット レプリケーションという複雑さとしては平均的なものまであります。
データベースには毎日の変更が大量にあり、ダウタイムを最小限に抑える必要があるアプリケーションには、継続的な移行オプションが最適と言えるでしょう。継続的な移行のシナリオは通常、SQL Server によってサポートされる、トランザクション / 結合レプリケーション、P2P、双方向レプリケーションなどのデータ レプリケーション技術のほか、SQL Server エージェント、スナップショット エージェント、ログリーダー エージェント、ディストリビューション エージェントに基づいています。他のレプリケーション技術では、変更データ キャプチャ（CDC）、変更追跡、さらにはカスタム トリガーを利用して、増分データの変更をキャプチャおよび保存し、これを独自の配信メカニズムと組み合わせます。
Cloud SQL for SQL Server はプッシュ トランザクション レプリケーション（これについてはパート 2 で詳述します）と、Google Cloud パートナーが提供する CDC ベースの移行ツール（Google Cloud Marketplace にあります）をサポートしています。
1 回限りの移行
データベースを Cloud SQL に移行する最も簡単な方法の一つは、バックアップからデータベースをインポートすることです。この方法は、あらゆるデータベース サイズに適しています。1 回限りの移行に注目している場合、バックアップからのインポートは、インスタンスのサイズが大きくなるほど魅力的な選択肢になります。それは主に、大量のデータを処理する場合に、このオプションと以下に説明するオプションとのパフォーマンスに違いがあるためです。ファイルサイズに制限があるため、5 TB 以上のデータベースには、ストライプ バックアップを使用する必要があります。
もう 1 つのオプションは、速度は遅くなりますが、すでに抽出したテーブルがあり、BCP ツールを使用してオンプレミス データベースをロードしているチームに役立つ可能性があります。クラウドでホストされたインスタンスでも同ように機能します。
BCP はスタンドアロン プロセスでも使用できますが、その場合、次のことが必要になります。
特定のオブジェクトを移行したい、またはファイルを手動で転送したくない場合は、スナップショット レプリケーションを使用できます。
これはバックアップのインポートに比べると複雑になりますが、この記事に手順が詳しく説明されています。スナップショット レプリケーションでは、スナップショットを保存するための追加スペースや、スナップショットを転送・生成するための IO リソースや CPU リソースなど、オンプレミス サーバーへのリソース負荷が増大します。ワークロードのタイプによってはサポートされていないものがあります。また、スナップショット生成プロセスをブロックまたはリセットするタイプもあります。データベース スキーマと使用する記事の構成によっては、このタイプのレプリケーションでサポートされるオブジェクトにも制限があり、レプリカにカットオーバーするために追加の手順が必要になる可能性があるため、たとえばこの記事から始めて、SQL Server のドキュメントを参照することをおすすめします。スナップショット レプリケーションには追加作業が必要で、注意事項もありますが、そのすべてに、インポート / エクスポートという単純な方法よりも優れた点があります。そのなかには、レプリケート / 移行するオブジェクトを細かく設定できること、ワンクリックの再初期化で、更新されたスナップショットをターゲット サーバーに適用できること、確立されたレポートおよび監視ツールがあることなどがあります。
スナップショットの生成では、プロセスが完了するまでソーステーブルをロックし続けます。大規模のデータベースでは実行時間が数時間に及ぶこともあるため、これが問題になる場合があります。このロックがワークロードに影響する場合は、バックアップからのインポート、またはスナップショット エージェントの初期化を使用するプッシュ トランザクション レプリケーションを検討してください。 スナップショット レプリケーションとは対照的に、トランザクション レプリケーションではわずかなロック時間で更新をトランザクション ログに組み込み、増分変更とともに送信します。
継続的な移行
バックアップを作成して Cloud SQL にインポートするにはダウンタイムが必要になるものの、その間、ワークロードを停止しておけないという場合は、継続的な移行方法であるプッシュ トランザクション レプリケーション設定または CDC ベースのカスタム レプリケーションのいずれかを使用できます。
プッシュ トランザクション レプリケーション
トランザクション レプリケーションにはさまざまな形態があり、非常に柔軟なレプリケーション設定が可能です。この記事の執筆時点で、Cloud SQL は、すべてのタイプのレプリケーションの中で、プッシュ トランザクション レプリケーションをパブリッシャーおよびサブスクライバーとしてサポートしています。これにより、外部ソースから Cloud SQL インスタンスへの継続的なレプリケーション設定、Cloud SQL での追加のレプリカの作成、または Cloud SQL から外部の宛先へのレプリケーション（たとえば、マルチ環境の DR シナリオの場合）が可能になります。
プッシュ トランザクション レプリケーションを使用した継続的な移行は、次の 3 つのステップで構成されると見なすことができます。
初期シード: 増分アップデートを Cloud SQL に送信する前に、初期データ スナップショットをコピーする必要があります。これを行う方法としては、バックアップ、スナップショット エージェント ジョブ、BCP など多数ありますが、それぞれに独自の利点と機能があります。
増分アップデート: レプリカ インスタンスには、増分アップデートが送信されています。レプリケーション設定によっては、レプリカを使用できるだけでなく、データベースに対してクエリも実行できます（ほとんどの場合、読み取りのみ）。
Cloud SQL へのカットオーバー: トランザクション レプリケーションが機能するために必要な特定の制限により、ワークロードを Cloud SQL インスタンスに完全にカットオーバーするには、データベース スキーマを最終的に変更する必要があります。この変更には、トリガーの追加 / 有効化、ID フィールド範囲の更新、ログインの同期、テーブルのビューの変換などが含まれる場合があります。
バックアップからの初期化を使用したレプリケーション:
これは、サーバーがサポートするすべてのオブジェクトに対して、スキーマと初期シードのデータ転送をワンストップで設定します。また、あらゆるデータベース サイズで機能し、スナップショット エージェント、BCP などの他の初期化方法が苦手とする大規模なインスタンスで最適なパフォーマンスを発揮します。このオプションには、カスタムで準備されたバックアップ ファイルが必要ですが（通常のバックアップは、パブリケーションが作成され、バックアップからの初期化を許可するようにマークされるまで機能しません）、以下で説明する手動の初期化では、準備されていないバックアップを使用することもできます。
スナップショット エージェントを使用したレプリケーション:
スナップショット エージェントを使用した初期シードは、フェーズを終了するのに十分な予備リソースを備えたインスタンスにおいて、互換性のある中規模のデータベースで適切に機能します。スナップショット レプリケーションと同様に、この方法を使用すると、移行の粒度が高まり、数回クリックするだけでいつでもプロセスを再開できる柔軟性が加わります。もう 1 つのメリットは、トランザクション レプリケーションのモニタリング機能が統合されている点で、この機能により、スナップショット エージェントとディストリビューション エージェント両方のレプリケーション ジョブのステータスと進捗状況が示されます。
手動の初期化を使用したレプリケーション:
このオプションの利点と制限事項は「バックアップからの初期化」と同じですが、小さいながらも重要な違いがあります。それは、トランザクション レプリケーション開始の同期点をデベロッパーが選択できることです。これにより、前述のオプションやカスタムツールを使用した初期シーディングが可能になります。残りはトランザクション レプリケーションが処理します。
トランザクション レプリケーションの初期シード方法を選択する際に考慮すべき重要事項は、データベースのサイズです。1 TB 以上のデータベースはバックアップからより確実に開始できる一方、小規模なデータベースではスナップショット エージェントを使用した再初期化の方が容易になりメリットをもたらす場合があります。データベースに主キーのない静的テーブルやサポートされていないオブジェクトがある場合は、バックアップ オプションまたは手動の初期化オプションを使用することをおすすめします。
増分アップデート
ディストリビューターの場所（ソースと同じにすることも、Cloud SQL に移行するための別の SQL Server インスタンスにして、ソースとして Cloud SQL インスタンスに置くこともできます）で実行されているログリーダー エージェントは、データ変更ステートメントを読み取ってディストリビューション データベースに格納することにより、ソース インスタンスからすべてのパブリッシュされたデータベース オブジェクトの増分アップデートを収集します。エージェントは、トランザクションの定期的なスイープとして実行することも、継続的なセットアップとして実行することもできるため、ソース インスタンスとターゲット インスタンス間の潜在的なレプリケーション ラグが減少します。
ディストリビューション エージェントは、ディストリビューション データベースを読み取り、配布されていないコマンドをターゲット インスタンスに適用します。増分変更は、最初のシード レプリケーションで見られた BCP パフォーマンスの恩恵を受けなくなっているため、データベースのサイズが大きく、データの回転率が高い場合は、効率を高めるためにトランザクション レプリケーション設定のさらなる調整が必要になる場合があります。意図せぬ遅延やタイムアウトを避けるために、実際の移行を試みる前に、テスト インスタンスで移行設定を検証することが重要です。
移行の複雑度
これまで多くの移行技術を調査してきましたが、それぞれの技術には複雑になりうる原因があり、それは移行する特定のデータベースによって異なる可能性があります。複雑になる原因として、次の 4 つの主要なステップが考えられます。
Cloud SQL へのファイル転送: 小規模なデータベースでは、バックアップのアップロードまたはダウンロードに関する問題はほとんどありませんが、TB 以上の領域のある大規模なデータベースでは、ストライプ バックアップや、圧縮技術、フィルタリングの使用など、要件が追加される場合があります。
初期シードを使用したデータベースの設定: データベースのバックアップ手順の復元を伴う方法には、データベース スキーマの復元が含まれますが、BCP またはカスタムツールを使用する方法では、スキーマの配置が必要になる場合があります。データベース スキーマの手動設定では、ID 範囲の更新や、トリガーの実行順序の設定などが必要になることがあるため、複雑さが増し、DBA やデベロッパーの関与の必要性が高まります。
レプリケーション設定の微調整: スナップショット レプリケーションとトランザクション レプリケーションでは、スキーマとワークロードにおけるレプリケーションとの互換性を検証し、正しいレプリケーション設定を見つけるためにテストの実行が必要になる場合があります。このプロセスのすべての手順で、DBA の関与が強く推奨されます。レプリケーションの実行が長時間になるよう設定している場合は、モニタリング システム、レポート システム、アラート システムの設定をおすすめします。レプリケーション方法の複雑度は、中程度から高度と推定できます。
アプリケーションのカットオーバーのためのデータベース設定の完了: スナップショット レプリケーション、トランザクション レプリケーション、BCP、および一部のサードパーティ ツールでは、データベース レプリカの移行が完了したことでそれぞれ該当する移行部分を終了せず、準備が完全には整っていない状態になる可能性があります。そのため、ID 範囲が不正確、トリガーがオフになっている（または欠落している）、ユーザーが欠落しているなどの不整合が生じる場合があります。移行される内容やその容量は、データベース スキーマと、選択した移行方法との互換性レベルによって異なります。スキーマを比較して移行テストを実行し、潜在的な欠陥を特定することで、データベース プロモーション用の「プルアップ」スクリプトを準備し、Cloud SQL インスタンスへのアプリケーション カットオーバーを行うことを強くおすすめします。
ただし、以上のような複雑化の原因すべてが、これまでに説明した方法すべてに影響を与えるわけではありません。たとえば、ファイル転送はスナップショット レプリケーションとは無関係で、レプリケーション設定の微調整はデータベース バックアップのインポートには関係ありません。
Cloud SQL for SQL Server からのデータのコピー
たいていはマルチクラウド戦略の一環ですが、Cloud SQL から他の宛先へのデータのコピーを希望するお客様もいます。簡単に言うと、上記で説明したすべての方法には、逆順に実行する機会があります。
1 回限りの移行
データベース バックアップのエクスポート
BCP または類似のツールは通常、インポートとエクスポートの双方向で機能します。
事前定義されたストアド プロシージャを使用したスナップショット レプリケーション。このガイドは、スナップショット レプリケーションとトランザクション レプリケーションの両方の設定のプロセスに役立ちます。
継続的な移行
スナップショット エージェントと手動の初期化を使用したプッシュ トランザクション レプリケーションでは、事前定義されたストアド プロシージャを使用できます。
バックアップを使用したプッシュ トランザクション レプリケーションは、事前定義されたストアド プロシージャを使用してパブリケーションを作成し、バックアップを作成することで実現できます。復元中は、LSN に注意し、「LSN から初期化」オプションを使用してサブスクライバーを追加してください。もう 1 つのオプションは、「レプリケーション サポートのみ」のサブスクリプションを使用することです。
オプションの確認
1 回限りの移行は、データベースのスナップショットを Cloud SQL に移行するうえで最も便利で単純な方法です。これに対して継続的な移行方法は、ワークロードの実行を継続しながらターゲット インスタンスとソース インスタンスの同期を維持できます。
一般的に推奨されるのは、可能な限りすべての場合でデータベース バックアップ インポートを使用することです。それが機能しない場合は、スナップショット レプリケーションでの、定期的に更新する単純なスキーマと要件を使用した、小規模なデータベースの 1 回限りの移行が役立つことがあります。テーブル ファイルの抽出がすでにワークフローの一部である場合、またはすでに ETL ジョブを使用していて、開発時間に余裕がある場合やニーズがある場合は、それぞれの BCP インポートとカスタムツールが役立つ可能性があります。
プッシュ トランザクション レプリケーションを使用すると、ソースサーバーとターゲット サーバーを同期させておくことができます。各方法の主な違いは初期化（初期シード）です。どの状況にも共通して推奨される方法というのはありません。さまざまなオプションを試して、最適なものを選択する必要があります。それはスナップショット エージェントまたはバックアップの初期化の場合もあれば、手動の初期化またはカスタム ETL ジョブの場合もあります。初期シード、レプリケーション プロセス、または最終的なプロモーション中に予期せぬ事態が発生しないように、最初から完全なカットオーバーまでテストが必要です。
以上、ゆっくりとコーヒーを飲みながらスムーズに移行できる方法が見つかったでしょうか。Cloud SQL for SQL Server への移行を今すぐ開始しましょう。
- ソフトウェア エンジニア Vlad Zhuk
