「サービスメッシュとは何か」について調べた

はじめに

最近、「サービスメッシュ」という語を見聞きする機会が増えた。
概念を正しく理解しておきたいと思って、このところ調べていたので、ここにまとめを記しておく。

はじめに
サービスメッシュとは何か
プロダクト
アーキテクチャー
サービスメッシュが必要とされた背景
サービスメッシュが登場した歴史
終わりに
参考

サービスメッシュとは何か

TL;DR

Microservicesとして構成される分散システムにおいて、サービス間通信を担う専用のレイヤ。
サービスディスカバリ、負荷分散、トラフィック制御、通信のセキュア化などの機能を実現し、個々のサービスから利用可能にする。
代表的なプロダクトとして、 IstioやLinkerdが挙げられる。

出典

上のようにまとめるにあたって参照した記事、文書、書籍を紹介する。
若干、相互に食い違う内容があったので、適当に自分が穏当と思うように取捨選択した。

What's a service mesh? And why do I need one? - blog.buoyant ... LinkerdやConduit*1の開発元であるBuoyant社CEOであるWilliam Morganの記事。Service Meshを語る上で紹介されることが多い(と思う)。
Istio / What is Istio? - Istio Documentation
- ここではむしろ、サービスメッシュをMicroservicesに付随するネットワークや相互作用と見ている。
Red Hat Developer | Introducing Istio Service Mesh for Microservices

私の解釈

もはや、当該レイヤで動作する(ソフトウェア)システムと定義してしまった方がしっくり来る。
なぜなら、上で述べたような機能を提供するもの(として認知されてきている)なので。

「service mesh」という語が登場するようになった当初は、単にMicroservices上のネットワークを指していたような表現が見られるが、いつの間にか「そのレイヤで動作するソフトウェア」という意味で述べられることが普通になってきたような気がする。

プロダクト

2018/8/11現在、自分が把握しているもの:

Istio
Envoy ... CNCF Incubation Project. Istio内ではプロキシ機能を担うコアコンポーネント
Buoyant社製品(※OSS)
- Linkerd ... CNCF Incubation Project.
- Conduit
Consul ... いつの間にか「distributed service mesh」となっている。また、Connectという新機能でsidecar proxyや通信の暗号化が実現される。

アーキテクチャー

サービスメッシュは上で述べたような概念のシステムなので、その実装は色々あり得るはずだが、IstioやLinkerdが事実上の標準実装となっているような向きがある。
正直、まだそんなに踏み込んで見てないのだけど、それらの構成要素は一致しており、よく似たアーキテクチャーとなっているようだ。

Istioのドキュメントから図を引用しておこう。

図: Istio Architecture

サービスメッシュ・システムの標準的な構成要素:

Data Plane ... サービス間の通信レイヤ
- Sidecar Proxy ... 個々のサービス・プロセスとともに配置され、in/out双方向の通信を中継する。
Control Plane ... クラスタ内に配置される独立したサービスで、様々な中央集権的機能を担う。例えば、プロキシの管理を含むData Planeの制御や、設定変更のためのAPIが挙げられる。

その他参考:

サービスメッシュが必要とされた背景

既に上に挙げたWilliam Morganの記事から、内容をかいつまんで訳す。

大規模なMicroservicesシステムはGoogleやNetflix, Twitterといった巨大企業で発展していった。
アプリケーションが多数のサービスに分割され、複雑化する内に、汎用的な通信レイヤが必要とされた。しかし、それらは「重厚なクライアントライブラリ」の形を取った。
TwitterのFinagle, NetflixのHystrix, GoogleのStubbyが具体例だ。
それらこそが最初の「サービスメッシュ」だと言える。

この「重厚なクライアントライブラリ」の問題点は、以下だ。