さまざまなマイクロサービスアーキテクチャをサポート
続いて田辺氏は、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
