EC2 インスタンスを手動で作成し、Tomcat サーバーをセットアップして典型的な Java Web アプリケーションにデプロイするよりも、Elastic Beanstalk を使用することで得られる利点は何ですか。負荷分散、監視、自動スケーリングだけが利点ですか?
データベースを使用する Web アプリケーションで、EC2 インスタンス自体にデータベースをインストールしたとします。自動スケーリングが行われると、新しく作成されたインスタンスでデータベースが作成されますか、それともマスター インスタンスで作成したデータベースにアクセスしますか?
負荷分散、監視、自動スケーリングなど、あなたが言及したすべてのことは間違いなく利点です.
ただし、次のように考える必要があります。真のサービスとしてのプラットフォーム(PAAS) では、アプリケーションをプラットフォームから分離することが目標です。開発者は、自分のアプリケーションについてのみ心配します。プラットフォームはあなたに「レンタル」されています。プラットフォームの「インスタンス」は、自動的に更新、管理、スケーリング、バランス調整などが行われます。WAR ファイルをアップロードするだけで機能します (少なくとも理論的には)。
EC2 自体は PAAS ではありません。IAAS ( Infrastructure as a Service ) に似ています。サーバー インスタンスの管理、ソフトウェアのインストール、更新の維持などを行う必要があります。
Elastic Beanstalk は PAAS システムです。App EngineやAzureも同様です。
真の PAAS システムでは、DBMS は Web アプリケーション サーバーとは別のコンポーネントです。理由は明らかです。アプリケーション サーバーに使用されているインスタンスに DBMS をインストールできない可能性があります。トラフィックに基づいてインスタンスが作成および破棄されるため、DBMS が失われるからです。いずれにせよ、DBMS とアプリケーション サーバーを同じマシン/インスタンスに配置することは、一般的には良い考えではありません。
PAAS システムでは、DBMS は別のサービスです。Amazon の場合、Amazon RDSになります。アプリケーション サーバーを気にする必要がなく、WAR ファイルをアップロードするだけの Elastic Beanstalk と同様に、RDS を使用すると、DBMS を気にする必要がなく、データベースをデプロイするだけです。
Elastic Beanstalk と RDS は、特にレイテンシーが非常に低い同じアベイラビリティーゾーンにデプロイされた場合に、非常にうまく連携します。
最後に、Elastic Beanstalk を使用しても、デプロイされたリソース (EC2 インスタンスとロード バランサー) 以外の費用はかかりません。ただし、RDS は安価ではなく、アプリケーション サーバーと DBMS の両方に単一の EC2 インスタンスを使用するよりも確実に高価になります。
Elastic Beanstalk は、ロード バランシング、モニタリング、自動スケーリング以上のことを行います。
1) アプリケーションのさまざまなバージョンを保存および管理することにより、アプリケーションのバージョンを管理し、アプリケーションのさまざまなバージョン間で簡単に切り替えられるようにします。
2) アプリケーションごとに「環境」の概念があり、各環境に異なるバージョンのアプリケーションをデプロイできます。これは、たとえば、QA 環境と DEV 環境を別々にセットアップしたい場合や、最初にビルドを簡単に DEV に展開し、QA チームが次のビルドの準備ができたときに QA に同じバージョンのアプリケーションを展開したい場合に便利です。
3) 重要なコンテナ設定プロパティ (Tomcat メモリ設定など) を Elastic Beanstalk コンソールと API に外部化します。このため、設定を簡単に保存して環境間でコピーできます。
4) コンソールを介してアプリケーション ログ ファイルを表示し、ログ ファイルを S3 に自動的にロールおよびアーカイブします。(確かに、この機能は現在少し弱いです。)