AWS から Google Cloud への移行: Amazon RDS for MySQL と Amazon Aurora for MySQL から Cloud SQL for MySQL に移行する

Last reviewed 2024-08-16 UTC

Google Cloud には、Amazon Relational Database Service（RDS）または Amazon Aurora から Cloud SQL for MySQL に移行するためのツール、プロダクト、ガイダンス、プロフェッショナル サービスが用意されています。

このドキュメントは、データベース移行プロジェクトの計画、実装、検証を行うクラウド管理者とデータベース管理者を対象としています。また、移行の時期を考え、移行がどのようなものかを知りたい意思決定者を対象としています。

このドキュメントでは、移行元データベースと移行先データベースで同じデータベース テクノロジーを使用する同種のデータベース移行に焦点を当てます。この移行ガイドでは、移行元は Amazon RDS または Amazon Aurora for MySQL、移行先は Cloud SQL for MySQL とします。

このドキュメントは、AWS から Google Cloud への移行に関する複数のパートからなるシリーズの一部です。このシリーズには、次のドキュメントが含まれています。

Google Cloud に移行する場合は、Google Cloud への移行: スタートガイドで説明する移行フレームワークに従うことをおすすめします。

次の図は、移行の過程を示しています。

4 フェーズの移行パス

移行元の環境から Google Cloud には、一連のイテレーションで移行できます。たとえば、最初に一部のワークロードを移行した後、残りのワークロードを移行できます。個別の移行イテレーションごとに、以下の一般的な移行フレームワークのフェーズに従います。

  1. ワークロードとデータを評価して検出します。
  2. Google Cloud で基盤を計画し、構築します。
  3. ワークロードとデータを Google Cloud に移行します。
  4. Google Cloud 環境を最適化します。

このフレームワークのフェーズの詳細については、Google Cloud への移行: スタートガイドをご覧ください。

効果的な移行計画を設計するには、計画の各ステップを検証し、ロールバック戦略を常に持っていることをおすすめします。移行計画の検証については、Google Cloud への移行: 移行計画の検証に関するベスト プラクティスをご覧ください。

移行元の環境を評価する

評価フェーズでは、移行元の環境を Google Cloud に移行するための要件と依存関係を確認します。

移行を成功させるには、評価フェーズが非常に重要です。このフェーズで、移行するワークロードとその要件、依存関係、および現在の環境について詳しく把握する必要があります。また、Google Cloud への移行を計画して実施するための出発点も理解する必要があります。

評価フェーズは、次のタスクで構成されます。

  1. ワークロードの包括的なインベントリを構築する。
  2. プロパティと依存関係に応じてワークロードを分類する。
  3. チームを Google Cloud でトレーニングして教育する。
  4. Google Cloud 上でテストと概念実証を作成する。
  5. ターゲット環境の総所有コスト（TCO）を計算する。
  6. ワークロードの移行戦略を選択する。
  7. 移行ツールを選択する。
  8. 移行計画とタイムラインを定義する。
  9. 移行計画を検証する。

データベースの評価フェーズを実施することで、ターゲット Cloud SQL データベース インスタンスに移行元と一致するサイズと仕様を選択し、同様のパフォーマンス要件を満たすことができます。ディスクサイズとスループット、IOPS、vCPU の数に特に注意してください。ターゲット データベース インスタンスのサイズが正しくないと、移行が困難になるか、失敗する可能性があります。サイズが適切でないと、移行に時間がかかったり、データベースのパフォーマンスの問題、データベース エラー、アプリケーションのパフォーマンスの問題が発生する可能性があります。Cloud SQL インスタンスを選択する場合は、ディスクのパフォーマンスはディスクのサイズと vCPU の数に基づくことに注意してください。

以降のセクションの内容は、Google Cloud への移行: ワークロードの評価と検出に基づいており、このドキュメントの情報が統合されています。

Amazon RDS インスタンスまたは Amazon Aurora インスタンスのインベントリを作成する

移行の範囲を定義するには、インベントリを作成し、Amazon RDS または Amazon Aurora インスタンスに関する情報を収集します。手動で行う方法はエラーが発生しやすく、誤った想定につながる可能性があるため、専用のツールを使用してこのプロセスを自動化することをおすすめします。

Cloud SQL には、Amazon RDS または Amazon Aurora と類似する機能、インスタンス仕様、オペレーションがない場合があります。一部の機能は、実装が異なるか、使用できない場合があります。違いがある領域としては、インフラストラクチャ、ストレージ、認証とセキュリティ、レプリケーション、バックアップ、高可用性、リソース容量モデル、特定のデータベース エンジン機能の統合、拡張機能などがあります。データベース エンジンのタイプ、インスタンスのサイズ、アーキテクチャによっては、データベース パラメータ設定のデフォルト値が異なる場合もあります。

ベンチマークは、移行するワークロードをより深く理解し、移行先の環境に適切なアーキテクチャを定義する際に役立ちます。パフォーマンスに関する情報を収集することは、Google Cloud のターゲット環境のパフォーマンス要件を見積もるうえで重要な作業となります。ベンチマークのコンセプトとツールについては、移行プロセスのテストと検証を実施するフェーズで詳しく説明しますが、これはインベントリの構築ステージにも当てはまります。

評価用のツール

現在のインフラストラクチャの概要を把握するには、Google Cloud Migration Center と、migVisor や Database Migration Assessment Tool（DMA）などの専用のデータベース評価ツールを使用することをおすすめします。

Migration Center を使用すると、Google Cloud へのデータベース移行の技術的な適合性など、アプリケーションとデータベースの状況を完全に評価できます。移行元のデータベースごとにサイズと構成の推奨事項を受け取り、サーバーとデータベースの総所有コスト（TCO）レポートを作成します。

Migration Center を使用して AWS 環境を評価する方法については、他のクラウド プロバイダからデータをインポートするをご覧ください。

Migration Center に加えて、専用のツール migVisor を使用できます。migVisor はさまざまなデータベース エンジンをサポートしており、特に異種間の移行に適しています。migVisor の概要については、migVisor の概要をご覧ください。

migVisor は、移行の失敗の原因となる可能性のあるアーティファクトと互換性のない独自のデータベース機能を特定し、回避策を示します。また、初期サイズやアーキテクチャなど、ターゲットとなる Google Cloud ソリューションを推奨する場合もあります。

migVisor データベース評価の出力には、次の情報が含まれます。

  • 現在のデータベース デプロイメントの包括的な検出と分析。
  • データベースで使用されている独自の機能に基づく、移行の複雑さに関する詳細なレポート。
  • 移行後のコスト削減、移行費用、新しい運用予算に関する詳細を含む財務レポート。
  • ビジネスへの影響を最小限に抑えながら、データベースとそれに関連するアプリケーションを移行するための段階的な移行計画。

評価出力の例については、migVisor - Cloud 移行評価ツールをご覧ください。

migVisor を使用すると、データベース サーバーの使用率が一時的に増大します。通常、この追加負荷は 3% 未満であり、ピーク時以外であれば問題ありません。

migVisor の評価出力は、RDS インスタンスの完全なインベントリの作成に役立ちます。レポートには、汎用プロパティ（データベース エンジンのバージョンとエディション、CPU、メモリサイズ）のほか、データベース トポロジ、バックアップ ポリシー、パラメータ設定、使用中の特別なカスタマイズに関する詳細が含まれます。

オープンソース ツールを使用する場合は、上記のツールとともに（または代わりに）データコレクタ スクリプトを使用できます。これらのスクリプトを使用すると、詳細な情報（ワークロード、機能、データベース オブジェクト、データベース コードなど）を収集し、データベース インベントリを構築できます。また、スクリプトでは通常、移行作業の見積もりなど、データベースの移行に関する詳細な評価が提供されます。

Google のエンジニアが作成したオープンソース ツールである DMA の使用をおすすめします。これは、使用中の機能、データベース ロジック、データベース オブジェクト（スキーマ、テーブル、ビュー、関数、トリガー、ストアド プロシージャなど）を含む、包括的で正確なデータベース評価を提供します。

DMA を使用するには、Git リポジトリからデータベース エンジンの収集スクリプトをダウンロードし、手順に沿って操作します。出力ファイルを Google Cloud に送信して分析します。Google Cloud は、データベース評価の読み取り結果を作成し、移行の次のステップを提示します。

移行の範囲と受容できるダウンタイムを特定して文書化する

この段階では、移行戦略とツールに影響を与える重要な情報を文書化します。ここまでの段階で、次の質問に答えられるはずです。

  • データベースが 5 TB を超えているかどうか。
  • データベースに大規模なテーブルはあるか。16 TB を超えているかどうか。
  • データベースはどこにあるか（リージョンとゾーン）。また、アプリケーションとの距離はどのくらいか。
  • データが変更される頻度はどのくらいか。
  • どのデータ整合性モデルを使用するのか。
  • 移行先データベースにどのような選択肢があるのか。
  • 移行元と移行先のデータベースに互換性があるか。
  • データが特定の物理的な場所に存在する必要があるかどうか。
  • 圧縮してアーカイブできるデータがあるか。移行する必要のないデータがあるか。

移行スコープを定義するには、保持するデータと移行するデータを決定します。すべてのデータベースを移行するには、かなりの時間と労力が必要になる場合があります。一部のデータは移行元データベースのバックアップに残る場合があります。たとえば、古いロギング テーブルやアーカイブ データは不要な場合があります。戦略とツールに応じて、移行プロセスの後にデータを移動することもできます。

結果と影響を比較して評価する際に役立つデータ移行のベースラインを設定します。これらのベースラインは、移行前と移行後のデータを表す参照ポイントであり、意思決定に役立ちます。データ移行の成功を評価するために、移行元の環境で測定を実施しておく必要があります。このような測定には次のようなものがあります。

  • データのサイズと構造。
  • データの完全性と整合性。
  • 最も重要なビジネス トランザクションとプロセスの所要時間とパフォーマンス。

許容できるダウンタイムを決定します。ビジネスに対するダウンタイムの影響はどのくらいか。データベース アクティビティが低く、ダウンタイムの影響を受けるユーザーが少ない期間があるか。ある場合、その期間はどのくらいか。また、いつ発生するのか。読み取り専用リクエストは引き続き処理されるように、書き込み専用の部分的なダウンタイムを検討してください。

デプロイと管理のプロセスを評価する

インベントリを構築したら、データベースの運用プロセスとデプロイ プロセスを評価し、移行を容易にするために、それらをどのように適応させるのかを判断します。これらのプロセスは、本番環境を準備して維持する方法の基本となります。

次のタスクの実行方法を検討してください。

  • インスタンスのセキュリティ ポリシーを定義して適用する: たとえば、Amazon セキュリティ グループの置き換えが必要になる場合があります。Google IAM ロール、VPC ファイアウォール ルール、VPC Service Controls を使用して、Cloud SQL インスタンスへのアクセスを制御し、VPC 内のデータを制限できます。

  • インスタンスにパッチを適用して構成する: 既存のデプロイツールの更新が必要になる場合があります。たとえば、Amazon パラメータ グループまたは Amazon オプション グループでカスタム構成設定を使用している場合です。Google Cloud Storage または Secret Manager を使用してこのようなカスタム構成リストを読み取るように、プロビジョニング ツールの調整が必要になる場合があります。

  • モニタリングとアラート インフラストラクチャを管理する: Amazon ソース データベース インスタンスの指標カテゴリは、移行プロセス中のオブザーバビリティを提供します。指標カテゴリには、Amazon CloudWatch、Performance Insights、Enhanced Monitoring、OS プロセスリストなどがあります。

評価を完了する

Amazon RDS または Amazon Aurora 環境からインベントリを構築したら、Google Cloud への移行: ワークロードの評価と検出で説明されている評価フェーズの残りの作業を実施します。

基盤の計画と構築

計画と構築フェーズでは、インフラストラクチャをプロビジョニングして構成し、以下のことを行います。

  • Google Cloud 環境でワークロードをサポートします。
  • 移行元の環境と Google Cloud 環境を接続して、移行を完了します。

計画と構築のフェーズは、次のタスクで構成されます。

  1. リソース階層を構築する。
  2. Google Cloud の Identity and Access Management（IAM）を構成する。
  3. お支払い情報を設定する。
  4. ネットワーク接続を設定する。
  5. セキュリティを強化する。
  6. ロギング、モニタリング、アラートを設定する。

これらの各タスクの詳細については、Google Cloud への移行: 基盤の計画と構築をご覧ください。

移行に Database Migration Service を使用する場合は、MySQL のネットワーキング方法で、移行シナリオで使用できるネットワーキング構成を確認してください。

モニタリングとアラート

Google Cloud Monitoring には、Cloud SQL モニタリング ダッシュボードなど、いくつかの Google Cloud プロダクト用に事前定義されたダッシュボードが用意されています。また、Datadog や Splunk など、Google Cloud と統合されたサードパーティのモニタリング ソリューションを使用することもできます。詳細については、データベース オブザーバビリティについてをご覧ください。

Amazon RDS と Amazon Aurora for MySQL インスタンスを Cloud SQL for MySQL に移行する

インスタンスを移行するには、次の操作を行います。

  1. 移行戦略（継続的レプリケーションまたは定期メンテナンス）を選択します。

  2. 選択した戦略と要件に応じて、移行ツールを選択します。

  3. 準備と実行のタスクなど、各データベース移行の移行計画とタイムラインを定義します。

  4. 移行ツールが適切に機能するように、準備タスクを定義します。

  5. 実行タスクを定義します。これには、移行を実装する作業アクティビティが含まれます。

  6. 実行タスクごとにフォールバック シナリオを定義します。

  7. テストと検証を行います。これは、別のステージング環境で行うこともできます。

  8. 移行を実行します。

  9. 本番環境のカットオーバーを実施します。

  10. 移行元の環境をクリーンアップし、移行先インスタンスを構成します。

  11. チューニングと最適化を行います。

以降のセクションでは、これらのフェーズについて説明します。

移行戦略を選択する

この時点で、各データベースのユースケースに最適な移行戦略を評価して選択するための十分な情報を取得しているはずです。

  • 定期メンテナンス（1 回限りの移行）: ダウンタイムを許容できる場合は、この方法が理想的です。このオプションでは、ワークロードとサービスのリファクタリングがほとんど必要ないため、費用と複雑さが比較的低くなります。ただし、移行が完了する前に失敗した場合は、プロセスを再開する必要があります。これにより、ダウンタイムが長くなります。

  • 継続的レプリケーション（トリクル移行）: ミッション クリティカルなデータベースの場合、このオプションはデータ損失のリスクが低く、ダウンタイムがほぼゼロになります。作業は複数のチャンクに分割されるため、失敗した場合のロールバックと再試行にかかる時間が短くなります。ただし、設定が複雑になり、より多くの計画と時間が必要になります。データベース インスタンスに接続するアプリケーションをリファクタリングするために、追加の作業が必要になります。次のいずれかのバリエーションを検討してください。

    • Y（書き込み / 読み取り）アプローチを使用する。これは並行移行の一種であり、移行中に移行元インスタンスと移行先インスタンスの両方でデータを複製します。
    • データアクセス マイクロサービスを使用すると、Y（書き込み / 読み取り）アプローチで必要なリファクタリングの労力を削減できます。

データ移行戦略の詳細については、データ移行方法の評価をご覧ください。

次の図は、単一データベースの移行戦略を決定する際に考慮すべき質問の例に基づくフローチャートを示しています。

移行戦略を選択するためのフローチャート。

上のフローチャートには、次の判断ポイントが示されています。

  • ダウンタイムを許容できるかどうか。

    • 「いいえ」の場合は、継続的レプリケーションの移行戦略を採用します。
    • 「はい」の場合、次の判断ポイントに進みます。

  • カットオーバーまでのダウンタイムを許容できるか。カットオーバー ウィンドウは、データベースのバックアップ、Cloud SQL への転送、復元、アプリケーションの切り替えにかかる時間を表します。

    • 「いいえ」の場合は、継続的レプリケーションの移行戦略を採用します。
    • 「はい」の場合は、定期メンテナンスの移行戦略を採用します。

同じインスタンス上にある場合でも、データベースによって戦略が異なる場合があります。戦略を組み合わせることで、最適な結果を得ることができます。たとえば、規模が小さく使用頻度の低いデータベースは定期メンテナンスで移行し、ダウンタイムが発生すると費用がかさむミッション クリティカルなデータベースは継続レプリケーションで移行します。

通常、移行は、最初の移行元インスタンスと移行先インスタンスの切り替えが行われたときに完了したと見なされます。レプリケーション（使用されている場合）は停止し、すべての読み取りと書き込みはターゲット インスタンスで実行されます。両方のインスタンスが同期している状態で切り替えが行われると、データ損失がなく、ダウンタイムが最小限に抑えられます。

データ移行戦略とデプロイの詳細については、データベース移行の分類をご覧ください。

アプリケーションのダウンタイムが発生しない移行構成では、より複雑な設定が必要になります。設定の複雑さと、トラフィックの少ない業務時間帯にスケジュールされたダウンタイムとの間で適切なバランスを見つけます。

各移行戦略には、移行プロセスに関連するトレードオフと影響があります。たとえば、レプリケーション プロセスでは、移行元インスタンスに負荷がかかり、レプリケーション ラグによってアプリケーションに影響が及ぶ可能性があります。アプリケーション（とユーザー）は、新しいデータベースが使用されるまでレプリケーション ラグが続く限り、アプリケーションのダウンタイム中に待機しなければなりません。実際には、次の要因によりダウンタイムが増加する可能性があります。

  • データベース クエリの完了には数秒かかることがあります。移行時に、処理中のクエリが中止される可能性があります。
  • データベースが大きい場合や、バッファメモリが大量にある場合は、キャッシュがいっぱいになるまでに時間がかかることがあります。
  • 移行元で停止し、Google Cloud で再起動したアプリケーションは、Google Cloud データベース インスタンスへの接続が確立されるまで少し遅延が生じることがあります。
  • アプリケーションへのネットワーク ルートを再ルーティングする必要があります。これは、DNS エントリの設定方法によってはある程度時間がかかることがあります。DNS レコードを更新する場合は、移行前に TTL を短くします。

次の一般的な方法を実施すると、ダウンタイムと影響を最小限に抑えることができます。

  • ダウンタイムがワークロードに与える影響を最小限に抑えられる期間を見つけます。たとえば、通常の業務時間外、週末、その他の定期メンテナンスの期間中などです。
  • 移行と本番環境のカットオーバーをさまざまな段階で行うことができるワークロードの部分を特定します。アプリケーションには、影響なく分離、適応、移行できるさまざまなコンポーネントが含まれている場合があります。たとえば、フロントエンド、CRM モジュール、バックエンド サービス、レポート プラットフォームなどです。このようなモジュールには、プロセスの前半または後半に移行をスケジュールできる独自のデータベースが存在する場合があります。
  • ターゲット データベースでレイテンシが発生しても問題ない場合は、段階的な移行の実施を検討してください。増分バッチデータ転送を使用し、ワークロードの一部を調整して、ターゲット インスタンスの古いデータを処理します。
  • 移行の影響を最小限に抑えるために、アプリケーションのリファクタリングを検討してください。たとえば、移行元データベースと移行先データベースの両方に書き込むようにアプリケーションを調整し、アプリケーション レベルでのレプリケーションを実装します。

移行ツールを選択する

移行を成功させるための最も重要な要素は、適切な移行ツールを選択することです。移行戦略が決まったら、移行ツールを確認して決定します。

利用可能なツールは多数あり、それぞれ特定の移行ユースケースに合わせて最適化されています。ユースケースには、次のようなものがあります。

  • 移行戦略（定期メンテナンスまたは継続的レプリケーション）。
  • 移行元と移行先のデータベース エンジンとエンジン バージョン。
  • 移行元インスタンスと移行先インスタンスが配置されている環境。
  • データベース サイズ。データベースが大きくなるほど、最初のバックアップの移行に時間がかかります。
  • データベースの変更頻度。
  • 移行にマネージド サービスを使用できるかどうか。

シームレスな移行とカットオーバーを確実に行うには、アプリケーションのデプロイ パターン、インフラストラクチャ オーケストレーション、カスタム移行アプリケーションを使用します。ただし、マネージド移行サービスと呼ばれる専用のツールを使用すると、データ、アプリケーション、さらにはインフラストラクチャ全体を環境間で移動するプロセスを容易に実施できます。これらのツールは、移行元データベースからデータを抽出して、データを移行先データベースに安全に転送します。また、転送中にデータを変更することもできます。これらの機能により、移行の複雑なロジックをカプセル化し、移行モニタリング機能を利用できます。

マネージド移行サービスには次のような利点があります。

  • ダウンタイムを最小限に抑える: サービスは、利用可能な場合にデータベース エンジンの組み込みレプリケーション機能を使用し、レプリカのプロモーションを実行します。

  • データの整合性とセキュリティを確保する: データは、移行元から移行先のデータベースに安全かつ確実に転送されます。

  • 一貫した移行エクスペリエンスを提供: データベース移行の実行可能ファイルを使用すると、さまざまな移行手法とパターンを一貫した共通インターフェースに統合できます。このインターフェースで管理とモニタリングを行うことができます。

  • 信頼性が高く実績のある移行モデルを提供: データベースの移行は頻繁ではありませんが、重要なイベントです。初歩的なミスや既存のソリューションに関する問題を回避するには、カスタム ソリューションを構築するのではなく、経験豊富な専門家が提供するツールを使用します。

  • 費用を最適化する: カスタム移行ソリューション用に追加のサーバーとリソースをプロビジョニングするよりも、マネージド移行サービスのほうが費用対効果に優れている場合があります。

以降のセクションでは、選択した移行戦略に推奨される移行ツールについて説明します。

定期メンテナンスでの移行用のツール

次の図は、定期メンテナンス移行戦略を採用し、単一データベースの移行ツールを選択する際に役立つ質問とフローチャートを示しています。

定期メンテナンス移行に使用するツールを選択するためのフローチャート。

上のフローチャートには、次の判断ポイントが示されています。

  • マネージド移行サービスが必要かどうか。
    • 「はい」の場合は、Database Migration Service の使用をおすすめします。
    • 「いいえ」の場合は、データベース エンジンの組み込みバックアップを使用して移行することをおすすめします。

このドキュメントの移行ツールを選択するセクションで説明しているように、マネージド移行サービスを使用すると、いくつかのメリットがあります。

以降のサブセクションでは、1 回限りの移行に使用できるツールとその制限事項、ベスト プラクティスについて説明します。

定期メンテナンス移行用の Database Migration Service

Database Migration Service は、初期同期と継続的な変更データ キャプチャ（CDC）レプリケーションの両方を管理し、移行オペレーションのステータスを提供します。

Database Migration Service を使用すると、移行ジョブを作成して管理および検証できます。Database Migration Service を使用することをおすすめします。このサービスでは、1 回限りの移行ジョブによる Cloud SQL for MySQL への移行がサポートされています。大規模なデータベースの場合は、Database Migration Service でデータダンプ並列処理を使用できます。

データベース移行アーキテクチャと Database Migration Service の詳細については、Database Migration Service を使用してデータベースを Cloud SQL for MySQL に移行すると MySQL の移行の忠実度をご覧ください。

Database Migration Service の制限事項と前提条件の詳細については、以下をご覧ください。

組み込みデータベース エンジンのバックアップ

大幅なダウンタイムが許容でき、移行元データベースが比較的静的である場合は、データベース エンジンの組み込みダンプと読み込み（バックアップと復元とも呼ばれます）機能を使用できます。

特にデータベースの数が多い場合は、設定と同期に手間がかかりますが、通常、データベース エンジンのバックアップはすぐに利用可能で、使いやすいものです。

データベース エンジンのバックアップには、次のような一般的な制限があります。

  • バックアップは、特に手動で行う場合はエラーが発生する可能性があります。
  • バックアップが適切に管理されていない場合、データは保護されません。
  • バックアップには適切なモニタリング機能がありません。
  • このツールを使用して多くのデータベースを移行する場合は、スケーリングに労力を要します。

このアプローチを選択する場合は、次の制限事項とベスト プラクティスを考慮してください。

  • データベースが比較的小さい（10 GB 未満）場合は、mysqldump の使用をおすすめします。固定の上限はありませんが、mysqldump の理想的なデータベース サイズは通常 10 GB 未満です。

  • 10 GB を超えるデータベースをインポートする場合は、データベースのダウンタイムを最小限に抑えるために、別の戦略が必要になることがあります。これらの戦略の例を以下に示します。

    • 2 次キーなしで、スキーマとデータをサブセクションにエクスポートします。
    • タイムスタンプを活用する: いずれかのテーブルがタイムスタンプ列を使用している場合は、WHERE 句を指定してタイムスタンプ列によってフィルタできる mysqldump コマンドを使用できます。
    • mydumper ツールや myloader ツールを使用するなどの他の方法も検討してください。

通常、データベース ダンプとバックアップには MySQL ユーザー アカウントは含まれません。移行の準備をする際は、移行元インスタンスのすべてのユーザー アカウントを確認してください。たとえば、ユーザーごとに SHOW GRANTS コマンドを実行して、現在の権限セットを確認し、Cloud SQL で制限されている権限があるかどうかを確認できます。同様に、Percona の pt-show-grants ツールでも付与された権限のリストを確認できます。

Cloud SQL のユーザー権限の制限は、DEFINER 属性を持つデータベース オブジェクトを移行するときに、移行に影響する可能性があります。たとえば、ストアド プロシージャには、Cloud SQL では許可されていないグローバル変数の変更などの SQL コマンドを実行するスーパーユーザー権限を持つ定義者が存在する場合があります。このような場合は、ストアド プロシージャ コードの書き換えや、ストアド プロシージャなどのテーブル以外のオブジェクトの個別の移行が必要になる場合があります。詳細については、データのインポートとエクスポートのベスト プラクティスをご覧ください。

制限事項とベスト プラクティスの詳細については、以下をご覧ください。

定期メンテナンス移行のその他の方法

マネージド インポートを使用して外部 MySQL データベースからのレプリケーションを設定する際、最初に、外部データベースから Cloud SQL インスタンスにデータが読み込まれます。このアプローチでは、外部サーバー（この場合は RDS インスタンス）からデータを抽出し、Cloud SQL インスタンスに直接インポートするサービスを使用します。

大規模なデータベース（数 TB）の場合は、mydumper ツールと myloader ツールを使用するカスタム インポートの初期読み込みを使用すると、より高速に処理できます。

MySQL データベースから CSV ファイルにテーブルをエクスポートし、Cloud SQL for MySQL にインポートすることもできます。RDS インスタンスからデータをエクスポートするには、AWS Database Migration Service（AWS DMS）と S3 バケットをターゲットとして使用できます。

詳細と手順については、マネージド インポートを使用して外部データベースからのレプリケーションを設定するをご覧ください。

継続的レプリケーションの移行ツール

次の図は、継続的レプリケーション移行戦略を採用し、単一データベースの移行ツールを選択する際に役立つ質問とフローチャートを示しています。

継続的レプリケーション移行に使用するツールを選択するためのフローチャート。

上のフローチャートには、次の判断ポイントが示されています。

  • マネージド移行サービスが必要かどうか。

    • 「はい」の場合、データベース内のテーブル数に応じて、書き込みのダウンタイムを数秒間許容できるかどうか。

      • 「はい」の場合、Database Migration Service を使用します。
      • 「いいえ」の場合、他の移行オプションを検討します。

    • 「いいえ」の場合は、データベース エンジンの組み込みレプリケーションがサポートされているかどうかを評価する必要があります。

      • 「はい」の場合は、組み込みレプリケーションを使用することをおすすめします。
      • 「いいえ」の場合は、他の移行オプションを検討することをおすすめします。

以降のセクションでは、継続的な移行に使用できるツールとその制限事項、ベスト プラクティスについて説明します。

継続的レプリケーション移行用の Database Migration Service

Database Migration Service は、継続的移行ジョブタイプを使用して、継続的移行をシームレスにサポートします。プロモートできるのは継続的な移行ジョブのみです。これにより、レプリケーションが停止します。

このツールを選択する場合は、次の制限事項とベスト プラクティスを考慮してください。

  • 移行中に長時間実行されるトランザクションは避けてください。このようなケースで AWS Aurora から移行しない場合は、リードレプリカから移行することをおすすめします。
  • 制限事項の一覧については、既知の制限事項をご覧ください。

データベース エンジンの組み込みレプリケーション

データベース エンジンの組み込みレプリケーションは、継続的な移行を行う Database Migration Service の代替オプションです。

データベース レプリケーションは、プライマリ データベースと呼ばれるデータベースからレプリカと呼ばれる他のデータベースにデータをコピーして分散するプロセスです。データベース システムのデータアクセス可能性を高め、フォールト トレランスと信頼性を向上させることを目的としています。データベース移行はデータベース レプリケーションの主な目的ではありませんが、この目標を達成するためのツールとして使用できます。データベース レプリケーションは通常、プライマリ データベースでデータが挿入、更新、削除されるたびにリアルタイムで実行される継続的なプロセスです。これは、一回限りのオペレーションとして、または一連のバッチ オペレーションとして行うことができます。

最新のデータベース エンジンのほとんどは、データベース レプリケーションを実現するためのさまざまな方法を実装しています。レプリケーションの 1 つのタイプは、プライマリの write-ahead log またはトランザクション ログをコピーしてレプリカに送信することで実現できます。このアプローチは、物理レプリケーションまたはバイナリ レプリケーションと呼ばれます。他のレプリケーション タイプは、ファイル システム レベルの変更をレプリケートするのではなく、プライマリ データベースが受信した SQL ステートメントをそのまま送信することで動作します。

Cloud SQL は MySQL のレプリケーションをサポートしています。ただし、前提条件と制限事項がいくつかあります。

前提条件:

  • Amazon RDS インスタンスまたは Amazon Aurora インスタンスで MySQL 5.5、5.6、5.7、または 8.0 を使用していることを確認します。
  • バイナリログが有効になっていることを確認します。
  • 最初の完全なダンプフェーズを高速化するには、CPU とメモリサイズの観点から十分な大きさのマシン階層を選択します。
  • CDC フェーズを高速化するには、並列レプリケーションを構成して、高パフォーマンスのフラッシュを有効にします。
  • 送信 IP アドレスが静的ではないために Cloud SQL レプリカが内部 IP アドレスで有効になっている場合は、Cloud SQL レプリカがプライベート ネットワークとして使用する VPC ネットワークのプライベート サービス アクセス用に割り振られた内部 IP 範囲を許可するように、Amazon RDS または Amazon Aurora サーバーのファイアウォールを構成します。詳細については、外部サーバーからのレプリケーションについてとプライベート サービス アクセスの構成をご覧ください。

制限事項:

  • データベースにサイズの大きい単一テーブルと多数のセカンダリ インデックスがある場合、最初の完全ダンプには時間がかかることがあります。
  • 外部サーバーに DEFINER 句（ビュー、イベント、トリガー、ストアド プロシージャ）が含まれている場合、これらのステートメントの実行順序によってはレプリケーションが失敗することがあります。Cloud SQL での DEFINER の使用方法と考えられる回避策の詳細をご確認ください。
  • InnoDB は、Cloud SQL でサポートされている唯一のデータベース エンジンです。MyISAM を移行すると、データに不整合が生じる可能性があり、データの検証が必要になることがあります。MyISAM から InnoDB へのテーブルの変換をご覧ください。

継続的レプリケーション移行のその他のアプローチ

継続的レプリケーションの移行方法には、次のようなものがあります。

  • Y（書き込み / 読み取り）を実行するようにアプリケーションをリファクタリングするか、データアクセス マイクロサービスを使用します。

    • 継続的レプリケーションはアプリケーションによって実行されます。
    • 移行作業では、データベース インスタンスに接続するツールのリファクタリングまたは開発に重点を置きます。
    • その後、リーダー アプリケーションを段階的にリファクタリングし、ターゲット インスタンスを使用するようにデプロイします。

  • Datastream を使用して、MySQL インスタンスの変更をほぼリアルタイムでレプリケートします。

    • Datastream は、Amazon RDS または Amazon Aurora と一緒に使用し、データのレプリケートと同期を実行できるサーバーレスの CDC とレプリケーション サービスです。
    • Datastream を使用して MySQL インスタンスから BigQuery または Cloud Storage に変更をレプリケートし、Dataflow または Dataproc を使用してデータを Cloud SQL インスタンスに転送します。

Datastream を使用したレプリケーションの詳細については、以下をご覧ください。

継続的レプリケーション移行のサードパーティ ツール

場合によっては、データベース エンジンに 1 つのサードパーティ ツールを使用するほうが適していることがあります。このようなケースとしては、マネージド移行サービスを使用し、ターゲット データベースが常に移行元とほぼリアルタイムで同期されるようにする必要がある場合や、移行プロセス中にデータのクリーニング、再構造化、適応などのより複雑な変換が必要な場合などがあります。

サードパーティ ツールを使用する場合は、次のいずれかをおすすめします。このツールは、ほとんどのデータベース エンジンで使用できます。

Striim は、データをリアルタイムで収集、フィルタリング、変換、拡充、集計、分析、配信するためのエンドツーエンドのインメモリ プラットフォームです。

  • メリット:

    • 大量のデータと複雑な移行に対応。
    • SQL Server の組み込み変更データ キャプチャ。
    • 事前構成済みの接続テンプレートとノーコード パイプライン。
    • 大量のトランザクション ロードで動作するミッション クリティカルな大規模なデータベースに対応。
    • 1 回限りの配信。

  • デメリット:

Striim の詳細については、Google Cloud での Striim の実行をご覧ください。

Debezium は CDC 用のオープンソース分散プラットフォームであり、外部サブスクライバーにデータ変更をストリーミングできます。

  • メリット:

    • オープンソースである。
    • 万全のコミュニティ サポート。
    • 優れた費用対効果。
    • 行、テーブル、データベースに対するきめ細かい制御。
    • データベース トランザクション ログからリアルタイムで変更をキャプチャするように特化されている。

  • デメリット:

    • Kafka と ZooKeeper に関する特定の経験が必要。
    • データ変更を 1 回以上配信。つまり、重複の処理が必要になります。
    • Grafana と Prometheus を使用してモニタリングを手動で設定。
    • 増分バッチ レプリケーションは非対応。

Debezium の移行の詳細については、Debezium を使用したニアリアルタイム データ レプリケーションをご覧ください。

Fivetran は、クラウド データ プラットフォームからデータを移動したり、複数のクラウド データ プラットフォーム間でデータを移動するための自動データ移動プラットフォームです。

  • メリット:

    • 事前構成済みの接続テンプレートとノーコード パイプライン。
    • スキーマの変更を移行元から移行先データベースに反映。
    • データ変更の 1 回限りの配信。つまり、重複の処理は必要ありません。

  • デメリット:

    • オープンソースではない。
    • 複雑なデータ変換のサポートは制限付き。

移行計画とタイムラインを定義する

データベースの移行と本番環境へのカットオーバーを成功させるには、明確で包括的な移行計画を準備することをおすすめします。ビジネスへの影響を軽減するために、必要なすべての作業項目のリストを作成することをおすすめします。

移行の範囲を定義すると、データベース移行プロセスの前、最中、移行後に必要な作業タスクが明らかになります。たとえば、データベースから特定のテーブルを移行しない場合は、このフィルタを実装するために移行前または移行後のタスクが必要になることがあります。また、データベースの移行が既存のサービスレベル契約（SLA）と事業継続計画に影響しないようにします。

移行計画のドキュメントには、次のドキュメントを含めることをおすすめします。

  • 技術設計ドキュメント（TDD）
  • RACI 図
  • タイムライン（T-Minus プランなど）

データベースの移行は反復的なプロセスであり、最初の移行は後続の移行よりも時間がかかることがよくあります。通常、計画的な移行は問題なく実行されますが、想定外のトラブルが発生することもあります。常にロールバック計画を用意することをおすすめします。ベスト プラクティスとして、Google Cloud への移行: 移行計画の検証に関するベスト プラクティスのガイダンスに従うことをおすすめします。

TDD

TDD には、プロジェクトで行うすべての技術的な決定が文書化されます。TDD には、以下のものを記述します。

  • ビジネス要件と重要性
  • 目標復旧時間（RTO）
  • 目標復旧時点（RPO）
  • データベースの移行の詳細
  • 移行に必要な作業の見積もり
  • 移行の検証に関する推奨事項

RACI 図

移行プロジェクトによっては、RACI マトリックスが必要になる場合があります。RACI マトリックスは、移行プロジェクト内のタスクと成果物に対する責任を負う個人またはグループを定義する一般的なプロジェクト管理ドキュメントです。

タイムライン

移行が必要な各データベースのタイムラインを準備します。実施する必要のあるすべての作業タスクと、その開始日と終了予定日を定義します。

移行環境ごとに T-minus プランを作成することをおすすめします。T-minus プランはカウントダウン スケジュールとして構成され、移行プロジェクトの完了に必要なすべてのタスクと、担当グループ、推定所要時間を示します。

タイムラインには、移行前の準備タスクの実施だけでなく、データ転送後に実施される検証、監査、テストのタスクも考慮する必要があります。

移行タスクにかかる時間は通常、データベースのサイズに依存しますが、ビジネス ロジックの複雑さ、アプリケーションの使用状況、チームの空き状況など、ほかにも考慮すべき点があります。

T-Minus プランは次のようになります。

日付 フェーズ カテゴリ タスク ロール T-minus ステータス
11/1/2023 移行前 評価 評価レポートを作成する ディスカバリ チーム -21 完了
11/7/2023 移行前 ターゲットの準備 設計ドキュメントに従って移行先の環境を設計する 移行チーム -14 完了
11/15/2023 移行前 会社のガバナンス 移行日と T-Minus の承認 リーダー -6 完了
11/18/2023 移行 DMS を設定する 接続プロファイルを作成する クラウド移行エンジニア -3 完了
11/19/2023 移行 DMS を設定する 移行ジョブをビルドして開始する クラウド移行エンジニア -2 未開始
11/19/2023 移行 DMS をモニタリングする 移行元インスタンスの DMS ジョブと DDL の変更をモニタリングする クラウド移行エンジニア -2 未開始
11/21/2023 移行 DMS をカットオーバーする DMS レプリカをプロモートする クラウド移行エンジニア 0 未開始
11/21/2023 移行 移行の検証 データベースの移行の検証 移行チーム 0 未開始
11/21/2023 移行 アプリケーション テスト 機能テストとパフォーマンス テストを実行する 移行チーム 0 未開始
11/22/2023 移行 会社のガバナンス 移行の検証: 可否 移行チーム 1 未開始
11/23/2023 移行後 モニタリングを検証する モニタリングを構成する インフラストラクチャ チーム 2 未開始
11/25/2023 移行後 セキュリティ DMS ユーザー アカウントを削除する セキュリティ チーム 4 未開始

複数のデータベースの移行

移行するデータベースが複数ある場合は、移行計画にすべての移行タスクを含める必要があります。

移行プロセスを開始する際は、小規模なデータベース（できればミッション クリティカルでないデータベース）を移行することをおすすめします。このアプローチにより、移行プロセスとツールに関する知識と自信を深めることができます。移行全体のスケジュールの早い段階で、プロセスの欠陥を検出することもできます。

移行するデータベースが複数ある場合は、タイムラインを並列化できます。たとえば、移行プロセスを高速化するために、次の図に示すように、小規模なデータベース、静的データベース、または重要度の低いデータベースのグループを同時に移行できます。

並列データベース移行タスク。

図の例では、データベース 1～4 は、同時に移行される小規模データベースのグループです。

準備タスクを定義する

準備タスクは、移行の前提条件を満たすために完了する必要があるすべてのアクティビティです。準備タスクがないと、移行を実行できません。また、移行を行っても、移行後のデータベースが使用できなくなります。

準備タスクは、次のように分類できます。

  • Amazon RDS または Amazon Aurora インスタンスの準備と前提条件
  • 移行元データベースの準備と前提条件
  • Cloud SQL の設定
  • 移行固有の設定

Amazon RDS または Amazon Aurora インスタンスの準備と前提条件

次の一般的な設定と前提条件のタスクを検討してください。

  • 移行パスによっては、RDS インスタンスでのリモート接続の許可が必要になる場合があります。RDS インスタンスが VPC でプライベートに構成されている場合は、Amazon と Google Cloud の間にプライベート RFC 1918 接続が必要です。

  • 必要なポートでリモート接続を許可するように、新しいセキュリティ グループの構成が必要になる場合があります。

    • AWS では、デフォルトでデータベース インスタンスのネットワーク アクセスが無効になっています。
    • セキュリティ グループで、IP アドレス範囲、ポート、またはセキュリティ グループからのアクセスを許可するルールを指定できます。同じルールが、そのセキュリティ グループに関連付けられているすべてのデータベース インスタンスに適用されます。

  • Amazon RDS インスタンスの完全読み込み中に WAL ログをバッファリングするための十分な空きディスク容量があることを確認します。

  • 最適な移行結果を得るには、Amazon Aurora から移行する場合を除き、読み取りレプリカから移行することを検討してください。また、データベース アクティビティが少ない時間帯に移行プロセスを開始することをおすすめします。

  • MySQL では、ホスト名が 60 文字に制限されています。Amazon RDS データベースのホスト名は通常、60 文字を超えます。移行するデータベースがこれに該当する場合は、DNS リダイレクトを構成して、ドメイン名を RDS データベース インスタンスのドメイン名に関連付ける CNAME レコードを作成します。

  • 組み込みレプリケーションを使用している場合は、レプリケーション用に Amazon RDS または Amazon Aurora インスタンスを設定する必要があります。組み込みレプリケーションまたはそれを使用するツールでは、MySQL のバイナリ ロギングを ROW に設定する必要があります。

  • サードパーティ ツールを使用する場合は、通常、ツールを使用する前に事前設定と構成が必要です。サードパーティ ツールのドキュメントを確認してください。

インスタンスの準備と前提条件の詳細については、MySQL のレプリケーション用に外部サーバーを設定するをご覧ください。

移行元データベースの準備と前提条件

  • Database Migration Service を使用する場合は、移行元データベースに接続する前に、移行元データベースを構成する必要があります。ジョブを実装する前に、移行ジョブを確認します。詳細については、MySQL のソースを構成するをご覧ください。
  • データベース エンジンによっては、特定の機能の変更が必要になる場合があります。たとえば、Cloud SQL for MySQL は InnoDB データベース エンジンのみをサポートしています。MyISAM テーブルを InnoDB に変更する必要があります。
  • 一部のサードパーティ移行ツールでは、すべての LOB 列が null 可能である必要があります。NOT NULL である LOB 列は、移行中にその制約を削除する必要があります。

  • 本番環境で移行元環境のベースラインを測定します。次の点を考慮してください。

    • データのサイズとワークロードのパフォーマンスを測定します。重要なクエリまたはトランザクションに平均でどのくらいの時間がかかるか。ピーク時は何分間か。
    • ベースライン測定値を記録して後で比較し、データベース移行の忠実度が十分かどうかを判断できるようにします。本番環境ワークロードを切り替えて移行元の環境を廃止できるかどうか、またはフォールバック用に引き続き必要かどうかを判断します。

Cloud SQL の設定

同様のパフォーマンス要件を満たすため、ターゲット Cloud SQL for MySQL データベース インスタンスに移行元と一致するサイズと仕様を慎重に選択します。ディスクサイズとスループット、IOPS、vCPU の数に特に注意してください。サイズが適切でないと、移行に時間がかかったり、データベースのパフォーマンスの問題、データベース エラー、アプリケーションのパフォーマンスの問題が発生する可能性があります。

Cloud SQL インスタンスを作成する前に、次のプロパティと要件を確認する必要があります。後で変更する場合は、再作成する必要があります。

  • ターゲット Cloud SQL インスタンスのプロジェクトとリージョンは慎重に選択してください。Cloud SQL インスタンスは、データ転送なしで Google Cloud プロジェクトとリージョン間で移行することはできません。
  • Cloud SQL で一致するメジャー バージョンに移行します。たとえば、ソースで Amazon RDS または Amazon Aurora の MySQL 8.0.34 を使用している場合は、Cloud SQL for MySQL バージョン 8.0.34 に移行する必要があります。
  • 組み込みデータベース エンジンのバックアップまたは Database Migration Service を使用している場合は、ユーザー情報を個別にレプリケートします。Cloud SQL では Google IAM を使用してユーザーを管理します。詳細については、組み込みデータベース エンジンのバックアップのセクションの制限事項をご覧ください。
  • データベース エンジン構成フラグを調べ、移行元と移行先のインスタンスの値を比較します。これらの影響を把握し、同程度の影響にする必要があるかどうかを判断します。たとえば、移行前に移行元データベースで SHOW VARIABLES コマンドを実行し、Cloud SQL データベースで再度実行することをおすすめします。移行元の設定をレプリケートするように、Cloud SQL データベースで必要に応じてフラグの設定を更新します。Cloud SQL インスタンスで使用できる MySQL フラグは一部です。

Cloud SQL の設定の詳細については、以下をご覧ください。

移行固有の設定

SQL ダンプファイルを Cloud SQL にインポートする場合は、Cloud Storage バケットの作成が必要になることがあります。バケットにはデータベース ダンプを保存します。

レプリケーションを使用する場合は、Cloud SQL レプリカがプライマリ データベースにアクセスできるようにする必要があります。このアクセスは、ドキュメントに記載されている接続オプションで実現できます。

シナリオと重大度によっては、フォールバック シナリオの実装が必要になります。通常、これはレプリケーションと逆方向になります。この場合、Cloud SQL から移行元の Amazon インスタンスへのレプリケーション メカニズムが必要になることがあります。

ほとんどのサードパーティ ツールの場合、移行固有のリソースをプロビジョニングする必要があります。たとえば、Striim の場合は、Google Cloud Marketplace を使用して開始する必要があります。次に、Striim で移行環境を設定します。その際、Flow Designer を使用してアプリケーションを作成または変更するか、既存のテンプレートを選択します。アプリケーションは、Tungsten Query Language（TQL）プログラミング言語を使用してコーディングすることもできます。データ検証ダッシュボードを使用すると、Striim アプリケーションによって処理されるデータを視覚的に確認できます。

移行が完了して検証されたら、Amazon 環境と Google Cloud 環境を接続するリソースを廃止できます。

詳しくは以下をご覧ください。

実行タスクを定義する

実行タスクは移行作業自体を実装します。タスクは、次のサブセクションで説明するように、選択した移行ツールによって異なります。

組み込みデータベース エンジンのバックアップ

1 回限りの移行を行うには、mysqldump ユーティリティを使用してバックアップを作成します。これにより、Amazon RDS からローカル クライアント コンピュータにデータがコピーされます。手順については、Cloud SQL for MySQL に SQL ダンプファイルをインポートするをご覧ください。

Cloud SQL インスタンスのインポートとエクスポートのオペレーションのステータスを確認できます。

Database Migration Service の移行ジョブ

移行元インスタンスから移行先データベースにデータを移行するには、Database Migration Service で移行ジョブを定義して構成します。移行ジョブは、ユーザー定義の接続プロファイルを介して移行元データベース インスタンスに接続します。

すべての前提条件をテストして、ジョブが正常に実行できることを確認します。ワークロードで移行と本番環境へのカットオーバーに短いダウンタイムを許容できる時間を選択します。

Database Migration Service では、移行は最初の完全バックアップと読み込みから始まり、その後、移行元から移行先のデータベース インスタンスへの変更が継続的に適用されます。

Database Migration Service では、最初の完全ダンプを一貫した方法で実行するために、移行元の Amazon RDS または Amazon Aurora インスタンス内のすべてのテーブルに対する読み取りロックを取得しますが、これに数秒かかります。読み取りロックを取得するには、1～49 秒の書き込みのダウンタイムが必要になる場合があります。ダウンタイムは、データベース内のテーブルの数によって異なります。1 秒は 100 テーブルに相当し、9 秒は 10,000 テーブルに相当します。

Database Migration Service による移行プロセスは、プロモート オペレーションで終了します。データベース インスタンスをプロモートすると、移行先データベースが移行元データベースからの変更フローと切断され、スタンドアロンの移行先インスタンスがプライマリ インスタンスにプロモートされます。このアプローチは、本番環境への切り替えとも呼ばれます。

Database Migration Service の移行ジョブの詳細については、以下をご覧ください。

移行の設定プロセスの詳細については、Database Migration Service を使用してデータベースを Cloud SQL for MySQL に移行するをご覧ください。Database Migration Service では、移行ジョブを開始して実行することで移行を行います。

データベース エンジンの組み込みレプリケーション

Amazon RDS から外部の Cloud SQL for MySQL インスタンスへの組み込みレプリケーションを使用できます。

MySQL の場合は、まず Cloud Storage バケットに保存できる初期ダンプから開始し、データを Cloud SQL for MySQL にインポートする必要があります。次に、レプリケーション プロセスを開始します。

レプリケーションをモニタリングし、適切なタイミングで移行元インスタンスでの書き込みを停止します。レプリケーションのステータスを再度確認して、すべての変更がレプリケートされたことを確認してから、Cloud SQL for MySQL レプリカをスタンドアロン インスタンスにプロモートして移行を完了します。

Amazon RDS や Amazon Aurora for MySQL などの外部サーバーからの組み込みレプリケーションを設定する方法については、外部サーバーからのレプリケーションについてとレプリケーション用に Cloud SQL と外部サーバーを構成するをご覧ください。

詳細とガイダンスについては、以下をご覧ください。

サードパーティ ツール

選択したサードパーティ ツールの実行タスクを定義します。

このセクションでは、例として Striim について説明します。Striim は、さまざまなソースからデータを取得して処理し、他のアプリケーションまたはターゲットにデータを配信するアプリケーションを使用します。

アプリケーションは、ウェブ クライアントを使用してグラフィカルに作成できます。このアプリケーションでは、ソース、ターゲット、その他の論理コンポーネントが 1 つ以上のフローに編成されています。

Striim で移行環境を設定するには、Flow Designer 機能を使用してアプリケーションを作成および変更するか、既存のテンプレートから選択します。アプリケーションは、TQL プログラミング言語を使用してコーディングすることもできます。

データ検証ダッシュボードを使用すると、Striim アプリケーションで処理されるデータを視覚的に確認できます。

Google Cloud で Striim のクイックスタートを行うには、Google Cloud で Striim を実行するをご覧ください。Striim の基本的なコンセプトの詳細については、Striim のコンセプトをご覧ください。初期読み込みから継続的レプリケーションへの切り替えに関するベスト プラクティス ガイドも必ずご覧ください。

データ移行では、次のベスト プラクティスを検討してください。

  • 各計画ステップの開始と終了を関係チームに通知します。
  • いずれかのステップで予想よりも時間がかかる場合は、経過時間を各ステップに割り当てられた最大時間と比較します。このような場合は、関係するチームに定期的に中間情報を提供します。
  • 時間範囲が、計画の各ステップに予約されている最大時間を超える場合は、ロールバックを検討してください。
  • 移行とカットオーバーの計画の各ステップについて、実施するかどうかを判断します。
  • 各ステップについて、ロールバック アクションや代替シナリオを検討します。

フォールバック シナリオを定義する

移行プロセス中に発生する可能性のある予期しない問題に備えて、移行の実行タスクごとにフォールバック アクションを定義します。通常、フォールバック タスクは、使用される移行戦略とツールによって異なります。

フォールバックには多大な労力が必要になる場合があります。満足のいくテスト結果になるまで、本番環境への切り替えは行わないことをおすすめします。データベースの移行とフォールバック シナリオの両方を適切にテストして、重大なサービス停止を回避する必要があります。

成功基準を定義し、すべての移行実行タスクにタイムボックスを設定します。移行のドライランを行うと、各タスクの所要時間に関する情報を収集できます。たとえば、定期メンテナンス移行の場合は、カットオーバー時間枠で示されるダウンタイムを許容できます。ただし、1 回限りの移行ジョブまたはバックアップの復元が途中で失敗した場合に備えて、次のアクションを計画しておくことが重要です。移行タスクが想定時間内に完了しない場合、計画されたダウンタイムの期間に応じて、移行を延期する必要があります。

通常、フォールバック計画とは、本番環境へのカットオーバー後に、ターゲット インスタンスで問題が発生した場合に移行をロールバックすることを指します。フォールバック計画を実装する場合は、計画とテストを含む完全なデータベース移行として扱う必要があります。

フォールバック計画を用意しない場合は、その結果について十分に理解しておく必要があります。フォールバック計画がないと、予期しない作業が増え、移行プロセスに不要な中断が生じる可能性があります。

フォールバックは最終手段であり、ほとんどのデータベース移行では使用されませんが、フォールバック戦略を常に用意することをおすすめします。

シンプルなフォールバック

このフォールバック戦略では、アプリケーションを元の移行元データベース インスタンスに戻します。この戦略は、フォールバック時のダウンタイムを許容できる場合、または新しいターゲット システムでトランザクションを commit する必要がない場合に採用します。

ターゲット データベースに書き込まれたすべてのデータが必要で、ダウンタイムを許容できる場合は、ターゲット データベース インスタンスへの書き込みを停止してから、組み込みバックアップを取得して移行元インスタンスに復元し、アプリケーションを元の移行元データベース インスタンスに再接続することを検討してください。ワークロードの性質とターゲット データベース インスタンスに書き込まれるデータの量によっては、後で最初の移行元データベース システムに移行できます（特に、ワークロードが特定のレコード作成時間や時間順序の制約に依存していない場合）。

リバース レプリケーション

この戦略では、本番環境の切り替え後に新しいターゲット データベースで発生した書き込みを、移行元データベースにレプリケートします。これにより、移行元と新しいターゲット データベースの同期が維持され、新しいターゲット データベース インスタンスで書き込みが行われます。主な欠点は、ターゲット データベース インスタンスにカットオーバーするまでレプリケーション ストリームをテストできないことです。そのため、エンドツーエンドのテストは行えず、フォールバックのない期間が短くなります。

この方法は、移行元のインスタンスをしばらく保持し、継続的レプリケーション移行で移行する場合に選択します。

フォワード レプリケーション

この戦略は、リバース レプリケーションのバリエーションです。新しいターゲット データベースの書き込みを、任意のサードパーティ データベース インスタンスにレプリケートします。アプリケーションをこのサードパーティ データベースに接続し、サーバーを使用できないときにサーバーへの接続と読み取り専用クエリの実行を行うことができます。ニーズに応じて、任意のレプリケーション メカニズムを使用できます。このアプローチの利点は、エンドツーエンドで完全にテストできることです。

このアプローチは、常にフォールバックでカバーする場合や、本番環境への切り替え直後に最初の移行元データベースを破棄する必要がある場合に使用します。

重複書き込み

Y（書き込み / 読み取り）またはデータアクセス マイクロサービスの移行戦略を選択した場合、このフォールバック計画はすでに設定されています。この戦略は、アプリケーションをリファクタリングするか、データベース インスタンスに接続するツールを開発する必要があるため、より複雑です。

アプリケーションは、最初の移行元データベース インスタンスとターゲット データベース インスタンスの両方に書き込みます。これにより、ターゲット データベース インスタンスのみを使用するまで、段階的に本番環境への移行を実行できます。問題が発生した場合は、ダウンタイムなしでアプリケーションを元の移行元に接続します。問題が発生していない移行が完了したと判断した場合は、元の移行元との重複書き込みを破棄できます。

この方法は、移行のダウンタイムが許容できない場合、信頼性の高いフォールバックが存在する場合、アプリケーションのリファクタリングを行う時間とリソースがある場合におすすめします。

テストと検証を実施する

このステップの目標は、次の項目をテストして検証することです。

  • データベース内のデータの移行が正常に完了したこと。
  • 新しいターゲット インスタンスを使用するように切り替えた後、既存のアプリケーションとの統合。

移行に固有の重要な成功要因を定義します。要因の例を次に示します。

  • 移行するデータ。一部のワークロードでは、すべてのデータを移行する必要はありません。すでに集計されているデータ、冗長なデータ、アーカイブされているデータ、古いデータは移行しない場合があります。バックアップとして、そのデータを Cloud Storage バケットにアーカイブできます。
  • 許容できるデータ損失の割合。これは、分析ワークロードに使用されるデータに特に当てはまります。データの一部が失われても、ワークロードの一般的な傾向やパフォーマンスに影響しません。
  • データの品質と量の基準。移行後に移行元環境に適用して移行先環境と比較できます。
  • パフォーマンス基準。一部のビジネス トランザクションは移行先の環境で遅くなる可能性がありますが、処理時間は定義された期待値内です。

移行元環境のストレージ構成が Google Cloud 環境のターゲットに直接マッピングされない場合があります。たとえば、IOPS バースト パフォーマンスの汎用 SSD（gp2 と gp3）ボリュームの構成や、プロビジョニングされた IOPS SSD の構成などです。移行先インスタンスを比較して適切なサイズを決定するには、評価フェーズと検証フェーズの両方で移行元インスタンスをベンチマークします。

ベンチマーク プロセスでは、本番環境のようなオペレーションのシーケンスをデータベース インスタンスに適用します。この期間中に、指標をキャプチャして処理し、移行元システムと移行先システムの相対的なパフォーマンスを測定して比較します。

従来のサーバーベースの構成の場合は、ピーク負荷時に観測された関連する測定値を使用します。Aurora Serverless などの柔軟なリソース容量モデルの場合は、過去の指標データを使用して、スケーリングのニーズを確認することを検討してください。

テスト、検証、データベース ベンチマークには、次のツールを使用できます。

  • HammerDB: オープンソースのデータベース ベンチマークと負荷テストツール。複数のデータベース エンジン（TPROC-C と TPROC-H の両方）で、業界標準に基づく複雑なトランザクション ワークロードと分析ワークロードをサポートします。HammerDB には詳細なドキュメントと幅広いユーザー コミュニティがあります。複数のデータベース エンジンとストレージ構成で結果を共有して比較できます。詳細については、HammerDB を使用した SQL Server の負荷テストと HammerDB を使用した Amazon RDS SQL Server のパフォーマンスのベンチマークをご覧ください。
  • DBT2 ベンチマーク ツール: MySQL に特化したベンチマーク。データベース ワークロード キットのセットは、ウェアハウスを所有する会社のアプリケーションを模倣しています。ここでは、読み取りトランザクションと書き込みトランザクションが混在しています。既製のオンライン トランザクション処理（OLTP）負荷テストを使用する場合は、このツールを使用します。
  • DbUnit: Java でリレーショナル データベースのインタラクションをテストするために使用されるオープンソースの単体テストツール。設定と使用は簡単で、複数のデータベース エンジン（MySQL、PostgreSQL、SQL Server など）をサポートしています。ただし、データベースのサイズと複雑さに応じて、テストの実行が遅くなることがあります。シンプルさが重要である場合は、このツールをおすすめします。
  • DbFit: テスト駆動型のコード開発と自動テストをサポートするオープンソース データベース テスト フレームワーク。基本的な構文を使用して、テストケースの作成。データドリブン テスト、バージョン管理、テスト結果のレポート機能を実行します。ただし、複雑なクエリとトランザクションのサポートは限定的であり、他のツールと比較して、コミュニティ サポートやドキュメントが充実していません。このツールは、クエリが複雑ではなく、自動テストを実行して継続的インテグレーションとデリバリー プロセスと統合する場合におすすめします。

移行計画のテストなど、エンドツーエンドのテストを実行するには、必ず移行のドライランを実施します。ドライランでは、本番環境のワークロードを切り替えることなく、フルスコープのデータベース移行を実行します。ドライランには次のような利点があります。

  • すべてのオブジェクトと構成が適切に移行されていることを確認できます。
  • 移行テストケースの定義と実行に役立ちます。
  • 実際の移行に必要な時間に関する分析結果に基づいて、タイムラインを調整できます。
  • 移行計画のテスト、検証、適応を行うタイミングを確認できます。すべてを事前に計画できない場合もあるため、ギャップを見つけるのに役立ちます。

データテストは、移行するデータベースの小さなセットまたはセット全体に対して実行できます。データベースの総数と移行に使用するツールに応じて、リスクベースのアプローチを採用できます。この方法では、同じツールで移行されたデータベースのサブセットに対してデータ検証を行います（特に、ツールがマネージド移行サービスの場合）。

テストでは、移行元と移行先の両方のデータベースにアクセスして、次のタスクを行う必要があります。

  • 移行元と移行先のスキーマを比較します。すべてのテーブルと実行可能ファイルが存在するかどうかを確認します。行数を確認し、データベース レベルでデータを比較します。
  • カスタムデータ検証スクリプトを実行します。
  • 移行されたデータが、ターゲット データベースの使用に切り替えたアプリケーションでも表示されること（移行されたデータがアプリケーションから読み取られること）を確認します。
  • さまざまなユースケースをテストして、切り替えられたアプリケーションとターゲット データベースの統合テストを行います。このテストでは、アプリケーションを介してターゲット データベースにデータを読み書きします。これにより、ワークロードは、移行されたデータと新しく作成されたデータを完全にサポートします。
  • 最も使用頻度の高いデータベース クエリのパフォーマンスをテストして、構成ミスやサイズの設定エラーによるパフォーマンスの低下がないか確認します。

これらの移行テストのシナリオはすべて自動化され、任意のソースシステムで再現可能であることが理想的です。自動テストケース スイートは、切り替えられたアプリケーションに対して実行されるように適応されています。

移行ツールとして Database Migration Service を使用している場合は、移行を確認するをご覧ください。

データ検証ツール

データ検証を行う場合は、データ検証ツール（DVT）を使用することをおすすめします。DVT は、Google がサポートするオープンソースの Python CLI ツールです。さまざまな環境での検証を自動化し、再現性のあるソリューションを提供します。

DVT は、移行元と移行先のテーブルをテーブルレベル、列レベル、行レベルで比較するカスタマイズ可能なマルチレベル検証機能を提供することで、データ検証プロセスを合理化します。検証ルールを追加することもできます。

DVT は、AlloyDB for PostgreSQL、BigQuery、Cloud SQL、Spanner、Cloud Storage 上の JSON ファイルや CSV ファイルなど、多くの Google Cloud データソースに対応しています。また、Cloud Run 関数と Cloud Run と統合して、イベントベースのトリガーとオーケストレーションを行うこともできます。

DVT は、次のタイプの検証をサポートしています。

  • スキーマレベルの比較
  • 列（AVG、COUNT、SUM、MIN、MAX、GROUP BY、STRING_AGG など）
  • 行（フィールドの比較でのハッシュと完全一致を含む）
  • カスタムクエリの結果の比較

DVT の詳細については、Git リポジトリと Google Cloud のデータ検証ツールで簡単にデータ検証を行うをご覧ください。

移行を実行する

移行タスクには、あるシステムから別のシステムへの転送をサポートするアクティビティが含まれます。

データ移行では、次のベスト プラクティスを検討してください。

  • 計画のステップの開始と終了を関係チームに通知します。
  • いずれかのステップで予想よりも時間がかかる場合は、経過時間をそのステップに割り当てられた最大時間と比較します。このような場合は、関係するチームに定期的に中間情報を提供します。
  • 時間範囲が、計画の各ステップに予約されている最大時間を超える場合は、ロールバックを検討してください。
  • 移行とカットオーバーの計画の各ステップについて、実施するかどうかを判断します。
  • 各ステップについて、ロールバック アクションや代替シナリオを検討します。

定義済みの実行タスクに従って移行を実行し、選択した移行ツールのドキュメントを参照します。

本番環境のカットオーバーを実施する

本番環境へのカットオーバーの概要プロセスは、選択した移行戦略によって異なります。ワークロードのダウンタイムを許容できる場合は、移行元データベースへの書き込みを停止して、移行の切り替えを開始します。

継続的レプリケーションの移行では、通常、カットオーバー プロセスで次の操作を行います。

  • 移行元データベースへの書き込みを停止します。
  • ソースをドレインします。
  • レプリケーション プロセスを停止します。
  • 新しいターゲット データベースを指すアプリケーションをデプロイします。

選択した移行ツールを使用してデータを移行したら、移行先データベースのデータを検証します。移行元データベースと移行先データベースが同期されており、移行先インスタンスのデータが、選択した移行成功基準を満たしていることを確認します。

データ検証が基準を満たしたら、アプリケーション レベルのカットオーバーを実行できます。新しいターゲット インスタンスを使用するようにリファクタリングされたワークロードをデプロイします。新しいターゲット データベース インスタンスを指すアプリケーションのバージョンをデプロイします。デプロイは、ローリング アップデート、ステージング リリース、または Blue/Green デプロイ パターンを使用して実行できます。アプリケーションのダウンタイムが発生する可能性があります。

本番環境への切り替えに関するベスト プラクティスに従います。

  • カットオーバー後にターゲット データベースで動作するアプリケーションをモニタリングします。
  • モニタリング期間を定義して、フォールバック計画を実装する必要があるかどうかを検討します。
  • 一部のデータベース フラグを変更した場合は、Cloud SQL または AlloyDB for PostgreSQL インスタンスの再起動が必要になることがあります。
  • 移行をロールバックする作業は、ターゲット環境に現れる問題を修正するよりも手間がかかる場合があることを考慮してください。

移行元の環境をクリーンアップし、Cloud SQL または AlloyDB for PostgreSQL インスタンスを構成する

カットオーバーが完了したら、移行元データベースを削除できます。移行元のインスタンスのクリーンアップを行う前に、次の重要な操作を行うことをおすすめします。

  • 各移行元データベースの最終的なバックアップを作成します。これらのバックアップにより、移行元データベースの最終状態が提供されます。一部のデータ規制を遵守するために、バックアップが必要な場合もあります。

  • 移行元インスタンスのデータベース パラメータ設定を収集します。または、インベントリ作成フェーズで収集したデータと一致していることを確認します。移行元インスタンスのパラメータと一致するように移行先インスタンスのパラメータを調整します。

  • 移行元インスタンスからデータベース統計情報を収集し、移行先インスタンスの統計情報と比較します。統計情報が異なる場合、移行元インスタンスと移行先インスタンスのパフォーマンスを比較するのは困難です。

フォールバック シナリオでは、Cloud SQL インスタンスに対する書き込みのレプリケーションを元の移行元データベースに実装することをおすすめします。この設定は移行プロセスに似ていますが、逆方向に実行されます。つまり、最初の移行元データベースが新しいターゲットになります。

カットオーバー後に移行元インスタンスを最新の状態に保つためのベスト プラクティスとして、ターゲット Cloud SQL インスタンスで実行された書き込みを移行元データベースにレプリケートすることをおすすめします。ロールバックが必要な場合は、データ損失を最小限に抑えて古い移行元インスタンスにフォールバックできます。

移行元の環境のクリーンアップに加えて、Cloud SQL インスタンスに次の重要な構成を行う必要があります。

  • 中断更新がいつ発生するかを制御するため、プライマリ インスタンスのメンテナンスの時間枠を構成してください。
  • Cloud SQL が実行する可能性のある重要なデータベース メンテナンス オペレーションに対応できるよう、少なくとも 20% の空き容量を確保するようにインスタンスのストレージを構成します。使用可能なディスク容量が 20% を下回った場合にアラートを受信するには、ディスク使用率指標に対して指標ベースのアラート ポリシーを作成します。

前のオペレーションが完了する前に管理オペレーションを開始しないでください。

メンテナンスとベスト プラクティスの詳細については、Cloud SQL インスタンスでのメンテナンスについてをご覧ください。

移行後の環境を最適化する

最適化が移行の最終フェーズになります。このフェーズではターゲット環境が最適化の要件を満たすまで最適化タスクを繰り返します。このイテレーションの手順は次のとおりです。

  1. 現在の環境、チーム、最適化ループを評価する。
  2. 最適化の要件と目標を設定する。
  3. 環境とチームを最適化する。
  4. 最適化ループを調整する。

最適化の目標を達成するまで、このシーケンスを繰り返します。

Google Cloud 環境の最適化の詳細については、Google Cloud への移行: 環境の最適化とパフォーマンスの最適化プロセスをご覧ください。

最適化の要件を確立する

Google Cloud 環境の次の最適化要件を確認し、ワークロードに最適なものを選択します。

データベースの信頼性と可用性を向上させる

Cloud SQL を使用すると、目標復旧時間（RTO）と目標復旧時点（RPO）に沿った高可用性と障害復旧の戦略を実装できます。信頼性と可用性を高めるには、次の点を考慮してください。

  • 読み取り負荷の高いワークロードの場合は、リードレプリカを追加してプライマリ インスタンスからトラフィックをオフロードします。
  • ミッション クリティカルなワークロードの場合は、高可用性構成、リージョン フェイルオーバー用のレプリカ、堅牢な障害復旧構成を使用します。
  • 重要度の低いワークロードの場合は、自動バックアップとオンデマンド バックアップで十分です。
  • インスタンスが誤って削除されないようにするには、インスタンスの削除保護を使用します。
  • Cloud SQL Enterprise Plus エディションを使用すると、可用性の向上、ログ保持、ダウンタイムがほぼゼロの計画的メンテナンスのメリットを得ることができます。Cloud SQL Enterprise Plus の詳細については、Cloud SQL のエディションの概要とダウンタイムがほぼゼロの計画的メンテナンスをご覧ください。

データベースの信頼性と可用性を高める方法の詳細については、以下をご覧ください。

データベース インフラストラクチャの費用対効果を高める

経済的にプラスの効果を得るには、ワークロードで利用可能なリソースとサービスを効率的に使用する必要があります。次のオプションを検討してください。

  • 次の手順で、必要最小限のストレージ容量をデータベースに提供します。

    • データの増加に合わせてストレージ容量を自動的にスケーリングするには、ストレージの自動増量を有効にします。ただし、ピーク時のワークロードでバッファが確保されるようにインスタンスを構成してください。データベースのワークロードは時間の経過とともに増加する傾向があります。

  • 過大評価されている可能性のあるリソースを特定します。

    • Cloud SQL インスタンスを適正化することで、容量管理戦略に新たなリスクを生じさせることなく、インフラストラクチャの費用を削減できます。
    • Cloud Monitoring には、Cloud SQL を含む多くの Google Cloud コンポーネントの健全性と容量使用率を把握する際に役立つ事前定義のダッシュボードが用意されています。詳細については、カスタム ダッシュボードの作成と管理をご覧ください。

  • 高可用性または障害復旧構成を必要としないインスタンスを特定し、インフラストラクチャから削除します。

  • 不要になったテーブルとオブジェクトを削除します。これらは、フル バックアップまたはアーカイブ用の Cloud Storage バケットに保存できます。

  • ユースケースで最も費用対効果の高いストレージ タイプ（SSD または HDD）を評価します。

    • ほとんどのユースケースでは、SSD が最も効率的でコスト効果の高い選択肢です。
    • データセットが大きい場合（10 TB 以上）や、レイテンシの影響を受けなかったり、アクセス頻度が低い場合は、HDD のほうが適している場合があります。
    • 詳しくは、SSD ストレージか HDD ストレージかの選択をご覧ください。

  • リソースのニーズが予測可能なワークロードについては、確約利用割引を購入します。

  • Active Assist を使用して、費用に関する分析情報と最適化案を取得します。

詳細とオプションについては、費用を抑えて効果を高める: Active Assist による Cloud SQL の費用最適化に関する推奨機能をご覧ください。

データベース インフラストラクチャのパフォーマンスを向上させる

データベース関連のパフォーマンスの問題は、軽微であっても、オペレーション全体に影響を与える可能性があります。Cloud SQL インスタンスのパフォーマンスを維持して向上させるには、次のガイドラインに従ってください。

  • データベース テーブルの数が多いと、インスタンスのパフォーマンスと可用性に影響し、インスタンスが SLA の対象外になる可能性があります。

  • インスタンスがメモリや CPU の制限を受けないようにします。

    • 高いパフォーマンスが要求されるワークロードの場合、インスタンスに 60 GB 以上のメモリを割り当てます。
    • データベースの挿入、更新、削除が遅い場合は、書き込みとデータベースのロケーションを確認します。データの送信距離が長いと、レイテンシが発生します。

  • Cloud Monitoring で事前定義の Query Insights ダッシュボード（または同様のデータベース エンジンの組み込み機能）を使用して、クエリのパフォーマンスを改善します。最も費用のかかるコマンドを特定して最適化します。

  • データベース ファイルが不必要に大きくなるのを防ぎます。autogrow を割合ではなく MB 単位で設定します。要件に合わせて最適な増分量を設定します。

  • リーダーとデータベースの場所を確認します。レイテンシは、書き込みパフォーマンスよりも読み取りパフォーマンスに大きく影響します。

  • マシン構成の上限とデータ キャッシュの増加を活用するには、Cloud SQL Enterprise Plus エディションの使用を検討してください。詳細については、Cloud SQL のエディションの概要をご覧ください。

パフォーマンスの向上について詳しくは、[問題の診断] のパフォーマンスをご覧ください。

データベースのオブザーバビリティ機能を強化する

データベース インスタンスに接続するアプリケーションの問題の診断とトラブルシューティングは、困難で時間のかかる場合があります。そのため、すべてのチームメンバーがデータベースとインスタンスのレベルで何が起こっているかを把握できる一元的な場所が不可欠です。Cloud SQL インスタンスは、次の方法でモニタリングできます。

  • Cloud SQL では、組み込みのメモリ カスタム エージェントを使用してクエリ テレメトリーを収集します。

    • Cloud Monitoring を使用して、サービスと使用している Google Cloud リソースの測定値を収集します。
      • Cloud Monitoring には、Cloud SQL モニタリング ダッシュボードなど、いくつかの Google Cloud プロダクト用に事前定義されたダッシュボードが用意されています。
    • 指標をモニタリングするカスタム ダッシュボードを作成し、アラート ポリシーを設定することで、タイムリーに通知を受け取ることができます。
    • また、Google Cloud と統合されたサードパーティのモニタリング ソリューション（Datadog、Splunk など）を使用することもできます。

  • Cloud Logging は、一般的なアプリケーション コンポーネントからロギングデータを収集します。

  • Cloud Trace は、レイテンシ データと実行したクエリプランをアプリケーションから収集します。これにより、リクエストがアプリケーション全体でどのように影響するのかを追跡できます。

  • データベース センターは、AI を活用したデータベース フリートの概要を 1 か所で確認できます。データベースの健全性、可用性構成、データ保護、セキュリティ、業界コンプライアンスをモニタリングできます。

Cloud SQL の一般的なベスト プラクティスと運用ガイドライン

Cloud SQL のベスト プラクティスを適用して、データベースを構成し、調整します。

Cloud SQL に関する一般的な推奨事項は次のとおりです。

  • 大規模なインスタンスがある場合は、可能な限り小規模なインスタンスに分割することをおすすめします。
  • 重要なデータベースのメンテナンスに対応するストレージを構成します。Cloud SQL が実行する可能性のある重要なデータベース メンテナンス オペレーションに対応できるよう、少なくとも 20% の空き容量を確保します。
  • データベース テーブルが多すぎると、データベースのアップグレード時間に影響する可能性があります。理想的には、インスタンスあたり 10,000 個未満のテーブルを目標とします。
  • トランザクション（バイナリ）ログの保持を考慮して、インスタンスに適切なサイズを選択します。特に、書き込みアクティビティが多いインスタンスでは、この点に注意してください。

発生する可能性のあるデータベースのパフォーマンスの問題を効率的に処理するには、問題が解決するまで次のガイドラインに従って対応してください。

インフラストラクチャをスケールアップする: リソース（ディスク スループット、vCPU、RAM など）を増やします。緊急性、チームの可用性、経験に応じて、インスタンスを垂直方向にスケーリングすると、ほとんどのパフォーマンスの問題を解決できます。後で、テスト環境で問題の根本原因をさらに調査し、問題を排除する方法について検討できます。

データベースのメンテナンス オペレーションをスケジューリングして実行する: インデックスのデフラグメンテーション、統計情報の更新、バキューム分析、更新頻度の高いテーブルのインデックス再作成など。これらのメンテナンス オペレーションが最後に実行されたかどうかを確認します。特に、影響を受けるオブジェクト（テーブル、インデックス）で実行されたかどうかを確認します。通常のデータベース アクティビティから変更があったかどうかを確認します。たとえば、最近新しい列を追加した場合や、テーブルに多くの更新がある場合などです。

データベースの調整と最適化を行う: データベース内のテーブルは適切に構造化されているかどうか。列のデータ型が正しいかどうか。データモデルはワークロードのタイプに適しているかどうか。遅いクエリとその実行プランを調査します。使用可能なインデックスが使用されているかどうか確認します。他のリソースのインデックス スキャン、ロック、待機を確認します。重要なクエリをサポートするためにインデックスを追加することも検討してください。重要でないインデックスと外部キーを削除します。複雑なクエリと結合を書き換えることも検討してください。問題を解決するまでの時間は、チームの経験と可用性によって異なり、数時間から数日かかる場合があります。

読み取りをスケールアウトする: リードレプリカの使用を検討します。垂直方向のスケーリングではニーズを満たせず、データベースの調整や最適化対策が役に立たない場合は、水平方向のスケーリングを検討します。アプリケーションからリードレプリカに読み取りクエリをルーティングすると、データベース ワークロードの全体的なパフォーマンスが向上します。ただし、リードレプリカに接続するようにアプリケーションを変更するには、追加の作業が必要になる場合があります。

データベースの再設計: データベースのパーティショニングとインデックス作成を検討します。この作業には、データベースの調整や最適化よりも大幅に多くの労力が必要であり、データ移行が必要になることもありますが、長期的な修正になる可能性があります。データモデルの設計が適切でないと、パフォーマンスの問題が発生することがあります。これは、垂直方向のスケールアップによって部分的に補正できます。ただし、適切なデータモデルは長期的な修正となります。テーブルのパーティショニングを検討します。可能であれば、不要になったデータをアーカイブします。データベース構造を正規化します。ただし、非正規化によってパフォーマンスが向上する場合もあります。

データベース シャーディング: データベースをシャーディングすることで、書き込みをスケールアウトできます。シャーディングは複雑なオペレーションであり、データベースとアプリケーションを特定の方法で再設計し、データ移行を行う必要があります。特定のパーティショニング基準を使用して、データベース インスタンスを複数の小さなインスタンスに分割します。条件は、ユーザーまたは対象に基づいて設定できます。このオプションを使用すると、書き込みと読み取りの両方を水平方向にスケーリングできます。ただし、データベースとアプリケーションのワークロードの複雑さが増します。また、ホットスポットと呼ばれる不均衡なシャードが発生し、シャーディング効果が薄まる可能性があります。- Cloud SQL for MySQL の場合、テーブルに主キーまたは一意キーがあることを確認します。Cloud SQL は行ベースのレプリケーションを使用します。これは、主キーまたは一意のキーを持つテーブルで最も効果的です。

詳細については、Cloud SQL for MySQL の一般的なベスト プラクティスと運用ガイドラインをご覧ください。

次のステップ

寄稿者

作成者:

その他の寄稿者: