IT用語集 2022/12/05

HA構成とは？種類と特徴などをわかりやすく解説

コラム

システムを止めずに稼働させ続けるには、冗長化を前提とした「HA構成（高可用性構成）」が欠かせません。HA構成にはいくつかの型があり、求める停止許容時間や運用体制に応じて選び分ける必要があります。この記事では、HA構成の基本（可用性の考え方、仕組み、代表的な種類）と、DR構成との違いまでを整理します。読み終える頃には、RTO/RPOの考え方も含めて「自社はどの構成が必要か」を判断できる状態を目指します。

HA構成とは

この章では、HA構成の定義と、なぜ必要とされるのかが分かります。

HAとは「High Availability（高可用性）」の略で、システムやサービスを停止させず、継続して稼働させることを目指す設計・運用の考え方です。何らかの障害が起きても、予備の機器や別系統の構成へ切り替えることで、サービス停止（ダウンタイム）を最小化します。

この考え方が重視される背景には、デジタル化の進展により、システム停止が売上・業務・信用に直結しやすくなったことがあります。たとえばECサイトが数時間停止するだけでも、その間の売上機会が失われるだけでなく、復旧後のブランドイメージや利用者の信頼に影響する可能性があります。

かつては、コストや運用負荷の制約から、あらゆるシステムに十分な冗長性を持たせることが難しい場面もありました。しかし近年は、仮想化やクラウドの普及、運用技術の成熟により、以前より現実的なコストでHA構成を取り入れられるケースが増えています。

また、金融・医療など、事業特性上「止まること」の影響が大きい領域では、規制や業界ガイドライン、契約要件として高可用性が求められることもあります。

「止めない」には対象範囲の定義が先に必要

HA構成は「システム全体を止めない」取り組みですが、実務では対象範囲の定義が欠かせません。例えば、Webフロントは止められないがバッチ処理は夜間停止できる、決済は止められないが帳票出力は復旧後でもよい、といった具合に、止められない機能と許容できる停止を切り分けます。

ここが曖昧だと、コストをかけるべき範囲が広がりすぎたり、逆に重要部分の冗長化が漏れたりします。HA構成の検討は、まず「止められない業務・機能の定義」から始めるのが現実的です。

可用性とは

この章では、可用性の意味と、似た概念（信頼性・保守性）との違いが分かります。

可用性（かようせい）とは「必要なときに使える状態であること」を指します。IT分野では、システムやサービスが利用者にとって必要とされた時に、継続して利用可能である状態（またはその度合い）を意味します。

たとえば、顧客が常時取引できる銀行システムは可用性が高いといえます。一方で可用性が低いと、障害によって利用できない時間が増え、顧客の信頼や事業継続に深刻な影響を与えかねません。

なお「可用性」は「信頼性」と混同されがちですが、重視するポイントが異なります。信頼性は「壊れにくさ（障害が起きにくいこと）」に焦点があり、可用性は「障害が起きても、止まらず（または短時間で）使えること」に焦点があります。さらに実務では、復旧のしやすさ（保守性）も含め、可用性・信頼性・保守性をセットで捉えると、運用設計の判断がしやすくなります。

可用性の目標は「%」だけで決めない

可用性は「99.9%」「99.99%」のように数字で語られることがありますが、数字だけで設計を進めると判断を誤りやすくなります。重要なのは、停止の許容時間と復旧の設計を現実の運用に落とし込むことです。

そのため実務では、可用性の議論をRTO/RPOとセットにすると整理しやすくなります。

RTO（目標復旧時間）：障害発生から「いつまでに復旧すべきか」
RPO（目標復旧時点）：復旧時に「どこまでのデータが残っていればよいか（どれだけ戻りが許容されるか）」

例えば「数分で復旧が必要」なのか「数時間の停止は許容できる」のか、「直前までのデータが必要」なのか「前日分まででもよい」のかで、必要な構成は大きく変わります。

HA構成の仕組み

この章では、HA構成が冗長化と切り替えで成立すること、そして運用設計が重要であることが分かります。

HA構成（高可用性構成）は、冗長化と切り替え制御によって実現されます。代表的な考え方の一つが「クラスタリング」で、複数のコンピューター（ノード）を組み合わせ、全体として一つのサービスを提供する形に設計します。

クラスタには、性能向上を主目的とするもの（HPCクラスタなど）と、可用性向上を主目的とするもの（HAクラスタ）があります。本記事で扱うHAクラスタでは、障害検知と切り替え（フェールオーバー）を軸に、サービス停止の最小化を狙います。

一般的に、HAクラスタは「稼働系（アクティブ）」と「待機系（スタンバイ）」で役割を分けます。平常時は稼働系が処理を担当し、待機系は障害に備えて準備します。稼働系で障害が発生した場合、待機系へ自動（または手動）で切り替えて処理を引き継ぎ、影響を抑えます。

ただし、HA構成で本当に重要なのは「切り替えができること」だけではありません。監視や切り替えの誤判定を想定した設計、切り替え後も正しくサービスを提供できる構成（依存関係の整理）、そして運用手順の整備まで含めて初めて、安定した可用性が実現します。

フェールオーバーで起きやすい落とし穴

フェールオーバーは「切り替えれば終わり」ではなく、切り替え後の整合性と復旧手順が要点になります。代表的な落とし穴として、次のようなものがあります。

スプリットブレイン：通信断などで両系が「自分が稼働系」と誤認し、二重に書き込みが発生する
依存先が単一障害点：アプリは冗長でも、DNS、認証基盤、共有ストレージ、監視基盤などが単一で止まる
切り替え後の性能不足：待機系が想定負荷に耐えられず、復旧したが遅くて業務にならない
運用が追いつかない：監視の閾値や判断基準が曖昧で、誤検知・誤切り替えが増える

これらは構成図だけでは見落とされがちです。監視・切り替え・復旧の「一連の動き」が机上と実機で一致するかを、テストと手順整備で確認することが重要です。

HA構成の種類とそれぞれの特徴

この章では、代表的なHAの型（コールド／ウォーム／ホット、負荷分散）を比較し、選び分けの観点が分かります。

HA構成は、待機系の状態や構成目的によっていくつかの型に分けられます。ここでは代表的な構成の特徴と、メリット・デメリットを整理します。

コールドスタンバイ構成

コールドスタンバイ構成は、稼働系（アクティブ）と待機系（スタンバイ）を用意するものの、待機系は停止状態（電源オフ、あるいはサービス停止）で待たせる構成です。障害が起きた場合、待機系を起動し、役割を引き継がせます。

メリットは、待機系を止めておけるためコスト（電力や保守負荷）を抑えやすい点です。構成も比較的シンプルで、導入の難易度が上がりにくい傾向があります。

一方デメリットは、障害発生時に待機系の起動や引き継ぎが必要になるため、切り替えまでの時間が長くなりやすい点です。サービス停止時間を短くできない環境では、要件に合わないことがあります。

コールドが向く典型例

停止許容時間が比較的長く、コストを抑えたい場合に向きます。例えば社内向けの一部業務システムなど、「止まると困るが、短時間の停止は許容できる」ケースで検討されます。

ホットスタンバイ構成

ホットスタンバイ構成は、待機系の電源をオンにし、稼働系と同等の設定やデータを保持した状態で待たせる構成です。稼働系で障害が起きると、待機系へ迅速に切り替え（フェールオーバー）できます。

メリットは、切り替えが速く、ダウンタイムを抑えやすい点です。待機系が稼働準備を整えているため、復旧までの時間が短くなり、業務影響の最小化につながります。

デメリットは、待機系を常時稼働させるためコストが増えやすい点です。また、設定・データ同期の仕組みや監視が必要になり、構成と運用が複雑化しやすい点にも注意が必要です。

ホットで必ず詰めるべき論点

切り替え後のIP/DNSやルーティングがどう変わるか（利用者は同じ接続先でよいか）
データ同期の方式と遅延（同期方式によってRPOが変わる）
切り替え権限と判断基準（自動切り替えにするのか、手動承認を挟むのか）

「速く切り替えたい」ほど、運用での誤切り替えリスクも上がるため、監視と判断基準の設計が重要になります。

ウォームスタンバイ構成

ウォームスタンバイ構成は、コールドスタンバイとホットスタンバイの中間に位置づけられる考え方です。待機系は最低限の稼働状態（例：OSは起動、アプリケーションは停止）で待たせ、切り替え時に必要なサービスを起動して引き継ぎます。

メリットは、コールドより切り替えが速く、ホットより運用コストを抑えやすい点です。一方で、切り替え時に起動が入るため、ホットほどの即時性は期待できません。停止許容時間とコストのバランスで検討される構成です。

ウォームの現実的な使いどころ

「数分〜十数分程度の停止は許容できるが、コールドほど長い停止は困る」といった中間要件で採用されやすい型です。運用負荷と復旧速度のバランスを取りたい場合の選択肢になります。

負荷分散構成

負荷分散構成は、複数のシステムを同時に稼働させ、リクエストを分散することで処理能力と可用性を高める構成です。単に「待機系を用意する」だけでなく、平常時から複数台で処理する点が特徴です。

メリットは、性能を上げやすいこと、そして一部のノードが故障しても残りで処理を継続できる可能性がある点です。

デメリットは、負荷分散の方式選定や設定が必要になることに加え、データの一貫性やセッション管理など、システム特性に応じた追加設計が必要になりやすい点です。運用面でも監視対象が増え、設計次第では複雑化します。

負荷分散で論点になりやすい設計要素

セッション管理：ステートフルな処理をどう扱うか（固定化が必要か、外部ストアへ逃がすか）
データ一貫性：複数台で処理しても整合性が崩れない設計になっているか
LB自体の冗長化：負荷分散装置やDNSが単一障害点になっていないか

負荷分散は「増やすほど強くなる」ように見えますが、単一障害点と整合性設計を同時に詰めないと、期待通りの可用性になりません。

DR構成とは

この章では、HAと混同されやすいDRの目的と、設計時に必要になる判断軸が分かります。

DR（Disaster Recovery）は災害復旧を意味し、地震・洪水・火災などの広域災害や拠点障害を想定した構成です。特徴は、同一拠点内の障害だけでなく、拠点自体が利用不能になる事態に備えて、システムを別の場所・地域に用意する点にあります（例：稼働系を東京、待機系を大阪に設置するなど）。

日本のように自然災害リスクが相対的に高い環境では、DR構成は事業継続の観点から重要な選択肢になり得ます。ただし、距離が離れるほど運用や同期、切り替え手順が難しくなることもあるため、要件に合わせた設計が必要です。

DRは「切り替え」より「戻し方」まで含めて設計する

DR設計で見落とされやすいのが、切り替え後に元の拠点へ戻す「フェールバック」です。DRサイトで一定期間稼働した場合、データ差分の取り込み、接続先の戻し、性能確保、運用体制の切り替えなど、現実的な作業が発生します。切り替えに成功しても、戻せなければ恒久運用になり、コストや運用が破綻することがあります。

DRは、切り替え手順だけでなく、戻し方まで含めた演習と手順整備が重要です。

HA構成の主目的は、機器故障やソフトウェア障害など「局所的な障害」に対して、ダウンタイムを最小限に抑えることです。待機系への切り替えや、複数ノードでの稼働によって、停止を短くし、サービス継続を狙います。

一方でDR構成は、データセンターや拠点全体が影響を受けるような「災害・広域障害」を想定します。地理的に離れた場所にシステムを用意し、一方が使えなくなっても別拠点でサービスを継続できるようにします。

整理すると、HAは「止めない／止まっても短くする」ための構成で、DRは「拠点レベルの喪失に備える」ための構成です。両者は目的が異なるため、どちらが上位というより、要件に応じて組み合わせて設計することが現実的です。