NGINXのマイクロサービスリファレンスアーキテクチャのご紹介

Chris Stetson

著者注 – このブログ記事は、シリーズの第1回です：

1. NGINXマイクロサービスリファレンスアーキテクチャのご紹介（本記事）
2. MRA第2部：プロキシモデル
3. MRA、第3部：ルーターメッシュモデル
4. MRA、第4部：ファブリックモデル
5. MRA、第5部：Twelve-Factor Appをマイクロサービス向けに適応
6. MRA、第6部：NGINX Plusによるサーキットブレーカーパターンの実装

全6回のブログに加え、マイクロサービスアプリケーション向けWebフロントエンド<.htmla>に関するブログをまとめた無料のeBookをご用意しています。

マイクロサービスに関する以下のNGINXリソースもご覧ください。

• Chris Richardsonによる、非常に有用で人気の高いシリーズ：マイクロサービスアプリケーションの設計
• Chris Richardsonの記事をまとめた無料の電子書籍。NGINXとNGINX Plusを使用してマイクロサービスを実装するための追加のヒントも収録しています
• その他のマイクロサービスに関するブログ記事
• マイクロサービスに関するウェビナー
• マイクロサービスソリューションのページ
• トピック：マイクロサービス

はじめに

NGINXは、マイクロサービスの潮流が始まった当初から、その発展に携わってきました。軽量で高性能かつ柔軟なNGINXは、マイクロサービスに非常に適しています。

The NGINX Docker imageは、Docker Hubでダウンロード数第1位のアプリケーションイメージです。また、現在Web上で提供されているマイクロサービスプラットフォームの多くには、何らかの形でNGINXをデプロイし、ウェルカムページに接続するデモが含まれています。

マイクロサービスへの移行はお客さまの成功に不可欠であると考え、NGINXでは、Webアプリケーションの開発とデリバリーにおけるこの大きな変革を支える機能やプラクティスを開発するための専用プログラムを立ち上げました。また、マイクロサービスの実装方法は多岐にわたり、その多くが新しく、各開発チーム固有のニーズに合わせたものであることも認識しています。企業が独自のマイクロサービスベースのアプリケーションをより容易に開発し、デリバリーできるようにするためのモデルが必要だと考えています。

こうした点を踏まえ、NGINX Professional Servicesでは、独自のマイクロサービスアプリケーションの構築に利用できる一連のモデルであるNGINX Microservices Reference Architecture（MRA）を開発しています。

MRAは、3つのモデルそれぞれの詳細な説明と、写真共有のサンプルプログラム「Ingenious」を実装するダウンロード可能なコードという2つの要素で構成されています。3つのモデルの唯一の違いは、各モデル向けにNGINX Plusを構成するための設定コードです。このブログシリーズでは、各モデルの概要を紹介します。詳細な説明、設定コード、およびIngeniousサンプルプログラムのコードは、今年後半に公開する予定です。

このリファレンスアーキテクチャを構築する目的は、次の3つです。

• マイクロサービスベースのシステム構築にすぐに活用できる設計図をお客さまと業界に提供し、開発の迅速化と改善を図ること
• 社内外で開発され、製品コアまたはダイナミックモジュールとして提供されるNGINXおよびNGINX Plusの新機能をテストするためのプラットフォームを構築すること
• パートナーのシステムとコンポーネントへの理解を深め、マイクロサービスエコシステムを包括的に把握するため

Microservices Reference Architectureは、NGINXのお客さま向けプロフェッショナルサービスにおいても重要な役割を果たします。MRAでは、可能な限りNGINX Open SourceとNGINX Plusに共通する機能を使用し、必要に応じてNGINX Plus固有の機能を使用します。以下で説明するように、複雑なモデルほどNGINX Plusへの依存度が高くなります。MRAの多くのユーザーにとって、NGINXのプロフェッショナルサービスや、NGINX Plusサブスクリプションに付属するテクニカルサポートを利用できることが有益であると考えています。

マイクロサービスリファレンスアーキテクチャの概要

このリファレンスアーキテクチャは、Twelve‑Factor Appの原則に準拠するよう構築しています。各サービスは、軽量かつ一時的で、ステートレスになるよう設計されています。

MRAでは、Dockerコンテナ、Java、PHP、Python、NodeJS/JavaScript、Rubyなどの幅広い言語、NGINXベースのネットワークといった業界標準のコンポーネントを使用しています。

マイクロサービスへの移行に伴うアプリケーションの設計とアーキテクチャにおける最大の変化の1つは、アプリケーションの機能コンポーネント間の通信にネットワークを使用することです。モノリシックアプリでは、アプリケーションコンポーネントはメモリ内で通信します。一方、マイクロサービスアプリでは、この通信がネットワーク経由で行われるため、ネットワークの設計と実装が極めて重要になります。

これを反映し、MRAは3つの異なるネットワークモデルを使用して実装されています。いずれもNGINXまたはNGINX Plusを使用しており、比較的シンプルなものから、機能が豊富でより複雑なものまであります。

• プロキシモデル – マイクロサービスアプリケーション向けのコントローラーまたはAPIゲートウェイとしてNGINX Plusを実装するのに適した、シンプルなネットワーキングモデルです。このモデルはDocker Cloud上に構築されています。
• Router Mesh Model – 各ホストにロードバランサーを配置し、システム間の接続を管理する、より堅牢なネットワーク構成手法です。このモデルは、Deis 1.0のアーキテクチャに似ています。
• Fabric Model – MRAの中核をなすFabric Modelでは、各コンテナにNGINX Plusを配置し、すべての受信トラフィックと送信トラフィックを処理します。高負荷システムに適しており、あらゆるレベルでSSL/TLSをサポートします。また、NGINX Plusにより、すべてのマイクロサービスにわたって、レイテンシの低減、SSL/TLS接続の維持、サービスディスカバリ、サーキットブレーカーパターンを実現します。

これらのモデルを独自のマイクロサービス実装の出発点としてご活用ください。また、MRAの改善に向けたフィードバックをお待ちしています。（まずは、以下のコメント欄にご意見をお寄せください。）

以下に各モデルの概要を示します。まずはすべての説明に目を通し、1つまたは複数のモデルをどのように活用するのが最適か、イメージをつかむことをお勧めします。今後のブログ記事では、各モデルを1記事につき1つずつ詳しく説明します。

プロキシモデルの概要

プロキシモデルは、比較的シンプルなネットワークモデルです。初めてマイクロサービスアプリケーションを構築する際の出発点として、また、中程度に複雑なモノリシックのレガシーアプリケーションを移行する際の目標モデルとして最適です。

Proxy Modelでは、NGINXまたはNGINX PlusがIngressコントローラーとして機能し、リクエストをマイクロサービスにルーティングします。NGINX Plusでは、新しいサービスの作成に伴うサービスディスカバリにダイナミックDNSを使用できます。また、Proxy Modelは、NGINXをAPIゲートウェイとして使用する際のテンプレートにも適しています。

サービス間通信が必要な場合（一定以上の複雑さを持つほとんどのアプリケーションで必要です）、サービスレジストリがクラスター内でその仕組みを提供します。（サービス間通信の仕組みの詳細な一覧については、こちらのブログ記事をご覧ください。）Docker Cloudでは、デフォルトでこのアプローチが使用されます。別のサービスに接続する際、サービスはDNSに問い合わせ、リクエストの送信先となるIPアドレスを取得します。

一般に、プロキシモデルは、単純なアプリケーションから中程度に複雑なアプリケーションまで対応できます。ただし、特に大規模な環境では、負荷分散の手法／モデルとして最も効率的とはいえません。負荷分散の要件が厳しい場合は、以下で説明するいずれかのモデルを使用してください。（ここでいう「大規模」とは、マイクロサービスの数が多い場合だけでなく、トラフィック量が多い場合も指します。）

編集者注：このモデルの詳細については、「MRA、第2部：プロキシモデル」をご覧ください。

ルーターメッシュモデルへの移行

Router Mesh Modelは中程度の複雑さを備えており、堅牢な新規アプリケーションの設計に適しています。また、Fabric Modelの機能を必要としない、より複雑なモノリシック型のレガシーアプリケーションの移行にも適しています。

Router Mesh Modelでは、各ホストでロードバランサーを実行し、マイクロサービス間の接続を能動的に管理することで、Proxy Modelよりも堅牢なネットワークアプローチを採用しています。Router Mesh Modelの主な利点は、サービス間でより効率的かつ堅牢な負荷分散を実現できることです。NGINX Plusを使用すると、アクティブヘルスチェックを実装して個々のサービスインスタンスを監視し、停止時にはトラフィックを適切に抑制できます。

Deis Workflowでは、Router Mesh Modelと同様のアプローチを使用してサービス間のトラフィックをルーティングし、各ホスト上のコンテナでNGINXインスタンスを実行します。新しいアプリインスタンスが起動すると、プロセスがetcdサービスレジストリからサービス情報を抽出し、NGINXに読み込みます。NGINX Plusも、さまざまなlocationとそれに関連付けられたupstreamを使用して、このモードで動作できます。

編集者注：このモデルの詳細については、「MRAパート3：ルーターメッシュモデル」をご覧ください。

最後に ― オプションでSSL/TLSを使用できるファブリックモデル

NGINXが最も期待を寄せているのがFabric Modelです。高いパフォーマンス、柔軟な負荷分散、個々のマイクロサービスに至るまで広く適用できるSSL/TLSなど、マイクロサービスがもたらす特に魅力的な可能性を実現します。Fabric Modelは、セキュアなアプリケーションに適しており、非常に大規模なアプリケーションにも拡張できます。

Fabric Modelでは、NGINX Plusが各コンテナ内にデプロイされ、コンテナに出入りするすべてのHTTPトラフィックのプロキシとして機能します。アプリケーションは、すべてのサービス接続でlocalhostのアドレスと通信し、サービスディスカバリ、負荷分散、ヘルスチェックをNGINX Plusに委ねます。

この構成では、NGINX Plusが、アプリの接続先となるサービスのすべてのインスタンスについてZooKeeperに問い合わせます。たとえば、DNSの問い合わせ頻度を指定するvalidを1秒に設定すると、NGINX PlusはZooKeeperを毎秒確認してインスタンスの変更を検出し、トラフィックを適切にルーティングします。

NGINX Plusの強力なHTTP処理により、キープアライブを使用してマイクロサービスへのステートフルな接続を維持できるため、レイテンシーが短縮され、パフォーマンスが向上します。これは、SSL/TLSを使用してマイクロサービス間のトラフィックを保護する場合に特に有用な機能です。

最後に、NGINX Plusのアクティブヘルスチェックを使用して、正常なインスタンスへのトラフィックを管理し、実質的にサーキットブレーカーパターンを追加コストなしで組み込みます。

編集者注：このモデルの詳細については、「MRAパート4：ファブリックモデル」をご覧ください。

MRA向けの独創的なデモアプリ

MRAには、デモ用のサンプルアプリケーションとして、写真共有アプリ「Ingenious」が含まれています。Ingeniousは、Proxy、Router Mesh、Fabricの3つのモデルそれぞれに実装されています。Ingeniousデモアプリは、今年後半に一般公開される予定です。

Ingeniousは、FlickrやShutterflyのような写真の保存・共有アプリケーションを簡略化したものです。写真共有アプリケーションを選んだ理由はいくつかあります。

• ユーザーにも開発者にも、その機能を簡単に理解できます。
• 管理すべきデータのディメンションが複数あります。
• アプリに美しいデザインを簡単に取り入れることができます。
• 高負荷処理と低負荷処理が混在する非対称なコンピューティング要件を備えているため、さまざまな種類の機能にわたって、フェイルオーバー、スケーリング、監視機能を実環境に即してテストできます。

まとめ

NGINX Microservices Reference Architectureは、私たちにとっても、これまで共有してきたお客さまやパートナーにとっても、期待の高まる新たな取り組みです。今後数か月にわたり、その詳細を紹介する一連のブログ記事を公開し、今年後半には利用可能にする予定です。また、9月7～9日にテキサス州オースティンで開催される「nginx.conf 2016」でも詳しくご紹介します。ぜひご意見をお寄せください。皆さまにお会いできることを楽しみにしています。

それまでの間、NGINX PlusでMRAをお試しください。今すぐ30日間の無料トライアルを開始するか、ユースケースについてご相談ください。

著者について

Chris Stetson

Chris Stetsonのその他のブログ記事