EC2 を1台立てて動かせた。次に「これが壊れたらどうなるか」と考えると、ELB や Auto Scaling の名前は浮かぶのに、何から組めばいいのかが見えない。台数を増やせば冗長になる、と考えたくなりますが、データやログイン状態が1台の中にあると、増やしても止まるときは止まります。この記事は、構成を「何が1つしかないか」から見直し、5段の順番で描く方法を説明します。
この記事の結論
- 設計は「何が1つしかないか」を探すことから始めます。1台、1つの AZ、サーバーの中だけにあるデータが典型です。
- 1台の故障の影響を小さくするには、大きい1台に替える（スケールアップ）より、小さい複数台に分ける（スケールアウト）が基本です。
- 台数を増やす前に、データ・セッション・ファイルを EBS 以外（S3・データベース・外部ストア）へ出し、各台を使い捨てにできる形にします。
- そのうえで複数 AZ に置き、ELB が正常な台だけに振り、Auto Scaling グループが異常な台を入れ替えます。
- 購入オプションは「常時いる分」と「増減する分」で分けて考えます。
EC2 1台の構成は、どこが単一障害点なのか
単一障害点とは、そこが止まるとシステム全体が止まる「1つしかない部品」のことです。EC2 を1台だけ立てた構成には、少なくとも3つあります。
- 1台しかない: そのインスタンスが故障すれば、受け付ける台が無くなります。
- 1つの AZ にしかない: AZ（アベイラビリティーゾーン）は障害の範囲を分けるための単位です。その AZ が使えなくなると、中の台はまとめて影響を受けます。
- データがサーバーの中にしかない: インスタンスの中にだけあるデータやセッションは、その台を失うと一緒に失われます。台を作り直しても戻りません。
3つは別の問題です。台数を増やしても解けるのは1つ目だけで、2つ目は置き場所、3つ目はデータの持ち方の問題です。
SINGLE POINT OF FAILURE1つしかないものを探す
止まる原因は1台・1つの AZ・台の中のデータ
1台構成
どれか1つ止まれば全部止まる
- 台が1台だけ
- AZ が1つだけ
- データが台の中だけ
分散構成
1つ止まっても続けられる
- 同じ AMI の複数台
- 複数の AZ に配置
- データは台の外（S3・DB など）
CHECK 1ここまでの確認
ログイン状態を1台のメモリだけに持つ構成で、台数を2台に増やすと何が起きうる?
答えと解説
答え: 2. リクエストが別の台に届くと、その台には状態が無く、ログインが切れたように見える
台数を増やしても、状態が各台の中にあれば台ごとに持っている中身が違います。「単一障害点」の章の「状態を外へ出す」を読み直してください。
スケールアップとスケールアウトはどう選ぶのか
処理能力を上げる方向は2つあります。1台を強くするのがスケールアップ（垂直）、台数を増やすのがスケールアウト（水平）です。
| 観点 | スケールアップ | スケールアウト |
|---|---|---|
| 1台が壊れたときの影響 | 全部を1台に載せているので、全部止まる | 残りの台で続けられる |
| 上限 | 1台の最大サイズで頭打ち | 台を足せる限り伸ばせる |
| 止めずに変えられるか | サイズ変更には停止が要る | 台を足し引きするだけで済む |
| アプリへの要求 | ほぼ無い | 台が入れ替わってもよい作りが要る |
スケールアウトの代償は、最後の行です。アプリが「この台が私の状態を全部知っている」前提だと、台を増やしても動きません。分散できない処理や、アプリをすぐに直せない場面では、スケールアップが現実的な選択になります。ただし上限と停止が必要な点は覚えておきます。
AWS の Well-Architected フレームワークの信頼性の柱も、設計原則に「水平にスケールして、システム全体の可用性を高める」を挙げています。1つの大きな資源を小さい複数の資源に置き換えると、1つの故障の影響が小さくなる、という考え方です。
UP OR OUT強くするか、分けるか
故障の影響を小さくするなら、小さい複数台に分ける
スケールアップ
- 故障すると全部止まる
- 1台の最大サイズで頭打ち
- サイズ変更に停止が要る
スケールアウト
- 故障しても残りが続ける
- 台を足せる限り伸ばせる
- 台を足し引きするだけ
支点は「台が入れ替わってもアプリが動くか」
CHECK 2ここまでの確認
1台が壊れたときの影響をなるべく小さくしたい。基本の方向はどちら?
答えと解説
答え: 2. 小さい台を複数に分ける（スケールアウト）
台数が多いほど、1台が止まったときに失う割合が小さくなります。「スケールアップとスケールアウト」の章の表を読み直してください。
台数を増やす前に何を1台の外へ出すのか
スケールアウトの前提は、各台が使い捨てにできることです。どの台がいつ消えても、同じ構成の新しい台に替えて続けられる状態を、ステートレス（状態を持たない）な設計と呼びます。そのために、台の中にあるものを次のように外へ出します。
| 今は台の中にあるもの | 出す先の考え方 |
|---|---|
| アップロードされたファイル | S3 のようなオブジェクトストレージ |
| 業務データ | データベース（台とは別に動かすもの） |
| ログイン状態（セッション） | 台の外のストア、またはクライアント側に持たせる |
| ログ | 台の外へ転送して集める |
| 設定・OS・アプリの中身 | AMI や起動の仕組みに入れておく |
最後の行が、「同じ台を何度でも作れる」ことを支えます。AMI は、OS・設定・ソフトウェアをまとめた起動用のテンプレートで、これで起動すれば同じ構成の台が何台でも作れます。台の外へ出せないものが残っていると、その台は使い捨てにできません。
なお、EBS ボリュームは台と別に存在しますが、基本は特定の AZ の中にあり、台に付けて使うものです。ここでいう「外へ出す」は、台や AZ が替わっても読めるところへ置くという意味です。
CHECK 3ここまでの確認
Auto Scaling グループに複数の AZ を指定していて、そのうち1つの AZ が使えなくなった。グループは何をする?
答えと解説
答え: 2. 使える他の AZ でインスタンスを起動して補う
複数 AZ を指定していれば、使える AZ 側で起動して台数を保ちます。1つの AZ しか指定していないとこの動きにならない点も、「複数 AZ に並べる」の章で確認してください。
複数 AZ に並べて、ELB と Auto Scaling グループで守るとは
状態を外へ出せたら、同じ AMI から作った台を複数の AZ に並べます。そのうえで2つの仕組みを前に置きます。
- ELB（Elastic Load Balancing）: 受信したリクエストを複数の台に分散します。ヘルスチェックで応答しない台を見つけると、その台には振りません。
- Auto Scaling グループ: 台数を決めた範囲に保ちます。AWS のドキュメントでは、異常なインスタンスを検知して入れ替えること、複数の AZ にまたがって台を分散し、1つの AZ が使えなくなったら他の AZ で起動して補うことが利点として説明されています。ELB を前に置く構成もそこに書かれています。
役割分担は、ELB が「いま届け先として適切な台を選ぶ」、Auto Scaling グループが「台そのものを入れ替えて数を保つ」です。ELB だけでは壊れた台が戻らず、Auto Scaling グループだけでは入れ替わるまでの間、壊れた台にリクエストが届き続けます。両方を置くと、異常な台は振り分けから外され、数が足りなければ補われます。
BUILD IT UP壊れにくさを積む順番
下の段が済んでから、上の段を積む
台が1台壊れる
- ⑤ Auto Scaling グループ — 異常な台を入れ替える
- ④ ELB — 正常な台だけに振る
- ③ 複数 AZ — 場所を分ける
- ② 同じ AMI で複数台 — 台を増やす
- ① 状態を外へ — 台を使い捨てにする
AZ が1つ使えない
- ⑤ Auto Scaling グループ — 異常な台を入れ替える
- ④ ELB — 正常な台だけに振る
- ③ 複数 AZ — 場所を分ける
- ② 同じ AMI で複数台 — 台を増やす
- ① 状態を外へ — 台を使い捨てにする
効いている段土台の段
台数の下限はどう決めるのか
「2台あれば足りる」とは限りません。1台が落ちたとき、残りの台が全体の負荷を受けきれるかで決めます。たとえば2つの AZ に1台ずつ置くと、1つの AZ を失った時点で残りは1台です。その1台でふだんの負荷を受けられないなら、AZ の数だけでなく1つ失ったあとの台数で見積もります。
需要の変動には、Auto Scaling グループが台数を増減して合わせます。毎日ほぼ同じ時間に来る山のように予測できるものには、スケジュールで先に容量を上げる備え方もあります。細かい設定は auto-scaling-toha で扱います。
CHECK 4ここまでの確認
応答しなくなった台にリクエストを送らないようにするのは、主にどの仕組み?
答えと解説
答え: 1. ELB のヘルスチェックによる振り分けの除外
ELB は正常な台だけに振り、Auto Scaling グループは異常な台を入れ替えます。役割が別である点は「複数 AZ に並べて、守る」の章を読み直してください。
常時の台数と増減する台数は、購入オプションをどう分けるのか
構成が決まると、常時いてほしい台と、需要に応じて増減する台が分かれます。購入オプションは、この区別で考えます。
- 常時いる台: 使い続ける量が読めるので、約束をして安くする方法が選べます。
- 増減する台: 約束しない払い方のほうが無駄が出にくくなります。
どの払い方がどんな約束と引き換えかは、
READ ALSO — 未経験向け・段1 入口
EC2 のインスタンスタイプと購入オプションの仕組み｜名前の読み方と払い方
にまとめてあります。ここでは「構成の形が決まってから、払い方を分ける」という順番だけ押さえてください。
設計を決めるときのチェックの順番は
最後に、設計を見直すときの順番です。
- 単一障害点を洗い出す: 1台・1つの AZ・台の中のデータの3つを探します。
- 外へ出す: ファイル・データ・セッション・ログ・設定を台の外へ。
- 並べる: 同じ AMI から複数台、複数 AZ に。
- 守る: ELB で分散し、Auto Scaling グループで入れ替える。
- 台数を見積もる: 1つ失ったあとの台数で足りるかを見る。
順番を守る理由は、前の段が済んでいないと後の段が効かないからです。状態が台の中にあれば、ELB で振っても台ごとに中身が違い、Auto Scaling グループが入れ替えれば中身が消えます。
Cloudory 執筆者（AWS 認定 全冠）
構成図を描くときは、箱を増やす前に「この箱が消えたら何が失われるか」を1つずつ書き出すと、足りない段が見つかります。ここで挙げた順番は、公式ドキュメントと Well-Architected の考え方を整理したものです。
まとめ
- 単一障害点は、1台・1つの AZ・台の中のデータの3つ。台数を増やして解けるのは1つ目だけです。
- 故障の影響を小さくするにはスケールアウトが基本。ただしアプリが状態を台の外に持てることが前提です。
- 順番は、状態を外へ、同じ AMI で複数台、複数 AZ、ELB で分散、Auto Scaling グループで入れ替え。
- 次は、Auto Scaling グループの容量とスケーリングを扱う
READ ALSO — 学習中向け・段2 構成
Amazon EC2 Auto Scaling とは何か｜台数を自動で増減し、壊れた1台を入れ替える仕組み
へ進んでください。
参照ソース
- Amazon EC2 Auto Scaling ユーザーガイド「Amazon EC2 Auto Scaling の利点」 — 異常なインスタンスの検知と入れ替え、複数 AZ への分散と他 AZ での補完、ELB を前に置く構成の根拠
- AWS Well-Architected 信頼性の柱「設計原則」 — 水平にスケールして可用性を上げる、障害から自動復旧する、という原則の根拠
