nginx のロードバランシングとリバースプロキシの説明

負荷分散

負荷分散とは、複数のサーバーを対称的に組み合わせてサーバー セットを作成するプロセスです。各サーバーは同等のステータスを持ち、他のサーバーの支援なしに独立してサービスを提供できます。一定の負荷分散技術により、外部から送信されたリクエストは対称構造のサーバーに均等に分散され、リクエストを受信したサーバーはユーザーのリクエストに独立して応答します。負荷分散により、サービス要求をサーバー アレイに均等に分散し、データを迅速に取得し、多数の同時アクセス サービスの問題を解決できます。

負荷分散分類

1. DNS 負荷分散

DNS サーバーで複数の A レコードを設定します。これらの A レコードに対応するサーバーがクラスターを形成します。

アドバンテージ：

• 1. 使いやすい: 負荷分散作業はDNSサーバーによって処理されるため、負荷分散サーバーのメンテナンスの手間が省けます。
• 2. パフォーマンスの向上: アドレスベースのドメイン名解決をサポートし、ユーザーに最も近いサーバー アドレスに解決できるため、アクセスが高速化され、パフォーマンスが向上します。

欠点:

• 1. 可用性が低い: DNS 解決はマルチレベルの解決です。DNS を追加/変更した後、解決時間が長くなります。解決プロセス中、ユーザーは Web サイトにアクセスできなくなります。
• 2. スケーラビリティが低い: DNS 負荷分散の制御はドメイン名プロバイダーが担当しており、それ以上の改善や拡張は不可能です。
• 3. 保守性が低い: サーバーの現在の実行状態を反映できない、サポートされるアルゴリズムが少ない、サーバー間の違いを区別できない (システムとサーバーの状態に基づいて負荷を判断できない)

2. IP負荷分散

ネットワーク層では、要求ターゲット アドレスを変更することで負荷分散が行われます。ユーザー要求データ パケットが負荷分散サーバーに到着すると、負荷分散サーバーはオペレーティング システム カーネル プロセスでネットワーク データ パケットを取得し、負荷分散アルゴリズムに基づいて実サーバー アドレスを取得し、要求ターゲット アドレスを取得した実 IP アドレスに変更します。
実サーバーが処理を完了すると、対応するデータ パケットが負荷分散サーバーに返され、負荷分散サーバーはデータ パケットの送信元アドレスを自身の IP アドレスに変更して、ユーザーのブラウザーに送信します。

IP ロード バランシングでは、実際の物理サーバーがロード バランシング サーバーに戻ります。方法は 2 つあります。

• （１）負荷分散サーバは、送信元アドレスを変更すると同時に宛先IPアドレスも変更する。データ パケットの送信元アドレスを自身のディスクに設定します。これを送信元アドレス変換 (SNAT) と呼びます。
• （２）負荷分散サーバは、実物理サーバクラスタのゲートウェイサーバとしても機能します。

アドバンテージ：

• （１）データ配信はカーネルプロセス内で完結するため、アプリケーション層での配信よりも性能が優れている。

欠点:

• （１）すべての要求応答は負荷分散サーバを通過する必要があり、クラスタの最大スループットは負荷分散サーバのネットワークカード帯域幅によって制限されます。

3. リンク層の負荷分散

通信プロトコルのデータリンク層で MAC アドレスを変更して、負荷分散を実行します。
データ配信では IP アドレスは変更されません。つまり、ターゲットの MAC アドレスを変更し、実際の物理サーバー クラスター内のすべてのマシンの仮想 IP アドレスを負荷分散サーバーの IP アドレスと一致するように構成することで、データ パケットの送信元アドレスと宛先アドレスを変更せずにデータ配信の目的を達成します。

実際の処理サーバーの IP はデータ要求の宛先 IP と一致しており、負荷分散サーバーによる変換は必要ありません。応答データ パケットはユーザーのブラウザーに直接返すことができるため、負荷分散サーバーのネットワーク カード帯域幅がボトルネックになることを防止できます。ダイレクトルーティングモード（DRモード）とも呼ばれます。以下のように表示されます。

利点：優れたパフォーマンス
デメリット: 構成が複雑

4. ハイブリッド負荷分散

複数のサーバー クラスターによってハードウェア機器、規模、提供されるサービスが異なるため、各サーバー クラスターに最適な負荷分散方法を使用することを検討し、多数のサーバー クラスター間で負荷分散または再度クラスター化して、外部全体にサービスを提供することで (複数のサーバー クラスターを新しいサーバー クラスターとして扱う)、最適なパフォーマンスを実現できます。

方法 1 は以下のとおりです。

上記のモードは、動的と静的の分離があるシナリオに適しています。リバース プロキシ サーバー (クラスター) は、キャッシュと動的リクエスト分散の役割を果たすことができます。静的リソースがプロキシ サーバーにキャッシュされると、それらは直接ブラウザーに返されます。動的ページの場合は、後続のアプリケーション負荷分散が要求されます。
方法 2 は以下のとおりです。

上記のシナリオは、動的リクエストのシナリオに適しています。

負荷分散アルゴリズム

一般的な負荷分散アルゴリズムには、ポーリング、ランダム、最小リンク、ソース アドレス ハッシュ、重み付けなどがあります。

1 投票

すべてのリクエストを各サーバーに順番に分散します。これは、同じサーバー ハードウェアを使用するシナリオに適しています。

利点: サーバー要求の数は同じです。

デメリット: サーバーの圧力が異なるため、サーバー構成が異なる状況には適していません。

2 ランダム

リクエストはサーバーにランダムに割り当てられます。
利点: 使いやすい;

デメリット: マシン構成が異なるシナリオには適していません。

3 最小リンク

接続数が最も少ないサーバー (現在処理しているリクエストが最も少ないサーバー) にリクエストを送信します。

利点: サーバーの現在のリクエスト処理ステータスに基づいた動的な割り当て。

デメリット: アルゴリズムの実装は比較的複雑で、サーバー要求接続の数を監視する必要があります。

4 ハッシュ（送信元アドレスハッシュ）

IP アドレスに基づいてハッシュ計算を実行し、IP アドレスを取得します。

利点: 同じセッション中に同じ IP アドレスからのリクエストを同じサーバーに転送し、セッションの持続性を実現します。

デメリット: ターゲット サーバーがダウンすると、セッションが失われます。

5 加重

ポーリング、ランダム、最小リンク、ハッシュなどのアルゴリズムに基づいて、負荷サーバーの分散が重み付け方式で実行されます。

利点: 重みに応じて転送サーバーへのリクエスト数を調整します。

デメリット: 使用が比較的複雑。

リバースプロキシ

リバースプロキシとは、プロキシサーバーがインターネット上の接続要求を受け付け、内部ネットワーク上のサーバーに要求を転送し、サーバーで得られた結果をインターネット上の接続要求元のクライアントに返すことです。このとき、プロキシサーバーは外部からはサーバーのように見えます。

nginx ロード バランシングとリバース プロキシに関するこの記事はこれで終わりです。より関連性の高い nginx ロード バランシングとリバース プロキシのコンテンツについては、123WORDPRESS.COM で以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。