複雑化したアプリケーションのインフラをもっとシンプルに
田辺氏はまず、NGINX社の現在の主要製品として「NGINX Plus」「NGINX Controller」「NGINX Unit」を簡単に紹介した。
中心となるのは、高速軽量なオープンソースのWebサーバーとしてお馴染みの「NGINX」の商用版にあたるNGINX Plusだ。サポートが提供されるほか、オープンソース版にはない機能も複数追加されており、セキュリティ強化モジュールとしてWebアプリケーションファイアウォール（WAF）の「NGINX WAF」も用意されている。
NGINX Controllerは、そのNGINX Plusを集中管理するためのコントロールプレーン。多数のNGINX Plusから統計情報を集約してグラフ化し、モニタリングする機能なども備えている。
そしてNGINX Unitは、多言語対応の軽量なアプリケーションサーバーおよびWebサーバーだ。2018年に正式リリースされた新しい製品であり、オープンソースで提供されている。
NGINX社では、これらの製品群を「NGINXアプリケーションプラットフォーム」と呼んでいる。もともとNGINX（オープンソース版、NGINX Plus含む）はWebサーバーとしてだけではなく、ロードバランサーやコンテンツキャッシュ（リバースプロキシ）の用途でも広く活用されてきたが、さらにその製品領域を広げている背景には、「アプリケーションインフラの複雑化」があると田辺氏はいう。
ここ20年ほどのWeb技術の進化とともに、アプリケーションのインフラはかなり複雑になってきた。「ユーザー」と「アプリケーション」の間には、コンテンツキャッシュやWAF、ロードバランサー、APIゲートウェイなど、多様な要素が存在する。さらに、同種の機能でも採用されている技術や製品を提供するベンダー、ハードウェア／ソフトウェアなどの提供形態はさまざまで、それぞれ設定や管理の方法も異なる。
「こうした複雑さは管理の負荷を増大させ、安定性の低下にもつながりかねない。NGINXでは複雑さを解消するために、できる限り同じ管理体系の製品で機能を集約し、アプリケーションのインフラを包括的に提供することを目指している」（田辺氏）
その実現に向けたソリューションが、NGINXアプリケーションプラットフォームというわけだ。
NGINX Plusではロードバランス先を動的に変更可能
オープンソース版のNGINXと比較したNGINX Plusの特徴として、田辺氏はまず「詳細で豊富なメトリック」を挙げた。サーバーが現在どういう状態にあるのか、NGINX PlusではさまざまなメトリックをAPI経由で取り出し、付属のダッシュボードで見ることができる。たとえば、NGINX Plusのインスタンスごとのアクセス状況やエラーなどを確認したり、サーバーの状況をゾーンに分けて表示したり、キャッシュや共有メモリーの使用状況などを確認することも可能。なお、このダッシュボードについてはデモサイトが用意されており、自由に体験できるようになっている。
もう1つの重要な特徴として田辺氏が挙げたのは、「Upstreamの動的変更」だ。Upstreamとは、ロードバランス先であるバックエンドのサーバーのこと。オープンソース版のNGINXでは、Upstreamの追加・削除やweight（重み付け）などのパラメータを変更する場合、設定ファイルのnginx.confを書き換えてからリロードする必要がある。NGINX Plusでは、こうした変更をAPI経由で実行し、リロード不要で適用させることができるという。
ほかにも、NGINX Plusでは負荷分散のアルゴリズムやヘルスチェックなどの機能がオープンソース版よりも強化されている。
NGINX Plusの導入パターンとしては、新しいサービスを構築する際に導入するケースと既存サービスの環境を置き換えるケースが考えられるが、後者はなかなかハードルが高い。そこで、既存環境はそのまま活かしながら、フロントにNGINX Plusを置いてリバースプロキシ（コンテンツキャッシュ）として機能させるのも有効な利用法だと田辺氏は話す。
「たとえば静的なイメージなどはキャッシュの有効期限を長めに、WordPressのドキュメントなどダイナミックに生成されるものは短めの5秒程度に設定する。5秒のキャッシュでアクセスのパフォーマンス向上が期待できるし、ダイナミックなコンテンツでもそれほど古いものが出ることもなく、ちょうどいい環境が実現できる」
こうしたリバースプロキシとしての利用のほか、最近ではAPIゲートウェイの機能に対するニーズが高まっており、実際にNGINX Plusユーザーの3～4割程度がAPIゲートウェイとして活用しているという。
さまざまなマイクロサービスアーキテクチャをサポート
続いて田辺氏は、NGINXのマイクロサービスへの取り組みについて言及。マイクロサービスアーキテクチャとして成熟度に応じた3モデルを例示し、NGINXはそれらすべてをサポートしていると説明した。
1. Proxy Model
マイクロサービスへの移行初期段階となる単純なモデル。サービス群のフロントにNGINXを置き、プロキシとして使う。外からのアクセスをルーティングして、適切に各サービスに振り分ける。サービス間は直接つながっていて、サービス同士で通信を行う。
2. Router Mesh Model
Proxy Modelではサービスが増えるほど各サービスの負荷が大きくなり、運用も煩雑になる。そこで次の段階として、サービス群の中央にNGINXをルーターとしてもう1台置き、サービス間の通信はすべてルーター（NGINX）を通して行うようにする。
3. Fabric Model
Router Mesh Modelでもさらにサービスが増えれば1台のルーターで捌ききれなくなり、ルーターが増えすぎると、やはりサービス間通信が複雑になっていく。最終的には、各サービスにNGINXが入り、そこを通してやりとりするモデルが望ましい。他のサービスとの通信はすべてNGINXに任せ、各サービスは自立して通信以外の処理に集中する。
この最終段階のFabric Modelにおいて、各サービスで動くWebサーバーとして機能するのが、NGINX Unitだ。NGINX Unitは「ダイナミックWeb・アプリケーションサーバー」と呼ばれ、アプリケーションありきで動作する。静的なファイルを提供する機能がなく、アプリケーションが出すHTTPの中身を返すという機能に限られている。
Python、PHP、Go、Perl、Ruby、JavaScript（Node.js）など多言語に対応（3月リリース済みのバージョン1.8.0でJavaにも対応）するほか、設定はすべてRESTful JSON APIで行うという特徴を持つ。設定ファイルを編集する必要がなく、必要なところだけREST APIで変えればよい。
田辺氏は、Dockerのイメージを使ったNGINX UnitのインストールやPHPアプリケーションの作成、設定変更などをデモで紹介。シンプルな手順で、動的に必要な部分だけ設定をスピーディに変更できることを示した。
DNSサービスディスカバリでサービス側の変更にも動的に対応
たとえば新しいサービスが追加されたり、既存のサービスのインスタンスが追加された場合などに、NGINX側でその変更に対応するには「設定ファイルを書き換えてリロードする」という単純な方法がある。しかし、マイクロサービスの環境ではさまざまなサービスが稼働し、サービスの増減や変更も頻繁に発生するため、そのようなやり方ではすぐに追随できなくなってしまう。そこで重要となるのが、「サービスの検出（サービスディスカバリ）」の機能だ。
NGINX Plusは、さまざまな方法でこのサービスの検出に対応できるという。田辺氏はその1つである「DNSサービスディスカバリ」について、Kubernetes上でのデモを交えながら説明した。基本的な仕組みとしては、DNSのSRVレコードを一定間隔で参照し、Upstreamとして設定されている対象のDNS情報に変更があればNGINX側の設定にも動的に反映することで、変更後のサービスを検出するというものだ。
デモでは実際に、NGINX PlusのUpstreamとしたサービス（Pod）をスケールアウト／スケールインさせると、NGINX Plus側の設定もすばやく変更されていく様子が見てとれた。
最後に、田辺氏は「『Webシステムが複雑になりすぎた』『ロードバランサーのハードウェアが更新時期を迎える』『マイクロサービスやコンテナでの運用を検討中』など、思い当たる項目がある方は、ぜひ一度、NGINX Plusのフリートライアルを活用していただきい」と呼びかけ、セッションを終えた。
お問い合わせ
NGINX
