先日、Envoyの作者であるMattさんの記事の翻訳を投稿しましたが、その記事に対する自分なりのフォローアップになります。 (限定公開していた関係で、時系列が逆になってますが、こっちを後に公開しました)
"Service mesh data plane vs. control plane" by Matt Klein の日本語訳
service mesh周り、色々とキャッチアップを続けているはずなのに、何だか言ってることがよく分からんな〜ということがちょくちょくありました。そんな中、Mattさんの上記の記事に出会って読み進め、スーッと霧が晴れていくような感じになり、その後の情報の吸収度が大きく変わった感覚があったので、翻訳してみました。しかし、ただ、翻訳するだけでは芸がないので、最近の事例等を交えつつ、control plane vs data planeの観点からあれこれともう少しあれこれと調べてみました。
Envoyの導入事例を改めてみてみる
control planeとしてIstioを使った本番導入事例というのを、まだ見つけれていませんが、data planeとしてEnvoyの導入した事例はMattさんがいるLyftがバリバリ使っているのは勿論のこと、他にもチラホラと出てきています。
- Cookpad
この分野に興味あるエンジニアであれば、この記事は目にされた方は多いと思います。
Service Mesh and Cookpad
冒頭に、先のdata plane vs control planeの記事へのリンクがあり、また、↓の説明がなされています。
クックパッドでのサービスメッシュは data-plane として Envoy を採用し、control-plane は自作、という構成を選択をしました。
(略)
当初実現したいことと Istio のソフトウェア自体の複雑さを考慮して、小さく始められる自作 control-plane という道を選びました。
- Booking.com
kubeconで発表のあった事例
Introducing Envoy-Based Service Mesh at Booking.com
資料のリンク
Booking.comもIstioの導入を見送って、自分たちでcontrol planeを実装したそうです。
(上記リンクの資料から引用)
恐らく、お互いの存在を知らずに技術選定したと思うのですが、初期にEnvoyを導入した２社が揃って、control planeを自作したというのは面白い事実ですね。Istioという各cloud vendor一押しのcontrol planeはもう一息って感じで、現状ではデファクトと言えるcontrol planeは無いという状況と言えそうです。
Lyftはどうしてるの？
この話の流れだと、本家のLyftはどうしてるんだ？って思いますが、
Booking.comの事例と同じくkubeconの↓のプレゼンで少し紹介されていて、
Envoy Project Intro
昔は、“human control plane” だったそうです。 ("human control plane" については、最初にリンクしているMattさんの記事の中で言及があります。）
パッと見ただけで、オペミスでめちゃ事故りそうな予感がしますw
ですが、今は勿論進化していて、"Envoymanager" という名前のcontrol planeがいるそうです。話を聞いていると、自分たちの運用フローに合わせて、相当にcontrol planeを作りこんでいるような印象を受けました。data planeはservice meshを実現する上での共通の機能が提供される所なので、機能要求として大きな差異はないけれど、control planeの所は、アーキテクチャ、開発組織の構造、デプロイのフロー等々、共通化しづらい様々な要因に左右されるため、それなりの作り込みが必要 or Istioのような共通control planeを採用するのであれば、逆に自分たちをそこに合わせていいく〜という姿勢が求められそうだなと思いました。
control planeとしての(？) Consul
そういえば、control planeの責務とされる service discoveryといえば、Hashi corpのConsulの十八番だったよな〜と思って、ちょっと探してみたら、Consulもしっかりとservice mesh対応していました。
Smart Networking with Consul and Service Meshes
ただ、以下の引用部分を読んでみると、Matt先生の記事の中ではIstioはcontrol planeとして紹介されていて、Linkerd, Envoyと並列に並べられるものではないはずだし、Consulはcontrol planeのためのcontrol planeということになり、何のこっちゃ、、、
This post discusses a few first principles around adopting service meshes and how Consul can be used as a control plane for projects like Istio, Linkerd, and Envoy.
もう少し読み進めていくと、↓のような図と説明がありました。
Pilot aims to abstract platform-specific service discovery mechanisms and provide a standard data format that is consumable by the data plane (Envoy). Since Consul provides rich service discovery API, Pilot can be configured to use that data to discover services running in a datacenter
Istioの公式ドキュメントに記載されている図と比較してみると、Consulの位置付けが分かりやすそうです。
Kubernetes, Mesos, CloudFoundryと同じレイヤーにいます。これらのプロダクトが提供しているservice discoveryの機能はpilotが抽象化して受け取ることができ、それを共通APIを使ってdata planeに引き渡すから、service discoveryのレイヤーにconsulも使えるよという話のようです。確かにIstioの一部をcontrolしているといえなくもないけど、これをcontrol planeと言ってしまうのはやや乱暴な気もします。
先のMattさんの記事では、control plane, data planeの２軸だけでしたが、service mesh界隈がもっと熟してきて、他のレイヤーの用語もいい感じの抽象度で合わせられるようになってきたら、この辺どんどんとスッキリ理解しやすいものになっていくのかな〜と思ったりしました。
まとめ
概念をしっかりと抑えれば、service mesh怖くない！