MODULE 02 · 01
役割を、 図の中で読む
CloudWatch・Auto Scaling・ELBを、1つの構成の中で確認します。矢印の色と、サービスの横にある説明をたどってください。
読み方
青いリクエストの経路から読み、次に紫と緑の制御の経路を追います。
ユーザー
リクエスト
01ELB / ALBリクエストを分散
どこへ送るか共通の入口から複数のEC2へ。新しい台も、連携設定によりターゲットへ登録されます。
複数のEC2へ振り分け
Auto Scalingグループ
EC2 Aアプリを実行
EC2 Bアプリを実行
EC2の観測値
02CloudWatchメトリクス・アラーム
何が起きているかCPUなどの状態を観測します。観測することと、台数を変えることは別の役割です。
アラームを用いて制御
03EC2 Auto Scalingポリシーで台数を調整
何台にするか需要に合わせて増減します。新しいEC2の起動には時間が必要です。
↑ EC2グループの台数を変更し、その負荷を再び観測する。
分散と増減を、 分けて考える
ELBがあるだけで台数が増えるわけではありません。Auto Scalingで増やしただけでも、リクエストが適切に分かれるとは限りません。観測・台数の制御・リクエストの分散を組み合わせます。
増減には、 条件がある
学習用の設定例は、最小2台・希望2台・最大6台、平均CPUの目標50%です。台数の増減はポリシーと上下限に従い、起動・ウォームアップには時間がかかります。CPUが上がった瞬間に、必ず台数が増えるという意味ではありません。
Auto ScalingグループとELBを連携させると、起動・終了に応じてターゲットが自動で登録・解除されます。ELBはヘルスチェックで状態を確かめ、通常は正常なターゲットへ送ります。アプリ側も複数台で処理を分担できる設計が必要です。
確認したAWS公式資料
2026年10月6日に確認。Module 2のトランスクリプトをもとに再編集しています。図は概念図で、VPC・AZ・セキュリティ設定などは省略しています。