NGINX Plus と Microsoft Azure ロードバランサー

[編集者 – この投稿は、2021 年 6 月時点で NGINX Plus と Azure 負荷分散サービスでサポートされている機能を反映するように更新されました。 また、元の投稿で言及されていた個別の動的構成モジュールを置き換えて非推奨とするNGINX Plus APIについても言及しています。

Microsoft Azure を使用するお客様には、負荷分散のオプションが 3 つあります。 NGINX Plus 、Azure 負荷分散サービス、または NGINX Plus と Azure 負荷分散サービスの組み合わせ。 この投稿の目的は、決定を下すのに十分な情報を提供すること、また、NGINX Plus を Azure Load Balancer と組み合わせて使用することで、豊富なレイヤー 7 機能を備えた高可用性 HTTP ロード バランサーを実現する方法を示すことです。

概要

Microsoft Azure では、ユーザーに 2 つのロード バランサーの選択肢が提供されます。 Azure ロード バランサー 基本的なTCP/UDP負荷分散（レイヤー4、ネットワーク層）および Azure アプリケーション ゲートウェイ HTTP/HTTPS 負荷分散用 （レイヤー7、アプリケーション層）。 これらのソリューションは単純なユースケースでは機能しますが、NGINX Plus に標準で付属する多くの機能は提供しません。

NGINX Plus と Azure の負荷分散サービスの一般的な比較は次のとおりです。

ここで、NGINX Plus と Azure ロード バランシング サービスの違い、それぞれの独自の機能、NGINX Plus と Azure ロード バランサーがどのように連携するかについて説明します。

NGINX Plus と Azure 負荷分散サービスの比較

負荷分散方法

NGINX Plus では、デフォルトのラウンドロビン方式に加えて、いくつかの負荷分散方式を選択できます。

• 最小接続数– 各リクエストは、アクティブな接続数が最も少ないサーバーに送信されます。
• 最小時間– 各リクエストは、平均レイテンシとアクティブ接続の最小数の加重組み合わせから計算されたスコアが最も低いサーバーに送信されます。
• IP ハッシュ- 各リクエストは、リクエストの送信元 IP アドレスによって決定されるサーバーに送信されます。
• 汎用ハッシュ- 各リクエストは、ユーザー定義のキーから決定されたサーバーに送信されます。ユーザー定義のキーには、テキストと NGINX変数の任意の組み合わせを含めることができます。たとえば、ソースIPアドレスとソースポートのヘッダー フィールドに対応する変数、または URI などです。
• ランダム– 各リクエストはランダムに選択されたサーバーに送信されます。 2 つのパラメータが含まれている場合、NGINX Plus は 2 つのサーバーをランダムに選択し、設定された最小接続アルゴリズム (デフォルト) または最小時間のいずれかを使用してそれらを選択します。

すべてのメソッドは、各バックエンド サーバーに異なる重み値を割り当てることによって拡張できます。 メソッドの詳細については、 NGINX Plus 管理者ガイドを参照してください。

Azure Load Balancer には、ハッシュという 1 つの負荷分散方法が用意されています。この方法では、既定で、送信元IPアドレス、送信元ポート、宛先IPアドレス、宛先ポート、およびプロトコルヘッダー フィールドに基づくキーを使用して、バックエンド サーバーが選択されます。

Azure Application Gateway ではラウンドロビン方式のみが提供されます。

セッションの永続性

セッション永続性(スティッキー セッションまたはセッション アフィニティとも呼ばれる) は、クライアントの状態がバックエンド サーバー間で共有されないため、アプリケーションが特定のクライアントからのすべての要求を同じバックエンド サーバーに送信し続けることを必要とする場合に必要になります。

NGINX Plus は、3 つの高度なセッション持続方式をサポートしています。

• スティッキー Cookie – NGINX Plus は、特定のクライアントのアップストリーム グループからの最初の応答にセッション Cookie を追加します。 この Cookie は、リクエストの処理に使用されたバックエンド サーバーを識別します。 クライアントは後続のリクエストにこの Cookie を含め、NGINX Plus はそれを使用してクライアント リクエストを同じバックエンド サーバーに送信します。
• Sticky Learn – NGINX Plus はリクエストと応答を監視してセッション識別子 (通常は Cookie) を見つけ、それを使用してセッション内の後続のリクエストのサーバーを決定します。
• スティッキー ルート– ルート値とバックエンド サーバー間のマッピングを設定して、NGINX Plus がルート値のリクエストを監視し、一致するバックエンド サーバーを選択できるようにすることができます。

NGINX Plus は、上記の負荷分散方法の 2 つとして実装された 2 つの基本的なセッション持続方法も提供します。

• IP ハッシュ- バックエンド サーバーは、リクエストの IP アドレスによって決定されます。
• ハッシュ- バックエンド サーバーは、ソースIPアドレスとソースポート、または URI などのユーザー定義のキーから決定されます。

Azure Load Balancer は、NGINX Plus ハッシュ メソッドと同等の機能をサポートしていますが、キーは、ソースIPアドレス、ソースポート、宛先IPアドレス、宛先ポート、およびプロトコルヘッダー フィールドの特定の組み合わせに制限されます。

Azure Application Gateway は、NGINX Plus スティッキー Cookie メソッドと同等の機能をサポートしていますが、次の制限があります: Cookie の名前、有効期限、ドメイン、パス、またはHttpOnlyまたはSecure Cookie 属性を構成することはできません。

注記： Azure Load Balancer、NGINX Plus IP ハッシュ メソッド、またはキーにソースIPアドレスが含まれる NGINX Plus ハッシュ メソッドを使用する場合、クライアントの IP アドレスがセッション全体で同じである場合にのみ、セッションの永続性が正しく機能します。 たとえば、モバイル クライアントが WiFi ネットワークからセルラー ネットワークに切り替える場合など、これは常に当てはまるとは限りません。 リクエストが引き続き同じバックエンド サーバーに送信されることを確認するには、上記の高度なセッション永続化方法のいずれかを使用することをお勧めします。

健康診断

Azure Load Balancer と Azure Application Gateway は、基本的なアプリケーションの正常性チェックをサポートしています。 ロードバランサが要求するURLを指定でき、期待されるHTTPを受信すればバックエンドサーバは正常であるとみなされます。200戻りコード。 ヘルスチェックの頻度と、サーバーが正常でないと判断されるまでのタイムアウト期間を指定できます。 Azure Application Gateway を使用すると、予想される応答コードをカスタマイズし、応答本文の内容と照合することもできます。

NGINX Plus は、高度なヘルスチェックによってこの機能を拡張します。 NGINX Plus では、使用する URL を指定するだけでなく、リクエストにヘッダーを挿入してさまざまな応答コードを探し、応答のヘッダーと本文の両方を調べることができます。

NGINX Plus の便利な関連機能はスロースタートです。 NGINX Plus は、新しいサーバーまたは最近回復したサーバーへの負荷を徐々に増加させ、接続によって過負荷にならないようにします。これは、バックエンド サーバーにウォームアップ時間が必要で、正常であると表示されたらすぐにトラフィックの完全な割り当てが与えられると障害が発生する場合に役立ちます。

NGINX Plus はTCPおよびUDPサーバーへのヘルス チェックもサポートしており、送信する文字列と応答で検索する文字列を指定できます。

Azure Load Balancer は TCP 正常性チェックをサポートしていますが、このレベルの監視は提供していません。

SSL/TLS 終了

NGINX Plus は、 Azure Application Gatewayと同様にSSL/TLS 終端をサポートしています。 Azure Load Balancer ではそうではありません。

接続とレート制限

NGINX Plus を使用すると、NGINX Plus インスタンスとの間のトラフィックを制御するために複数の制限を設定できます。 これには、着信接続、バックエンド ノードへの接続、着信要求のレート、NGINX Plus からクライアントへのデータ転送レートの制限が含まれます。

Azure Application Gateway と Azure Load Balancer は、レート制限や接続制限をサポートしていません。 ただし、他の Azure サービスを使用してレート制限を構成し、有効にすることができます。

プロトコルのサポートと URL の書き換えとリダイレクト

NGINX Plus、Azure Application Gateway、Azure Load Balancer はすべて以下をサポートしています。

• HTTP/2 – NGINX Plus は 2016 年からクライアントからのHTTP/2 リクエストを受け入れています。 Azure では最近、WebSocket サポートが追加されました。
• WebSocket – NGINX Plus は 2014 年からクライアントからの WebSocket 接続を受け入れています。 Azure では最近、WebSocket サポートが追加されました。
• URL 書き換えとリクエストのリダイレクト- リクエストの URL は、バックエンド サーバーに渡される前に変更できます。つまり、クライアントにアドバタイズされる URL を変更することなく、リクエストのパスとファイルの場所を内部的に変更できます。 また、HTTP リクエストのスキームを HTTPS に変更するなどして、リクエストをリダイレクトすることもできます。

NGINX Plus と Azure 負荷分散サービス

Azure Load Balancer およびAzure Traffic Managerと併用すると、NGINX Plus は豊富なレイヤー 7 機能を備えた高可用性ロード バランサー ソリューションになります。

アクティブ-アクティブ高可用性

Azure Load Balancer を使用して可用性セット内の NGINX Plus インスタンス間で負荷分散を行うことで、リージョン内に高可用性ロード バランサーを作成できます。

NGINX Plusの自動スケーリング

平均 CPU 使用率に基づいて、NGINX Plus インスタンスの自動スケーリングを設定できます。 これは、NGINX Plus インスタンスをホストする Azure クラウド サービスに可用性セットを作成することで可能になります。 NGINX Plus 設定ファイルの同期に注意する必要があります。

バックエンドインスタンスの自動スケーリング

平均 CPU 使用率に基づいてバックエンド インスタンスの自動スケーリングを設定することもできます。 これは、バックエンド インスタンスをホストする Azure クラウド サービスに可用性セットを作成することで可能になります。 NGINX Plus 構成からバックエンド インスタンスを追加または削除する必要がありますが、これはNGINX Plus APIを使用して可能です。

NGINX Plus 構成の更新を自動化するには (可用性セットと組み合わせて使用するか、NGINX Plus を単独で使用するか)、 NGINX Plus API経由、またはシステムに DNS インターフェイスがある場合は DNS 経由で、サービス検出システムを NGINX Plus と統合できます。 一般的なサービス検出システムで NGINX Plus を使用する方法については、当社のブログ投稿をご覧ください。

• Consul の DNS SRV レコードを使用した NGINX Plus のサービス検出
• Consul API を使用した NGINX Plus のサービス検出
• etcd を使用した NGINX Plus のサービス検出
• ZooKeeper を使用した NGINX Plus のサービス検出

Azure Traffic Manager との統合

グローバルに分散された環境では、Azure Traffic Manager を使用して、クライアントからのトラフィックを多くのリージョンに分散できます。

Azure 負荷分散サービスの追加機能

Azure Load Balancer と Application Gateway は Azure Cloud によって管理され、どちらも可用性の高い負荷分散ソリューションを提供します。

NGINX Plus では利用できない Azure Load Balancer の機能は、ソース NATです。これは、バックエンド インスタンスからの送信トラフィックのソース IP アドレスがロード バランサーと同じになる機能です。

Azure Load Balancer は、Azure Cloud の自動スケーリング機能を使用するときに自動再構成を提供します。

まとめ

負荷分散の要件が単純な場合は、Azure 負荷分散サービスが適切なソリューションを提供します。 要件がより複雑になった場合は、NGINX Plus が適切な選択肢となります。 NGINX Plus インスタンスの高可用性を実現するために、NGINX Plus を単独で使用することも、Azure Load Balancer と組み合わせて使用することもできます。

Microsoft Azure で NGINX Plus を試すには、今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、ユースケースについてご相談ください。