サービスメッシュのLinkerd 2.9を紹介。EWMA実装のロードバランサー機能とは

今回の記事ではLinkerdバージョン2.9を解説するWebinarから、最新機能とロードバランサーのアルゴリズムを紹介する。LinkerdはCNCFにホストされているサービスメッシュのプロジェクトで、軽量、高速、シンプルをゴールとして開発が進められているオープンソースソフトウェアだ。開発をリードするのは、元Twitterのエンジニアが創業したBuoyantである。

このWebinarは2020年11月13日にCNCFのYouTubeチャネルにて公開されたもので、2.9の概要だけではなくLinkerdのアーキテクチャーやデータプレーンとコントロールプレーンの解説、さらにロードバランシングの詳細としてExponentially Weighted Moving Average（指数平滑移動平均、EWMA）のアルゴリズムについても解説している。概要だけに留まらず、より深い解説を行っているのがポイントだ。

Linkerd 2.9を紹介するCNCFのWebinar：CNCF Webinar: What's New in Linkerd 2.9: mTLS for all TCP connections, ARM support, and more

Linkerd 2.9を紹介するのはBuoyantのOliver Gould氏

最初はLinkerdの概略の紹介から始まった。ここでは「Ultralight, ultrafast, security-first service mesh for Kubernetes」というキャッチコピーとともに、本番環境として利用が始まって4年になること、100社以上の利用実績があることなどを紹介した。eBay、Expedia、Walmart、Chaseなどの企業名が紹介され、インターネットベンチャーからエンタープライズ企業まで多様な組織での事例があることがわかる。

Linkerdの概略

またLinkerdの過去を振り返るこのスライドでは、Buoyantを創業したWilliam Morgan氏とOliver Gould氏が、ともにTwitterで働いていたことが背景にあることがわかる。2010から2015年のところにTwitterのロゴが配置されているのはそういう意味だ。Twitterは多くのオープンソースソフトウェアを公開しているが、その中でもFinagleというRPCフレームワークはTwitterの分散システムを構築する上でも大きな役割を果たしている。この後に紹介するLinkerdのロードバランシングのアルゴリズムであるEWMAは、Finagleにも利用されているアルゴリズムである。Twitterのエンジニアリングに関わっていた二人のエンジニアによって創業されたBuoyantが開発を始めたLinkerdにおいても、それが応用されているのは至極当然と言えるだろう。

Linkerdの歴史を振り返る

ここでは特にLinkerdの1.xから2.xへの移行に際して、大きなアーキテクチャー上の変更が行われたことが強調されている。1.xはJVMベースのソフトウェアであるのに対し、2.xではデータプレーンをRustで書かれたソフトウェアに置き換えて、より高速でセキュア、Kubernetesに特化したソフトウェアに進化したことが解説されている。

Rustはシステムプログラミングに適したメモリーセーフなプログラミング言語として注目を集めているが、Linkerdは業界が注目する前に一早くJavaからRustに移行したことになる。

Linkerdの特徴はとにかくシンプルなこと

このスライドではObservability、Connectivity、Securityの3つのポイントで解説が行われているが、何よりも「Operational Simplicity」という部分に、複雑な構成設定を行わなくても導入したらすぐに動き出すというLinkerdの特徴を表していると言える。

次のスライドではLinkerdのアーキテクチャーが紹介されている。これは2.xになってからのもので、点線より下のProxyという部分がRustで書かれたデータプレーンで、その上の部分はGoで書かれたコントロールプレーンになる。デフォルトでGrafanaとPrometheusが実装され、導入直後からモニタリングを行うことが可能だ。またすでにPrometheus、Grafanaを利用しているのであれば、それを利用することもできる。

Linkerd 2.xのアーキテクチャー

Linkerdのデザインについて解説したのがこのスライドだ。ここでは「do less, Not more」としてKubernetesに特化したこと、コントロールプレーンはGo、データプレーンがRustで開発されたことなどが解説されている。

Linkerdのデザインフィロソフィー

またセキュリティについてはデフォルトでmTLSがオンになっていること、ゼロトラストをベースに設計されていることなどが解説された。

Linkerdのセキュリティはゼロトラストがベース

LinkerdのデータプレーンはLinkerd2-proxyと呼ばれるRustで書かれたプログラムだ。このスライドで「Not Envoy！」と書かれているように、サービスメッシュにEnvoyを想定しているユーザーは多いが、それに対して明確に否定していることは興味深い。過去にBuoyantのCEOであるWilliam Morgan氏にインタビューした際も「Envoyは汎用的なProxyであり、それだけではサービスメッシュは実装できない」ことを強調していた記憶がある。またBuoyantのブログにも「どうしてLinkerdはEnvoyを使わないのか？」を解説した記事があるぐらいには誤解があることを示していると言えるだろう。

データプレーンはRust、Envoyは使われていない

Buoyantのブログ：Why Linkerd doesn't use Envoy

このブログにも書かれているように、EnvoyではなくLinkerd2-proxyを使うことには明確な理由がある。それはEnvoyを使うと、Linkerdが目指している軽量で高速なサービスメッシュが実装できないということに尽きる。

次のスライドでは、Linkerdが利用するロードバランサー機能の詳細が解説されている。

EWMAによるロードバランサー機能を解説

EWMAはExponentially Weighted Moving Average（指数平滑移動平均）の略で、金融の世界では株価予想のアルゴリズムとしても紹介されることもあるもので、直近の値を古いデータよりも重視して評価するものだ。Linkerdには2016年の開発当初から実装されている機能だ。

参考：Beyond Round Robin: Load Balancing for Latency

このブログでは、ラウンドロビンによるロードバランサーよりも良い結果が得られるとして紹介されている。

EWMAのほうがラウンドロビンよりも低レイテンシー

このグラフは2016年のブログ記事からの引用だが、EWMAを利用することでデータプレーンの稼働率が高くなってもレイテンシーが低いままに抑えられていることがわかる。前述のようにTwitterが開発したFinagleもEWMAを使ったロードバランサー機能を実装しており、この辺りはBuoyantの創業者たちのTwitterでの経験が活かされていると言えるだろう。

アプリ～Proxy間、Pod～Pod間の通信の概要

このスライドではPodの中の通信（アプリ対Proxy）とPod間通信の解説が行われている。手描きの図は、いかにもエンジニアによるスライドという感じだ。すべてのPod間の通信はmTLSによって行われていることがわかる。

トラフィックの分割も可能

このスライドではFlaggerを活用してトラフィックの分割を行うことが解説されている。カナリアデプロイメントやブルーグリーンデプロイメントが実装できるという。

マルチクラスターもセキュアに実装可能

またマルチクラスターの実装に関して解説したこのスライドでは、クラスター間においてもmTLSが有効になっていることがわかる。

Prometheusもアプリの変更なしで利用可能

モニタリングに関してはデフォルトでPrometheusが実装されるが、すでに実装されているPrometheusを利用することも可能であることが解説されている。

またトレーシングについてはOpenCensusを使うことで可能になるという。こちらについては、アプリケーション側の変更も必要となるようだ。OpenCensusの後継であるOpenTelemetryについては言及されていないが、今後の実装を期待したい。

OpenCensusでトレーシング

まとめとして2.9の新機能、変更点を解説したのが次のスライドだ。

Linkerd 2.9.0のまとめ

多くの変更がデータプレーン側、Linkerd2-proxyで行われていることがわかる。

動画では、ここからデモとしてCLIを使ったデモ、Linkerdのダッシュボードを使ったデモが行われている。

最後にLinkerdのコミュニティで議論されている項目が挙げられている。より詳しくはLinkerdのSlackやCNCFのメーリングリストで確認することをお勧めする。

コミュニティが議論している将来の機能追加

Linkerdのコミュニティでは本番環境での実装をユースケースとして求めており、Community Anchorと呼ばれるプログラムで語り部となってくれるエンジニアを募集している。

参考：Become a Linkerd Community Anchor

ちなみにこのページで使われているベースボールキャップは「本番環境でLinkerdを使っているエンジニアに贈呈されるSwag」であり、Anchorになってくれたエンジニアに対するご褒美と言ったところだろう。

以前の記事でも紹介したLinkerdのベースボールキャップ

サービスメッシュについては、Google、Cisco、IBM、Red Hatという大手が推すIstioがフル装備のサービスメッシュを目指している。これに対して「シンプル」「セキュア」「高速」でKubernetesに特化したサービスメッシュを実現しているLinkerdがどのように伍していくのか引き続き注目していきたい。

Linkerd2.9のリリースに関するブログ：Announcing Linkerd 2.9: mTLS for all, ARM support