助け合いフォーラム
このシステムをより可用性の高い構成に変更したいとき、システムへの影響が最も少ないものはどれか。
正解
フロントエンドとバックエンドの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はトラフィック量に応じて自動的にスケーリングするため、可用性が向上します。しかしデータベースの可用性に関する言及がないため、最も適切な選択肢とはいえません。したがって、誤りです。
参考
アプリケーションの実行環境を用意する際、通常はアプリケーションの動作に必要なスペックを持つハードウェア（物理マシンや仮想マシン）を用意し、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よりも柔軟な構成を組むことができますが、その分インフラやサーバーに関する知識が必要になります。
システムへの影響について
以下問題についてです。
問題：
あるシステムは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に置き換える点もありシステムへの影響が最も少ないとは思えなかったのですが、どのように考えるべきでしょうか？
「システムへの影響が最も少ないものはどれか」の前に「可用性の高い構成に変更したいとき」があります。
可用性の高い構成に変更できる方法の中から、システムへの影響が最も少ないものを選択する必要があります。
「フロントエンドとバックエンドのEC2インスタンスをAuto Scalingグループに追加し、ELBの後ろに配置する」は、誤答解説にあるとおりデータベースの可用性についての言及がないので、そもそも「可用性の高い構成にする」という要件を満たしていません。
コメント
参考に以下の記述があるので「システムへの影響」は最も少ないと言っても問題ないと思うのですが、どうでしょうか？
一方、稼働中のアプリケーションをバージョンアップするような場合には、一部のインスタンスから段階的にデプロイを行う方式（ローリングデプロイ）や、旧環境は稼働したまま新しい環境にバージョンアップしたアプリケーションをデプロイし、問題ないことが確認できたら旧環境とURLを入れ替える方式などがあります。段階的にデプロイする際に行うELBの切り替えや新規インスタンスの構築などは、Elastic Beanstalkがすべて自動で行います。アプリケーションの開発者にとってはシステムの複雑な設定や切り替え作業を行う必要がなく、開発したアプリケーションを安全に展開できます。
コメント
この投稿に対して返信しませんか？
s shia125
2024/02/29 21:21
ご返信ありがとうございます。 要件が「より可用性の高い構成に変更したい」「システムへの影響が最も少ないものはどれか」でしたので 一番重要な要件はシステム影響であり、可能性向上は次点である(今より上がれば良い)と考えたのですがいかがでしょうか？