Google Cloud には、Amazon Relational Database Service（RDS）から Cloud SQL for SQL Server に移行するためのツール、プロダクト、ガイダンス、プロフェッショナル サービスが用意されています。
このドキュメントは、データベース移行プロジェクトの計画、実装、検証を行うクラウド管理者とデータベース管理者を対象としています。また、移行の時期を考え、移行がどのようなものかを知りたい意思決定者を対象としています。
このドキュメントでは、移行元データベースと移行先データベースで同じデータベース テクノロジーを使用する同種のデータベース移行に焦点を当てます。移行元は Amazon RDS for SQL Server、移行先は Cloud SQL for SQL Server です。
このドキュメントは、AWS から Google Cloud への移行に関する複数のパートからなるシリーズの一部です。このシリーズには、次のドキュメントが含まれています。
- 始めましょう
- Amazon EC2 から Compute Engine への移行
- Amazon S3 から Cloud Storage への移行
- Amazon EKS から GKE への移行
- Amazon RDS for MySQL および Amazon Aurora for MySQL から Cloud SQL for MySQL への移行
- Amazon RDS for PostgreSQL と Amazon Aurora for PostgreSQL から Cloud SQL for PostgreSQL と AlloyDB for PostgreSQL への移行
- Amazon RDS for SQL Server から Cloud SQL for SQL Server に移行する（このドキュメント）
- AWS Lambda から Cloud Run に移行する
Google Cloud に移行する場合は、Google Cloud への移行: スタートガイドで説明する移行フレームワークに従うことをおすすめします。
次の図は、移行の過程を示しています。
移行元の環境から Google Cloud には、一連のイテレーションで移行できます。たとえば、最初に一部のワークロードを移行した後、残りのワークロードを移行できます。個別の移行イテレーションごとに、以下の一般的な移行フレームワークのフェーズに従います。
- ワークロードとデータを評価して検出します。
- Google Cloud で基盤を計画し、構築します。
- ワークロードとデータを Google Cloud に移行します。
- Google Cloud 環境を最適化します。
このフレームワークのフェーズの詳細については、Google Cloud への移行: スタートガイドをご覧ください。
効果的な移行計画を設計するには、計画の各ステップを検証し、ロールバック戦略を常に持っていることをおすすめします。移行計画の検証については、Google Cloud への移行: 移行計画の検証に関するベスト プラクティスをご覧ください。
移行元の環境を評価する
評価フェーズでは、移行元の環境を Google Cloud に移行するための要件と依存関係を確認します。
移行を成功させるには、評価フェーズが非常に重要です。このフェーズで、移行するワークロードとその要件、依存関係、および現在の環境について詳しく把握する必要があります。また、Google Cloud への移行を計画して実施するための出発点も理解する必要があります。
評価フェーズは、次のタスクで構成されます。
- ワークロードの包括的なインベントリを作成する。
- プロパティと依存関係に応じてワークロードを分類する。
- チームを Google Cloud でトレーニングして教育する。
- Google Cloud 上でテストと概念実証を構築する。
- ターゲット環境の総所有コスト（TCO）を計算する。
- ワークロードの移行戦略を選択する。
- 移行ツールを選択する。
- 移行計画とタイムラインを定義する。
- 移行計画を検証する。
評価フェーズとこれらのタスクの詳細については、Google Cloud への移行: ワークロードの評価と検出をご覧ください。以下のセクションは、このドキュメントの情報に基づいています。
データベースの評価フェーズを実施することで、ターゲット Cloud SQL データベース インスタンスに移行元と一致するサイズと仕様を選択し、同様のパフォーマンス要件を満たすことができます。ディスクサイズとスループット、IOPS、vCPU の数に特に注意してください。ターゲット データベース インスタンスのサイズが正しくないと、移行が困難になるか、失敗する可能性があります。サイズが適切でないと、移行に時間がかかったり、データベースのパフォーマンスの問題、データベース エラー、アプリケーションのパフォーマンスの問題が発生する可能性があります。Cloud SQL インスタンスを選択する場合は、ディスクのパフォーマンスはディスクのサイズと vCPU の数に基づくことに注意してください。
以降のセクションの内容は、Google Cloud への移行: ワークロードの評価と検出に基づいており、このドキュメントの情報が統合されています。
Amazon RDS インスタンスのインベントリを作成する
移行の範囲を定義するには、インベントリを作成し、Amazon RDS インスタンスに関する情報を収集します。手動で行う方法はエラーが発生しやすく、誤った想定につながる可能性があるため、このプロセスは自動化するのが理想的です。
Amazon RDS と Cloud SQL には、類似する機能、インスタンス仕様、オペレーションがない場合があります。一部の機能は、実装が異なるか、使用できない場合があります。違いがある領域としては、インフラストラクチャ、ストレージ、認証とセキュリティ、レプリケーション、バックアップ、高可用性、リソース容量モデル、特定のデータベース エンジン機能の統合、拡張機能などがあります。データベース エンジンのタイプ、インスタンスのサイズ、アーキテクチャによっては、データベース パラメータ設定のデフォルト値が異なる場合もあります。
ベンチマークは、移行するワークロードをより深く理解し、移行先の環境に適切なアーキテクチャを定義する際に役立ちます。パフォーマンスに関する情報を収集することは、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 内のデータを制限できます。Cloud SQL for SQL Server で Windows 認証を使用する場合は、Managed Microsoft AD をデプロイし、既存の Active Directory インフラストラクチャに接続する必要があります。
- インスタンスにパッチを適用して構成する: 既存のデプロイツールの更新が必要になる場合があります。たとえば、Amazon パラメータ グループまたは Amazon オプション グループでカスタム構成設定を使用している場合です。Google Cloud Storage または Secret Manager を使用してこのようなカスタム構成リストを読み取るように、プロビジョニング ツールの調整が必要になる場合があります。
- モニタリングとアラート インフラストラクチャを管理する: Amazon ソース データベース インスタンスの指標カテゴリは、移行プロセス中のオブザーバビリティを提供します。指標カテゴリには、Amazon CloudWatch、Performance Insights、Enhanced Monitoring、OS プロセスリストなどがあります。
評価を完了する
Amazon RDS 環境からインベントリを構築したら、Google Cloud への移行: ワークロードの評価と検出で説明されている評価フェーズの残りの作業を実施します。
基盤の計画と構築
計画と構築フェーズでは、インフラストラクチャをプロビジョニングして構成し、以下のことを行います。
- Google Cloud 環境でワークロードをサポートします。
- 移行元の環境と Google Cloud 環境を接続して、移行を完了します。
計画と構築のフェーズは、次のタスクで構成されます。
- リソース階層を構築する。
- Google Cloud の Identity and Access Management（IAM）を構成する。
- お支払いとご請求の設定をします。
- ネットワーク接続を設定する。
- セキュリティを強化する。
- ロギング、モニタリング、アラートを設定する。
これらの各タスクの詳細については、Google Cloud への移行: 基盤の計画と構築をご覧ください。
モニタリングとアラート
Google Cloud Monitoring には、Cloud SQL モニタリング ダッシュボードなど、いくつかの Google Cloud プロダクト用に事前定義されたダッシュボードが用意されています。また、Datadog や Splunk など、Google Cloud と統合されたサードパーティのモニタリング ソリューションを使用することもできます。詳細については、データベース オブザーバビリティについてをご覧ください。
Amazon RDS for SQL Server インスタンスを Cloud SQL for SQL Server に移行する
インスタンスを移行するには、次の操作を行います。
移行戦略（継続的レプリケーションまたは定期メンテナンス）を選択します。
選択した戦略と要件に応じて、移行ツールを選択します。
準備と実行のタスクなど、各データベース移行の移行計画とタイムラインを定義します。
移行ツールが適切に機能するように、準備タスクを定義します。
実行タスクを定義します。これには、移行を実装する作業アクティビティが含まれます。
実行タスクごとにフォールバック シナリオを定義します。
テストと検証を行います。これは、別のステージング環境で行うこともできます。
移行を実行します。
本番環境のカットオーバーを実施します。
移行元の環境をクリーンアップし、移行先インスタンスを構成します。
チューニングと最適化を行います。
以降のセクションでは、これらのフェーズについて説明します。
移行戦略を選択する
この時点で、各データベースのユースケースに最適な移行戦略を評価して選択するための十分な情報を取得しているはずです。
- 定期メンテナンス（1 回限りの移行）: ダウンタイムを許容できる場合は、この方法が理想的です。このオプションでは、ワークロードとサービスのリファクタリングがほとんど必要ないため、費用と複雑さが比較的低くなります。ただし、移行が完了する前に失敗した場合は、プロセスを再開する必要があります。これにより、ダウンタイムが長くなります。
継続的レプリケーション（トリクル移行）: ミッション クリティカルなデータベースの場合、このオプションはデータ損失のリスクが低く、ダウンタイムがほぼゼロになります。作業は複数のチャンクに分割されるため、失敗した場合のロールバックと再試行にかかる時間が短くなります。ただし、設定が複雑になり、より多くの計画と時間が必要になります。データベース インスタンスに接続するアプリケーションをリファクタリングするために、追加の作業が必要になります。次のいずれかのバリエーションを検討してください。
- Y（書き込み / 読み取り）アプローチを使用する。これは並行移行の一種であり、移行中に移行元インスタンスと移行先インスタンスの両方でデータを複製します。
- データアクセス マイクロサービスを使用すると、Y（書き込み / 読み取り）アプローチで必要なリファクタリングの労力を削減できます。
データ移行戦略の詳細については、データ移行方法の評価をご覧ください。
次の図は、単一データベースの移行戦略を決定する際に考慮すべき質問の例に基づくフローチャートを示しています。
上のフローチャートには、次の判断ポイントが示されています。
ダウンタイムを許容できるかどうか。
- 「いいえ」の場合は、継続的レプリケーションの移行戦略を採用します。
- 「はい」の場合、次の判断ポイントに進みます。
カットオーバーまでのダウンタイムを許容できるか。カットオーバー ウィンドウは、データベースのバックアップ、Cloud SQL への転送、復元、アプリケーションの切り替えにかかる時間を表します。
- 「いいえ」の場合は、継続的レプリケーションの移行戦略を採用します。
- 「はい」の場合は、定期メンテナンスの移行戦略を採用します。
同じインスタンス上にある場合でも、データベースによって戦略が異なる場合があります。戦略を組み合わせることで、最適な結果を得ることができます。たとえば、規模が小さく使用頻度の低いデータベースは定期メンテナンスで移行し、ダウンタイムが発生すると費用がかさむミッション クリティカルなデータベースは継続レプリケーションで移行します。
通常、移行は、最初の移行元インスタンスと移行先インスタンスの切り替えが行われたときに完了したと見なされます。レプリケーション（使用されている場合）は停止し、すべての読み取りと書き込みはターゲット インスタンスで実行されます。両方のインスタンスが同期している状態で切り替えが行われると、データ損失がなく、ダウンタイムが最小限に抑えられます。
データ移行戦略とデプロイの詳細については、データベース移行の分類をご覧ください。
ダウンタイムと移行に関連する影響を最小限に抑える
アプリケーションのダウンタイムが発生しない移行構成では、より複雑な設定が必要になります。設定の複雑さと、トラフィックの少ない業務時間帯にスケジュールされたダウンタイムとの間で適切なバランスを見つけます。
各移行戦略には、移行プロセスに関連するトレードオフと影響があります。たとえば、レプリケーション プロセスでは、移行元インスタンスに負荷がかかり、レプリケーション ラグによってアプリケーションに影響が及ぶ可能性があります。アプリケーション（とユーザー）は、新しいデータベースが使用されるまでレプリケーション ラグが続く限り、アプリケーションのダウンタイム中に待機しなければなりません。実際には、次の要因によりダウンタイムが増加する可能性があります。
- データベース クエリの完了には数秒かかることがあります。移行時に、処理中のクエリが中止される可能性があります。
- データベースが大きい場合や、バッファメモリが大量にある場合は、キャッシュがいっぱいになるまでに時間がかかることがあります。
- 移行元で停止し、Google Cloud で再起動したアプリケーションは、Google Cloud データベース インスタンスへの接続が確立されるまで少し遅延が生じることがあります。
- アプリケーションへのネットワーク ルートを再ルーティングする必要があります。これは、DNS エントリの設定方法によってはある程度時間がかかることがあります。DNS レコードを更新する場合は、移行前に TTL を短くします。
次の一般的な方法を実施すると、ダウンタイムと影響を最小限に抑えることができます。
- ダウンタイムがワークロードに与える影響を最小限に抑えられる期間を見つけます。たとえば、通常の業務時間外、週末、その他の定期メンテナンスの期間中などです。
- 移行と本番環境のカットオーバーをさまざまな段階で行うことができるワークロードの部分を特定します。アプリケーションには、影響なく分離、適応、移行できるさまざまなコンポーネントが含まれている場合があります。たとえば、フロントエンド、CRM モジュール、バックエンド サービス、レポート プラットフォームなどです。このようなモジュールには、プロセスの前半または後半に移行をスケジュールできる独自のデータベースが存在する場合があります。
- ターゲット データベースでレイテンシが発生しても問題ない場合は、段階的な移行の実施を検討してください。増分バッチデータ転送を使用し、ワークロードの一部を調整して、ターゲット インスタンスの古いデータを処理します。
- 移行の影響を最小限に抑えるために、アプリケーションのリファクタリングを検討してください。たとえば、移行元データベースと移行先データベースの両方に書き込むようにアプリケーションを調整し、アプリケーション レベルでのレプリケーションを実装します。
移行ツールを選択する
移行を成功させるための最も重要な要素は、適切な移行ツールを選択することです。移行戦略が決まったら、移行ツールを確認して決定します。
利用可能なツールは多数あり、それぞれ特定の移行ユースケースに合わせて最適化されています。ユースケースには、次のようなものがあります。
- 移行戦略（定期メンテナンスまたは継続的レプリケーション）。
- 移行元と移行先のデータベース エンジンとエンジン バージョン。
- 移行元インスタンスと移行先インスタンスが配置されている環境。
- データベース サイズ。データベースが大きくなるほど、最初のバックアップの移行に時間がかかります。
- データベースの変更頻度。
- 移行にマネージド サービスを使用できるかどうか。
シームレスな移行とカットオーバーを確実に行うには、アプリケーションのデプロイ パターン、インフラストラクチャ オーケストレーション、カスタム移行アプリケーションを使用します。ただし、マネージド移行サービスと呼ばれる専用のツールを使用すると、データ、アプリケーション、さらにはインフラストラクチャ全体を環境間で移動するプロセスを容易に実施できます。これらのツールは、移行元データベースからデータを抽出して、データを移行先データベースに安全に転送します。また、転送中にデータを変更することもできます。これらの機能により、移行の複雑なロジックをカプセル化し、移行モニタリング機能を利用できます。
マネージド移行サービスには次のような利点があります。
ダウンタイムを最小限に抑える: サービスは、利用可能な場合にデータベース エンジンの組み込みレプリケーション機能を使用し、レプリカのプロモーションを実行します。
データの整合性とセキュリティを確保する: データは、移行元から移行先のデータベースに安全かつ確実に転送されます。
一貫した移行エクスペリエンスを提供: データベース移行の実行可能ファイルを使用すると、さまざまな移行手法とパターンを一貫した共通インターフェースに統合できます。このインターフェースで管理とモニタリングを行うことができます。
信頼性が高く実績のある移行モデルを提供: データベースの移行は頻繁ではありませんが、重要なイベントです。初歩的なミスや既存のソリューションに関する問題を回避するには、カスタム ソリューションを構築するのではなく、経験豊富な専門家が提供するツールを使用します。
費用を最適化する: カスタム移行ソリューション用に追加のサーバーとリソースをプロビジョニングするよりも、マネージド移行サービスのほうが費用対効果に優れている場合があります。
以降のセクションでは、選択した移行戦略に推奨される移行ツールについて説明します。
定期メンテナンスでの移行用のツール
以降のサブセクションでは、1 回限りの移行に使用できるツールとその制限事項、ベスト プラクティスについて説明します。
組み込みデータベース エンジンのバックアップ
大幅なダウンタイムが許容でき、移行元データベースが比較的静的である場合は、データベース エンジンの組み込みバックアップと復元機能を使用できます。
特にデータベースの数が多い場合は、設定と同期に手間がかかりますが、通常、データベース エンジンのバックアップはすぐに利用可能で、使いやすいものです。このアプローチはあらゆるデータベース サイズに適しており、通常、大規模なインスタンスでは他のツールよりも効果的です。
データベース エンジンのバックアップには、次のような一般的な制限があります。
- バックアップは、特に手動で行う場合はエラーが発生する可能性があります。
- バックアップが適切に管理されていない場合、データは保護されません。
- バックアップには適切なモニタリング機能がありません。
このアプローチを選択する場合は、次の制限事項とベスト プラクティスを考慮してください。
- 5 TB を超えるデータベースのバックアップの場合は、ストライプド バックアップ（複数のファイルのバックアップ）を使用します。
- ストライプ バックアップを使用する場合、10 個を超えるバックアップ ファイルから同時にバックアップまたは復元することはできません。
- ソース データベース インスタンスと同じ Amazon リージョンにある Amazon S3 バケットにバックアップする必要があります。
- バックアップには、インスタンス レベルにある SQL Server のログイン、権限、サーバーロールは含まれません。このタイプのデータをソース インスタンスからターゲット インスタンスに転送するには、PowerShell スクリプトまたは DBAtools などのツールを使用します。
制限事項とベスト プラクティスの詳細については、Cloud SQL for SQL Server でデータをインポートおよびエクスポートする際のベスト プラクティスと Cloud SQL for SQL Server の既知の問題をご覧ください。
定期メンテナンス移行のその他の方法
他の方法を使用すると、定期メンテナンス移行プロセスの制御と柔軟性が向上する場合があります。
たとえば、フラット ファイルを使用してデータをエクスポートおよびインポートする（またはカスタム スクリプトを使用する）と、次のことを行えます。
- 移行中にデータに対して変換、チェック、その他のオペレーションを実行します。たとえば、ソースデータの検証、集計、正規化、非正規化などです。
- 移行する構造と残す構造を選択します。テーブルのサブセットのみをフラット ファイルに抽出してインポートすることもできます。
- ドメイン、ソース、年齢などのカスタム条件に基づいてデータを除外できます。たとえば、移行前に、存続期間のしきい値に達したデータを除外し、ファイルまたはソース データベースの最終バックアップに保存できます。
- データベース構造をリファクタリングし、発生したダウンタイムを移行のダウンタイムと同期します。
- 複数のインスタンスまたはデータベースを 1 つのインスタンスまたはデータベースに統合して、運用コストを軽減し、スケーラビリティの問題を軽減します。たとえば、アプローチを、顧客ごとに 1 つのインスタンス、データベース、スキーマを使用する方法から、単一のマルチテナント向けに最適化されたデータベース構造を使用する方法に変更できます。
その他のアプローチには次のものがあります。
CSV ファイルまたは JSON ファイルを使用する: この方法では、データベースのデータをファイルに抽出して、ファイルをターゲット インスタンスにインポートします。
- 通常は遅くなりますが、この方法はテーブルのサブセット（または特定のテーブル内のデータ）を移行するのに役立ちます。
- CSV 形式と JSON 形式は多くのツールで認識されます。
- プロセスを自動化する場合、バッチ処理された継続的レプリケーション移行に移行できます。
Microsoft の SQL Server インポートとエクスポート ウィザードを使用する: このツールは SQL Server Integration Services（SSIS）を使用し、他のデータベース エンジンやフラット ファイルなど、さまざまなソースからデータをインポートできます。
SQL Server スクリプトの生成と公開ウィザードと bcp ユーティリティを使用する: このツールは Microsoft SQL Server Management Studio の一部です。
- この方法では、データベース スキーマ全体またはその一部のスクリプトを作成できます。
- bcp ユーティリティを使用すると、データをスクリプト化してファイルにエクスポートできます。
ソースで Amazon RDS Standard を使用している場合は、スナップショット レプリケーションを使用します。
- このアプローチでは、RDS インスタンスの SQL Server バックアップを Compute Engine 上の SQL Server の別のスタンドアロン インスタンスに復元します。次に、スナップショット レプリケーションを使用して Cloud SQL for SQL Server に移行します。
- スナップショットの生成ではソーステーブルがロックされたままになるため、ワークロードに影響する可能性があります。
- スナップショット レプリケーションにより、Amazon RDS サーバーの負荷が増加する可能性があります。
- ただし、移行または複製するオブジェクトを選択できるため、柔軟性があります。
- 詳細については、スナップショット レプリケーションを使用した SQL Server 2017 から Cloud SQL for SQL Server へのデータ移行をご覧ください。
継続的レプリケーションの移行ツール
次の図は、継続的レプリケーション移行戦略を採用し、単一データベースの移行ツールを選択する際に役立つ質問とフローチャートを示しています。
上のフローチャートには、次の判断ポイントが示されています。
マネージド移行サービスが必要かどうか。
- 「はい」の場合、次の判断に進みます。最小限のダウンタイムを許容でき、データ変換やリアルタイム同期が不要な場合は、Database Migration Service をおすすめします。そうでない場合は、サードパーティのオプションを検討してください。
- 「いいえ」の場合は、次の判断に進みます。データベース エンジンの組み込みレプリケーションがサポートされている場合は、組み込みレプリケーションを使用することをおすすめします。そうでない場合は、他の移行オプションを検討することをおすすめします。
ダウンタイムを最小限に抑え、データ変換やリアルタイム同期なしで移行できますか？
- 「はい」の場合は、Database Migration Service をおすすめします。
- 「いいえ」の場合は、サードパーティのオプションを検討します。
データベース エンジン固有の組み込みレプリケーションはサポートされていますか？
- 「はい」の場合は、組み込みレプリケーションを使用することをおすすめします。
- 「いいえ」の場合は、他の移行オプションを検討することをおすすめします。
以降のセクションでは、継続的なレプリケーション移行に使用できるツールとその制限事項、ベスト プラクティスについて説明します。
継続的レプリケーション移行用の Database Migration Service
Database Migration Service は、移行元が Amazon RDS の場合、Cloud SQL for SQL Server への同種移行をサポートしています。
Database Migration Service は、費用対効果が高く、使いやすいツールです。次の状況では、Database Migration Service をおすすめします。
- 最小限のダウンタイムを許容できる。
- リアルタイム同期は必要ありません。
- 移行中にデータ変換を行う必要はありません。
このツールを選択する場合は、次の制限事項とベスト プラクティスを考慮してください。
- ダウンタイムの長さは、トランザクション ログのバックアップの頻度によって異なります。
- バックアップには、SQL Server のログイン、権限、サーバーロールは含まれません。これらはインスタンス レベルにあるためです。ソース インスタンスからスクリプトを出力し、PowerShell スクリプトまたは DBAtools などのツールを使用してターゲット インスタンスに転送します。
制限事項の一覧については、既知の制限事項をご覧ください。
データベース エンジンの組み込みレプリケーション
Cloud SQL は SQL Server のレプリケーションをサポートしています。ただし、Standard Amazon RDS for SQL Server はサブスクライバーにのみできます。Amazon RDS Standard からの組み込みレプリケーションは使用できません。組み込みパブリッシャーとして設定できるのは、Amazon RDS Custom for SQL Server のみです。
Amazon RDS でサポートされている機能とサポートされていない機能のリストについては、Amazon RDS for Microsoft SQL Server をご覧ください。
継続的レプリケーション移行のその他のアプローチ
継続的レプリケーションの移行方法には、次のようなものがあります。
Y（書き込み / 読み取り）を実行するようにアプリケーションをリファクタリングするか、データアクセス マイクロサービスを使用します。
- 継続的レプリケーションはアプリケーションによって実行されます。
- 移行作業では、データベース インスタンスに接続するツールのリファクタリングまたは開発に重点を置きます。
- その後、リーダー アプリケーションを段階的にリファクタリングし、ターゲット インスタンスを使用するようにデプロイします。
ソース インスタンスでデータを定期的にクエリし、新しいデータのみをフィルタして、CSV、JSON、または Parquet ファイルにデータを書き込む関数を実装します。
- これらのファイルは Google Cloud Storage バケットに保存されます。
- Cloud Run functions を使用して、ファイルをターゲット データベース インスタンスにすぐに書き込むことができます。
- 変更データ キャプチャ（CDC）機能を使用すると、ほぼリアルタイムのレプリケーション移行を実現できます。
- AWS Database Migration Service（AWS DMS）を使用して、CDC を Parquet 形式で Amazon S3 データレイクにストリーミングできます。
- ファイルを読み取り、そのコンテンツを Cloud SQL に書き込むカスタム実装を用意できます。
継続的レプリケーション移行のサードパーティ ツール
場合によっては、データベース エンジンに 1 つのサードパーティ ツールを使用するほうが適していることがあります。このようなケースとしては、マネージド移行サービスを使用し、ターゲット データベースが常に移行元とほぼリアルタイムで同期されるようにする必要がある場合や、移行プロセス中にデータのクリーニング、再構造化、適応などのより複雑な変換が必要な場合などがあります。
サードパーティ ツールを使用する場合は、次のいずれかをおすすめします。このツールは、ほとんどのデータベース エンジンで使用できます。
Striim は、データをリアルタイムで収集、フィルタリング、変換、拡充、集計、分析、配信するためのエンドツーエンドのインメモリ プラットフォームです。
メリット:
- 大量のデータと複雑な移行に対応。
- SQL Server の組み込み変更データ キャプチャ。
- 事前構成済みの接続テンプレートとノーコード パイプライン。
- 大量のトランザクション ロードで動作するミッション クリティカルな大規模なデータベースに対応。
- 1 回限りの配信。
デメリット:
- オープンソースではない。
- 特に長時間の移行の場合は費用が高くなる可能性があります。
- データ定義言語（DDL）オペレーションの伝播に制限がある。詳細については、サポートされている DDL オペレーションとスキーマの進化に関する注意事項と制限事項をご覧ください。
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 インスタンスの準備と前提条件
- 移行元データベースの準備と前提条件
- Cloud SQL の設定
- 移行固有の設定
Amazon RDS インスタンスの準備と前提条件
次の一般的な設定と前提条件のタスクを検討してください。
- 移行パスによっては、RDS インスタンスでのリモート接続の許可が必要になる場合があります。RDS インスタンスが VPC でプライベートに構成されている場合は、Amazon と Google Cloud の間にプライベート RFC 1918 接続が必要です。
必要なポートでリモート接続を許可するように、新しいセキュリティ グループの構成が必要になる場合があります。
- AWS では、デフォルトでデータベース インスタンスのネットワーク アクセスが無効になっています。
- セキュリティ グループで、IP アドレス範囲、ポート、またはセキュリティ グループからのアクセスを許可するルールを指定できます。同じルールが、そのセキュリティ グループに関連付けられているすべてのデータベース インスタンスに適用されます。
継続的なレプリケーション（CDC による変更のストリーミング）では、CDC が有効になっているリードレプリカではなく、完全な RDS インスタンスを使用する必要があります。詳細については、SQL Server での変更データ キャプチャの使用をご覧ください。
サードパーティ ツールを使用する場合は、通常、ツールを使用する前に事前設定と構成が必要です。サードパーティ ツールのドキュメントを確認してください。
移行元データベースの準備と前提条件
- 移行オペレーション中にソース データベースで使用可能なバッファ ストレージとメモリがあることを確認します。たとえば、トランザクション ログのバックアップ ファイルを使用している場合は、ストレージの使用状況をモニタリングし、追加のバッファ ストレージ容量があることを確認してください。
- データベース パラメータの設定を記録し、移行テストと検証を行う前に移行先インスタンスに適用します。
本番環境で移行元環境のベースラインを測定します。次の点を考慮してください。
- データのサイズとワークロードのパフォーマンスを測定します。重要なクエリまたはトランザクションに平均でどのくらいの時間がかかるか。ピーク時は何分間か。
- ベースライン測定値を記録して後で比較し、データベース移行の忠実度が十分かどうかを判断できるようにします。本番環境ワークロードを切り替えて移行元の環境を廃止できるかどうか、またはフォールバック用に引き続き必要かどうかを判断します。
Cloud SQL の設定
同様のパフォーマンス要件を満たすため、ターゲット Cloud SQL データベース インスタンスに移行元と一致するサイズと仕様を慎重に選択します。ディスクサイズとスループット、IOPS、vCPU の数に特に注意してください。サイズが適切でないと、移行に時間がかかったり、データベースのパフォーマンスの問題、データベース エラー、アプリケーションのパフォーマンスの問題が発生する可能性があります。
リンク先が適切であることを確認します。Amazon RDS の構成オプションは Cloud SQL と異なる場合があります。Cloud SQL が要件を満たさない場合は、Compute Engine 上のデータベースを含むオプションを検討してください。
Cloud SQL インスタンスを作成する前に、次のプロパティと要件を確認する必要があります。後で変更する場合は、再作成する必要があります。
ターゲット Cloud SQL インスタンスのプロジェクトとリージョンは慎重に選択してください。Cloud SQL インスタンスは、データ転送なしで Google Cloud プロジェクトとリージョン間で移行することはできません。
Cloud SQL で一致するメジャー バージョンに移行します。たとえば、ソースで SQL Server 15.0 を使用している場合は、Cloud SQL for SQL Server 15.0 に移行します。バージョンが異なる場合は、同じエンジン機能を確保するために、互換性レベルの設定を同じにする必要があります。
組み込みデータベース エンジンのバックアップまたは Database Migration Service を使用している場合は、ユーザー情報を個別にレプリケートします。詳細については、データベース エンジン固有のバックアップのセクションの制限事項をご覧ください。
データベース エンジン固有の構成フラグを調べ、移行元と移行先のインスタンスの値を比較します。これらの影響を把握し、同程度の影響にする必要があるかどうかを判断します。たとえば、移行元データベースの sys.configurations ビューの値と Cloud SQL インスタンスの値を比較することをおすすめします。すべてのフラグが同じである必要はなく、Cloud SQL インスタンスですべてのフラグ変更が許可されるわけではありません。
Cloud SQL の設定の詳細については、以下をご覧ください。
移行固有の設定
ファイルのエクスポートとインポートを使用して移行する場合、または Database Migration Service 移行ツールを使用する場合は、Cloud Storage バケットを作成する必要があります。バケットには、データベースとトランザクション ログのバックアップ ファイルが保存されます。Database Migration Service の使用方法については、バックアップ ファイルを Cloud Storage バケットに保存するをご覧ください。
レプリケーションを使用する場合は、Cloud SQL レプリカがプライマリ データベースにアクセスできるようにする必要があります。このアクセスは、ドキュメントに記載されている接続オプションで実現できます。
シナリオと重大度によっては、フォールバック シナリオの実装が必要になります。通常、これはレプリケーションと逆方向になります。この場合、Cloud SQL から移行元の Amazon インスタンスへのレプリケーション メカニズムが必要になることがあります。
ほとんどのサードパーティ ツールの場合、移行固有のリソースをプロビジョニングする必要があります。たとえば、Striim の場合は、Google Cloud Marketplace を使用して開始する必要があります。次に、Striim で移行環境を設定します。その際、Flow Designer を使用してアプリケーションを作成または変更するか、既存のテンプレートを選択します。アプリケーションは、Tungsten Query Language（TQL）プログラミング言語を使用してコーディングすることもできます。データ検証ダッシュボードを使用すると、Striim アプリケーションによって処理されるデータを視覚的に確認できます。
移行が完了して検証されたら、Amazon 環境と Google Cloud 環境を接続するリソースを廃止できます。
実行タスクを定義する
実行タスクは移行作業自体を実装します。タスクは、次のサブセクションで説明するように、選択した移行ツールによって異なります。
組み込みデータベース エンジンのバックアップ
データベース固有のバックアップの詳細と手順については、BAK ファイルから Cloud SQL for SQL Server にデータをインポートすると RDS for SQL Server からデータをエクスポートするをご覧ください。トランザクション ログファイルのアップロードを自動化する方法については、Amazon RDS のトランザクション ログファイルのアップロードをスケジュールするをご覧ください。
Database Migration Service の移行ジョブ
移行元インスタンスから移行先データベースにデータを移行するには、Database Migration Service で移行ジョブを定義して構成します。移行ジョブは、ユーザー定義の接続プロファイルを介して移行元データベース インスタンスに接続します。
すべての前提条件をテストして、ジョブが正常に実行できることを確認します。ワークロードで移行と本番環境へのカットオーバーに短いダウンタイムを許容できる時間を選択します。
通常、移行プロセスには次のタスクが含まれます。
- 移行元データベースのフル バックアップをエクスポートし、Cloud Storage バケットにアップロードします。
- トランザクション ログ ファイルのバックアップを取得し、同じ Cloud Storage バケットにアップロードします。このプロセスを自動化する方法については、Amazon RDS のトランザクション ログファイルのアップロードをスケジュールするをご覧ください。
- Database Migration Service では、トランザクション ログのバックアップの処理をモニタリングします。
- 移行元データベースへの書き込みを停止します。
- ソースとターゲットが同期されるまで待ちます。これは、最後のトランザクション ログ バックアップが処理されるときです。
- 進行中のレプリケーションを停止し、移行ジョブを昇格します。移行ジョブを昇格すると、移行先の Cloud SQL インスタンスは移行元のデータベース インスタンスから切断され、プライマリ インスタンスに昇格されます。
- 新しいターゲット データベースを指すアプリケーションをデプロイします。
移行の設定プロセスの詳細については、SQL Server データベースを Cloud SQL for SQL Server に移行するをご覧ください。
データベース エンジンの組み込みレプリケーション
Amazon RDS Standard を使用している場合は、まず Amazon RDS カスタム バージョンに移行してから、Cloud SQL にレプリケートする必要があります。
Cloud SQL は SQL Server のレプリケーションをサポートしています。外部サーバーからのレプリケーションの詳細については、スナップショット レプリケーションを使用した SQL Server 2017 から Cloud SQL for SQL Server へのデータの移行をご覧ください。
サードパーティ製ツール
選択したサードパーティ ツールの実行タスクを定義します。たとえば、Striim を使用する場合は、Namespace にアプリを作成し、Amazon インスタンスに接続するように CDC リーダーを構成する必要があります。詳細については、Striim のドキュメントの SQL Server の設定をご覧ください。
フォールバック シナリオを定義する
移行プロセス中に発生する可能性のある予期しない問題に備えて、移行の実行タスクごとにフォールバック アクションを定義します。通常、フォールバック タスクは、使用される移行戦略とツールによって異なります。
フォールバックには多大な労力が必要になる場合があります。満足のいくテスト結果になるまで、本番環境への切り替えは行わないことをおすすめします。データベースの移行とフォールバック シナリオの両方を適切にテストして、重大なサービス停止を回避する必要があります。
成功基準を定義し、すべての移行実行タスクにタイムボックスを設定します。移行のドライランを行うと、各タスクの所要時間に関する情報を収集できます。たとえば、定期メンテナンス移行の場合は、カットオーバー時間枠で示されるダウンタイムを許容できます。ただし、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 インスタンスを構成する
カットオーバーが完了したら、移行元データベースを削除できます。移行元のインスタンスのクリーンアップを行う前に、次の重要な操作を行うことをおすすめします。
各移行元データベースの最終的なバックアップを作成します。これらのバックアップにより、移行元データベースの最終状態が提供されます。一部のデータ規制を遵守するために、バックアップが必要な場合もあります。
移行元インスタンスのデータベース パラメータ設定を収集します。または、インベントリ作成フェーズで収集したデータと一致していることを確認します。移行元インスタンスのパラメータと一致するように移行先インスタンスのパラメータを調整します。
移行元インスタンスからデータベース統計情報を収集し、移行先インスタンスの統計情報と比較します。統計情報が異なる場合、移行元インスタンスと移行先インスタンスのパフォーマンスを比較するのは困難です。
フォールバック シナリオでは、Cloud SQL インスタンスに対する書き込みのレプリケーションを元の移行元データベースに実装することをおすすめします。この設定は移行プロセスに似ていますが、逆方向に実行されます。つまり、最初の移行元データベースが新しいターゲットになります。
カットオーバー後に移行元インスタンスを最新の状態に保つためのベスト プラクティスとして、ターゲット Cloud SQL インスタンスで実行された書き込みを移行元データベースにレプリケートすることをおすすめします。ロールバックが必要な場合は、データ損失を最小限に抑えて古い移行元インスタンスにフォールバックできます。
移行元の環境のクリーンアップに加えて、Cloud SQL インスタンスに次の重要な構成を行う必要があります。
- 中断更新がいつ発生するかを制御するため、プライマリ インスタンスのメンテナンスの時間枠を構成してください。
- Cloud SQL が実行する可能性のある重要なデータベース メンテナンス オペレーションに対応できるよう、少なくとも 20% の空き容量を確保するようにインスタンスのストレージを構成します。使用可能なディスク容量が 20% を下回った場合にアラートを受信するには、ディスク使用率指標に対して指標ベースのアラート ポリシーを作成します。
前のオペレーションが完了する前に管理オペレーションを開始しないでください。
詳しくは以下をご覧ください。
移行後の環境を最適化する
最適化が移行の最終フェーズになります。このフェーズではターゲット環境が最適化の要件を満たすまで最適化タスクを繰り返します。このイテレーションの手順は次のとおりです。
- 現在の環境、チーム、最適化ループを評価する。
- 最適化の要件と目標を設定する。
- 環境とチームを最適化する。
- 最適化ループを調整する。
最適化の目標を達成するまで、このシーケンスを繰り返します。
Google Cloud 環境の最適化の詳細については、Google Cloud への移行: 環境の最適化とパフォーマンスの最適化プロセスをご覧ください。
最適化の要件を確立する
Google Cloud 環境の次の最適化要件を確認し、ワークロードに最適なものを選択します。
データベースの信頼性と可用性を向上させる
Cloud SQL を使用すると、目標復旧時間（RTO）と目標復旧時点（RPO）に沿った高可用性と障害復旧の戦略を実装できます。信頼性と可用性を高めるには、次の点を考慮してください。
- 読み取り負荷の高いワークロードの場合は、リードレプリカを追加してプライマリ インスタンスからトラフィックをオフロードします。
- ミッション クリティカルなワークロードの場合は、高可用性構成、リージョン フェイルオーバー用のレプリカ、堅牢な障害復旧構成を使用します。
- 重要度の低いワークロードの場合は、自動バックアップとオンデマンド バックアップで十分です。
- インスタンスが誤って削除されないようにするには、インスタンスの削除保護を使用します。
- Cloud SQL for SQL Server インスタンスでポイントインタイム リカバリ（PITR）を有効にします。
- メンテナンス プランを使用して 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 for SQL Server のライセンス費用を削減するには、次の点を考慮してください。
- SLA が要件を満たしている場合は、SQL Server Standard Edition に移行します。
- 同時マルチスレッディング（SMT）をオフにして、コアを 25% 増やします。追加のコアにより、SMT の無効化によるパフォーマンスへの影響を補正できます。この戦略はライセンス費用を削減できますが、インスタンスのパフォーマンスに影響する可能性があります。SLA に影響が及ばないように、インスタンスで負荷テストを実行することをおすすめします。
- ワークロードに応じて、Cloud SQL for SQL Server から Cloud SQL for PostgreSQL または AlloyDB for PostgreSQL への異種移行を検討してください。
データベース インフラストラクチャのパフォーマンスを向上させる
データベース関連のパフォーマンスの問題は、軽微であっても、オペレーション全体に影響を与える可能性があります。Cloud SQL インスタンスのパフォーマンスを維持して向上させるには、次のガイドラインに従ってください。
- データベース テーブルの数が多いと、インスタンスのパフォーマンスと可用性に影響し、インスタンスが SLA の対象外になる可能性があります。
インスタンスがメモリや CPU の制限を受けないようにします。
- 高いパフォーマンスが要求されるワークロードの場合、インスタンスに 60 GB 以上のメモリを割り当てます。
- データベースの挿入、更新、削除が遅い場合は、書き込みとデータベースのロケーションを確認します。データの送信距離が長いと、レイテンシが発生します。
Cloud Monitoring で事前定義の Query Insights ダッシュボード（または同様のデータベース エンジンの組み込み機能）を使用して、クエリのパフォーマンスを改善します。最も費用のかかるコマンドを特定して最適化します。
データベース ファイルが不必要に大きくなるのを防ぎます。
autogrowを割合ではなく MB 単位で設定します。要件に合わせて最適な増分量を設定します。リーダーとデータベースの場所を確認します。レイテンシは、書き込みパフォーマンスよりも読み取りパフォーマンスに大きく影響します。
データとインデックスの断片化を防ぎます。データの変更頻度に応じて、SQL Server でインデックスを再構築するスケジュールを設定します。
Cloud SQL で最適に動作するように SQL Server エンジン固有の設定を変更します。
インデックスと統計情報のメンテナンスについては、SQL Server Maintenance Solution をご覧ください。
Cloud SQL for SQL Server で統計情報を定期的に更新します。
インスタンスのキャッシュに影響する可能性があるため、リードレプリカで ETL オペレーションを実行することを検討してください。
パフォーマンスの向上について詳しくは、[問題の診断] のパフォーマンスと Cloud SQL - SQL Server のパフォーマンス分析とクエリ調整をご覧ください。
データベースのオブザーバビリティ機能を強化する
データベース インスタンスに接続するアプリケーションの問題の診断とトラブルシューティングは、困難で時間のかかる場合があります。そのため、すべてのチームメンバーがデータベースとインスタンスのレベルで何が起こっているかを把握できる一元的な場所が不可欠です。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 に関する一般的な推奨事項は次のとおりです。
- 大規模なインスタンスがある場合は、可能な限り小規模なインスタンスに分割することをおすすめします。
- 重要なデータベースのメンテナンスに対応するストレージを構成します。Cloud SQL が実行する可能性のある重要なデータベース メンテナンス オペレーションに対応できるよう、少なくとも 20% の空き容量を確保します。
- データベース テーブルが多すぎると、データベースのアップグレード時間に影響する可能性があります。理想的には、インスタンスあたり 10,000 個未満のテーブルを目標とします。
- トランザクション（バイナリ）ログの保持を考慮して、インスタンスに適切なサイズを選択します。特に、書き込みアクティビティが多いインスタンスでは、この点に注意してください。
発生する可能性のあるデータベースのパフォーマンスの問題を効率的に処理するには、問題が解決するまで次のガイドラインに従って対応してください。
インフラストラクチャをスケールアップする: リソース（ディスク スループット、vCPU、RAM など）を増やします。緊急性、チームの可用性、経験に応じて、インスタンスを垂直方向にスケーリングすると、ほとんどのパフォーマンスの問題を解決できます。後で、テスト環境で問題の根本原因をさらに調査し、問題を排除する方法について検討できます。
データベースのメンテナンス オペレーションをスケジューリングして実行する: インデックスのデフラグメンテーション、統計情報の更新、バキューム分析、更新頻度の高いテーブルのインデックス再作成など。これらのメンテナンス オペレーションが最後に実行されたかどうかを確認します。特に、影響を受けるオブジェクト（テーブル、インデックス）で実行されたかどうかを確認します。通常のデータベース アクティビティから変更があったかどうかを確認します。たとえば、最近新しい列を追加した場合や、テーブルに多くの更新がある場合などです。
データベースの調整と最適化を行う: データベース内のテーブルは適切に構造化されているかどうか。列のデータ型が正しいかどうか。データモデルはワークロードのタイプに適しているかどうか。遅いクエリとその実行プランを調査します。使用可能なインデックスが使用されているかどうか確認します。他のリソースのインデックス スキャン、ロック、待機を確認します。重要なクエリをサポートするためにインデックスを追加することも検討してください。重要でないインデックスと外部キーを削除します。複雑なクエリと結合を書き換えることも検討してください。問題を解決するまでの時間は、チームの経験と可用性によって異なり、数時間から数日かかる場合があります。
読み取りをスケールアウトする: リードレプリカの使用を検討します。垂直方向のスケーリングではニーズを満たせず、データベースの調整や最適化対策が役に立たない場合は、水平方向のスケーリングを検討します。アプリケーションからリードレプリカに読み取りクエリをルーティングすると、データベース ワークロードの全体的なパフォーマンスが向上します。ただし、リードレプリカに接続するようにアプリケーションを変更するには、追加の作業が必要になる場合があります。
データベースの再設計: データベースのパーティショニングとインデックス作成を検討します。この作業には、データベースの調整や最適化よりも大幅に多くの労力が必要であり、データ移行が必要になることもありますが、長期的な修正になる可能性があります。データモデルの設計が適切でないと、パフォーマンスの問題が発生することがあります。これは、垂直方向のスケールアップによって部分的に補正できます。ただし、適切なデータモデルは長期的な修正となります。テーブルのパーティショニングを検討します。可能であれば、不要になったデータをアーカイブします。データベース構造を正規化します。ただし、非正規化によってパフォーマンスが向上する場合もあります。
データベース シャーディング: データベースをシャーディングすることで、書き込みをスケールアウトできます。シャーディングは複雑なオペレーションであり、データベースとアプリケーションを特定の方法で再設計し、データ移行を行う必要があります。特定のパーティショニング基準を使用して、データベース インスタンスを複数の小さなインスタンスに分割します。条件は、ユーザーまたは対象に基づいて設定できます。このオプションを使用すると、書き込みと読み取りの両方を水平方向にスケーリングできます。ただし、データベースとアプリケーションのワークロードの複雑さが増します。また、ホットスポットと呼ばれる不均衡なシャードが発生し、シャーディング効果が薄まる可能性があります。
Cloud SQL for SQL Server に固有のベスト プラクティスは次のとおりです。
- Cloud SQL でパフォーマンスを最適化するために SQL Server の設定を更新するには、SQL Server の設定をご覧ください。
- SQL Server をデプロイする前に、I/O サブシステムの容量を決定してください。
大規模なインスタンスがある場合は、可能な限り小規模なインスタンスに分割します。
- ディスクサイズが 4 TB 以上の場合、より高いスループットと IOPS が得られます。
- vCPU が高いほど、IOPS とスループットが向上します。より高い vCPU を使用する場合は、並列処理のためにデータベースが待機する時間をモニタリングします。この時間も増加する可能性があります。
特定の状況でパフォーマンスが低下する場合は、SMT をオフにします。たとえば、アプリケーションがボトルネックになるスレッドを実行し、CPU のアーキテクチャがこれを効果的に処理しない場合などです。
データの変更頻度に応じて、インデックスを再編成または再構築するスケジュールを設定します。
断片化を減らすために適切なフィルファクタを設定します。SQL Server で、パフォーマンスの向上につながるインデックスの欠落をモニタリングします。
データベース ファイルが不必要に大きくなるのを防ぎます。
autogrowを割合ではなく MB 単位で設定します。要件に合わせて最適な増分量を設定します。また、autogrowしきい値に達する前に、データベースの増加をプロアクティブに管理します。ストレージ容量を自動的にスケーリングするには、ストレージの自動増量を有効にします。データベースとインスタンスの空き容量が不足している場合に、Cloud SQL が保存容量を追加できます。
使用するデータの言語 / 地域の要件、並べ替え順序、大文字と小文字、アクセント記号の区別を理解してください。サーバー、データベース、列、または式に対して照合を選択すると、データに特定の特性が割り当てられます。
再帰的なハッシュ結合やハッシュ ベイルアウトはサーバーのパフォーマンスを低下させます。トレースにハッシュ警告イベントが多数含まれている場合は、結合されている列の統計情報を更新します。詳細については、ハッシュ警告イベントクラスをご覧ください。
詳細については、Cloud SQL for SQL Server の一般的なベスト プラクティスと運用ガイドラインをご覧ください。
次のステップ
- AWS から Google Cloud への移行のその他の工程を確認する。
- AWS サービスや Azure サービスと Google Cloud を比較する方法を学習する。
- 移行に関するヘルプを確認するタイミングを確認する。
- Cloud Architecture Center で、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
作成者:
- Alex Cârciu | ソリューション アーキテクト
- Marco Ferrari | クラウド ソリューション アーキテクト
その他の寄稿者:
- Derek Downey | デベロッパーリレーションズ エンジニア
- Paweł Krentowski | テクニカル ライター
- Matthew Smith | Strategic Cloud Engineer
- Somdyuti Paul | データ マネジメント スペシャリスト
- Zach Seils | ネットワーキング スペシャリスト