NGINX Microservices Reference Architectureの3モデルを紹介

Nginx, Inc.のMicroservices Reference Architecture(MRA)についてのドキュメントでProxyモデル、Router Meshモデル、Fabricモデルという3つのネットワーキングモデルが解説されている。 GoFのデザインパターン然り、名前が付いている、というのは重要なことだ。本項ではこの3モデルについて紹介する。

1. Proxyモデル

Proxyモデルはマイクロサービスアプリケーションのフロント側にリバースプロキシクラスターを配置する。

出典元: MRA Part 2 – Proxy Model

Proxyモデルは比較的単純であり、API Gateway、初期のマイクロサービス、もしくは、複雑なレガシーモノリシックアプリケーションを変換する際のターゲットとして適している。特に大規模なマイクロサービスやトラフィックについての負荷分散に適しているようなモデルではないので、負荷分散への要件が厳しい場合にはRouter MeshモデルかFabricモデルを使わなければいけない。

このモデルは以下のような機能をもたらしうる。

パフォーマンスの最適化

• Caching
  • 参考: The Benefits of Microcaching with NGINX - NGINX
• Load Balancing
  • 動的なサービスディスカバリも併せて機能させれば、新しいサービスインスタンスをすぐに追加できる。
• Low‑Latency Connectivity
  • ウェブブラウザやクライアントアプリなど外部からの接続に対して、HTTP/2サポートやHTTP/HTTPSのkeepaliveを機能させる。
• High Availability
  • リバースプロキシの冗長化構成。

セキュリティと管理

• Rate Limiting / WAF
  • マイクロサービスアプリケーションへの単一の入り口となるので、すべてのリクエストについてDDoSかどうかといった問題の判定が行える。
  • 参考: NGINX Rate Limiting
• SSL/TLS Termination
• HTTP/2 Support
• Health Checks
  • 問題のあるサービスインスタンスへのトラフィックを止めて、別のインスタンスにトラフィックを流せる。

マイクロサービス特有の機能

• Central Communications Point for Services
  • マイクロサービスアプリケーションを使うクライアントは、通信において必要となるのは1箇所だけ。
• Dynamic Service Discovery
  • Consul, etcd, Kubernetes, ZooKeeperといったサービスレジストリと連携して、新しいサービスエンドポイントの追加や、新しいインスタンスにトラフィックを流す。
• API Gateway Capability
  • クライアントから受け取ったリクエストを必要に応じて変換しながら、サービスにルーティングする。
  • 複数リクエストの結果を集約して、単一レスポンスとしてクライアントに返す。

2. Router Meshモデル

Router Meshモデルは、Proxyモデルにおけるフロントのリバースプロキシクラスターに加え、ルーターメッシュハブのクラスターを配置する。ルーターメッシュハブはサービス間通信をハンドリングする。

出典元: MRA Part 3 – Router Mesh Model

このモデルはより堅牢なアプリケーション設計として適しており、Fabricモデルほど複雑ではない。

Proxyモデルにおけるリバースプロキシの役割を2つのサーバクラスターに分けることとなる。2つのクラスターはそれぞれ以下のような機能を担うことができる。

リバースプロキシクラスター

• Caching
• Low‑Latency Connectivity
• High Availability
• Rate Limiting / WAF
• SSL/TLS Termination
• HTTP/2 Support

ルーターメッシュハブクラスター

• Central Communications Point for Services
• Dynamic Service Discovery
• Load Balancing
• Interservice caching
• Health checks and the circuit breaker pattern

3. Fabricモデル

Fabricモデルでは各マイクロサービスインスタンスをホストするコンテナごとにプロキシサーバを配置する。このプロキシサーバはコンテナに出入りするすべてのHTTPトラフィックを扱うforward and reverseのプロキシサーバとなる。

出典元: MRA Part 4 – Fabric Model

Router Meshモデルと違い、各マイクロサービスコンテナごとにプロキシを配置する。サービス間の通信においてアプリケーションはローカルホストのプロキシサーバとやり取りし、サービスディスカバリ、負荷分散、ヘルスチェックをプロキシサーバに委ねる。プロキシサーバがすべての接続の両端にあるので、その機能は特定のサーバやマイクロサービス特有の機能ではなく、アプリケーションを実行しているネットワークの性質となる。

このモデルは以下の問題を解決する。

• 安全で高速な通信
  • マイクロサービス間のすべてのリクエストにSSL/TLSを使用して通信を安全にし、接続を永続化することでSSL/TLSのハンドシェイクといった処理を高速化する。
• Service discovery
• Load balancing
• Resilience
  • すべてのマイクロサービスにおいてヘルスチェックを実行できるので、ネットワーク固有の性質としてサーキットブレーカーパターンを実装できる。

参考資料

• Microservices Reference Architecture | NGINX
• MRA Part 2 – Proxy Model
• MRA Part 3 – Router Mesh Model
• MRA Part 4 – Fabric Model

あとがき

Proxyモデル、Router Meshモデル、Fabricモデルは、順番に複雑さを増していくモデルであり、この順に適応していくこともできます。もちろんマイクロサービスの実践においてはこれらに該当しない事も多いのですが、名前付けられたモデルがあれば議論がしやすくなると思い紹介に至りました。

今回は参考資料を部分的に抜粋しながら翻訳しました。参考資料では他にもNGINX Plusでの設定方法やサーキットブレーカー、ウェブフロントエンドの作り方など、MRAについて様々なことが詳しく書かれています。気になった事があれば是非参考元の資料を読んでみてください。 また、参考元ではNGINX Plusを採用する前提として説明されている部分が多いのですが、本項ではNGINX Plusについての特別な記載はすべて省きました。