マイクロサービス

マイクロサービス（英語：microservices）とは、ソフトウェア開発の技法の1つであり、1つのアプリケーションを、ビジネス機能に沿った複数の小さいサービスの疎に結合された集合体として構成するサービス指向アーキテクチャ（service-oriented architecture; SOA）の1種である。マイクロサービスアーキテクチャでは、各サービスはを持ち、軽量なプロトコルを用いて通信を行う。
アプリケーションを異なる小さなサービスに分割することの利点は、が高くなることである。これによって、アプリケーションの理解、開発、テストがより簡単に行えるようになり、アーキテクチャの腐敗に対する弾力性が向上する。マイクロサービスによる開発を行うことで、開発が並列化され、少人数の自律的なチームにより、各チームが所有するサービスを独立に、開発、デプロイ、スケールさせることが可能になる。また、継続的リファクタリングを通して、個々のサービスのアーキテクチャ全体を置き換えることも可能になる。マイクロサービスベースのアーキテクチャでは、継続的デリバリーと継続的デプロイが可能になる。
概要.
2014年、ThoughtWorks社のマーチン・ファウラーとジェームス・ルイスが提唱したソフトウェアアーキテクチャである。
何がマイクロサービスであるか、という公式な定義は存在しないが、業界では徐々にコンセンサスが形成されつつある。マイクロサービスを特徴づける定義としてよく引き合いに出されるものとしては、以下のような点が挙げられる。
マイクロサービスは、モノリシックなアプリケーション内にある1つのレイヤー（たとえば、ウェブコントローラや、フロントエンド向けバックエンド（backend-for-frontend））ではない。むしろ、自身のみでビジネス機能を提供する、明確なインターフェイスを持った小さなピースである（サービス内部のコンポーネントとしてレイヤーアーキテクチャを実装することさえある）。戦略的な観点からは、マイクロサービスは 「ただ1つのことをして、それをうまくやる」というUnix哲学に本質的には従っているものとして考えられる。マーティン・ファウラーは、マイクロサービス・アーキテクチャには次のような性質があると述べている。
なお、「マイクロサービス」という用語は、2011年5月にヴェネツィア近郊のソフトウェアアーキテクトのワークショップで議論され、参加者が最近調査した共通のアーキテクチャースタイルと見なした内容を提唱者らが説明している。2012年5月、同グループが最も適切な名前として「マイクロサービス」を決定した。
特徴.
提唱者らは下記に述べる特性を挙げているがこれらは定義ではなく、すべての特性をもつ必要はないとしている。
背景.
従来のソフトウェアアーキテクチャは単一のアプリケーションとして構築されたモノリシックアーキテクチャが主流であった。しかし、ビジネスや環境の変化とともにアプリケーションへの変更サイクルが短くなり、特にモノリシックアーキテクチャの場合はアプリケーション全体を再構築して展開する必要がある。時間の経過とともに、適切なモジュール構造を維持することは難しいため、そのモジュール内の1つのモジュールにしか影響を与えない変更を維持するのが難しくなってしまう。
技術の発展とサービスの多様化に伴い、モジュールが独立して展開可能でなおかつスケーラブルであるようになる。
また、堅固なモジュール境界を提供し、それぞれの機能が異なるプログラミング言語で書かれることを可能にした。さらに、異なるチームによって開発・運用管理することもできるようになることで、一部の変更が全体へ影響を及ぼすことへのリスクがサービスの独立によって解消できるアプローチスタイルが出来上がった。
課題.
モノリシックアーキテクチャと比較し、下記の欠点を上げている。
方法論.
提唱当初のプラクティス.
2014年当初の提唱者らは「マイクロサービスがソフトウェアアーキテクチャの将来の方向性であると確信していると主張しているわけではない」と語る。
アプローチのひとつとしては、マイクロサービスアーキテクチャから始めるべきではないということ。代わりにモノリスで始め、モジュール化したままにし、モノリスが問題になったらマイクロサービスに移行・分割していく。
サービスメッシュ.
マイクロサービスを構成するネットワーク基盤をサービスメッシュと呼び、ネットワーク基盤をアプリケーションから隠蔽することでマイクロサービスをより容易に実現しようと試みられている。
サービスメッシュ（Service Mesh）は、アプリケーションを構成するマイクロサービス群からなるネットワークである。マイクロサービス間通信を用いてアプリケーションを構成するには、データ転送の制御と監視が必須である。要件の例としては以下が挙げられる。
さらにA/Bテストやカナリアデプロイ、レート制限、アクセス制御、認証、カオスエンジニアリングなど様々なネットワーク関連の要件が発生しうる。サービスメッシュに着目した場合、ネットワークに由来するこれらの困難さをアプリケーションから隠蔽するためにプロキシなどの様々な手法が用いられる。
ネットワークの転送部は転送を担うデータプレーン（data plane）と転送制御を決定するコントロールプレーン（control plane）に分離できる（c.f. Software Defined Networking）。アプリケーションからデータプレーンおよびコントロールプレーンを分離することでアプリケーションからサービスメッシュを隠蔽する手法が主流である。
例えばEnvoyはService Meshにおけるデータプレーンプロキシである。Envoyプロキシは各マイクロサービスに同梱され、Envoy間で通信を行うことでサービスメッシュを構成する。マイクロサービスは同梱されるEnvoyプロキシのみを見ているため、サービスAppにとってサービスメッシュは透過的に扱われる（隠蔽されている）。Eovoyデータプレーンが利用する制御情報は別に用意されたコントロールプレーンから提供される（例: humanコントロールプレーンによる静的設定ファイル、Istioによるコントロールプレーンサービス）。
クラウドコンピューティングによるマネージドコントロールプレーンも提供されている。例えばAmazon Web ServicesはAWS App MeshによりEnvoyをデータプレーンとしたマネージドコントロールプレーンを提供している。