Amazon WebServicesのTomcatのJ2EE webappの設計に関する考慮事項

Question

私のプロジェクトでは、Amazonのクラウドに新しいJ2EEアプリケーションを導入しようとしています。 ElasticBeanstalkはTomcatアプリケーションをサポートしています。サーバー上のスタンドアロンの風袋とは異なるかもしれない前記のアプリを書くときに留意すべき設計上の考慮事項はありますか？

たとえば、サーバーは自動的に拡大/縮小されることを理解しています。これはクラスタのようなものですか？私たちのアプリケーションフレームワークはHttpSessionにステートを張りたいのですが、それは問題ですか？あるいは、自動的に拡大縮小すると言うと、メモリとCPUを意味するのでしょうか？

Answer 1

AWSの自動スケーリングは、サーバーを追加し、CPU/RAMを追加しないで行います。 CPU/RAMを手動で追加することもできますが、変更を加えるためにサーバーを1分間シャットダウンしてから、追加されたRAMを利用するようにサーバー上で実行されるソフトウェアを構成する必要があります。 。

Elastic Beanstalkは、基本的にAmazon EC2サーバー、Elastic Load Balancer、およびAuto Scaling Groupsの管理インターフェイスです。それはあなたのためにすべてを設定し、アプリケーションの新しいバージョンを簡単に導入する便利な方法を提供します。 Elastic Beanstalkは、Elastic Load Balancerの背後にEC2サーバーを作成し、Auto Scaling構成を使用してアプリケーションの負荷が増加するにつれてサーバーを追加します。ロードバランサがトラフィックを受信する準備ができたときにサーバーをロードバランサーに追加し、ロードバランサからサーバーを削除し、不要になったときに余分なサーバーを削除します。

Tomcatで動作するJavaアプリケーションの場合、水平方向のスケーリングをうまく処理するためのオプションがいくつかあります。 Load Balancerでスティッキー・セッションを使用可能にすると、特定のユーザーからのすべての要求が同じサーバーに送られ、HttpSessionがユーザーに関連付けられたままになります。これの主な問題は、サーバーがプールから削除された場合、HttpSessionが失われ、そのサーバーに「スタック」したユーザーがアプリケーションからログアウトする可能性があることです。これに対する解決策は、セッションを共有ロケーションに格納するようにTomcatインスタンスを設定することです。 ElastiCache（Redis）やDynamoDBのようなAWSサービスで動作するTomcatセッションストアの実装があります。 DynamoDBに慣れていない場合は、おそらくRedisの実装を使用することをお勧めします。

---

JavaアプリケーションをAWSに移行する際のもう1つの考慮点は、マルチキャストに依存するツールやライブラリを使用できないことです。マルチキャストを何も使用していないかもしれませんが、AWSに移行しなければならなかったすべてのJavaアプリケーションは、クラスタリングのためにマルチキャストに依存していました。別のクラスタリング方法を使用するように変更する必要がありました。

また、AWSへの移行が成功するには、VPC、プライベートIPとパブリックIP、セキュリティグループについて少しお読みください。これらのトピックを確実に理解することは、WebサーバーがDBサーバーやキャッシュサーバーと安全かつ効率的に通信できるように、ネットワークを設定する上で重要です。