Q36 — AWS SAP-C02 第2章

第 36/75 問 | ← 第2章

Q186. ある企業がAWS Elastic BeanstalkとJavaを用いてパイロットアプリケーションを開発しました。開発中のコスト削減のため、開発チームはこのアプリケーションをシングルインスタンス環境にデプロイしました。最近のテスト結果によると、アプリケーションが想定よりも高いCPU使用率を示しており、CPU利用率が定期的に85%を超え、一部のパフォーマンスボトルネックを引き起こしています。ソリューションアーキテクトは、本番環境へのアプリケーションリリース前に、これらのパフォーマンス問題を解消する必要があります。これらの要件を満たすとともに、運用上のオーバーヘッドが最も少ないソリューションはどれですか？

• A. 新しいElastic Beanstalkアプリケーションを作成します。ロードバランシングされた環境タイプを選択し、すべての可用性ゾーンを選択します。最大CPU利用率が5分間連続して85%を超えた場合に実行されるスケールアウトルールを追加します。
• B. 2つ目のElastic Beanstalk環境を作成します。トラフィック分割デプロイポリシーを適用し、平均CPU利用率が5分間連続して85%を超えた場合に、受信トラフィックの一定割合を新しい環境に転送するよう指定します。
• C. 既存の環境のキャパシティ設定を変更し、ロードバランシングされた環境タイプを使用するようにします。すべての可用性ゾーンを選択し、平均CPU利用率が5分間連続して85%を超えた場合に実行されるスケールアウトルールを追加します。 ✓
• D. ロードバランシングオプション付きで「環境の再構築」アクションを選択します。すべての可用性ゾーンを選択し、CPU利用率の合計値が5分間連続して85%を超えた場合に実行されるスケールアウトルールを追加します。

正解: C. 既存の環境のキャパシティ設定を変更し、ロードバランシングされた環境タイプを使用するようにします。すべての可用性ゾーンを選択し、平均CPU利用率が5分間連続して85%を超えた場合に実行されるスケールアウトルールを追加します。

解説

これらの要件を満たし、かつ運用上のオーバーヘッドが最も少ないソリューションは、選択肢Cです。既存の環境のキャパシティ設定を変更し、ロードバランシングされた環境タイプを使用するようにします。すべての可用性ゾーンを選択し、平均CPU利用率が5分間連続して85%を超えた場合に実行されるスケールアウトルールを追加します。 理由は以下の通りです。 1. 運用上のオーバーヘッド：既存の環境のキャパシティ設定を変更するという方法は、非常にシンプルな操作であり、新規環境の作成や既存環境の再構築などに比べて、運用負荷が最小限に抑えられます。 2. ロードバランシングされた環境：ロードバランシングされた環境タイプに切り替えることで、受信トラフィックを複数のインスタンスに分散させることができ、高CPU利用率によるパフォーマンスボトルネックの緩和が可能になります。 3. 可用性ゾーン：すべての可用性ゾーンを選択することで、異なる物理ロケーションにまたがるリソースを活用でき、耐障害性およびスケーラビリティが向上します。 4. スケールアウトルール：平均CPU利用率が5分間連続して85%を超えた場合にトリガーされるスケールアウトルールを追加すると、負荷増加時に自動的にインスタンス数を増やすことができ、パフォーマンス問題の発生リスクを低減できます。 選択肢A（新しいElastic Beanstalkアプリケーションとロードバランシングされた環境の作成）は、新規アプリケーションおよび環境の構築を伴うため、既存環境の設定変更に比べて追加のオーバーヘッドと複雑さが生じます。 選択肢B（トラフィック分割デプロイを用いた2つ目のElastic Beanstalk環境の作成）は、2つの環境間でのトラフィック分割の設定・監視が必要となり、運用の複雑さが増します。 選択肢D（ロードバランシング付きでの環境の再構築）は、再構築中にダウンタイムが発生する可能性があり、また設定変更よりも手間と時間がかかるため、運用負荷が高くなります。 したがって、与えられた要件に基づき、選択肢Cは、既存環境の設定変更のみで効果的にパフォーマンス問題を解決できる、最も簡潔かつ実用的なソリューションです。