Google Cloud の Microsoft SQL Server Always On 可用性グループ

Last reviewed 2026-08-12 UTC

このドキュメントでは、Always On 可用性グループを使用して Google Cloud に高可用性（HA）の Microsoft SQL Server データベースをデプロイするためのリファレンス アーキテクチャについて説明します。このドキュメントには、HA と障害復旧（DR）の設計上の考慮事項、デプロイ オプション、自動化に関する推奨事項、Backup and DR のオペレーションに関するガイダンスも含まれています。このドキュメントは、SQL Server データベースを実行するプラットフォームとして Google Cloud を評価している技術担当者を対象としています。Compute Engine と SQL Server の基本的な知識があることを前提としています。

Google Cloud は、SQL Server データベースの実行に適した費用対効果と信頼性が高く、安全で高性能なソリューションを提供します。 Google Cloudでサポートされている SQL Server ソリューションの概要については、 Google Cloud上の SQL Server をご覧ください。

Google Cloudで SQL Server の非開発環境のデプロイを運用するには、次のいずれかのライセンス オプションを使用します。

このドキュメントのデプロイ セクションでは、このリファレンス アーキテクチャのデプロイに役立つリソースを提供します。

アーキテクチャ

次の図は、 Google Cloudで HA 構成の SQL Server デプロイのリファレンス アーキテクチャを示しています。

異なるゾーンとリージョンの Compute Engine VM にまたがる Always On 可用性グループを使用した SQL Server デプロイを示すアーキテクチャ。

上記のアーキテクチャは、Windows Server フェイルオーバー クラスタ（WSFC）に 3 つのノードがある Always On 可用性グループを示しています。各ノードは、SQL Server を実行する Compute Engine VM です。

Always On 可用性グループは、ミッション クリティカルな SQL Server データベースの信頼性目標を達成するための業界標準のデプロイ パターンです。Always On 可用性グループは、ローカル HA（リージョン内のフェイルオーバー）と DR のクロスリージョン フェイルオーバーを提供します。このデプロイ パターンは、データベース ミラーリングに代わるエンタープライズ グレードのソリューションです。Always On 可用性グループには次の利点があります。

  • 特別なインフラストラクチャ コンポーネントは不要: SQL Server は、構成されたすべてのデータベース レプリカ間のレプリケーションを管理します。
  • SQL Server の最高 SLA 構成: 1 分未満の目標復旧時間（RTO）とほぼゼロの目標復旧時点（RPO）。
  • 読み取り専用ワークロードをセカンダリ レプリカにオフロードする機能: 分析やその他の一般的なユースケース向けにデプロイを効率的にスケーリングします。
  • DR 用の追加リージョンのノード: プライマリ レプリカと最大 8 個のセカンダリ レプリカをデプロイします。
  • Windows と Linux にデプロイ可能: Pacemaker などのサードパーティ製ツールを Linux デプロイのクラスタ マネージャーとして使用できます。

上記のアーキテクチャでは、プライマリ SQL Server ノードとセカンダリ SQL Server ノードは、リージョン内の別々のゾーンにあります。DR ノードが地理的に離れたリージョンにある。プライマリ ノードのデータは、セカンダリ ノードに同期的に複製され、DR ノードに非同期的に複製されます。

アプリケーション レイヤからリージョン内のプライマリ データベース ノードとセカンダリ データベース ノードにトラフィックを分散するには、次のいずれかの方法を使用します。

使用するプロダクト

このアーキテクチャでは、次の Google Cloud プロダクトと Microsoft プロダクトおよびコンポーネントを使用します。

Google Cloud プロダクト

  • Compute Engine: Google のインフラストラクチャで VM を作成して実行できる、安全でカスタマイズ可能なコンピューティング サービス。
  • Google Cloud Hyperdisk: 構成可能かつ予測可能なパフォーマンスで、ブロック ストレージ ボリュームをプロビジョニングして動的にスケーリングできるネットワーク ストレージ サービス。
  • Virtual Private Cloud（VPC）: Google Cloud ワークロードにグローバルでスケーラブルなネットワーキング機能を提供する仮想システム。VPC には、VPC ネットワーク ピアリング、Private Service Connect、プライベート サービス アクセス、共有 VPC が含まれます。
  • Cloud Load Balancing: 高パフォーマンスでスケーラブルなグローバル ロードバランサとリージョン ロードバランサのポートフォリオ。

Microsoft の製品とコンポーネント

SQL Server ノードには、次のコンポーネントが含まれているか、有効になっています。

  • Windows Server（バージョン 2019 以降）。
  • WSFC: 複数の Windows Server クラスタノードまたは複数のサブネットにインストールされている SQL Server インスタンスのグループ。
  • Always On 可用性グループ: データベース ミラーリングに代わるエンタープライズ グレードの HA と DR。
  • 可用性グループ リスナー: クライアントが Always On 可用性グループのプライマリ レプリカまたはセカンダリ レプリカのデータベースにアクセスするために使用できる仮想ネットワーク名（VNN）。クライアントは、レプリカの物理インスタンス名を知る必要はありません。リスナーはトラフィックをルーティングするため、フェイルオーバー後にクライアント接続文字列を変更する必要はありません。

このアーキテクチャをデプロイするには、次の追加コンポーネントが必要です。

設計上の考慮事項

このセクションでは、このリファレンス アーキテクチャを使用して、信頼性、運用効率、セキュリティ、費用、パフォーマンスに関する要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、設計に関する推奨事項について説明します。

信頼性

このセクションでは、Google Cloudでの SQL Server デプロイ用に信頼性の高いインフラストラクチャを構築して運用するための設計上の考慮事項と推奨事項について説明します。

HA と DR の戦略を選択する

Google Cloudに信頼性の高い SQL Server データベースをデプロイするには、 Google Cloud の堅牢なインフラストラクチャと SQL Server の HA および DR 機能を組み合わせた戦略が必要です。この組み合わせにより、ゾーン停止からリージョン災害まで、さまざまな障害からデータベースを保護できます。

SQL Server デプロイの HA と DR の戦略を設計する際は、次の要素を考慮してください。

  • RPO: 障害発生時に許容できるデータ損失量はどのくらいですか？
  • RTO: 障害発生後、データベースをどのくらいの時間で再び稼働させる必要がありますか？
    • RTO を短縮するには、Always On 可用性グループを使用します。
    • ダウンタイムが許容される場合は、バックアップからデータベースを復元するか、手動フェイルオーバーでログシッピングを使用します。
  • 予算: 費用と信頼性のトレードオフを考慮します。
    • コストは高いが信頼性が高い: 非同期レプリケーションを使用して、DR リージョンの追加ノードに Always On 可用性グループを使用します。冗長インフラストラクチャとライセンスを計画します。
    • 中程度のコスト: 別のリージョンに非同期ディスク レプリケーションを実装するか、Backup and DR サービスを使用します。
    • 低コストだが復元時間が長い: データベースをマルチリージョン Cloud Storage バケットにバックアップします。
  • 障害の種類: 処理する必要がある障害の種類。
    • ハードウェア レベル、インスタンス レベル、ゾーンレベルの障害を処理するには、可用性グループを使用します。
    • サイト全体の停止や障害から復旧するには、ログシッピングや非同期データベース レプリケーションを使用した Always On 可用性グループなど、地理的に分散された DR ソリューションが必要です。
  • ビジネスの重要度: アプリケーションはビジネスにとってどの程度重要ですか？
    • ミッション クリティカルなアプリケーションには、最高レベルの可用性、最小限のデータ損失、迅速な復旧を実現する戦略が必要です。
    • 重要度の低いシステムの場合は、許容可能なダウンタイムまたはデータ損失を想定した戦略を検討してください。

次の決定フロー アンケートを使用して、SQL Server データベースに最適な信頼性戦略を選択します。戦略オプションは、データ損失をほぼゼロにする Always On 可用性グループから、費用対効果の高いオフサイト バックアップまで多岐にわたります。

  1. オフサイト バックアップは RPO と RTO を満たしていますか？
    • はい: オフサイトのバックアップまたはログ転送を使用します。
    • いいえ: 次の質問に進みます。
  2. RTO または RPO が 1 分未満ですか？
    • はい（RPO がほぼゼロ）: DR データベース レプリカで SQL Server Always On 可用性グループを使用します。
    • いいえ: 次の質問に進みます。
  3. RTO はどのくらいですか？
    • 5 分未満: 非同期ディスク レプリカを使用する SQL Server Always On 可用性グループを使用します。
    • 1 時間以上: 次の質問に進みます。
  4. RPO はどのくらいですか？
    • 2 時間未満: Backup and DR サービスで SQL Server Always On 可用性グループを使用します。
    • 8 時間以上: オフサイト バックアップまたはログ シッピングを使用します。

適切なバックアップ オプションを選択する

信頼性戦略にデータベース バックアップが含まれている場合は、要件を満たすバックアップ方法を選択します。 Google Cloud には、SQL Server データベースのバックアップ用に、柔軟でエンタープライズ対応の次のオプションが用意されています。

  • Cloud Storage バケットへの直接バックアップ: BACKUP TO URL コマンドと SQL Server（バージョン 2022 以降）の S3 コネクタを使用して、データベース バックアップを Cloud Storage に直接書き込みます。本番環境では、ハッシュベースのメッセージ認証コード（HMAC）アクセスキーを使用できます。このバックアップ オプションは、中間ローカル ストレージを必要とせずに、データベースとログを費用対効果の高い方法で保護します。
  • Compute Engine インスタント スナップショット: Compute Engine の整合性グループと組み合わせた Transact-SQL（T-SQL）のフリーズ / 解凍オペレーションを使用して、複数のディスク（Hyperdisk Balanced ディスクなど）で同時にスナップショットを 1 秒未満で取得します。このオプションを使用すると、マルチディスク データベースで高パフォーマンスの VM レベルのバックアップが可能になり、書き込みフリーズの要件がほぼゼロになります。
  • Backup and DR: Microsoft VSS プロバイダと整合性グループを使用して、アプリケーション整合性のあるスナップショットをオーケストレートします。このバックアップ オプションは、きめ細かいマルチデータベースのポイントインタイム リカバリ（PITR）が必要な場合や、ログを使用してデータベースをロールフォワードする必要がある場合に適しています。
  • Google Cloud NetApp Volumes: ONTAP ストレージ エンジンを使用して、リモート ボルトにインスタント スナップショットと非同期バックアップを作成します。ランサムウェアの迅速な軽減とスペース効率の高いクローンを必要とするレイテンシの影響を受けやすいエンタープライズ アプリケーションには、NetApp Volumes をおすすめします。

統一されたデータ保護ポリシーが必要なマルチクラウドとハイブリッド デプロイの場合は、Veeam、Veritas NetBackup、Cohesity などのサードパーティのバックアップ プロダクトを選択できます。

運用

Compute Engine VM にデプロイされた SQL Server データベースの高可用性と最適なパフォーマンスを確保するには、Cloud Monitoring と Cloud Logging を使用して包括的なモニタリングとアラート システムを設定します。

  • CPU 使用率やメモリ負荷などのコアリソースの指標を継続的に追跡します。ベースライン アラートを設定して、クエリのパフォーマンスが低下する前にリソースの負荷を検出します。
  • データベースの書き込み停止を防ぐため、ディスク容量の使用率を継続的にモニタリングします。サービス全体のステータスをモニタリングし、データベースが予期せず停止したときに通知を受け取るようにアラートを設定します。
  • 高可用性デプロイの場合は、計画外のフェイルオーバーを追跡し、自動障害復旧イベント中に完全な可視性を確保します。
  • システムレベルのテレメトリーに加えて、 Google Cloud は、アクティブ ユーザー接続制限、レプリケーション ラグ、トランザクション レートなど、データベース固有の指標の広範なスイートを提供します。これらの指標を追跡して、SQL Server データベースの可用性とパフォーマンスをモニタリングします。
  • デッドロック、データベースの破損、エージェント ジョブの失敗などのアプリケーション レベルのエラーを SQL Server エラーログから直接キャプチャするには、Logging でカスタム ログベースのアラートを設定します。

セキュリティ

このセクションでは、ワークロードのセキュリティ要件を満たす Google Cloud で SQL Server のデプロイを設計するための設計上の考慮事項と推奨事項について説明します。

ネットワーク セキュリティと分離

  • データベースが外部に公開されないようにするには、VPC 内にプライベート IP アドレスを使用して SQL Server インスタンスをデプロイします。プライベート サービス アクセスを使用して、トラフィックを内部的に転送します。このアプローチにより、データベース トラフィックが公共のインターネットを通過しないようにできます。
  • 承認されたアプリケーション サブネットまたは特定の CIDR ブロックからのトラフィックのみを許可する厳格な VPC ファイアウォール ルールを構成して、データベースへのアクセスをさらに制限します。
  • 転送中のデータを盗聴や傍受から保護するには、すべてのデータベース接続に TLS/SSL を適用して、暗号化された接続を実装します。

暗号化と鍵の制御

  • デフォルトでは、 Google Cloud は Google 管理の AES-256 鍵を使用して、データベース ディスク、一時ファイル、バックアップ内のすべての保存データを自動的に暗号化します。コンプライアンス環境に対応するために、SQL Server の透過的データ暗号化（TDE）機能を使用して、データベース レベルの暗号化を実装できます。
  • データ主権を確保するために、Cloud Key Management Service で顧客管理の暗号鍵（CMEK）を使用できます。CMEK を使用すると、暗号を完全に制御できます。鍵のライフサイクルを管理し、自動ローテーション スケジュールを設定します。必要に応じて、データベースとそのバックアップへのアクセスを直ちに取り消すことができます。

認証と認可

  • データベースを Microsoft Active Directory と統合するか、Identity and Access Management（IAM）を使用して、SQL Server データベースやその他のGoogle Cloud リソース全体で ID 管理を一元化します。
  • ID が確立されたら、最小権限の原則を適用して、ユーザーとアプリケーション サービス アカウントがその機能を実行するために必要な権限のみを持つようにします。ID をきめ細かい SQL Server データベース ロールにマッピングします。

費用の最適化

このセクションでは、このリファレンス アーキテクチャを使用して構築した SQL Server デプロイの設定と運用の費用を最適化するためのガイダンスを示します。費用の最適化は、予算の制約内でワークロードの信頼性とパフォーマンスの要件を満たすデプロイを保証するのに役立ちます。

以下の推奨事項を参考にしてください。

  • 同時マルチスレッディング（SMT）を無効にする: SMT を無効にすると、ライセンス目的で報告されるコア数を 50% 削減できます。CPU を 20% オーバー プロビジョニングしてから SMT を無効にすると、パフォーマンスを犠牲にすることなくライセンス費用を大幅に削減できます。詳細については、コアあたりのスレッド数を設定するをご覧ください。
  • SQL Server Standard エディションを使用する: HA と DR の要件に応じて、Enterprise エディションの代わりに SQL Server Standard エディションを使用することで、ライセンス費用を削減できます。詳細については、SQL Server のエディションとサポートされている機能をご覧ください。
  • ストレージを最適化する: Hyperdisk には、SQL Server デプロイのニーズに基づいて選択できるさまざまなディスク オプションが用意されています。Hyperdisk Balanced は、費用とパフォーマンスのバランスを取ります。スループットと 1 秒あたりの入出力オペレーション（IOPS）を個別にスケーリングできるため、インフラストラクチャの費用をワークロードのニーズに正確に合わせることができます。詳細については、適切なストレージ ディスクタイプを選択するをご覧ください。

パフォーマンスの最適化

このセクションでは、パフォーマンス要件を満たす SQL Server デプロイの設計上の考慮事項と推奨事項について説明します。

Compute Engine VM に SQL Server をデプロイすると、データベースと基盤となるインフラストラクチャを完全に制御できます。ワークロードのパフォーマンスは、選択したインフラストラクチャによって異なります。パフォーマンスと費用、信頼性のバランスを取るには、データベース ノードの VM マシン ファミリーとディスクタイプについて、十分な情報に基づいて決定する必要があります。

適切な VM マシン ファミリーを選択する

Compute Engine VM に選択するマシン ファミリーによって、SQL Server ノードで使用可能な処理能力（vCPU）とメモリ（RAM）が決まります。これらのリソースは、データベースのパフォーマンスに影響します。

主なパフォーマンス ボトルネックに対処する VM マシン ファミリーを選択します。たとえば、SQL Server データベースの CPU 使用率が常に高い場合は、コンピューティング最適化マシン ファミリーからマシンタイプを選択します。SQL Server データベースでディスクからの読み取りが遅い場合は、メモリ最適化マシンタイプを選択します。

次の表は、Compute Engine が提供する VM マシン ファミリー、各マシン ファミリーの主なユースケース、SQL Server データベースのパフォーマンスへの影響を比較したものです。

マシン ファミリーとシリーズ 主なユースケース SQL Server のパフォーマンスへの影響
汎用（N4 マシンシリーズ） 価格とパフォーマンスのバランス ほとんどのワークロードでは、このマシン ファミリーをベースとして使用します。N4 マシンシリーズは、複合用途のデータベース、ウェブ アプリケーション、開発環境またはテスト環境に最適な CPU とメモリのバランスを提供します。
コンピューティング最適化（C3 または C4 マシンシリーズ） コアあたりのパフォーマンスが最も高い このマシン ファミリーは、CPU バウンドのワークロードに使用します。複雑なクエリを実行するデータベース、大量のデータを処理するデータベース、または多数のオンライン トランザクション処理（OLTP）オペレーションを提供するデータベースには、C3 マシンシリーズと C4 マシンシリーズを使用します。これらのシリーズのマシンタイプを使用すると、クエリの実行時間を大幅に短縮できます。
メモリ最適化（M3 または M4 マシンシリーズ） メモリと vCPU の比率が高い このマシン ファミリーは、メモリ使用量の多いアプリケーションに最適です。SQL Server は、データと実行プランをメモリにキャッシュに保存します。これにより、ディスクから読み取るよりも高いパフォーマンスが得られます。オンライン分析処理（OLAP）用の非常に大きなデータベースやデータ ウェアハウスでは、クエリは通常、大きなテーブルとデータセットをスキャンします。このようなユースケースでは、メモリを増やすことでパフォーマンスを向上させることができます。

詳細については、マシン ファミリーのリソースと比較ガイドをご覧ください。

適切なストレージ ディスクタイプを選択する

ディスク パフォーマンスは、データベースの応答性にとって重要な要素であり、アプリケーションのパフォーマンスに不可欠です。 Google Cloudが提供するディスクタイプの場合、パフォーマンス機能は次の指標で示されます。

  • IOPS: ディスクが 1 秒あたりに処理できる読み取り / 書き込みリクエストの数。IOPS は、顧客レコードの更新や注文の処理など、多くの小規模なランダム読み取り / 書き込みオペレーションを伴う OLTP ワークロードにとって重要です。
  • スループット: ディスクとの間で 1 秒あたりに移動できるデータの合計量。スループットは、レポートの実行、データ ウェアハウジング、バックアップの実行など、大量のデータをスキャンする OLAP ワークロードに不可欠です。

次の表は、選択できる Google Cloud ディスクタイプを比較したものです。

ディスクタイプ パフォーマンス特性 ワークロードの適合性
SSD 永続ディスク（pd-ssd） VM マシンタイプとディスクサイズに応じて中～高パフォーマンス ディスクのサイズと VM の vCPU に応じてパフォーマンスをスケーリングする必要があるワークロード。詳細については、Persistent Disk のパフォーマンスの概要をご覧ください。
Hyperdisk Balanced 構成可能な IOPS とスループットによるハイ パフォーマンス 本番環境の SQL Server のデータファイルとログファイル。Hyperdisk Balanced を使用すると、ディスクサイズとは無関係に、ワークロードのニーズに基づいて IOPS とスループットを構成できます。
Hyperdisk Extreme 構成可能な IOPS による非常に高いパフォーマンス 大規模な金融システムや e コマース システムなど、最大 IOPS と最小レイテンシを必要とするハイエンドのミッション クリティカルな OLTP ワークロード。
ローカル SSD 他のディスクタイプと比較して最高の IOPS とスループット 永続ディスクの耐久性を必要としない一時データ。tempdb システム データベースや Windows ページファイルなどのデータの場合、ローカル SSD は VM に物理的にアタッチされているため、レイテンシが最も低くなります。

インフラストラクチャをパフォーマンス要件に合わせる

ワークロードのパフォーマンス要件に基づいて、VM マシンタイプとディスクタイプを選択します。次の表に、さまざまなワークロード シナリオのインフラストラクチャ構成の推奨事項を示します。

シナリオ パフォーマンス要件 推奨されるマシンタイプとディスク構成
OLTP 用の高トランザクション e コマース データベース 数千件の小規模な同時読み取りと書き込みを処理する高い IOPS

VM マシンタイプ: トランザクションを効率的に処理するために、コンピューティング最適化マシンタイプ（C4 マシンシリーズなど）を選択します。

データディスクとログディスク: Hyperdisk Balanced ディスクを使用します。トランザクションの需要を満たすために、高いレベルの IOPS をプロビジョニングします。データとログに別々のディスクを使用します。

tempdb: ローカル SSD ディスクを使用して一時オペレーションをオフロードし、パフォーマンスを最大化します。
OLAP 用の会社のデータ ウェアハウス レポート作成のためにテラバイト単位のデータをスキャンして集計する高スループット

VM マシンタイプ: メモリ最適化マシンタイプ（M4 マシンシリーズなど）を選択して、大規模なデータセットをできるだけ多くキャッシュに保存できるようにします。

データディスク: Hyperdisk Balanced ディスクを使用します。大量のデータ スキャンを高速化するために、高いスループットをプロビジョニングします。
開発サーバーまたはステージング サーバー ピーク パフォーマンスよりも費用対効果

VM マシンタイプ: E2 または N4 マシンシリーズから、マシンサイズが小さい汎用マシンタイプを選択します。

ディスク: 低コストで許容可能なパフォーマンスを実現するために、すべてのデータベース ファイルにバランス永続ディスク（pd-balanced）を使用します。

デプロイ

このリファレンス アーキテクチャをデプロイするには、次のいずれかのリソースを使用します。

次のステップ

寄稿者

著者:

その他の寄稿者: Kumar Dhanagopal | クロスプロダクト ソリューション デベロッパー