助け合いフォーラム

AWS

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

正解

フロントエンドとバックエンドのEC2インスタンスをAWS Elastic BeanstalkのマルチAZ構成とし、PostgreSQLデータベースをAmazon RDSのマルチAZ構成にする

解説

本設問のポイントは「システムへの影響を少なく、より可用性の高い構成にする」という点です。
各選択肢を確認していきましょう。

・フロントエンドとバックエンドのEC2インスタンスをAWS Elastic BeanstalkのマルチAZ構成とし、PostgreSQLデータベースをAmazon RDSのリードレプリカ構成にする
AWS Elastic Beanstalkは、アプリケーションが動作する定番の構成を提供します。アプリケーションの開発者は、Elastic Beanstalkによって用意されている定番構成の中からアプリケーションの実行環境に適したものを選んで数クリックするだけで、環境(インフラ)を作成することができます。環境の作成後にアプリケーションをアップロードすることにより、デプロイ(実行環境への展開)を行うことができます。


また、Amazon RDSのリードレプリカとは参照専用のデータベースで、パフォーマンスを向上させるしくみです。
Elastic BeanstalkのマルチAZ構成によりEC2インスタンス群の可用性は向上しますが、リードレプリカは参照パフォーマンスに関する言及が要件にないため不適切です。可用性を向上させるにはリードレプリカよりもマルチAZの方が適切です。したがって、誤りです。

・フロントエンドにはAWS Lambdaを、バックエンドはAmazon S3を配置し、データベースはDynamoDBを利用する
AWS Lambdaはサーバーレスでプログラムのコードを実行できるサービスです。また、Amazon S3はストレージサービス、DynamoDBは大容量データの蓄積向けのデータベースサービスです。
バックエンドのEC2インスタンスをS3に置き換えられるかどうかは設問から読み取れません。
また、PostgreSQLはRDB(Relational Database:関係データベース)であり、DynamoDBはNoSQLのデータベースです。データ構造が異なるため、システムへの影響が大きい変更になります。したがって、誤りです。

・フロントエンドとバックエンドのEC2インスタンスをAWS Elastic BeanstalkのマルチAZ構成とし、PostgreSQLデータベースをAmazon RDSのマルチAZ構成にする
Elastic BeanstalkおよびRDSのマルチAZ構成により、EC2インスタンスとデータベースの可用性が向上します。正しい構成です。

・フロントエンドとバックエンドのEC2インスタンスをAuto Scalingグループに追加し、ELBの後ろに配置する
Auto Scalingはトラフィック量に応じて自動的にスケーリングするため、可用性が向上します。しかしデータベースの可用性に関する言及がないため、最も適切な選択肢とはいえません。したがって、誤りです。

参考

【AWS Elastic Beanstalk】
アプリケーションの実行環境を用意する際、通常はアプリケーションの動作に必要なスペックを持つハードウェア(物理マシンや仮想マシン)を用意し、OSやサーバー用のソフトウェアの導入、ネットワークの設定など、基盤となる設備や環境(インフラストラクチャ、インフラ)の準備から始まります。アプリケーションを開発して公開したいだけの開発者にとって環境構築は本来やるべき作業ではないため、最適な環境を用意するのが難しいなど障壁となりがちです。

AWS Elastic Beanstalk は、アプリケーションが動作する定番の構成を提供します。アプリケーションの開発者は、Elastic Beanstalkによって用意されている定番構成の中からアプリケーションの実行環境に適したものを選んで数クリックするだけで、環境(インフラ)を作成することができます。
EC2インスタンスは、OSはもちろん、Webサーバーソフトウェアやアプリケーションの実行環境などがインストール・設定された状態で提供されます。単一インスタンス・複数インスタンス(Multi-AZ)の構成を選択でき、関連する各種AWSサービス(ELBやS3、Auto Scalingグループなど)も設定済みのため、開発者はアプリケーションをアップロードするだけでデプロイ(実行環境への展開)を行うことができます。


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

環境が構築された後も、運用管理などはAWSによって行われます。例えば、EC2インスタンスのOSや導入されている各ソフトウェアへのアップデートも自動的に適用されるように設定できます。
また、Elastic Beanstalkで利用するリソースは自動スケーリング(Auto Scaling)に対応しており、利用状況に合わせた柔軟な構成変更を行うことができます。
なお、Elastic Beanstalk自体は無料で利用可能です。Elastic Beanstalkで構築した環境で動作するEC2インスタンスやS3バケットなど、利用したAWSリソースの分の料金がかかります。

以下はElastic Beanstalkの利用を始める際の入力画面です。

ユーザーはアプリケーションの名前と使用するプラットフォーム(実行環境)の情報のみで使い始めることができます。
さらに細かな設定を行いたい場合は「より多くのオプションの設定」から設定可能です。例えば負荷分散を考慮して複数のインスタンスを構築したい場合や、データベースサービスのRDSに関する設定を行うことができます。

Elastic Beanstalkで利用可能なプラットフォームには、Java、.NET、PHP、Ruby、Python、Node.js、Go、Dockerがあります。またWebサーバー用のソフトウェアにApacheやNginx、IISなどがあります。

●Dockerについて
Dockerとはコンテナ型の仮想化ソフトウェアです。コンテナ型の仮想化とは、1つのホストOS上に複数の独立した環境(コンテナ)を作成できる技術のことです。独立した環境ですから、例えばコンテナに障害が発生した場合でもホストOSには何の影響も与えません。
Dockerは、ミドルウェアの設定や各種環境をDockerfileというテキストファイルにコード化して管理できるため、同じ環境を配布したり別の環境に持ち出したりできる、などの特徴があります。
なお、Elastic Beanstalkでは単一(シングル)コンテナ、マルチコンテナの両方に対応しています。シングル・マルチとはEC2インスタンス上で作成できるコンテナの数を意味しており、シングルコンテナの場合は1インスタンスに1つのコンテナを、マルチコンテナの場合は1インスタンスに複数のコンテナを動作させることができます。

【環境構築の自動化サービス】
基盤となる環境(インフラ)を自動的に構築・管理するサービスには、「Elastic Beanstalk」のほかに「AWS CloudFormation」などがあります。

※詳細は「CloudFormation」の分野を参照してください。

Elastic Beanstalkを利用する大きな目的は「アプリケーションのデプロイを時間をかけずに行う」という点にあります。インフラやサーバーに関する知識がなくても定番の構成を利用するだけでアプリケーションを公開することができます。
CloudFormationではElastic Beanstalkよりも柔軟な構成を組むことができますが、その分インフラやサーバーに関する知識が必要になります。

上に戻る

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

公開日 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/アドレスの置き換えによって移行すれば瞬断程度のシステム影響に留まり 「システムへの影響が最も少ない」を満たせるという捉え方ですね。ご解説ありがとうございます。

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

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