アクティブ-スタンバイとは
アクティブ-スタンバイ（Active-Standby）とは、コンピュータシステムやネットワークにおいて、サービスの継続性を確保するための冗長化方式の一つであり、通常時は一台のシステム（アクティブ系）が稼働してサービスを提供し、もう一台のシステム（スタンバイ系またはパッシブ系）が待機状態にあって、アクティブ系に障害が発生した場合に自動的または手動で処理を引き継ぐ仕組みを指します。
この構成は、特にシステム停止による影響が大きいクリティカルなシステムで採用され、高可用性（High Availability, HA）を実現するために広く利用されています。
アクティブ-スタンバイの基本的な概念
アクティブ-スタンバイ構成は、障害発生時にもサービスの中断を最小限に抑えることを目的とした、フェイルオーバーの典型的な実装パターンです。
主な概念は以下の通りです。
- 高可用性（High Availability, HA）: システムが障害発生時にも継続して機能し、サービスを提供できる能力を指します。アクティブ-スタンバイは、このHAを実現するための主要な手段です。
- 稼働系（Active System）: 通常時において、実際に処理を実行し、サービスを提供しているシステムです。
- 待機系（Standby System / Passive System）: アクティブ系に障害が発生した場合に、その処理を引き継ぐために準備されているシステムです。通常時はサービスを提供せず、アクティブ系の状態を監視したり、データを同期したりしています。
- フェイルオーバー（Failover）: アクティブ系に障害が発生した際に、待機系が自動的に、または手動操作によってアクティブ系に切り替わり、サービスを引き継ぐ一連のプロセスです。
- レプリケーション/データ同期: アクティブ系で発生したデータの変更やセッション情報などを、リアルタイムまたは準リアルタイムで待機系に複製・同期することで、フェイルオーバー後もデータの整合性を保ち、直前の状態からサービスを再開できるようにします。
アクティブ-スタンバイ構成の動作原理
アクティブ-スタンバイ構成では、以下のような手順で高可用性を維持します。
- 通常稼働時:
- アクティブ系システムがすべてのリクエストを受け付け、サービスを提供します。
- スタンバイ系システムは、アクティブ系の死活監視（ハートビートなど）を継続的に行います。
- アクティブ系からスタンバイ系へ、データや設定情報が同期されます。この同期の頻度や方法は、RPO（Recovery Point Objective: 許容されるデータ損失量）やRTO（Recovery Time Objective: 許容される復旧時間）の要件に応じて決定されます。
- 障害検知:
- スタンバイ系システムがアクティブ系からのハートビートを受信できなくなった場合や、特定のサービスが応答しなくなった場合など、予め定められた基準に基づいてアクティブ系の障害を検知します。
- 複数のノードや監視システムが協調して障害を判断することで、誤検知による不要なフェイルオーバーを防ぎます。
- フェイルオーバーの実行:
- 障害が検知されると、スタンバイ系システムがアクティブ系への昇格を開始します。
- ネットワーク上の仮想IPアドレス（Virtual IP Address, VIP）を待機系に引き継いだり、DNSレコードを更新したりすることで、クライアントからのリクエストが新しいアクティブ系にルーティングされるように切り替えます。
- 未処理のセッションやトランザクションの引き継ぎを行います。
- 復旧と再同期:
- フェイルオーバーが完了すると、旧アクティブ系は停止するか、修理のために切り離されます。
- 旧アクティブ系が修理・復旧された後、新しいアクティブ系（旧スタンバイ系）のデータと同期され、再びスタンバイ系として運用に戻る準備ができます。
アクティブ-スタンバイのメリットとデメリット
メリット
- 実装と管理のシンプルさ: アクティブ-アクティブ構成と比較して、同時に複数のシステムがサービス提供している状態の整合性を維持する必要がないため、設計と実装が比較的シンプルです。
- リソースの有効活用（場合による）: スタンバイ系は通常時にサービス提供を行わないため、リソースの消費を抑えたり、パッチ適用やバックアップなどのメンテナンス作業を容易に行ったりできます。
- データの一貫性維持: データの同期が比較的容易であり、特に共有ストレージを使用する構成では、データの一貫性を高めやすくなります。
- 障害発生時の挙動予測性: フェイルオーバー時の動作が比較的予測しやすく、テストしやすい傾向にあります。
デメリット
- リソースの非効率性: スタンバイ系は通常時にはサービスを提供しないため、その分のハードウェアリソースは遊休状態となり、リソース効率が低いと言えます。
- フェイルオーバー時のダウンタイム: 切り替え時に、スタンバイ系の起動、データの整合性チェック、仮想IPアドレスの引き継ぎなどが必要となるため、ある程度のダウンタイム（数秒から数分）が発生します。ミッションクリティカルなシステムでは、このダウンタイムが許容されない場合があります。
- スケーラビリティの限界: アクティブ系一台で処理するため、負荷が増大した場合のスケーラビリティは限定的です。負荷分散を目的とする場合には不向きです。
- スプリットブレイン問題のリスク: ネットワークの分断などにより、アクティブ系とスタンバイ系の両方が自身をアクティブと誤認し、それぞれがサービスを開始してしまう「スプリットブレイン」問題が発生する可能性があります。これを防ぐための対策（クォーラム、フェンシングなど）が必要です。
アクティブ-スタンバイの主な適用例
- データベースクラスタ: データベースサーバーのHA構成で最も一般的な形式です。プライマリ（アクティブ）データベースとセカンダリ（スタンバイ）データベース間でデータを同期し、プライマリ障害時にセカンダリが昇格します。
- ファイアウォール/ロードバランサー: ネットワークの境界に設置されるこれらの機器は、単一障害点（Single Point of Failure, SPoF）とならないよう、アクティブ-スタンバイ構成が採用されることが多いです。
- 仮想化環境のHAクラスタ: VMware vSphere HAやMicrosoft Hyper-V Failover Clusteringなどで、物理ホスト障害時にその上で稼働していた仮想マシンを別のホストで自動的に再起動する機能も、広義のアクティブ-スタンバイ（またはN+1スタンバイ）と言えます。
- ファイルサーバー/アプリケーションサーバー: 重要な業務アプリケーションや共有ファイルを提供するサーバーのダウンタイムを避けるために利用されます。
アクティブ-スタンバイは、システムの高可用性を実現するための冗長化方式の一つで、通常時はアクティブ系がサービスを提供し、スタンバイ系が待機・監視を行います。アクティブ系に障害が発生すると、自動的または手動でスタンバイ系に処理が引き継がれる（フェイルオーバー）ことで、サービスの中断を最小限に抑えます。
実装のシンプルさやデータの一貫性維持がメリットである一方で、リソース効率の低さやフェイルオーバー時のダウンタイム、スプリットブレイン問題のリスクといったデメリットも存在します。データベースクラスタ、ファイアウォール、ロードバランサーなどで広く採用されており、システムの信頼性を確保する上で不可欠な技術です。
関連用語
お問い合わせ
システム開発・アプリ開発に関するご相談がございましたら、APPSWINGBYまでお気軽にご連絡ください。
APPSWINGBYの
ソリューション
APPSWINGBYのセキュリティサービスについて、詳しくは以下のメニューからお進みください。
システム開発
既存事業のDXによる新規開発、既存業務システムの引継ぎ・機能追加、表計算ソフトによる管理からの卒業等々、様々なWebシステムの開発を行っています。
iOS/Androidアプリ開発
既存事業のDXによるアプリの新規開発から既存アプリの改修・機能追加まで様々なアプリ開発における様々な課題・問題を解決しています。
リファクタリング
他のベンダーが開発したウェブサービスやアプリの不具合改修やソースコードの最適化、また、クラウド移行によってランニングコストが大幅にあがってしまったシステムのリアーキテクチャなどの行っています。
ご相談・お問い合わせはこちら
APPSWINGBYのミッションは、アプリでビジネスを加速し、
お客様とともにビジネスの成功と未来を形作ること。
私達は、ITテクノロジーを活用し、様々なサービスを提供することで、
より良い社会創りに貢献していきます。
T関する疑問等、小さなことでも遠慮なくお問合せください。３営業日以内にご返答致します。
ご相談・お問合せはこちら
APPSWINGBYのミッションは、アプリでビジネスを加速し、お客様とともにビジネスの成功と未来を形作ること。
私達は、ITテクノロジーを活用し、様々なサービスを提供することで、より良い社会創りに貢献していきます。
IT関する疑問等、小さなことでも遠慮なくお問合せください。３営業日以内にご返答させて頂きます。
