Cloud SQL のリージョンの移行
Google Cloud Japan Team
※この投稿は米国時間 2023 年 9 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。
Cloud SQL を使用してビジネスを新しいリージョンに拡大する予定ですか？Cloud SQL で実行しているアプリケーションを、固有のデータ コンプライアンスや地理的な地域要件のあるリージョンに移動する必要がありますか？リージョンの停止が発生し、Cloud SQL インスタンスを別のリージョンに移動する必要がありますか？あるいは、エンタープライズのお客様で、新しく発表された Cloud SQL Enterprise Plus エディションに移行して、99.99% の可用性、ダウンタイムがほぼゼロの計画メンテナンス、パフォーマンスの 3 倍向上を実現することを検討していますか？これらのどのケースにおいても、まずはデータを新しいリージョンに移動して、アプリケーションの運用を可能にしてお客様へのサービス提供を迅速に開始するでしょう。この記事では、Cloud SQL について、移行の複雑さの緩和、アプリケーションのダウンタイムの短縮、移行プロセスの簡素化に焦点を当てます。
このブログ投稿では、Cloud SQL でのリージョン移行計画に関する以下の手順について説明します。
移行要件の評価
移行方法
アプリケーションの有効化
移行要件の評価
移行計画を検討する場合は必ず、アプリケーション固有のインテグレーション要件を定義する必要があります。これらのアプリケーションがバックエンド データベースとやりとりし、次のようなリージョン移行についての決定事項を定義できるようにします。
データベースのサイズはどのくらいか？
データベースのサイズによって、移行にかかる時間が決まります。オンライン アプローチ（レプリカなど）とオフライン アプローチ（エクスポート / インポートやバックアップなど）のどちらを選択するかで、ある程度は時間を制御できます。長期間のダウンタイムを許容できないアプリケーションにはオンライン アプローチが適していますが、ダウンタイムを許容できるのであれば、オフライン アプローチの方が簡単に計画して実行できます。ダウンタイムは許容されるか？
本番環境でアプリケーションに変更リクエスト スケジュールを定義することで、移行の複雑度を判断しやすくなります。変更のデプロイでダウンタイムを許容できる場合は、継続的な移行ではなく、簡単な 1 回限りの移行方法を検討してください。アプリケーションでどのようなデータベース接続が構成されているか？
Cloud SQL のリージョン移行では、アプリケーション内のデータベース接続構成の更新が必要になる場合があります。アプリケーションで Cloud SQL への接続に Cloud NAT ゲートウェイ、Cloud DNS、ロードバランサなどをすでに使用している場合は、簡単に構成を更新でき、アプリケーション自体に影響を与えることはありません。時間ごとのデータベースの更新サイズはどれくらいか？
リージョン移行方法の決定は、変更またはトランザクションが各時間にデータベースにアクセスする頻度に大きく影響されます。トランザクション頻度が最も低い移行時間枠を選択すると、トランザクション データの損失、多数のユーザー接続エラー、アプリケーションのタイムアウト、高いエラー率などの発生リスクを回避できます。そのため、移行時間中のトランザクション頻度は重要な考慮事項となります。インスタンスがデータベースへのトラフィックを処理する量が最も少ない時間を特定すると、移行の計画を進めやすくなります。クライアント サイドでデータベースを暗号化しているか？
データを暗号化してアプリケーションで復号できるようにする機能が Cloud SQL には用意されています。データの暗号化と復号に使用される暗号鍵は、Cloud Key Management Service（KMS）に保存されます。リージョン KMS 鍵とグローバル KMS 鍵のどちらを使用してデータを暗号化するかによって、Cloud SQL の移行方法の決定が左右されます。単一のリージョン KMS 鍵を使用する場合、使用する移行方法によってはデータの再暗号化が必要になる場合があります。詳しくは、Cloud SQL の暗号鍵の操作をご覧ください。
前述の質問に回答すると、可能な限り最適な移行パスを計画して、クライアント アプリケーションを Cloud SQL の新しいインスタンスに移行するのに役立ちます。これにより、クライアント アプリケーションでスプリット ブレイン状態の発生を回避できます。
リージョンの移行方法
Cloud SQL データベースのリージョン間の移行は、さまざまな方法で行うことができます。次のセクションでは最も一般的な方法について説明します。
リージョンの移行のためのクロスリージョン リードレプリカ
読み取り専用レプリカにはデータベース全体のコピーが含まれており、リーダー リージョンへのラウンドトリップを必要とせずに読み取りを処理できます。つまり、近傍のクライアントに低レイテンシでステイル読み取りを提供し、クライアントの場所にかかわらず、ノードの読み取りのスケーラビリティを全体的に向上させます。クロスリージョン レプリケーションは、プライマリ インスタンスとは異なるリージョンでフルマネージドのリードレプリカを簡単に作成できます。
クロスリージョン リードレプリカは、プライマリ インスタンスを非同期に複製するように設定されます。つまり、リードレプリカはプライマリ インスタンスより古くなる場合があります。移行中にリードレプリカがプライマリ インスタンスと同期していない場合、プライマリ インスタンスの新しいデータは失われます。レプリカがプライマリ インスタンスより古くならないようにするには、モニタリング指標を定義して、移行時間中にレプリカ インスタンス上でトラッキングする必要があります。
リージョンの拡大やビジネス要件によりリージョン全体を移行する必要がある場合、このクロスリージョン リードレプリカをスタンドアロン インスタンスになるように昇格させることができます。レプリカ プロモーションのシナリオでは、Cloud SQL インスタンスの IP アドレスは、同じままになる場合と変更される場合があります。
ゾーン リードレプリカの場合、Cloud SQL レプリカ インスタンスの IP アドレスはプライマリ インスタンスと同じになります。
リージョン リードレプリカの場合、Cloud SQL レプリカ インスタンスの IP アドレスはプライマリ インスタンスとは異なります。
したがって、Cloud SQL リージョン リードレプリカを昇格させると、その IP アドレスは、新しく昇格されたプライマリ インスタンスの IP アドレスになります。アプリケーションは昇格前の Cloud SQL の IP アドレス（プライマリ インスタンスの IP）を指しているため、新しく昇格された Cloud SQL インスタンスの IP アドレス（リージョン リードレプリカの IP）を指すように構成を更新する必要があります。
アプリケーションのポイント先を新しい Cloud SQL インスタンスに変更する複雑さの度合いは、アプリケーション構成がどのように定義されているかによって異なります。Cloud DNS を使用した構成の更新方法については、Cloud SQL ラボを参照してください。
新しいリージョンの Cloud SQL インスタンスに対するデータ移行サービス
Database Migration Service（DMS）を使用すると、既存の CloudSQL インスタンスから、異なるリージョンにある同じまたは異なる Cloud SQL エディションの新しいインスタンスへデータベースを移行し、ソース データベースからターゲット データベースへの継続的なレプリケーションを実行できます。DMS は、すべての移行元に対して CDC スタイルの移行（同種移行と異種移行の両方）をサポートしており、移行元から移行先へ継続的に変更を移行します。PostgreSQL DMS の既知の制限事項をご覧ください。
新しいリージョンの Cloud SQL インスタンスのバックアップと復元
マルチリージョン バケットに保存されている自動バックアップまたはオンデマンド バックアップを使用して、Cloud SQL を別のリージョンに移行できます。バックアップから Cloud SQL インスタンスを設定するには、新しいインスタンスを作成した後にバックアップから復元するため、ある程度時間がかかります。
新しいリージョンでのデータベースのエクスポートとインポート
データベースのエクスポートを使用して、データベースを異なるリージョンに移行することもできます。データベースのエクスポート / インポートを選択する場合は、労力、時間、データ損失に対する組織の許容レベルを考慮することが重要です。リージョンの移行では、マルチリージョンの Cloud Storage バケットで 1 回限りのエクスポートとインポートを使用でき、ターゲット リージョンでこれにアクセスできます。
エクスポート / インポートを使用して障害復旧を計画するには、ビジネス要件に基づいて定期的にデータベースをエクスポートするようにプロセスを自動化する必要があります。たとえば、どのような SLA 要件がありますか？データをエクスポートする際に考慮すべきコンプライアンス要件（GDPR など）はありますか？データ エクスポートの頻度はどのくらいにする必要がありますか？
以下は、バックアップ / 復元とエクスポート / インポートの簡単な比較を示しています。
アプリケーションの有効化
Cloud SQL のデータを使用するアプリケーションには、データベース専用の構成があります。ある構成から別の構成に移行する際の複雑さの度合いは、構成がどのように定義されているかによって異なります。データベース接続エンドポイントは、アプリケーションのランタイム構成で定義されます。
接続文字列でデータベース IP アドレスを使用する代わりに、データベース エンドポイントにエイリアスを使用することをおすすめします。こうすることで、接続文字列を変更する必要がなくなるため、アプリケーションに影響を与えずにデータベースを移行できます。更新する必要があるのは、移行した Cloud SQL データベースのエイリアスの詳細だけです。
企業のお客様は、パブリック インスタンスに対する特別な必要性がない限り、プライベートの Cloud SQL インスタンスを使用することがほとんどです。たとえば、Cloud DNS を使用すれば、DNS レコード（FQDNI）を Cloud SQL のパブリックまたはプライベート IP アドレスに解決できます。SQL ホストレコードを参照するには、アプリケーション構成で対応する Cloud DNS 名を使用します。移行後に更新する必要があるのは、移行した Cloud SQL インスタンスの Cloud DNS レコードだけです。
その他のリソース
あるリージョンから別のリージョンへの Cloud SQL の移行には、影響を受けるデータベース コンポーネントの分析、アプリケーションの有効化と再構成、ネットワーク構成、ユーザー インターフェース アプリケーションへの影響、データベース モニタリングの移行など、さまざまなアクティビティが含まれます。バックアップ、リードレプリカ、オフライン エクスポートを使用した Cloud SQL リージョン データベースのさまざまな移行方法について説明しました。クロスリージョンのリードレプリカを使用するのが最も便利な方法ではありますが、どの方法を選択するかはビジネス、費用、レイテンシの要件に基づいて決定する必要があります。それぞれのオプションの特長を把握して最適な構成を選択するうえで、このブログ投稿が参考になれば幸いです。
まずは、Cloud SQL インスタンスを GCP アカウントまたは SQL リージョン移行 Qwiklab で作成し、リージョン移行体験をお試しください。
詳しくは、以下のリソースをご活用ください。
