SQL Serverでビジネスを運営している場合、ダウンタイムは収益の損失を意味します。SQL Serverでは、データベースの可用性を維持する主な方法として2つを提供しています：Always On可用性グループ（AG）とAlways Onフェールオーバークラスタインスタンス（FCI）です。どちらもWindows Serverフェールオーバークラスタリング（WSFC）を必要とし、ハードウェアおよびソフトウェア障害から保護しますが、異なるレベルで動作し、異なるトレードオフをもたらします。
ここでは、それぞれの仕組み、相違点、およびどのシナリオに適合するかを解説します。ログ配送、ストレージレベルレプリケーション、その他のメカニズムについては扱わず、AGとFCIの直接比較に焦点を当てます。
開始前に名称に関する注意点：マイクロソフトの正式名称はAGであり、AAGやAOAGではありません。他の略称が使用されることもありますが、AGが正しい表記です。
目次
Always On可用性グループ
Always On可用性グループはデータベースレベルで動作します。データベースのセットを選択し、それらをグループ化すると、AGがプライマリレプリカから最大8つのセカンダリレプリカへレプリケーションを行います。グループ化されたデータベースはユニットとしてまとめてフェイルオーバーします。
各レプリカは、独自のWSFCノード上にある個別のSQL Serverインスタンスです。プライマリがすべての読み取りと書き込みを処理します。セカンダリはプライマリからトランザクション ログ データを受信し、同期を維持するために適用します。従来のデータベース ミラーリング設定のような監視者ロールは存在せず、クォーラムは完全に WSFC によって処理され、レプリカをホストしているかどうかに関係なく、クラスター内のすべてのノードが参加します。
データベース ミラーリングについて言えば、技術的には SQL Server 2022 でもまだ存在しますが、非推奨となっています。Microsoft の推奨は AG への移行です。
同期コミットと非同期コミット
これは、高可用性（HA）を構築するか、災害復旧（DR）を構築するかを決定する選択です。同期コミットモードでは、プライマリはセカンダリがログレコードを固定したことを確認するまで待機し、その後クライアントにトランザクションを承認します。フェイルオーバー時のデータ損失はありませんが、その代償としてトランザクションのレイテンシが発生します。すべての書き込みは少なくとも1つのセカンダリへの往復通信を必要とします。書き込み負荷の高いワークロードでは、この遅延ペナルティは恒常的かつ避けられません。このモードは自動フェイルオーバーをサポートします。
非同期コミットモードでは、プライマリは待機しません。トランザクションはローカルでコミットされ、ログレコードはバックグラウンドでセカンダリに送信されます。遅延は低減されますが、セカンダリが追いつく前にプライマリがダウンした場合、データ損失が発生する可能性があります。地理的に離れたレプリカ間ではネットワーク遅延により同期コミットが非現実的となるため、災害対策（DR）オプションとして有用です。フェイルオーバーは手動かつ強制実行となります。
モードの混在が可能です：最大5つのレプリカ（プライマリ含む）を同期モード、残りを非同期モードに設定できます。多くの本番環境では、ローカルのHAペアに同期モード、遠隔のDRレプリカに非同期モードを採用しています。
AGに必要な要件
AGはWSFC上で動作します。Windows環境ではこれを回避する方法はありません。各AGは独自のクラスターロールを持ち、クライアントが接続する仮想ネットワーク名（リスナー）を割り当てられます。リスナーはトラフィックを現在のプライマリノードにリダイレクトするため、アプリケーションはどのサーバーがアクティブかを知る必要がありません。
補足：クラスタレスAG（「読み取り専用」AG）も存在しますが、手動フェイルオーバーのみをサポートし、HA（高可用性）やDR（災害復旧）ソリューションにはなりません。また、Pacemakerを使用したLinux上のAGもありますが、ここではWindows環境での展開に焦点を当てています。
Always ON可用性グループアーキテクチャ
Always On可用性グループで得られるメリット
最大9つのレプリカ（プライマリ1つ＋セカンダリ8つ）により柔軟性が向上します。セカンダリをアクティブに設定し、読み取り専用クエリやバックアップに使用できるため、セカンダリハードウェアが遊休状態になることはありません。AGは自動フェイルオーバー（同期モード）と手動/強制フェイルオーバー（非同期モード）の両方をサポートします。単一技術で高可用性（HA）と災害復旧（DR）の両方を実現します。
AGにはデータ破損検出機能が組み込まれています。データは整合性チェックを伴い順序通りにコピー・適用されます。プライマリでページが破損した場合、AGはセカンダリから正常なコピーを取得できます。
Always On可用性グループの制限事項
AGの管理上最大の課題は、従来よりサーバーレベルのオブジェクトでした。AGが複製するのはデータベースであり、インスタンスそのものではありません。つまり、SQL Serverログイン、リンクサーバー、SQL Agentジョブ、その他masterやmsdbに保存されるあらゆる要素は複製対象外となります。従来のAG構成では、DBAはこれらを手動でスクリプト化し、各セカンダリに展開し、同期を維持する必要がありました。ログインを1つでも漏らしたりSIDの不一致が発生すると、フェイルオーバー時にアプリケーションが動作しなくなります。
SQL Server 2022では「コンテインド可用性グループ」によりこの問題が解決されました。これはAG内に独自のmasterおよびmsdbデータベースを作成します。AGリスナー経由で作成されたログインやジョブは自動的にレプリケートされます。これは大幅な改善ですが、インスタンスの管理方法を再構築する必要があり、AGリスナー外で作成されたオブジェクトは依然として同期されません。
もう一つのコストは同期コミットのレイテンシです。コミットされたトランザクションは、クライアントが確認応答を得る前に、少なくとも1つのセカンダリへのネットワーク往復を必要とします。読み取り中心のレポートワークロードでは問題になりませんが、書き込み集約型のOLTP環境では、すべての操作に測定可能な遅延が生じます。非同期モードではこれを回避できますが、その代わりにフェイルオーバー時のデータ損失リスクを受け入れることになります。
AGのほとんどの機能にはEnterprise Editionが必要です（Standard EditionのAGはグループあたり1データベースに制限されます）。また、AGの移動にはFailover Cluster Managerを使用せず、SQL Serverツールを使用してください。
さらに、すべてのレプリカは同一のWSFC内に存在する必要があり、同期レプリカは5つまでに制限されます。
フェールオーバー クラスター インスタンス(FCI)
FCIはインスタンスレベルで動作します。個々のデータベースを複製する代わりに、単一のSQL Serverインスタンスを複数のWSFCノードにまたがってインストールします。同時にアクティブになるノードは1つだけです。そのノードが障害を起こした場合、インスタンス全体（データベース、ログイン、エージェント ジョブなどすべて）が別のノードに移動します。
AGとの主な違い：FCIは共有ストレージを使用します。データベースファイルは、すべてのクラスターノードがアクセス可能なストレージ（iSCSI SAN、ファイバーチャネル、Storage Spaces Direct、StarWind Virtual SAN、またはSMBファイル共有）上に存在し、フェールオーバー時にはそのストレージの所有権がノード間で移行されます。データの権威あるコピーが単一で存在するため、フェールオーバーモードに関係なく、常にレプリケーション遅延ゼロ、データ損失ゼロを実現します。同期コミットのオーバーヘッドも、非同期のリスクウィンドウも存在しません。
SQL Server フェールオーバー クラスタ インスタンス アーキテクチャ
FCIで得られるもの
FCIの中核的な利点は、SQL Serverインスタンス全体を単一の単位として保護することです。データベース、ログイン、リンクサーバー、エージェントジョブ、サーバーレベルの設定など、すべてが追加の同期ロジックなしで同時にフェイルオーバーします。SIDの不一致リスクも、セカンダリでのログインの忘れも、間違ったレプリカで実行されるエージェントジョブもありません。ノードAで実行されるものは、ノードBでもまったく同じように実行されます。
これによりFCIの運用は極めて簡素化されます。DBAが管理するのは単一のSQL Serverインスタンスであり、プライマリとレプリケーションの健全性を監視するセカンダリ群ではありません。数十のSQLインスタンスを運用する組織では、この簡素化効果が相乗的に発揮され、維持管理すべき運用面が大幅に削減されます。
FCIはSQL Server Standard Editionで動作するため、ライセンスコストに大きな影響を与えます。AGの機能の大半（読み取り可能セカンダリ、グループごとの複数データベース、2つ以上のレプリカ）にはEnterprise Editionが必要です。中規模環境では、StandardとEnterpriseのライセンス差額は非常に大きくなる可能性があります。
クライアントは仮想ネットワーク名に接続するため、フェイルオーバー時のアプリケーション再構成が不要です。
さらにFCIはSQLレイヤーでデータを複製しないため、コミット遅延のペナルティが発生しません。全ての書き込みはセカンダリノードへの往復通信なしにストレージへ直接書き込まれます。書き込み負荷の高いOLTPワークロードにおいて、これはFCIがHA構成でもスタンドアロンインスタンスと同等の書き込み性能を実現することを意味します。
共有ストレージ：単一障害点の解決
FCIに対する従来の批判は、共有ストレージが単一障害点を作り出すという点にある。SANがダウンすれば、クラスタも同様にダウンする。これは、共有ストレージが単一の物理SANアプライアンスを意味していた時代には正当な懸念だった。
現代のソフトウェア定義ストレージはこの構図を変えます。StarWind Virtual SANのようなソリューションは、クラスタノード間でブロックレベルでストレージを複製し、フェイルオーバークラスタに対してミラーリングされたボリュームを共有ストレージとして提示します。各ノードは独自のローカルディスクを持ち、StarWindがそれら間でデータを同期的にミラーリングします。ノード（とそのディスク）が故障しても、他のノードには完全なコピーが既に存在します。故障する外部SANは存在せず、ストレージ層自体に冗長性が組み込まれています。
これにより「SANがSPOF（単一障害点）となる」という議論は完全に解消されます。FCIの運用上の簡便性（インスタンスレベルの保護、レプリケーション遅延ゼロ、コミット遅延なし）を、少なくともAGのデータベースレベルレプリケーションと同等の耐障害性を持つストレージレベルのフォールトトレランスと両立させます。多くの場合、ストレージレプリケーションはSQL Serverに対して透過的（通常のディスクとして認識される）であるため、管理がより簡素化されます。
フェールオーバー クラスター インスタンスの制限事項
フェールオーバーは可用性グループ（AG）よりも時間がかかります。SQL Server はアクティブ ノードで停止し、パッシブ ノードで起動し、すべてのデータベースでクラッシュ リカバリを実行する必要があります。中規模のインスタンスの場合、典型的なフェールオーバーには 30～60 秒かかります。数百ギガバイトのバッファ プールを持つ非常に大規模なインスタンスではさらに時間がかかる場合がありますが、これは例外的なケースです。
読み取り可能なセカンダリが存在しないため、フェールオーバーが発生するまでパッシブノードはSQLの観点からアイドル状態となります。読み取りトラフィックの負荷分散が必要な場合は、AGがそのための選択肢となります。
FCI単体ではローカルHAを提供しますが、地理的なDRには適していません。サイト間保護を実現するには、FCIとAGを組み合わせます。FCIをローカルなインスタンスレベルのフェールオーバーに、非同期AGレプリカを遠隔サイトでのDRに活用します。
SQL Server 2022 および 2025 の高可用性に関する新機能
AG と FCI の両方が最近のリリースで改善されました。選択において重要な点を以下に示します。
コンテインド可用性グループ（2022年に導入）
AGの最大の課題の一つは、サーバーレベルオブジェクトの同期化が不十分だった点です。DBAはログイン、権限、SQL Agentジョブを手動でスクリプト化し、各セカンダリレプリカにコピーする必要がありました。コンテインド可用性グループは、AG内に存在する専用のmasterデータベースとmsdbデータベースを作成することでこの問題を解決します。リスナー経由でユーザーやジョブを作成すると、自動的に全ノードにレプリケートされます。
設定可能なAGコミット時間とスケーリング（2025年導入）
SQL Server 2025はパフォーマンスチューニングをさらに進化させます。設定可能なAGコミット時間（従来は10msに固定）を導入。管理者はサーバーレベルでこの値を微調整し、同期コミットモードのレイテンシを最適化できます。さらに、SQL Server 2025 Standard Editionは最大32コア/256GB RAM（従来は24コア/128GB）まで拡張可能となり、エンタープライズ版ライセンスを直ちに必要とせずに、Standard Edition上のAGを中規模から大規模なワークロードで大幅に実用化できます。
実体験に基づく実用的な考察
AGとFCIの選択は、保護対象、書き込みプロファイル、管理可能な運用複雑性の度合いによって決まります。
AGを選択すべき場合：- リモートサイトへの地理的DRが必要な場合- レポートやバックアップオフロード用の読み取り可能セカンダリが必要な場合- 読み込みが中心のワークロードで同期コミットの遅延が許容できる場合
FCIを選択すべき場合：- インスタンスレベル（ログイン、ジョブ、サーバー設定など全て）の保護が必要な場合- 書き込みが集中するワークロードで同期レプリケーションの遅延が許容できない場合- 日々の管理を簡素化し運用対象範囲を縮小したい場合- Standard Editionのライセンスが予算に合致する場合 StarWind VSANのようなソフトウェア定義ストレージがストレージレベルの冗長性を提供するため、従来の共有ストレージにおけるSPOF（単一障害点）の懸念はもはや適用されません。
両方を組み合わせる：それぞれの長所を最大限に活用したい場合。FCIはデータ損失ゼロ、コミットオーバーヘッドゼロでローカルインスタンスレベルのHAを処理します。AGはリモートロケーションに非同期レプリカを配置し、サイト間DRを追加します。このハイブリッドアプローチは本番環境で一般的であり、ローカル障害とサイトレベルの災害の両方をカバーします。
いずれを選択する場合でも、導入の一貫性が最も重要です。複数ノードにまたがる設定を行う場合は、自動化してください。手動設定では設定のばらつきや人的ミスが発生する可能性が高まります。HA環境では、設定ミスはフェイルオーバーが発生して機能不全が生じるまで表面化しません。
クラスタには適切な監視を組み合わせてください。クォーラム状態、ストレージレイテンシ、同期の健全性を継続的に追跡します。リアルタイムで検知した予期せぬフェイルオーバーは「インシデント」です。ユーザーから報告を受けて初めて気付くものは「サービス停止」です。
結論
AGとFCIは同じ問題を異なる方法で解決し、どちらが普遍的に優れているわけではありません。
AGはデータベースレベルの細分化、1秒未満のフェイルオーバー、読み取り可能なセカンダリ、組み込みのDR機能を提供する。その代償として運用複雑性の増大、全機能利用のためのEnterprise Editionライセンス、同期コミットによる書き込み遅延ペナルティが生じる。SQL Server 2022のコンテインドAGは管理ギャップを縮小したが、AG設定には依然として継続的な注意が必要である。
FCIは完全なインスタンスレベルの保護を提供します。データベース、ログイン、ジョブなど全てが単位としてフェイルオーバーします。管理はより簡素で、Standard Editionでも動作し、レプリケーションによる書き込みレイテンシのオーバーヘッドはありません。StarWind VSANのようなソフトウェア定義ストレージと組み合わせることで、ストレージ層自体が冗長性を獲得し、従来の単一障害点の問題を解消。AGよりも複雑性を抑えつつ、完全な耐障害性を備えたHAソリューションを実現します。
関連したトピックス
- SQL ServerとMySQLリレーショナルデータベースの比較
- SQL Server on Linuxの可用性について ①
- データウェアハウスとは何なのか？
- SQL Server for Linuxがすぐそこに！ – WindowsデータベースがHA機能を追加
- ユーザ・データベースの最適化とOracle支出の削減
- SQL Server on Linuxの可用性について ②
- Dockerfilesを使用してSQL Server Dockerコンテナを構成
- DBMotoでのMicrosoft SQL Server 2017 on Linuxとの接続検証
- スクリプトを使用してSQL Serverにデータベースを作成する方法
- Microsoft SQL Serverのバックアップとリストア手法
RSSフィードを取得する
