手動デプロイメントとAmazon Elastic Beanstalk

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になります。Elastic Beanstalkと同じように、アプリケーションサーバーについて心配する必要がなく、WARファイルをアップロードするだけで、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にロールおよびアーカイブします。（確かに、この機能は現在少し弱いです。）

EC2専用（Nginx＆Gunicorn）とBeanstalk Environment（CentOS＆Apache2）の両方にアプリをデプロイしました。

私の観察：

• BeanStalkはPaasです。EC2インスタンス（IAAS）を手動で作成することは、すべてを最初から行うようなものですが、確実に制御できます。

• BeanStalkには、デフォルトでCentOSとApache（Httpd）が付属しています。専用インスタンスでOSを選択できます。

• 私にとって重要なこれらのこと、

  • Beanstalk環境で多くの504エラーが発生しました。
  • ログも表示されず、マシンにSSH接続できないため、BeanStalkサーバーがクラッシュしたときにデバッグするのが困難でした。これは非常に重要です。
  • Celery、Redis（別のポートを実行する必要がある）などのツールのインストール/設定。専用インスタンスでははるかに簡単です。

• 私の場合、いくつかのパッケージ（pandocなど）のインストールを実行するために、（Beanstalk）サーバーをスケールアップする必要がありました。これらのものは、Ubuntuでより簡単です。

• BeanStalkではスケーリングがはるかに簡単です。BeanStalkでは、サーバーの複製は簡単です。

• 私は両方のケースでマイクロを使用していました（専用＆Beanstalk）。専用のマイクロインスタンスの方が優れていると感じました。

• Beanstalkでの自動デプロイメント。それを自動化するためにスクリプトを作成する必要がありました。