ソフトウェアADC

NGINX Plusを使用した3つのクラウドアーキテクチャー

※本記事はNGINX,Inc.のブログ記事「3 Cloud Architectures with NGINX Plus」を和訳した内容となります。
【URL】
https://www.nginx.com/blog/cloud-architectures/

クラウドへの移行をご検討中でしょうか?クラウドへの移行には、多くのメリットと同時に、いくつかデメリットもあります。一部の企業では、会社のファイアウォール外にデータをホストすることは契約違反です。でも、ほとんどの場合では、自分のハードウェアを管理する必要がないという利点の重みは、絶対的なコントロールを失うといった欠点をはるかに上回っています。最近の調査によると、このことはIT責任者にとって、ますます明らかになりつつあるようです。今後2年間で、エンタープライズのIT支出の3分の1ががクラウドに向かうことが予測されている(英語ページ)のです。

クラウドへの移行を検討している場合、またはそうでない場合でも、今はアプリケーションのアーキテクチャーについて考え始めるのによい時期です。よく知られた問題を抱えたまま、盲目的にアプリケーションをクラウドに移行させるよりは、この新しいタイプの環境でよりスムーズに動作するよう、アプリケーションスタックを更新してはどうでしょうか?アプリケーション・デリバリー戦略は、再評価プロセスを開始するのに最適なスタート地点です。優れたアプリケーション配信は、あなたに忠実なお客様を得るか、競合他社の新しいお客様にしてしまうかの違いを生むのです。

オンプレミスでアプリケーションをホストする場合、ハードウェアのアプリケーション デリバリー コントローラー(以下ADCと表記)を使う可能性が高いはずです。ハードウェアADCはオンプレミス環境ではうまくいくかもしれませんが、クラウドにハードウェアを置くことはできません。
従来のハードウェアADCベンダーのほとんどは、自社製品の仮想バージョンを持っていますが、
クラウドに移行するなら、クラウドを念頭に置いて作られた最新のADCを試してみてはいかがでしょうか。

NGINX Plusは、現代のWebから誕生した、エンタープライズグレードのソフトウェアのADCです。NGINX Plusは軽量で、アプリケーションを完璧に届けるために必要なすべての機能を備え、
使いもしない機能にコストを強いることもありません。NGINX PlusはハードウェアADCのコストのほんの一部分で利用でき、機能を遅くする帯域幅やSSLの制限はありません。

クラウドコンピューティングの調査を始めるための参考に、NGINX Plusの機能を活用した、
いくつかのクラウドアーキテクチャーをご紹介します。

シンプルクラウドバースト

一度にすべてをクラウドに移行することが危険すぎるようであれば、より混乱しにくい方法として
ハイブリッド展開を考えてみてください。このタイプの構成では、オンプレミスとクラウドサービスの両方を使って、アプリケーションを提供します。

NGINX Plusの最小時間ロードバランシング・アルゴリズム(英語ページ)を使用すると、すべての
オンプレミスサーバーがビジー状態のときに、トラフィックがクラウドに送信される
「クラウドバースト」構成を構築できます。

 

ローカルサーバーがすべてビジー状態のとき、NGINX Plusはクラウドにトラフィックを送信します。

最小時間アルゴリズムでは、NGINX Plusは、各サーバーに対して2つの数値(現在のアクティブな接続数と、過去のリクエストに対する加重平均した応答時間)を数学的に結合し、最小値だったサーバーにリクエストを送ります。
最小時間だと、ローカルサーバーの応答が速いため、そちらに多くのリクエストを送信する傾向が
あります。ローカルサーバーにリクエストを送り続けて、ネットワークの余分なレイテンシーの分を含めてもなお、クラウドサーバーがローカルサーバーよりも迅速に応答する点まで行くと、
NGINX Plusはクラウドサーバーへリクエストを振り向け始めます。ローカルサーバーの負荷が
再び
小さくなると、NGINX Plusは、ほとんどのリクエストの振り向け先をローカルサーバーに戻します。

 

ローカル・ロードバランシング

多くのパブリッククラウドベンダーは、世界中に地域ごとのデータセンターを持ち、そのいずれか、またはすべてにアプリケーションをホストすることができます。たとえば、Amazon Web Services、北米、南米、ヨーロッパ、アジアに9つのデータセンターあります。
フォールトトレランスのために、クラウドベンダーは各地域のデータセンターに「可用性ゾーン」を設定しています。可用性ゾーンには、独立した電源、ネットワーキング、冷却装置などを備え、物理​​的に分離されたハードウェアのラックがあります。たとえば電力を失うなどして、ある可用性ゾーンに障害が発生した場合、稼働中の可用性ゾーンが代わりを務めることができます。
可用性ゾーンをまたいでアプリケーションを複製することで、アプリケーションの可用性を
高めることが可能です。
可用性ゾーンをまたいでアプリケーションを複製することにより、高可用性を実現

上記のクラウドアーキテクチャ図では、クラウドベンダーのネイティブなロードバランサー
(Amazon Web Servicesの
ELB、Google Cloud Platformのロードバランサー、またはMicrosoft AzureのAzure Traffic Manager)がトラフィックをさまざまな可用性ゾーンに分散しています。
それぞれの可用性ゾーン内で、NGINX Plusはアプリケーションサーバーへの負荷分散を行います。NGINX Plusの背後にあるアプリケーションは、モノリスでも、マイクロサービスベースの
アプリケーション、またはそれらの中間のものでも構いません。

 

グローバル・ロードバランシング

アプリケーションを複数の可用性ゾーンにまたがって複製することで、地域内での高可用性が
実現します。次のステップは、複数の地域でアプリケーションをホストすることです。
アプリケーションをユーザーの近くに移動すると、ネットワークのレイテンシーの
影響が軽減され、全体的なユーザーエクスペリエンスが向上します。グローバルに分散されたアプリケーションを構築するには多くの方法があります。
一般的な方法の一つは、地理的な位置情報ベースのDNS(GeoDNS)ソリューションを使うことです。GeoDNSソリューションを使うと、ドメインの権威DNSサーバーがクライアントの応答を形成するとき、クライアントの位置を考慮して、最も近いデータセンターにクライアントを送信します。

NGINX PlusとGeoDNSは、グローバルに分散したアプリケーションを構成します

AmazonのRoute 53など、利用可能なGeoDNSソリューションはたくさんあります。
それらをNGINX Plusと組み合わせることで、グローバルに分散した、スケーラブルな
アプリケーションを作成できます。
上記の図では、GeoDNSはカリフォルニアのユーザーを
米国西部データセンターに誘導し、
ニューヨークのユーザーは
米国東部データセンターに誘導しています。各データセンター内で、
NGINX Plusは入ってくるトラフィックをアプリケーションサーバーに分散します。

 

結論

クラウドへの移行を検討している場合は、アプリケーション・デリバリー戦略も再考することが
理にかなっています。ハードウェアADCは、オンプレミス構成ではうまくいくかもしれませんが、
クラウドアーキテクチャの一部にすることはできません。大部分のハードウェアADCベンダーは
自社アプライアンスの仮想バージョンを提供していますが、不必要に高価で、クラウドでは
必要のない機能にコストを支払うことになります。さらに、仮想バージョンは通常、一部の
クラウドしかサポートされませんが、NGINX Plusなら、クラウドを選ばず実行できます。

NGINX Plusは、クラウド上で動作するように設計されたソフトウェアADCです。
仮想ハードウェアADCのコストのほんの一部で利用できますが、実際に必要とされるすべての機能を備えています。

クラウドアーキテクチャでNGINX Plusがどう最適なのか、ご自分で確認されたいですか?
すぐに
無料の30日間のトライアルをお試しください。

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日間)