本文へスキップ
BecomeCoder

AWS SAA（ソリューションアーキテクト）コース　·　第8章　回復性・高可用性の設計　·　レッスン44

高可用性の基本：単一障害点(SPOF)の排除

導入

「サーバーが1台落ちたらサイト全体が止まった」——これがSAAで最も嫌われる設計です。どこか1点が壊れただけでシステム全体が止まる箇所を 単一障害点（SPOF: Single Point of Failure） と呼びます。SAAの回復性問題の大半は、突き詰めると「このSPOFをどう消すか」です。

説明

SPOFを消す基本戦略は2つだけです。

  • 冗長化（Redundancy）：同じ役割のリソースを複数用意する
  • 複数AZへの分散：冗長化したリソースを、異なるアベイラビリティゾーンに置く

1台のEC2だけでWebサーバーを動かしていれば、そのインスタンスが落ちればサービス停止です。同じAZ内で2台に増やしても、AZごと（データセンターごと）の障害には耐えられません。必ず異なるAZに分散して冗長化するのがSAAの大原則です。

この原則をそのまま体現するのが、SAAで繰り返し登場する定番構成です。

flowchart TD
    U["利用者"] --> ELB["Elastic Load Balancing"]
    ELB --> A1["EC2（AZ-a）"]
    ELB --> A2["EC2（AZ-c）"]
    A1 --> ASG["Auto Scaling グループ<br/>（AZをまたいで台数を自動調整）"]
    A2 --> ASG
    A1 --> RDS["RDS Multi-AZ<br/>（プライマリ＋スタンバイ）"]
    A2 --> RDS
コンポーネント役割SPOFをどう消すか
Elastic Load Balancing（ELB）複数AZのインスタンスへリクエストを分散ELB自体もAWSがマネージドで冗長化・ヘルスチェックで不健全なインスタンスを自動除外
Auto Scaling需要と障害に応じてインスタンス数を自動調整落ちたインスタンスを自動で置き換え、複数AZに均等配置
RDS Multi-AZ別AZに同期レプリカ（スタンバイ）を待機させるプライマリ障害時に自動フェイルオーバー

この「ELB＋Auto Scaling（複数AZ）＋Multi-AZ RDS」の組み合わせが、SAAにおける高可用性アーキテクチャの標準形です。以降のレッスンは、この形にどう機能を足していくかという話になります。

具体例

あるサービスが「EC2が1台、その上でWebとMySQLが同居」という構成で運用されていました。SPOFを1つずつ潰していく過程を追いましょう。

  1. 今のSPOFはどこか … このEC2が1台きり。落ちれば全停止。DBも同じ1台に乗っているので、二重のSPOF。
  2. Webを冗長化 … EC2を2台にし、前段にELB。ただし2台を同じAZに置くと、AZ障害で共倒れ。→ AZ-aとAZ-cに分散。
  3. 自動復旧を足す … Auto Scalingグループで管理し、1台落ちたら自動で置き換え、負荷に応じて台数も増減。
  4. DBを切り離して冗長化 … MySQLをEC2から外し、RDS Multi-AZへ。プライマリが落ちても別AZのスタンバイに自動フェイルオーバー。

こうして「1台構成」が「ELB＋Auto Scaling（複数AZ）＋Multi-AZ RDS」の標準形に。SAAの回復性問題は、選択肢に1台構成・単一AZ構成が混ざっていたら、それがまず不正解。「冗長化されているか」「複数AZか」を最初に確認します。

読んでみよう

問題文に「単一障害点をなくしたい」「可用性を高めたい」とあれば、まず「冗長化されているか」「複数AZに分かれているか」をチェックしましょう。選択肢に1台構成・単一AZ構成が混ざっていたら、それはまず不正解です。

次のレッスンへ →