NGINX と NGINX Plus を使用した Docker Swarm 負荷分散
今年 9 月にオースティンで開催された nginx.conf 2016 で、 Docker Swarm クラスターで NGINX と NGINX Plus を使用する方法についてプレゼンテーションを行いました。 この記事では、Docker 1.12 で導入された機能と組み合わせて、Docker Swarm の負荷分散に NGINX と NGINX Plus を使用する方法について説明します。 nginx.conf でのデモ中に使用したすべてのファイル (およびその他) は、GitHub で公開されており、試すことができます。
概要
2016 年 7 月下旬にリリースされた Docker バージョン 1.12 では、Docker Engine と Swarm が統合され、いくつかの新しいオーケストレーション機能が追加され、Kubernetes などの他のコンテナー プラットフォームに似たプラットフォームが作成されます。 Docker 1.12 では、Swarm モードを使用すると、一連の Docker ホストをswarmに結合して、フォールト トレラントで自己修復可能な分散型アーキテクチャを実現できます。 新しいプラットフォームでは、Swarm クラスターのセットアップも簡単になり、すべてのノードをキーで保護し、ノード間のすべての通信を TLS で暗号化します。
同時に、Docker API は、同じイメージを使用するコンテナのセットであるサービス(Docker Compose のサービスに似ていますが、より多くの機能があります) を認識できるように拡張されました。 サービスの作成とスケーリング、ローリングアップデートの実行、ヘルスチェックの作成などを行うことができます。 DNS サービス検出と負荷分散が組み込まれており、クラスター全体のオーバーレイ ネットワークを設定することもできます。
Docker Swarm 負荷分散のトポロジ
この説明とデモでは、マネージャーとワーカーの 3 つの Swarm ノードを使用します。 マネージャー ノードは、Swarm コマンドが実行される場所です。 Swarm は、すべてのノード上のスケジューリング、DNS サービスの検出、スケーリング、およびコンテナの負荷分散 (図では小さなボックスで表されます) を処理します。
クラスター内のコンテナ間でプライベート ネットワーク通信を提供するために、コンテナは、クラスター内のすべてのノードにまたがる複数の内部オーバーレイ ネットワークに接続できます。 コンテナは、Swarm ロード バランサーを通じてクラスターの外部に公開できます。
Docker Swarm ロード バランサはすべてのノードで実行され、クラスター内の任意のホスト上の任意のコンテナ間でリクエストを負荷分散できます。 NGINX または NGINX Plus を使用しない Swarm デプロイメントでは、Swarm ロード バランサーが受信クライアント リクエスト (図 3 の緑色の矢印で表されます) と内部サービス間リクエスト (赤色の矢印で表されます) を処理します。
Swarm には負荷分散機能が含まれているので、別の負荷分散装置が必要なのはなぜでしょうか? 理由の 1 つは、Swarm ロードバランサーが基本的なレイヤー 4 (TCP) ロードバランサーであるためです。 多くのアプリケーションでは、次のような追加機能が必要です。
- SSL/TLS 終了
- コンテンツベースのルーティング（たとえば、URL またはヘッダーに基づく）
- アクセス制御と認証
- 書き換えとリダイレクト
さらに、すでにロード バランサーの使用経験がある場合、Swarm でロード バランサーを使用できれば、すでに使用しているツールや知識を活用できます。
NGINX オープンソースと NGINX Plus の使用
NGINX Open Source と NGINX Plus は、ネイティブの Swarm ロードバランサーにはないアプリケーションクリティカルな機能を提供する 2 つのロードバランサーです。
NGINXオープンソースの使用
NGINX オープンソースは、前述の機能 (SSL/TLS 終端など) に加え、次のような機能も提供します。
- 負荷分散アルゴリズムの選択
- HTTP/2やWebSocketなどのプロトコルの追加
- 設定可能なログ
- リクエストレート、帯域幅、接続などのトラフィック制限
- Lua、Perl、JavaScript を使用した高度なユースケースのスクリプト作成 (nginScript 動的モジュール[編集者注: 現在は NGINX JavaScript 動的モジュールと呼ばれています]を使用)
- 許可リストや拒否リストなどのセキュリティ機能
NGINX Open Source を使用する最も簡単な方法は、1 つ以上のコンテナを使用してサービスとしてデプロイすることです。 NGINX サービスに必要なポートはクラスター上で公開され、Swarm ロード バランサーはこれらのポート上のリクエストを NGINX コンテナーに分散します。
この例では、NGINX が提供するサービスは SSL/TLS 終端です。 これがどのように機能するかを説明するために、バックエンド サービス A をクラスターにデプロイし、3 つのコンテナー (1 つのノードに 2 つのインスタンス、別のノードに 1 つのインスタンス、図 5 に示すように) を持つようにスケーリングします。 Swarm は、クラスター内で使用するために、サービス A に仮想 IP アドレス (VIP) を割り当てます。 コンテナの個々の IP アドレスをリストするのではなく、サービス A のアップストリーム グループの NGINX 構成でこの VIP を使用します。 こうすることで、NGINX の設定を変更せずにサービス A をスケーリングできます。
図 5 に示すように、クライアントが最初の Swarm ノードにサービス A のリクエストを送信すると、そのノードの Swarm ロード バランサーがリクエストを NGINX にルーティングします。NGINX はリクエストを処理し (この例では SSL/TLS 復号化を実行)、サービス A の VIP にルーティングします。Swarm ロード バランサーは (暗号化されていない) リクエストを、いずれかの Swarm ノードにあるサービス A のコンテナーの 1 つにルーティングします。
NGINX でバックエンド コンテナーへのリクエストを直接ロード バランシングし、内部のサービス間リクエストを処理することも可能になりますが、サービス A がスケーリングされるたびに NGINX 構成を変更して再ロードする必要がある、より複雑なソリューションが必要になります。 NGINX Plus でこれを簡単に実現する方法については、後ほど説明します。
NGINX Plusの使用
NGINX Plus が提供する追加機能の一部は次のとおりです。
- アクティブなアプリケーションのヘルスチェック– NGINX Plus はバックエンド ノードを継続的にチェックして、ノードが正常で適切に応答していることを確認し、正常でないノードを負荷分散ローテーションから削除します。
- セッションの永続性-スティッキー セッションとも呼ばれ、クライアントのリクエストが同じバックエンドに継続的に送信されることを要求するアプリケーションで必要です。 NGINX Plus は、開いているセッションを持つクライアントに影響を与えずにバックエンド サーバーをオフラインにする必要がある場合に、セッション ドレインをサポートします。
動的再構成- これにより、NGINX 構成を変更して再ロードすることなく、バックエンドをスケールアップおよびスケールダウンできるようになります。 これは、Swarm などのマイクロサービス プラットフォームでサービス検出を行うときに特に役立ち、NGINX Plus をこれらのプラットフォームと完全に統合できるようにする最も重要な機能の 1 つです。
動的再構成の方法には、NGINX Plus に変更をプッシュできる API と、ドメイン名に接続されているノードの数の変更を NGINX Plus が継続的にチェックする DNS の 2 つがあります。 これは、NGINX Plus デモで Swarm の組み込みサービス検出と統合するために使用されている方法です。
- ライブ アクティビティ モニタリング- NGINX Plus から広範なメトリックを取得するための API と、メトリックを表示したり、バックエンド サーバーを追加、削除、変更したりできる API 上に構築された Web ダッシュボードを提供します。
上記のNGINX オープンソース構成では、Swarm ロードバランサーは外部リクエストをバックエンド コンテナーに分散するとともに、それらの間でサービス間リクエストを処理します。 NGINX の役割は SSL/TLS オフロードです。
NGINX Plus を使用する場合、外部クライアントからのクライアント要求は最初に Swarm ロードバランサーにヒットしますが、NGINX Plus がバックエンド コンテナーへの実際の負荷分散を実行します (図 6)。 クライアントのリクエストが最初に Swarm ロードバランサーにヒットするようにすると、NGINX Plus の高可用性を簡単に実現できます。
同様に、Swarm ロードバランサーはサービス間リクエストを受信しますが、NGINX Plus は実際にそれらをサービス間で分散します (図 7)。
デモ
NGINX の有無にかかわらず、Docker 負荷分散に Swarm を使用する例をいくつか提供するために、3 つのデモを作成しました。 これらのデモのすべてのファイルは、詳細な手順とともにGitHubで入手できます。 3 つのデモンストレーションは次のとおりです。
Docker Swarm 負荷分散
これは、NGINX または NGINX Plus を使用せずに、シンプルな Web アプリ バックエンドへのリクエストの Docker Swarm 負荷分散を示しています。
NGINX オープンソースを使用した Docker Swarm 負荷分散
このデモでは、NGINX オープンソースを追加して、外部リクエストの SSL/TLS オフロードを提供します。 Swarm ロード バランサーは、前のデモと同じシンプルな Web アプリ バックエンドにリクエストを分散し、内部のサービス間リクエストを処理します。
NGINX Plus を使用した Docker Swarm 負荷分散
このデモは 2 つの部分から構成されています。 最初の部分では、NGINX Plus を使用します。NGINX Plus は、SSL/TLS オフロードに加えて、バックエンド コンテナーへのリクエストを直接ロード バランシングし、内部のサービス間リクエストも処理します。 これは Swarm サービス検出と統合されており、動的 DNS を使用してバックエンドに関連付けられたドメイン名を頻繁に再解決します。 NGINX Plus は、 Service1とService2 の2 つのバックエンド サービスを負荷分散しています。 これは、 Service1 がService2にリクエストを送信することで、内部のサービス間リクエストを示します。
2 番目の部分では、NGINX ステータス API と Docker サービス API を組み合わせて、バックエンド コンテナーを自動的にスケーリングする方法を示します。 Python プログラムは、NGINX Plus Status API を使用してService1とService2の負荷を監視し、Docker Swarm Service API を使用してバックエンド コンテナーをスケールアップまたはスケールダウンします。
まとめ
Docker 1.12 で導入された新機能により、Swarm はより強力なプラットフォームになりましたが、NGINX オープンソースを活用し、さらに NGINX Plus を使用することで、さらに強化することができます。 NGINX Plus は、DNS を使用してバックエンド コンテナを動的に再構成し、負荷を分散する機能と、Status API によって提供される可視性により、非常に強力なコンテナ ソリューションを実現します。
NGINX Plus をお試しいただくには、今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、使用事例についてご相談ください。
GitHubリポジトリで提供されているデモをぜひお試しください。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"