Linkerdを開発するBuoyantがサービスメッシュの始まりと未来を語る
サービスメッシュは、仮想化、コンテナ化の次のマイクロサービスのパターンとして注目されている。2019年後半時点ではGoogleやIBM、Red HatなどがプッシュするIstioがサービスメッシュの実装として評判になっているが、それ以外にもHashi Corpが手がけるConsul Connect、APIゲートウェイを手がけるKongがリリースしたKuma、Containous(ProxyであるTraefikを手がける)が開発するMaeshなど、さまざまなベンダー、オープンソースプロジェクトが名乗りを挙げているレッドオーシャンとも言える領域である。
その中でCNCFにもホストされているサービスメッシュのソフトウェアであるLinkerdの開発をリードするBuoyantのCEOであるWilliam Morgan氏とCTOのOliver Gould氏にインタビューを行った。昨年も同じ時期にこのお二人に対してインタビューを実施したが、今回はインタビューに加えて10月23日に行われたCommunity Meetingの様子を収めた動画も紹介したい。ここにはLinkerdの最新情報や、最近IstioからLinkerdに乗り換えたというRancherのエンジニアによるデモなども収められており、プロジェクトの進行を俯瞰する良い機会であるためだ。
2018年のインタビューに関しては以下の記事を参考にされたい。
サービスメッシュを実現するLinkerdの将来を開発元のBuoyantが語る
今回は昨年から1年経ったということで、サービスメッシュに関するアップデートをお聞きしたいと思っています。
Morgan:もう前回のインタビューから1年ですね。しかし当時は「サービスメッシュ」という言葉がバズワードになるとは思ってもいませんでした。ちょうど3年前、2016年の10月の初めに「Kubernetesのためのサービスメッシュ、Linkerd……」というツイートをしたことを覚えています。
最初のLinkerdを出したのが2016年の3月だったかな。あれからLinkerdは定期的にバージョンアップを行っています。今はバージョン2をリリースして、最新は2.6というバージョンになっています。数週間ごとにマイナーリリースを行って、ソフトウェアを更新していることになりますね。
注:2019年10月8日に、Morgan氏はそのことを思い出した旨のツイートをしている。
Three years ago last Friday was, I believe, the first occurrence on Twitter of the term "service mesh" with its modern meaning. ⏰ ✈️ https://t.co/tlweJTrtQC
— William Morgan (@wm) October 7, 2019
多くのユーザーがLinkerdのシンプルさを讃えていますが、それに関しては?
Morgan:Linkerdは簡単にインストールできることをデザインのポイントとして開発されています。とにかくシンプルでちゃんと動くこと、これが重要です。
Gould:サービスメッシュは複雑である必要はないと思います。もちろん、単純なネットワークに比べれば新しいことを覚える必要はありますが。「サービスメッシュは複雑だ」というのは、多分にIstioのせいかもしれませんね(笑)。
去年のインタビューでは「アプリケーションルーター」と呼んでいたLinkerdが、サービスメッシュと呼び始めたら急に話題になるようになったと言っていたことを思い出します。
Morgan:そうです。その時からこのお祭り騒ぎが始まったのかもしれません。
今や、IstioだけではなくKongのKumaやHashiCorpのConsul Connectなどがサービスメッシュとして打ち出しています。
Gould:そうなんです。Consulはもともと分散キーバリューストアで、どちらかといえばetcdと同じ領域のソフトウェアだったはずですが、今やサービスメッシュとしてマーケティングしているということになりますね。
Morgan:他にもTraefikのMaeshなどもありますね、とにかく今は多くのベンダーが競い合っている状態です。
そんな中、バルセロナのKubeConではMicrosoftが主導するSMI(Service Mesh Interface)の発表がありました。BuoyantはSMIをどう評価していますか?
Morgan:SMIは非常に良い動きだと思います。それはユーザーにとってもLinkerdにとっても他のベンダーにとっても良いことであると思います。我々のエンジニアの中では、Thomas(Thomas Rampelberg氏)がSMIのために集中的にコードを書いてます。さまざまなソフトウェアが出てくるという状況の中で、Microsoftが主導してSMIを作ったことは大きな意味があります。それぞれのベンダーが個々にInteroperabilityを作り上げるのは無駄ですから。
一つの例としてFlaggerというプロジェクトがあります。これはKubernetesの上でカナリアデプロイメントを行うためのOperatorですが、Flaggerによってこれまで容易にはできなかったトラフィックの制御が行えるようになりました。その中のサービスメッシュの部分は、LinkerdでもSolo.ioのGlooでも良いのです。これがSMIの実装のサンプルになるでしょうね。
Gould:SMIには他の一面もあると思います。例えばKubernetesのライフサイクルマネージメントを個別にやるのではなく、その部分はSMIに任せて役割を分けるということにも使えると思います。特にMicrosoftにとって、SMIはWindowsワークロードを実行するという部分で重要になってきますので、Microsoftにとっては大きな意味があると思います。
IstioがSMIに入っていないこと、そして最近、GoogleがIstioとKnativeをCNCFなどの組織に寄贈しないことを明らかにしました。それについてコメントは?
Morgan:その理由については個人的な意見ですが、GoogleはKubernetesの失敗を繰り返したくなかったからではないかと思います。Kubernetes自体はとても大きな成功をしているプロジェクトですが、Googleにとっては思った以上の成果を挙げていません。つまりGCPのサービスとしてKubernetesをうまく使えていないということがあるのでしょう。もっとGCPにとって良い方向にコントロールをしたくても、CNCFの配下ではそれができない。IstioやKnativeでは、同じことを繰り返したくないということではないかなと。
一方Linkerdは、それとはまったく異なる運用体制を取っています。大部分のコードはBuoyantのエンジニアが書いています。Linkerdのコードを書いてくれるコミュニティのメンバーに、Buoyantのエンジニアになって無償ではなく給料をもらってコードを書かないか? と誘うことはありますが、Buoyantにとって欲しいのはLinkerdのコントロールではなくアダプション、つまりもっとLinkerdを使うユーザーが増えて欲しいのです。その意味では、IstioとLinkerdはまったく逆の存在かもしれません。
変な質問かもしれませんが、この後、Kubernetesはどうなっていくと思いますか?
Gould:何か変化が起こるとすれば、VMwareの新しいプロジェクト(Project Pacific)、あれはvSphereの上でKubernetesのPodを実行するというもので、個人的にはまったく興味はありませんが、VMwareユーザーにとっては大きな意味があるものでしょうね。それによって、Kubernetes自体がさらに広がっていくということにつながると思います。その分、もっと複雑になっていくのでしょうが。
Morgan:Kubernetes自体は、もっと退屈な存在になっていくのではないかと思います。サービスメッシュもできてしまえばそれ自体は退屈なものとして使われていくでしょう。それぐらいに当たり前のものという意味ですが。実際には、Flaggerのようなプロジェクトがビジネスに直結することを達成する役割を果たしていくのではないかと思います。ですので、Kubernetesやサービスメッシュは退屈なレイヤーで良いと思います。
LinkerdにとってはKubernetesは特別な存在です。バージョン1はまだコンテナオーケストレーションのプラットフォームとしてKubernetesはFirst Citizenではありませんでした。しかし我々は、バージョン2でKubernetesを最優先のプラットフォームにしようと決定しました。その結果としてKubernetesに最低限のレイヤーしか載せないやり方で実装を行いました。結果的にその賭けは成功したように思います。シンプルですぐに使えて、メモリーも少なく速いサービスメッシュを実現できました。
Linkerdの将来の目標は?
Morgan:ポリシーを実装することですね。セキュリティは今や誰にとっても重要な要素ですし、特にヨーロッパのユーザーにとっては重要です。いわゆる「技術者にとってのセキュリティ」という意味ではなく、ビジネスに直結するセキュリティをいかに実装するのか? そのためにはポリシーという発想で、ビジネスの側面からサービスメッシュを見ていく必要があります。
Gould:サービスメッシュもKubernetesも、今はまだiPhoneのように簡単に使えてセキュリティを意識する必要がないというレベルには到達していないわけで、そこを目指していくということが必要だと思います。
短い時間であったがサービスメッシュ、SMI、Googleの戦略などについて語ってくれたMorgan氏とGould氏であった。
このインタビューの後に実施されたオンラインコミュニティミーテイングでは、Linkerdの最新情報だけではなく、RancherによるLinkerdを使ったデモが行われた。これはRancherが開発するRioというプラットフォームに関するものだ。Rioは、KubernetesをPaaSのように使うための新しいオープンソースソフトウェアで、その中で使われるサービスメッシュをIstioからLinkerdに替えたということを紹介するものだ。デモ自体の内容は、Kubernetes上で実行されるNGINXのサーバーのDockerファイルを書き換えて、徐々にPodが置き換わっていくというローリングアップデートを見せるものだった。
デモの部分は以下のリンクから参照されたい。
Linkerd Community Meeting、Rancher Rioのデモ:
Linkerd Community Meeting 10-23-19
他にも2.6のアップデート、2.7のプレビュー、KubeConの話などが盛りだくさんで、Google Docで議事録を書きながらのミーテイングは英会話が苦手なエンジニアにも参考になる内容だ。
ちなみにこの議事録の中で言及されている「Hat」というのは、Linkerdを本番で使っているユーザーが手に入れることのできる野球帽である。
議事録へのリンク:Linkerd Online Community Meeting Minutes
サービスメッシュがレッドオーシャン化して、ユーザーにとっては選択肢が多過ぎて難しくなっている昨今、CNCFの他のプロジェクトとも親和性を高めていくLinkerdに今一度、注目して欲しい。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- KubeCon Europeでサービスメッシュの標準化を目指すSMIを発表。Istioの動向にも注目
- サービスメッシュのLinkerdの最新リリースと将来計画をBuoyantのCEOが解説
- サービスメッシュのLinkerd 2.9を紹介。EWMA実装のロードバランサー機能とは
- KubeCon NA 2021からサービスメッシュの2セッションを紹介
- サービスメッシュを実現するLinkerdの将来を、開発元のBuoyantが語る
- KubeCon Europeに参加した日本人エンジニアとの座談会で見えてきたKubernetesの次の方向性とは
- KubeCon+CloudNativeCon EU 2021、コロナ禍に対抗するシステムを支えるLinkerd
- KubeCon NA 2020、サービスメッシュのLinkerdの概要とユースケースを紹介
- KubeCon Europe開幕、初日のキーノートではLinkerd、OpenTelemetryに注目
- サービスメッシュのLinkerd、Pod間通信にオーソライゼーションポリシーを実装