助け合いフォーラム
このシステムをより可用性の高い構成に変更したいとき、システムへの影響が最も少ないものはどれか。
正解
フロントエンドとバックエンドの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）の設定が可能です。さらに、ELB、S3、Auto Scalingグループなど関連するAWSサービスも予め設定されているため、開発者はアプリケーションのコードをElastic Beanstalkにアップロードするだけでデプロイ（実行環境への展開）が可能となります。
[AWS Elastic Beanstalkイメージ図]
Elastic Beanstalkでは、状況に応じたデプロイ方式を選択することができます。例えば、新規の環境やテスト時などにはすべてのインスタンスに一括でデプロイを行えます。一方、稼働中のアプリケーションをバージョンアップするような場合には、一部のインスタンスから段階的にデプロイを行う方式（ローリングデプロイ）や、旧環境は稼働したまま新しい環境にバージョンアップしたアプリケーションをデプロイし、問題ないことが確認できたら旧環境とURLを入れ替える方式などがあります。段階的にデプロイする際に行うELBの切り替えや新規インスタンスの構築などは、Elastic Beanstalkがすべて自動で行います。アプリケーションの開発者にとってはシステムの複雑な設定や切り替え作業を行う必要がなく、開発したアプリケーションを安全に展開できます。
また、環境構築後の運用管理もAWSに委ねられます。具体的には、EC2インスタンスのOSやインストール済みソフトウェアの自動アップデートが可能です。Elastic Beanstalkが使用するリソースは自動スケーリング（Auto Scaling）にも対応しており、利用状況に応じて柔軟な構成調整が実行できます。
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
ご返信ありがとうございます。 要件が「より可用性の高い構成に変更したい」「システムへの影響が最も少ないものはどれか」でしたので 一番重要な要件はシステム影響であり、可能性向上は次点である(今より上がれば良い)と考えたのですがいかがでしょうか？