LVS、Nginx、HAProxy がどのように動作するかを本当に理解していますか?

現在のインターネットシステムのほとんどは、サーバークラスターテクノロジを使用しています。クラスターは、複数のサーバーに同じサービスを展開して、全体としてクラスターを形成し、外部にサービスを提供します。

[[272323]]

画像はUnsplashより

これらのクラスターには、Web アプリケーションサーバークラスター、データベースサーバークラスター、分散キャッシュサーバークラスターなどがあります。

実際のアプリケーションでは、Web サーバークラスターの前に常に負荷分散サーバーが存在します。負荷分散デバイスの役割は、Web サーバートラフィックの入り口として機能し、最適な Web サーバーを選択し、クライアントの要求をそのサーバーに転送して処理し、クライアントから実際のサーバーへの透過的な転送を実現することです。

近年普及しているクラウドコンピューティングや分散アーキテクチャは、基本的にバックエンドサーバーをコンピューティングリソースやストレージリソースとして利用し、管理サーバーによってサービスとしてパッケージ化されて外部に提供されるものです。クライアントは、実際にどのマシンがサービスを提供するかを気にする必要はありません。

その観点から見ると、ほぼ無制限の機能を備えたサーバーに直面しているように見えますが、本質的には、実際にサービスを提供するのはバックエンドクラスターです。

LVS、Nginx、HAProxy は、広く使用されている 3 つの負荷分散ソフトウェアです。一般的に、Web サイトの規模が大きくなるにつれて、さまざまな段階でさまざまなテクノロジを使用して負荷分散が行われます。

特定のアプリケーション要件を具体的に分析する必要があります。例えば、1日のPVが1000万未満の中小規模のWebアプリケーションであれば、Nginxで十分です。

マシンが多数ある場合は、DNS ポーリングを使用できます。 LVS はまだ多くのマシンを消費します。多数のサーバーを備えた大規模な Web サイトや重要なサービスの場合は、LVS の使用を検討できます。

現在、Web サイトアーキテクチャの最も合理的で人気のあるアーキテクチャソリューションは次のとおりです。

Web フロントエンドは、ロードバランサーとして Nginx/HAProxy+Keepalived を使用します。
バックエンドは、1 つのマスターと複数のスレーブ、および読み取りと書き込みの分離を備えた MySQL データベースを使用し、LVS + Keepalived アーキテクチャを採用しています。

LVS の

LVS は Linux Virtual Server の略で、Linux 仮想サーバーです。 LVS は現在、標準の Linux カーネルの一部となっています。

Linux 2.4 カーネル以降、LVS のすべての機能モジュールが完全に統合されています。カーネルにパッチを適用する必要がなく、LVS が提供するさまざまな機能を直接使用できます。

LVS は 1998 年から開発されており、比較的成熟した技術プロジェクトとなっています。

LVS アーキテクチャ:

LVS によって構築されるサーバークラスターシステムは、次の 3 つの部分で構成されます。

フロントエンドの負荷分散層は、ロードバランサによって表されます。
中央のサーバークラスター層は、サーバーアレイによって表されます。
最下位レベルのデータ共有ストレージ層は、共有ストレージによって表されます。

LVS 負荷分散メカニズム

HAProxy やその他のレイヤー 7 ソフトロードとは異なり、LVS は HTTP パケットを対象としていません。したがって、LVS はレイヤー 7 ロードが実行できる URL 解決などのタスクを完了できません。

LVS は 4 層の負荷分散であり、OSI モデルの第 4 層であるトランスポート層上に構築されています。トランスポート層には、私たちがよく知っている TCP/UDP があります。 LVS は TCP/UDP 負荷分散をサポートします。

LVS は 4 層の負荷分散であるため、DNS ドメイン名ラウンドロビン解決、アプリケーション層負荷スケジューリング、クライアントスケジューリングなどの他の高レベル負荷分散ソリューションと比較して、効率が非常に高くなります。

いわゆる 4 層負荷分散は、主にメッセージ内のターゲットアドレスとポートに基づいています。「コンテンツスイッチング」とも呼ばれるレイヤー 7 ロードバランシングでは、主にメッセージ内の本当に意味のあるアプリケーションレイヤーコンテンツが使用されます。

LVS 転送は、主に IP アドレスの変更 (NAT モード、送信元アドレス変更 SNAT とターゲットアドレス変更 DNAT に分かれています) とターゲット MAC の変更 (DR モード) によって実現されます。

NAT モード: ネットワークアドレス変換

NAT (ネットワークアドレス変換) は、外部ネットワークアドレスと内部ネットワークアドレスをマッピングするテクノロジです。

NAT モードでは、すべての着信および発信ネットワークデータグラムは LVS によって処理される必要があります。 LVS は RS (実サーバー) のゲートウェイとして機能する必要があります。

パケットが LVS に到達すると、LVS は宛先アドレス変換 (DNAT) を実行し、宛先 IP を RS の IP に変更します。

RS はパケットを受信すると、クライアントが直接送信したかのように動作します。 RS が処理を完了して応答を返すと、送信元 IP は RS IP になり、宛先 IP はクライアント IP になります。

このとき、RS パケットはゲートウェイ (LVS) を介して転送され、LVS は送信元アドレス変換 (SNAT) を実行してパケットの送信元アドレスを VIP に変更します。この方法では、パケットは LVS によって直接クライアントに返されたように見えます。

DRモード: ダイレクトルーティング

DR モードでは、LVS クラスターと RS クラスターを同じ VIP にバインドする必要があります (RS は VIP をループバックにバインドすることによって実装されます)。

しかし、NAT との違いは、要求が LVS によって受信され、LVS を経由せずに実際にサービスを提供するサーバー (RealServer、RS) によって直接ユーザーに返されることです。

詳細には、要求が来ると、LVS はネットワークフレームの MAC アドレスを特定の RS の MAC に変更するだけで、パケットは対応する RS に転送されて処理されます。現時点ではソース IP とターゲット IP は変更されておらず、LVS が移植を行っただけであることに注意してください。

RS が LVS によって転送されたパケットを受信すると、リンク層は MAC が自分のものであることを検出し、次に上位のネットワーク層に移動して IP も自分のものであることを検出するため、パケットは合法的に受け入れられ、RS は前方の LVS の存在を認識できません。

RS が応答を返すときは、LVS を経由せずに送信元 IP (つまり、ユーザーの IP) に直接返すだけで済みます。

DR ロードバランシングモードでは、データ配布中に IP アドレスは変更されず、Mac アドレスのみが変更されます。実際の処理要求の実際の物理 IP アドレスは、データ要求の宛先 IP アドレスと一致しているため、負荷分散サーバーを介してアドレス変換を実行する必要はありません。

応答データパケットをユーザーのブラウザーに直接返すことで、負荷分散サーバーのネットワークカード帯域幅がボトルネックになるのを防ぐことができます。

したがって、DR モードはパフォーマンスが向上し、大規模な Web サイトで広く使用されている負荷分散方法でもあります。

LVS の利点は次のとおりです。

強力な負荷耐性を備えており、トラフィックを生成せずに、配信のみを目的としてトランスポート層で動作します。この機能は、負荷分散ソフトウェアの中で最も強力なパフォーマンスを持ち、比較的少ないメモリと CPU リソースを消費することも判明しています。
構成可能性は比較的低いですが、これは欠点であると同時に利点でもあります。設定する項目がそれほど多くないため、多くの操作を必要とせず、人為的エラーの可能性が大幅に減少します。
強力な耐荷重性と、LVS + Keepalived などの完全なデュアルマシンホットスタンバイソリューションを備えているため、安定して動作します。
渋滞はありません。 LVS はリクエストを分散するだけで、トラフィックは LVS から出ません。これにより、バランサー IO のパフォーマンスが大量のトラフィックの影響を受けなくなります。
応用範囲は比較的広いです。 LVS はトランスポート層で動作するため、HTTP、データベース、オンラインチャットルームなど、ほぼすべてのアプリケーションの負荷を分散できます。

LVS の欠点は次のとおりです。

ソフトウェア自体は正規表現処理をサポートしておらず、動的および静的分離を実行できません。ただし、現在多くの Web サイトではこの点に関して強い要求があり、これが Nginx、HAProxy+Keepalived の利点です。
ウェブサイトアプリケーションが比較的大きい場合、LVS/DR+Keepalived の実装はより複雑になります。相対的に言えば、Nginx/HAProxy+Keepalived の方がはるかにシンプルです。

エンギンクス

Nginx は、高同時 HTTP リクエストを処理し、負荷分散のためのリバースプロキシサーバーとして機能する強力な Web サーバーソフトウェアです。

高性能、軽量、低メモリ消費、強力な負荷分散機能などの利点があります。

Nignx アーキテクチャデザイン

従来のプロセスまたはスレッドベースのモデル (Apache はこのモデルを使用) と比較すると、同時接続を処理する場合、接続ごとに個別のプロセスまたはスレッドが確立され、ネットワークまたは入出力操作中にブロックされます。

これにより、新しい個別のプロセスまたはスレッドが、ヒープおよびスタックメモリの割り当て、新しい実行コンテキストを含む新しいランタイム環境を準備する必要があるため、大量のメモリと CPU が消費され、当然、過剰な CPU オーバーヘッドも発生します。

最終的には、コンテキストの切り替えが多すぎるためにサーバーのパフォーマンスが低下します。一方、Nginx のアーキテクチャは、モジュール式、イベント駆動型、非同期型、シングルスレッド型、非ブロッキング型となるように設計されています。

Nginx は多重化とイベント通知を広範に利用します。 Nginx が起動されると、マスタープロセスと n (n>=1) 個のワーカープロセスを含む、システム内のデーモンとしてバックグラウンドで実行されます。

すべてのプロセスはシングルスレッド（つまり、メインスレッドは 1 つだけ）であり、プロセス間通信では主に共有メモリが使用されます。

マスタープロセスは、外部からの信号を受信し、ワーカープロセスに信号を送信し、ワーカープロセスの動作状態を監視するために使用されます。

ワーカープロセスは、外部要求の実際のプロセッサです。各ワーカーのリクエストは独立しており、クライアントからのリクエストに対して平等に競合します。

リクエストは 1 つのワーカープロセスでのみ処理でき、ワーカープロセスにはメインスレッドが 1 つしかないため、一度に処理できるリクエストは 1 つだけです。 (原理はNettyと非常に似ています)

Nginx 負荷分散

Nginx ロードバランシングは、主に 7 層ネットワーク通信モデルの 7 番目のアプリケーション層で HTTP と HTTPS をサポートします。 Nginx はリバースプロキシモードで負荷分散を実行します。

リバースプロキシ方式とは、インターネット上の接続要求をプロキシサーバーで受け付け、その要求を社内ネットワーク上のサーバーに転送し、サーバーから取得した結果をインターネット上の接続を要求しているクライアントに返す方式です。このとき、プロキシサーバーは外部からはサーバーとして表示されます。

Nginx には多くの負荷分散戦略があります。 Nginx Upstream は現在、次のメソッドをサポートしています。

ポーリング (デフォルト): 各リクエストは時系列順に異なるバックエンドサーバーに割り当てられます。バックエンドサーバーがダウンしている場合は、自動的に削除されます。
重み: ポーリング確率を指定します。重みはアクセス比率に比例し、バックエンドサーバーのパフォーマンスが不均一な場合に使用されます。
IP_Hash: 各リクエストはアクセス IP のハッシュ結果に従って割り当てられるため、各訪問者は固定のバックエンドサーバーにアクセスし、セッションの問題を解決できます。
公平 (サードパーティ): リクエストはバックエンドサーバーの応答時間に基づいて分散され、応答時間が短いリクエストが優先されます。
URL_Hash (サードパーティ): アクセスされた URL のハッシュ結果に従ってリクエストを分散し、各 URL が同じバックエンドサーバーに送信されるようにします。これは、バックエンドサーバーがキャッシュされている場合に、より効果的です。

Nginx の利点は次のとおりです。

クロスプラットフォーム: Nginx はほとんどの Unix 系 OS でコンパイルして実行でき、Windows に移植されたバージョンもあります。
非常にシンプルな構成: 始めるのは非常に簡単です。構成スタイルはプログラム開発と同じ、神のような構成です。
ノンブロッキング、高同時接続: 公式テストでは 50,000 の同時接続をサポートできることが示されており、実際の運用環境では 20,000 ～ 30,000 の同時接続に達することができます。
イベント駆動型: 通信メカニズムは、大規模な同時接続をサポートするために Epoll モデルを採用しています。
マスター/ワーカー構造: マスタープロセスは 1 つ以上のワーカープロセスを生成します。
メモリ消費量が少ない: 大量の同時リクエストを処理する場合、メモリ消費量は非常に少なくなります。同時接続数が 30,000 の場合、開かれた 10 個の Nginx プロセスは 150M のメモリのみを消費します (15M * 10 = 150M)。
組み込みのヘルスチェック機能: Nginx プロキシの背後にある Web サーバーがダウンしても、フロントエンドのアクセスには影響しません。
帯域幅を節約: GZIP 圧縮をサポートし、ブラウザのローカルキャッシュにヘッダーを追加します。
高い安定性: リバースプロキシとして使用する場合、ダウンタイムの可能性は最小限に抑えられます。

Nginx の欠点は次のとおりです。

Nginx は HTTP、HTTPS、TCP、電子メールなどのプロトコルのみをサポートしているため、適用範囲が狭く、それが欠点です。
バックエンドサーバーのヘルスチェックでは、URL 経由ではなく、ポート経由の検出のみがサポートされます。直接的なセッションの永続性はサポートされていませんが、IP_Hash を通じて解決できます。

HAプロキシ

HAProxy は、TCP (レイヤー 4) と HTTP (レイヤー 7) の 2 つのプロキシモードをサポートし、仮想ホストもサポートします。

HAProxy の利点は、セッション保持や Cookie ガイダンスのサポートなど、Nginx の欠点の一部を補うことができます。また、指定された URL を取得してバックエンドサーバーの状態を検出することもサポートしています。

HAProxy は LVS に似ており、それ自体は単なる負荷分散ソフトウェアです。効率性の観点から見ると、HAProxy は Nginx よりも負荷分散速度が優れており、並行処理でも Nginx よりも優れています。

HAProxy は、TCP プロトコルの負荷分散転送をサポートし、MySQL 読み取りの負荷分散、バックエンドの MySQL ノードの検出と負荷分散を行うことができます。 LVS+Keepalived を使用して、MySQL マスターとスレーブの負荷を分散できます。

HAProxy には多くの負荷分散戦略があります。