NGINX および NGINX Plus でのサービス検出に DNS を使用する

[編集者 – この投稿は、元の投稿で言及されていた個別の動的設定モジュールを置き換えて非推奨とするNGINX Plus APIを参照するように更新されました。]

マイクロサービス アーキテクチャの大きな利点の 1 つは、サービス インスタンスを迅速かつ簡単に拡張できることです。 複数のサービス インスタンスがある場合は、ロード バランサと、利用可能なサービス インスタンスのセットの変更をロード バランサに迅速に通知する方法が必要です。 これはサービス検出と呼ばれます。 NGINX Plus には、サービス検出システムと統合するための 2 つのオプション、 NGINX Plus APIとドメイン ネーム システム (DNS) の再解決が用意されています。 このブログ投稿では後者に焦点を当てます。

仮想マシン (VM) またはコンテナを追加または削除してサービス インスタンス (このブログ投稿ではバックエンドと呼びます) をスケーリングする場合、バックエンドのセットに対するすべての変更を反映するようにロード バランサーの構成を変更する必要があります。 スケーリングは、アプリケーションに応じて、1 日あたり、1 時間あたり、または 1 分あたりに複数回発生する可能性があります。 構成変更の頻度が高いため、構成変更を自動化する必要があり、これを実現する方法の 1 つが DNS 経由のサービス検出です。

Kubernetesなど、現在アプリケーションを実行する多くのプラットフォームは、DNS を使用したサービス検出をサポートしています。 このブログ投稿の最後に、DNS を使用する一般的なプラットフォームやサービス検出ツールと NGINX Plus を統合する方法を説明する記事へのリンクを示します。

主要な DNS 機能の簡単なレビュー

DNS 経由でサービス検出を構成する方法を説明する前に、特に関連性が高く便利な DNS プロトコルの機能について簡単に見てみましょう。

存続期間

DNS クライアントが古い情報を使用することを防ぐために、DNS レコードには、クライアントがレコードを有効と見なす期間を定義する TTL (Time To Live) フィールドが含まれています。 DNS 標準に準拠するには、レコードの TTL が経過したときに、クライアントは DNS サーバーに更新を照会する必要があります。 NGINX Plus はデフォルトで TTL を尊重しますが、レコードの「有効期間」をより細かく制御することもできます。NGINX Plus を設定して、TTL を無視し、代わりに指定された頻度でレコードを更新することもできます。 (NGINX Open Source が TTL をどのように処理するかについては、この記事の後半で説明します。)

TCP 経由の DNS

デフォルトでは、DNS クライアントとサーバーは UDP 経由で通信しますが、ドメイン名が多数のバックエンド IP アドレスに解決される場合、完全な応答が 512 バイトに制限されている単一の UDP データグラムに収まらない可能性があります。 UDP の代わりに TCP を使用すると、この問題は解決されます。レコードの完全なセットが 1 つのデータグラムに収まらない場合、サーバーは応答に切り捨てフラグを設定し、クライアントに TCP に切り替えてすべてのレコードを取得するように指示します。 DNS over TCP は、NGINX バージョン 1.9.11 以降、および NGINX Plus R9 以降でサポートされています。 詳細については、弊社のブログの「NGINX および NGINX Plus を使用した DNS トラフィックの負荷分散」をご覧ください。

SRVレコード

DNS はホスト名を IP アドレスに解決しますが、ポート番号はどうでしょうか? たとえば、Docker コンテナの負荷分散を行う場合など、ポート番号が動的に割り当てられるため、既知のポート番号に依存できない場合があります。 DNS には、ポート番号やその他のいくつかのパラメータを含む、サービス ( SRV ) レコードという特別なタイプのレコードがあります。 R9 以降では、NGINX Plus はSRVレコードをサポートしています (したがって、そこからポート情報を抽出できます)。

編集者 – NGINX Plus R9 のすべての新機能の概要については、ブログの「NGINX Plus R9 の発表」をご覧ください。

NGINX および NGINX Plus の DNS を使用したサービス検出の方法

ここでは、NGINX と NGINX Plus で DNS を使用してサービス検出を行う 5 つの方法を、洗練度が増す順に紹介します。 最初の 3 つは NGINX と NGINX Plus の両方で使用できますが、最後の 2 つは NGINX Plus でのみ使用できます。

このサービス検出方法の調査では、ゾーンexample.comの IP アドレスが 10.0.0.2 である権威ネーム サーバーがあると仮定します。 nslookupユーティリティからの次の出力に示すように、ドメイン名backends.example.comに対応するバックエンド サーバーが 3 つあります。 ここで説明する最初の 4 つの方法では、NGINX と NGINX Plus は DNS から標準のAレコードを要求します。最後の方法では、NGINX Plus は代わりにSRVレコードを要求します。

$ nslookup backends.example.com 10.0.0.2サーバー:		10.0.0.2 アドレス:	10.0.0.2#53 名前: backends.example.com アドレス: 10.0.0.11 名前: backends.example.com アドレス: 10.0.0.10 名前: backends.example.com アドレス: 10.0.0.12

NGINX で DNS を使用してサービス検出を行う

まず、 NGINX Open Sourceで DNS を使用する 3 つの方法を紹介します (上で述べたように、NGINX Plus でも使用できます)。

proxy_passディレクティブでドメイン名を使用する

アップストリーム サーバー (バックエンド) のグループを定義する最も簡単な方法は、 proxy_passディレクティブのパラメーターとしてドメイン名を指定することです。

サーバー { 場所 / {
proxy_pass http://backends.example.com:8080;
}
}

NGINX が起動するか設定を再読み込みすると、DNS サーバーにクエリを実行してbackends.example.com を解決します。 DNS サーバーは、上で説明した 3 つのバックエンドのリストを返します。NGINX は、デフォルトのラウンドロビン アルゴリズムを使用して、それらの間でリクエストの負荷を分散します。 NGINX は、OS 構成ファイル/etc/resolv.confから DNS サーバーを選択します。

この方法は、サービス検出を行うための最も柔軟性の低い方法であり、次のような追加の欠点があります。

• ドメイン名を解決できない場合、NGINX は起動に失敗したり、設定を再読み込みしたりできなくなります。
• NGINX は、レコードの TTL 値を無視して、次の再起動または構成の再読み込みまで DNS レコードをキャッシュします。
• 別の負荷分散アルゴリズムを指定することはできません。また、パッシブヘルスチェックや、サーバーディレクティブのパラメータによって定義されるその他の機能を構成することもできません。これについては次のセクションで説明します。

アップストリームサーバーグループでのドメイン名の使用

NGINX が提供する負荷分散オプションを活用するには、アップストリーム構成ブロックでアップストリーム サーバーのグループを定義します。 ただし、個々のサーバーを IP アドレスで識別するのではなく、ドメイン名をサーバーディレクティブのパラメーターとして使用します。

最初の方法と同様に、NGINX が起動するか設定を再読み込みすると、 backends.example.com は3 つのバックエンド サーバーに解決されます。 しかし今では、より洗練された負荷分散アルゴリズムであるLeast Connectionsを定義し、 max_failsパラメータを使用してパッシブヘルスチェックを有効にし、3 つの連続したリクエストが失敗した場合に NGINX がサーバーをダウンとしてマークするように指定することができます。

アップストリーム バックエンド { least_conn;

サーバー backends.example.com:8080 max_fails=3;
}

サーバー {
場所 / {
proxy_pass http://backends;
}
}

この方法では、負荷分散アルゴリズムを選択してヘルスチェックを設定できますが、開始、再ロード、TTL に関しては、以前の方法と同じ欠点が残っています。

変数にドメイン名を設定する

この方法は最初の方法のバリエーションですが、NGINX がドメイン名を再解決する頻度を制御できます。

リゾルバ 10.0.0.2 有効 = 10 秒;
サーバー {
場所 / {
$backend_servers backends.example.com を設定します。
proxy_pass http://$backend_servers:8080;
}
}

proxy_passディレクティブで変数を使用してドメイン名を指定すると、NGINX は TTL の有効期限が切れたときにドメイン名を再解決します。 ネーム サーバーを明示的に指定するには、 resolverディレクティブを含める必要があります (NGINX は最初の 2 つの方法のように/etc/resolv.confを参照しません)。 リゾルバディレクティブにvalidパラメータを含めることで、NGINX に TTL を無視し、代わりに指定された頻度で名前を再解決するように指示できます。 ここでは、NGINX に 10 秒ごとに名前を再解決するように指示します。

注記： TCP/UDP ロード バランシングの場合、 proxy_passディレクティブで変数を使用するこの方法は、NGINX 1.11.3 以降および NGINX Plus R10 以降でサポートされています。

この方法では、ドメイン名を解決できない場合でも NGINX の起動またはリロード操作が失敗せず、NGINX が名前を再解決する頻度を制御できるという点で、最初の方法の 2 つの欠点が解消されます。 ただし、アップストリーム グループを使用しないため、負荷分散アルゴリズムやその他のパラメータをサーバーディレクティブに指定することはできません ( 2 番目の方法で行ったように)。

NGINX Plus で DNS を使用してサービス検出を行う

ここでは、NGINX Plus 専用の DNS を使用したサービス検出の 2 つの方法について説明します。

NGINX Plus でAレコードを使用する

NGINX Plus を使用すると、最初の 3 つの方法で説明した欠点がなく、必要な頻度で DNS 名を再解決できます。 この機能を使用するには、次のことが必要です。

• 前の方法と同様に、ネーム サーバーを指定するには、 resolverディレクティブを含めます。
• 共有メモリ ゾーンを割り当てるには、アップストリーム構成ブロックにゾーンディレクティブを含めます。
• ドメイン名を使用するサーバーディレクティブに、 resolveパラメータを追加します。

次の例を考えてみましょう。

リゾルバー 10.0.0.2 valid=10s ; アップストリーム バックエンド {ゾーン バックエンド 64k ; サーバー backends.example.com:8080解決; } サーバー { location / { proxy_pass http://backends; } }

デフォルトでは、NGINX Plus は TTL を尊重し、レコードの有効期限が切れると名前を再解決します。 NGINX Plus が指定された頻度で名前を再解決するようにするには、 resolverディレクティブにvalidパラメータを含めます。

このスニペットでは、NGINX Plus は 10 秒ごとに 10.0.0.2 のネーム サーバーにクエリを実行してbackends.example.com を解決します。 名前を解決できない場合、NGINX Plus は起動時、設定の再読み込み時、または実行時に失敗しません。 代わりに、クライアントは標準を見る502エラーページ。

NGINX Plus でSRVレコードを使用する

NGINX Plus R9 以降では DNS SRVレコードがサポートされています。 これにより、NGINX Plus はネーム サーバーから IP アドレスだけでなく、ポート番号、重み、優先度も取得できるようになります。 これは、サービスのポート番号が動的に割り当てられることが多いマイクロサービス環境では重要です。

編集者 – NGINX Plus R9 のすべての新機能の概要については、ブログの「NGINX Plus R9 の発表」をご覧ください。

SRVレコードは、サービス名、サービスとの通信プロトコル、ドメイン名の 3 つの要素によって定義されます。 ネーム サーバーを照会するときは、これら 3 つすべてを指定する必要があります。 10.0.0.2 ネーム サーバーには、 nslookupユーティリティからの次の出力に示すように、サービス名http 、プロトコルtcp 、ドメイン名backends.example.comの 3 つのSRVレコードがあります。

$ nslookup -query=SRV _http._tcp.backends.example.com 10.0.0.2サーバー:		10.0.0.2 アドレス:	10.0.0.2#53 _http._tcp.backends.example.com サービス = 0 2 8090 backend-0.example.com。 _http._tcp.backends.example.com サービス = 0 1 8091 backend-1.example.com。 _http._tcp.backends.example.com サービス = 10 1 8092 backend-2.example.com。

各SRVレコードのホスト名を照会すると、その IP アドレスが取得されます。

$ nslookup backend-0.example.com 10.0.0.2 ...
名前: backend-0.example.com アドレス: 10.0.0.10 $ nslookup backend-1.example.com 10.0.0.2 ...
名前: backend-1.example.com アドレス: 10.0.0.11 $ nslookup backend-2.example.com 10.0.0.2 ...
名前: backend-2.example.com アドレス: 10.0.0.12

最初のnslookupコマンドによって返される最初のSRVレコードの情報を詳しく見てみましょう。

_http._tcp.backends.example.com サービス = 0 2 8090 backend-0.example.com。

• _http._tcp. – SRVレコードの名前とプロトコル。 これを、NGINX Plus 構成ファイルのserverディレクティブのserviceパラメータの値として指定します (以下を参照)。
• 0 – 優先順位。 値が低いほど、優先度が高くなります。 NGINX Plus は、優先度が最も高いサーバーをプライマリ サーバーとして指定し、残りのサーバーをバックアップ サーバーとして指定します。 このレコードはすべてのレコードの中で最も低い値（最高の優先度）を持っているため、NGINX Plus は対応するバックエンドをプライマリ サーバーとして指定します。
• 2 – 重さ。 NGINX Plus は、バックエンドをアップストリーム グループに追加するときに、バックエンドの重みをこの値に設定します (サーバーディレクティブのweightパラメータに相当)。
• 8090 – ポート番号。 NGINX Plus は、バックエンドをアップストリーム グループに追加するときに、バックエンドのポートをこの値に設定します。
• backend‑0.example.com – バックエンド サーバーのホスト名。 NGINX Plus はこの名前を解決し、対応するバックエンドをアップストリーム グループに追加します。 名前が複数のレコードに解決される場合、NGINX Plus は複数のサーバーを追加します。

ここで、 SRVレコードを使用するように NGINX Plus を構成する方法を見てみましょう。 サンプル構成ファイルは次のとおりです。

リゾルバ 10.0.0.2 有効 = 10 秒;

アップストリーム バックエンド {
ゾーン バックエンド 64k;
サーバー backends.example.com サービス = _http._tcp 解決;
}

サーバー {
場所 / {
proxy_pass http://backends;
}
}

サーバーディレクティブのサービスパラメータを使用して、解決するSRVレコードの名前とプロトコルを指定します。 私たちの場合、それぞれ_httpと_tcpです。 サービスパラメータとポートを指定していない点を除けば、前のセクションの設定例と同じように見えます。

このセクションの最初のnslookupコマンドによって返される値に基づいて、NGINX Plus は 3 つのバックエンド サーバーで構成されます。

• 10.0.0.10 – ポート 8090、重み 2 のプライマリ サーバー。
• 10.0.0.11 – ポート 8091、重み 1 のプライマリ サーバー。
• 10.0.0.12 – ポート 8092、重み 1 のバックアップ サーバー。

NGINX Plus のライブ アクティビティ モニタリングを構成すると、組み込みダッシュボードでそれらのバックエンドを確認できます。

指定された重みに従ってリクエストがどのように分散されるかに注意してください。 10.0.0.11:8091 サーバー (重み 1) はリクエストの 3 分の 1 を取得し、10.0.0.10:8090 サーバー (重み 2) はリクエストの 3 分の 2 を取得します。 バックアップ サーバーである 10.0.0.12:8092 サーバーは、他の 2 つのサーバーがダウンしていない限り、リクエストを受け取りません。

注意点

NGINX Plus でサービス検出に DNS を使用する場合は、いくつか留意すべき点があります。

• DNS サーバーは高可用性であるか、バックアップ サーバーを備えている必要があります。 DNS サーバーが利用できなくなると、NGINX Plus は更新の取得を停止します。 既存のバックエンドは構成内に保持され (再起動するか構成を再ロードしない限り)、対応するレコードの TTL 値は無視されます。
• リゾルバディレクティブを使用して複数のネーム サーバーを指定できるため、そのうちの 1 つがダウンしても、NGINX Plus は他のネーム サーバーを試行します。
• はじめに述べたように、NGINX Plus を使用したサービス検出における DNS の代替手段はNGINX Plus APIです。これにより、アップストリーム グループ内のサーバーを追加または削除するための簡単な HTTP リクエストを作成できます。

例

完全な例を詳しく知りたい場合は、DNS を使用するサービス検出プラットフォームと NGINX および NGINX Plus の統合に関する次のブログ投稿をご覧ください。

• Consul の DNS SRVレコードを使用した NGINX Plus のサービス検出
• NGINX Plus を使用した Kubernetes サービスの負荷分散

今後、新しい統合オプションについてさらに詳しく説明するにつれて、このリストは更新される予定です。

結論

NGINX Plus で完全に利用可能な DNS 経由のサービス検出により、マイクロサービス環境でロードバランサーの構成を簡単に更新できるようになります。 リリース 9 以降でのSRVレコードのサポートにより、NGINX Plus は IP アドレスだけでなくバックエンドのポート番号も取得できるようになり、NGINX Plus がさらに強力になります。

NGINX Plus の DNS を使用したサービス検出とその他の拡張機能を試してみませんか? 今すぐ30 日間の無料トライアルを開始するか、使用事例についてご相談ください。