助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30658
問題を開く
あるシステムは3階層のEC2インスタンス群で構成されている。フロントエンド層とバックエンド層ではそれぞれ異なるEC2インスタンスが動作し、さらにその後ろにPostgreSQLデータベースが動作する別のEC2インスタンスがある。 このシステムをより可用性の高い構成に変更したいとき、システムへの影響が最も少ないものはどれか。

この問題はプレミアムコンテンツです。

上に戻る

システムへの影響について

投稿日 2024/02/27

以下問題についてです。

問題:
あるシステムは3階層のEC2インスタンス群で構成されている。フロントエンド層とバックエンド層ではそれぞれ異なるEC2インスタンスが動作し、さらにその後ろにPostgreSQLデータベースが動作する別のEC2インスタンスがある。
このシステムをより可用性の高い構成に変更したいとき、システムへの影響が最も少ないものはどれか。

・フロントエンドとバックエンドのEC2インスタンスをAWS Elastic BeanstalkのマルチAZ構成とし、PostgreSQLデータベースをAmazon RDSのマルチAZ構成にする
・フロントエンドとバックエンドのEC2インスタンスをAuto Scalingグループに追加し、ELBの後ろに配置する
・フロントエンドにはAWS Lambdaを、バックエンドはAmazon S3を配置し、データベースはDynamoDBを利用する
・フロントエンドとバックエンドのEC2インスタンスをAWS Elastic BeanstalkのマルチAZ構成とし、PostgreSQLデータベースをAmazon RDSのリードレプリカ構成にする

「システムへの影響が最も少ないものはどれか」が問われていますので
「フロントエンドとバックエンドのEC2インスタンスをAuto Scalingグループに追加し、ELBの後ろに配置する」が正解かと思ったのですが
「フロントエンドとバックエンドのEC2インスタンスをAWS Elastic BeanstalkのマルチAZ構成とし、PostgreSQLデータベースをAmazon RDSのマルチAZ構成にする」が正解でした。
EC2上のPostgreSQLデータベースをAmazon RDSに置き換える点もありシステムへの影響が最も少ないとは思えなかったのですが、どのように考えるべきでしょうか?


s shia125

2024/02/29 21:21

ご返信ありがとうございます。 要件が「より可用性の高い構成に変更したい」「システムへの影響が最も少ないものはどれか」でしたので 一番重要な要件はシステム影響であり、可能性向上は次点である(今より上がれば良い)と考えたのですがいかがでしょうか?

2024/02/29 16:16

「システムへの影響が最も少ないものはどれか」の前に「可用性の高い構成に変更したいとき」があります。
可用性の高い構成に変更できる方法の中から、システムへの影響が最も少ないものを選択する必要があります。
「フロントエンドとバックエンドのEC2インスタンスをAuto Scalingグループに追加し、ELBの後ろに配置する」は、誤答解説にあるとおりデータベースの可用性についての言及がないので、そもそも「可用性の高い構成にする」という要件を満たしていません。


コメント

s shia125

2024/02/29 21:21

※返信位置が誤っていたと思いますので、同じ投稿をさせていただきます ご返信ありがとうございます。 要件が「より可用性の高い構成に変更したい」「システムへの影響が最も少ないものはどれか」でしたので 一番重要な要件はシステム影響であり、可能性向上は次点である(今より上がれば良い)と考えたのですがいかがでしょうか?

n network_hoge

2024/03/01 11:13

横から失礼します。 確かに、「システムへの影響が最も少ないもの」は重要要件ではありますが、 そもそも達成しなければいけないのは「可用性のより高い構成への変更」です。 なので、この設問でに対する回答で必要なのは、 『「3階層すべての高可用化」を前提とした、「構成変更によるシステム影響の極小化」』 となります。 そのうえで、shia125さんの回答の場合、フロントエンド・バックエンドを高可用化しても 「PostgreSQLデータベースのEC2インスタンスが停止した場合、  DBそのもの、併せてDBと連携するシステムが使用できなくなる」という 単一障害点が残存します。 これでは、結果的に可用性が全く向上していないことになります。 他の誤答については解説の通りになります。 また、shia125さんの懸念にある「RDSへの置き換えによる影響」については、 RDSにPostgreSQL対応のサービスがあるので大きく問題にはならないと考えられます。

s shia125

2024/03/02 03:06

最も重要な要件は「可用性の高い構成」という捉え方ですね。ご解説ありがとうございます。 なおRDSへの置き換えによる影響については、アーキテクチャの変更ではなく 置き換えに伴うシステムの利用不可時間発生を懸念したものでした。 考え方がずれているのかもしれませんが、システムへの影響=利用不可時間と思っていました。 またこの点はarashi1977さんのご解説の通り、移行手法を工夫することで極小にすることが可能と捉えました。

この返信に対して
コメントを記入できます

2024/02/29 23:12

参考に以下の記述があるので「システムへの影響」は最も少ないと言っても問題ないと思うのですが、どうでしょうか?

一方、稼働中のアプリケーションをバージョンアップするような場合には、一部のインスタンスから段階的にデプロイを行う方式(ローリングデプロイ)や、旧環境は稼働したまま新しい環境にバージョンアップしたアプリケーションをデプロイし、問題ないことが確認できたら旧環境とURLを入れ替える方式などがあります。段階的にデプロイする際に行うELBの切り替えや新規インスタンスの構築などは、Elastic Beanstalkがすべて自動で行います。アプリケーションの開発者にとってはシステムの複雑な設定や切り替え作業を行う必要がなく、開発したアプリケーションを安全に展開できます。


コメント

a arashi1977

2024/02/29 23:17

追記です。 DBの部分についてはもともとが > その後ろにPostgreSQLデータベースが動作する別のEC2インスタンス なので、フロントエンドからしたら「接続先バックエンドのアドレスを変更する」だけなので、RDSに移行したとしても特に大きなシステム変更とはならないかなと。

s shia125

2024/03/02 03:04

フロントエンドとバックエンドのEC2インスタンスをAWS Elastic BeanstalkのマルチAZ構成とするために 環境の置き換えが発生し、システムの利用不可時間が発生する=システムへの影響を伴うと捉えていました。 置き換え先の環境への移行手法は特に言及ないのでフロントエンド、バックエンド、DBいずれも URL/アドレスの置き換えによって移行すれば瞬断程度のシステム影響に留まり 「システムへの影響が最も少ない」を満たせるという捉え方ですね。ご解説ありがとうございます。

この返信に対して
コメントを記入できます

この投稿に対して返信しませんか?