1つのアプリケーションを機能別にAPIとして切り出したもの。大規模化・複雑化が進むにつれ、開発コストおよび新規メンバーの参入コストが高くなるため、2014年頃から流行りだした。対して、もともとの1枚岩のアプリケーションはmonolithicと呼ばれる。日本だとモノリスとも言われる。
小さくなったのは良いが、「連携設定」「APIのセキュリティ」「リトライ処理」などコストが増した。また、個数の増加に伴い、新しいMSを追加したときの影響範囲も分かりづらく、それらを解消するために「監視体制」「サーキットブレイク」なども必要となり、複雑性を増していった。
各MSはビジネスロジック(BL)以外にも、手段(MS)のために不要な機能を多く持つことになった。本来モノリスであれば、開発者はBLだけに注力できていたが、MS起因の贅肉があまりにも大きく複雑でしかも冗長なため、開発者は本質的でない部分で疲弊し始めた。
開発者はBLだけの生活に戻りたいと思った。MSの中から、BL以外の部分を全部切り出して、それらをSidecarとして共通化した。名前は恐らく、BLをバイク本体とみなして、後付けでMSの税金部分を全部のせしたパーツ(Sidecar)をくっつけるイメージ。また、外部からはBL部分と同様にAPIとして叩けるため、Sidecar Proxyと丁寧に呼ぶ人もいる。
MS(BL)とSidecarの組(GCPならPod)の集団が、Sidecarによってうまく連携するようにした構成をService Meshと呼ぶ。これにより、開発者は本質的なBLをMSとして提供するだけで良くなった。あとは、PodにSidecarを埋め込んだり、Sidecarのネットワーク層の管理を、誰かがうまいことやってくれればいい。この誰かを「Control Plane」と呼ぶ。
デプロイ手段のBlue/Green方式では、「安全な切り戻し」が実現できる反面、短時間とは言え「エラー時は全滅」となり影響が大きい。Service Meshにはサービスディスカバリ機能があるため、同時に新旧のMSを稼働させることができる。また、トラフィック制御を細かくできるため、「特定条件にマッチした全体の10%だけ新しいMSに向ける」といった事ができる。この方式はカナリアテスト(Canary Deployment)と呼ばれる。
Service Meshはパターン(概念)。Istioはその実装の1つ。
Istioでは、SidecarをEnvoyによって実装している。EnvoyはNginxの仲間。もちろんproxyできる。このEnvoy proxyの大群を管理するControl Plane部分の実装がIstiod。内部的にはPilot、Citadel、Gallyという名前で機能分解されている。
- Pilot: サービス(Envoy sidecar)ディスカバリ、トラフィック管理、ルーティング
- Citadel: サービスやユーザの認証、証明書管理
- Gally: 設定とサービス管理