Bilgin Ibryam氏がQCon London[スライド]で、Kubernetesによる分散システムの進化と将来的なアーキテクチャのトレンドについて講演した。次のトレンドはインフラストラクチャに関連するものをマイクロサービスから分離することだ、と氏は言う。ビジネスロジックを備えたサービスと、状態管理やネットワーク、バインディング、ライフサイクルを担当するサイドカーとを組み合わせたこのアーキテクチャを、Ibryam氏はマルチランタイム・マイクロサービスと呼んでいる。
最近の分散アプリケーションは、多言語で独立性のある、数百の自動化されたコンポーネントで構成されている。アプリケーションの中にはハイブリッド環境で動作するものや、オープンソースソフトウェアを使用するもの、Kuberneresエコシステムに基くものなどがある、とIbryam氏は言う。これらの分散アプリケーションには、ライフサイクル管理、高度なネットワーク、リソースのバインド、ステートフルな抽象化などが必要である。Kubernetesを使用したクラウドネイティブアーキテクチャは、状態管理や自己修復メカニズム、宣言的デプロイメント、ワークロードのスケージュール、構成管理などによって、これらのニーズの多くを満足している、とIbryam氏は言う。
次に氏は、IstioやKnative、あるいはDaprといったプロジェクトによるKuberenetsエコシステムの進化について語った。これらのプロジェクトによってエコシステムに新たなパターンが登場した。サーバレスはマイクロサービスの後継ではない、と氏が言うのは、このような理由からだ。一方でサーバレスには、アプリケーションを単一のオペレーションとして実装する、より具体的なユースケースがある。マイクロサービスの次に来るのは、ネットワークやリソースバインディングなどのインフラストラクチャ上の事項のマイクロサービスからの分離である、とするIbryam氏は、これを"マルチランタイム"マイクロサービスアーキテクチャと呼んでいる。先日の記事で氏は、次のように述べている。
このソフトウェアアーキテクトでは、ビジネスロジック("マイクロロジック(micrologic)"と記されている部分)がアプリケーションのコアを形成して、サイドカーのメカ(mecha)コンポーネントがパワフルな組み込み分散プリミティブを提供します。"メカ"の機能を組み込んだマイクロロジックが、分散システムに必要なプロセス外機能を使用して、マルチランタイム・マイクロサービスを形成するのです。
InfoQは今回、"Kubernetes Patterns"の著者であるRedHatのプロダクトマネージャのBilgin Ibryam氏にインタビューして、マルチランタイム・マイクロサービスの定義と、マイクロサービスのパフォーマンス低下と複雑性に関する懸念について聞くことができた。
InfoQ: マルチランタイム・マイクロサービスとは何なのでしょうか？このアーキテクチャを実装しているツールや企業、あるいはパターンの例はありますか？
Bilgin Ibryam: Istioなどのサービスメッシュを使う時でも、アプリケーション以外にEnvoyなど複数のランタイムが存在します。しかしマルチランタイム・マイクロサービスは、Envoyなど他のランタイムやDockerランタイム以上のことを行うものなのです。例えばEnvoyはトラフィック管理をするだけですが、最近の通信ではキャッシュや暗号化など、もっと多くのことを行うようになってきました。これはつまり、"スマートなエンドポイントとダムパイプ"から"スマートなサイドカーとダムパイプ"へのシフトによって、インテリジェンスがエンドポイントからサイドカーに移行する、ということなのです。ビジネスロジックpodがアプリケーションのコアを形成し、サイドカーpodが分散プリミティブをアウトオブボックスで提供することによって、プロセス外の機能を使用して分散システムのニーズに応えるマルチランタイム・マイクロサービスが構成されます。
InfoQ: パフォーマンスの面ではどうなのでしょう？サイドカーの数が多過ぎて、システムが遅くなるようなことはないのでしょうか？
Ibryam: CiliumやCalicoのように、OSやハードウェアとのインタラクションをより効率的に行うサイドカーの作成を支援するプロジェクトが、サービスメッシュに合わせてすでに活動しています。ですが、それとは別に、私としてはあまり多くのサイドカーを使用するのはお勧めしません。最善のアプローチは、おそらくは統合を行うことでしょう。つまり、ビジネスロジック用のひとつのpod、私が今日話したような分散システムのニーズをカバーする処理を行うひとつのサイドカー、という構成が望ましいと思います。これならばオーバーヘッドも無視できます。パフォーマンス上のオーバーヘッドと同じように、モノリスからマイクロサービスアーキテクチャへの移行によって、インタラクションも非常に多くなっています。サイドカーがひとつであってもオーバーヘッドは増えるのですが、10倍になるようなことはありません。
InfoQ: マイクロサービスの複雑さを経験した後にモノリスアーキテクチャに立ち戻る企業については、どのような意見をお持ちですか？
Ibryam: 私はmicroservices.failというWebサイトを持っていて、マイクロサービス導入に失敗した企業の記事を集めています。マルチランタイムアーキテクチャは、そのような失敗を避けるためのものだ、と私は思っています。マイクロサービスをモノリシックなシステムに組み合わせることも可能ですが、ネットワークコネクタやさまざまなAPIの利用といった、分散システムに対するすべてのニーズを組み入れることができるとは考えられません。すべてをモノリスに入れたいとは思わないでしょう。ビジネスロジックはモノリスに収めて、その横にサイドカーを置く、ということも可能です。ですから、もしモノリスに戻ることがトレンドだとしても、それは以前のモノリスではなく、もっと分散システムのニーズに合った形のものなのです。私はこのアイデアを非常に気に入っているので、どちらに進むにせよ、選択権は持っていたいと思います。