冗長化とは？サーバー障害対策の基本

冗長化とは、サーバーやネットワークなどの重要な構成要素を複数用意し、1つが故障してもサービス全体を止めにくくする設計です。

たとえばWebサーバーを1台だけで運用していると、その1台が故障した時点でサイトが停止します。 一方、同じ役割を持つサーバーを複数台用意し、障害時に別のサーバーへ切り替えられるようにしておけば、停止時間を短くできます。

ただし、サーバーを2台用意しただけで自動的に「高可用性」になるわけではありません。 ロードバランサー、データ同期、監視、フェイルオーバー、DNS、ストレージなど、どこに単一障害点が残っているかを確認する必要があります。

30秒でわかる結論

冗長化とは？

冗長化とは、システムを構成する重要な部品を複数用意し、1つが使えなくなっても別の部品で処理を続けられるようにする考え方です。

Google Cloudの現行設計指針でも、高可用性を高めるためには単一障害点を避け、重要コンポーネントを複数のマシン・ゾーン・リージョンへ複製・分散する考え方が示されています。

冗長化の目的は「障害をゼロにすること」ではない

冗長化しても、障害そのものを完全になくすことはできません。

重要なのは、1つの機器・サーバー・回線が壊れても、サービス全体が止まらないようにすることです。

単一障害点とは？

単一障害点は「Single Point of Failure（SPOF）」とも呼ばれ、その1か所が故障するとシステム全体が停止する部分です。

冗長化と高可用性の関係

高可用性（HA：High Availability）は、サービスを長時間止めずに利用できる状態を目指す設計です。

冗長化は、その高可用性を実現する代表的な方法の1つです。

冗長化だけでなく、監視、自動復旧、障害検知、フェイルオーバー、運用手順なども必要です。

冗長化する代表的な場所

対象	冗長化例
Webサーバー	複数台構成
データベース	プライマリ＋スタンバイ
ストレージ	複製・RAID・複数ゾーン
ネットワーク	複数経路・複数回線
電源	二重化電源・UPS
拠点	複数ゾーン・複数リージョン

Webサーバーの冗長化

Webサーバーを複数台用意し、利用者からのアクセスを分散する構成です。

Aが故障したときにBへ通信を送れるようにすれば、1台障害による全停止を避けやすくなります。

ロードバランサーの役割

ロードバランサーは、複数のサーバーへアクセスを振り分ける仕組みです。

高可用性構成では、単純な負荷分散だけでなく、ヘルスチェックで障害サーバーを検知し、正常なサーバーへ通信を送る役割も持ちます。

Active/Standbyとは？

Active/Standbyは、通常は1系統だけ稼働し、もう1系統を待機させる方式です。

Active/Activeとは？

Active/Activeは、複数系統を通常時から同時に稼働させる方式です。

片方が故障した場合、残ったサーバーで処理を継続します。

方式	通常時	障害時
Active/Standby	片方だけ稼働	待機系へ切り替え
Active/Active	複数系統が稼働	残りで処理継続

フェイルオーバーとは？

フェイルオーバーとは、稼働中のサーバーやシステムに障害が起きたとき、待機系・別系統へ処理を切り替える動作です。

Google Cloud SQLの高可用性構成でも、プライマリとスタンバイを別ゾーンへ配置し、障害時にスタンバイを新しいプライマリへ切り替える仕組みが採用されています。

データベースの冗長化

Webサーバーだけ複数台にしても、データベースが1台だけなら、そのDBが故障した時点でWordPressやWebアプリが動かなくなる可能性があります。

障害時にスタンバイを昇格させることで、停止時間を短くします。

ストレージの冗長化

ディスクやストレージも故障するため、データを複数のディスク・設備へ保存する冗長化があります。

Google Cloud Storageのリージョナル構成では、データを同一リージョン内の複数ゾーンへ冗長保存し、1つのゾーン障害へ耐えられる設計が採用されています。

RAIDも冗長化？

はい。RAIDの一部方式は、複数ディスクを使ってディスク障害への耐性を高める冗長化の一種です。

ただし、RAIDはサーバー全体・ネットワーク・データセンター障害まで防ぐ仕組みではありません。

ネットワークの冗長化

サーバーが正常でも、ネットワーク経路が1本しかなければ、その回線・ルーター・スイッチの障害で外部からアクセスできなくなる場合があります。

重要システムでは、サーバー台数だけでなく通信経路まで含めて単一障害点を確認します。

電源の冗長化

データセンターでは、電源障害を想定した冗長化も行われます。

レンタルサーバー利用者が自分でこれらを設置することは通常ありません。 設備側の冗長化はサービス提供会社が管理します。

ゾーン分散とは？

クラウドでは、同じリージョン内でも別のゾーンへサーバーを分散する方法があります。

1つのゾーン全体に障害が起きても、別ゾーンでサービスを継続できるようにします。

複数リージョンへの冗長化

さらに高い可用性が必要な場合は、地域的に離れた複数リージョンへシステムを配置します。

リージョン全体の大規模障害や災害を想定する場合に有効です。

構成	主な障害対策
同一サーバー内	ディスク障害など
複数サーバー	サーバー障害
複数ゾーン	ゾーン障害
複数リージョン	地域規模の障害

ただし、広域冗長化ほどコスト・設計・運用の難易度も高くなります。

冗長化とバックアップの違い

冗長化とバックアップは目的が違います。

項目	冗長化	バックアップ
主な目的	止まりにくくする	過去の状態へ戻す
サーバー故障	有効	復旧に利用
誤削除	削除も同期する場合あり	復元可能
ランサムウェア	被害が複製される場合あり	独立バックアップが重要

冗長化とレプリケーションの違い

レプリケーションは、データを別のサーバー・ストレージへ複製する仕組みです。

冗長化を実現する手段の1つとして使われます。

冗長化とロードバランサーの違い

ロードバランサーは複数サーバーへアクセスを振り分ける仕組みです。

一方、冗長化はサーバー、ネットワーク、データベース、ストレージなどを含むもっと広い設計概念です。

冗長化とスケールアウトは同じ？

同じではありませんが、構成が似ることがあります。

項目	目的
冗長化	障害時も止まりにくくする
スケールアウト	サーバー台数を増やして処理能力を上げる

Webサーバーを2台に増やすことで、負荷分散と冗長化を同時に実現できる場合もあります。

サーバーを2台にするだけでは不十分

2台のWebサーバーがあっても、共通のデータベースが1台だけなら、そのDBが単一障害点です。

DBが止まれば、Webサーバーが2台とも正常でもサービスは停止します。

冗長化しても停止する原因

「同じサーバーを複数台並べれば絶対に止まらない」というものではありません。

冗長化には監視が必要

障害を検知できなければ、正常な系統へ切り替えられません。

自動フェイルオーバーだけに頼らず、障害通知と復旧手順も用意します。

フェイルオーバーテストも必要

冗長構成を作っても、実際に切り替わるかテストしていなければ本番障害時に動かない可能性があります。

Google Cloudの信頼性設計でも、障害をシミュレーションしてレプリケーションやフェイルオーバー戦略が機能するか定期的に検証することが推奨されています。

RTO・RPOと冗長化の関係

どこまで冗長化するかは、停止時間とデータ損失をどこまで許容できるかで決めます。

指標	意味
RTO	何時間・何分で復旧したいか
RPO	どこまでのデータ損失を許容するか

冗長化すると費用は高くなる？

一般に高くなります。

サーバーを複数台用意するだけでなく、ロードバランサー、監視、複製ストレージ、別ゾーン・別リージョンなど追加リソースが必要になるためです。

ECや予約システムのように停止が売上へ直結するなら、冗長化コストをかける価値が高くなります。

どんなサイトで冗長化が必要？

共用レンタルサーバー利用者は自分で冗長化する？

通常は、自分でWebサーバーを2台構成したりロードバランサーを設置したりする必要はありません。

共用レンタルサーバーでは、物理サーバー、ストレージ、ネットワーク、電源などの基盤部分を提供会社が管理します。

VPSでは自分で設計する場面が増える

VPSではroot権限を持つため、OS・アプリケーションだけでなく、障害時の復旧設計も利用者側で考える必要があります。

冗長化されたサービスを選ぶときの確認項目

確認項目	見るポイント
サーバー冗長化	障害時に別系統へ移行できるか
ストレージ	複数ディスク・複数設備へ保存されるか
ネットワーク	複数経路・回線があるか
データセンター	電源・回線の冗長性
監視	24時間監視・自動検知
バックアップ	冗長化とは別に復元できるか

冗長化でよくある誤解

冗長化を考える手順

教科書判定

FAQ

まとめ