Single Point of Failureを特定・除去する

ゴール

保護する業務機能を確認
↓
業務経路上の必須要素を確認
↓
1つの障害で全体が止まる場所を特定
↓
単一障害点になっている要素そのものを修正
↓
独立した代替を用意
↓
正常な代替へ到達可能にする
↓
単一障害点を除去

ここでは、データレプリケーション方式、Auto Scaling、自己修復、DR戦略の詳細までは扱いません。

前提

障害ドメイン、マルチAZ、共通依存関係、フェイルオーバー成立性などの評価方法は既習として扱います。ここではそれらを再講義せず、特定済みの単一障害点をどこで、どのように除去するかへ進みます。

1. 単一障害点は「1台構成」だけではない

単一障害点になり得るのはサーバー1台だけではありません。唯一のデータベース、ネットワーク経路、出口経路、必須依存サービス、フェイルオーバー先、1つのAZだけに存在する必須コンポーネントなども対象です。

重要なのは個数ではなく、その1つを失っただけで保護対象の業務が成立しなくなるかです。

2. 業務経路に沿って単一障害点を探す

利用者
↓
ロードバランサー
↓
アプリケーション
↓
認証
↓
注文データ
↓
決済

注文完了までの入口、処理、認証、データ、外部通信を確認します。例えばアプリケーションA停止後もBで継続できるならA単体は単一障害点ではありません。一方、唯一の認証サービス停止で両方が認証不能になるなら、修正対象はアプリケーション台数ではなく認証サービス側です。

3. 既習の障害ドメインを「追加先の判断」に使う

同じAZへ複数配置してもAZ単位の単一障害点は残ります。ここで重要なのは、この知識を使ってどこへ代替を追加するかを決めることです。

現在
AZ-Aに処理先が集中
↓
AZ-Aが単一障害点
↓
AZ-Aへさらに追加するのではなく
AZ-Bへ独立した処理先を追加

発見した単一障害点と同じ障害ドメインの中で数を増やすのではなく、その障害ドメインをまたいで代替を作ります。

4. 論理的な複数登録と独立した冗長性を区別する

ロードバランサーへターゲット1・2・3を登録していても、すべてが同じ1台のネットワークアプライアンスへ到達するなら、その1台の障害ですべて失われます。

登録数 3
≠
独立した実体 3

単一障害点を除去するには、別の実体＋独立した障害ドメインとして代替を用意します。

5. AZ単位の単一障害点は「別AZでも利用可能」にする

AZ-Aだけに存在する必須コンポーネントが単一障害点なら、AZ-Bだけでもその必須機能を利用できる状態へ修正します。

Application Load Balancer
↓
AZ-A アプリケーションA
AZ-A アプリケーションB

AZ-B ターゲットなし

この場合はロードバランサーを増やすのではなく、AZ-Bへ実処理可能なターゲットを追加します。

AZ-A利用不能
↓
AZ-Bの正常なターゲット
↓
注文処理継続

6. ロードバランサーがあっても入口が固定なら冗長性を利用できない

AZ-AとAZ-Bに正常なターゲットがありApplication Load Balancerも存在していても、利用者がアプリケーションAの固定IPへ直接接続していれば、A停止後もAへ接続し続けます。

代替を作るだけでなく、その代替を実際に利用する入口まで修正する必要があります。

7. 共通依存が単一障害点なら依存先そのものを修正する

AZ-A アプリケーションA ┐
                         ├─ 唯一の認証サービス
AZ-B アプリケーションB ┘

この場合、アプリケーションを2台から4台へ増やしても認証サービス障害ではすべて利用不能になります。

認証サービスが単一障害点
↓
認証側へ独立した代替を用意
↓
アプリケーションから代替認証経路を利用可能にする

DNS、設定配布、データアクセス、ネットワーク、外部API接続などでも、単一障害点として特定した場所と実際に変更する場所を一致させることが重要です。

8. 入口だけでなく出口側の単一障害点も除去する

利用者
↓
Application Load Balancer
↓
AZ-A アプリケーションA
AZ-B アプリケーションB
       ↓
唯一の外部接続経路
       ↓
決済サービス

入口とアプリケーションが冗長でも、業務完了に必要な出口が1つなら単一障害点は残ります。AZ-A障害でもAZ-Bから外部サービスへ到達できるよう、残存側から利用可能な独立した出口経路を用意します。

9. フェイルオーバー先は「存在する」だけでは不十分

プライマリとスタンバイが存在しても利用者がプライマリだけへ固定されていれば、障害時にスタンバイを利用できません。

障害発生
↓
正常な代替先を利用

フェイルオーバー機構そのものの詳細設計は再講義せず、用意した代替を実際に利用できる経路があるかを確認します。

10. 冗長性と障害分離をセットで使う

目標は、独立した代替＋別の障害ドメイン＋正常系への到達経路を成立させることです。

11. 修正では「単一障害点がどこか」を起点にする

ALB配下のアプリケーションがAZ-Aだけなら単一障害点はAZ-Aなので、AZ-Bへ処理可能なアプリケーションを追加します。一方、AZ-A / AZ-Bのアプリケーションが唯一の認証サービスへ依存しているなら、修正対象は認証サービス側です。

「何かを冗長化する」のではなく、「単一障害点になっている場所を冗長化する」と考えます。

12. 入口・処理・依存・出口を別々に確認する

利用者
↓
入口
↓
処理
↓
必須依存
↓
出口
↓
業務完了

入口・アプリケーション・DB・認証が冗長でも外部接続が単一なら、修正対象は外部接続です。逆に入口だけが単一なら入口を修正します。

既に冗長な層をさらに増やすのではなく、まだ単一になっている経路へ修正を集中することが重要です。

13. 単一障害点除去の判断フロー

既存アーキテクチャ
↓
重要業務の経路を確認
↓
どの1要素の障害で全体が止まる？
↓
単一障害点を特定
↓
単一障害点はどの障害ドメインに属する？
↓
同じ障害で失われない代替を作る
↓
正常な代替へ到達できる経路を作る
↓
次の単一障害点を確認

14. 混同ポイント

15. このページで扱わないこと

Auto Scalingのスケーリングポリシー、予測スケーリング、ターゲット追跡スケーリング、異常インスタンスの自動置換、データレプリケーション方式、同期 / 非同期レプリケーション、DR戦略、RTO / RPOによるDR方式比較、リージョン規模のDR再設計、サービスクォータ不足への対応は扱いません。

ここで完成させるのは、1つの障害だけで重要業務が停止する場所を特定し、その単一障害点自体へ独立した代替と利用可能な経路を追加することです。

まとめ

どこが単一障害点か特定
↓
その単一障害点を修正
↓
独立した代替を用意
↓
別障害ドメインへ分離
↓
正常な代替へ到達可能にする

Application Load Balancerやアプリケーションが冗長でも、共通認証、出口、入口、実体のどこかが1つなら業務全体には単一障害点が残ります。

最終的には、冗長性＋障害分離＋利用可能な代替経路を、単一障害点として特定した場所そのものに成立させます。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 3.4
• AWS Well-Architected フレームワーク — 信頼性の柱
• Elastic Load Balancing — Application Load BalancerのターゲットとAZ