Istio以降へ:Azureのサービスメッシュインターフェイス

少なくともAzureでの最新のクラウドファーストアプリケーション開発は、Kubernetesにほぼ依存するようになりました。Virtual Kubelets、AKS(Azure Kubernetes Service)、Azure Service Fabric Meshなどのテクノロジーは、コンテナーを使用してマイクロサービスをデプロイおよび管理し、Azure上でスケーラブルな分散アプリケーションを構築するための鍵となります。

AzureのKubernetesツールを見ると、MicrosoftがCloud Native Computing Foundation内およびその周辺で多くの作業を行っており、オープンソースフレームワークのすべての側面に取り組んでいることは明らかです。驚かないでください。Microsoftは、Kubernetesプロジェクトの創設者の1人を雇い、重要なベンダーであるDeisを買収しました。Deisチームは、Kubernetesエコシステムへの最新のAzureの貢献の1つであるService Mesh Interface(SMI)の背後にいます。

サービスメッシュの紹介

最初に、サービスメッシュとは何か、Kubernetesベースのアプリケーションにとってなぜそれが重要なのかを説明するのが最善でしょう。

現代のITアーキテクチャは、すべて抽象化に関するものです。クラウドサービスを使用すると、基盤となるハードウェアについて考える必要がなくなります。IaaSを使用している場合は、コードをホストする仮想マシンを定義します。PaaSを使用すると、選択したサービスとAPIを使用してハードウェアからさらに離れ、アプリケーションと予算に適したパフォーマンスレベルを選択できます。Kubernetesなどのコンテナベースのアーキテクチャでは、2つの中間点にあります。AKSなどのサービスを使用して、基盤となる仮想マシンを定義できます。仮想マシンは、コンテナポッドをホストし、コンピューティングとメモリの変更に応じてスケールアウトします(および現在、KEDA(Kubernetesベースのイベント駆動型自動スケーリング)を使用して、イベントを受信します)。

これは抽象化の1つの側面にすぎません。 Kubernetesマイクロサービスは本質的にステートレスです。外部ストレージを使用し、物理ネットワークまたは仮想ネットワークの上に配置されます。おそらく最も注意が必要なのは、Kubernetesを実行するネットワークの側面です。サービスがスケールアウトおよびスケールダウンするにつれて、アプリケーションの変更に合わせてネットワークを変更する必要があります。しかし、アプリケーションのフロントエンドとバックエンドが異なる速度でスケーリングしている可能性がある場合、どのようにしてサービスを接続し続けるのでしょうか。

そこで登場するのがサービスメッシュです。これらは新しい抽象化レイヤーであり、最新のソフトウェア定義ネットワークの機能を利用して、基盤となるネットワークからコードを切り離します。サービスメッシュは、コードとともに展開される一連のネットワークプロキシとして機能することにより、コードが基盤となるネットワークを認識しなくても、サービス間の通信を管理します。サービスメッシュは、アプリケーションのネットワーキングの自動化されたコントロールプレーンと考えることができ、Kubernetesがコードをスケールアップおよびスケールダウンするときに基盤となるコントロールプレーンを管理します。

マイクロサービス用のソフトウェア定義ネットワーク

おそらく、サービスディスカバリと一緒にスマートで遅延を意識したスケーラブルな負荷分散を実装する方法として最もよく考えられているのは、サービスメッシュは基本的に、Kubernetesデプロイメントの一部として管理される動的ルーティングルールを備えた分散ルーターです。追加のルールを定義できます。たとえば、本番システムとテストシステムを分離しておく、新しいリリースの展開とコンテナバージョン間の変更を処理するなどです。アプリケーション内の各ポッドには、サイドカーとして実行されるサービスメッシュインスタンスがあり、サービス検出やその他のステートフル要素がサービスの外部で実行されます。

サービスメッシュを使用すると、インテリジェンスを新しいネットワークレイヤーにプッシュするため、マイクロサービスに組み込む必要がありません。接続を暗号化する必要がありますか?それはあなたのサービスメッシュの仕事です。クライアントを承認する必要がありますか?サービスメッシュの別のタスク。

メッシュが多すぎます

Kubernetesデプロイメントをサービスメッシュと組み合わせるのは非常に理にかなっています。ただし、もう1つ大きな問題があります。どちらを使用しますか?使節?イスティオ? Linkerd?アスペンメッシュ?いずれかを選択した場合、ビジネスの別の部分の開発チームが別の部分を選択しないようにするにはどうすればよいですか?それでは、あなたの会社が特定のプラットフォームで標準化することを決定した場合はどうなりますか?

これが、Microsoftがサービスメッシュインターフェイスで解決しようとしている問題です。SMIは、各サービスメッシュが独自のAPIセットを持つ代わりに、さまざまなサービスメッシュ間で機能する共通のAPIを実装し、その新しいスマートネットワークを管理する方法です。コードを特定のサービスメッシュとそのAPIにロックする代わりに、共通のAPIを介して最も一般的なユースケースに対応するコードを記述できます。サービスメッシュを交換する必要がある場合(プロバイダーを変更した場合、またはより適切に機能するプロバイダーを見つけた場合)、サービスメッシュがSMIを実装している限り、コードを変更する必要はありません。あなたがする必要があるのは、サービスメッシュサイドカーを変更し、コードを再デプロイすることです。

SMI:一般的なサービスメッシュAPI

Microsoftは、HashicorpやBuoyantなどのKubernetesエコシステム企業と協力して、顧客からの一般的な要求をサポートするSMIの主要な機能を定義してきました。最初のリリースでは、トラフィックポリシー、トラフィックテレメトリ、およびトラフィック管理の3つの領域に焦点を当てていました。これらの3つの領域は、ほとんどのサービスメッシュによって制御されます。その目的は、基盤となるアプリケーションを変更せずに実装しやすい仕様にすることです。

SMIを標準APIのセットにすることで、サービスメッシュベンダーが独自のAPIまたは指定されたもの以外の追加機能を提供し続けることを妨げるものは何もありません。または、変更を加える必要はありません。サードパーティは、SMIAPIと独自のサービスAPIの間に位置する変換レイヤーを構築できます。 SMI APIは拡張APIサーバーおよびカスタムリソース定義として実装されているため、新しいバージョンのKubernetesも必要ありません。既存の管理ツールを使用して、先に進んで任意のクラスターにインストールできます。これにより、Azureやその他のクラウドでホストされているKubernetesサービスがSMIを簡単に既存のマネージドKubernetesサービスに組み込むことができます。

Linkerd、Aspen Mesh、VMwareのNSX Service Meshのいずれを使用する場合でも、SMIを使用すると、コードの移植性が向上し、特定のクラウドサービスへのロックインを回避して、好みのメッシュを選択できます。次に、コードに影響を与えることなくサービスメッシュを切り替える機会があります。新しいサービスメッシュの方がパフォーマンスが優れている場合は、ビルドパイプラインを変更して新しいメッシュを使用し、更新されたアプリケーションをデプロイするだけです。

マイクロソフトがこのようなプロジェクトを主導し、Kubernetesコミュニティの幅広い分野で協力しているのを見るのは興味深いことです。Azureは、サービスメッシュの構築に明確に焦点を当てていないアプローチを採用することで、AKSの構成の一部としてさまざまなサービスメッシュを提供できるため、コードを変更することなく、必要なツールを選択できます。