高性能サービスガバナンスフレームワーク Kmesh について知る

3 月、openEuler コミュニティは、アーキテクチャの革新を通じてサービスグリッドに新しいデータプレーンエクスペリエンスをもたらす、高性能サービスガバナンスフレームワーク Kmesh という革新的なプロジェクトを立ち上げました。この記事はサービスグリッドから始まり、Kmesh の過去と現在を理解するのに役立ちます。

現在の Kmesh プロジェクトは openEuler 23.03 でリリースされており、興味のあるパートナーはダウンロードして使用することができます。

倉庫アドレス: https://gitee.com/openeuler/Kmesh

サービスメッシュとは

サービスグリッドは、Linkerd ソフトウェアを開発した好調な企業によって 2016 年に提案されました。William Morgan (Linkerd CEO) によって与えられた元の定義Service Mesh:

❝

サービスメッシュは、サービス間通信を処理するための専用のインフラストラクチャ層です。最新のクラウドネイティブアプリケーションを構成するサービスの複雑なトポロジを通じて、リクエストを確実に配信する役割を果たします。実際には、サービスメッシュは通常、アプリケーションコードと一緒にデプロイされる軽量ネットワークプロキシの配列として実装され、アプリケーションはそれを意識する必要がありません。

❞

大まかに言うと、サービスメッシュはサービス間の通信を処理するインフラストラクチャ層です。ネットワークプロキシアレイの形式を通じて、最新のクラウドネイティブアプリケーションに透過的で信頼性の高いネットワーク通信を提供します。

サービスグリッドの本質は、マイクロサービス間の通信を改善する方法の問題を解決することであり、負荷分散、グレースケールルーティング、サーキットブレーカーの電流制限などのガバナンスルールを通じて、トラフィックを合理的に配置し、クラスターサービスの機能を最大化します。サービスガバナンスの進化の産物。

サービスガバナンスの進化プロセスを 3 つの世代に分けて簡単に比較すると、サービスガバナンスの機能が徐々にビジネスから切り離され、インフラストラクチャに集約されていくことがわかります。

サービスグリッドは、サービス間通信を処理するインフラストラクチャ層として、マイクロサービスガバナンスにおける K8 の欠点を効果的に補い、クラウドネイティブな次世代テクノロジとして、クラウドインフラストラクチャの重要なコンポーネントとなっています。

近年のテクノロジーのトレンドとして、業界ではLinkerd、Istio、Consul Connect、Kumaなど、同様のソフトウェアアーキテクチャを持ったサービスグリッドソフトウェアが多数誕生しています。サービスグリッドの基本的なアーキテクチャを以下に示します。

k8s クラスターを例にとると、Pod インスタンスが作成されると、サービスグリッドソフトウェアは透過的に Proxy コンテナ (サイドカーとも呼ばれ、Istio のデフォルトのサイドカーソフトウェアは Envoy) を Pod 内に作成します。Pod 通信の基本的なフローは次のとおりです。以下に続きます:

トラフィックは、iptables ルールを通じてポッド内のプロキシコンポーネントに透過的にハイジャックされます。
プロキシコンポーネントは、リクエストに従ってトラフィック管理ロジック (ヒューズ、ルーティング、ロードバランシングなど) を完了し、通信するピアサービスインスタンスを見つけて、メッセージを転送します。
ピア Pod のプロキシコンポーネントは外部トラフィックをハイジャックし、基本的なトラフィック管理ロジック (電流制限など) を実行してから、トラフィックを Pod に転送します。
Pod の処理が完了すると、元のパスに従って応答メッセージが要求元の Pod に返されます。

サービスメッシュデータプレーンの問題点と課題

上記からわかるように、サービスグリッドは、データプレーンにプロキシ層を導入することにより、アプリケーションに対して透過的なサービスガバナンスを実装します。ただし、これにはコストがかかり、プロキシ層の導入によりサービス通信の遅延が増加し、パフォーマンスが低下することは避けられません。

Isito 公式 Web サイトで提供されているデータを例にとると、クラスター規模では、マイクロサービス間のデータプレーン上のシングルホップ通信遅延が 2.65ms 増加します。マイクロサービスクラスターでは、外部アクセスが頻繁に通過することがわかります。クラスター内の複数のマイクロサービスを介して呼び出しを行う場合、グリッドによってもたらされる遅延オーバーヘッドは非常に大きく、サービスグリッドの使用が増えるにつれて、プロキシアーキテクチャによって生じる追加の遅延オーバーヘッドがサービスグリッドが直面する重要な問題になっています。、

この目的のために、HTTP サービス L7 ロードバランシングのシナリオをテストし、グリッドデータプレーンの通信のパフォーマンス管理を行いました。時間のかかる割合は次のとおりです。

グリッドトラフィックの詳細な分析から、マイクロサービスの相互運用性は 1 つのリンク確立から 3 つのリンク確立に、2 つの入口および出口プロトコルスタックから 6 つの入口および出口プロトコルスタックに変化し、時間のかかる作業は主に複数のデータコピー、リンク構築に集中しています。通信、コンテキストスケジューリングのスイッチングなど、トラフィック管理の実際のオーバーヘッドの割合は大きくありません。

次に問題は、アプリケーションに対するグリッドの透過的なガバナンスを維持しながら、グリッドのレイテンシオーバーヘッドを削減するかどうかです。

高性能サービスグリッドガバナンスフレームワーク Kmesh

上記のパフォーマンス分析に基づいて、グリッドデータサーフェスのパフォーマンスを 2 段階で最適化しました。

Kmesh1.0: ソックマップに基づいてグリッドデータサーフェスを高速化

Sockmap は Linux 4.14 で導入された ebpf 機能で、複雑なカーネルプロトコルスタックを経由せずにノード内のソケット間のデータフローのリダイレクトを実現し、リンク上のソケット間のデータ転送パフォーマンスを最適化します。

サービスグリッドシナリオでは、ポッド内のビジネスコンテナとローカルプロキシコンポーネントの間で完全なカーネルプロトコルスタックがデフォルトで使用されます。このオーバーヘッドは、次の図に示すように、ソックマップを通じて最適化できます。

ソックマップアクセラレーションの基本的な手順は次のとおりです。

リンク構築プロセス中に ebpf プログラム (ebpf prog type: BPF_PROG_TYPE_SOCK_OPS) をマウントして、すべての TCP リンク構築アクションをインターセプトします。

通信相手の正側と負側のソケット情報をソックマップテーブルに格納します。
- BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB ステータスはクライアント側のソックマップレコードを追加します。
- BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB ステータスはサーバー側のソックマップレコードを追加します。
ebpf プログラム (ebpf prog タイプ: BPF_PROG_TYPE_SK_MSG) を sendmsg プロセスにマウントして、メッセージ送信アクションをインターセプトします。
- 現在のソケット情報に従ってソックマップテーブルを検索し、相手側のソケット情報を関連付けて見つけ、トラフィックを相手側ソケットの受信キューに直接リダイレクトします。

ソックマップアクセラレーションサービスグリッドデータサーフェスに基づくと、60 の長いリンクシナリオの実測では、サービスアクセスの平均遅延が元のグリッドと比較して 10% ～ 15% 削減されました。

Sockmap は現在、サービスグリッドのデータサーフェスを最適化するための比較的一般的なソリューションですが、効果の観点から見ると、通信遅延を 15% 削減しても、グリッド遅延のパフォーマンスが悪いという問題は実際には解決されません。

Kmesh2.0: プログラマブルカーネルに基づき、トラフィック管理を OS にシンク

上記のパフォーマンス分析によると、グリッドによって導入される追加のオーバーヘッドのうち、トラフィック管理の実際のオーバーヘッドはそれほど高くなく、ほとんどの時間はトラフィックをプロキシコンポーネントに送信するのに無駄に費やされていることがわかります。その場合、トラフィックガバナンスは、このプロキシコンポーネントを通過して、トラフィックの送受信のパスをたどることはできませんか? ネットワーク通信は当然カーネルプロトコルスタックを経由する必要がありますが、プロトコルスタックにトラフィックを管理する機能があれば、この問題は解決できるでしょうか?

Kmeshは当社が提案した高パフォーマンスなサービスガバナンスフレームワークですプログラマブルカーネルをベースにトラフィックガバナンスをOSに落とし込みましたグリッドデータプレーンがプロキシコンポーネントを経由しなくなりましたサービスの相互運用性が3ホップから1ホップに変化し、ガバナンスも作業は途中で本当に完了します。; マイクロサービス相互通信のトラフィックパスは次のとおりです。

Kmesh のソフトウェアアーキテクチャ:

Kmesh の主なコンポーネントは次のとおりです。

kmesh-controller: kmesh 管理プログラム。Kmesh ライフサイクル管理、XDS プロトコルのドッキング、観測の運用と保守、その他の機能を担当します。
kmesh-api: kmesh によって外部に提供される API インターフェイス層。主に、xds 変換後のオーケストレーション API、観測運用および保守チャネルなどが含まれます。
kmesh-runtime: L3 ～ L7 トラフィックオーケストレーションをサポートするカーネルに実装されたランタイム。
kmesh-orchestration: ルーティング、グレースケール、負荷分散など、ebpf に基づいて L3 ～ L7 トラフィックオーケストレーションを実装します。
kmesh-probe: エンドツーエンドの観察機能を提供する、観察操作およびメンテナンスプローブ。

Istio グリッド環境をデプロイし、異なるグリッドデータプレーンソフトウェア (Envoy/Kmesh) を使用して、http サービス L7 ロードバランシングのシナリオにおけるグリッドデータプレーン (テストツール: fortio) のパフォーマンスの比較テストを実施しました。

Kmesh に基づくグリッド内のサービス相互運用パフォーマンスは、Istio ネイティブデータサーフェス (Envoy) のサービス相互運用パフォーマンスの 5 倍であることがわかります。同時に、非環境下で k8s に基づくサービス相互運用パフォーマンスもテストしました。 -grid は、Kmesh のパフォーマンスデータとほぼ同等であり、Kmesh データプレーンの遅延パフォーマンスをさらに証明します。(テストシナリオは実験室環境での L7 負荷分散です。実際のガバナンスシナリオでのパフォーマンス効果はそれほど理想的ではありません。事前評価では Istio より 2 ～ 3 倍優れています)

要約する

サービスメッシュは、クラウドネイティブの次世代テクノロジーとして、アプリケーションに透過的なサービスガバナンスを提供すると同時に、そのプロキシアーキテクチャに起因する追加の遅延オーバーヘッドを導入し、これがグリッドアプリケーションの推進の鍵となっています。 OS、Kmesh は、プログラミングカーネルのサービスガバナンスフレームワークを提案し、トラフィック管理機能を OS にシンクすることにより、グリッドデータプレーンのパフォーマンスを大幅に向上させ、グリッドデータプレーンの開発に新しい考え方を提供します。

コミュニティの新しいプロジェクトとして、Kmesh はまだ初期段階にあり、今後も L4/L7 トラフィック管理機能の改善を続けていく予定です。詳細については、プロジェクトのホームページを確認してください: https://gitee.com/openeuler /Kメッシュ