週3EC2 / EBS / ELB / Auto Scaling

2026-08-16（日）EC2, EBS, ELB, Auto Scaling

この記事の目次
  1. 予習ポイント
  2. 図解イメージ（言葉で説明）
  3. 視聴後に自分でチェックしたい項目

1. 【予習ポイント】

  • ELB（ロードバランサー）の3つの種類と決定的な使い分け [p.67]:
    • ALB (Application Load Balancer): HTTP/HTTPS (L7レイヤー) の通信制御に特化した最も主流なバランサー [p.67]。URLパスに応じた振り分け（例：/images 宛ては画像専用サーバーへ転送等）や、WebSocket/HTTP2に対応します [p.67]。
    • NLB (Network Load Balancer): TCP/UDP (L4レイヤー) に特化し、ミリ秒以下の極めて低い遅延で秒間数百万の突発的な超高負荷リクエストを処理可能 [p.67]。ロードバランサー自体が「固定のIPアドレス」を保持できる唯一のバランサーです [p.67]。
    • CLB (Classic Load Balancer): 旧世代のバランサー。試験対策、および新規のシステム設計ではほぼ考慮から除外されます [p.67]。
  • ヘルスチェックによる自動切り離しと「セルフヒーリング（自己修復）」 [p.68-69]:
    • ELBは、配下のターゲット（EC2インスタンス）に対し、定期的（デフォルトで30秒など）に「体調不良がないか（生存しているか）」を確認する通信を送信します [p.68]。応答を返さない「異常（Unhealthy）」と判断されたインスタンスを自動で配分ルートから隔離し、回復が確認されたら自動で紐付けを戻す、インフラの無人巡回システムです [p.68, p.69]。
  • クラウド高可用設計の絶対原則①：「ステートレス設計（無状態化）」 [p.69-70]:
    • なぜそうするのか: EC2インスタンスの内部にログインセッション情報やアップロードされたファイルを直接保存（保持）すると、次に別インスタンスにアクセスが分散された際にデータが参照できず、エラーを招きます [p.69]。また、Auto ScalingによってEC2が自動削減・削除された際、データごと完全に消滅してしまいます [p.69]。
    • 設計の解決策: セッション情報や永続的なファイルは、EC2インスタンスの「外」にある共有オブジェクトストレージ（Amazon S3）やフルマネージドデータベース（Amazon RDS / DynamoDB）に完全に追い出し、EC2を「いつでも破棄・追加が可能な状態」にしておきます [p.69, p.70]。
  • クラウド高可用設計の絶対原則②：「マルチAZ配置（複数データセンターへの分散）」 [p.70]:
    • バランサー配下のEC2インスタンスは、必ず異なるアベイラビリティゾーン（例：AZ-aとAZ-c）に分散配置します [p.27, p.70]。もし単一のデータセンター（単一AZ）だけに全てのEC2を配置した場合、そのAZに落雷、大規模停電、災害等の物理的な障害が発生した時点でシステムが全停止（単一障害点: SPOF）してしまうためです [p.27, p.66, p.70]。

2. 【図解イメージ（言葉で説明）】

「大人気レストランの超優秀な受付マネージャーと、離れた2つのキッチンの連携劇」

インターネットを通じて訪れるお客様（ユーザー）が、どのような物理インフラ構造を通って安全にWebコンテンツ（料理）を受け取るか、身近なレストランの光景に例えて説明します。

  1. レストランの玄関（インターネット ⇔ パブリックALB） [p.38, p.67]: レストランの玄関口である「パブリックサブネット」に、超優秀な総合受付マネージャーである 「 ALB 」 が立っています [p.38, p.67]。マネージャーは公道（インターネット）から入ってきたお客様（リクエスト）の伝票を瞬時にスキャンし、ピザの注文なのかデザートの注文なのか（URLパス）によって、適切な調理チームへとスマートに案内します [p.67]。
  2. 調理指示ルート ＝ ターゲットグループ [p.67]: マネージャーが「ピザ注文担当チーム」などのグループごとに仕分けるためのオーダー伝票の束が 「 ターゲットグループ 」 です [p.67]。このグループの中に、実際に料理を作る複数のシェフ 「 EC2インスタンス 」 が登録されています [p.67, p.68]。
  3. 分散された調理場（プライベートEC2 ⇔ マルチAZ分散） [p.38, p.70]: この店では、ガス爆発や落雷（データセンター物理障害）が起きても料理の提供を止めないよう、キッチン（調理用サブネット）をわざと「Aビル（AZ-1a）」と「Cビル（AZ-1c）」という、異なる電源系統の別棟ビルに完全に分散させて稼働させています [p.27, p.70]。それぞれのビルに全く同じピザが焼けるシェフ（EC2）が配置されています [p.70]。
  4. 共有の巨大倉庫 ＝ ステートレス設計（S3 / RDS） [p.69-70]: 調理を安全に行うため、シェフたちの手元には食材や秘伝のレシピ、現在のお客様の進行メモを一切置きません [p.69]。それらはすべて、AビルとCビルの両方から瞬時にアクセスできる「中央の巨大共有倉庫 （S3 や データベース） 」に一元保管されています [p.69, p.70]。これによって、Aビルのシェフが自動交代（使い捨て削除）になっても、Cビルのシェフが即座に共有倉庫からレシピを引き継ぎ、何食わぬ顔でお客様に料理（Webコンテンツ）を出し続けられます [p.69, p.70]。
  5. マネージャーによるインカム確認（ヘルスチェック） [p.68]: 受付マネージャー（ALB）は、各キッチンのシェフに対して「動ける状態ですか？」とインカムで30秒ごとに生存確認をしています [p.68]。もしAビルのシェフがフライパンの火傷で倒れた（サーバーフリーズ）場合、マネージャーは即座にそのシェフへのオーダー提供をストップし（Unhealthy判定での切り離し）、すべてのお客様をCビルの正常なシェフへ転送してレストラン全体の営業停止を防ぎます [p.68]。

3. 【視聴後に自分でチェックしたい項目】

  • ⬜︎ チェック1: ターゲットグループに登録したEC2のヘルスチェックステータスが「Healthy」になったか？ [p.68]
    • もし「Unhealthy」のままである場合、EC2インスタンスに適用している「セキュリティグループ（SG）」が、「ALBからのインバウンド通信（ポート80など）」を正しく許可（Allow）しているか、セキュリティグループのステートフルな特性を意識して確認できたか？ [p.36, p.68]
  • ⬜︎ チェック2: ヘルスチェックの頻度や切り離しの判定基準（しきい値）はどこで調整できるか？ [p.68]
    • ハンズオンの設定画面で、ヘルスチェックの「周期（例：30秒）」や、「何回連続で応答がなければ異常とみなして切り離すか（非正常のしきい値：例：2回）」を設定した項目（パラメーター定義）を視覚的に特定できたか？ [p.68]
  • ⬜︎ チェック3: なぜEC2インスタンスを「プライベートサブネット」に隠したまま、インターネットのユーザーと通信させられるのか？ [p.38, p.67]
    • ALB自身がインターネットと繋がる「パブリックサブネット」に立ち、EC2は外部からハッキング不可能な「プライベートサブネット」に隠れていることで、直接アクセスを防御しながらも安全にALBが中継する「多層防御ネットワーク」のつながりをイメージできたか？ [p.38, p.67]
  • ⬜︎ チェック4: EC2上のWebサービス（ApacheやNginx）のプロセスを意図的に手動停止した際、ターゲットグループの画面上でどのようにステータスが「Unhealthy」に変化するか確認できたか？ [p.68]

📊 本日の実習は、AWS設計の王道である「スケーラビリティと耐障害性の基本構成」を実体験する極めて重要なフェーズです！