デスクトップ プログラムと比較すると、サーバー プログラムが依存する基本ソフトウェアは、オペレーティング システムとプログラミング言語だけでなく、さらに 2 つのカテゴリにも依存します。
負荷平衡;
データベースまたはその他の形式のストレージ (DB/ストレージ)。
なぜ負荷分散が必要なのでしょうか?今日はトラフィックのスケジューリングと負荷分散について説明します。
前回の講義では、次のようなサーバー プログラムのアーキテクチャ図を描きました。
「トラフィックスケジューリング」とは何ですか?まず、インスタンス (プロセス) を実行するいくつかの一般的なサーバー プログラムに関連する概念を理解する必要があります。
接続数。
IOPS；
トラフィック、受信トラフィックと送信トラフィック。
基本的なサーバー プログラムのサービス要求は、通常、要求パケット (Request) と応答パケット (Response) で構成されていることがわかっています。この質疑応答は完全なサービスです。
接続数は同時実行数とも呼ばれ、サービス内で同時に行われるリクエストの数を指します。つまり、リクエスト (Request) を送信したが、まだ応答 (Response) を受信していないリクエストの数です。
IOPS は、1 秒あたりに完了するリクエスト (1 つの質問と 1 つの回答) の平均数を指します。サーバープログラムの効率を判断するために使用できます。
トラフィックは、受信トラフィックと送信トラフィックに分けられます。インバウンドトラフィックは次のように推定できます。
1 秒あたりに受信されたリクエスト パケット (リクエスト) の平均数 * リクエスト パケットの平均サイズ。
同様に、送信トラフィックは次のように推定できます。
1 秒あたりに返される応答パケット (Response) の平均数 * 応答パケットの平均サイズ。
無効なリクエスト パケットの存在、つまり質問があっても答えがないことを無視した場合 (ただし、実際の運用環境ではいくつかあるはずです)、1 秒あたりに受信されるリクエスト パケット (リクエスト) の平均数と、1 秒あたりに返される平均応答数を求めます。パッケージ数（レスポンス）はIOPSです。したがって：
インバウンドトラフィック ≈ IOPS * 平均リクエストパケットサイズ
アウトバウンドトラフィック ≈ IOPS * 平均応答パケットサイズ
いわゆるトラフィック スケジューリングは、特定の戦略に従って、大量の顧客の同時要求パケットをさまざまなサーバー プログラム インスタンスに割り当てるプロセスです。
トラフィックのスケジュールを設定するにはさまざまな方法があります。
DNSトラフィックのスケジューリング
最も基本的な方法は、次の図に示すように、DNS を介する方法です。
ドメイン名は DNS を通じて複数の IP に解決され、各 IP は異なるサーバー プログラム インスタンスに対応します。これでトラフィックのスケジュール設定が完了します。ここでは従来の負荷分散（Load Balance）ソフトウェアを使用せず、トラフィックのスケジューリングを完了しました。
では、このアプローチの欠点は何でしょうか?
最初の問題は、アップグレードの不便さです。
IP1 に対応するサーバー プログラム インスタンスをアップグレードするには、まず IP1 を DNS 解決から削除する必要があります。IP1 インスタンスにトラフィックがなくなったら、インスタンスをアップグレードし、最後に IP1 を DNS 解決に追加し直します。
問題ないようですが、DNS 解決がバッファリングされていることを忘れないでください。 DNS 解決から IP1 を削除しました。TTL を 15 分に指定したとしても、1 日経ってもまばらなユーザー リクエストが IP1 インスタンスに送信される可能性があります。
したがって、DNS 解決の調整によるアップグレードには大きな不確実性があり、インスタンスを完成させるまでのアップグレード サイクルは非常に長くなります。
1 つのインスタンスのアップグレードに 1 日かかり、合計 10 個のインスタンスがある場合、10 日かかります。これは誇張です。
2 番目の問題は、不均衡なトラフィック スケジューリングです。
DNS サーバーは、特定のトラフィック バランシングを行うことができます。たとえば、最初のドメイン名解決では最初に IP1 が返され、2 番目のドメイン名解決では IP2 が優先されるなど、ドメイン名解決に基づいてバランスのとれた方法で IP リストを返すことができます。
ただし、ドメイン名解決のバランスは、実際のトラフィックのバランスを表すものではありません。
一方で、すべてのユーザー要求が DNS 解決に対応するわけではなく、クライアントには独自のキャッシュがあります。一方で、DNS 解決自体にもキャッシュの層があり、DNS サーバーの割合はすでに非常に小さくなっています。
したがって、このような状況では、ドメイン名解決に基づくトラフィックのスケジューリングとバランス調整は非常に大雑把で、実際の結果は制御不能になります。
では、トラフィック スケジュールの真のバランスを保つにはどうすればよいでしょうか?
ネットワーク層の負荷分散
1 つ目のアプローチは、ネットワーク層 (IP 層) で負荷分散を実行することです。
Zhang Wensong 博士が立ち上げた負荷分散ソフトウェア LVS (Linux Virtual Server) は、この層で動作します。 LVSを代表として動作原理を紹介しましょう。
LVS は 3 つのスケジューリング モードをサポートします。
VS/NAT: スケジューリングは、ネットワーク アドレス変換 (NAT) テクノロジによって行われます。リクエストとレスポンスの両方がスケジューラを通じて転送されるため、パフォーマンスが最悪になります。
VS/TUN: IP トンネル経由でリクエスト メッセージを実サーバーに転送し、実サーバーがクライアントに直接応答を返すため、スケジューラはリクエスト メッセージのみを処理します。このアプローチは、VS/NAT よりもはるかに優れたパフォーマンスを発揮します。
VS/DR: リクエストメッセージのMACアドレスを書き換えることにより、リクエストが実サーバに送信され、実サーバはクライアントに直接レスポンスを返します。 VS/TUN と比較して、このアプローチは IP トンネルのオーバーヘッドを削減し、最高のパフォーマンスを実現します。
VS/DR技術の導入に注力しています。
図１に示すように、クライアントの IP と MAC を CIP と CMAC とします。
ステップ 1: クライアントが要求を開始します。その IP パケットでは、送信元 IP はユーザーの CIP、宛先 IP は VIP、送信元 MAC アドレスは CMAC、宛先 MAC アドレスは DMAC です。
ステップ 2、要求パケットは LVS スケジューラ (ディレクター サーバー) に到着します。送信元 IP と宛先 IP は変更せず、宛先 MAC アドレスのみを RMAC に変更して、リクエストを実際のビジネス サーバー インスタンス RS (Real Server) に転送します。
ステップ 3: RS はデータ パケットを受信して処理し、クライアントに直接応答を送信します。
ここでの重要なトリックは、VIP が複数のマシンにバインドされているため、これを仮想 IP と呼ぶことです。これは、LVS スケジューラ (ディレクター サーバー) とすべてのビジネス サーバー インスタンス RS (リアル サーバー) の両方にバインドされます。
もちろん、ここで非常に重要な詳細は、VIP に対応する MAC アドレスに対する ARP ブロードキャスト クエリが何を取得するかということです。答えはもちろん LVS スケジューラ (ディレクター サーバー) です。リアル ビジネス サーバー インスタンス RS (リアル サーバー) では、VIP を lo インターフェイスにバインドし、ARP リクエストを抑制して、IP の競合を回避します。
LVS はネットワーク層の最下部で負荷分散を行い、他の負荷分散技術と比較して、高い汎用性と高いパフォーマンスの利点を備えています。
しかし、いくつかの欠点もあります。特定のビジネス サーバー インスタンス RS がハングしたが、LVS スケジューラー (ディレクター サーバー) がそれをまだ感知していない場合、この短期間にインスタンスに転送されたリクエストは失敗します。このような障害は、クライアントの再試行に頼ることによってのみ解決できます。
アプリケーション層の負荷分散
このリクエストの失敗を回避する方法はありますか?
できる。答えは「サーバーの再試行」です。
サーバー側で再試行するにはどうすればよいですか?アプリケーション層の負荷分散。アプリケーション ゲートウェイと呼ばれることもあります。
HTTP プロトコルは、最も広く使用されているアプリケーション層プロトコルです。現在のアプリケーション ゲートウェイのほとんどは HTTP アプリケーション ゲートウェイです。
Nginx と Apache は、最もよく知られた HTTP アプリケーション ゲートウェイです。 HTTP アプリケーション ゲートウェイは、アプリケーション層プロトコルの詳細を認識しているため、多くの場合非常に強力です。これについては後ほど詳しく説明しますが、今日はまず負荷分散 (Load Balance) について説明します。
HTTPゲートウェイは、HTTPリクエスト(Request)を受信すると、一定のスケジューリングアルゴリズムに従ってバックエンドの実業務サーバインスタンスRS(Real Server)にリクエストを転送し、RSからのレスポンス(Response)を受信した後、それを転送します。クライアントへ。
プロセス全体のロジックは非常にシンプルで、再試行も非常に簡単です。
RS インスタンスがダウンしていることを検出した後、HTTP ゲートウェイは同じ HTTP リクエスト (Request) を他の RS インスタンスに再送信できます。
もちろん、重要な点は、再試行をサポートするには、HTTP リクエスト (Request) を保存する必要があるということです。 HTTP リクエストを保存せずに再試行することは可能ですが、サポートできるのは、ビジネス インスタンスが完全に失敗し、HTTP リクエストのバイトが送信されないシナリオのみです。ただし、停電や異常クラッシュなどの状況では、この前提を満たさない継続的なリクエストが多数存在することは明らかであり、再試行することはできません。
ほとんどの HTTP リクエストは大きくないため、メモリに直接保存でき、ストレージ コストも高くありません。ただし、ファイル アップロード リクエストの場合、リクエスト パッケージにファイル コンテンツが含まれるため、HTTP リクエストを保存するために一時ファイルまたはその他の手段に依存する必要がある場合があります。
エレガントなアップグレード
負荷分散を使用すると、トラフィックのバランスの取れたスケジューリングが実現できるだけでなく、ビジネス サーバーのアップグレードもさらに便利になります。
フロントエンドが LVS などのネットワーク層負荷分散であるシナリオの場合、アップグレードの中心的な手順は次のとおりです。
アップグレード システムは、アップグレードするビジネス サーバー (リアル サーバー) インスタンスをオフラインにするように LVS スケジューラ (ディレクター サーバー) に通知します。
LVS スケジューラ (ディレクター サーバー) は、RS セットからインスタンスを削除し、新しいトラフィックがそのインスタンスにスケジュールされないようにします。
アップグレード システムは、アップグレードされる RS インスタンスに終了を通知します。
アップグレードされる RS インスタンスは、保留中のリクエストをすべて処理した後、アクティブに終了します。
システムをアップグレードして RS インスタンスを新しいバージョンに更新し、再起動します。
アップグレード システムは、RS インスタンスを RS コレクションに追加して戻し、スケジューリングに参加させます。
フロントエンドが HTTP アプリケーション ゲートウェイである負荷分散シナリオの場合、アップグレード プロセスはより簡単になります。
アップグレード システムは、アップグレードされたビジネス サーバー (リアル サーバー) インスタンスに終了するように通知します。
アップグレードされる RS インスタンスは終了状態に入ります。新しいリクエストが到着すると、それらは直接拒否され (特別なステータス コードが返されます)、すべての処理リクエストが処理された後、RS インスタンスはアクティブに終了します。
システムをアップグレードして RS インスタンスを新しいバージョンに更新し、再起動します。
HTTP アプリケーション ゲートウェイがリトライをサポートしているため、ビジネス サーバーのアップグレード プロセスが大幅に簡素化されていることがわかります。
結論
今日はトラフィックのスケジューリングから始めて、いくつかの典型的なスケジューリング方法と負荷分散方法について説明しました。
トラフィック スケジューリングの観点から見ると、負荷分散の最大の価値は、複数のビジネス サーバーの負荷のバランスをとることです。ここでの暗黙の前提は、負荷分散ソフトウェアは多くの場合、ビジネス サーバーよりも圧力に対する耐性がはるかに高いということです。
これは次の点で明らかです: まず、ロード バランシング インスタンスの数/ビジネス サーバー インスタンスの数は 1 よりはるかに少ないことがよくあります。第 2 に、DNS のスケジューリングが不均衡であるため、ロード バランシングのさまざまなインスタンスに対する負荷が均等ではなく、一部のインスタンスでは大きなプレッシャーにさらされることになる。
もちろん、ロード バランシングの価値は、トラフィックのバランスのとれたスケジューリングだけではなく、ビジネス サーバーを適切にアップグレードできるようにすることも可能になります。