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 にデプロイ可能: Linux デプロイのクラスタ マネージャーとして、Pacemaker などのサードパーティ ツールを使用できます。

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