「サービスメッシュ」とは、分散コンピューティング向けとして新たに台頭してきているサービスマネージャの一種だ。
サービスメッシュという新たなアーキテクチャによって、サーバ側アプリケーションを構成する小さなコンポーネント群（代表的なものとしてはマイクロサービス）が互いに動的にリンクされ、1つのアプリケーションとして機能できるようになる。これらのコンポーネント群は、単一のアプリケーションを実現するために意図的に作り上げられたコンポーネントである場合や、他のアプリケーションとワークロードを共有することでメリットを生み出そうとする、出自の異なるコンポーネントである場合もある。
実世界で今使用できるサービスメッシュ
この分野における最も古い取り組みはおそらく、「Linkerd」（リンカーディーと読む）というオープンソースプロジェクトであり、同プロジェクトはその開発を通じてサービスメッシュの必要性を初めて明らかにした。同プロジェクトは現在、Cloud Native Computing Foundation（CNCF）によって開発が続けられている。「Twitter」プロジェクトから派生したLinkerdプロジェクトによって、各種サービスを実現するプロキシが、専用のネットワーク経由で類似のプロキシと通信できる能力を備えるという考え方が普及した。サービスメッシュの商用化を目指すBuoyantは最近、「Conduit」という類似の取り組みをLinkerdプロジェクトにマージした。その結果、「Linkerd 2.0」が生み出されている。
一方、ライドシェアリングサービスLyftのエンジニアであるMatt Klein氏は、既存コード（レガシーな「一枚岩」に縛られているものであっても）がAPIを備えたマイクロサービスのようなかたちで表現されるネットワークを構築するための手法を考え出した。この手法は「Envoy」として実装されている。そしてEnvoyは現在、IBMやGoogleの成果とともに、「Istio」というフレームワークを作り上げるプロジェクトの構成コンポーネントの1つとなっている。
これまでの経緯
サービスメッシュが期待通りに動作する際には、分散されたデータセンタープラットフォームを共有する、数千にもおよぶマイクロサービスが互いにやり取りし、アプリケーションの一部として連携動作するようになる。そしてこうしたことは、これらのマイクロサービスが当初から該当アプリケーションのコンポーネントとして作り出されていない場合でも実現できる。
クライアント／サーバやウェブアプリケーションの世界でサービスメッシュに相当するのはミドルウェアだ（ミドルウェアについてはなじみがあるかもしれない）。21世紀に入ってから、ウェブアプリケーションのコンポーネントは非同期的に（互いに異なるタイミングで）処理されるようになったため、プロセス内で連携とまでは言わないが、通信するための何らかの手段が必要となった。エンタープライズサービスバス（ESB）は縁の下でこうした通信を実現するミドルウェアの一種であり、これによって初めて、サーバ側のアプリケーション同士を統合できるようになった。
