MODULE 02 · 02
構成が変わると、 何が解決する？
1台の構成から、台数だけを増やした構成、入口と制御を加えた構成へ。変わった場所と、その理由を見比べます。
読み方
01 → 02 → 03の図を比べ、「追加したもの」と「解決する問題」を確認します。
1台で受ける
ユーザー
すべてのリクエスト
EC2 Aアプリを実行負荷が集中
処理能力が 足りなくなる
アクセスが増えると、1台のEC2に負荷が集中します。必要な容量を増やす方法を考えます。
台数だけ 増やす
ユーザー
元の接続先へ
EC2 Aアプリを実行負荷が集中
EC2 B受付なし余力がある
2台目へ、 どう届ける？
手でEC2を追加しても、利用者が元のアドレスへ送るままでは偏りが残ります。台数と振り分けは別の問題です。
入口と 制御を加える
ユーザー
共通の入口
ELB / ALB正常なターゲットへ分散
EC2 AとBへ
EC2 Aアプリを実行
EC2 Bアプリを実行
分散と増減を 組み合わせる
ELBを共通の入口にし、CloudWatchの観測を使ってAuto Scalingが台数を調整します。連携したELBへ追加台が自動登録されます。
増やすことと、 送ること
Auto Scalingは「何台にするか」、ELBは「どこへ送るか」。違う役割を組み合わせて、追加した処理能力を使えるようにします。
変化を知るための CloudWatch
需要の変化に合わせるには、まずEC2の状態を知ります。CloudWatchのメトリクスとアラームを、台数制御の判断に利用します。
CloudWatchEC2のメトリクスを観測
アラーム
EC2 Auto Scalingポリシーで台数を調整
増減には、 条件がある
学習用の設定例は、最小2台・希望2台・最大6台、平均CPUの目標50%です。台数の増減はポリシーと上下限に従い、起動・ウォームアップには時間がかかります。CPUが上がった瞬間に、必ず台数が増えるという意味ではありません。
Auto ScalingグループとELBを連携させると、起動・終了に応じてターゲットが自動で登録・解除されます。ELBはヘルスチェックで状態を確かめ、通常は正常なターゲットへ送ります。アプリ側も複数台で処理を分担できる設計が必要です。
確認したAWS公式資料
2026年10月6日に確認。Module 2のトランスクリプトをもとに再編集しています。図は概念図で、VPC・AZ・セキュリティ設定などは省略しています。