Microsoftを中心とする業界全体のイニシアチブとして先日発表されたService Mesh Interface(SMI)は、さまざまなサービスメッシュテクノロジ間の相互運用性を開発者に提供するために、ポータブルな共通APIセットを定義しようとするものだ。SMIの発表は、Kubecon EUの基調講演においても、際立った形で取り上げられていた。
サービスメッシュテクノロジは、マイクロサービスとコンテナ、さらにはKubernetesなど、オーケストレータ利用の爆発的な増加に伴って注目を集めている。サービスメッシュテクノロジの広範な普及の裏には、アプリケーション開発を促進するためにさまざまなプラットフォームを推進する、数多くのベンダの存在がある。その一方では、ベンダのロックインによって、プラットフォームから別のプラットフォームに移行する際の移植性を失う危険性も存在する。
高次のサービスメッシュインターフェイスは、次のようなものを提供する。
- Kubernetes上のサービスメッシュの標準的インターフェイス
- 最も一般的なメッシュのユースケース用の基本機能セット
- 長期にわたって新しいメッシュ機能をサポート可能なフレキシビリティ
- メッシュテクノロジによるイノベーションのためのエコシステム空間
Service Mesh Interface(SMI)は、その原則やIngressなどのKubernetesリソースからアイデアを借用した共通APIセットが定義されているが、実装に関しては、ベンダが最も優れたものを独自に提供することが可能になっている。これらのAPIをプログラムで使用することにより、アプリケーションの移植性が保証されるのだ。
SMIの発表に関して、MicrosoftのプリンシパルプログラムマネージャであるLachlan Evenson氏に話を聞いた。論じられたトピックは、Kubernetesサービスメッシュのエコシステムや、それに関するGabe Monroy氏のブログ記事などだった。
InfoQ: KubeCon EUの基調講演では、"スマートエンドポイントとダムパイプ"や、マイクロサービスの進化に伴ってパイプをよりスマートにする必要がある、という話がありましたが、これが何を意味するのか、簡単に説明して頂けますか？
Lachlan Evenson: 長年にわたって、ネットワークアーキテクチャにおけるマントラは、ネットワークパイプはダム(dumb)のままで、アプリケーションにスマートさを組み込む、というものでした。ネットワークの仕事はパケットを転送することであって、暗号化や圧縮、認識といったロジックは、ネットワークエンドポイントの中に配置されるのです。インターネットはこのマントラを前提としていますから、かなりうまく機能していると言えます。
しかし今日では、マイクロサービスやコンテナ、Kubernetesのようなオーケストレーションシステムの爆発的な普及によって、エンジニアリングチームとしては、ますます多くなるネットワークエンドポイントの安全確保、管理、監視、という問題を抱えています。サービスメッシュテクノロジは、ネットワークをスマートに、これまでよりはるかにスマートにすることで、この問題の解決策を提供するものです。すべてのサービスに対して、セッションの暗号化、クライアントの承認、適切なテレメトリの発行、アプリケーションバージョン間トラフィックのシームレスな移行などを教える代わりに、サービスメッシュテクノロジがこれらのロジックをネットワークにプッシュし、独立した管理APIセットによってコントロールされるようになります。
InfoQ: まず最初に、マイクロサービスとサービスメッシュの関係について説明してください。Kubecon EUの廊下で話したように、SMIはマイクロサービス全般、特にKubernetesにとって、採用サイクルの初期段階にあると思われますか？
Evenson: 多くのベンダによって、アプリケーション開発者に新しいエキサイティングな選択肢を提供するサービスメッシュテクノロジが急増しています。問題なのは、メッシュテクノロジを使用する開発者がプロバイダを選択して、APIを直接使用するコードを書く必要があることです。つまり、サービスメッシュの実装にロックインされるのです。汎用インターフェイスがなければ、移植性と柔軟性が失われて、広範なエコシステム全体でイノベーションの恩恵を受けることができなくなります。
Gabe Monroy氏がブログで言及したことに加えて、コミュニティにおける他の一般的な抽象化(CNI、CRI、Ingress、NetworkPolicy)と同じように、技術的な実装を押し付けるのではなく、開発者のニーズの解決に焦点を当てているSMIにとっては、これはまさに好機といえます。サービスメッシュドメインにおいて抽象的な共通セットを作り上げることで、実装のエコシステムが拡大し、開発者とクラスタ管理者に対して、最高クラスの実装を選択する自由が与えられるのです。
InfoQ: Service Mesh Interfaceの技術的な詳細について説明をお願いします。主として開発者向けなのか、あるいはプラットフォームプロバイダ向けなのでしょうか？後者が対象である場合、開発者にも何らかの影響があるのでしょうか？
Evenson: 別々の方法で、両方を目標にしています。プラットフォームプロバイダは、そのジョブにとって最適な実装を選択する自由を維持しながら、最も共通的なサービスメッシュ機能として、唯一の抽象化を提供することが可能になります。これにより、プラットフォーム開発の迅速性を残し、ポータビリティ層を維持しながら、最も要求されるサービスメッシュ機能へのアクセスを提供することができるのです。
開発者の観点から見ると、サービスメッシュに必要なものを表現した、ひとつのAPIセットが存在することになります。これら共通的な抽象化により、実装固有の特異性は排除されます。例えば、"サービスにカナリアデプロイメントを提供したい"というのはごく一般的な要求ですが、低レベルのリソースを個別の方法でプログラムするのではなく、SMI TrafficSplit APIを使用することで、この複雑な処理を簡単にすることができます。
InfoQ: 基調講演では、SMIはKubernetes 1.1で導入されたIngressなどのKubernetesリソースに類似している、という言及がありました。公平のために言えば、ingresの機能範囲が非常に限定的であるのに対して、SMIでは、ネットワーク入力よりも多くの機能を備えた、複数のさまざまなプラットフォーム(Istio、Linkerd、Consulなど)に共通するインターフェースの提供を意図しています。この課題はどのように克服されるのでしょうか？
Evenson: 純粋なサービスメッシュエコシステムそのものの機能にアプローチするのではなく、企業ユーザと協力して、彼らがサービスメッシュを見た時に、最も重要となる要求を理解する作業を続けてきました。SIMで開発する抽象化は、これら一般企業の要求に沿う形で進めています。
InfoQ: サービスメッシュスの領域ではIstioが非常に多く採用されていますが、Istioの内部構造(あるいは概念)は、SIMにどの程度取り入れられているのでしょうか？あるいは、SMIは純粋に、サービスメッシュによって提供されるコア機能の抽象化であることに焦点を当てているのでしょうか？
Evenson: 後者ですね。SMIでは、サービスメッシュを導入した理由を企業ユーザからヒアリングした内容に基づいて、最も一般的な抽象化を提供します。
InfoQ: SMIに関わっているコミュニティと、ロードマップについて話していただけますか？
Evenson: SMIは、Microsoft、Linkerd、HashiCorp、Solo.io、Kinvolk、Weaveworksのパートナーシップで開始されたオープンプロジェクトで、Aspen Mesh、Canonical、Docker、Pivotal、Rancher、Red Hat、VMwareのサポートを受けています。
HashiCorp、Buoyant、Solo.ioなどと協力して、企業顧客から寄せられた上位3つのサービスメッシュ機能に関する初期仕様を構築しました。
- トラフィックポリシ — サービス全体にIDやトランスポート暗号化などのポリシを適用します
- トラフィックテレメトリ — エラー率やサービス間の遅延など、主要なメトリックをキャプチャします
- トラフィック管理 — 異なるサービス間でのトラフィックのシフトや重み付けを行います
これはまだ、SMIで達成したいことの始まりに過ぎません。開発中の数多くのエキサイティングなメッシュ機能によってSMI APIを徐々に進化させ、現在の仕様を新たな機能で拡張したいと思っています。
今は設立パートナたちと協力して、他に定義の必要なAPIを特定し、今後のプロジェクトのマイルストーンのロードマップを構築しているところです。
結局のところ、サービスメッシュテクノロジは、アプリケーション開発者から大きな注目を集めている。SMIは、実績あるアプリケーション開発の原則を取り入れることで、複数のベンダとプラットフォームプロバイダが実装を競うための統一仕様を提供することを目指すと同時に、開発者には共通インターフェイスセットを介したアプリケーションの移植性を提供する。
SMIの詳細情報はsmi-spec.ioに、仕様自体はGitHubにある。