.NET 3.5 Web サーバーの負荷分散の要件

Question

実際に単一サーバー環境から 10 台の負荷分散されたクラスターに移行する場合、それは私にとってすぐに警鐘を鳴らします。皆さんがすでに解決していることを願う多くの疑問がありますが、とにかくそれらを指摘し、一般的な考慮事項をいくつか示します。

10 という数字にどうやってたどり着いたのですか? 2 または 3 にスケールアップして、必要に応じてさらに追加しないのはなぜですか?

そもそもなぜ負荷分散を行うのでしょうか? たとえば、高負荷、高可用性、またはその両方を目指すのでしょうか? 差し迫ったニーズがあるのでしょうか、それとも予測されるニーズなのでしょうか?

現在負荷がかかっていて、それを解決するために拡張しようとしている場合、私が尋ねる大きな質問の 1 つは、実際にボトルネックを特定したかどうかです。セッション状態に .NET と SQL を使用しているとおっしゃっていますので、SQL ベースのアプリケーションも使用していると思います。SQL サーバーのバランスも調整していますか? SQL サーバーは、現在の 10 倍の接続を処理できますか?

可用性を追求する場合、他のすべての障害点を考慮しましたか? ロードバランサーに冗長性がありますか? データベースサーバーに冗長性がありますか? インターネットアップリンクに冗長性がありますか (単一ケーブル、単一スイッチなど、すべてのポイントを検討してください)? 可用性に関しては、最も弱いリンクと同じくらいしか安全ではありません。フロントエンド Web サーバーが 10 台、または 100 台あっても、データベースサーバーが 1 台しかなく、それがダウンした場合は意味がありません。

多くの場合、ボトルネックとなるのはデータベースサーバーです。その場合、フロントエンドがいくつあっても問題にはなりません。

SSL を使用している場合、ロードバランサーが通常動作する 2 つの一般的なモードがあり、これらは SSL の動作に影響します。
- レイヤー 4: これは TCP レベルです。SSL は各サーバーによって処理されるため、各サーバーに SSL 証明書をインストールする必要があります。
- レイヤー 7: これはアプリケーションレベルであり、リバースプロキシとも呼ばれます。ロードバランサーは HTTP セッションを処理し、アプリケーションサーバーへの 2 番目の接続を作成します。このモードでは、SSL 証明書はバランサーにのみインストールされ、アプリケーションサーバーへの接続は通常 HTTP です。これは「SSL オフロード」と呼ばれることもあり、ロードバランサーが強力で、アプリケーションサーバーで SSL の暗号化オーバーヘッドを処理したくない場合 (たとえば、アプリケーションが CPU を集中的に使用する) に便利です。
バランサーが、サーバーがダウンしたときにローテーションから外すように設定されていることを確認し、この機能をテストします。他のサーバーに影響を与えることなくサーバーをダウンできるはずです。PING と HTTP と応答時間のチェックに注意してください。(PING は HTTP が応答していることを意味するものではありません)
環境の負荷テストを実行します。完全に負荷をかけることはできないかもしれませんが、少なくとも 2 台のサーバー (バランサー内の 2 台のみ) に負荷をかけることができるはずです。
ステージング環境を実行します。これは 10 台のサーバーではないかもしれませんが、展開テスト用に実稼働システムを複製するには十分なはずです。
自動化されたデプロイメントスクリプトを用意し、ソース管理と構成管理を厳格に実施します。理想的には、すべて (構成ファイルを含む) がソースコントロールシステムにあり、インストーラー/スクリプトに至るまですべてを作成するための自動ビルドがあることを意味します。
外部向けサイトとすべての内部サーバーの両方を監視するツールを入手してください。サーバーがダウンしても、外部から見ると実際には何も変わりませんが、とにかくサーバーの状態を把握して修復する必要があります。パフォーマンスや可用性に問題が発生し始めた場合、3 台のサーバーが 1 か月間ダウンしていて、残りのサーバーが余分な負荷に苦しんでいるという状況は避けたいものです。

Answer 1