冗長構成と可用性設計の基礎｜インフラエンジニア向け実践入門

※本記事にはプロモーション（広告）を含みます。

冗長構成を設計する際は、まず各コンポーネントの単一障害点(SPOF)を洗い出し、業務ごとに許容できる停止時間(RTO)とデータ損失許容量(RPO)を数値で定義してください。数値目標がないまま「とにかく二重化する」設計を進めると、コストだけが膨らみ切り替え時間も検証できない構成になります。本記事では稼働率の考え方から実際の冗長パターン、クラウド環境での実装、運用時に見落とされがちな検証項目まで順に解説します。

可用性設計の基本指標

冗長構成の議論を始める前に、可用性を測る指標を共有言語として押さえておきます。指標がなければ、設計者ごとに「十分な冗長化」の基準がずれてしまい、レビューが噛み合いません。

稼働率とSLAの関係

稼働率は年間の総稼働時間に対して実際にサービスが稼働していた時間の割合で表します。目安として99.9%(いわゆる「スリーナイン」)は年間換算で約8.76時間の停止を許容する水準、99.99%は約52.6分まで停止時間を絞る水準です。クラウド事業者が公開するSLA文書には、この稼働率と未達時の返金条件が明記されているため、契約前に必ず一次情報を確認してください。SLA数値はサービス個別に異なり、マネージドデータベースとオブジェクトストレージでは保証水準が違う場合もあります。

MTBFとMTTRの目安

MTBF(平均故障間隔)は障害が発生してから次の障害までの平均時間、MTTR(平均修復時間)は障害発生から復旧までにかかる平均時間を指します。可用性は概算で「MTBF ÷ (MTBF + MTTR)」で表せるため、故障そのものをゼロに近づける努力に加えて、MTTRを短縮する設計、つまり自動フェイルオーバーや監視の即時通知が可用性向上に直結します。冗長構成はMTBFを底上げする手段であると同時に、MTTR短縮の仕組みとセットで初めて効果を発揮します。

冗長構成の主要パターン

冗長構成にはいくつかの型があり、それぞれ切り替え速度・コスト・実装の複雑さが異なります。業務要件と予算に応じて選択してください。

アクティブ-スタンバイ型

通常時は1台(または1系統)のみが処理を受け持ち、待機系はヘルスチェックの結果を監視しながら障害発生時に昇格します。Keepalived や Pacemaker といったOSSクラスタリングツール、あるいはロードバランサのフェイルオーバー機能で実装するケースが一般的です。待機系は普段リソースを消費しないためコストを抑えやすい一方、切り替え時にコネクションが一度切断される、あるいはキャッシュが空の状態から再開するといった影響が出ます。

アクティブ-アクティブ型

複数系統が同時に処理を受け持ち、片方が停止しても残りの系統がトラフィックを吸収し続けます。HAProxyやAWS Elastic Load Balancingのようなロードバランサでトラフィックを分散し、バックエンドは状態を共有するかステートレスに設計します。切り替え時間をほぼゼロに近づけられる代わりに、データの整合性設計とセッション管理の複雑さが増します。

N+1構成の考え方

必要な処理能力をNとしたとき、Nに対して1台分(または1系統分)の余剰を持たせる設計です。3台で処理していたワークロードなら4台構成にしておき、1台が停止しても残り3台で通常運用を続けられる状態を保ちます。負荷が高いシステムではN+2以上を選ぶ場合もありますが、余剰を増やすほど固定コストも増えるため、過去のトラフィックのピーク値を基に余剰台数を決めます。

構成パターン	切り替え時間の目安	コスト傾向	主な用途
アクティブ-スタンバイ型	数秒〜数十秒	低〜中(待機系は低稼働)	データベース、認証基盤
アクティブ-アクティブ型	ほぼ即時	中〜高(常時稼働台数が多い)	Webサーバー、API層
N+1構成	ほぼ即時(自動振替の場合)	中(余剰分のみ追加)	アプリケーションサーバー群

単一障害点の排除

冗長構成を組んでも、ネットワークやストレージ、電源といった下位レイヤーに単一障害点が残っていれば、上位の冗長化は意味を成しません。層ごとに確認していきます。

ネットワーク層の対策

スイッチやルーターを二重化する場合、単に台数を増やすだけでなく、経路自体が同じ電源系統や同じラックに集中していないかを確認します。VRRP(Virtual Router Redundancy Protocol)やHSRPのようなプロトコルでデフォルトゲートウェイを冗長化し、上位回線もキャリアの異なる複数回線で構成すると、片方のキャリア障害時にも通信を維持できます。ネットワーク機器のファームウェアバージョンによって対応プロトコルや挙動が異なるため、設定変更前には必ずベンダーの公式ドキュメントで対象バージョンの仕様を確認してください。

ストレージ層の対策

RAID構成はディスク単体の故障に対する冗長化であり、RAID5やRAID6は複数ディスクの同時障害にも一定まで耐えられますが、コントローラー自体や筐体全体の障害には別途対策が必要です。レプリケーションによって別筐体・別データセンターにデータを複製する構成を組み合わせ、非同期レプリケーションを使う場合はRPO(データ損失許容時間)がゼロにならない点を業務側と事前にすり合わせておきます。

電源とDCの冗長化

UPS(無停電電源装置)と自家発電設備の組み合わせは、瞬断や短時間の停電に対応しますが、長時間の停電や設備故障にはデータセンター自体の冗長化、つまり複数拠点への分散が必要になります。オンプレミス環境で複数拠点を持つことが難しい場合、クラウドのリージョン・アベイラビリティゾーンを活用する選択肢が現実的です。物理的な単一障害点は目視では気づきにくいため、ラック配置図や電源系統図を定期的に棚卸しする作業が有効です。

クラウドの可用性設計

クラウド環境では物理層の冗長化を事業者側が担うため、利用者側はサービスの機能を正しく使いこなす設計に注力できます。

マルチAZ構成の実践

AWSやGoogle Cloud、Microsoft Azureは、いずれも1つのリージョン内に複数のアベイラビリティゾーン(独立した電源・ネットワークを持つデータセンター群)を提供しています。データベースをマルチAZ構成にすると、プライマリが稼働するAZに障害が起きた際、別AZのレプリカへ自動的に昇格します。ただし自動フェイルオーバーの対象範囲やダウンタイムの目安はサービスごとに異なるため、公式ドキュメントに記載された仕様を必ず確認してから設計に反映してください。

自動フェイルオーバー

Kubernetesのliveness probe・readiness probeは、コンテナの死活状態をkubeletが監視し、異常なPodを自動で再起動またはトラフィックから除外する仕組みです。ロードバランサのヘルスチェックと組み合わせることで、障害発生から数秒〜数十秒でトラフィックを健全なノードへ振り替えられます。プローブの間隔やタイムアウト値を短く設定しすぎると、一時的な負荷スパイクを故障と誤検知してしまうため、実際のレスポンスタイム分布を見ながら閾値を調整します。

運用で見落としやすい点

設計段階では完璧に見える冗長構成も、運用フェーズでの検証を怠ると、実際の障害時に想定通り動かないケースが少なくありません。

フェイルオーバー訓練

Netflixが公開しているChaos Engineeringの考え方のように、意図的に障害を注入して切り替え動作を確認する手法があります。本番環境でいきなり実施するのはリスクが高いため、まずはステージング環境で待機系への昇格、ロードバランサからの切り離しといった一連の手順を実際に流し、手順書と実機の挙動にズレがないかを確認します。訓練を年1回程度に留めていると、その間に加わった構成変更が反映されないまま本番障害を迎える恐れがあります。

監視設計の落とし穴

冗長構成そのものを監視対象から外してしまうと、待機系が実は起動していなかった、レプリケーションが数時間前から停止していたといった状態に気づけません。待機系のプロセス死活、レプリケーション遅延、ヘルスチェックの応答時間を個別の監視項目として登録し、閾値を超えたらアラートが飛ぶよう設定します。監視ツール自体の設定変更やアップグレードは、必ず変更前後で通知が正しく届くかをテスト環境で確認したうえで本番に適用してください。セキュリティ設定を伴う監視エージェントの導入は、権限設計を含めて自己責任で実施する項目であることも念頭に置いておきます。

よくある質問

Q1. RTOとRPOはどう決めればよいですか

業務停止による損失額と、復旧にかかるコストを見比べて決めます。決済処理のように停止が直接収益に影響するシステムはRTOを数分単位、社内向けの参照系システムは数時間単位といった具合に、業務の重要度ごとに段階を分けるのが実務的です。

Q2. オンプレミスとクラウドどちらが冗長化しやすいですか

物理的な拠点分散を自前で用意する手間を考えると、クラウドの方が短期間でマルチAZ・マルチリージョン構成を組みやすい傾向があります。一方でオンプレミスは既存のネットワーク構成や社内ポリシーとの親和性が高い場合もあり、要件次第で判断が分かれます。

Q3. RAIDがあればバックアップは不要ですか

不要ではありません。RAIDはディスク故障への耐性を高める仕組みであり、誤削除やランサムウェアによるデータ破損には対応できません。世代管理されたバックアップを別途、可能であれば別ネットワーク・別媒体で保持する設計が必要です。

Q4. アクティブ-アクティブ型は必ず優れていますか

切り替え時間の短さでは優れていますが、複数系統間でのデータ整合性設計やセッション共有の実装が複雑になります。小規模なシステムではアクティブ-スタンバイ型の方が運用コストを抑えられる場合もあります。

Q5. SLA100%を目指すべきですか

目指す必要はありません。100%に近づけるほど冗長化のコストは指数的に増加するため、業務が許容できる停止時間を先に定義し、その水準を満たす構成を選ぶ方が投資対効果に優れます。

Q6. 冗長構成の設定はどこまで自分で判断してよいですか

ネットワーク機器やクラウドサービスのバージョンによって挙動や設定項目が変わるため、最終的な設定値は必ず公式ドキュメントで対象バージョンの仕様を確認したうえで適用してください。セキュリティに関わる設定変更は、変更内容の記録と承認プロセスを経て自己責任で実施することが前提になります。

まとめ

冗長構成の設計は、稼働率やMTBF・MTTRといった指標を業務要件から逆算し、ネットワーク・ストレージ・電源という物理層から順にSPOFを潰していく作業です。アクティブ-スタンバイ型、アクティブ-アクティブ型、N+1構成のいずれを選ぶ場合も、切り替え時間とコストのバランスを業務側と共有したうえで決定してください。クラウド環境ではマルチAZ構成や自動フェイルオーバー機能を活用できますが、公式ドキュメントで仕様を確認する作業は欠かせません。設計を組んだ後は定期的なフェイルオーバー訓練と監視項目の見直しを続け、机上の冗長構成を実際に機能する構成へと育てていく姿勢が、長期的な可用性を支えます。

おすすめ: Amazon技術書｜インフラ・クラウド・ネットワーク

【編集・制作ポリシー】
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。編集ポリシーはこちら