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

2021年3月22日(月)
松下 康之 - Yasuyuki Matsushita
KubeCon+CloudNativeCon NA 2020にて行われた、開発元のBuoyantによるLinkerdのセッションを紹介する。

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

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

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の概略

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

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

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

参考:Why Linkerd doesn't use Envoy

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

Linkerd2のアーキテクチャー

Linkerd2のアーキテクチャー

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

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

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

Linkerd2-proxyの概要

Linkerd2-proxyの概要

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

Istioとの比較

Istioとの比較

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

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

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

IstioとLinkerdの比較

IstioとLinkerdの比較

最新版Linkerd 2.8.1

この後はプレゼンをPothulapati氏に交代して、最新のバージョンLinkerd 2.8.1の解説に移った。

Linkerd 2.8.1の紹介

Linkerd 2.8.1の紹介

ここでのポイントは、マルチクラスターへの対応だろう。リスクを分散するために複数のデータセンターやパブリッククラウドを使い分けたいというニーズに対応するために、複数のクラスターにまたがってサービスメッシュを構成したい場合には有効な機能だ。

将来計画を紹介

将来計画を紹介

ここではLinkerdの将来のバージョンである2.9において、TCPにおけるmTLS、ARM64プロセッサのサポート、Kubernetes 1.17で登場したサービストポロジーへの対応などが紹介された。

さらに2.10の計画も紹介し、マルチクラスターでのTCPサポートなどを紹介した。ここで「Server-Speaks-Firstプロトコル」とあるのは、Linkerd2におけるプロトコルを検出し識別する機能に関連する内容だ。すでに公式ドキュメントにも記述があるので、参考にして欲しい。

プロトコルの検出に関するドキュメント:TCP Proxying and Protocol Detection

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

次にテキサスのスーパーマーケット、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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Linkerdは「疑いたくなるくらい簡単」だったという

Linkerdは「疑いたくなるくらい簡単」だったという

そしてBuoyantのサポートが良かったこと、Slackでのコミュニティの支援が素晴らしかったことなどを紹介した。

Buoyantとコミュニティを賞賛

Buoyantとコミュニティを賞賛

カオスエンジニアリングによるゲームディ(意図的にシステムを壊すテストの実施日をGremlinではゲームディと称している)も行われ、Linkerdに対するテストも実施されたことが解説された。

Linkerdに対してもカオスエンジニアリングを実施

Linkerdに対してもカオスエンジニアリングを実施

H-E-Bはパンデミックに対応するために、従前のモノリシックなシステムにクラウドネイティブなサービスメッシュとカオスエンジニアリングを導入した形になった。この事例は、導入が簡単ですぐに稼働できるというLinkerdの良さが実感させる内容となった。

最後に、筆者が2019年にサンフランシスコのBuoyant本社に訪問した際のインタビューも参考にされたい。

2019年のインタビュー:Linkerdを開発するBuoyantがサービスメッシュの始まりと未来を語る

著者
松下 康之 - Yasuyuki Matsushita
フリーランスライター&マーケティングスペシャリスト。DEC、マイクロソフト、アドビ、レノボなどでのマーケティング、ビジネス誌の編集委員などを経てICT関連のトピックを追うライターに。オープンソースとセキュリティが最近の興味の中心。

連載バックナンバー

運用監視イベント
第7回

ベンダーニュートラルな可視化ツールOpenTelemetryの最新情報を紹介

2021/3/29
可視化のためのプロジェクトOpenTelemetryの最新情報を、KubeConのセッションなどから解説する。
OSSイベント
第6回

KubeCon NA 2020で語られたオープンソースに貢献する意味・メリットとは?

2021/3/25
KubeCon NA 2020において、オープンスースに貢献する意味を元Facebookのコンサルタントが解説したセッションを紹介する。
クラウドイベント
第5回

KubeCon NA 2020 LinkerdとAmbassadorを使ったマルチクラスター通信を紹介

2021/3/23
LinkerdとAmbassadorを使ったマルチクラスターの実装例を、BuoyantとAmbassador Labsのエンジニアが紹介した。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています