m.large ec2 サーバーでホストされている Java アプリケーションがあり、将来的には多数の計算を実行する必要があります。正確には、1 日あたり 1,000 万回の計算が必要であり、各ユニットの計算には約 100 ミリ秒が必要です。計算のタイプは次のとおりです。 Write Once、Read Manyとは異なり、Javaコードで複数の処理を行ってからdbにダンプします。負荷を分散するための最良の方法はどれですか? 私たちが行ってきたオプションは、負荷が増加するにつれてスクリプトによってec2サーバーをインスタンス化することですが、それを実装する前に、専門家からの確かな提案が必要です. 親切に提案を提供してください。
2 に答える
これはあなたにとって正しい答えではないかもしれませんが、確かに検討する価値があります. アプリケーションのメトリックとしきい値を定義する必要があります。
負荷の増加に合わせてスクリプトで ec2 サーバーをインスタンス化する
上記のステートメントでは、「ロード」の意味を定義する必要がありますか? 負荷が「増加した」と判断するために、負荷が超えるべきしきい値は何ですか?
この情報を手元に用意したら、AWS クラウドウォッチを使用してこれらのメトリクスとしきい値を監視できるかどうかを確認してください。はいの場合は、クラウドウォッチ アラームによって「負荷が増加した」と通知されるとすぐに、自動呼び出しが新しいインスタンスをスピンアップする自動呼び出しグループを作成できます。
Cloudwatch がメトリクスをサポートしていないことがわかった場合は、独自のカスタム メトリクスを作成し、cloudwatch で監視します。カスタム Cloudwatch メトリクスのドキュメントについては、ここをクリックしてください。
カスタムメトリクスを取得したら、自動スケーリングとクラウドウォッチアラームを再度統合して、負荷が増加したときに新しい EC2 インスタンスの作成を管理します。
つまり、AWS クラウドウォッチ アラームと AWS 自動スケーリングについて調べてください。
このプロセス全体は、ソフトウェア スタックと共に EC2 インスタンスを作成する完全に自動化された方法があることを前提としています。アプリケーション スタックを使用して事前にベイクされた AMI を作成することも、Opscode Chef などのツールを使用してその場でアプリケーション スタックをインストールすることもできます。
マシンを手動で作成してスケーリングする代わりに、Platform-as-a-Service (PaaS) を使用します。これは、長期的な使用に対してより柔軟であり、必要なスクリプトも少なくて済みます。ここに PaaS の推奨事項がいくつかあります: PaaS プロバイダーの推奨事項を探しています。
免責事項: Cloudifyオープンソース PaaS スタックの開発者である Gigaspaces で働いています。