おい、ハブル！ 記事の翻訳をご紹介します 「サービス メッシュ データ プレーンとコントロール プレーン」 作者 マット·クライン.

今回は、サービス メッシュ コンポーネント、データ プレーンとコントロール プレーンの両方の説明を「希望して翻訳」しました。 この説明が私には最もわかりやすく、興味深く思えました。そして最も重要なことに、「それはそもそも必要なのか？」という理解につながります。

「サービス メッシュ」というアイデアがここ 10 年間でますます人気が高まり (元の記事 2017 年 XNUMX 月 XNUMX 日)、このスペースへの参加者の数が増加するにつれて、それに比例して全体の混乱が増大しているのがわかりました。さまざまなソリューションを比較対照する方法に関する技術コミュニティ。

この状況は、XNUMX 月に私が書いた次の一連のツイートに最もよく要約されています。

サービス メッシュの混乱 #1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy。 どれも Istio と同等ではありません。 Istio はまったく別のものです。 1 /

2 つ目は単なるデータ プレーンです。 彼らは自分たちだけでは何もしません。 彼らはもっと何かをしたいと思っているに違いありません。 XNUMX/

Istio は、パーツを結び付けるコントロール プレーンの一例です。 これは別の層です。 /終わり

前のツイートでは、いくつかの異なるプロジェクト (Linkerd、NGINX、HAProxy、Envoy、Istio) について言及していますが、より重要なのは、データ プレーン、サービス メッシュ、およびコントロール プレーンの一般的な概念を紹介していることです。 この投稿では、一歩下がって「データ プレーン」と「コントロール プレーン」という用語の意味について大まかに説明し、その後、その用語がツイートで言及されているプロジェクトにどのように適用されるかについて説明します。

サービス メッシュとは実際何ですか?

図 1: サービス メッシュの概要

図1 は、サービス メッシュの概念を最も基本的なレベルで示しています。 サービス クラスター (AD) は XNUMX つあります。 各サービス インスタンスはローカル プロキシ サーバーに関連付けられます。 単一のアプリケーション インスタンスからのすべてのネットワーク トラフィック (HTTP、REST、gRPC、Redis など) は、ローカル プロキシを介して適切な外部サービス クラスターに渡されます。 このようにして、アプリケーション インスタンスはネットワーク全体を認識せず、ローカル プロキシのみを認識します。 事実上、分散システム ネットワークはサービスから削除されました。

データプレーン

サービス メッシュでは、アプリケーションのローカルに配置されたプロキシ サーバーが次のタスクを実行します。

• サービスディスカバリ。 あなたのアプリケーションではどのようなサービス/アプリケーションが利用できますか?
• ヘルスチェック。 サービス ディスカバリによって返されたサービス インスタンスは正常であり、ネットワーク トラフィックを受け入れる準備ができていますか? これには、アクティブ (応答/ヘルスチェックなど) ヘルス チェックとパッシブ (異常なサービス状態の指標として 3 つの連続した 5xx エラーを使用するなど) ヘルス チェックの両方が含まれます。
• ルーティング。 REST サービスから「/foo」へのリクエストを受信した場合、そのリクエストはどのサービス クラスターに送信されるべきですか?
• 負荷分散。 ルーティング中にサービス クラスターが選択されたら、どのサービス インスタンスにリクエストを送信する必要がありますか? タイムアウトは何ですか? どのようなサーキットブレーカー設定を使用しますか? リクエストが失敗した場合、再試行する必要がありますか?
• 認証と認可。 受信リクエストの場合、mTLS またはその他のメカニズムを使用して、呼び出し側サービスを暗号的に識別/承認できますか? 認識/承認された場合、サービス上で要求された操作 (エンドポイント) を呼び出すことが許可されますか、それとも認証されていない応答を返す必要がありますか?
• 可観測性。 詳細な統計、ログ/ログ、分散トレース データはリクエストごとに生成され、オペレータが分散トラフィック フローとデバッグの問題を発生時に理解できるようにする必要があります。

データ プレーンは、サービス メッシュ内の以前のすべてのポイントを担当します。 実際、サービス (サイドカー) に対してローカルなプロキシはデータ プレーンです。 言い換えれば、データ プレーンは、サービスとの間で送受信されるすべてのネットワーク パケットを条件付きでブロードキャスト、転送、監視する役割を果たします。

コントロールプレーン

ローカル プロキシがデータ プレーンで提供するネットワーク抽象化は魔法 (?) です。 しかし、プロキシは実際にサービス B への「/foo」ルートをどのようにして知るのでしょうか? プロキシ リクエストによって設定されたサービス ディスカバリ データはどのように使用できますか? 負荷分散、タイムアウト、サーキット ブレークなどのパラメータはどのように構成されますか? ブルー/グリーン方式またはグレースフル トラフィック トランジション方式を使用してアプリケーションをデプロイするにはどうすればよいですか? システム全体の認証と認可の設定を構成するのは誰ですか?

上記の項目はすべて、サービス メッシュのコントロール プレーンの制御下にあります。 コントロール プレーンは、一連の分離されたステートレス プロキシを取得し、それらを分散システムに変換します。.

多くの技術者がデータ プレーンとコントロール プレーンの別々の概念を混乱させる理由は、ほとんどの人にとってデータ プレーンは馴染みのあるものであるのに対し、コントロール プレーンは馴染みのない/理解できないものだからだと思います。 私たちは、物理ネットワークのルーターとスイッチに長年取り組んできました。 パケット/リクエストはポイント A からポイント B に移動する必要があり、これを行うためにハードウェアとソフトウェアを使用できることを理解しています。 新世代のソフトウェア プロキシは、私たちが長年使用してきたツールの単なる機能強化版です。

図 2: ヒューマン コントロール プレーン

ただし、ほとんどのネットワーク オペレータはシステムのこの部分をテクノロジー コンポーネントと関連付けていない可能性がありますが、私たちは長い間コントロール プレーンを使用してきました。 理由は簡単です。
現在使用されているほとんどのコントロール プレーンは....

На 図2 私が「ヒューマン・コントロール・プレーン」と呼ぶものを示しています。 このタイプの展開では、依然として非常に一般的ですが、おそらく不機嫌そうな人間のオペレーターが静的構成を (場合によってはスクリプト経由で) 作成し、特別なプロセスを通じてすべてのプロキシに展開します。 その後、プロキシはこの構成の使用を開始し、更新された設定を使用してデータ プレーンの処理を開始します。

図 3: 高度なサービス メッシュ コントロール プレーン

На 図3 は、サービス メッシュの「拡張された」コントロール プレーンを示しています。 これは次の部分で構成されます。

• 人間: システム全体に関して高度な意思決定を下す人がまだいます (怒りが少ないことを願っています)。
• コントロールプレーンUI: 人間は、ある種のユーザー インターフェイスを操作してシステムを制御します。 これは、Web ポータル、コマンド ライン アプリケーション (CLI)、またはその他のインターフェイスである可能性があります。 ユーザー インターフェイスを使用して、オペレータは次のようなグローバル システム構成パラメータにアクセスできます。
  • 導入制御、ブルー/グリーン、および/または段階的なトラフィック移行
  • 認証と認可のオプション
  • ルーティング テーブルの仕様。たとえば、アプリケーション A が「/foo」に関する情報を要求した場合に何が起こるか
  • タイムアウト、再試行、サーキット ブレーク設定などのロード バランサーの設定。
• ワークロードスケジューラ: サービスは、Kubernetes や Nomad など、何らかのタイプのスケジューリング/オーケストレーション システムを通じてインフラストラクチャ上で実行されます。 スケジューラは、ローカル プロキシとともにサービスをロードする責任があります。
• サービスディスカバリ。 スケジューラは、サービス インスタンスを開始および停止するときに、ヘルス ステータスをサービス検出システムに報告します。
• サイドカープロキシ構成 API : ローカル プロキシは、オペレータの介入なしに、結果的に整合性のあるモデルを使用して、さまざまなシステム コンポーネントから状態を動的に抽出します。 現在実行中のすべてのサービス インスタンスとローカル プロキシ サーバーで構成されるシステム全体が、最終的に XNUMX つのエコシステムに収束します。 Envoy のユニバーサル データ プレーン API は、これが実際にどのように機能するかを示す一例です。

基本的に、コントロール プレーンの目的は、最終的にデータ プレーンによって受け入れられるポリシーを設定することです。 より高度なコントロール プレーンでは、一部のシステムのより多くの部分がオペレータから削除され、正しく動作する限り、手動操作の必要性が減ります。

データ プレーンとコントロール プレーン。 データ プレーンとコントロール プレーンの概要

• サービス メッシュ データ プレーン: システム内のすべてのパケット/リクエストに影響します。 アプリケーション/サービスの検出、ヘルスチェック、ルーティング、負荷分散、認証/認可、可観測性を担当します。
• サービス メッシュ コントロール プレーン: サービス ネットワーク内で実行中のすべてのデータ プレーンにポリシーと構成を提供します。 システム上のパッケージ/リクエストには一切触れません。 コントロール プレーンは、すべてのデータ プレーンを分散システムに変えます。

現在のプロジェクトの状況

上記の説明を理解した上で、サービス メッシュ プロジェクトの現在の状態を見てみましょう。

• データプレーン: Linkerd、NGINX、HAProxy、Envoy、Traefik
• コントロールプレーン: Istio、ネルソン、SmartStack

上記の各ソリューションを詳細に分析するのではなく、現在エコシステムに大きな混乱を引き起こしていると思われるいくつかの点について簡単に説明します。

Linkerd は、2016 年初頭にサービス メッシュ用の最初のデータ プレーン プロキシ サーバーの 6 つであり、サービス メッシュ設計モデルに対する認識と注目を高めるという素晴らしい仕事をしてきました。 それから約 2015 か月後、Envoy は Linkerd に加わりました (ただし、彼は XNUMX 年末から Lyft に在籍していました)。 Linkerd と Envoy は、サービス メッシュについて議論するときに最も頻繁に言及される XNUMX つのプロジェクトです。

Istio は 2017 年 XNUMX 月に発表されました。 Istio プロジェクトの目標は、図に示した拡張コントロール プレーンと非常に似ています。 図3。 Envoy for Istio はデフォルトのプロキシです。 したがって、Istio はコントロール プレーンであり、Envoy はデータ プレーンです。 短期間で、Istio は多くの興奮を引き起こし、Envoy の代わりに他のデータ プレーンが統合され始めました (Linkerd と NGINX の両方が Istio との統合を実証しました)。 同じコントロール プレーン内で異なるデータ プレーンを使用できるという事実は、コントロール プレーンとデータ プレーンが必ずしも密接に結合されているわけではないことを意味します。 Envoy の汎用データ プレーン API などの API は、システムの XNUMX つの部分間のブリッジを形成できます。

Nelson と SmartStack は、コントロール プレーンとデータ プレーンの分離をさらに詳しく説明するのに役立ちます。 Nelson は Envoy をプロキシとして使用し、HashiCorp スタックに基づいてサービス メッシュの信頼できるコントロール プレーンを構築します。 ノマドなどSmartStack は、おそらくサービス メッシュの新しい波の最初のものでした。 SmartStack は、HAProxy または NGINX を中心にコントロール プレーンを構築し、データ プレーンのサービス メッシュからコントロール プレーンを分離する機能を実証します。

サービス メッシュを使用したマイクロサービス アーキテクチャは（当然のことですが）ますます注目を集めており、ますます多くのプロジェクトやベンダーがこの方向に取り組み始めています。 今後数年間で、データ プレーンとコントロール プレーンの両方で多くの革新が見られ、さまざまなコンポーネントがさらに混在することになるでしょう。 最終的には、マイクロサービス アーキテクチャは、運営者にとってより透明で魔法のような (?) ものになるはずです。
願わくばイライラが減りますように。

重要なポイント

• サービス メッシュは、データ プレーンとコントロール プレーンという XNUMX つの異なる部分で構成されます。 どちらのコンポーネントも必要であり、これらがなければシステムは動作しません。
• コントロール プレーンについては誰もがよく知っていますが、現時点では、コントロール プレーンはあなたである可能性があります。
• すべてのデータ プレーンは、機能、パフォーマンス、構成可能性、拡張性に関して相互に競合します。
• すべてのコントロール プレーンは、機能、構成可能性、拡張性、使いやすさの点で互いに競合します。
• XNUMX つのコントロール プレーンに適切な抽象化と API を含めることができるため、複数のデータ プレーンを使用できます。

出所： habr.com