クラウドネイティブソフトウェア企業のBuoyantが、Linkerd(“linker-DEE”と読む)のバージョン1.0をリリースした。クラウドネイティブなマイクロサービスベースのアプリケーションのための、オープンソースの“サービスメッシュ”プロジェクトだ。CTOのOliver Gould氏が、今回のリリースの重要性について論じている。
オープンソースプロジェクトにとって、1.0リリースは重要なマイルストンです。当社の場合のそれは、ユーザの最も重要なプロダクショントラフィックがその処理を依存する上で、十分に安定した機能セットに到達したという認識です。同時にそれは、今後の大幅な構成変更を制限するというコミットメントを示すものでもあります。
当社の小さなプロジェクトが、これほど素晴らしいオペレータや開発者の支持を集めているというのは、本当に頭の下る思いです。Linkerdのコミュニティから現れる機能やインテグレーションにはいつも驚かされています。さまざまな仕事を行なう上で、その不安や不確実性の低減にLinkerdが少しでも役に立てているのならば、これ以上の喜びはありません。
さらに創業者でCEOのWilliam Morgan氏は、次のように述べている。
Linkerdが1.0に到達して、PaypalやCredit Kama、Tickermasterといった社名が、採用企業の長いリストに加わることを誇りに思います。これら高トラフィックで信頼性の高い企業がDockerやKubernetes、その他のクラウドネイティブなスタックと共にLinkerdを使用して、さらに高いレベルの信頼性やスケーラビリティを、自分たちのアプリケーションに実現しているのです。
Morgan氏はサービスメッシュの目的と、クラウドネイティブなスタックにおいてその存在が重要な理由を定義した。DockerやKubernetes、ローカルマシン上で動作するLinkerdの使用例が、GitHubに公開されている。
Morgan氏とはLinkerdが１周年を迎えた先月にも単独インタビューを行なっているが、今回改めて、このマイルストンリリースに関するインタビューに応じてくれた。
InfoQ: サービスメッシュのビジョンは何か、サービス間のコミュニケーションを管理する上で、この新たな抽象化が必要となるのはどの時点なのか、改めて読者に説明して頂けますか？
William Morgan:/0} サービスメッシュは、サービス間通信を処理するインフラストラクチャ層です。マルチサービスアプリケーションに信頼性とセキュリティを追加するためのスタック上のポイントであり、アプリ全体にわたって統一された可視性とコントロールを提供します。
モノリシックまソフトウェアを運用している場合、あるいはホップ数が限られていて、専用のクライアントライブラリ(3層アプリケーションなど)で問題のないアーキテクチャであれば、これはおそらく不要でしょう。
ですが、“クラウドネイティブ”なアプリケーション - 現在はおもに、DockerやKubernetesやマイクロサービスを使用しているという意味ですが - を開発しているのであれば、このクロスサービス通信は、アプリケーションのランタイム動作において重要な部分を形成します。無視することはできません。監視しなければなりませんし、管理することができなくてはなりません。Linkerdのようなサービスメッシュが必要なのです。
InfoQ: サービス間において最も一般的な通信上の断絶はどのようなものでしょう、それはいまだ初期段階にある、現在のマイクロサービスやコンテナアーキテクチャに固有なものなのでしょうか？
Morgan: そうですね、分散システムが“面白い”理由のひとつは、小さな部分的障害がシステム全体の動作停止にまで拡がるパターンが非常に多い、という点にあります。悪名高い“カスケード障害”です。例えば、何らかの一時的な障害が発生した場合、その要求を再試行して処理する必要があります。再試行は当然、システムの負荷を増やすことになります。ソフトウェアの負荷が大きくなれば、速度が低下し始め、最終的には障害が発生するか - あるいは非常に遅くなって、障害と同じような状況に陥ります。つまり、障害を処理する方法によっては、事態を悪化させる可能性があるのです。 ごく小さな一部において速度が低下すると、負荷が増大して障害が発生し、その周りのすべてに障害が発生し始めるのです。
Linkerdはこのような状況を処理するように設計されています。負荷を低減し、適切な方法でフェールして、問題をエスカレートさせない方法で再試行を行なうようにできているのです。セキュリティや最適化、計装といった別の面もありますが、最も重視されるべきは信頼性に関する面です。
InfoQ: 1.0リリースで追加された新機能はどのようなものですか？最もクールな機能や特徴は何でしょう？
Morgan: 1.0で追加されたもので最も大きいのは、サービスメッシュAPIです。サービスメッシュで重要なのは、もはや内部向きのプロキシをそこら中に配置することに留まりません。そう、今や信頼性が重要なのです。ポイントは、サービス間の通信を、これまで不可視で暗黙的であった領域からとり出して、エコシステムのファーストクラスメンバという役割に移行することにあります。ここでも、このクリティカルなレイヤを監視し、管理し、コントロールすることが必要です。サービスメッシュAPIはそれを実現するための基本部分なのです。
1.0に向けて、当社では、Linkerdを取り囲むエコシステム - KubernetesやgRPC、Mesos、Consul、Prometheus、Zipkinなど、数多くのインテグレーションの拡大と強化を続けてきました。サービスメッシュはグルー層です。ユーザの多くは、Kubernetesを既存のインフラストラクチャに結合するためや、あるいはアーキテクチャ間でサービスをスムーズに移行するために、Linkerdを使用しています。
InfoQ: バージョン1.0が安定性や“対応度(readiness)”において、巨大なマイルストンであることは間違いありませんが、今後、追加的な機能という意味において、Linkerdユーザの関心を最も集めそうなのはどのような機能領域だと思いますか？
Morgan: 私たちの前には、非常にエキサイティングなロードマップがあります。当社ではこれまで、信頼性に関する機能に重点を置いてきました。その結果として、２つの素晴らしいビルディングブロックを実現することができました - トップレベルのサービスメトリックと、任意の方法でトラフィックをルーティングする機能です。この２つを合わせることで、原則に基づいたデータセンタ間のフェールオーバ、あるいはマルチクラウド/ハイブリッドクラウド、あるいはレイテンシを基準とする自動スケーリングなど、非常にパワフルな動作を行います。今後はさらに、ポリシの適用やサーバレス、メータリング、マルチテナントアカウンティングなど、さらに多くの機能にも着手したいと思っています。
そして最後に、安定性とパフォーマンス、リソース消費は常に最優先です。特にTLSのようなものに関しては、Linkerdの高速化、小型化、軽量化のためだけでも膨大な作業があります。
InfoQ: LinkerdはCloud Native Foundationに参加していますが、クラウドネイティブは今後、企業のトレンドとしてどのように成長すると思われますか？企業が開発するアプリケーションのクラウドネイティブ化を促進する条件は何でしょう、また、開発者への影響という観点からは、今後数年間でどのような変化が見込まれるでしょうか？
Morgan: クラウドネイティブの採用拡大には驚異的で、そのペースは毎日、さらに増加しています。DockerとKubernetesの採用率を見れば一目瞭然です。クラウド採用とリンクしているという意味からも、企業にとって不可欠なものです。クラウドネイティブは、クラウド用ソフトウェアを開発する場合に採用する、パターンの名前のひとつに過ぎません。クラウドで作業する場合、ハードウェアを占有していた時の信頼性に関する保証がすべて失われる、という事実を受け入れる必要があります。ハードウェアやランダムに発生する障害、他のテナントとのリソースの競合などをコントロールすることはできません。すべてが常に間違っているのです。従って、アプリケーションの信頼性とスケーラビリティを実現するには、ソフトウェアのレベルですべてに対処しなくてはなりません。まったく信頼できない環境を基盤として信頼性とスケーラビリティを実現できるようなソフトウェアを構築すること - それがすなわち、クラウドネイティブということなのです。