KubeCon NA 2020、サービスメッシュのLinkerdの概要とユースケースを紹介

連載 [第4回] :

KubeCon＋CloudNativeCon North America 2020レポート

2021年3月22日(月)

KubeCon＋CloudNativeCon NA 2020にて行われた、開発元のBuoyantによるLinkerdのセッションを紹介する。

今回は、KubeCon＋CloudNativeCon NA 2020からLinkerdの概要とユースケースのセッションを紹介する。概要についてはLinkerdの開発をリードするBuoyantのCEOであるWilliam Morgan氏とエンジニアのTarun Pothulapati氏が解説したセッションから、ユースケースについてはテキサスのスーパーマーケットH-E-Bのマイクロサービスを紹介するセッションからの引用となる。

Linkerdの概要と最新情報に関するセッション

Linkerdの概要：Overview and State of Linkerd - William Morgan & Tarun Pothulapati

H-E-Bの事例：How H-E-B Curbside Adopted Linkerd During a Pandemic - Justin Turner & Garrett Griffin, H-E-B

Linkerdの概略

Linkerdについて

Morgan氏はLinkerdの概要として、すでに本番環境での実装が4年前から行われていることなどを紹介したが、ポイントは「超軽量、超高速、セキュリティを最優先にしたKubernetesに特化したサービスメッシュ」であるという部分だろう。

オブザーバビリティ、信頼性、セキュリティが特徴

そして次のスライドでは「No Developer Involvement」として、開発者がLinkerdを直接触らなくてもサービスメッシュが実装できるという特徴を紹介した。これはKubernetesが開発者にとって非常に難しいソフトウェアであるという認識の裏返しとも言えるものだろう。MicrosoftなどがAppDev、AppOps、InfraOpsと開発と運用の間に新しいアプリケーションオペレーターという役割を導入していることと合わせて考えると、開発者にとってクラウドネイティブがいかに難しい発想なのかを表していると言える。

開発者の手を煩わせないのが特徴

Linkerdのデザインについて解説した次のスライドでは、YAMLファイルなどで設定をしなくても良いこと、資源を使わずに高速であること、などを紹介した。ここではコントロールプレーンがGoで、データプレーンがRustで書かれていることも紹介された。

高速で、利用するメモリーなども少ないことを強調

これについては、より詳細に解説されているBuoyantのブログを参照されたい。これは「LinkerdがEnvoyを使わない理由」ことを解説している。「IBMやRed Hatなどが強力にプッシュするサービスメッシュであるIstioで利用されているProxyのEnvoyを、なぜLinkerdが採用していないのか？」を解説する中で、データプレーンとして同じ働きをするLinkerd2-proxyがEnvoyに比べて、非常に小さく高速であることを示している。

Linkerd2-proxyはEnvoyに比べてメモリー使用量が1/10

Buoyantのブログは以下から参照されたい。

参考：Why Linkerd doesn't use Envoy

Linkerdのアーキテクチャーについて解説したのが次のスライドだ。ここではコントロールプレーンとデータプレーンに分離されていること、そしてサイドカーとしてKubernetesのPodにインジェクトされるモジュールがLinkerd2-proxyであることが解説されている。

Linkerd2のアーキテクチャー

ここでLinkerd2と明記されているのは、Linkerdの最初のバージョンはJavaベースで開発されており、それをKubernetesに特化する形でデータプレーンをRustで書き直して置き換えたのがLinkerd2だからだ。当初はLinkerdとConduitという別プロジェクトだったものをマージして、シンプルにブランディングし直したのが今のLinkerdである。この辺りの経緯は2018年のインタビュー記事を参考にして欲しい。

参考：サービスメッシュを実現するLinkerdの将来を、開発元のBuoyantが語る

Linkerd2-proxyについて解説したのが次のスライドである。ここでもEnvoyではないということが繰り返されており、Morgan氏がEnvoyとの比較を何度も訊かれているであろうことが想像できる。

Linkerd2-proxyの概要

Istioとの性能比較について解説したMorgan氏は「何もサービスメッシュを使わない場合よりは遅いが、Istioと比べたら圧倒的に小さくて高速」であることを強調した。

Istioとの比較

ここで紹介されたIstioとのベンチマークテストについては、以下のリンクを参照されたい。

Kinvolkによるベンチマークレポート：Performance Benchmark Analysis of Istio and Linkerd

性能以外の比較についても解説し、「IBMが勧めるソフトウェアを使ってクビになった人いない」とソフトウェアそのものの比較ではなく、IBMやRed HatというメジャーなITベンダーが推奨していることがIstioの強みであることを、ジョークを交えて紹介した。

IstioとLinkerdの比較

コロナ禍に対応するためにLinkerdを採用したH-E-Bの事例

次にテキサスのスーパーマーケット、H-E-Bのユースケースについて紹介したい。

H-E-Bのユースケース

H-E-Bは1905年に創業されたプライベート企業で、テキサスとメキシコに340箇所の店舗を持つ。同社がCOVID-19のパンデミックに際して、モバイル向けの新システムを、計画していたモノリシックなものからサービスメッシュを使ったものに移行させた際の経験を解説したのがこのセッションとなる。

H-E-Bの事例：How H-E-B Curbside Adopted Linkerd During a Pandemic - Justin Turner & Garrett Griffin, H-E-B

これはパンデミックの際に顧客が店舗で食品などを購入するのではなく、品物をモバイルからオーダーして店舗で受け取る、または配達してもらうという新サービス、Curbsideの開発にまつわる内容だ。

モバイルで品物を買い、店舗で受け取るサービスCurbside

混雑する店舗の中に入らなくても買い物ができて自分の車に積んでもらえるというのは、コロナ禍における小売店の対応としては良くできていると言える。

モノリスからサービスメッシュに移行

元はFASTというサービスを開発していたが、パンデミックに伴いそれをサービスメッシュに移行したというのが実情だ。興味深いのは、サービスメッシュと同時にカオスエンジニアリングを採用して、意図的にシステムを壊しても元の状態に復元させる柔軟性を採用したことだろう。

コロナ禍に伴い計画を更新

ここでLinkerdによるサービスメッシュと、Gremlinによるカオスエンジニアリングが採用されたことが紹介されている。

複数のチームが協力してサービスメッシュとカオスエンジニアリングを採用

サービスメッシュの採用については、複数のソフトウェアを評価した上でLinkerdを選択したことが解説された。

サービスメッシュとしてLinkerdを採用

PoC（Proof of Concept）では「非常にドキュメントが良くできていること」「導入が容易であったこと、疑いたくなるぐらいに簡単であった」ことなどが紹介された。「疑いたくなるぐらい（Suspiciously）」という形容詞はIT業界ではなかなか見ないものだが、それぐらいLinkerdの導入が簡単だったことを表している。