LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

冗長化とは、システムを構成する部品を複数用意し、1つが故障しても残りの部品でサービスを続けられるようにすることです。Azure Well-Architected Frameworkは、冗長性を「ワークロードの構成要素の同一のインスタンスを複数実装すること」と定義しています。^*1 そこが止まると全体が止まる部品を単一障害点（SPOF）と呼び、電源からリージョンまでの層ごとにこれを見つけて複数にしていくのが、冗長化の設計の中身です。

本記事では、AWS・Azure・Google Cloudの設計指針、IPAの「非機能要求グレード」、NISTの指針をもとに、二重化の方式からつまずきやすい点までを整理します。災害時の復旧方式は「クラウドのDR構成」、目標復旧時間の決め方は「可用性・DR設計」で扱っています。

冗長化とは

Google Cloudの設計指針は、信頼性の水準を決めたら単一障害点を避けて設計するよう求めています。重要な構成要素は、複数のマシン、ゾーン、リージョンにわたって複製します。重要なデータベースを1つのリージョンだけに置けば、そこが止まったときに全体が止まります。^*2

IPAの非機能要求グレード2018は、可用性の耐障害性の項目で、サーバーやネットワーク機器、ストレージなどごとに冗長化の水準を選ぶ形です。冗長化の単位は2つに分かれます。機器は筐体を複数用意すること、コンポーネントは筐体を構成するディスク、電源、FAN、ネットワークカードなどの部品を複数用意することです。水準は、冗長化しない構成から、特定のサーバーだけ、全てのサーバーへと段階で示されます。^*3

二重化は、同じものを2つ用意する冗長化の形です。非機能要求グレードはディスクの冗長化について、単一箇所の障害であればサービスを続けられる単一冗長と、同時に複数の箇所が障害の状態になってもサービスを続けられる多重冗長を分けています。何台にするかは、同時にいくつの故障まで耐えたいかで決まります。

仕組み：二重化の2つの方式

アクティブ/アクティブは、複数のインスタンスを同時に動かし、それぞれが処理を受け持つ方式です。Azureの指針は、1つのインスタンスが故障すると、処理は正常なインスタンスへ自動で振り替えられると説明しています。その代わり費用と複雑さが増し、データの整合性の確保や全インスタンスへの更新の調整が必要になります。

アクティブ/スタンバイ（Azureの表記ではアクティブ/パッシブ）は、主系がすべての処理を受け持ち、待機系は主系の故障や保守のときだけ動き出す方式です。ウォームスペアは最小限の規模で負荷をかけずに動かしておき、切り替えた後に拡張します。コールドスペアは全負荷を処理できる規模で用意しますが、計算資源は止めておき、切り替える前に起動します。前者は復旧が速い代わりに費用が高く、後者はその逆です。^*1

AWSの指針は、同じリージョン内のアベイラビリティーゾーン（AZ）どうしは1桁ミリ秒の低遅延でつながり、ほとんどのワークロードでAZ間の同期レプリケーションができるため、AZをアクティブ/アクティブとアクティブ/スタンバイのどちらの構成でも使えるとしています。^*4 層ごとの選び方について、Azureの指針は、計算の層には状態を持たせないこと、データベースは障害のときに自動でフェイルオーバーするよう構成することを勧めています。

層ごとの冗長化

電源について、NISTのSP 800-34 Rev.1は、サーバーなどの重要な機器を二重電源にして2つを同時に使う構成を挙げています。ただし2つ目の電源が防ぐのはハードウェアの故障で、停電は防げません。停電に備えるのはUPSで、通常は30〜60分の一時的な電力を供給して、正常に停止する時間を確保します。高い可用性が要る場合は発電機も挙げています。^*5

ネットワークについて、非機能要求グレードは、回線の冗長化を、伝送路を物理的に複数用意し、一方の伝送路で障害が起きても他方で通信できる状態にすること、経路の冗長化を、経由するルータの順序を複数設定し、ある区間で障害が起きても他の経路で迂回できる状態にすることと説明しています。^*3 NISTは、冗長な回線が同じ経路を通らないこと、複数の通信事業者を使うなら建物の引き込み口を含めて設備を共有しないことを確かめるよう求めています。^*5

サーバーとデータの層について、AWSの指針は、本番を同じリージョンの少なくとも2つのAZで動かすことを勧めています。Amazon S3やAmazon Auroraは既定で複数のAZにデータを複製しますが、Amazon RDSやAmazon ElastiCacheはマルチAZを有効にする必要があります。マルチAZで要件を満たせるのに複数リージョンの構成を組むことは、避けたい例に挙げられています。^*4 ロードバランサ自体の冗長化は「ロードバランサとは」で解説しています。

バックアップとの違い

NISTのSP 800-34 Rev.1は、高可用性の仕組みはしっかりしたバックアップ戦略の代わりにならないとしています。システム上のデータの破損は高可用性の仕組みを通じて伝わり、システムを使えなくする場合があります。システム本体から切り離したバックアップが無ければ、復旧できないこともあります。^*5

誤ったテーブルの削除やバグによる一括更新も、レプリカへそのまま伝わります。Azureの指針は、リソースの誤削除を防ぐロックについて、バックアップやレプリケーション、アクセスの管理を補う補助的な備えであり、それらの置き換えではないと書いています。冗長化を組んでも、バックアップの取得と復元の手順は別に設計します。戻せるかどうかの確かめ方は「バックアップは本当に戻せるか」でまとめています。

具体例：稼働率を計算する

冗長化の効果は稼働率の計算で見積もれます。AWSの指針は、依存先が止まると自分も止まる強い依存では、全体の稼働率は各稼働率の積になるとしています。99.99%のシステムが99.99%の独立したシステム2つに依存すると、理論上は99.97%です。独立した冗長な部品を並べる場合は、1から各部品の故障率の積を引きます。99.9%の部品2つなら99.9999%になります。^*6 次のPythonのコードは、この2つの式で構成ごとの稼働率と年間の停止時間を計算します（Python 3.12.10で実行）。

# 稼働率の計算（部品どうしの故障は互いに独立と仮定）
def series(*a):    # 直列：どれか1つが止まると全体が止まる
    p = 1.0
    for x in a:
        p *= x
    return p

def parallel(*a):  # 並列：全部が同時に止まったときだけ止まる
    q = 1.0
    for x in a:
        q *= 1 - x
    return 1 - q

def show(name, a):
    print(f"{name}: {a * 100:.4f}%  年間停止 {(1 - a) * 8760:.2f}時間")

show("1台", 0.999)
show("2台並列", parallel(0.999, 0.999))
show("3つ直列", series(0.9999, 0.9999, 0.9999))
web = parallel(0.999, 0.999)
show("LB+Web2台+DB1台", series(0.9999, web, 0.999))
show("LB+Web2台+DB2台", series(0.9999, web, parallel(0.999, 0.999)))

1台: 99.9000%  年間停止 8.76時間
2台並列: 99.9999%  年間停止 0.01時間
3つ直列: 99.9700%  年間停止 2.63時間
LB+Web2台+DB1台: 99.8899%  年間停止 9.64時間
LB+Web2台+DB2台: 99.9898%  年間停止 0.89時間

部品の稼働率は説明のための仮の値で、1年は8,760時間としています。99.9%の1台は年8.76時間止まる計算で、非機能要求グレードの表とも一致します。^*3 2台を並列にすると年0.01時間、約30秒まで縮まります。

ロードバランサ（99.99%）の後ろにWebサーバーを2台並べても、データベースが1台（99.9%）のままなら全体は99.8899%で、サーバー1台だけの99.9%より低くなります。直列の部品のうち一番弱いものに全体が引きずられるからです。データベースも2台にすると99.9898%になり、残る停止の大半はロードバランサの分になります。冗長化は、一番弱い部品から順に手当てします。

この計算は、部品どうしの故障が独立していることを前提にしています。2台が同じ電源や同じスイッチにつながっていれば、並列の式は成り立ちません。切り替えにかかる時間も入っていません。稼働率をサービスの約束として契約に書く方法は「保守契約のSLA設計」で扱っています。

使いどころ

Azureの指針は、冗長性を増やすほど費用が増えること、同じワークロードの中でも処理の流れごとに求める信頼性が違うことを挙げ、構成を定期的に見直すよう勧めています。NISTも、高可用性の仕組みは費用が高く、停止を許容できないシステムに限って検討するものだとしています。

決める順番は、業務がどのくらいの時間なら止まってよいかが先で、層ごとの冗長化はその後です。数時間止まっても代わりの手段がある業務なら部品の冗長化とバックアップで足りる場合があり、受注や決済のように止まると売上に直結する業務では複数AZのアクティブ/アクティブまで検討します。非機能要求グレードが特定のサーバーだけを冗長化する水準を用意しているのも、範囲を絞る選び方があるからです。

つまずきやすい点

一つ目は、共通の依存先です。サーバーを2台にしても、同じ電源系統、同じスイッチ、同じDNS、同じ認証の基盤に頼っていれば、そこが単一障害点として残ります。冗長化した部品ごとに、その先の依存先までたどって確かめます。

二つ目は、余力の不足です。Azureの指針は、性能のために2台へ処理を分け、どちらも使用率60%で動いているときに1台が故障すると、残る1台は120%では動けないため処理しきれなくなるおそれがあると書いています。^*1 アクティブ/アクティブの台数は、1台が止まったときの負荷で決めます。

三つ目は、障害が起きてから資源を用意する設計です。AWSの指針は、AZの障害から回復するために別のAZで新しいインスタンスを起動しようとすると、正常時と障害時でふるまいが変わる二峰性の動作になるとしています。インスタンスは障害の前に2つ目のAZに用意しておくべきで、大規模な障害では残りのゾーンの空き資源に頼るため効果が落ちるとしています。この考え方を静的安定性と呼びます。^*7

四つ目は、切り替えの試験をしないことです。AWSの指針は、フェイルオーバーの設計を検証しないこと、早すぎる切り戻しを防ぐ待ち時間が無いことを避けたい例に挙げています。^*8 Google Cloudの指針も、避難訓練のように障害を定期的に模擬し、複製と切り替えの仕組みが働くかを確かめるよう勧めています。待機系は普段使われないため、設定のずれに気づきにくい部分です。計画的に障害を起こして確かめる方法は「カオスエンジニアリング」で紹介しています。

外部に委託するときに確認しておきたい点

インフラの設計や構築を外部に頼むときは、まず層ごとの単一障害点を構成図に書き出してもらいます。DNSや認証などの依存先まで含めて、どこが1つのまま残り、なぜ残すのかを説明してもらいます。

次に、稼働率の目標と、その計算の前提を確かめます。アクティブ/スタンバイなら、切り替えは自動か手動か、切り替えにどのくらいの時間がかかるか、待機系をどの規模で用意するかを決めておきます。

三つ目は、切り替えの試験の計画と結果の記録です。本番と同じ構成の環境で主系を止め、待機系が引き継げたかを残してもらいます。バックアップが冗長化とは別に設計されているかも確かめます。

まとめ：冗長化で確かめておきたい3つの点

冗長化を実務で設計するうえで、確かめておきたい点は3つに整理できます。第一に、層ごとに単一障害点を洗い出し、共通の依存先まで含めて1つのまま残る部分を把握すること。第二に、稼働率は直列の部品の積と並列の部品の故障率の積で見積もれるものの、部品どうしが独立しているという前提が崩れていないかを確かめること。第三に、冗長化は誤削除やデータの破損を防がないため、バックアップを別に持ち、切り替えの試験で待機系が動くことを確かめておくことです。

よくある質問

出典

1. *1　参考：Microsoft「Architecture strategies for designing for redundancy」（Azure Well-Architected Framework、Microsoft Learn）（https://learn.microsoft.com/en-us/azure/well-architected/reliability/redundancy）。出典：RE:05の定義（Redundancy）、アクティブ/アクティブとアクティブ/パッシブ（ウォームスペア・コールドスペア）、使用率60%の例、削除ロックの記述を参照（2026年10月確認）
2. *2　参考：Google「Build highly available systems through resource redundancy」（Google Cloud Well-Architected Framework、Cloud Architecture Center）（https://cloud.google.com/architecture/framework/reliability/build-highly-available-systems）。出典：単一障害点の回避、障害ドメインの特定と複製、フェイルオーバーの試験の記述を参照（2026年10月確認）
3. *3　参考：独立行政法人情報処理推進機構（IPA）「非機能要求グレード2018 システム基盤の非機能要求に関する項目一覧」（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html）。出典：A.1.5.1 稼働率、A.2.1〜A.2.5 耐障害性（冗長化〔機器〕〔コンポーネント〕〔ディスク〕、回線の冗長化、経路の冗長化）を参照（本体一括ダウンロードのZIP内の項目一覧PDF）（2026年10月確認）
4. *4　参考：Amazon Web Services「REL10-BP01 Deploy the workload to multiple locations」（AWS Well-Architected Framework 信頼性の柱）（https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_multiaz_region_system.html）。出典：少なくとも2つのAZでの運用、AZ間の同期レプリケーション、マルチAZを既定で行うサービスと有効化が必要なサービス、避けたい例を参照（2026年10月確認）
5. *5　参考：National Institute of Standards and Technology「SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems」（https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf）。出典：5.1.3 Protection of Resources（二重電源・UPS・発電機）、5.1.6 Use of High Availability (HA) Processes、5.3.2 Telecommunications Contingency Solutions（WANの冗長な回線と通信事業者）を参照（2026年10月確認）
6. *6　参考：Amazon Web Services「Availability」（AWS Well-Architected Framework 信頼性の柱）（https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html）。出典：Calculating availability with hard dependencies / with redundant components を参照（2026年10月確認）
7. *7　参考：Amazon Web Services「REL11-BP05 Use static stability to prevent bimodal behavior」（AWS Well-Architected Framework 信頼性の柱）（https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html）。出典：二峰性の動作と静的安定性の記述を参照（2026年10月確認）
8. *8　参考：Amazon Web Services「REL11-BP02 Fail over to healthy resources」（AWS Well-Architected Framework 信頼性の柱）（https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_failover2good.html）。出典：Common anti-patterns（フェイルオーバーの設計の試験・検証をしない、早すぎる切り戻しを防ぐ待ち時間が無い）を参照（2026年10月確認）

Tweet