ALB + Auto Scaling + RDS Multi-AZ 高可用性構成
複数AZにWebサーバーを配置し、ALBで負荷分散し、Auto ScalingとRDS Multi-AZで可用性を高める構成です。
構成図
使用AWSサービス
サービス名をクリックすると、用語詳細ページへ移動します。
概要
高可用性Webアプリ構成は、複数AZにWebサーバーを配置し、ALBで負荷分散し、Auto Scalingで必要な台数を維持し、RDS Multi-AZでDB障害に備える構成です。 1つのAZや1台のEC2に障害が発生しても、別AZのリソースでサービス継続できる設計を目指します。
通信フロー
1. ユーザーがALBへHTTPSアクセスします。 2. ALBが複数AZに配置されたEC2へリクエストを分散します。 3. Auto Scaling Groupが希望台数を維持します。 4. 異常なEC2はALBのヘルスチェックで切り離されます。 5. アプリケーションはRDSのプライマリDBへ接続します。 6. RDS Multi-AZ構成では、障害時にスタンバイDBへフェイルオーバーします。 7. CloudWatchがメトリクスを収集し、スケーリングや障害調査に使われます。
設計ポイント
ALBとAuto Scaling Groupは複数AZにまたがるように設計します。EC2はステートレスにし、ユーザーセッションやアップロードファイルをインスタンス内に持たせない設計が望ましいです。 RDS Multi-AZは可用性向上が目的です。読み取り性能向上が目的の場合はRead Replicaを検討します。Multi-AZとRead Replicaの役割を混同しないことが重要です。
コスト設計
ALB、EC2、RDSは継続的に課金されます。RDS Multi-AZではスタンバイ分のコストも考慮します。 個人MVPでは固定費が重くなるため、このプロジェクト本体では採用しません。SAA対策として、可用性要件がある業務システム向けの構成として理解します。
SAA試験ポイント
高可用性、Multi-AZ、Auto Scaling、ヘルスチェック、ステートレス設計、RDS Multi-AZとRead Replicaの違いが問われます。 障害に強いWebアプリを作る条件では、複数AZ、ALB、Auto Scaling、RDS Multi-AZを組み合わせる選択肢を考えます。
このプロジェクトでの役割
AWS Cert Roadmap Labは静的サイト中心なので、この高可用性構成を本番採用する必要はありません。ただし、SAAで問われる可用性設計を説明するための重要コンテンツとして扱います。
他のAWS構成図も確認する
SAA対策では、AWSサービスを単体ではなく構成パターンとして理解することが重要です。