変更要約: SOA-C02 第2章を Associate 級に深掘り（比較表・シナリオ・FAQ・ひっかけ＋深掘り段落、図を日本語化）
2.1スケーラビリティと高可用性
ロードバランサーと Auto Scaling グループ（複数 AZ への分散・ヘルスチェックによる自己修復・min/desired/max）、スケーリングポリシーといった高可用性運用の基礎を理解します。
サービスを止めないためには、複数の AZ に冗長化し、負荷に応じて自動で増減させます。ロードバランサーと Auto Scaling グループがその要です。
2.1.1ロードバランサーと Auto Scaling
- ロードバランサー：ヘルスチェックで健全なターゲットだけにトラフィックを分散する。
- Auto Scaling グループ（ASG）：複数 AZ に分散し、min/desired/max で台数を管理。異常インスタンスは自動置換。
- スケーリングポリシー：ターゲット追跡（例 CPU 50%）・ステップ・スケジュールで増減させる。
「複数 AZ に分散＝単一 AZ 障害に耐える」「異常時に自動置換＝ASG の自己修復」「CPU などに追従＝ターゲット追跡ポリシー」 は SOA で頻出です。ELB のヘルスチェックと ASG のヘルスチェックの連携も押さえましょう。
高可用性は「複数 AZ への分散」と「自己修復」で実現します。Auto Scaling グループ（ASG） は min/desired/max で台数を管理し、複数 AZ にまたがって配置することで単一 AZ 障害に耐えます。ヘルスチェックには EC2 ステータスチェック（ハードウェア/到達性）と ELB ヘルスチェック（HTTP などアプリ層）があり、ASG のヘルスチェック種別を ELB 連携にすると、プロセスは生きていても HTTP で異常なインスタンスを置換できます。スケーリングポリシーは3種：ターゲット追跡（例 CPU 50% を維持＝最も簡単で推奨）、ステップスケーリング（しきい値の段階ごとに増減量を変える）、スケジュールスケーリング（時間帯が決まった負荷向け）。急増に備える ウォームプール や、新規インスタンスが計測に乗るまで待つ ウォームアップ/クールダウン、終了前に処理を逃がす ライフサイクルフック も運用で重要です。ELB には L7 の ALB・L4 の NLB があり、ターゲットグループ単位でヘルスチェックします。
| ポリシー | 使いどころ |
|---|---|
| ターゲット追跡 | メトリクスを目標値に維持（最も簡単） |
| ステップスケーリング | しきい値の段階で増減量を変える |
| スケジュールスケーリング | 時間帯が決まった負荷 |
| ELB ヘルスチェック連携 | アプリ層(HTTP)異常も置換 |
シナリオ：プロセスは生きているのに HTTP 500 を返すインスタンスが残る。 ASG のヘルスチェック種別を ELB 連携に変更すると、ELB のヘルスチェック（HTTP）で異常と判定されたインスタンスを ASG が自動置換。負荷追従は ターゲット追跡（CPU 50%）、毎朝のバッチ急増は スケジュールスケーリングで先回りします。
Q. 単一 AZ 障害に耐えるには？ ASG を複数 AZ に分散。Q. HTTP 異常も置換したい。 ASG ヘルスチェックを ELB 連携に。Q. CPU を一定に保つ？ ターゲット追跡。Q. 決まった時間の急増は？ スケジュールスケーリング。
混同に注意：
①EC2 ステータスチェックだけではアプリ層(HTTP)の異常を検知できない——ELB ヘルスチェック連携が必要。
②desired は希望値で、min/max の範囲内に収まる。
③スケールインで処理中の作業を失わないようライフサイクルフック/接続ドレインを使う。
ASG のヘルスチェックを ELB 連携にすると、アプリ層（HTTP）で異常なインスタンスも置換できます（EC2 ステータスだけでは検知できない障害に対応）。
2.1.2この節のまとめ
- 複数 AZ＋ASG＋ELB で高可用・自己修復
- スケールはターゲット追跡/ステップ/スケジュール
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 単一の AZ 障害が起きてもサービスを継続させたい。最も適した配置はどれですか？
Q2. Auto Scaling グループが異常なインスタンスを検知して置き換える仕組みは何と呼ばれますか？
Q3. CPU 使用率を一定（例 50%）に保つように台数を増減させたい。どのスケーリングポリシーが適しますか？