現在、単一のサーバーで実行されている JavaEE WebApp (JSP+Struts+Hibernate+MySQL) を入手しました。Web サイトの成長とパフォーマンスの問題のため、プロジェクトをいくつかのマシンにクラスタ化することにしました。Web サイトは、1 秒あたり 5000 件のリクエストを許容する必要があります。グーグルで検索したり、さまざまな資料を読んだりして、これを実行するためのいくつかの戦略を見つけました。
- Apache をフロントエンド ロード バランサおよびリバース プロキシとして使用し、いくつかの Tomcat インスタンスをそれぞれ別のマシンに配置し、最後に MySQL を実行する DB サーバーを使用します。Tomcat インスタンスは必要に応じて拡張できます。
- 使用エンギンクスフロントエンドのロードバランサおよびリバースプロキシとして機能します。残りは上記と同じです。
- 使用HAプロキシフロントエンドのロードバランサおよびリバースプロキシとして機能します。残りは上記と同じです。
前述のアプローチでは、すべてのトラフィックがフロントエンド ロード バランサー (Apache、Nginx、または HAProxy Server) を通過する必要があると思います。これにより、フロントエンド サーバーがボトルネックになり、SPOF にもなります。これは正しいですか? 単一のフロントエンド サーバーで、大規模な Web アプリケーションのすべてのトラフィックを許容できますか?
この問題を回避するために、私はちょっとした手作りの戦略を思いつきました:
- ログイン ページと認証アクションをフロントエンド サーバーに配置します (たとえば、myapp.com からアクセス可能)。ユーザーが正常にログインすると、バックエンド サーバーの 1 つ (srv1.myapp.com など) にリダイレクトされ、そこでアクティビティが続行されます。
それで、私は正しい道を歩んでいるのでしょうか?
これらのアプローチについてのご意見をお聞かせください。また、より良いアプローチを考えている場合には、ここでお知らせください。
答え1
ログイン ページをフロントエンド サーバーに配置してバックエンドにリダイレクトするのは、良い考えではありません。ユーザーがバックエンド サーバーをブックマークすると、不均等な分散が発生し、サーバーがダウンしても、同じセッションにいるユーザーは引き続きそのサーバーにアクセスしようとする可能性があります。
必要なのはアクティブ/パッシブ（ハートビート/ペースメーカー/IPフェイルオーバー/DNSフェイルオーバー) またはアクティブ/アクティブ (DNSラウンドロビン/ネットワーク負荷分散) フロントエンド サーバー。
アクティブ/パッシブでは、すべてのトラフィックが1つのフロントエンドサーバーにリダイレクトされ、2番目のサーバーが待機します（ホットスタンバイ）。最初のサーバーがダウンした場合は、何らかの方法でフェイルオーバーして（IP アドレスを再割り当てするか、DNS* を変更して）、2 番目のサーバーを指すようにします。
アクティブ/アクティブでは、2台（またはそれ以上）のサーバーが常にアクティブになり、イーサを使用してDNSラウンドロビンまたはIP/ネットワーク負荷分散2 つのサーバー間で負荷を (ほぼ) 均等に分散します。その後、2 つのサーバーはバックエンド サーバーに負荷を再び分散します。
アクティブ/アクティブは、ほとんどの大規模 Web アプリケーションで使用されている方法です (Youtube/Google/Twitter/Wordpress.com/Tumblr の DNS レコードを見ると、DNS ラウンドロビン用のサーバーに複数の IP があることがわかります)。
一度決断して実行したら、あとは解決策を選択するだけです。個人的にはNGINX とはしかし、人それぞれ好みはあります（HAプロキシ、イカ、チェロキー、ライトスピード、F5(ハードウェア)、シスコ(ハードウェア) およびその他無数のもの。
残念ながら、この種の質問に対しては、単に「これを行ってください」と言うことはできません。要件が何であるかによって大きく異なるからです。上記のキーワードをいくつか調べて、具体的な質問がある場合は遠慮なく質問してください。
*DNS ベースのフェイルオーバーは、可能であれば避けるべきです。一部のクライアントは TTL を超えて DNS をキャッシュするため、理想的とは言えません。
答え2
nginx についてはわかりませんが、haproxy が単一障害点になるのを防ぐために、アクティブ/パッシブ構成でいくつかの haproxy ロードバランサーをペアにすることができます。
商用ソリューションもありますが、何らかの理由で ServerFault ではあまり取り上げられていないようです。