NGINX PlusとMicrosoft Azure Load Balancer

NGINX | 2021年6月25日

［編集者注 – この投稿は、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つの選択肢が提供されています。基本的なTCP/UDPロードバランシング（レイヤー4、ネットワーク層）向けの「Azure Load Balancer」と、HTTP/HTTPSロードバランシング（レイヤー7、アプリケーション層）向けの「Azure Application Gateway」です。これらのソリューションはシンプルなユースケースには対応できますが、NGINX Plusに標準搭載されている多くの機能は提供していません。

NGINX PlusとAzureの負荷分散サービスの一般的な比較を以下に示します。

機能	NGINX Plus	Azure Load Balancer	Azure Application Gateway	NGINX Plus & Azure Load Balancer
HTTPおよびHTTPSの負荷分散	✅	❌	✅	✅
HTTP/2の負荷分散	✅	❌	✅	✅
WebSocketの負荷分散	✅	❌	✅	✅
TCP/UDPの負荷分散	✅	✅	❌	✅
負荷分散方式	高度	シンプル	シンプル	高度
セッション維持	高度	シンプル	シンプル	高度
HTTPヘルスチェック	高度	シンプル	シンプル	高度
TCP/UDPヘルスチェック	高度	シンプル	❌	高度
SSL/TLS終端	✅	❌	✅	✅
レートおよび接続数の制限	✅	❌	❌	✅
URLの書き換えとリダイレクト	✅	❌	✅	✅
URLリクエストのマッピング	✅	❌	✅	✅
アクティブ／アクティブ構成のNGINX Plusクラスター	❌	❌	❌	✅

ここからは、NGINX PlusとAzureの負荷分散サービスの違いや、それぞれ独自の機能、さらにNGINX PlusとAzureロードバランサーを連携させる方法について見ていきます。

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

負荷分散方式

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

最小接続数 – 各リクエストは、アクティブな接続数が最も少ないサーバーに送信されます。
Least Time – 各リクエストは、平均レイテンシとアクティブな接続数の少なさを重み付けして算出したスコアが最も低いサーバーに送信されます。
IP Hash – 各リクエストは、その送信元IPアドレスに基づいて決定されたサーバーに送信されます。
汎用ハッシュ – 各リクエストは、ユーザー定義のキーに基づいて決定されたサーバーに送信されます。このキーには、テキストとNGINXの変数を任意に組み合わせて指定できます。たとえば、送信元 IP アドレスおよび送信元 ポートのヘッダーフィールドに対応する変数やURIを指定できます。
ランダム – 各リクエストは、ランダムに選択されたサーバーに送信されます。twoパラメーターを指定すると、NGINX Plusは2台のサーバーをランダムに選択し、設定に応じて、最小接続数アルゴリズム（デフォルト）または最小時間アルゴリズムを使用して、そのうちの1台を選択します。

すべての方式は、各バックエンドサーバーに異なる重み値を割り当てることで拡張できます。各方式の詳細については、NGINX Plus管理ガイドをご覧ください。

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

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

セッション永続化

セッション永続化（別名「スティッキーセッション」または「セッションアフィニティ」）は、バックエンドサーバー間でクライアントの状態が共有されないため、特定のクライアントからのすべてのリクエストを同じバックエンドサーバーに継続して送信する必要があるアプリケーションで必要となります。

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

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

NGINX Plusでは、上記の負荷分散方式のうち2つとして実装された、2種類の基本的なセッション永続化方式も提供しています。

IP Hash – リクエストのIPアドレスに基づいてバックエンドサーバーが決定されます。
Hash – バックエンドサーバーは、ユーザー定義のキー（例：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方式に相当する機能を。ただし、次の制限があります。Cookieの名前、有効期限、ドメイン、パス、およびHttpOnlyまたはSecureのCookie属性は設定できません。

注： Azure Load Balancer、NGINX PlusのIP Hash方式、またはキーにSource IP Addressを含むNGINX PlusのHash方式を使用する場合、セッション中にクライアントのIPアドレスが変わらない場合に限り、セッション永続化が正しく機能します。たとえば、モバイルクライアントがWiFiネットワークからモバイルネットワークに切り替えると、IPアドレスが変わることがあります。リクエストが同じバックエンドサーバーに引き続き送信されるようにするには、上記の高度なセッション永続化方式のいずれかを使用することを推奨します。

ヘルスチェック

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

NGINX Plusでは、この機能が高度なヘルスチェックによって拡張されています。使用するURLを指定できるほか、リクエストにヘッダーを挿入してさまざまなレスポンスコードを確認し、レスポンスのヘッダーと本文の両方を検査できます。

NGINX Plusの便利な関連機能として、スロースタートがあります。NGINX Plusは、新規サーバーや最近復旧したサーバーへの負荷を徐々に増やし、接続が集中して過負荷にならないようにします。この機能は、バックエンドサーバーに一定のウォームアップ時間が必要で、正常と判定された直後に通常どおりのトラフィックを割り当てると障害が発生する場合に役立ちます。

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

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

SSL/TLS終端

NGINX PlusはSSL/TLS終端をサポートしており、Azure Application Gatewayも同様です。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 Load Balancing Services

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

アクティブ／アクティブ構成による高可用性

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

NGINX Plusの自動スケーリング

NGINX Plusインスタンスの平均CPU使用率に基づいて、オートスケーリングを設定できます。これを行うには、NGINX PlusインスタンスをホストするAzure Cloud ServiceでAvailability Setsを作成します。NGINX Plusの設定ファイルが同期されるように管理する必要があります。

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

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

NGINX Plusの設定更新を自動化するには（Availability Setsと組み合わせる場合でも、NGINX Plusを単独で使用する場合でも）、サービスディスカバリシステムをNGINX Plusと統合できます。統合には、NGINX Plus APIを使用するか、システムにDNSインターフェースがある場合はDNSを使用します。一般的なサービスディスカバリシステムでNGINX Plusを使用する方法については、以下のブログ記事をご覧ください。

Azure Traffic Managerとの統合

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

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

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

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

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

まとめ

負荷分散の要件がシンプルな場合は、Azureの負荷分散サービスが適したソリューションとなります。要件が複雑になる場合は、NGINX Plusが適しています。NGINX Plusインスタンスの高可用性を確保するために、NGINX Plusを単独で使用することも、Azure Load Balancerと組み合わせて使用することもできます。

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