マイクロサービスとは、単一の機能（認証、通知、決済処理など）を実行する複数の小さなコンポーネントから、大規模で複雑なアプリケーションを構築するソフトウェア アーキテクチャのアプローチを指します。また、小さなコンポーネントそのものを指す場合にも使用される用語です。各マイクロサービスは、ソフトウェア開発プロジェクトの中で独立した単位となり、それぞれ独自のコードベース、インフラストラクチャ、データベースを持ちます。複数のマイクロサービスは、Web APIやメッセージングキューを介した通信により連携し、着信イベントに対応します。
Sam Newman氏は著書『Building Microservices』の中で、「マイクロサービスは小さく、自律的で、連携するサービスである」と簡潔に定義しています。この定義には、マイクロサービスの3つの重要な側面が包含されています。マイクロサービスのコードベースが「小さい」のは、ひとつの秀でた機能に集中しているためです。サイズが小さいということは、コードの作成維持が個人の開発者や小人数のチームで事足りることを意味します。また、「自律的」であるため、マイクロサービスのデプロイやスケールアップを必要に応じて実行できます。マイクロサービスの内部が変更された場合でも、他のマイクロサービスを担当するチームに相談する必要はありません。これが可能となるのは、マイクロサービスの「連携」で、マイクロサービス内部の動作を公開しないメカニズム（明確に定義されたAPIなど）により通信が行われるためです。
マイクロサービスによる開発
多くの場合、プロジェクトの成長に伴って他のアーキテクチャモデルで発生する問題を解決するために、マイクロサービスのアーキテクチャが採用されます。従来のモノリシックなアーキテクチャでは、機能を論理的にコンポーネントモジュールに分けることはできても、すべてのモジュールは単一のコードベースに収められ、通常はモジュール間に複雑な相互依存関係があります。そのため、他のモジュールを壊すことなく任意のモジュールのコードを変更することは困難でした。開発者が少数のモジュールに集中している場合でも、他のモジュールの変更が作業対象のモジュールに影響する可能性があるため、コードベース全体の変更を追跡するためには時間と労力を要します。ビジネスを拡大するために新しい開発者を採用しても、膨大なコードベースを習得して機能追加やバグ修正を安全に行えるようになるまでに長い期間が必要なため、収穫逓減は避けられません。
ソフトウェアの機能をマイクロサービスとしてコンポーネント化することで、プロジェクトのスケールアップが容易になります。システムごとに個別のコードベースを使用することで、開発者はコードを変更したときの影響を容易に判断できます。サービスごとに個別のデプロイとインフラストラクチャを使用することで、DevOpsチームは必要な場所だけにコンピューティングリソースを容易に追加できます。
マイクロサービスベースのアプリケーションを構築するには、アプリケーションのコンポーネント間の連携を理解し、コンポーネントの分離を可能にするインターフェイスを設計する必要があります。Netflixのリードクラウドアーキテクトを務めたAdrian Cockcroft氏が説明するように、マイクロサービスアーキテクチャの目標は、アプリケーションを構成するマイクロサービスの緩い結合と独立性による相互作用を実現することです。これは、自社サービスと外部サービスプロバイダーのシステムとの間で行われる相互作用と同様のものです。
マイクロサービスの管理
マイクロサービスは、何らかの形式のコンテナ化と組み合わせて使用されることが多く、サービス用管理ツールの多くでは、コンテナの管理とスケーリングが中心の機能となります。KubernetesやDocker Swarmのような一般的な管理ツールは、マイクロサービスを念頭に置いて設計されています。マイクロサービスは、Amazon Elastic Container Service（ECS）のようなコンテナや仮想マシンを管理するためのプラットフォームにデプロイされることがあります。 しかし、より一般的には、Amazon Elastic Kubernetes Service（EKS）、Azure Kubernetes Service（AKS）、Google Kubernetes Engine（GKE）などのKubernetesマネージドクラウドプラットフォームや、Red Hat OpenShift Container PlatformやSUSE RancherrなどのKubernetes PaaSプラットフォームにデプロイされます。
マイクロサービスのデプロイは、モノリシックなアーキテクチャからの移行に伴うタスクの中でも、特に困難です。複数のドメインにわたってAPIのバージョンや統合テストを考慮するという、モノリシックなアーキテクチャでは問題にならなかったことが必要となるためです。そのため、マイクロサービスのデプロイでは、各コンポーネントが円滑に動作することを保証するための自動モニタリングが重要となります。モノリシックなアーキテクチャに比べて、マイクロサービスアプリケーションでは部分的な障害の発生が多くなるため、障害管理を念頭に置いたシステム設計が必要です。
NGINX Plusはどのように役立ちますか？
NGINX PlusとNGINXは、クラス最高のロードバランシングソリューションであり、Dropbox、Netflix、Zyngaなどの高トラフィックのWebサイトで使用されています。世界中で4.5億以上のWebサイトがNGINX PlusとNGINX Open Sourceを利用しており、迅速かつ確実で安全なコンテンツのデリバリーを実現しています。
NGINX Plusは、ソフトウェアベースのアプリケーションデリバリーコントローラー（ADC）として、現代のマイクロサービスアーキテクチャに不可欠なスピード、構成性、信頼性を提供するように設計されています。
- NGINX Plusは、シンプルなサービス管理のための動的な再構成を可能にし、Kubernetesなどの一般的なマイクロサービス管理ツールと容易に統合できます。Netflixのような大手企業は、マイクロサービスのデプロイの中核としてNGINXを活用しています。
- 大規模な運用には、詳細なモニタリングが必要です。NGINX Plusの堅牢なライブアクティビティ モニタリングは、サービスが負荷にどのように対応するかを確認して、必要な場所にリソースを集中させる上で役立ちます。
- NGINX Plusのソフトウェアベースのロードバランサー機能は、構成が常に変更されるマルチサービスのデプロイにおけるサービスディスカバリに最適です。
NGINX Controllerは、NGINXマイクロサービスソリューション向けのアプリケーションデリバリー管理を提供します。
コンテナ化がマイクロサービスへの移行の一環となっている場合には、NGINX Ingress ControllerとNGINX Service Meshが、コンテナ化されたマイクロサービス向けの管理ソリューションを提供するとともに、異種混在のマイクロサービス環境間を橋渡しする役割も担います。
