業務でgRPCを使いはじめて、マイクロサービス化もすこしずつ進みだしてきたので、一旦マイクロサービスを支える仕組み、Service Meshについて調べてまとめてみる。

Service Meshとしてあげられるのは最近だとIstio、Envoy、そしてLinkerdがあると思います。 特にEnvoyとLinkerdは CNCFのプロジェクト の一つとなっています。

CNCF

Cloud Native Computing Foundation の略

CNCFは、クラウドネイティブなアプリケーションとサービスの開発を標榜する、オープンソースのLinux財団組織である。その定款では‘クラウドネイティブ’システムを、以下の特性を持つものとして定義している。コンテナパッケージ – アプリケーションデプロイメントの分離したユニットとして、アプリケーションとプロセスがソフトウェアコンテナ内で動作すること。動的管理 – 集中的なオーケストレーションプロセスによるアクティブなスケジュールと管理が行われること。マイクロサービス指向 – (サービスポイント経由などの)明示的に記述された依存関係を持った疎結合であること、である。

参考: https://www.infoq.com/jp/news/2017/05/cncf-growing-portfolio

Service Mesh

Linkerd

https://linkerd.io/ https://github.com/linkerd/linkerd

linkerd is a transparent service mesh, designed to make modern applications safe and sane by transparently adding service discovery, load balancing, failure handling, instrumentation, and routing to all inter-service communication.

コンテナに関して

The Linkerd service mesh is deployed as a Kubernetes DaemonSet, running one Linkerd pod on each node of the cluster. Applications running in Kubernetes can then take advantage of the service mesh by sending all of their network traffic through the Linkerd running on their node.

linkerdはdaemonSetで各Nodeに1Pods立ち上げる。

https://linkerd.io/advanced/deployment/#sidecar 実はsidecarとしても使う事が出来る。

However, the sidecar model also has a downside: deploying per pod means that resource costs scale per pod. If your services are lightweight and you run many instances, like Monzo (who built an entire bank on top of linkerd and Kubernetes), then the cost of using sidecars can be quite high.

Linkerdは単体でトラフィック管理、経路判断なども行うので、少なくは無いリソースを利用する。 その為、daemonSetで各ノード1Podではなく、Sidecarとして全てのPodに作る事になると、やはりリソースがそのために使われてしまう。 確かに悩みだ

役割

  • Scala
  • L7/L4 Loadbarancer
  • Service discovery
  • 経路破壊、レイテンシを考慮したロードバランサを提供

    Envoy

https://www.envoyproxy.io/ https://github.com/envoyproxy/envoy

ENVOY IS AN OPEN SOURCE EDGE AND SERVICE PROXY, DESIGNED FOR CLOUD-NATIVE APPLICATIONS

役割

  • C++
  • L7/L4 Loadbarancer
  • Service discovery
  • 経路破壊、レイテンシを考慮したロードバランサを提供

Istio

https://istio.io/ https://github.com/istio/istio

An open platform to connect, manage, and secure microservices

アーキテクチャ

https://istio.io/docs/concepts/what-is-istio/overview.html

Envoy

  • Envoy Proxyの拡張バージョンを利用
  • EnvoyはSidecarとして、Kubernetes podに作られる
  • Envoyは他のpodのEnvoyと通信を行い、各サービスにメッセージを伝える

Sidecar とは、Dockerを使って開発する際のパターンの一つで、Sidecar Pattern を指す。

  1. Podsのメインコンテナ同士の結合をなくし、Sidecarコンテナによって結合、機能拡張を行う
  2. Service Meshを例にあげると、本来メインコンテナが知るべきAPIのコンテナ情報を、SidecarがService Desicoveryとしてルート検索を行い、対象のPodsまで届ける
  3. 更にはLBとしての機能も兼ねているので、特定のPodの負荷が高い場合は、負荷が低いPodに導いたり、死んでるPodには届けないようにしたりなどトラフィック管理・監視も行っている
  4. これによってメインコンテナは、依存サービスの経路・負荷・生き死にを意識しなくても良くなる

この様にSidecarはメインコンテナをサポートをする為の存在と定義されている。

Mixer

  • Envoy間のアクセス制御

Pilot

  • Envoyに対してトラフィックに応じてルーティングルールを生成して、Envoyに伝える
  • A/Bテスト、Canariaテスト、タイムアウトの為のトラフィック管理も行う

Istio-Auth

  • Service Mesh内の暗号化されていない通信の暗号化を行う
  • Server To Serverへの認証機能を提供

IstioとLinkerdが連携

https://linkerd.io/getting-started/istio/

Istio is an open platform to connect, manage, and secure microservices. Linkerd is an open source service mesh for cloud native applications. Istio and Linkerd can work together, with Istio acting as a control plane across Linkerd instances.

IstioはEnvoyだけサポート可と思いきや、Linkerdのサポートもしている

Linkerd’s Istio integration is experimental and currently supports routing rules, ingress, egress, and metrics. Support for fault injection, destination policy, route policy, ACLs, and auth are coming soon.

ただし、Mixer, Pilot, Istio-Authが提供している機能との連携はまだまだのようです。