コンテンツに移動
データベース

Cloud SQL for SQL Server を使用してオンプレミスの SQL Server インスタンスのビジネス継続性を強化

2024年6月14日
Alex Cârciu

Solutions Architect, Google Cloud

Gemini 1.5 モデル をお試しください。

Vertex AI からアクセスできる、Google のもっとも先進的なマルチモーダル モデルです。

試す

※この投稿は米国時間 2024 年 6 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

SQL Server を管理するデータベース プロフェッショナルは、災害時のデータ損失に対して復元力のあるシステムを設計する必要があります。これには多くの場合、フル バックアップ、差分バックアップ、トランザクション ログ バックアップを組み合わせた使用が含まれます。トランザクション ログ バックアップの頻度は、目標復旧時点(RPO)の定義に合わせて調整できます。一部の専門家は、1 分に 1 回の頻度でログ バックアップを取ることを推奨しています。

データ損失をさらに減らすためにお客様が使用する一般的なモデルの一つは、これらのバックアップを別の環境にレプリケートすることです。これにより、別のサービスにプライマリ SQL Server データベースのスタンバイ コピーを用意できます。たとえば、Cloud SQL では障害復旧(DR)手順の一環として、クロスリージョン リードレプリカを使用します。プライマリ インスタンスのリージョンが利用できなくなった場合、クロスリージョン レプリカをプロモートし、別のリージョンにフェイルオーバーできます。

このブログ投稿では、定期的なバックアップをシームレスにレプリケートし、その後 Cloud SQL for SQL Server にインポートすることで、オンプレミスと他のパブリック クラウド プロバイダの SQL Server インスタンスの両方に対して、Cloud SQL を使用して DR アーキテクチャを簡単に設定する方法について探っていきます。

Cloud SQL ではトランザクション ログのバックアップのインポートをサポートしています。これにより、データベースのニア リアルタイムでの移行や、Cloud SQL for SQL Server を既存のデータベース インスタンスの DR として機能させることなど、多くの可能性が開かれ、ビジネスの継続性とデータの整合性を確保するための柔軟で堅牢かつ信頼性の高いソリューションが実現されます。

Cloud SQL for SQL Server DR アーキテクチャの設定

まず、データベースのフル バックアップを指定された Cloud SQL for SQL Server DR インスタンスに復元することから始めます。次に、トランザクション ログ バックアップを順次 Cloud Storage にアップロードします。EventArc トリガーを使用することで、インポート オペレーションをオーケストレートする Cloud Functions の関数が実行されます。この関数は Cloud SQL インスタンスにリクエストを送信し、アップロードされたバックアップ ファイルのインポートと復元を行います。

https://storage.googleapis.com/gweb-cloudblog-publish/images/22_KCezWbf.max-1200x1200.jpg

この関数は、復元オペレーションの進行状況を確認します。復元オペレーションが成功すると、そのファイルを元の Cloud Storage バケットから削除し、オプションで別の Cloud Storage バケットにコピーします。オペレーションが成功しなかった場合、関数は発生したエラーのタイプに応じて動作します。

Google Cloud Database Migration Service (DMS) for SQL Server は、フル バックアップとトランザクション ログ バックアップを Cloud SQL for SQL Server に復元するこのプロセスを自動化しますが、その主な目的は SQL Server データベースの移行を効率的に行うことです。これを使用して、移行元の SQL Server インスタンスと Cloud SQL for SQL Server 間で継続的なデータフローを確立し、モニタリングし、Cloud SQL に移行できます。Google Cloud Database Migration Service (DMS) for SQL Server を使用した SQL Server データベースの移行についてより深く理解するには、Google Cloud Database Migration Service for SQL Server のドキュメントをご覧ください。

このソリューションの設定

まず、Cloud SQL for SQL Server インスタンスと SQL Server のバックアップを保存する Cloud Storage バケットをプロビジョニングして設定する必要があります。Cloud Shell で次のコマンドを実行します。

1. SQL Server インスタンスがまだない場合は、次のコマンドを使用して作成します。

export PROJECT_ID=$(gcloud config get-value project)

gcloud sql instances create <CLOUD_SQL_INSTANCE_NAME> \

--database-version=SQLSERVER_2022_STANDARD  --cpu=4 --memory=8GiB \

--zone=us-central1-a --root-password=<PASSWORD>  \

--project=${PROJECT_ID} \

--network=projects/$PROJECT_ID/global/networks/<VPC_NETWORK_NAME> \

--no-assign-ip

2. gcloud describe コマンドを使用して、Cloud SQL インスタンスのサービス アカウント情報を取得します。

gcloud sql instances describe <CLOUD_SQL_INSTANCE_NAME>

serviceAccountEmailAddress フィールドの値をメモしておきます。後で必要になります。この値は、p*******-****@******.iam.gserviceaccount.com の形式になります。

3. フル バックアップおよびトランザクション ログ バックアップ ファイルをアップロードするための Cloud Storage バケットが必要です。

gcloud storage buckets create gs://<BUCKET_NAME> \

--project=${PROJECT_ID} \

--location=<BUCKET_LOCATION> \

--public-access-prevention

4. 先ほど作成したバケットの Cloud SQL サービス アカウントに objectViewer 権限を付与します。

gcloud projects add-iam-policy-binding ${PROJECT_ID} \

--member="serviceAccount:<service-account-email-address>" \

--role="roles/storage.objectViewer"

5. ここで、バケットに新しいオブジェクトがアップロードされたときにトリガーされる Cloud Functions の関数を作成します。まず、関数用のサービス アカウントを作成します。

gcloud iam service-accounts create cloud-function-sql-restore-log --display-name "Service Account for Cloud Function and SQL Admin API"

6. Cloud SQL インスタンスでインポートを実行する権限を持ち、バケット上のファイルをオーケストレートすることもできる Cloud SQL インポーターというロールを作成します。

gcloud iam roles create cloud.sql.importer \

 --project ${PROJECT_ID} \

 --title "Cloud SQL Importer Role" \

 --description "Grant permissions to import and synchronize data from a cloud storage bucket to a Cloud SQL instance" \

 --permissions "cloudsql.instances.get,cloudsql.instances.import,eventarc.events.receiveEvent,storage.buckets.get,storage.objects.create,storage.objects.delete,storage.objects.get"

7. Cloud SQL インポーター ロールを Cloud Functions サービス アカウントにアタッチします。

gcloud projects add-iam-policy-binding ${PROJECT_ID} \

--member="serviceAccount:cloud-function-sql-restore-log@${PROJECT_ID}.iam.gserviceaccount.com" \

--role="projects/${PROJECT_ID}/roles/cloud.sql.importer"

8. バケットに新しいオブジェクトがアップロードされたときにトリガーされる Cloud Functions の関数をデプロイします。この関数は、フル バックアップ ファイルとトランザクション ログ バックアップ ファイルを復元し、バケット上のファイル同期も処理します。次の手順を Cloud Shell または gcloud CLI をインストールした任意の環境で実行します。

  • SQL Server の復元用 Cloud Functions の関数リポジトリのクローンを作成します。

git clone https://github.com/google/example-demos-for-msft-workloads.git

  • restore-sql-server-transaction-logs/Function フォルダに移動します。

cd example-demos-for-msft-workloads/restore-sql-server-transaction-logs/Function

  • restore-sql-server-transaction-logs/Function フォルダから、次の gcloud コマンドを実行して Cloud Functions の関数をデプロイします。

gcloud functions deploy <CLOUD_FUNCTION_NAME> \

--gen2 \

--region=<REGION_NAME> \

--retry \

--runtime=python312 \

--source=. \

--timeout=540 \

--entry-point=fn_restore_log \

--set-env-vars USE_FIXED_FILE_NAME_FORMAT=False,PROCESSED_BUCKET_NAME=,MAX_OPERATION_FETCH_TIME_SECONDS=30 \

--no-allow-unauthenticated \

--trigger-bucket="<BUCKET_NAME>" \

--service-account cloud-function-sql-restore-log@${PROJECT_ID}.iam.gserviceaccount.com

9. 認証された関数を呼び出すには、基盤となるプリンシパルに起動元の IAM 権限が必要です。第 2 世代関数の Cloud Run を介して、起動元ロールを関数のサービス アカウントに割り当てます。

gcloud functions add-invoker-policy-binding <CLOUD_FUNCTION_NAME> \

--region="<REGION_NAME>" \

--member="serviceAccount:cloud-function-sql-restore-log@${PROJECT_ID}.iam.gserviceaccount.com"

10. 先ほど作成したバケットに、オンプレミスの SQL Server データベースのフル バックアップをアップロードします。

この関数では、アップロードされたバックアップ ファイルを Cloud SQL for SQL Server インスタンスに復元するための適切なリクエストを行うために、特定の情報が必要になります。これには以下の情報が含まれます。

  • 対象とする Cloud SQL インスタンス名

  • データベース名

  • バックアップの種類(フル、差分、またはトランザクション ログ バックアップ)

  • バックアップを復元オプションで復元するかどうかの情報(復元が使用されない場合に、後続の復元を実行できるようにデータベースを準備しておく)

関数がこの情報を取得する方法は 2 つあります。ファイル名自体から取得する方法と、オブジェクトのメタデータから取得する方法です。関数がファイル名機能を使用できるようにするには、USE_FIXED_FILE_NAME_FORMAT 環境変数を「True」に設定します。この方法では、関数はアップロードされたすべてのバックアップ ファイルに固定の名前パターンがあると想定し、そこから必要な情報を推測します。このオプションを使用する場合、ファイル名は次のようになります。

<CLOUD_SQL_INSTANCE_NAME>_<DB_NAME>_[Full/Diff]_[Recovery].BAK

[Full/Diff] および [Recovery] グループはオプションです。指定されていない場合は、TLOG バックアップ タイプと NORECOVERY オプションが使用されます。

または、USE_FIXED_FILE_NAME_FORMAT パラメータを False」に設定し、バックアップ ファイルをアップロードする際に次のメタデータを設定します。

  • CloudSqlInstance - 復元リクエストが行なわれる Cloud SQL for SQL Server インスタンスの名前。必須。

  • DatabaseName - 関数が復元オペレーションを実行するデータベースの名前。必須。

  • BackupType - バックアップの種類。「完全」、「差分」、「TLOG」のいずれかのみ可能。必須。

  • Recovery - 復元の種類。「True」または「False」のいずれかを指定。必須。

11. Cloud Storage にファイルをアップロードします。

gcloud storage cp <OBJECT_LOCATION> gs://<BUCKET_NAME>

<OBJECT_LOCATION> をフル バックアップ ファイルへのフルパスに置き換えます。

12. 関数が正常にトリガーされたかどうかを確認します。これを行うには、次の gcloud コマンドを使用して関数のログを調べます。

gcloud functions logs read <CLOUD_FUNCTION_NAME> --region=<REGION_NAME>

13. SQL Server Management Studio を使用して Cloud SQL for SQL Server インスタンスに接続することもできます。フル バックアップの復元が正常に完了した場合、以下のような内容が表示されます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_J1xiGmo.max-800x800.png

または、gcloud コマンドを使用して --no-recovery 引数を指定し、フル バックアップを手動でインポートすることもできます。

SQL Server では、復元オプションを使用しない復元が行われると、commit されていないトランザクションが保持され、後続のバックアップの復元によるロール フォワードが可能になります。そのデメリットは、ユーザーがそのデータベースにアクセスできなくなることです。今回のケースでは、さらにトランザクション ログ バックアップの復元を適用したいため、復元オプションを使用しません。

フル バックアップのインポートの詳細については、BAK ファイルから Cloud SQL for SQL Server へのデータのインポート ドキュメントをご覧ください。

この時点で、フル バックアップ、差分バックアップ、またはトランザクション ログ バックアップが Cloud Storage にアップロードされると、これを復元する Cloud Functions の関数のデプロイに成功しています。ただし、Cloud SQL for SQL Server DR インスタンスとして使用するには、トランザクション ログを Cloud Storage に自動的にアップロードする方法を設定する必要があります。まず、バケットにファイルをアップロードする権限を持つサービス アカウントを作成する必要があります。サービス アカウントの権限借用を使用します。

1. サービス アカウントを作成します。

gcloud iam service-accounts create tx-log-backup-writer \

    --description="Account that writes transaction log backups to Cloud Storage" \

    --display-name="tx-log-backup-writer"

2. バケット上のオブジェクトを作成および表示する権限をサービス アカウントに付与します。

export PROJECT_ID=$(gcloud config get-value project)

gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> --member=serviceAccount:tx-log-backup-writer@${PROJECT_ID}.iam.gserviceaccount.com --role=roles/storage.objectAdmin

3. ローカルの Google Cloud ユーザー(またはサービス アカウント)にアクセス権を付与し、先ほど作成したサービス アカウントの権限を借用できるようにします。

gcloud iam service-accounts add-iam-policy-binding tx-log-backup-writer@${PROJECT_ID}.iam.gserviceaccount.com \

--member="user:<YOUR_GOOGLE_CLOUD_USER>"  \

--role=roles/iam.serviceAccountTokenCreator

または、この目的専用の新しいユーザーを作成することもできます。サービス アカウントの権限借用の詳細については、サービス アカウントの権限借用を使用するをご覧ください。

トランザクション ログ バックアップ ファイルへの読み取りアクセス権を持つマシンで次のアクションを実施します。

1. トランザクション ログ バックアップ ファイルにアクセスできるマシン上にフォルダを作成します。フォルダ内で、リポジトリのスケジュール設定されたアップロード フォルダからコンテンツのクローンを作成します。

git clone https://github.com/google/example-demos-for-msft-workloads.git

2. restore-sql-server-transaction-logs/scheduled-upload フォルダに移動します。

cd example-demos-for-msft-workloads/restore-sql-server-transaction-logs/scheduled-upload

3. upload-script.ps1 ファイルを編集し、定数の値を次のように変更します。

New-Variable -Name LocalPathForBackupFiles -Value "" -Option Constant

New-Variable -Name BucketName -Value "" -Option Constant

New-Variable -Name AccountName -Value "" -Option Constant

  • LocalPathForBackupFiles - アップロードする新しいファイルをスクリプトが検索するフォルダです。

  • BucketName - ファイルがアップロードされる Cloud Storage バケットの名前です。

  • AccountName - このサービス アカウント名の権限を借用します。

4. まだインストールされていない場合は、gcloud CLI をインストールします。

5. 次のコマンドを実行して、アプリケーションのデフォルト認証情報の新しいユーザー認証情報を取得します。

gcloud auth application-default login

権限の借用を設定した Google Cloud ユーザーでログインします。

6. スクリプトが定期的に呼び出されるように、スケジュール設定されたタスクを作成します。たとえば、以下のスクリプトでスケジュール設定されているタスクは、午後 2 45 分に実行を開始し、1 分ごとに実行されます。<username> を、マシン上の settings.json ファイルの読み取りおよび編集権限を持つローカルのユーザー アカウントに置き換えます。

schtasks /create /sc minute /mo 1 /tn "Cloud Storage Upload script" /tr "powershell <full-path-to-the-upload-script>" /st 14:45 /ru <local_account_username> /rp 

: タスクを作成する際に、ローカルの <local_account_username> のパスワードを入力するよう求められます。

PowerShell スクリプトは、指定されたフォルダから新しいトランザクション ログ バックアップ ファイルのみを 1 分ごとに Cloud Storage にアップロードします。

関数の実行をモニタリングし、実行回数に基づいてアラートを設定できます。たとえば、過去 10 分間に関数が正常に実行されなかった場合に、アラートを設定できます。モニタリングの詳細については、Cloud Functions の関数をモニタリングするおよび Cloud Functions の指標をご覧ください。

: Storage Transfer Service ジョブを設定して、ローカル ファイル システムまたは互換性のある Cloud Storage の場所から Google Cloud Storage バケットへのバックアップ ファイルの転送を自動化することもできます。詳細については、Storage Transfer Service とはをご覧ください。

DR スイッチを実施する場合は、データベースにアクセスできる状態にしておく必要があります。そのためには、復元オプションを「True」に設定して有効なバックアップ ファイルを復元する必要があります。たとえば、最後に正常に復元されたトランザクション ログ バックアップを使用できます。固定ファイル名形式の設定に応じて、バックアップ ファイルの名前を文字列「_recovery」が含まれるように変更するか、Cloud Storage バケットにファイルをアップロードする際に、メタデータキー「Recovery」の値を「True」に設定します。

最初のプライマリ インスタンスの健全性を復元し、フォールバックに適していると判断したら、Cloud SQL DR インスタンスからデータを同期する必要があります。次に、ワークロードが低い期間に、復元されたプライマリ インスタンスに接続するようにアプリケーションを切り替えます。

DR インスタンスを以前のプライマリ インスタンスと同期するには、次の方法を検討してください。

  • バックアップからの復元: Cloud SQL for SQL Server インスタンスからのデータベースのフル バックアップと差分バックアップを利用します。

  • レプリケーションの設定: Cloud SQL for SQL Server DR インスタンスから以前のプライマリへのレプリケーションを確立します。

Cloud SQL for SQL Server からデータをエクスポートまたはレプリケートする方法について詳しくは、Cloud SQL for SQL Server からデータをエクスポートするおよび Cloud SQL for SQL Server からデータをレプリケートするをご覧ください。フォールバックのシナリオでは、フォールバックによって新しい問題が発生したり、オペレーションに支障をきたしたりしないよう、徹底的なテストを実施することをおすすめします。

結論として、Google Cloud 上に既存の SQL Server DR インスタンスを実装することは、データベース インフラストラクチャの復元力を高める戦略的なアプローチとなります。ビジネスの継続性を確保し、データ損失を防ぎ、重要なアプリケーションにスケーラブルで安全な環境を提供します。

-Google Cloud、ソリューション アーキテクト Alex Cârciu

投稿先