助け合いフォーラム
AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 35551
問題を開く
ある会社は、AWS上で本番用Webアプリケーションを運用している。このWebアプリケーションは、Amazon SQSキューからデータを取得し、Auto Scaling配下にある複数のEC2インスタンスで並列に処理している。このアプリケーションに対する需要は不規則に変動し、予測が困難である。会社は費用対効果を最大化しつつ、アプリケーションのダウンタイムが発生することなくユーザーが継続的に利用できるようにしたい。
次のうち、最適なソリューションはどれか。
次のうち、最適なソリューションはどれか。
正解
ベースラインとなる台数のEC2インスタンスをリザーブドインスタンスで契約し、需要増加に対応するためのEC2インスタンスをスポットインスタンスで契約する
解説
EC2インスタンスには、利用目的に基づいてコストを最適化するために複数の購入オプションがあります。
![<img src="/mondai3/img/jpg/k58333.jpg">](https://ping-t-resouces.com/uploads/question_image/file/22839/k58333.jpg)
上記の表から、ベースラインとなる台数のEC2インスタンスは、長期契約で低価格となるリザーブドインスタンスが適しています。一方、需要増加に対応するためのEC2インスタンスは、スポットインスタンスが最も低価格です。スポットインスタンスは利用中にインスタンスが中断する可能性がありますが、Amazon SQSキューでリクエストを中継しているので、万が一処理中にインスタンスが中断してもSQSキューに保持されているメッセージは失われず、別のインスタンスで処理を再開できます。
したがって正解は
・ベースラインとなる台数のEC2インスタンスをリザーブドインスタンスで契約し、需要増加に対応するためのEC2インスタンスをスポットインスタンスで契約する
です。
その他の選択肢については、以下のとおりです。
・ベースラインとなる台数のEC2インスタンスをリザーブドインスタンスで契約し、需要増加に対応するためのEC2インスタンスをオンデマンドインスタンスで契約する
オンデマンドインスタンスは、インスタンスが中断することなく継続的にアプリケーションを実行できますが、スポットインスタンスよりも高額です。設問のケースではSQSキューを利用してリクエストを中継しているので、インスタンスが突然中断された場合でもデータが消失せずに、別のEC2インスタンスで継続してアプリケーションを実行できます。
需要増加に対応するためのEC2インスタンスは、オンデマンドインスタンスよりスポットインスタンスの方が、費用対効果を最大化できるので誤りです。
・ベースラインとなる台数のEC2インスタンスをオンデマンドインスタンスで契約し、需要増加に対応するためのEC2インスタンスをスポットインスタンスで契約する
オンデマンドインスタンスは開発環境など利用が短時間のシステムや、需要が予測できないシステムに適しています。
長期運用が見込まれる本番用アプリケーションには、ベースラインとなる台数をリザーブドインスタンスで契約する方が、費用対効果を最大化できます。よって、誤りです。
・最大の需要に対応できる台数のEC2インスタンスをリザーブドインスタンスで契約する
リザーブドインスタンスは長期契約で低額になりますが、常に最大の需要に対応できるインスタンス数を契約する場合、過剰なリソースを契約することになります。
費用対効果を最大化できないので、誤りです。
![<img src="/mondai3/img/jpg/k58333.jpg">](https://ping-t-resouces.com/uploads/question_image/file/22839/k58333.jpg)
上記の表から、ベースラインとなる台数のEC2インスタンスは、長期契約で低価格となるリザーブドインスタンスが適しています。一方、需要増加に対応するためのEC2インスタンスは、スポットインスタンスが最も低価格です。スポットインスタンスは利用中にインスタンスが中断する可能性がありますが、Amazon SQSキューでリクエストを中継しているので、万が一処理中にインスタンスが中断してもSQSキューに保持されているメッセージは失われず、別のインスタンスで処理を再開できます。
したがって正解は
・ベースラインとなる台数のEC2インスタンスをリザーブドインスタンスで契約し、需要増加に対応するためのEC2インスタンスをスポットインスタンスで契約する
です。
その他の選択肢については、以下のとおりです。
・ベースラインとなる台数のEC2インスタンスをリザーブドインスタンスで契約し、需要増加に対応するためのEC2インスタンスをオンデマンドインスタンスで契約する
オンデマンドインスタンスは、インスタンスが中断することなく継続的にアプリケーションを実行できますが、スポットインスタンスよりも高額です。設問のケースではSQSキューを利用してリクエストを中継しているので、インスタンスが突然中断された場合でもデータが消失せずに、別のEC2インスタンスで継続してアプリケーションを実行できます。
需要増加に対応するためのEC2インスタンスは、オンデマンドインスタンスよりスポットインスタンスの方が、費用対効果を最大化できるので誤りです。
・ベースラインとなる台数のEC2インスタンスをオンデマンドインスタンスで契約し、需要増加に対応するためのEC2インスタンスをスポットインスタンスで契約する
オンデマンドインスタンスは開発環境など利用が短時間のシステムや、需要が予測できないシステムに適しています。
長期運用が見込まれる本番用アプリケーションには、ベースラインとなる台数をリザーブドインスタンスで契約する方が、費用対効果を最大化できます。よって、誤りです。
・最大の需要に対応できる台数のEC2インスタンスをリザーブドインスタンスで契約する
リザーブドインスタンスは長期契約で低額になりますが、常に最大の需要に対応できるインスタンス数を契約する場合、過剰なリソースを契約することになります。
費用対効果を最大化できないので、誤りです。
参考
【EC2インスタンスの購入オプション】
EC2インスタンスには、利用目的に基づいてコストを最適化するために複数の購入オプションがあります。インスタンスが稼働するハードウェアを他AWSアカウントと共用するか否かで「共用ハードウェアを使用するインスタンス」と「ハードウェアを専有するインスタンス」に分けられます。
【共有ハードウェアを使用するインスタンスの購入オプション】
以下の購入オプションは、他のAWSアカウントとハードウェアを共有して利用します。
〇オンデマンドインスタンス
インスタンスの起動時間に基づいた料金体系で、EC2インスタンスのデフォルトの購入オプションです。開発環境など、利用が短期間のシステムに適しています。
〇リザーブドインスタンス
1年もしくは3年の長期契約を結ぶことによって、オンデマンドインスタンスよりも低価格で利用できる購入オプションです。1年以上にわたり継続して稼働するシステムに適しています。リザーブドインスタンスは、1年契約より3年契約、前払い無しより前払い有りの方が割引率が高いです。
リザーブドインスタンスには2つの種類があります。
・スタンダードリザーブドインスタンス(標準RI)
契約の途中でOSやインスタンスタイプを変更できない代わりに、コンバーティブルリザーブドインスタンスと比較して割引率がより高くなっています。
・コンバーティブルリザーブドインスタンス(コンバーティブルRI)
スタンダードリザーブドインスタンスと比べて割引率が低い代わりに、条件が合えば契約の途中でOSやインスタンスタイプを変更できます。
〇Savings Plans
1年もしくは3年の期間、一定のサービス使用量(1時間あたりの利用料金)を決めて契約することで、オンデマンドインスタンスよりも低価格になる購入オプションです。リザーブドインスタンスは購入時にOSやインスタンスタイプを指定する必要がありますが、Savings Plansはそのような指定が不要で、契約途中に変更も可能です。また、Savings PlansはEC2に加えてLambda、Fargateにも割引を適用させるプランもあり、柔軟性の高いオプションです。
〇スポットインスタンス
AWS内で使用されていないEC2インスタンスを低価格で利用できる購入オプションです。EC2インスタンスの購入オプションの中で、もっとも割引率が高いです。
スポットインスタンスの価格は、AZ内の各インスタンスタイプの需要と供給バランスに基づいて決定されます。インスタンスの需要が急増するか供給が不足する場合、インスタンスが中断されるリスクがあります。このため、インスタンスの中断が許容されるシステム(例:並列バッチ処理の一部のインスタンスなど)に向いています。
スポットインスタンスには複数のオプションがあります。その中の「スポットフリート」は必要なインスタンス数を指定することで、指定した数のスポットインスタンスが起動します。スポットインスタンスが中断されて必要なインスタンス数を下回った場合、自動的にインスタンスを補充してインスタンス数を維持します。補充されるインスタンスにはオンデマンドインスタンスも含まれます。
[共有ハードウェアを使用するインスタンスの購入オプション一覧]
![【図を表示】](https://ping-t-resouces.com/uploads/question_image/file/22839/k58333.jpg)
【ハードウェアを専有するインスタンスの購入オプション】
以下の購入オプションは、AWSアカウント内でハードウェアを専有して利用します。
〇ハードウェア専有インスタンス
ハードウェア専有インスタンスは、他のAWSアカウントとは分離された専用ハードウェアでEC2インスタンスを利用できる購入オプションです。物理的なCPUソケット、コア数、ホストIDは確認できません。ハードウェア専有インスタンスは、同AWSアカウントのハードウェア専有インスタンスではないインスタンスと、ハードウェアを共有する可能性があります。
〇専有ホスト(Dedicated Hosts)
Dedicated Hosts(専有ホスト)は、他のEC2インスタンスとは分離された専用ハードウェアで利用できる購入オプションです。物理的なCPUソケット、コア数、ホストIDを確認できます。Dedicated Hostsのハードウェアには、ユーザーが指定したインスタンスのみ配置されます。
例えば、CPUソケットや物理コア、仮想マシンごとに割り当てられたソフトウェアライセンスを保有している場合に、Dedicated Hosts契約のインスタンスを利用します。
Dedicated HostsはEC2インスタンスを利用する上で、もっとも購入価格が高いオプションです。
[ハードウェアを専有するインスタンスの購入オプション一覧]
![<img src="/mondai3/img/jpg/k58341.jpg">](https://ping-t-resouces.com/uploads/question_image/file/23053/k58341.jpg)
[共有ハードウェアインスタンスと、ハードウェアを専有するインスタンスのイメージ]
![<img src="/mondai3/img/jpg/kk58341.jpg">](https://ping-t-resouces.com/uploads/question_image/file/23054/kk58341.jpg)
EC2インスタンスには、利用目的に基づいてコストを最適化するために複数の購入オプションがあります。インスタンスが稼働するハードウェアを他AWSアカウントと共用するか否かで「共用ハードウェアを使用するインスタンス」と「ハードウェアを専有するインスタンス」に分けられます。
【共有ハードウェアを使用するインスタンスの購入オプション】
以下の購入オプションは、他のAWSアカウントとハードウェアを共有して利用します。
〇オンデマンドインスタンス
インスタンスの起動時間に基づいた料金体系で、EC2インスタンスのデフォルトの購入オプションです。開発環境など、利用が短期間のシステムに適しています。
〇リザーブドインスタンス
1年もしくは3年の長期契約を結ぶことによって、オンデマンドインスタンスよりも低価格で利用できる購入オプションです。1年以上にわたり継続して稼働するシステムに適しています。リザーブドインスタンスは、1年契約より3年契約、前払い無しより前払い有りの方が割引率が高いです。
リザーブドインスタンスには2つの種類があります。
・スタンダードリザーブドインスタンス(標準RI)
契約の途中でOSやインスタンスタイプを変更できない代わりに、コンバーティブルリザーブドインスタンスと比較して割引率がより高くなっています。
・コンバーティブルリザーブドインスタンス(コンバーティブルRI)
スタンダードリザーブドインスタンスと比べて割引率が低い代わりに、条件が合えば契約の途中でOSやインスタンスタイプを変更できます。
〇Savings Plans
1年もしくは3年の期間、一定のサービス使用量(1時間あたりの利用料金)を決めて契約することで、オンデマンドインスタンスよりも低価格になる購入オプションです。リザーブドインスタンスは購入時にOSやインスタンスタイプを指定する必要がありますが、Savings Plansはそのような指定が不要で、契約途中に変更も可能です。また、Savings PlansはEC2に加えてLambda、Fargateにも割引を適用させるプランもあり、柔軟性の高いオプションです。
〇スポットインスタンス
AWS内で使用されていないEC2インスタンスを低価格で利用できる購入オプションです。EC2インスタンスの購入オプションの中で、もっとも割引率が高いです。
スポットインスタンスの価格は、AZ内の各インスタンスタイプの需要と供給バランスに基づいて決定されます。インスタンスの需要が急増するか供給が不足する場合、インスタンスが中断されるリスクがあります。このため、インスタンスの中断が許容されるシステム(例:並列バッチ処理の一部のインスタンスなど)に向いています。
スポットインスタンスには複数のオプションがあります。その中の「スポットフリート」は必要なインスタンス数を指定することで、指定した数のスポットインスタンスが起動します。スポットインスタンスが中断されて必要なインスタンス数を下回った場合、自動的にインスタンスを補充してインスタンス数を維持します。補充されるインスタンスにはオンデマンドインスタンスも含まれます。
[共有ハードウェアを使用するインスタンスの購入オプション一覧]
![【図を表示】](https://ping-t-resouces.com/uploads/question_image/file/22839/k58333.jpg)
【ハードウェアを専有するインスタンスの購入オプション】
以下の購入オプションは、AWSアカウント内でハードウェアを専有して利用します。
〇ハードウェア専有インスタンス
ハードウェア専有インスタンスは、他のAWSアカウントとは分離された専用ハードウェアでEC2インスタンスを利用できる購入オプションです。物理的なCPUソケット、コア数、ホストIDは確認できません。ハードウェア専有インスタンスは、同AWSアカウントのハードウェア専有インスタンスではないインスタンスと、ハードウェアを共有する可能性があります。
〇専有ホスト(Dedicated Hosts)
Dedicated Hosts(専有ホスト)は、他のEC2インスタンスとは分離された専用ハードウェアで利用できる購入オプションです。物理的なCPUソケット、コア数、ホストIDを確認できます。Dedicated Hostsのハードウェアには、ユーザーが指定したインスタンスのみ配置されます。
例えば、CPUソケットや物理コア、仮想マシンごとに割り当てられたソフトウェアライセンスを保有している場合に、Dedicated Hosts契約のインスタンスを利用します。
Dedicated HostsはEC2インスタンスを利用する上で、もっとも購入価格が高いオプションです。
[ハードウェアを専有するインスタンスの購入オプション一覧]
![<img src="/mondai3/img/jpg/k58341.jpg">](https://ping-t-resouces.com/uploads/question_image/file/23053/k58341.jpg)
[共有ハードウェアインスタンスと、ハードウェアを専有するインスタンスのイメージ]
![<img src="/mondai3/img/jpg/kk58341.jpg">](https://ping-t-resouces.com/uploads/question_image/file/23054/kk58341.jpg)
解説がよくわかりません。
公開日 2024/06/01
問題文に「このアプリケーションに対する需要は不規則に変動し、予測が困難である。」とあるためベースのEC2インスタンスの契約はオンデマンドインスタンスが最適と考えましたが不正解のようでした。
解説中にも「オンデマンドインスタンスは開発環境など利用が短時間のシステムや、需要が予測できないシステムに適しています。」とあるにもかかわらず「ベースラインとなる台数のEC2インスタンスをオンデマンドインスタンスで契約し、需要増加に対応するためのEC2インスタンスをスポットインスタンスで契約する」が不正解になるのはなぜなのでしょうか?
2024/06/01 22:06
日本語的な部分になるかもしれませんが
- 問題文の冒頭に「ある会社は、AWS上で本番用Webアプリケーションを運用している。」とあるので、「本番用」であることが前提
- 本番用ということは、ある程度のリソース(ベースライン)分が一定期間稼働することが確実である(短期利用ではない)
- 最低稼働に必要な「ベースライン」はオンデマンド(短期需要対応)ではなくリザーブド(稼働することが確定しているもの向け)の方が低価格
- このシステムはSQS(とAuto Scaling)によってダウンタイムを発生させない作りになっているので、「需要は不規則に変動し、予測が困難」な部分の対応にはオンデマンドより低価格なスポットインスタンスを採用できる
ということかなと思います。
何ヶ所か問題や解説を引用されていますが、それ以外の部分をもう一度じっくり読み返してみると良いかもしれません。
コメント
この投稿に対して返信しませんか?
a a-misaki-1687
2024/06/01 22:48
分かりやすいご説明ありがとうございます。 安定稼働させたいはずの本番環境で需要もわからない状態なのにベースラインをどう見極めたのかなとか、オンデマンドで様子見をするのではなくいきなりリザーブドで契約するのがどうしても飲み込めできず引っかかっていたのですが、確かにAuto Scalingも考慮され、不足部分はスポットインスタンスで補おうとしているので費用対効果とダウンタイムへの対策としてはこちらが最適なのかなと納得できました。