Service Mesh Interface(SMI) 仕様は、さまざまなサービスメッシュ実装の上に抽象化レイヤを提供することで、システム内のプロセスを変更せずに実装を簡単に交換できるようにする。Kubernetesの開発者のひとりで現在はMicrosoftに所属する、著名なエンジニアのBrendan Burns氏は、先日のQCon New York 2019 Conferenceで、新しい仕様と今後のロードマップについて講演した。
最初に氏は、現在のサービスメッシュの状況について論じた。市場では現在、いくつかの異なる実装による断片化や混乱、複雑化が数多く発生している。サービスメッシュベースのソリューションを採用する場合には、アプリケーションアーキテクチャの重要部分の多くがサービスメッシュに展開される。そのため、何かが機能しなくなると、後でロールバックやクリッピングすることは容易ではない。
ユーザは、複数のツールを選択した上で、それらを統合して相互に機能させるか、必要な機能をすべて備えていない可能性のある単一の実装か、いずれかを選択しなければならない。
サービスメッシュエコシステムには、これらの課題に対処する共通の標準が必要であり、それがSMI仕様の開発につながった。SMIの抽象化レイヤは、さまざまなサービスメッシュ実装(Istio、Linkerd、Consul Connectなど)で実装可能な、使いやすいAPIを提供する。サービスメッシュは新しいパターンではなく、Open Container Initiative(OCI)、Container Network Interface(CNI)、Container Storage Interface(CSI)、StorageVolumesなど、他の仕様と共通点がある。
SMI仕様の目標は次のようなものだ。
- 概念を実装から分離する — 現状はプロダクトが実装である
- サービスメッシュの"コアコンセプト"を提供する
- リリースとイテレーションを行う
- コンセプトとしてのService Meshを中心としたコミュニティを構築する
Burns氏は、このアプローチの背景となった理由の説明として、ユーザに必要なのは実装ではなくサービスメッシュの概念であること、ツールベンダに必要なのは特殊化ではなく抽象化であること、実装者に必要なのはユーザからの隔離であること、の３つを挙げた。Service Mesh Interfaceコミュニティには、Microsoft、Linkerd、Hashicorp、Solo.io、Redhat、Pivotal、VMWareなどがパートナとして参加している。
次にBurns氏は、Service Mesh Interface APIの概要として、TrafficSpec、TrafficTarget、TrafficSplit、TrafficMetricsの各コンポーネントについて説明した。SMIはこれらすべての機能に対して、Kubernetes APIを可能な限り再利用している。氏はRoutesとTraffic Targetsの設定方法を説明した上で、YAML設定の例を公開した。また、TrafficSplitやTrafficMetricsなど、その他の面を設定する方法についても説明した。トラフィックの分割構成を定義すると、Kubernetesが着信要求のトラフィックを分割するための新たなサービスを作成してくれる。
SMI仕様には現在、HashicorpのConsulConnect、Linkerd、Istioによる3つの実装がある。さらに、WeaveWorksのFlaggerや、Rancher LabsのRioなどのフレームワークでは、そのツーリングもサポートしている。
Service Mesh Interfaceの詳細については、仕様、Github プロジェクト、およびSDKを参照してほしい。AzureクラウドプラットフォームでホストされたKubernetesクラスタ上でサービスを実行するためのサンプルコードを含む、SMIウェビナをチェックアウトすることもできる。