%3F%20.png)
Google Cloud Platform で負荷分散環境を構成しています。ロード バランサの背後には、構成がほぼ同じ 2 台のサーバーがあります。1 台は米国東部地域に、もう 1 台は米国中部地域にあります。米国東部地域のサーバーは、CPU 使用率を平均 45% 程度に抑えて、負荷全体を簡単に処理します。中部地域のサーバーをロード バランサに追加すると、そのサーバーの CPU 使用率が急上昇し、ロード バランサに接続されている限り、使用率は 99% 前後に留まります。
追加の背景: サーバーは、ASP.NET Umbraco 7 Web サイトを実行している Windows サーバーです。また、MariaDB を実行しているデータベース サーバーが 2 つあり、1 つはマスター、もう 1 つはレプリケーション スレーブです。東部サーバーはマスター (東部地域) に接続します。中央サーバーはスレーブ (中央地域) に接続します。
中央サーバーがなぜ苦戦しているのか説明できる人はいますか?
私が試したこと:
- 中央サーバーの負荷をいくらか軽減できるのではないかと考え、バランス調整パラメータを微調整して、より多くのリクエストが東部サーバーに送信されるよう試みました。
- 中央サーバーを東部地域のマスターデータベースに接続してみました。
- どこかに破損があり、問題が発生した場合に備えて、サイト ファイルの最新のコピーをアップロードしました。
- 私は Google の (自動化された) アドバイスに従って、RAM を増やしました (RAM はもともとそれほど負荷がかかっておらず、使用率が 50% を超えることはありませんでした)。
- 中央リージョンでまったく新しいサーバーを立ち上げ、最初から構成してみました。同じパフォーマンスの問題が発生しました。
現時点で私が考えられる最善のことは、サーバーがヘルス チェッカーの ping に追いつくのに苦労しているということだが、ではなぜ他のサーバーは苦労しないのだろうか? 別の地域にあることが問題の原因となっているのだろうか?
まだ試していないこと。これらの優先順位を自由に提案してください。
- 中央サーバーを別の地域に移動します。
- 中央サーバーを他のサーバーと並行して東部地域に移動します。
- CPUの追加
最後の方法は根本的な問題を見つけるのではなく、症状を治療しているようなので避けるようにしています。
答え1
まず、Google L7 ロードバランサは、リクエスト元に最も近いバックエンドにトラフィックをルーティングしようとします。この場合、東海岸からのリクエストはすべて us-east バックエンドに送られ、北米からのその他のリクエストはすべて us-central に送られます。これは想定された動作です。
L7LB トラフィックの分散を確認するには、管理コンソール > ネットワーク サービス > 負荷分散に移動し、「詳細メニュー」をクリックします。ここから「バックエンド サービス」に移動し、LB バックエンドをクリックします。これで、バックエンド内のインスタンスごとの RPS を表示できます。2 つの別々のバックエンドを使用している場合は、それぞれを個別に確認できます。
us-central サーバーのボリュームがはるかに大きい場合、CPU 使用率は高くなります。
ヘルスチェックに関しては、チェックの頻度を完全に制御できます (理想的には、us-east サーバーの頻度と一致する必要があります)。ヘルスチェックは、Compute Engine > ヘルスチェック、またはロードバランサの詳細画面から確認できます。
現時点ではメモリが問題なので、メモリを増やさずに CPU を増やすことはいつでも可能です。ただし、それでは症状は解決されるだけで、問題は解決されません。
上記は、Google Cloud Platform 側で確認すべき事項について説明しています。両方のインスタンスへのトラフィックがほぼ同じである場合は、サーバーのパフォーマンスを監視して、CPU 使用率が最大になっている原因を調べ、実際に IIS によるものであり、別のアプリケーションによるものではないことを確認します。