著者注–このブログ投稿はシリーズの最初の投稿です:
これら 6 つのブログと、マイクロサービス アプリケーションの Web フロントエンドに関するブログ <.htmla> が、無料の電子書籍にまとめられています。
マイクロサービスに関するその他の NGINX リソースもご覧ください。
NGINX は、マイクロサービスの動きに当初から関わってきました。 NGINX の軽量、高性能、柔軟性は、マイクロサービスに最適です。
NGINX Docker イメージはDocker Hub で最も多くダウンロードされているアプリケーション イメージであり、現在 Web で見つかるほとんどのマイクロサービス プラットフォームには、何らかの形で NGINX をデプロイし、ウェルカム ページに接続するデモが含まれています。
マイクロサービスへの移行はお客様の成功に不可欠であると信じているため、NGINX では、Web アプリケーションの開発と配信におけるこの大きな変化をサポートする機能とプラクティスを開発するための専用プログラムを開始しました。 また、マイクロサービスの実装にはさまざまなアプローチがあり、その多くは斬新で個々の開発チームのニーズに特化したものであることも認識しています。 企業が独自のマイクロサービスベースのアプリケーションをより簡単に開発および提供できるようにするモデルが必要だと考えています。
これらすべてを念頭に置いて、NGINX プロフェッショナル サービスでは、独自のマイクロサービス アプリケーションを作成するために使用できるモデルのセットである NGINX マイクロサービス リファレンス アーキテクチャ (MRA) を開発しています。
MRA は、3 つのモデルの詳細な説明と、サンプル写真共有プログラム Ingenious を実装するダウンロード可能なコードの 2 つのコンポーネントで構成されています。 3 つのモデル間の唯一の違いは、それぞれの NGINX Plus を構成するために使用される構成コードです。 このブログ投稿シリーズでは、各モデルの概要を説明します。詳細な説明、構成コード、および Ingenious サンプル プログラムのコードは、今年後半に公開される予定です。
このリファレンス アーキテクチャを構築する際の目標は 3 つあります。
マイクロサービス リファレンス アーキテクチャは、NGINX のお客様向けのプロフェッショナル サービス提供の重要な部分でもあります。 MRA では、可能な場合はNGINX Open SourceとNGINX Plus の両方に共通する機能を使用し、必要な場合は NGINX Plus 固有の機能を使用します。 以下に説明するように、NGINX Plus の依存関係は、より複雑なモデルではより強くなります。 MRA の多くのユーザーが、NGINX Plus サブスクリプションに付属する NGINX プロフェッショナル サービスとテクニカル サポートへのアクセスから恩恵を受けると予想されます。
私たちは、 Twelve-Factor Appの原則に準拠するリファレンス アーキテクチャを構築しています。サービスは軽量、一時的、ステートレスになるように設計されています。
MRA は、Docker コンテナ、Java、PHP、Python、NodeJS/JavaScript、Ruby などの幅広い言語、NGINX ベースのネットワークなどの業界標準コンポーネントを使用します。
マイクロサービスに移行する際のアプリケーション設計とアーキテクチャにおける最大の変更点の 1 つは、アプリケーションの機能コンポーネント間の通信にネットワークを使用することです。 モノリシック アプリでは、アプリケーション コンポーネントはメモリ内で通信します。 マイクロサービス アプリでは、その通信はネットワーク経由で行われるため、ネットワークの設計と実装が非常に重要になります。
これを反映するために、MRA は 3 つの異なるネットワーク モデルを使用して実装されており、いずれも NGINX または NGINX Plus を使用しています。 それらは、比較的単純なものから、機能が豊富で複雑なものまで多岐にわたります。
私たちの意図は、これらのモデルを独自のマイクロサービス実装の開始点として使用していただくことであり、MRA を改善する方法についてのフィードバックをお待ちしています。 (まずは下のコメント欄にコメントを追加してください。)
各モデルの簡単な説明は次のとおりです。1 つまたは複数のモデルを最適に使用する方法を理解するために、すべての説明を読むことをお勧めします。 今後のブログ投稿では、各モデルについて 1 つのブログ投稿ごとに詳しく説明します。
プロキシ モデルは比較的単純なネットワーク モデルです。 これは、初期のマイクロサービス アプリケーションの優れた出発点であり、中程度に複雑なモノリシックなレガシー アプリを変換する際のターゲット モデルとしても最適です。
プロキシ モデルでは、NGINX または NGINX Plus はイングレス コントローラーとして機能し、リクエストをマイクロサービスにルーティングします。 NGINX Plus は、新しいサービスが作成されると、サービス検出に動的 DNS を使用できます。 プロキシ モデルは、NGINX をAPI ゲートウェイとして使用する場合のテンプレートとして使用するのにも適しています。
サービス間通信が必要な場合 (これは、複雑さのレベルに関係なくほとんどのアプリケーションで必要になります)、サービス レジストリがクラスター内でメカニズムを提供します。 (サービス間通信メカニズムの詳細なリストについては、このブログ投稿を参照してください。) Docker Cloud はデフォルトでこのアプローチを使用します。別のサービスに接続するために、サービスは DNS を照会し、リクエストを送信する IP アドレスを取得します。
一般に、プロキシ モデルは、単純なアプリケーションから中程度に複雑なアプリケーションに適しています。 これは、特に大規模な負荷分散には最も効率的なアプローチ/モデルではありません。負荷分散の要件が厳しい場合は、以下に説明するモデルのいずれかを使用してください。(「規模」とは、多数のマイクロサービスと大量のトラフィックを指す場合があります。)
編集者 – このモデルの詳細については、 「MRA、パート 2 – プロキシ モデル」を参照してください。
ルーター メッシュ モデルは中程度の複雑さで、堅牢な新しいアプリケーション設計に適しています。また、ファブリック モデルの機能を必要としない、より複雑でモノリシックなレガシー アプリを変換する場合にも適しています。
ルーター メッシュ モデルは、各ホストでロード バランサーを実行し、マイクロサービス間の接続をアクティブに管理することで、プロキシ モデルよりも堅牢なネットワーク アプローチを採用しています。 ルーター メッシュ モデルの主な利点は、サービス間の負荷分散がより効率的かつ堅牢になることです。 NGINX Plus を使用すると、アクティブ ヘルス チェックを実装して個々のサービス インスタンスを監視し、インスタンスが停止したときにトラフィックを適切に調整できます。
Deis Workflow は、ルーター メッシュ モデルに似たアプローチを使用してサービス間のトラフィックをルーティングし、各ホストのコンテナーで NGINX のインスタンスを実行します。 新しいアプリ インスタンスが起動されると、プロセスがetcdサービス レジストリからサービス情報を抽出し、NGINX にロードします。NGINX Plus は、さまざまな場所とそれに関連するアップストリームを使用して、このモードでも動作できます。
編集者 – このモデルの詳細については、 「MRA、パート 3 – ルータ メッシュ モデル」を参照してください。
NGINX の私たちは、Fabric モデルに最も期待しています。 これにより、高パフォーマンス、負荷分散の柔軟性、ユビキタス SSL/TLS など、マイクロサービスの最も魅力的な利点のいくつかが、個々のマイクロサービス レベルまで実現されます。 ファブリック モデルは、安全なアプリケーションに適しており、非常に大規模なアプリケーションにも拡張可能です。
ファブリック モデルでは、NGINX Plus は各コンテナ内にデプロイされ、コンテナに出入りするすべての HTTP トラフィックのプロキシになります。 アプリケーションは、すべてのサービス接続についてローカルホストの場所と通信し、NGINX Plus を使用してサービス検出、負荷分散、ヘルスチェックを実行します。
私たちの構成では、NGINX Plus は、アプリが接続する必要があるサービスのすべてのインスタンスについてZooKeeper にクエリを実行します。 たとえば、DNS 頻度設定valid
を 1 秒に設定すると、NGINX Plus は ZooKeeper をスキャンしてインスタンスの変更を検出し、トラフィックを適切にルーティングします。
NGINX Plus の強力な HTTP 処理により、キープアライブを使用してマイクロサービスへのステートフル接続を維持し、レイテンシを削減してパフォーマンスを向上させることができます。 これは、SSL/TLS を使用してマイクロサービス間のトラフィックを保護する場合に特に役立つ機能です。
最後に、NGINX Plus のアクティブ ヘルス チェックを使用して正常なインスタンスへのトラフィックを管理し、基本的にサーキット ブレーカー パターンを無料で組み込みます。
編集者 – このモデルの詳細については、 「MRA、パート 4 – ファブリック モデル」を参照してください。
MRA には、デモとしてサンプル アプリケーション (Ingenious 写真共有アプリ) が含まれています。Ingenious は、プロキシ、ルーター メッシュ、ファブリックの 3 つのモデルのそれぞれに実装されています。 Ingenious デモ アプリは今年後半に一般公開される予定です。
Ingenious は、Flickr や Shutterfly のような写真保存および共有アプリケーションの簡易版です。 私たちが写真共有アプリケーションを選んだ理由はいくつかあります。
NGINX マイクロサービス リファレンス アーキテクチャは、私たちにとって、そしてこれまでそれを共有してきた顧客やパートナーにとって、刺激的な開発です。 今後数か月にわたって、詳細を説明するブログ投稿シリーズを公開し、今年後半に公開する予定です。 これについては、9 月 7 日から 9 日までテキサス州オースティンで開催されるnginx.conf 2016でも詳しく説明する予定です。ぜひフィードバックをお寄せください。お会いできるのを楽しみにしています。
それまでの間、NGINX Plus を使用した MRA をぜひお試しください。今すぐ30 日間の無料トライアルを開始するか、弊社にご連絡の上、ユースケースについてご相談ください。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"