AWS Certified CloudOps Engineer - Associate (SOA-C03) #5 Domain 2-1 信頼性: Multi-AZ・Auto Scaling・ELB ヘルスチェック
#4 までモニタリングドメインを終えました。この記事からは 2 番目のドメインである 信頼性とビジネス継続性 (22%) です。信頼性の最初の軸は「障害が起きてもサービスが続くようにする」可用性運用です。SAA で設計として学んだ Multi-AZ・Auto Scaling・ELB を、ここでは 運用中にどう動作し、何がずれたときに何を直すのか の観点で改めて見ます。
可用性の基本: アベイラビリティーゾーンの多重化 #
リージョン (Region) は物理的に分離された複数の アベイラビリティーゾーン (AZ) で構成されます。1 つの AZ が丸ごと失敗してもサービスが生き残るには、リソースを 複数の AZ にまたがって 置く必要があります。
| 構成 | Single-AZ | Multi-AZ |
|---|---|---|
| AZ 障害の影響 | サービス停止 | 別の AZ で継続 |
| 代表的な適用 | 開発・一時的 | 運用ワークロード |
核心は 多重化はほぼ常に AZ レベルから始まる という点です。リージョン全体の障害に備えるマルチリージョンはコストが大きく、アソシエイト試験の基本的な答えはたいてい Multi-AZ です。
Auto Scaling グループ (ASG) の運用 #
ASG は 決められた容量を維持し、負荷に応じてインスタンス数を調整 する仕組みです。3 つの容量値が運用の核心です。
| 値 | 意味 |
|---|---|
| Minimum | 常に維持する最小インスタンス数 |
| Desired | 現在の目標数。ポリシーがこの値を調整 |
| Maximum | 増やせる上限 |
スケーリングポリシー #
| ポリシー | 動作 | いつ |
|---|---|---|
| Target Tracking | 目標指標値 (例: CPU 50%) を維持するよう自動調整 | 最も推奨。シンプル・安定 |
| Step Scaling | しきい値の区間ごとに決められた量だけ調整 | 細かい制御が必要なとき |
| Scheduled | 決められた時刻に容量を変更 | トラフィックパターンが予測できる場合 |
「トラフィックが毎日午前に集中する」のような 予測可能なパターン は Scheduled Scaling、「負荷に応じて自動で」は Target Tracking が答えです。
ライフサイクルフック (Lifecycle Hook) #
インスタンスが ASG に入るときや出るときに 特定の作業を挟み込む 仕組みです。
- 起動フック: インスタンスがサービスに入る前に設定・登録の完了を保証
- 終了フック: インスタンスが終了する前に ログ収集・接続の整理 といった仕上げ
「終了されるインスタンスのログを失わないようにせよ」という要件の答えが終了ライフサイクルフックです。インスタンスを一時待機状態に保持し、仕上げ作業を終えてから送り出します。
ELB: 種類とヘルスチェック #
ELB はトラフィックを健全なターゲットにのみ分配します。種類の区別が試験のポイントです。
| 種類 | 層 | 代表的な用途 |
|---|---|---|
| ALB | L7 (HTTP/HTTPS) | パス・ホストベースのルーティング、Web アプリケーション |
| NLB | L4 (TCP/UDP) | 超高性能・固定 IP・低遅延 |
| GWLB | L3 | ファイアウォールなどインラインのセキュリティアプライアンス |
ヘルスチェック #
ELB はターゲットグループのインスタンスに 定期的にヘルスチェックリクエスト を送り、健全かどうかを判断します。
- 正常しきい値・異常しきい値・間隔・タイムアウト・パスを設定
- 異常と判定されたターゲットにはトラフィックを送らない
- ALB は HTTP パス (例:
/health) とステータスコードで、NLB は TCP 接続で判断
「一部のインスタンスが応答しないのに ELB がトラフィックを送り続ける」というシナリオは、たいてい ヘルスチェックのパス・しきい値の設定問題 です。
接続ドレイニング (Deregistration Delay) #
インスタンスをターゲットグループから外したり終了したりするときに、処理中のリクエストを最後まで処理するよう待つ 時間です。この値が 0 だと、デプロイ・縮小の途中でユーザーリクエストが切れます。「デプロイのたびに一部のリクエストが失敗する」の答えが接続ドレイニング (登録解除の遅延) の設定です。
Route 53 フェイルオーバー #
AZ を越えた エンドポイントレベルの可用性 は Route 53 で構成します。
| ルーティングポリシー | 動作 |
|---|---|
| Failover | 主 (primary) が異常なら副 (secondary) に切り替え |
| Weighted | 重みの比率で分散 (段階的なロールアウト・A/B) |
| Latency | 最も遅延の低いリージョンへ |
| Multivalue | 複数の正常なエンドポイントを返す (簡単な分散) |
フェイルオーバーの前提は Route 53 ヘルスチェック です。エンドポイントを定期的に点検し、異常なら DNS 応答から外して副に引き継ぎます。「リージョン障害時に別のリージョンへ自動で切り替え」の答えが Route 53 Failover ルーティング + ヘルスチェックです。DNS キャッシュ (TTL) のために切り替えが即時ではない点も合わせて覚えておく価値があります。
試験での出題パターン #
- AZ 障害でも継続 → リソースを 複数の AZ に多重化
- 予測可能なトラフィック急増 → Scheduled Scaling
- 負荷に応じて自動調整 → Target Tracking
- 終了インスタンスのログ保存 → 終了ライフサイクルフック
- 異常なインスタンスにトラフィックが行き続ける → ヘルスチェック設定の点検
- デプロイ中のリクエスト失敗 → 接続ドレイニング (登録解除の遅延)
- リージョン障害時の自動切り替え → Route 53 Failover + ヘルスチェック
よくある落とし穴 #
1) Desired だけ変えれば恒久的だと思う #
スケーリングポリシーが Desired を再び調整します。固定するには Min・Max を同じ値にするか、ポリシーを手直しする必要があります。
2) ASG ヘルスチェックを EC2 だけにしておく #
#4 で見た落とし穴の繰り返しです。アプリケーション障害まで捉えるには ELB ヘルスチェック を有効にする必要があります。
3) NLB に HTTP パスのヘルスチェックを期待する #
NLB は L4 です。アプリケーションの応答コードで除外するには ALB が正解です。
4) Route 53 フェイルオーバーが即時だと仮定する #
DNS TTL とヘルスチェック間隔のために切り替えに時間がかかります。TTL を下げて切り替えを速くします。
まとめ #
この記事で押さえたこと:
- 多重化は AZ レベル から始まる。アソシエイトの基本的な可用性の答えは Multi-AZ
- ASG は Min・Desired・Max で容量を維持・調整。ポリシーは Target Tracking (推奨)・Step・Scheduled
- ライフサイクルフック で起動・終了時に作業を挿入。終了フックでログを保存
- ELB は ALB (L7)・NLB (L4)・GWLB。ヘルスチェックで健全なターゲットのみに分配
- 接続ドレイニング でデプロイ・縮小中の処理中リクエストを保護
- Route 53 Failover + ヘルスチェック でエンドポイント・リージョンレベルの切り替え。DNS TTL で切り替え速度を調整
次: Domain 2-2 バックアップ・復元と災害復旧 #
可用性で「動き続けること」を押さえたので、次は「データを失わずに復旧すること」です。
#6 Domain 2-2 信頼性: バックアップ・復元と災害復旧 (DR) では、EBS スナップショットと AMI、RDS バックアップとスナップショット、AWS Backup でバックアップを中央管理する方法、RPO と RTO の意味、そしてバックアップ・パイロットライト・ウォームスタンバイ・マルチサイトへとつながる DR 戦略まで整理します。