NGINXとAzureロードバランサーの違い

[編集部 – この記事は、2021年6月時点でNGINX PlusとAzureロードバランシングサービスでサポートされている機能を反映するために更新されました。また、NGINX Plus APIについても言及し、元の記事で説明した個別の動的構成モジュールを置き換え、非推奨としています。]

Microsoft Azureを使用しているお客様向けに、3つのロードバランシングに対するオプションがあります。これらは、NGINX Plus、Azureロードバランシングのサービス、そしてNGINX PlusとAzureロードバランシングを併用する方法です。この記事は、お客様に意思決定するのに十分な情報を提供することを目的とし、Azure Load BalancerでNGINX Plusを使用することで、豊富なレイヤ7機能を備えた可用性の高いHTTPロード バランサーを実現する方法についても説明しています。

概要

Microsoft Azureには、ユーザーにロードバランサーの選択肢を2つ提示しています。1つはAzure Load Balancerで基本的なTCP/UDPのロードバランシング（ネットワークレイヤであるレイヤ4）向けのもの、もう１つは Azure Application Gatewayで、 – HTTP/HTTPSのロードバランシング (アプリケーションレイヤであるレイヤ7）向けです。これらのソリューションは単純なユースケースには適していますが、NGINX Plusに標準装備されている多くの機能を提供するものではありません。

ここでは、NGINX PlusとAzureのロードバランシング製品・サービスを一般的に比較します。

では、NGINX PlusとAzureのロードバランシングサービスの違い、それぞれの機能、そしてNGINX PlusとAzure Load Balancerの連携について説明していきます。

NGINX PlusとAzureロードバランシングのサービスの比較

ロードバランシングのメソッド

NGINX Plusでは、デフォルトのRound Robinメソッドに加えて、いくつかのロードバランシングのメソッドが選択できます。

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

異なる重み値をそれぞれのバックエンドサーバーに割り当てることで、すべてのメソッドを拡張できます。メソッドの詳細については 『NGINX Plus Admin Guide』を参照してください。

Azure Load Balancerは、1つのロードバランシングのメソッド「ハッシュ」を提供します。これはデフォルトでは、Source IP Address、Source Port、Destination IP Address、Destination Port、およびProtocolヘッダーフィールドに基づくキーを使用して、バックエンドサーバーを選択します。

Azure Application Gatewayは、round‑robinメソッドのみを提供します。

セッションパーシステンス

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

NGINX Plusは、3つの高度なセッションパーシステンスメソッドをサポートします。

• スティッキークッキー – NGINX Plusは、特定のクライアントのアップストリームグループからの最初のレスポンスにセッションクッキーを追加します。このクッキーはリクエストの処理に使用されたバックエンドサーバーを識別します。クライアントは後続のリクエストにこのクッキーを含め、NGINX Plusはこれを使用してクライアントのリクエストを同じバックエンドサーバーに転送します。
• スティッキーラーン – NGINX Plusは、リクエストとレスポンスをモニタリングしてセッション識別子（通常はクッキー）を特定し、それらを使ってセッション内の後続リクエストのサーバーを決定します。
• スティッキールート – NGINX Plusはルート値のリクエストをモニタリングし、一致するバックエンドサーバーを選択できるよう、ルート値とバックエンドサーバー間のマッピングを設定します。

NGINX Plusは、以下のような、上記のロードバランシングの2つのメソッドとして実装された、2つの基本的なセッションパーシステンスメソッドも提供します。

• IPハッシュ – バックエンドサーバーは、リクエストのIPアドレスによって決定されます。
• ハッシュ – バックエンドサーバーは、たとえば、Source IP AddressとSource PortまたはURIなど、ユーザーが定義したキーから決定されます。

Azure Load Balancerは、NGINX Plus Hashメソッドと同等のメソッドをサポートしますが、キーは、特定の組み合わせに制限されます。組み合わせは、Source IP Address、Source Port、 Destination IP Address、Destination Port、Protocolのヘッダーフィールドです。

Azure Application Gatewayは、NGINX Plus Sticky Cookieメソッドと同等のメソッドをサポートしますが、次のような制限があります。 クッキーの名前、その有効期限、ドメイン、パス、またはHttpOnlyやSecureクッキーの属性を構成することはできません。

注：Azure Load Balancer、NGINX Plus IP Hashメソッド、またはキーに含まれるSource IP Addressを使用したNGINX Plus IP Hashメソッドを使用する際に、クライアントのIPアドレスがセッションを通して同じままである場合にのみ、セッションの持続性は正しく機能します。これは必ずしも常に当てはまるわけではありません。たとえば、モバイルクライアントがWiFiネットワークから携帯電話のネットワークに切り替えた場合などは例外となります。リクエストが引き続き同じバックエンドサーバーに到着するようにするには、上記の高度なセッションパーシステンスメソッドのいずれかを使用することをお勧めします。

ヘルスチェック

Azure Load BalancerとAzure Application Gatewayは、ベーシックなアプリのヘルスチェックをサポートしています。ロードバランスが要求するURLを指定できます。また、予期されるHTTP 200戻りコードを受け取った場合、バックエンドサーバは正常であると見なされます。サーバーが正常でないと見なされるまでのヘルスチェックの頻度とタイムアウト期間を指定できます。Azure Application Gatewayを使用すると、予想されるレスポンスコードをカスタマイズし、レスポンス本文の内容と照合することもできます。

NGINX Plusは、高度なヘルスチェックを使って、この機能を拡張します。使用するURLを指定するだけでなく、NGINX Plusを使うと、リクエストにヘッダーを挿入して異なるレスポンスコードを検索したり、レスポンスのヘッダーと本文の両方を調べたりできます。

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 Cloud Serviceでアベイラビリティーセットを作成することで可能となります。細心の注意を払って、NGINX Plus設定ファイルの同期化を行う必要があります。

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

また、平均CPU使用率に基づいてバックエンドインスタンスの自動スケーリングを設定することもできます。 これは、バックエンドインスタンスをホストするAzure Cloud Serviceにアベイラビリティーセットを作成することで可能となります。 NGINX Plus APIより可能となるNGINX Plus構成では、バックエンドインスタンスの追加または削除する際には、細心の注意を払う必要があります。

NGINX Plus構成の更新を自動化するには（アベイラビリティーセットと併用、またはNGINX Plusの単独使用の場合）、NGINX Plus APIを介して、またはシステムがDNSインターフェイスを備えている場合はDNSを介して、サービス検出システムをNGINX Plusと統合することができます。ポピュラーなサービス検出システムでNGINX Plusを使用する方法に関する次のブログをご覧ください。

• Service Discovery for NGINX Plus Using DNS SRV Records from Consul
• Service Discovery for NGINX Plus Using Consul APIs
• Service Discovery for NGINX Plus with etcd
• Service Discovery for NGINX Plus with ZooKeeper

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の単独使用、あるいはAzure Load Balancerとの併用により、NGINX Plusインスタンスの高可用性を実現することが可能となります。

Microsoft Azure上でNGINX Plusをお試しになりたい場合は30日間の無料トライアルがございます。または、お客様のユースケースについてご相談ください。