この記事はEnvoyの作者であるMatt Kleinさんの以下の記事を
Service mesh data plane vs. control plane
本人の許可をえて日本語訳したものになります。
Sure! Please credit me as the original author and link to the original article. Thank you!
— Matt Klein (@mattklein123) 2018年5月30日
Envoyの存在を知って以降、service meshに関して興味を持ってあれこれと調べていたのですが、まだ発展途上中の分野のためか、言葉の定義がはっきりと固まっておらず、色々な情報に触れる中で混乱することがありました。
が、この記事を読んで、data plane と control planeの区分けがはっきりしたことで、諸々の情報をキャッチアップする際の１つの軸になったと感じているので、より多くの人に読まれるといいなという思いと、自分の知識整理も兼ねて翻訳してみることにしました。
なお、
service meshにおけるcontrol plane と data planeの話の続き という記事も書いてますので、data plane, control planeのことをもう少し知りたい！と思った方は、是非、こちらもご覧ください。
以下、翻訳になります。
Service mesh data plane vs. control plane
"service mesh" という考え方がここ２年ほどで急激に人気になり、この分野に次々と多くの新しい人が入ってくるようになって、コミュニティの中で、別領域のプロダクトを比較し始めるという混乱が同じように増えているように見えます。
この状況に関しては、７月に私が書いた一連のツイートに要約されています
service mesh confusion #1: linkerd ~= nginx ~= haproxy ~= envoy. None of them equal istio. istio is something else entirely. 1/
— Matt Klein (@mattklein123) 2017年7月19日
The former are just dataplanes. By themselves they do nothing. They need to be configured into something larger. 2/
— Matt Klein (@mattklein123) 2017年7月19日
istio is an example of a unified control plane that ties the pieces together in a coherent way. different layer. /end
— Matt Klein (@mattklein123) 2017年7月19日
先のツイートはいくつかの異なるプロジェクト(Linkerd, NGINX, HAProxy, Envoy, Istio) について言及していますが、service meshのdata planeとcontrol plane という汎用的な概念を紹介していることがより重要になります。この記事の中では、一歩下がって、私が上位概念としてのdata planeとcontrole planeという言葉にどのような意味を込めていて、ツイートの中で言及した具体的なプロジェクトにどのように関係付けられるかを書いていきたいと思います。
What is a service mesh, really?
図1
図1はservice meshのコンセプトを最も基本的な形で表現しています。4つのサービスクラスター(A-D) があり、各サービスのインスタンスにはnetwork proxyの役割を果たすsidecarが一緒に配置されています。各サービスからの全てのネットワークのトラフィック(HTTP, REST, gRPC, Redis 等)はsidecar proxyを経由して正しい接続先に届けられます。これによって、各サービスのインスタンスはネットワーク全体を気にすることなく、local proxyのことだけ知って入れば良いことになるのです。つまり、複雑なネットワークは各サービスの開発者からは抽象化された存在となるのです。
The data plane
service meshの中で、sidecar proxyは以下のタスクを担当します
Service dicovery: upstream/backendのserviceの全ての利用可能な接続先の一覧は？
Health checking: service discoveryで返されてくるupstreamのインタンスはhealtyで接続可能な状態か？これは、active(e.g. /healthcheck endpointへのping)、passive(e.g. 3回連続して5xxが返ってきたらunhealthyとみなす)、両方のhealth checkを含みます。
Routing: /foo にRESTで接続したい時、そのリクエストはどのupstreamのサービスクラスタに送信するべきか？timeoutの設定は？circut breakerの設定は?リクエストが失敗した時はリトライすべきか?
Authentication and authorization: 受け取ったリクエストに対して、呼び出し元はmTLSなどの正しい方式での暗号化を行なっているかの確認。もし、正しい形式であった場合、呼び出し元はそのendpointを呼ぶことを許可されているのか、もしくはunauthenticatedのレスポンスを返すべきか。
Observability: 各リクエストに対して、詳細な統計、ロギング、分散トレーシングが生成され、運用者がトラフィックがどのように分散しているかを把握でき、問題が起きた時にはデバッグできるようになっているべきです。
これらの項目はservice meshのdata planeの責務です。つまり、sidecar proxyがdata planeそのものなのです。別の言い方をすれば、data planeは条件に従っての暗号化/復号化、リクエストのフォワーディング、そして、サービスのインスタンス上を流れる全てのネットワークパケットの観測をしているのです。
The control plane
sidecar proxyであるdata planeが実現するネットワークの抽象化は素晴らしいものです。しかし、proxyは /foo に対するリクエストをservice Bにルーティングすべきという情報をどのように知ればいいのでしょうか？proxyがクエリーするためのservice discoveryの元データはどのようにして生成されるのでしょうか？ロードバランス、タイムアウト、サーキットブレーカーの設定はどのようにして行われるのでしょうか？ blue/greenや徐々にリクエストの流量の比率を変えていくようなデプロイはどのようにして実現できるでしょうか？誰がシステム全体としての認証/認可の設定をすべきなのでしょうか？
上に挙げた全ての項目はservice meshのcontrol planeの責務です。control planeはステートレスなsidecar proxyの集まりを分散システムへと変化させるのです。
多くの技術者がdata planeとcontrol planeというはっきり分かれた概念を混同してしまうのは、多くの人にとってdata planeは馴染み深いものですが、control planeはあまり扱ったことがないからではないかと私は考えています。長い間、私たち自身が物理的なネットワークルーターでありスイッチであったのです。A地点からB地点までpacket/requestがどう流れるべきかを私たち自身が把握しており、ハードウェアやソフトウェアを使ってそれを実現しているのです。新しくソフトウェアのproxyが産み出されていますが、これは、これまで私が長い間使ってきたツールの高等版なのです。
図2
control plane自体は長く使われてきたと言えますが、多くのネットワーク運用者はこれをテクノロジーであるとは考えてはいないでしょう。その理由は簡単です。 - 今日のcontrol planeの多くは私たち自身なのです。
図２は私が"人力 control plane" と呼んでいるものを表しています。このタイプでのデプロイメント(現在でもとても幅広く使われている方式でもあります)では、(大抵はとても気難しい)人間が静的な設定を作り込み - 時には何らかのscriptのツールを使いながら - 依頼をベースにそれらを全てのproxyに対してデプロイするのです。proxyは配布された設定を読み込み、更新された設定を元にdata planeとしての処理を行います。
図3
図3は"進化した"serivce meshのcontol planeを表しています。次のようなパーツから成り立っています。
The Human: システム全体に対しての高レベルでの判断を行うための(希望としては、少しはとっつきやすくなった)人間の介在が残ります。
Control plane UI: 人間はシステムを制御するために何らかのUIを操作します。これはweb画面、CLI、 または他の形のインターフェイスかも知れません。UIを通して、運用者はデプロイの制御(blue/green, トラフィックの推移のさせ方)、認証と認可の設定、ルーティングテーブル(e.g. service A が /foo にリクエストしたらどうすべきか)、ロードバランサーの設定(e.g. タイムアウト、リトライ、サーキットブレーカー) といったグローバルなシステムの設定を行います。
Workload scheduler: サービスは何らかのスケジューリングシステム(e.g. Kubernetes, Nomad)の上で動いています。スケジューラはサービスと一緒にsidecar proxyを起動させることが責務です。
Service discovery: スケジューラはサービスをstart/stopするたびに、最新の状態をservice discoveryのシステムに通知します。
Sidecar proxy configuration APIs: sidecar proxyは運用者を介在させることなくeventual consistentな何らかの方式で様々なシステムのコンポーネントから、動的に設定を取得します。システム全体としては、全ての動いているサービスのインスタンスとsidecar proxyが、eventualに収束していくことで成立しています。Envoyの共通data plane APIは、この仕組みをどのように実践することができるかの一例です。
突き詰めていくと、control planeのゴール/責務はdata planeにeventualに反映されていくポリシーを設定することです。 control planeが進化するにつれ、システム構成は運用者から抽象化されていき、運用者の介在が不要になっていくのです。(control planeが意図通りに動作していることが前提ですけど！)
Data plane vs. control plane summary
Service mesh data plane : システム内の全てのpacket/requestに関与する。サービスディスカバリ、ヘルスチェック、ルーティング、ロードバランス、認証/認可、observabilityが責務。
Service mesh control plane : サービスメッシュ内の起動中の全てのdata planeに対して、ポリシーと設定を提供する。システム内のpacket/requestに関与することはない。control planeの集まりを分散システムへと変化させる。
Current project landscape
ここまでの説明は一旦脇において、今のservice meshの状況を見てみましょう。
Data planes: Linkerd, NGINX, HAProxy, Envoy, Traefik
Control planes: Istio, Nelson, SmartStack
各プロジェクトの詳細を見ていくのではなく、現在エコシステムに混乱をもたらしていると思うポイントをサラッと説明したいと思います。
Linkerdは2016年初期から注目を集めた最初のservice mesh data planeで、service meshのデザインパターンへの注目と関心をもたらす大きな役割を果たしました。Envoyは6ヶ月遅れで発表されました(Lyftでは2015年の後半から本番環境で動いてはいましたが)。LinkerdとEnvoyが"service mesh"の議論の中で最もよく言及される２つのプロジェクトになっています。
Istioは2017年の5月に発表されました。Istioプロジェクトのゴールは図3で示したような進化したcontrol planeです。IstioのデフォルトのproxyはEnvoyです。つまり、Istioはcontrol planeで、Envoyはdata planeです。短期間の間に、Istioは大きな関心を集め、他のdata planeがEnvoyの代わりのproxyとなるべく、Istioとのintergrationを開始しました(LinkerdとNGINXの両方ともIstioとのintegrationを発表しています)。一つの種類のcontrol planeで様々な種類のdata planeを利用することができるというのは、control planeとdata planeが必ずしも密結合ではないことを意味しています。Envoyの共通data plane APIのようなAPIの存在はこの２つの架け橋となるのです。
NelsonとSmartStackはcontrol plane vs data planeの構図をより分かりやすくしてくれました。NelsonはEnvoyをproxyとして利用しつつ、HashiCorp製品(Nomadなど)と組み合わせて使える安定したservice mesh control planeを作ることができます。SmartStackはservice meshの界の最初のニューウェーブです。SmartStackはHAProxyやNGINXと組み合わせられるcontrol planeを作ることができ、service mesh control planeとdata planeを疎結合にできることを示してくれたのです。
service mesh microservice ネットワークは、まさに今多くの注目を集めていて (それも正しい方向で！)、多くのプロジェクトやベンダーが参入してきています。次の数年のうちに、data planeとcontrol planeの両方でたくさんのイノベーションが生まれるのを目にするでしょうし、より様々な種類のコンポーネントの組み合わせでてくるでしょう。マイクロサービスのネットワークの最終的なゴールは、気にする必要のない透明な存在になり、(希望としては、もっととっつきやすくなった) 運用者にとって魔法のように魅力的であることです。
Key takeaways
- service meshは２つの異なる部品で成り立っています: data planeとcontrol planeです。両方が必要なのです。両方揃っていなければシステムは動きません。
- 多くの人がcontrol planeのことを実は知っています - そのcontrol planeというのはあなた自身のことかもしれませんが！
- data plane同士では、機能、パフォーマンス、設定の柔軟性、拡張性を通じての競争が繰り広げられています。
- control plane同士では、機能、設定の柔軟性、拡張性、使いやすさを通じての競争が繰り広げられています。
- 一つのcontrol planeが、複数の種類のdata planeを扱うことのできる、正しく抽象化されたAPIを含んでいる場合もあります。