Q67 — AWS SAA-C03 第17章
第 67/89 問 | ← 第17章
Q1367. ある会社が、重要なWebベースアプリケーションのアップグレードを行っています。このアプリケーションは、Application Load Balancer(ALB)の背後に配置されたAuto Scalingグループに属するAmazon EC2インスタンス上でホストされています。同社は、すべてのトラフィックをアップグレード版アプリケーションに切り替える前に、特定の割合のトラフィックで新しい設定をテストしたいと考えています。ソリューションアーキテクトは、これらの要件を満たすために、どのようなアーキテクチャを設計すべきでしょうか?
- A. 新しい起動テンプレートを作成します。この新しい起動テンプレートをAuto Scalingグループに関連付けます。Auto ScalingグループをALBにアタッチします。リダイレクトルールを使用してトラフィックを分散します。
- B. 新しい起動テンプレートを作成します。追加のAuto Scalingグループを作成します。この新しい起動テンプレートを追加のAuto Scalingグループに関連付けます。追加のAuto ScalingグループをALBにアタッチします。重み付きターゲットグループを使用してトラフィックを分散します。 ✓
- C. 新しい起動テンプレートを作成します。追加のAuto Scalingグループを作成します。この新しい起動テンプレートを追加のAuto Scalingグループに関連付けます。追加のALBを作成します。追加のAuto Scalingグループを追加のALBにアタッチします。Amazon Route 53のフェイルオーバールーティングポリシーを使用してトラフィックをルーティングします。
- D. 新しい起動テンプレートを作成します。追加のAuto Scalingグループを作成します。この新しい起動テンプレートを追加のAuto Scalingグループに関連付けます。追加のALBを作成します。追加のAuto Scalingグループを追加のALBにアタッチします。Amazon Route 53の重み付きルーティングポリシーを使用してトラフィックをルーティングします。
正解: B. 新しい起動テンプレートを作成します。追加のAuto Scalingグループを作成します。この新しい起動テンプレートを追加のAuto Scalingグループに関連付けます。追加のAuto ScalingグループをALBにアタッチします。重み付きターゲットグループを使用してトラフィックを分散します。
解説
正解はBです。「新しい起動テンプレートを作成します。追加のAuto Scalingグループを作成します。この新しい起動テンプレートを追加のAuto Scalingグループに関連付けます。追加のAuto ScalingグループをALBにアタッチします。重み付きターゲットグループを使用してトラフィックを分散します。」 解説: 会社は、全トラフィックをアップグレード版アプリケーションに切り替える前に、一定の割合のトラフィックで新設定をテストしたいという要件を持っています。これは、カナリアデプロイ(段階的なトラフィック移行)またはブルー・グリーンテスト(一部のトラフィックを新バージョンに送信)を実現する必要があります。 ■ 選択肢Bが最適な理由: ・新バージョン専用の別個のAuto Scalingグループ(ASG) 既存の(旧)バージョンとアップグレード後の(新)バージョンを同時に実行でき、互いに分離されます。新バージョンの障害が旧バージョンに影響を与えるリスクがありません。 ・ALBにおける重み付きターゲットグループ Application Load Balancer(ALB)は、複数のターゲットグループ(それぞれが1つのASGに対応)間でトラフィックを分散できます。 重み付きルーティングにより、各バージョンへのトラフィック割合(例:新バージョン10%、旧バージョン90%)を柔軟に制御できます。 これにより、段階的なロールアウトや、問題発生時の即時ロールバック(重みの調整や新ASGの終了)が可能です。 ・運用負荷が最小限 追加のALBやRoute 53の設定は不要であり、選択肢CおよびDよりシンプルです。 ALBのネイティブ機能を活用したトラフィック分割が可能になります。 ■ 他の選択肢が不適切な理由: A:単一のAuto Scalingグループ+リダイレクトルール → リダイレクトルールは、すべてのトラフィックを指定先に転送するものであり、部分的なトラフィック制御はできません。 → 旧・新バージョンが同一ASG内で実行されるため、新バージョンの障害が旧バージョンにも影響を及ぼすリスクがあります。 C:別個のALB+Route 53フェイルオーバールーティング → フェイルオーバールーティングは、主系エンドポイントの障害発生時にのみ代替エンドポイントへトラフィックを切り替えるものであり、段階的テストには不向きです。 → コストと運用の複雑さが増し、2つのALBおよびRoute 53のヘルスチェック管理が必要になります。 D:別個のALB+Route 53重み付きルーティング → 不必要な複雑さ:Route 53の重み付きルーティングはDNSレベルでのトラフィック分割であり、以下の課題があります。 ・TTLによる遅延:設定変更がDNSキャッシュ経由で反映されるまで時間がかかり、リアルタイムなトラフィック制御が困難です。 ・ALBの重み付きターゲットグループに比べ、精度が劣ります。 ・コスト増:2つのALBを運用するため、費用が高くなります。 ■ 部分的トラフィックでのテストに最適なアーキテクチャ: ・新バージョンを、新しい起動テンプレートを用いた別個のASGでデプロイします。 ・両方のASG(旧・新)を、同一のALBに別々のターゲットグループとして登録します。 ・ALBの重み付きターゲットグループ機能を用いてトラフィック配分を制御(例:新バージョン10%、旧バージョン90%)します。 ・パフォーマンスを監視しながら、徐々に新バージョンへのトラフィック割合を増加させ、問題が発生した場合は重みの調整や新ASGの終了により即座にロールバックできます。 結論:選択肢Bは、以下の点から最も効率的かつスケーラブルなソリューションです。 ・ALBのネイティブなトラフィック分割機能を活用(正確かつ迅速) ・新バージョンを完全に分離(リスク低減) ・最小限の構成変更(追加ALBやDNS設定不要) 選択肢A、C、Dは、いずれもトラフィック制御機能の欠如または不必要な複雑さを含むため、推奨されません。 最終的な正解:B