BIG-IP

F5 BIG-IP LTMからNGINX Plusへのロードバランサー構成の移行

※本記事はNGINX,Inc.のブログ記事「Migrating Load Balancer Configuration from F5 BIG-IP LTM to NGINX Plus」を和訳した内容となります。
【URL】
https://docs.nginx.com/nginx/deployment-guides/f5-configuration-migrating-nginx-plus/

NGINX Plusなら、従来のハードウェアベースのアプリケーション デリバリー コントローラー(以下ADCと表記)を柔軟に置き換えられます。NGINX Plusは、ベアメタル、仮想マシン、コンテナ、オンプレミスに、パブリック/プライベート/ハイブリッドクラウドなど、およそどこにでもインストール可能な小さなソフトウェア・パッケージですが、旧来のADCと同レベルのアプリケーション配信、高可用性、そしてセキュリティーを実現します。このガイドでは、F5 BIG-IPローカルトラフィックマネージャ(以下LTMと表記)の設定を、NGINX Plusソフトウェア・アプリケーション配信プラットフォームに移行する方法を説明し、迅速な移行を実現するのに、最も一般的に使われている機能と設定をお伝えします。

 

NGINX PlusとBIG-IP LTMはどちらも、完全なリバースプロキシとロードバランサーとして機能するため、クライアントはアプリケーションとしてロードバランサーを認識し、バックエンドサーバーはクライアントとしてロードバランサーを認識します。これにより、トラフィックの優れた制御ときめ細かな取り扱いが可能になります。このガイドでは、基本的な負荷分散に重点を置いています。レイヤ7ロジックとスクリプトを使用した設定の拡張については、NGINXブログのレイヤ7ロジックの移行(英語)に関する記事を参照してください。コンテンツの切り替えやリクエストのルーティング、書き換え、リダイレクトなどの機能について取り上げています。

 

  • コミュニティ版NGINXとNGINX Plusについて
  • NGINX Plusデプロイメント・シナリオ
  • 前提条件
  • BIG-IP LTMのネットワーク概念をNGINX Plusにマッピングする
  • F5 BIG-IP LTMロードバランサー設定からNGINX Plusへの変換
    • 仮想サーバー
    • SSL / TLSオフロード(ターミネーションおよびプロキシ)
    • セッションの永続性
    • Keepalive接続
    • モニター(ヘルスチェック)
  • 変換されたロードバランサー構成のまとめ

コミュニティ版のNGINXとNGINX Plusについて

コミュニティ版のNGINXは、オープンソースのWebサーバー、リバースプロキシ、およびロードバランサーで、近年そのスケーラビリティにより普及してきています。当初、C10K問題(クライアント1万台問題:単一のWebサーバー上で10,000の同時接続を処理することができない問題)を解決するために作られましたが、その機能と性能で、多くの高性能サイトが頼る解決策となっています。今や、NGINXは世界で最もアクセスされている10万ウェブサイトの大部分で利用されています。(英語)

NGINX Plusは、コミュニティ版NGINXの商用サポート版です。完全なソフトウェア・ロードバランサー兼アプリケーション配信プラットフォームで、大規模なウェブアプリケーションの構築には欠かせない多くのエンタープライズ対応機能があり、コミュニティ版NGINXの能力を拡張しています。

 

 

NGINX Plusデプロイメント・シナリオ

構造的に言えば、NGINX Plusは設置場所と機能の点で、従来のADCとは異なります。一般的なハードウェアベースのADCは、通常ネットワークエッジに配置され、すべてのアプリケーショントラフィックのフロントドア・エントリーポイントとして機能します。ネットワークに入ってくるトラフィックの100%を処理するという大きな負担を想定して、大規模なハードウェアADCがパブリックDMZとプライベートDMZにまたいで置かれることは珍しくありません。またこの環境下で、ADCがすべてのアプリケーション(セキュリティー、可用性、最適化、認証など)トラフィックにかかわる、すべての機能を担っていることもよくありますが、これには非常に大きく強力なハードウェアアプライアンスが必要になります。このモデルの欠点は、ADCが常にネットワークの「フロントドア」に固定されてしまっていることです。

 

インフラストラクチャーの更新や、アプリケーション配信に取り組む時、多くの企業がハードウェアのエッジに置かれたADCの機能を削ぎ落とし、より分散したアプリケーションモデルに移行しています。旧来のハードウェアADCはすでにネットワークエッジに位置しているため、すべての入力トラフィック管理を引き続き処理し、アプリケーショントラフィックを種類ごとに適切なNGINX Plusインスタンスに誘導できます。NGINX Plusは各アプリケーションタイプのトラフィックを処理して、オンプレミスでもオフプレミスでもネットワーク全体に対し、アプリケーション中心のロードバランシングと高可用性を実現します。NGINX Plusはアプリケーションの近くに配置され、各アプリケーションタイプに固有のすべてのトラフィックを管理できます。

NGINX PlusはBIG-IP LTMの後ろで稼働し、アプリケーショントラフィックを処理します

また、ネットワークエッジに固定された、ハードウェアADCアプライアンスを完全にNGINX Plusに置き換え、そこで同レベルのアプリケーション配信を実現した企業もあります。


NGINX Plus
でハードウェアADCを完全に置き換え、ネットワークに入るすべてのトラフィックを処理することができます

前提条件

このガイドは、F5 BIG-IP LTMの概念とCLI設定コマンドを知っていることを前提としています。基本的なNGINXソフトウェアの概念とディレクティブの知識に役立ちます。各ドキュメンテーションへのリンクは以下の通りですが、そのガイドではNGINX Plusについて詳細な説明はしていません。

 

F5 BIG-IP LTMのネットワーク概念をNGINX Plusにマッピングする

ネットワーク・アーキテクチャー

F5 BIG-IP LTMネットワーキングとロードバランサーの設定をNGINX Plusに移行するとき、F5のコンセプトやコマンドを、NGINX Plusの構文に直接変換してみたくなるかもしれません。しかし、大概は不満な結果に陥ります。理由としては、この2製品はどのようにネットワークやアプリケーショントラフィックを捉え、処理するかという点で、いくつかの領域であまり一致していないからです。相違点を理解し、移行を行う際にはその点を覚えておくことが重要です。

 

F5は、ネットワークを2つの部分に分割します。つまり、管理ネットワーク(管理プレーンまたは制御プレーンと呼ばれます)とアプリケーショントラフィック・ネットワークデータプレーンと呼ばれます)です。従来のアーキテクチャーでは、管理ネットワークはトラフィックネットワークから分離され、別の内部ネットワークを介してアクセス可能であり、アプリケーションネットワークは公衆ネットワーク(または別のアプリケーションネットワーク)に接続されます。これには、2種類のトラフィックのそれぞれに別々のネットワーク構成が必要です。

 

BIG-IP LTMアプライアンスはデュアルプロキシ環境であり、データプレーントラフィックも2つの異なるネットワークに分かれていることを意味します。つまり、クライアントリクエストがBIG-IP LTMに入ってくるクライアント側のネットワークと、リクエストがアプリケーションサーバーに送信されるサーバー側のネットワークです。BIG-IP LTMには通常、各ネットワークを処理するために2つのネットワークインターフェースカード(以下NICと表記)が必要です。

 

しかし、BIG-IP LTMのアプライアンスで、データプレーンをシングルスタックプロキシアーキテクチャに結合し、1つのNIC上にクライアントとサーバーのネットワークをまとめることは可能です。これは、トラフィックがBIG-IP LTMデータプレーンに入り、同じ仮想NICを介して出てくるクラウド環境では、非常に典型的なアーキテクチャーです。ネットワーク・アーキテクチャーにかかわらず、ロードバランシングと同じ基本原理が適用され、以下で説明する構成はどちらのアーキテクチャーレイアウトでも機能します。

 

NGINX Plusは、以下の2つの似たアーキテクチャーで機能することができます。ホストデバイスで使用可能な1つのNICに複数のIPサブネット(「/(プレフィックス)」 または「VLAN」で分割)をバインドする方法か、複数のNICをインストールし、それぞれを固有のクライアントおよびサーバーネットワークに使う、または複数のクライアントネットワークと複数のサーバー側のネットワークをインストールする方法です。これは本質的に、BIG-IP LTMアプライアンスがどのように機能するかと同じです。通常、仮想NICにトランク接続またはバインドできる複数のNICが搭載されています。

 

ネットワーキングの概念の定義

基本的なF5 BIG-IP LTMネットワーク構成では、管理およびデータプレーンのIPアドレスを指定するだけで済みますが、BIG-IP LTMアプライアンスを含むより複雑なネットワーク環境を管理するには、いくつかの追加の概念が必要です。これらのコンセプトはすべて

簡単に簡略化が出来、NGINX Plusインスタンスにマッピングできます。BIG-IP LTMの主なネットワーキング概念で、NGINX Plusと関連するものは以下のとおりです。

 

  • Self IPアドレス– 特定のVLAN上の着信クライアント側データプレーントラフィックをlistenするプライマリインターフェース。これは、そのVLANまたはVLANグループに関連付けられた特定のNIC上の特定のIPアドレスまたはサブネットです。

 

NGINX Plusでは、Self IPアドレスがプライマリホストインターフェースに最も直接的にマップしますが、これはNGINX Plusがトラフィックプレーンのアプリケーションデータを管理するために使われるものです。一般的には、NGINX Plusは管理とデータトラフィック制御に基盤となるOSネットワーキングを利用しているため、Self IPアドレスはNGINX Plusデプロイメントで必要な概念ではありません。

 

  • 管理IPアドレス:ポートペア– BIG-IP LTMアプライアンスのIPアドレス:ポートの組み合わせは、GUIに加え、またはリモートSSHアクセスを介して管理するために使用されます。NGINX Plusに相当するのは、LinuxホストのIPアドレスで、通常はプライマリホストインターフェースです。アプリケーショントラフィックからリモートアクセスを分離する必要がある場合は、NGINX Plusが実行されているLinuxホストへの管理アクセスに別々のIPアドレスやNICを使用することは可能ですが、必須ではありません。

 

  • 仮想サーバー– BIG-IP LTMが、負荷分散されたアプリケーションのパブリック送信先IPアドレスとして使用するIPアドレス:ポートの組み合わせ。これは、例えばフロントエンド・アプリケーションのドメイン名と関連付けられている仮想サーバーのIPアドレス部分と、サービスに関連付けられているポート(HTTPアプリケーションの場合はポート80など)です。このアドレスは、クライアントリクエストと、フェールオーバーの際にはプライマリデバイスからセカンダリデバイスへのシフトを処理します。

 

NGINX Plusの仮想サーバーは、serverブロックを使用して設定されます。serverブロック内のlistenディレクティブは、クライアントトラフィックのIPアドレスとポートを指定します。

 

  • プールノードリスト– プールは、それぞれが同じアプリケーションまたはサービスをホストするバックエンドノードの集合であり、相互に入ってくる接続の負荷分散が行われます。プールは仮想サーバーに割り当てられているため、新しいリクエストが仮想サーバーに入ってくると、BIG-IP LTMは使用するバックエンドアプリケーションを認識できます。さらに、BIG-IP LTMはノードリストという用語で、異なるサービスの配列を指しますが、これはすべて同じトラフィックプロトコルを使用し、同じIPアドレスでホストされているが、異なるポート番号でlistenするものです(たとえば、168.10.10:8100,192.168.10.10:8200、および192.168.10.10:8300で3つのHTTPサービスなど)。

NGINX Plusは、BIG-IP LTMプールおよびノー​​ドリストの概念を、upstream構成ブロックに表示することで記述を統一しました。またそこで、バックエンドサーバーのグループにトラフィックを転送する、仮想サーバーのロードバランシングとセッションパーシスタンス(永続性)の方法も定義しています。NGINX Plusはノードリストの概念を必要としません。標準的なupstreamブロック設定は、同一IPアドレス上の複数サービスにとても簡単に対応できるためです。

 

これらのネットワーキングの概念に加えて、BIG-IP LTMからNGINX Plus に移行する際、考慮すべき2つの重要な技術カテゴリがあります。

 

  • iRules– iRulesは、独自のイベント駆動型のコンテンツスイッチング、およびトラフィック操作エンジン(TCLベース)で、BIG-IP LTMがデータプレーントラフィックのあらゆる面を制御するのに使います。iRulesは仮想サーバーに接続されており、URIに基づいたプールの選択、ヘッダーの挿入、JSESSIONIDとの親和性の確立など、あらゆるタイプのコンテンツの切り替えに必要です。iRulesはイベント駆動型で、新しいHTTPリクエストが仮想サーバーに送信されたり、サーバーがクライアントに応答を送信したりといった特定の基準が満たされたときに、新しい接続に対して起動するよう設定されています。

 

NGINX Plusは、コンテンツの切り替えやHTTPセッションの操作をネイティブに処理するため、ほとんどのコンテキストベースのiRulesとヘッダー操作などのHTTPトランザクションを処理するものを明示的に移行する必要はありません。ほとんどのコンテキストベースのiRulesは、serverおよびlocationブロックに変換することができ、NGINX Plusディレクティブおよびコンフィグレーションブロックで複製できない、より複雑なiRulesは、LuaまたはJavaScriptモジュールで実装できます。iRulesをNGINX Plusのコンテンツルールに変換する方法についての詳細は、NGINXブログのF5 iRulesおよびCitrixポリシーからNGINXおよびNGINX Plusへのレイヤ7ロジックの移行(英語)を参照してください。

 

  • 高可用性(ハイアベイラビリティ)– 概念的には、BIG-IP LTMとNGINX Plusは同じようにハイアベイラビリティ(以下HAと表記)を実現します。Active-Passiveロードバランサーの各組み合わせは、現在アクティブなインスタンスにマップされるフローティング “仮想” IPアドレス(以下VIPと表記)を共有します。アクティブなインスタンスに障害が発生すると、パッシブなインスタンスが肩代わりし、VIPを引き継ぎます。

 

BIG-IP LTMは、組み込まれたHAの仕組みを使い、フェールオーバーを行います。

 

オンプレミス構成では、NGINX Plusは別のソフトウェア・パッケージであるnginx-HA-keepalivedを使って、 VIPとNGINX Plusサーバーのアクティブ-パッシブのペアのフェールオーバープロセスを処理します。このパッケージはVIPを処理するVRRPプロトコルを実装しています。nginx-ha-keepalivedパッケージでは、限られたActive-Activeシナリオも可能です。

 

以下のように、クラウド環境でのNGINX Plusの高可用性ソリューションもあります。

 

(英語)

 

F5 BIG-IP LTMロードバランサー構成からNGINX Plusへの変換

 

 

F5 BIG-IP LTMには3つの設定方法があります。

  • GUI
  • CLI(カスタムのオンボックス トラフィック管理シェル[TMSH]ツール)
  • iControl API

 

最終的に、GUIまたはAPIを介して行うすべての変更はTMSH CLIコマンドに変換されるため、このガイドではTMSH CLIコマンドを使用します。また、(tmos.ltm)ロケーションからデバイスを設定していると仮定して、すべてのTMSHコマンドから、汎用コマンド変数であるltmを省略しています。

 

NGINX Plusを使用すると、設定は簡単なテキストファイルに保存されます。このファイルには、従来のオンボックスツールや設定管理、AnsibleChefPuppetなどのオーケストレーションツールを使って、直接アクセスまたは管理できます。

 

このガイドの例では、仮想サーバーを識別するのにIPアドレスだけを使っていますが、リクエストを処理する適切なserverブロックを選択する際、NGINX Plusは、listenするIPアドレスとポートの組み合わせに加え、Hostヘッダーを使用することもできます。ブロックにserver_nameディレクティブを含めて、Hostヘッダー内で一致する値を指定します。

 

server_nameディレクティブへのパラメーターのリストには、複数のホスト名、ワイルドカード、および正規表現を含めることができます。NGINX Plus の1つのserverブロックに、複数のserver_nameディレクティブと複数のリスニングIPアドレスとポートの組み合わせを含めることが可能です。IPアドレスの代わりにHost、およびserver_nameディレクティブを使う方法については、nginx.orgのサーバー名の項目をご覧ください。

 

注:このガイドのすべてのIPアドレスとオブジェクト名(upstreamブロック、仮想サーバー、プールなど)は単なる例ですので、代わりに、BIG-IP LTM設定の値を入力してください。

 

仮想サーバー

上記のように、仮想サーバーはBIG-IP LTMとNGINX Plus のプライマリーリスナーですが、それらを定義するための構成構文は全く異なります。ここでは、192.168.10.10の仮想サーバーがポート80でHTTPトラフィックをlistenし、test_pool上流グループにリストされている2つのバックエンドアプリケーションサーバー間で着信トラフィックを配信します。

 

BIG-IP LTM

#create pool test_pool members add {10.10.10.10:80 10.10.10.20:80}

#create virtual test_virtual { destination 192.168.10.10:80 pool test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

#save sys config

 

NGINX Plus

http {

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

}

 

server {

listen 192.168.10.10:80;

location / {

proxy_pass http://test_pool;

}

#…

}

}

 

ディレクティブのドキュメント(英語):listenlocationproxy_passserver(仮想)server(アップストリーム)upstream

 

SSL / TLSオフロード(ターミネーションおよびプロキシ)

 

SSL/ TLSターミネーションの処理は、ADCロードバランサーの一般的な使用例です。F5 BIG-IP LTMは独自のSSL / TLS実装をしています。NGINX Plusはシステムライブラリに依存しているため、OpenSSLのバージョンはOSによって規定されています。BIG-IP LTMでは、各SSL / TLSキーと証明書の組合せでのプロファイルを仮想サーバーに対して発行(クライアント着信/発信のトラフィックを暗号化するためのクライアントプロファイルか 、バックエンドのトラフィックを暗号化するためのサーバープロファイルのいずれか、または両方)されています。NGINX Plusでは、ssl_certificateおよび、 ssl_certificate_keyディレクティブは仮想サーバーのserverブロックに含まれています。

 

ロードバランサーインスタンス上でSSL / TLSトラフィック処理を行ったり、ターミネーションやプロキシするには、以下の2つの方法があります。

 

  • SSL / TLSターミネーションを用いたロードバランサーとクライアントでは暗号化されたHTTPSセッションで通信します。銀行のオンライン取引サイトのような、セキュアなアプリケーションがSSL / TLS証明書でクライアントの暗号化を行うのと同じ方法です。ロードバランサーは、クライアントメッセージを復号化した後(安全な接続を実質的に終了する)、平文(暗号化されていない)のHTTP接続を介してメッセージをバックエンドサーバーに転送します。逆方向では、ロードバランサーはクライアントに送信する前にサーバー応答を暗号化します。SSL / TLSターミネーションは、ロードバランサーとバックエンドサーバーがセキュリティー保護されたネットワーク上にある場合、すなわち外部のエージェントが平文のバックエンドトラフィックを傍受して読み取る危険性がなく、またアップストリームアプリケーションのパフォーマンスが最優先の場合には良い選択肢です。
  • SSL / TLSプロキシアーキテクチャーでは、ロードバランサーはターミネーションモデルと同じように、クライアント側トラフィックを復号化します。ただその後、バックエンドサーバーに転送する前に再暗号化します。これは、サーバー側のネットワークが安全でない場合、またはバックエンドサーバーがSSL / TLSの暗号化・復号化に伴うコンピューティング負荷を処理できる場合には適しています。

 

BIG-IP LTM

  • SSL / TLSのターミネーションとプロキシ:SSL / TLS仮想サーバーとプールメンバーの作成

# create pool ssl_test_pool members add { 10.10.10.10:443 10.10.10.20:443 }

# create virtual test_ssl_virtual { destination 192.168.10.10:443 pool ssl_test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

# save /sys config

 

  • SSL / TLSターミネーション:クライアントSSL / TLSプロファイルの作成

 

  • # create profile client-ssl test_ssl_client_profile cert test.crt key test.key
  • # modify virtual test_ssl_virtual profiles add { test_ssl_client_profile }
  • # save /sys config

 

  • SSL / TLSプロキシ:サーバーSSL / TLSプロファイルの作成

 

# create profile server-ssl test_ssl_server_profile cert test.crt key test.key

# modify virtual test_ssl_virtual profiles add { test_ssl_server_profile }

# save /sys config

 

NGINX Plus

  • SSL / TLSターミネーション

upstream ssl_test_pool {

server 10.10.10.10:443;

server 10.10.10.20:443;

}

 

server {

listen 192.168.10.10:443 ssl;

ssl_certificate     /etc/nginx/ssl/test.crt;

ssl_certificate_key /etc/nginx/ssl/test.key;

 

location / {

proxy_pass http://ssl_test_pool;

}

}

 

  • SSL / TLSプロキシ

upstream ssl_test_pool {

server 10.10.10.10:443;

}

 

server {

listen 192.168.10.10:443 ssl;

ssl_certificate     /etc/nginx/ssl/test.crt;

ssl_certificate_key /etc/nginx/ssl/test.key;

 

location / {

proxy_pass https://ssl_test_pool;

proxy_ssl_certificate /etc/nginx/ssl/client.pem;

proxy_ssl_certificate_key /etc/nginx/ssl/client.key;

proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

proxy_ssl_ciphers HIGH:!aNULL:!MD5;

proxy_ssl_trusted_certificate /etc/nginx/ssl/trusted_ca_cert.crt;

proxy_ssl_verify on;

proxy_ssl_verify_depth 2;

}

}

 

ディレクティブのドキュメント(英語):listenlocationproxy_passproxy_ssl*server(仮想)server(アップストリーム)ssl_certificateおよびssl_certificate_keyupstream

 

セッション・パーシステンス(永続性)

F5 BIG-IP LTMとNGINX Plus は、アップストリームサーバー(BIG-IP LTMプールまたはNGINX Plus upstreamブロック)で、いずれもセッション永続性(親和性とも呼ばれます)を似たような方法で処理し、同等レベルの設定ができます。どちらも複数の形態のパーシステンスをサポートします。セッション・パーシステンスは、セッション状態を保持するアプリケーションには重要で、継続的デリバリーの用途に役立ちます 。

Cookieベースのセッション・パーシステンス

アプリケーションと互換性がある場合、NGINX Plusのフェールオーバーを簡単に設定して処理する方法の1つに、スティッキークッキーがあります。これはBIG-IP LTMのCookie Insertメソッドと同じように機能します。つまり、ロードバランサーはサーバーを表すクッキーを作成し、クライアントは各リクエストにクッキーを含め、ロードバランサー自体からセッショントラッキングを効果的に負荷軽減します 。

 

  • BIG-IP LTM:HTTP クッキー・パーシステンス

# create persistence cookie test_bigip_cookie cookie-name BIGIP_COOKIE_PERSIST expiration 1:0:0

# modify virtual test_virtual { persist replace-all-with { test_bigip_cookie } }

# save /sys config

 

  • BIG-IP LTM:HTTPSクッキー・パーシステンス

# create persistence cookie test_bigip_cookie cookie-name BIGIP_COOKIE_PERSIST expiration 1:0:0

# modify virtual test_ssl_virtual { persist replace-all-with { test_bigip_cookie } }

# save /sys config

 

 

  • NGINX Plus:HTTP クッキー・パーシステンス

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

sticky cookie mysession expires=1h;

}

 

  • NGINX Plus:HTTPS クッキー・パーシステンス

upstream ssl_test_pool {

server 10.10.10.10:443;

server 10.10.10.20:443;

sticky cookie mysession expires=1h;

}

 

ディレクティブのドキュメント(英語):serversticky cookieupstream

送信元IPアドレスベースのセッション・パーシステンス

セッション・パーシステンスの別の形態は、リクエストパケットに記録されている送信元IPアドレス(リクエストしているクライアントのIPアドレス)に基づいています。ロードバランサーはリクエストごとにIPアドレスでハッシュを計算し、そのハッシュに関連付けられているバックエンドサーバーにリクエストを送信します。特定のIPアドレスのハッシュは常に同じなので、同じハッシュのリクエストはすべて同じサーバーに送られます。(NGINX Plusの実装の詳細については、ブログでNGINX Plusの負荷分散手法選択する(英語)を参照してください)。

 

  • BIG-IP LTM

#modify virtual test_virtual {persist replace-all-with {source_addr}}

#save / sys設定

  • NGINX Plus

upstream test_pool {

ip_hash;

server 10.10.10.10:80;

server 10.10.10.20:80;

}

ディレクティブのドキュメント(英語):ip_hashserverupstream

 

トークンベースのセッション・パーシステンス

セッション・パーシステンスのもう1つの方法は、バックエンドサーバーがセッション内で生成するCookieやjsessionidといった他のトークンを利用します。Jsessionidの作成や追跡を管理するために、NGINX Plusは特定のバックエンドサーバーとCookie値を照合してメモリー内にテーブルを作成します。

 

  • BIG-IP LTM

BIG-IP LTMは、高度なiRuleを作成しない限り、学習した(またはユニバーサルな)パーシステンスプロファイルをネイティブでサポートしていませんので、本ドキュメントでは対象としません。

 

  • NGINX Plus

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

sticky learn create=$upstream_cookie_jsessionid

lookup=$cookie_jsessionid

zone=client_sessions:1m;

}

ディレクティブのドキュメント(英語):serversticky learnupstream

 

keepalive接続

通常、別のHTTPセッションが作成され、接続ごとに破棄されます。Webサーバーから少量のコンテンツを要求するなど、短時間の接続では問題無いかもしれませんが、長時間の接続ではとても非効率になりえます。セッションや接続を絶え間なく作成・破棄していると、アプリケーションサーバーとクライアントの両方に負荷が掛かってページの読み込みが遅くなり、Webサイトやアプリケーションのパフォーマンスに対する全体的な印象が損なわれる可能性があります。ロードバランサーに対し、セッション用の接続を開いたままにするよう指示するHTTP keepalive接続は、Webページをより高速にロードするためには必要なパフォーマンス機能です。

 

BIG-IP LTM

# modify virtual test_virtual profiles add { oneconnect }

# modify virtual test_ssl_virtual profiles add { oneconnect }

# save /sys config

 

NGINX Plus

upstream test_pool {

server 10.10.10.10:80;

server 10.10.10.20:80;

keepalive 32;

}

ディレクティブのドキュメント(英語):keepaliveserverupstream

モニター(ヘルスチェック)

F5 BIG-IP LTMはモニターという用語で、サーバーが正常に機能していることを確認するプロセスを指しますが、NGINX Plusではヘルスチェックという用語を使います。BIG-IP LTM構成では、モニターはプールに直接関連付けられ、プール内の各ノードに割り当てられますが、NGINX Plusではlocationブロックにヘルスチェックを配置します。

 

以下のBIG-IP LTM createコマンドに対するInterval引数は、5秒ごとにサーバーをチェックするようにBIG-IP LTMを設定します。これはNGINX Plusの初期設定でのチェック頻度に相当します。NGINX Plusは、intervalおよびfailsパラメーターを使用してタイムアウト機能を実装するため、BIG-IP LTM timeoutパラメーターは必要ありません。

注:このBIG-IP LTM設定はHTTP用です。HTTPSの場合は、createとmodifyコマンドの両方でtest_ssl_monitorをtest_monitorに置き換えてください。同じNGINX Plus設定は、HTTPとHTTPSの両方で機能します。

 

BIG-IP LTM

# create monitor http test_monitor defaults-from http send “GET /index.html HTTP/1.0\r\n\r\n” interval 5 timeout 20

# modify pool test_pool monitor test_monitor

# save /sys config

NGINX Plus

upstream test_pool {

# …

zone test_pool_zone 64k;

}

 

server {

# …

location / {

proxy_pass http://test_pool;

health_check interval=5 fails=2;

}

}

ディレクティブのドキュメント(英語):health_checklocationproxy_passserverupstreamzone

 

変換されたロードバランサー構成のまとめ

ここでは、構成要素をまとめて基本的なF5 BIG-IP LTM環境を構築するために必要な構成と

NGINX Plusに移行するための同じ設定方法の詳細を記載します。

 

BIG-IP LTM

# create pool test_pool members add { 10.10.10.10:80 10.10.10.20:80 }

# create virtual test_virtual { destination 192.168.10.10:80 pool test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

# create pool ssl_test_pool members add { 10.10.10.10:443 10.10.10.20:443 }

# create virtual test_ssl_virtual { destination 192.168.10.10:443 pool ssl_test_pool source-address-translation { type automap } ip-protocol tcp profiles add { http } }

# create profile client-ssl test_ssl_client_profile cert test.crt key test.key

# modify virtual test_ssl_virtual profiles add { test_ssl_client_profile }

# create profile server-ssl test_ssl_server_profile cert test.crt key test.key

# modify virtual test_ssl_virtual profiles add { test_ssl_server_profile }

# create persistence cookie test_bigip_cookie cookie-name BIGIP_COOKIE_PERSIST expiration 1:0:0

# modify virtual test_virtual { persist replace-all-with { test_bigip_cookie } }

# modify virtual test_ssl_virtual { persist replace-all-with { test_bigip_cookie } }

# modify virtual test_virtual profiles add { oneconnect }

# modify virtual test_ssl_virtual profiles add { oneconnect }

# create monitor http test_monitor defaults-from http send “GET /index.html HTTP/1.0\r\n\r\n” interval 5 timeout 20

# modify pool test_pool monitor test_monitor

# create monitor https test_ssl_monitor defaults-from https send “GET /index.html HTTP/1.0\r\n\r\n” interval 5 timeout 20

# modify pool ssl_test_pool monitor test_ssl_monitor

# save /sys config

 

 

NGINX Plus

以下の構成には、これまで説明していなかった3つの追加ディレクティブが含まれています。トラフィックを

プロキシするときは、これらを追加することがベストプラクティスです。

 

  • proxy_set_headerHost $hostディレクティブは、クライアントから受信したHostヘッダーがリクエストとともにバックエンドサーバーに送信されるようにします。
  • proxy_http_versionディレクティブは、バックエンドサーバーへの接続用にHTTPバージョンを1に設定します。
  • proxy_set_header Connection “”ディレクティブは、NGINX Plusがアップストリームサーバーへの暗号化されたkeepalive接続を維持できるように、Connectionヘッダーをクリアします。

 

また、最後のserverブロックでライブアクティビティのモニタリングも可能にしています。ライブアクティビティのモニタリングは、NGINX Plus APIモジュールで実装される、NGINX Plus限定の機能です。APIがレポートする幅広い統計情報は、組み込みダッシュボードに表示され、JSON形式のメッセージを理解するすべてのアプリケーションパフォーマンス管理(APM)または監視ツールにエクスポートすることができます。ロギングとモニタリングの詳細については、「NGINX Plus管理者ガイド」(英語)を参照してください。

 

upstream test_pool {

zone test_pool_zone 64k;

server 10.10.10.10:80;

server 10.10.10.20:80;

sticky cookie mysession expires=1h;

keepalive 32;

}

 

upstream ssl_test_pool {

zone ssl_test_pool_zone 64k;

server 10.10.10.10:443;

server 10.10.10.20:443;

sticky cookie mysession expires=1h;

keepalive 32;

}

 

server {

listen 192.168.10.10:80 default_server;

proxy_set_header Host $host;

 

location / {

proxy_pass http://test_pool;

health_check;

proxy_http_version 1.1;

}

 

location ~ /favicon.ico {

root /usr/share/nginx/images;

}

}

 

server {

listen 192.168.10.10:443 ssl default_server;

ssl_certificate     test.crt;

ssl_certificate_key test.key;

proxy_set_header    Host $host;

 

location / {

proxy_pass https://ssl_test_pool;

proxy_http_version 1.1;

proxy_set_header Connection “”;

health_check;

}

 

location ~ /favicon.ico {

root /usr/share/nginx/images;

}

}

 

server {

listen 8080;

status_zone status-page;

root /usr/share/nginx/html;

 

location /api {

api write=on;

# directives controlling access, such as ‘allow’ and ‘deny’

}

 

location = /dashboard.html {

root /usr/share/nginx/html;

}

 

# Redirect requests made to the old (pre-R14) dashboard

location = /status.html {

return 301 /dashboard.html;

}

 

location ~ /favicon.ico {

root /usr/share/nginx/images;

}

}

改訂履歴

  • バージョン2(2018年4月) – 高可用性とNGINX Plus APIに関する情報(NGINX Plus R13、NGINX Open Source 1.13.4)
  • バージョン1(2017年2月) – イニシャル・バージョン(NGINX Plus R11、NGINXオープンソース11.5)

NGINX Plus 対 F5 BIG-IP:価格・性能比較

※本記事はNGINX,Inc.のブログ記事「NGINX Plus vs. F5 BIG‑IP: A Price‑Performance Comparison」を和訳した内容となります。
【URL】
https://www.nginx.com/blog/nginx-plus-vs-f5-big-ip-a-price-performance-comparison/

最近、AppNexusIgnitionOneをはじめとする多くのお客様が、主流のハードウェアであるアプリケーション デリバリー コントローラー(以下ADCと表記)アプライアンスをNGINX Plusに置き換え、多大なコスト削減と大幅なパフォーマンス向上を実現しています。他にも巨大なWeb資産を持つ複数の企業が、ADC機能のソフトウェア実装(SSL / TLS暗号化のような、歴史的にハードウェア集約の機能だったものを含む)を行い、必要とする作業負荷に対し、十分以上に速いということを証明しています。

当社はベアメタルサーバー上で、NGINX Plusのパフォーマンスを測定した各種テストの結果(英語)に基づき、NGINXサイジングガイド(英語)を発行しました。
この記事では、これらのパフォーマンス計測値を3つのサイズで、F5ハードウェア アプライアンス
の公開計測値と比較します。

私たちのテストによれば、汎用ハードウェアで動くNGINX PlusはF5 BIG-IPアプライアンスの性能を満たすか、しばしば凌駕しつつ、最大83%のコスト削減を達成しています。

ハードウェアADCをNGINX Plusに置き換える方法の詳細については、以下のリソースを
参照してください。

ブログの投稿

移行ガイド

このブログでは、次の3つの単純で明白なパフォーマンス指標を比較します。

  • HTTPリクエスト/秒(RPS)
  • SSL / TLSトランザクション/秒(TPS)
  • HTTPスループット

各指標の詳細は、「パフォーマンス指標」の項を参照してください。

F5アプライアンスの数値は、公表されたデータシート(英語)ものと、2つのデータ元(CDW(英語)とCarahsoft(英語))の価格情報から、NGINX Plusのパフォーマンス数値はサイジングガイドのものを使っています。NGINX Plusのハードウェア費用は、テスト結果を達成したIntelハードウェアと同じ仕様のDell PowerEdgeサーバーの定価に基づいています。

注:表に記載されている費用は、記事の公開時点のもので、変更される可能性があります。

では、さっそく調査結果を見てみましょう。

NGINX Plus 対 F5 BIG-IP 2000S

以下の表では、F5のエントリーレベルのアプリケーション デリバリー コントローラーであるF5 BIG-IP 2000Sと、2つの異なるベアメタルサーバー上で動作するNGINX Plusを比較しています。

  • DellのPowerEdge R230 4コア Intel®Xeon®E3-1220 V5 3.0GHzのCPUと Intel XL710 2×40
    GbE NIC
  • DellのPowerEdge R430 8コア Intel®Xeon®プロセッサー E5-2630 V3 2.4GHzのCPUとIntel XL710 2×40 GbE NIC

NGINX Plusはスループットに人為的な上限を課していません。つまり、購入したハードウェアの全性能を使用することになります。

NGINX Plus 対 F5 BIG-IP 5050S

以下の表では、中規模のBIG-IPアプライアンスであるF5 BIG-IP 5050Sと、同等サイズのベアメタルサーバー、デュアル16コアIntel®Xeon®E5-2697A v4 2.6GHz CPUおよびIntel XL710 2×40 Gbe NIC搭載のDell PowerEdge R630 上で動作するNGINX Plus とを比較しています。

NGINX Plus 対 F5 BIG-IP 11050

以下の表では、ハイエンドのBIG-IPアプライアンスF5 BIG-IP 11050 と2つのNGINX Plusインスタンス、それぞれがデュアル18コア Intel®Xeon®E5-2699 v3 2.3GHz CPUとIntel XL710 2×40Gbe NICを搭載したDell PowerEdge R630で動作するものを比較しています。 1つのNGINX Plusインスタンスは1秒間に最大120万件のリクエストを処理できるため、2インスタンスではおおむねBIG-IP 11050とほぼ同じ性能となり、毎秒最大250万件のリクエストを処理できます。

最新のSSL / TLS要件のレポート結果

現在のSSL / TLSベストプラクティスに従って、楕円曲線ディフィー・ヘルマン鍵共有(Ephemeral Elliptic Curve Diffie-Hellman:以下ECDHEと表記)、AES、およびSHA384を使用するECDHE-RSA-AES256-GCM-SHA384暗号スイートを使い、NGINX PlusのSSL / TLSトランザクション/秒(以下TPSと表記)を計測しました。また、F5データシートの性能値との有効な比較のため、RSA 2048ビットキーを使用しました。

この暗号は秘密鍵が漏洩された場合でも、今、暗号化されたトラフィックがキャプチャーされても、後から解読できないようにするPerfect Forward Secrecy(以下PFSと表記)を提供します。PFSは現在のセキュリティー環境において、「必須」となっています。たとえば、AppleはiOS9アプリがPFSを使用して通信することを義務づけています。

F5は、データシートのパフォーマンステストで使用している暗号は明らかにしておらず、また以前のF5ベンチマークでは、パフォーマンス上不利になるPFSが使用されていませんでした。F5は、ほとんどのプラットフォームで、ソフトウェアECDHE暗号を実装しています。

お読みいただく際には、異なる暗号を使うと、セキュリティーとスピードの間でトレードオフが生じる場合に、SSLのパフォーマンスを比較することの課題についてはご留意ください。

結論

当社のお客様は、ハードウェアアプライアンスから同等のNGINX Plusソリューションに切り替える際、大幅なコスト削減を行えたとしています。また、私たちのパフォーマンス測定と価格分析はこれを裏付けています。私たちが調べたシンプルなユースケースでは、1年目で80%から84%のコスト削減が見られました。

NGINX Plusはどう違うのでしょうか?ソフトウェアにハードウェアをバンドルしていませんし、当社のソフトウェアには人為的なパフォーマンス制限を課していません。自社のニーズに対し最も費用対効果の高いハードウェアを、自由に選択してください。社内規格に適合しないハードウェアを受け入れるよう強制するものではありませんし、2〜3年後に発生する可能性のあるトラフィック増加やアプリケーションの複雑化を見越して、過剰なハードウェアを今、見積もっておく必要もありません。

最後に、複数利用のハードウェア ロードバランサーのコストに対しては、アプリケーション全体でNGINX Plusサブスクリプションを取得できます。アプリケーション価格、お客様のアプリケーション全体、つまりロード・バランシング、キャッシング、ウェブやメディアサービスなど、また本番、テスト、開発環境全体すべてをサポートする無制限のNGINX Plusインスタンスをお使いいただけます。NGINXサポートチームのエキスパートが支援するアプリケーション配信スタック全体で、標準的で信頼できるテクノロジーを使用したなら、
運用とアプリケーションの配信コストにどのような影響があるでしょうか?

NGINX Plusのパフォーマンスを評価するには、すぐに無料の30日間のトライアルを開始するか、ライブデモをご依頼ください

付録 テストの詳細

このコスト比較を作成するため使用したデータは、複数のデータ元から集めたものです。

  • NGINX Plusのテストは、すべてそれぞれ36コアのCPUを1つ搭載した3台のサーバーを使用して行いました。サーバーは、標準的なクライアント→プロキシ→サーバー・トポロジーで構成されていました。
  • 異なる数のCPUコアで計測値を取るために、使用するCPUコアの数を変更しています。
  • BIG-IPアプライアンスのハードウェア仕様とパフォーマンス値は、F5 BIG-IPのデータシートから得られたものです(自分たちでF5ハードウェアのテストはしていません)。

NGINX Plusのベンチマークに使用したハードウェアは、Intel社より貸与いただきました。テストの実行方法の詳細については、このブログを参照してください。

パフォーマンス指標

このレポートでは、以下のパフォーマンス指標を比較しています。

  • 1秒当たりリクエスト(RPS)  – HTTP要求を処理する能力を測定します。NGINX Plusのテストでは、クライアントはkeepalive接続でリクエストを送信します。NGINX Plusは各リクエストを処理し、別のkeepalive接でWebサーバーに転送します。
  • SSL / TLS 1秒当たりトランザクション(TPS)  – 新しいSSL / TLS接続を処理する能力を測定します。NGINX Plusのテストでは、クライアントは新しい接続で、一連のHTTPSリクエストを送信します。NGINX Plusは各リクエストを解析し、別の確立されたkeepalive接でWebサーバーに転送します。Webサーバーは、各リクエストに対して0バイトの応答を返します。
  • スループット  – HTTP経由で大容量のファイルを処理する場合に発生するスループットを測定します。

ご使用の環境でNGINX Plusがどのように機能するかを確認するには、今すぐ無料の30日間のトライアル開始するか、ライブデモをご依頼ください。

 

F5 BIG-IPからNGINX Plusに切り替える5つの理由

※本記事はNGINX,Inc.のブログ記事「5 Reasons to Switch from F5 BIG-IP to NGINX Plus」を和訳した内容となります。
【URL】
https://www.nginx.com/blog/5-reasons-switch-f5-big-ip-to-nginx-plus/

 

2016年、NGINX Plusの価格と性能をF5 BIG-IPアプリケーション デリバリー コントローラー(以下ADCと表記)の複数モデルと比較しました。NGINX Plusに切り替えることで、F5アプライアンスのパフォーマンスと同等、またはそれ以上のパフォーマンスを達成しながら、1年目から80%以上のコストを節約できます。

ADCをNGINX Plusに置き換える方法については、以下のリソースをご覧ください。

NGINX,INC ブログの投稿

 

 

移行ガイド

 

 

 

BIG-IP ADCは、ASICでレイヤ4のロードバランシング(英語)を行うなど、カスタムハードウェアを使っているため高価です。以前は、コモディティサーバーでは同等のプロセッサー性能を実現できないか、実現できてもはるかに高価だったため、ロードバランシング用のカスタムハードウェアは費用対効果の高い方法でした。しかし最近では、サーバーは大幅に安く、高速化しているため、いまやカスタムハードウェアは割高な選択肢になっています。

またF5は、ハードウェアアプライアンスを作ることに集中するあまり、現代的なアプリケーションのニーズ、つまりソフトウェアだけが実現できる柔軟性を取り入れませんでした。一方、NGINX Plusが提供するものは、現代のアプリケーションや今日のITインフラストラクチャー、特にクラウドDevOpsのニーズに合わせて設計された、ソフトウェアロードバランサーとアプリケーション配信プラットフォームです。ソフトウェアとしてNGINX Plusは、レイヤー7の機能と柔軟性のある現代的なアプリケーションという、開発者と運用チームが必要とするものを提供できる点で優れています。 

 

このブログ記事では、NGINX Plusの5つの固有の機能を紹介しています。これは、F5 BIG-IPのADCからは得られないものです。

  1. サービス・ディスカバリーの統合(英語)  – マイクロサービスを使用するアプリケーションは、NGINX Plusの最先端機能である、洗練されたサービス・ディスカバリー機能が必要です。
  2. 静的コンテンツの提供(英語) – F5 BIG-IPでは静的コンテンツを提供することはできませんが、NGINX Plusの核となる機能です。
  3. ARMサーバーでベアメタルを実行する(英語)  – ARMサーバーはエネルギーコストを節約します。NGINX PlusはネイティブでARM上で動作しますが、F5 BIG-IPではARMは動作しません。
  4. Dockerコンテナの中で実行(英語)  – Dockerを使うと、アプリケーションの開発、デプロイ、管理が非常に簡単になるため、急速に人気が高まっています。NGINX PlusはDockerコンテナ内でスムーズに動作します。
  5. 再起動いらずのアップグレード – アップグレードは、絶え間ない作業のように見えるかもしれません。NGINX Plusがあれば、アップグレード中でも、絶え間ないアップタイムを実現できます。

1.サービス・ディスカバリーの統合

2016年に実施した調査によると、組織の68%以上がマイクロサービスを利用または調査しています。マイクロサービスを調べると、最大の課題の1つにサービスの検出があることがわかるでしょう。マイクロサービスベースのアーキテクチャーでは、サービスにはIPアドレスとポートが動的に割り当てられます。つまり、サービスの場所は予測できません。サービスにアクセスできるようにするには、ConsuletcdZooKeeperなどの「サービスレジストリー」にIPアドレスとポートを登録する必要があります。トラフィックをサービスに送信する必要のあるクライアント(NGINX Plusなど)は、サービスレジストリーにクエリして、サービスのIPアドレスとポートを取得します。

 

NGINX Plusは、DNS SRVレコードを使って、マイクロサービス環境でサービス・ディスカバリーを実行できます

 

サービスレジストリーは、DNS SRVレコードの形式でサービスのロケーション情報を提供します。DNS SRVレコードは、動的に割り当てられるポート番号を含む点で、標準的なDNSレコードとは異なります。マイクロサービスベースのアプリケーション向けロードバランサーは、サービスレジストリーが提供するDNS SRVレコードから、IPアドレスとポート情報を抽出できる必要があります。

 

このスニペットでは、NGINX Plusがサービスレジストリーを照会し、応答されたDNS SRVレコードを解析するように設定しています。

 

resolver service-registry-address;

 

upstream my_service {

   zone backend 64k;

   server service-hostname service=http resolve;

}

 

server {

   # …

   location /my_service {

       # …

       proxy_pass http://my_service;

   }

}

 

serverディレクティブの最初のパラメーターとして、サービスのresolverディレクティブとホスト名で、サービスレジストリーのIPアドレスを指定します。このservice=httpパラメーターはDNS SRVレコードの解析を有効にし、resolveパラメーターはNGINXが定期的にホスト名を再解決するよう指示します。ここでは、DNSレコードに含まれたデフォルトの期間、生存期間(TTL)を使います。validパラメーターを使えば、resolverディレクティブに別の期間を設定することもできます。

 

サービスのコピーが複数ある場合、サービスレジストリーは単一のDNS SRVレコード内のすべてのサービスのIPアドレスとポートを返します。その場合、NGINX Plusはサービス間のトラフィックを負荷分散します。

 

F5 BIG-IPはDNS SRVレコードを解析できないため、マイクロサービス環境でのトラフィックのロードバランシングを行うことはできません。

 

2.静的コンテンツの提供

NGINX Plusは、アプリケーションの負荷を分散し、コンテンツをキャッシュし、監視することができます。また、静的コンテンツのオリジンサーバーにすることもできます。NGINX Plusは、コミュニティー版のNGINXソフトウェアの上に構築され、静的なコンテンツをユーザーに配信するために4億9,000万以上のWebサイトで使用されています。静的コンテンツには、画像、CSS、JavaScript、およびWebページを構成するその他のアセットが含まれます。

 

「私はただのロードバランサーは望んでいませんでした。静的なコンテンツも提供したいと思っていたのです。そのため、 私の製品検索は、すぐにNGINX Plusに絞られました。」

– Dan Chamberlain、プリンシパルアーキテクト、Bluestem Brands

 

以下の構成スニペットで、NGINX Plusがwww.example.com/images/image.jpgへのリクエストを受信すると、要求者に対して、/path/to/images/image.jpg ファイルを返します。

server {

   server_name www.example.com;

   # …

   location /images {

        alias /path/to/images;

   }

}

F5 BIG-IPは、NGINX Plusのようにコンテンツのロードバランスとキャッシュは行えますが、静的なコンテンツは配信できません。F5を使用すると、Apache、NGINX、またはIISを実行する別のWebサーバーを立てる必要があります。

 

 

3.ARMサーバーでベアメタルを実行する

ARMプロセッサーは、低消費電力が要件となる、スマートフォンやその他のモバイル機器向けとしてよく知られています。でも、データセンターでARMサーバーを使用すれば、高パフォーマンスを維持しながら、エネルギー消費を削減できることまでは知られていないかもしれません。半導体チップメーカーのAMDは、2020年までにARMサーバーの市場シェアが20%になると予測しています。

 

NGINX,Inc.は、ARMバージョンのUbuntu Linux 14.04 / 16.04 LTSを搭載したARMサーバー上で動作するNGINX Plusを完全にサポートしています。インストール手順、構成、および機能セットはすべてx86バージョンと同じで、ARMサーバーへの移行はスムーズです。(ARMサーバーに加えて、NGINX Plusはx86およびPowerPC [ppc64_le]サーバー(IBM POWER8など)で動作します。

 

F5 BIG-IPは、プロプライエタリーなx86ベースのアプライアンスのみ、またはVMWare ESXiなどのハイパーバイザーの助けを借りれば、汎用のx86サーバーで実行できます。

 

4.Dockerコンテナの中で実行

 

コミュニティー版NGINXはDocker Hubで最も頻繁にダウンロードされるアプリケーションの 1つで、これまでに1000万回以上ダウンロードされています。Dockerを使用してアプリケーションを構築する開発者は、アプリケーションスタックの重要な部分として、圧倒的にNGINXを選択しています。

 

NGINX Plusはまた、NGINX, Inc.がフルサポートするDockerコンテナ内で実行できます。Docker用に独自のNGINX Plusのイメージを構築する方法については、UbuntuとCentOS/ Oracle Linux / Red Hatシステム用のサンプルDockerファイルを試して、 ブログ記事「NGINXとNGINX PlusをDockerに展開するをご覧ください。

 

Dockerコンテナ内で実行できることにより、NGINXのマイクロサービス・リファレンスアーキテクチャーであるファブリックモデルなど、興味深いアーキテクチャーが可能になります。これは、NGINX Plusがすべてのコンテナ内で実行されて、ロードバランシング、ルーティング、SSL / TLS終了サービスを提供するモデルです。

 

ファブリックモデルの特長は、コンテナ化されたすべてのマイクロサービスインスタンスで、NGINX Plusインスタンスが実行されることです

 

F5 BIG-IPはDockerコンテナの内部では実行できません。仮想アプライアンスまたはハードウェアアプライアンスとしてのみ使用できます。

 

 

5.再起動いらずのアップグレード

最新のバグフィックスとセキュリティパッチを確実に適用するために、ソフトウェアを最新の状態に保つことは非常に重要です。NGINX Plusを使用すると、サーバーを再起動したりパケットを取りこぼすことなく、ソフトウェアをアップグレードすることができます。

 

次の例は、標準のパッケージ管理ツール(この場合はapt)を使って、NGINX Plusをアップグレードする方法です。コマンドが完了すると、NGINX Plusのプロセスがリロードされ、新しいバージョンのソフトウェアがダウンタイムなしで実行されます。

 

# apt-get update

# apt-get install nginx-plus

Reading package lists… Done

Building dependency tree

Reading state information… Done

The following packages will be upgraded:

 nginx-plus

1 upgraded, 0 newly installed, 1 to remove and 43 not upgraded.

Need to get 2373 kB of archives.

After this operation, 1547 kB disk space will be freed.

Do you want to continue? [Y/n] y

Setting up nginx-plus (1.11.5-1~xenial) …

 

一方でF5 BIG-IPは、ソフトウェアをアップグレードするために完全に再起動する必要があります。

 

結論

NGINX Plusなら、同クラスのF5 BIG-IPと比較して80%以上のコスト節約が可能で、F5では実現できない幅広い機能を提供します。DNS SRVレコードを読み取ったり、コンテナ内で実行できる機能は、マイクロサービスのサポートとレガシーアプリケーションの近代化を考える際には、非常に重要です。

NGINX Plus 試用版(30日間)