クラウドネイティブサービスを提供するBuoyantは、Linkerd(“linker-DEE”と読む)の１周年を発表した。Linkerdは、クラウドネイティブなマイクロサービスベースのアプリケーションを対象とした、オープンソースな“サービスメッシュ”だ。その発表によると、
1990年代におけるネットワーク通信のTCP/IPへの移行は、メインフレームからクライアント/サーバアーキテクチャへという業界全体のシフトを実現しました。同じように、次世代クラウドアプリケーションの基本的ネットワーク層としてLinkerdの採用が増え続けることによって、企業におけるモノリシックアプリケーションからマイクロサービスへというコンピューティングアーキテクチャの移行が、信頼性を損なうことなく実現するのです。
Linkerdは自動化されたロードバランシングとサービスディスカバリ、稼働回復能力を備えた、信頼性の高いマイクロサービスを提供する。
2016年2月にバージョン0.1.0がリリースされたLinkerdは、ともに元Twitterのエンジニアで、現在はBuoyantのCEOであるWilliam Morgan氏と、CTOのOliver Gould氏によって開発された。Linkerdは、“プロトコルに依存せず、Java、ScalaなどJVMでホストされる言語による堅牢なクライアントとサーバの構築を容易にするJVM用非同期RPCシステム”であるFinagle上に構築され、Twitterで運用中のサービスに展開されている。
下の図は、アプリケーションインスタンスのサービスメッシュを形成する上で、Linkerdがどのように展開されるのかを示したものだ。
Buoyantは先頃、Linkerdのバージョン0.9.0をリリースした。この最新リリースの特長は、
- 改良された管理ダッシュボード
- Prometheusメトリックのサポートの改善
- シンプルになったルーティング名
創業者でCEOのWilliam Morgan氏が、InfoQのために今回のマイルストンを説明してくれた。
InfoQ: おふたりのBuoyantでの現在の責務について教えてください。毎日どのような仕事をしているのですか？
William Morgan: 私はCEOです。ただし、Buoyantのようなエンジニアリング中心の企業では、エンジニアたちに追いついていくことが仕事の大半です。彼らの仕事が優れた製品を開発することであるのに対して、それらを支える素晴らしい企業を作り上げて、彼らが創造する価値を外部の世界から認知されるものにすることが私の仕事です。
InfoQ: あなた方の会社であるBuoyantについて、読者に詳しく説明して頂けますか？
Morgan: 私たちが開発したのは、クラウドネイティブな環境のための、オープンソースの運用信頼性ソフトウェアです。あらゆる場所の企業がこのソフトウェアを使ってミッションクリティカルなソフトウェアを安全かつレジリエントに構築できるようにしたい、と考えています。当社はエンジニアリングを非常に重視する企業です。TwitterやGoogle、Microsoft、Yahooといった企業での経験を持ち寄って、エンジニア – 特にSREやDevOpsの関係者たちが、自分たちのアプリケーションを高い信頼性と安全性を持って運用する上で必要なものを構築しています。私たちは皆、これまでは、つまらない理由のために夜中の3時に起こされなくてはなりませんでした。それを少なくすることが私たちの目標です。それはすなわち、私たちの仲間であるオンコールエンジニアへの感謝の気持ちでもあります。
InfoQ: Linkerdとは何でしょう？ マイクロサービスやクラウドネイティブなアプリケーションの通信層において、新たに“サービスメッシュ”が必要なのはなぜですか？
Morgan: Linkerdの“サービスメッシュ”とは、時間的制約のあるサービス間通信に特化したインフラストラクチャ層のことです。従来のネットワークとは対照的に、サービスメッシュは要求のレベルで動作します。パケットやバイトではなく、要求とその結果としての応答を対象とするのです。FooサービスがBarサービスに通信して応答を待ち、それが返ったならば、Fooがその結果を処理した上で、自身の結果を呼び出し側に返します。もしBarが一定時間内に応答しなければ、Fooはその対処をしなくてはなりません。
このような要求-応答パターンがネットワークプログラミングの初期から存在するのはもちろんですが、マイクロサービスを使用したクラウドネイティブなアプリケーションが違うのは、アプリケーションが呼び出しを実行する度に、アプリケーション内でこのような通信が数十回、あるいは数百回発生するという点です。ですから、もし数百のサービスが存在して、それぞれのサービスが数百のインスタンスを生成するのならば、毎秒数百回もの要求が発生して、アプリケーション内に極めて複雑な要求フローが存在することになります。しかもインスタンスは常に停止したり、オーバーロードしたり、あるいは再スケジュールされたりしていますから ... 非常に複雑なのです。
サービスメッシュの目的は、このようなモデルの運用上の複雑性を切り離すことです。それをアプリケーション外に移動することによって、アプリケーションの純粋性が維持できます。アプリのコードでは単に、“私はFooサービスで、このリクエストをBarに送りたいのだ”、と言えばよいのです。リトライやタイムアウト、デッドライン、ロードバランシング、サービスディスカバリといった、正しく実施することがが困難であると同時に非常に重要な – それらなしではアプリケーションが成り立たないような – 運用上の機能は、アプリケーションとは別に処理されます。それらは別の層に位置して、アプリケーションの動作とは無関係に管理することができます。
Linkerdの現在の形式はユーザ空間プロキシです。利用する上で、これが一番簡単だからです。要するに、巨大なHAProxyのようなものですが、サービスメッシュの概念としては、根本的にプロキシモデルをはるかに越えています。
InfoQ: Twitterでのあなた方のFinagle(Twitterの“Fail Whale(訳注:Twitterのダウン時にかつて表示されていた鯨のイラスト)”を退治した重要機能のひとつだと言われている)の経験と、そのFinagle上にLinkerdがどのように構築されているのか、読者に詳しく説明して頂けますか？
Morgan: FinagleはTwitterがFail Whaleに打ち勝つ上で、非常に大きな部分を占めていました(“退治する(kill)”ではなく“打ち勝つ(defeat)”と言ったのは、鯨があちらこちらを破壊しているというよりも、周りに迷惑を掛けながら寂しく泳いでいる様子を想像するからです)。
Twitterはモノリスを、さまざまなサービスに分解する決定を下しました。“マイクロサービス”ということばは当時ありませんでしたが、私たちが実行したのはまさにそれです。当初のFinagleは非常に単純なものでした。サービスが別のサービスを呼び出すために使用するライブラリになる予定だったのです。やがてTwitterのほぼすべてのサービスが、要求の受信にFinagleサーバを使用する別のサービスに対して、Finagleクライアントを使って通信を行うようになりました。すべての要求の両端にFinagleが存在することになったのです。
当時のTwitterが稼働時間と信頼性の面で抱えていた問題の多くは、サービスの相互通信の方法に関わるものであることが分かっていました。従ってFinagleは、これらすべての問題を解決する場所でした。やがてFinagleにはロードバランシングやサービスディスカバリ、リレーロジック、サーキットブレーク、ルーティング、名前の抽象化など ... あらゆる機能が追加されていきました。Finagleの観点から見れば、TwitterとはFinagleの管理するコネクションの束の間に、ちょっとしたアプリケーションコードが挟まっているようなものだったのです。
それを通じて、非常に多くの運用上のノウハウが Finagleにコード化されました。Twitterが何らかの新たな理由でダウンすると、その根本原因に対する対応がFinagle内にコード化される、というサイクルが繰り返されました。時間が経つにつれてFinagleは非常に成熟し、あらゆる種類の境界条件に対処できるようになりました。分散システムとはそもそもそういうもので、1%の正常動作と99%の異常な境界条件で成り立っているのです。
InfoQ: Linkerdの開発初期に、Finagleのパワーを多くの人たちに提供することを目標として掲げていましたが、Finagleが提供するサービス通信を簡略化して一般的な企業が採用できるものにするために、LinkerdはFinagleをどのように拡張しているのでしょうか？
Morgan: 最も大きな違いは、LinkerdがFinagleをスタンドアロンのプロキシでラップすることによって、その実装の詳細を理解しなくても実行できるようにしている点です。サービスが記述されている言語や、使用しているサービスフレームワークが何であっても構いません。FinagleはライブラリなのでJVM上でしか利用できませんが、Linkerdはどこでも使用可能です。
もうひとつの違いは、Linkerdが運用モデルのみを提供していることです。Finagleにはプログラミングモデルと運用モデルの２つがあります。プログラミングモデルは非常にエレガントで、表現力が豊かなRPCコールの関数プログラミングなので、きれいなコードを記述することができます。素晴らしいコード。最高のコード。そういったものを私たちは、すべて投げ捨てました。運用に関するものだけを提供することにしたのです。実際に私たちは、Finagleに関する知識を必要とせずにLinkerdが使用できるように、多大な努力を払っています。“TwitterやSoundcloud、Pinterestなどたくさんの企業で実績のある、信頼できるものをベースとしている”、というだけではありません。
InfoQ: マイクロサービスに対してのLinkerdは、20年前にTCPがクライアントサーバへの移行を実現した方法に例えられていますが、この対比は妥当なものなのでしょうか？
Morgan: 極めて理に適っています。私自身がパーカーを着たVint Cerfだと思っています。ちょっと大それた例えかも知れませんが、少なくともチャンスはあると思います。そのひとつが抽象化層です。TCPはネットワークプログラムを、“このデータをここからあそこへ送ってくれ”というようなものにしました。パケットのロスや重複、ルーティング、フロー管理、複数のアプリケーションが同じIPアドレスを共用しているかも知れない、といったことを意識する必要はありません。これと同じようにLinkerdは、アプリケーションプログラマがタイムアウトやデッドラインの存在、サービスディスカバリ、複数のエンドポイント間のバランシング、リトライ、サーキットブレークといったことを気にせずに、“この要求をここからあそこへ送ってくれ”と言えるようにします。
一般論として言うならば、アプリケーションのアーキテクチャ方法において、業界全体に大きな変化が起きています。それがまさに、“クラウドネイティブ”への移行なのです。企業はDockerやKubernetes、マイクロサービスなどに、そしてクラウドネイティブなスタックに移行しています。それ以外に選択肢はなく、いつ行なうかだけの問題です。運用を期待される規模もますます大きくなっていますが、仮想化ハードウェアには信頼性の乏しいセマンティクスしかありません。それと同時に、プロダクトには非常に迅速なイテレーションが求められます。これらすべてが、クラウドネイティブなアーキテクチャへとつながります。
スタックの基本レベルでのこのような大きな転換は、TCP/IPを中心として実現した、メインフレームからクライアントサーバへの移行に酷似しています。ネットワークを取り巻く業界全体は、1980年代にCiscoのような企業の変化から生まれました。それと同じようなことが、スタックのもう少し上で起きています。それこそが私たちの秘密の計画、マイクロサービスのCiscoになることなのです。
InfoQ: Linkerdが重要な意味を持つユースケースの例をいくつか挙げて頂けますか？
Morgan: 複数のサービスがあって、パフォーマンスや信頼性が重要で、SLAが有効なシステムならば、Linkerdを検討する余地があります。Linkerdのアーリーアダプタの大部分は、MonzoやZoozのような支払業務処理や銀行関連の企業でした。そういった企業はクラウドネイティブなプラットフォーム上に自らのインフラストラクチャを構築していて、信頼性を非常に重視しています。そういったシステムでは、数秒のダウンタイムが金銭的な損失になりますし、処理するトランザクションには文字通りお金が貼り付けられているのです。まさにLinkerdが真価を発揮するユースケースです。
InfoQ: Linkerdのロードマップについて教えてください。初めて公開された昨年から何が追加されていて、今後はどのような機能が拡張されるのでしょう？
Morgan: そうですね、常に取り組んでいるのはパフォーマンスとリソース消費量です。Linkerdをもっと小さく、早く、軽いものにしたいのです。素晴らしい機能を実現するために取り組んでいる、とてもクールなトップシークレットがいくつかあります。近いうちに発表できると思います。
さらに多くのプロトコルのサポートや、生のTCPのサポートに関する開発も行なっています。そしもちろん、当社のクラウドネイティブな兄弟、特にKubernetesとのより緊密な統合があります – KubernetesにLinkerdを接続するのは現在でもかなり簡単ですが、将来的にもっと簡単にできる部分が残っています。
そして最後に、今後の大規模な分散システムにおいては、gRPCやHTTP/2といった多重化プロトコルが選択肢となるのは間違いありません。Linkerdはすでにこれらのプロトコルをしっかりとサポートしていますが、さらによいものにするための投資を続けます。
Resources
Additional information on Linkerd can be found via the following resources:
- Getting Started with Linkerd
- How to Use Linkerd
- Linkerd Joins the Cloud Native Computing Foundation blog post by William Morgan
この記事を評価
- 編集者評
- 編集長アクション