5

私の仕事では、いくつかの既存の Enterprise Java アプリケーションを AWS に移行する必要があります。私は aws.amazon.com の多くのページに目を通し、十分にグーグルもしました。また、stackoverflow で関連するすべての質問を調べてみました。これらすべてにより、多くのことが明らかになりましたが、私はまだ混乱しています。アプリケーション構造は次のとおりです。

  1. これは、Spring MVC をプレゼンテーション レイヤーとして使用し、ビジネスおよびデータ ロジックを処理するためのプレーンな Java インターフェイスおよびクラスを使用する Spring ベースのアプリケーションです。
  2. MySQL は永続化のために使用されます。

したがって、アプリケーション アーキテクチャは十分に単純です。ただし、問題は、このアプリケーションの多くのインスタンスをデプロイする必要があることです。この数は現在 15 で、30 を超える可能性があります。もう 1 つのポイントは、これらすべてのインスタンスが共通のデータベースを共有していることです。

AWS に移行することで達成する必要があるのは次のとおりです。

  1. アプリケーションの耐障害性が向上します。最近、専用ホスティングでサーバー/電源障害に直面し、数時間のダウンタイムが発生しました。
  2. 応答時間とスループットに関して、アプリケーションのすべてのインスタンスのパフォーマンスが向上します。
  3. MySQL の耐障害性が向上しました。最近、一部のハードウェア (ハード ドライブ) が原因で、サーバーの 1 つでアプリケーション インスタンスがダウンし、基本的に MySQL が予期せず停止しました。ハード ドライブのファイル システム全体が読み取り専用になり、そのサーバーでホストされているアプリケーション インスタンスの誤動作が発生しました。
  4. インフラストラクチャ管理の総コストとオーバーヘッドを明らかに削減します。

これまでAWSインフラストラクチャを理解できる限り、セットアップのためにAWSで必要なものは次のとおりです。

  1. Tomcat と MySQL がインストールされた EBS ベースの LINUX AMI の 4 つのインスタンス。それぞれが約 10 のアプリケーション インスタンスをホストします。
  2. これら 4 つのインスタンスのそれぞれに対して、フォールト トレランス用に 1 つのインスタンスが必要であり、合計で 8 つのインスタンスが必要になると推測しています。
  3. すべてのサーバー インスタンスには、約 160 GB の EBS があります。
  4. 4 つのエラスティック IP
  5. 4 つのエラスティック ロード バランサー
  6. スナップショットなどのその他のもの

ここに私の質問があります：

  1. EBS が AWS によって自動的にバックアップされ、ハードウェア障害が発生した場合に新しい EBS に同じデータを提供することを考えると、メイン サーバー インスタンスごとに追加のサーバー インスタンス (フォールト トレランス用) が本当に必要ですか?

  2. 上記のシナリオで、すべてのサーバー インスタンス (4x2) 間でデータベースを共有するにはどうすればよいですか? 私が見ている 1 つのオプションは、これらのサーバー インスタンス間で MySQL クラスタリングを実装することです。たとえば、MySQL クラスターに 1 つの管理ノード、3 つの SQL ノード、および 4 つのデータ ノードが含まれているとします。ただし、この場合、クラスターを維持することは私たちにとって追加のオーバーヘッドになり、インフラストラクチャ管理を取り除きたいため、これは受け入れられない可能性があります.

  3. データベースの代わりに RDS を使用し、すべてのサーバーインスタンス (4x2) から MySQL インスタンスを削除する必要がありますか? はいの場合、EC2 インスタンスに加えて RDS インスタンスを購入する必要がありますか (RDS 用に別のインスタンスを購入する必要がある場合、インフラストラクチャ全体のコストは少なくとも 75% 増加すると思います)、または RDS インスタンスはコンピューティング ユニットも提供します。アプリケーション開発のために、アプリケーション展開のためのインスタンスの総数を減らしますか?

  4. RDS 実装の場合、EBS ベースの EC2 インスタンスが本当に必要ですか? RDS インスタンスを配置した EC2 インスタンスから EBS 要件を取り除くことができれば、総コストを削減できます。

問題を特定するのが明確でなく、任意の点についてさらに明確にする必要がある場合はお知らせください。

4

1 に答える 1

3

私はインフラストラクチャの専門家ではありませんが、AWS についてある程度の経験があるため、少なくともいくつかの質問にお答えできれば幸いです。私のバックグラウンドでは、インフラストラクチャのサイジングについてアドバイスすることはできませんが、インフラの種類についてアドバイスすることはできます。
まず第一に、私は間違いなく EBS を選びます。アプリケーション サーバーから物理的に分離されているだけでなく、高い信頼性と可用性も備えています。私はそれが私を数回救ったと言えます。サイジングについては何も言わないと言いましたが、余分な 4 つの「フォールト トレランス」インスタンスは必要ないと思いますが、念のため、トラフィックをオフにするために 2 つのインスタンスを用意しておくこともできます。

DB に関しては、必ず RDS for MySQL (http://aws.amazon.com/rds/mysql/) を使用する必要があります。事前構成されたノード、自動パッチ、自動バックアップ、自動レプリケーション、ワンクリック スケーリングを (IMHO) 低価格で提供します。これらの機能はすべて、すぐに使用できる MySQL 用の準備が整っています。メトリクスとモニタリングも使用できます。すべて含まれています。RDS はコンピューティング ユニットを提供しませんが、AWS でそれらを分離しておくことをお勧めします。4 つの EC2 Tomcat ノード + 2 つの RDS ノードをセットアップすることもできます。それはちょうどサイズの問題です:)

Amazon Elastic Load Balancing について既に読んだことがある場合は、ソリューションに最適です。各 ELB ノードにいくつかの EC2 ノードを接続して、負荷分散を忘れることができます。それだけで機能し、必要に応じてスティッキー セッションを構成することもできます。いくつの ELB ノードを選択する必要があるかはわかりませんが、1 つの問題に注意してください。同じ地理的リージョン (米国東海岸など) からの EC2 ノードのみを同じ ELB に追加できます。たとえば、西海岸の Tomcat と東海岸の別の Tomcat の間でトラフィックのバランスを取ることはできません。ノードを複数のリージョンに分散することを選択した場合は、Amazon 以外の別の LB ソリューションを用意する必要があります。

私の最後のアドバイスは、ELB + EBS ベースの EC2 + RDS を使用することです。監視、展開、およびメンテナンスが大幅に簡素化され、コストが大幅に削減される傾向があります。必要な各種類のノードの数については、おそらくより認識しているでしょうが、見落とすことを恐れないでください。AWS でインフラストラクチャをアップスケールまたはダウンスケールするのは非常に簡単だからです。

于 2011-08-28T14:20:35.970 に答える