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

サービスメッシュを実現するためのProxyであるLinkerdを開発するBuoyantのサンフランシスコのヘッドクォーターを訪問。Co-FounderでCEOであるWilliam Morgan氏にインタビューを行った。

CEOのWilliam Morgan氏（左）とOliver Gould氏（右）

自己紹介をお願いします。

私はBuoyantのCEOで、Oliverと一緒にBuoyantを立ち上げました。Buoyantの前は二人ともTwitterでエンジニアをやっていました。私は主にバックエンド、Oliverはインフラストラクチャー側を担当していました。私が書いた写真を扱うライブラリーは、今でもTwitterで動いていると思いますよ。

LinkerdやConduitを開発した理由を教えてください。

そもそもTwitterでの経験が元になっているのです。私がいた当時のTwitterは、まだモノリシックなRuby on Railsのアプリケーションでした。それも、巨大なね。それをDistributedなシステムに置き換えなければいけないということで、MesosやDockerを使ってScalaで開発したものが今のTwitterのベースになっているというわけです。それはモノリシックなシステムから分散型のシステムへ切り替えるという大きな賭けだったのです。それをなんとか終わらせて考えたのは、この厳しいチャレンジを全ての企業が超えないといけないというのは間違っているということだったのです。つまりもっと簡単に分散協調するシステムを開発することが出来ないとおかしい、そのためには何が必要か？　それを考えた上で出てきたものがLinkerdだったということです。

ただ当時のLinkerdは、まだScalaで書いたサーバーとクライアントを繋げるためのコミュニケーションレイヤーでしかなかったのです。機能は果たしていましたが、やはりScalaのハードルは高いということから、Linkerd 2.0ではGoで書き直したわけです。Scalaでシステムを記述するというのは、エンジニアにとって非常にハードルが高いものだと思います。そして当然、JVMなども必要になりますから、性能面でも利点が少ないのです。

そして軽量のProxyであるConduitが2.0でマージされたわけですね。

Conduitについてはちょっと説明が必要ですね。Conduitはもっとメモリーのフットプリントが小さなProxyをKubernetesのために作ろうというところから始まっています。実際にはそのために2名のRustコミッターにBuoyantに入ってもらうことになりました。とても優秀なエンジニアで、ネットワークにも詳しい人たちです。彼ら2人が書いたのがConduitです。Proxyの部分はRustで、コントローラーの部分はGoで書かれています。

Conduitは良く出来ていましたし、ユーザーも満足していました。しかしその役割と向かう先を考えれば考えるほど、Linkerdとは別の製品として扱うのは不自然だと思うようになったのです。LinkerdもConduitも、サービスメッシュを実現するためのプラットフォームなのですから。そこでまず、Linkerd 2.0のリリースの際に「ConduitをLinkerdにマージする」と宣言しました。コードのマージは、まだこれからです。

LinkerdとConduitのブランディングをまず整理したということですね。

そうです。そして、それにはもうひとつ理由があります。実際にLinkerdを説明する際のエピソードを紹介しましょう。当時はLinkerdを説明する時に「Application Router」などの単語を使って説明したのですが、なかなかLinkerdのことが伝わらない。どんな呼び方をしても、すでにあるツールと比較されてしまって、Linkerdが実現する機能を分かってもらえなかったのです。

そこで「サービスメッシュ」という単語を使ってみたら、「なるほど。で、そのサービスメッシュを使えば何が出来るの？」というようにリアクションが変わってきたのです。サービスメッシュは、人によっては定義が違うものですが、「とにかく新しくて分散協調型のアプリケーションを実現するものらしい」というポイントだけは伝わったのです。そしてまだKubernetesが爆発的に拡がる前に開発を進めていたLinkerdについては、Twitterでの経験がそのまま活かされていたものだったので、ScalaとFinagleをベースにして開発しました。

その後に先ほど説明した通り、軽量のKubernetes用のサイドカーProxyであるConduitを書いたわけです。なので、「サービスメッシュ」という言葉が2つのプロダクトを上手に説明出来るということになれば、別の製品である必要はない、ということです。

Linkerdと良く似ているものとしてEnvoyがありますが。

実際にはEnvoyではなく、IstioやKongなどと比較されることが多いような気がしますね。どれも完全に同じ機能を果たすわけではなく、少しずつカバーするエリアが違うのですが、とにかく比較したがる人は多いので（笑）。

今少し感じている問題は、「自分が何をやりたいのか？」をちゃんと理解せずに、このツールとあのツールを比較して良さそうな方を使う、というアプローチの人が多いことですね。つまり自分が望むアプリケーションをどういう風に作るのか？　運用するのか？　これが分かっていないのに、とにかくサービスメッシュが良さそうだからツールを選ぶという手法は、あまり良くないと思います。

Istioについては、我々とはアプローチが違うということは言えると思います。どうしてGoogleがIstioにリソースを注ぎ込んでいるのかといえば、最終的にGCPでIstioを動かすことがデフォルトになって欲しいと考えているのではないかなと思います。つまり面倒なことは全部GCPが面倒をみるから、デベロッパーはアプリケーションだけに集中していいですよ、そのために機能はどんどん追加していく、という発想ですね。

Linkerdはそうではなくて、とにかくデベロッパーがサービスメッシュを実装するためにシンプルにすること、何度もコマンドを叩かなくてもデプロイ出来ること、機能を絞ってデバッグをやりやすくしたり、トレーシングをシンプルにしたりすることなどを目指しています。そこが大きな差異でしょうね。Linkerdはあくまでも、アプリケーションデベロッパーが簡単に使い始められるように考えています。

ではこれからのLinkerdの将来の姿について何か教えてもらえますか？

これはまだ外部には公開しておらず、社内で議論していることなんですが、「ポリシー」という機能を入れようと思っています。これは例えばアプリケーションが実行される時に、このPodは何回までリトライ可能、接続されるPodはこれ、といった設定情報をもっとアプリケーションデベロッパーやビジネスのオーナーなどにとっても読みやすく理解しやすいものにしたいという発想です。

それは先日、GitHubがGitHub Actionsを発表した時にも聞いたようなコメントですね。つまりYAMLやJSONのようなフォーマットではマシンにとっては良くても人間にとっては良くない、だからHCL（HashiCorp Configuration Language）を選んだのだと言っていました。

GitHub Actionsはすごく評判が良いみたいですね。話題になってますよ。ポリシーについてですが、サービスメッシュはその名前から分かる通りに、多くのプロセスが繋がることで仕事をします。そのために、「全てのプロセスが完璧に動く」ということを前提していては危ないのです。例えばアプリケーションを使っているユーザーが不具合を感じていても、Kubernetesのステータス上はうまく動いているということもあり得ます。Kubernetesは、現在の状態とあるべき状態を比べて、あるべき状態にするためにPodを増やしたりするわけですが、それをもっと詳細に監視する必要があります。そのためには、サービスメッシュを支えるProxyは、よりデバッグがしやすいものであるべきだと思いますね。将来的には、それらを実現したいと考えています。

最後に会社の概要とユーザーについて教えてください。

Buoyantには今、15名くらいの社員がいますね。ほとんどはエンジニアです。ほとんどの社員がこのサンフランシスコのオフィスにいて、Rustのエンジニアがリモートにいます。ユーザーについてはオープンソースソフトウェアなので仕方がないことですが、どこの誰が使っているのかは、あまり正確には分かっていません。Slackに突然質問が来て、使っているのを知るというような感じですね。なぜかヨーロッパに多くのユーザーがいるのは把握しています。特にイギリスに多いのです。Monzo Bankというインターネットバンクが、Linkerdを本番環境で多く使っているというのは知っていますが。

Monzo Bankはコペンハーゲンで行われたKubeConで失敗のユースケースとして発表されていました。確かにLinkerdとKubernetesを使ったシステムダウンの経験を共有するためのものでした。

参考：KubeConで失敗を紹介したMonzo Bankのキーノート

知っています。私もあのセッションは気に入っています。それはLinkerdの名前が出ているということ以上に、失敗を共有するという部分が特に良いと思いました。

ところで最初に会った時に、私がBuoyantの社内では有名人だと教えてくれましたが……

あぁ、そうです。あなたはBuoyantでは「BABYMETAL」と呼ばれているんですよ。Twitterで何度もLinkerdやConduitについてツイートしてくれていて、どんな人なんだろう？　と思ってProfileを見たんですが、私達には日本語が分かりません。唯一分かるのがBABYMETALという単語だったので（笑）。あなたがLinkerdに関するツイートをすると「またBABYMETALがツイートしてるよ」と話題にしていました。同時に、BABYMETALのことも知ることが出来てよかったと思います。そして、今日やっと本当の名前が分かりました（笑）。

Buoyantのノベルティ。ボトルはコントリビューターにだけプレゼントするというレアグッズ

短い時間ながら、Buoyantの生い立ち、LinkerdとConduitの違いと将来などについてフランクに教えてくれたMorgan氏だった。最後に合流したOliver Gould氏も、いかにもエンジニアという風貌で、GitHub Actionsについて率直なコメントをくれたのが印象的であった。これからもLinkerd、そしてBuoyantに注目していきたい。