サービス メッシュ: すべてのソフトウェア エンジニアが最も注目されているテクノロジについて知っておくべきこと

ノート。 翻訳。: サービス メッシュは、ロシア語への安定した翻訳がまだ確立されていない現象です (2 年以上前、私たちは「サービス用メッシュ」というオプションを提案しましたが、少し後に一部の同僚が「サービスふるい」という組み合わせを積極的に推進し始めました)。 このテクノロジーに関する絶え間ない話題により、マーケティングと技術的な要素が密接に絡み合いすぎる状況が生じています。 元の用語の作成者の XNUMX 人が作成したこの素晴らしい資料は、エンジニアやその他の人々に明確さを提供することを目的としています。

コミックから セバスティアン・カセレス

導入

あなたがバックエンド システム分野で働いているソフトウェア エンジニアであれば、おそらくここ数年で「サービス メッシュ」という用語がすでに心にしっかりと根付いているでしょう。 奇妙な偶然のおかげで、このフレーズはますます業界を席巻しており、これに関連する誇大宣伝やプロモーションのオファーは坂を下る雪玉のように成長しており、勢いが衰える気配はありません。

サービス メッシュは、クラウド ネイティブ エコシステムの曖昧で偏った領域で生まれました。 残念ながら、このことは、この問題をめぐる論争の多くが、「低カロリーの話」から、専門用語を使うとまったくのナンセンスにまで及ぶことを意味します。 しかし、すべてのノイズを排除すると、サービス メッシュには非常に現実的で定義された重要な機能があることがわかります。

この投稿では、サービス メッシュに対する正直で詳細な、エンジニアに焦点を当てたガイドを提供することを目指します。 私は単に質問に答えるだけではありません。 「それは何ですか？」、 - だけでなく "何のために？"と "なぜ今なのか？"。 最後に、なぜこの特定のテクノロジーが (私の意見では) これほど狂った騒動を引き起こしたのかを概説したいと思いますが、それ自体が興味深い話です。

どうですか？

こんにちは、みんな！ 私の名前は ウィリアム・モーガン。 私もクリエイターの一人です リンカード — まさに最初のサービス メッシュ プロジェクトであり、この用語の出現の原因となったプロジェクト サービスメッシュ そのとおりです（ごめんなさい！）。 (翻訳に注意してください。：ところで、2,5年半以上前、この用語が登場した黎明期に、私たちはすでに同じ著者の初期の資料「」を翻訳しました。サービス メッシュとは何ですか? [マイクロサービスを備えたクラウド アプリケーションに] サービス メッシュが必要な理由は何ですか?。「） 私も頭です 浮力 Linkerd や Linkerd などのクールなサービス メッシュを作成するスタートアップです。 ダイビング.

おそらく、私がこの問題に関して非常に偏った主観的な意見を持っていることはご想像いただけると思います。 ただし、偏見を最小限に抑えるように努めます (XNUMX つのセクションを除いて: 「なぜサービス メッシュについてこれほど話題になっているのでしょうか?」、-その中で私はまだ私の先入観を共有します）。 また、このガイドをできるだけ客観的なものにするために最善を尽くします。 具体的な例については、主に Linkerd の経験に依存し、他のサービス メッシュ タイプの実装で私が知っている相違点 (存在する場合) を指摘します。

さて、グッズの話に移りましょう。

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

誇大宣伝にもかかわらず、サービス メッシュの構造は非常に単純です。 これは、サービスの「隣」に配置されたユーザー空間プロキシの束 (「次」とは何かについては後で少し説明します) に、一連の制御プロセスを加えたものです。 プロキシは総称して呼ばれます データプレーン、制御プロセスが呼び出されます。 コントロールプレーン。 データ プレーンはサービス間の呼び出しをインターセプトし、サービスに対して「あらゆる種類のさまざまなこと」を実行します。 したがって、コントロール プレーンはプロキシの動作を調整し、アクセスを提供します。 オペレータを API に接続し、ネットワーク全体を操作および測定できるようにします。

これはどのようなプロキシですか? これはレイヤー 7 対応の TCP プロキシです (つまり、OSI モデルのレイヤー 7 を「考慮に入れる」) HAProxy や NGINX など。 好みに応じてプロキシを選択できます。 Linkerd は、単に名前が付けられた Rust プロキシを使用します。 リンカードプロキシ。 サービスメッシュ専用にまとめました。 他のメッシュは他のプロキシを優先します (Envoy が一般的な選択です)。 ただし、プロキシの選択は単なる実装の問題です。

これらのプロキシ サーバーは何をするのでしょうか? 明らかに、サービスとの間の呼び出しをプロキシします (厳密に言えば、プロキシおよびリバース プロキシとして機能し、受信呼び出しと送信呼び出しの両方を処理します)。 そして、通話に焦点を当てた機能セットを実装しています。 между サービス。 サービス間のトラフィックに重点を置いている点が、サービス メッシュ プロキシと、たとえば API ゲートウェイやイングレス プロキシ (後者は外部からクラスターに入る呼び出しに重点を置いています) との違いです。 (ノート。 翻訳。: Kubernetes 用の既存の Ingress コントローラーの比較については、その多くがすでに述べた Envoy を使用しているを参照してください。 この記事.)

そこで、データプレーンを整理しました。 コントロール プレーンはより単純です。これは、サービス ディスカバリ、TLS 証明書の発行、メトリクスの集約など、データ プレーンが調整された方法で動作するために必要なすべての仕組みを提供する一連のコンポーネントです。データ プレーンはコントロール プレーンに次の情報を通知します。その動作。 さらに、コントロール プレーンは、データ プレーン全体の動作を変更および監視できる API を提供します。

以下は、Linkerd のコントロール プレーンとデータ プレーンの図です。 ご覧のとおり、コントロール プレーンには、プロキシ サーバーからメトリクスを収集する Prometheus インスタンスや、次のような他のコンポーネントを含む、いくつかの異なるコンポーネントが含まれています。 destination (サービスディスカバリ)、 identity (認証局、CA) および public-api (Web および CLI のエンドポイント)。 対照的に、データ プレーンは、アプリケーション インスタンスの隣にある単純なリンカード プロキシです。 これは単なる論理図です。 実際の展開では、各コントロール プレーン コンポーネントの XNUMX つのレプリカと、データ プレーン内に数百または数千のプロキシが存在する場合があります。

(この図の青い四角形は、Kubernetes ポッドの境界を表しています。linkerd-proxy を備えたコンテナーがアプリケーション コンテナーと同じポッド内にあることがわかります。このスキームは次のように呼ばれます。 サイドカーコンテナ.)

サービス メッシュ アーキテクチャには、いくつかの重要な意味があります。 まず、プロキシのタスクはサービス間の呼び出しをインターセプトすることであるため、サービス メッシュは、アプリケーションが特定のサービス セット用に作成された場合にのみ意味を持ちます。 メッシュ 1ことができます モノリスで使用できますが、これは単一のプロキシのために明らかに冗長であり、その機能は需要がありそうにありません。

もう XNUMX つの重要な結果は、サービス メッシュが次のことを必要とすることです。 巨大な プロキシの数。 実際、Linkerd は、すべてのサービスのすべてのインスタンスに linkerd-proxy を接続します (他の実装では、すべてのノード/ホスト/仮想マシンにプロキシを追加します。とにかくそれは大量です)。 このようにプロキシを積極的に使用すると、それ自体でさらに多くの複雑な問題が発生します。

1. データ プレーン内のプロキシは次のとおりである必要があります。 速いこれは、呼び出しごとにプロキシへの呼び出しが XNUMX つあります。XNUMX つはクライアント側で、もう XNUMX つはサーバー側です。
2. プロキシも次のようにする必要があります 小さな и 軽量。 それぞれがメモリと CPU リソースを消費し、この消費量はアプリケーションに応じて直線的に増加します。
3. 多数のプロキシを展開および更新するメカニズムが必要になります。 手動で行うことはできません。

一般に、サービス メッシュは (少なくとも俯瞰的には) 次のようになります。内部のサービス間トラフィックで「何かを行う」一連のユーザー空間プロキシをデプロイし、コントロール プレーンを使用してそれらを監視および管理します。

今度は「なぜ?」という質問をしてみましょう。

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

サービス メッシュのアイデアに初めて出会った人は、少し不安を感じるのも無理はありません。 サービス メッシュ設計は、アプリケーションの遅延を増加させるだけでなく、 消費する リソースと 追加します インフラストラクチャ内の多数の新しいメカニズム。 まずサービス メッシュをセットアップすると、突然、数百 (数千ではないにしても) のプロキシにサービスを提供する必要があることに気づきます。 問題は、誰が自発的にこれを行うのかということです。

この質問に対する答えは XNUMX つの部分に分かれています。 まず、エコシステム内で起こっているいくつかの変化のおかげで、これらのプロキシの導入に関連するトランザクション コストを大幅に削減できます (これについては後で詳しく説明します)。

第二に、このようなデバイスは、システムに追加のロジックを導入するための優れた方法です。 サービス メッシュでは多くの新しい機能を追加できるだけでなく、エコシステムに干渉することなく追加できるためでもあります。 実際、サービス メッシュ モデル全体は次の前提に基づいています。マルチサービス システムでは、何があっても 作る 個別のサービス、トラフィック それらの間 機能を追加するのに最適なポイントです。

たとえば、Linkerd (ほとんどのメッシュと同様) では、機能は主に HTTP/2 や gRPC* などの HTTP 呼び出しに焦点を当てています。 この機能は非常に豊富で、次の XNUMX つのクラスに分類できます。

1. に関連する機能 信頼性。 繰り返されるリクエスト、タイムアウト、カナリア アプローチ (トラフィック分割/リダイレクト) など。
2. に関連する機能 モニタリング。 各サービスまたは個別の指示の成功率、遅延、リクエスト量の集計。 サービスのトポロジーマップの構築など
3. に関連する機能 安全。 相互TLS、アクセス制御など

* Linkerd の観点から見ると、gRPC は HTTP/2 と実質的に変わりません。ペイロードで protobuf を使用するだけです。 開発者の観点から見ると、当然ながら、この XNUMX つは異なります。

これらのメカニズムの多くはリクエスト レベルで動作します (したがって、「L7 プロキシ」となります)。 たとえば、Foo サービスが Bar サービスに対して HTTP 呼び出しを行う場合、Foo 側のリンカード プロキシはインテリジェントな負荷分散を実行し、観測されたレイテンシに基づいて呼び出しを Foo から Bar インスタンスにルーティングできます。 必要に応じて (そして冪等である場合には) リクエストを繰り返すことができます。 応答コードやタイムアウトなどを記録できます。 同様に、Bar 側の linkerd-proxy は、リクエストが許可されていない場合、またはリクエストの制限を超えている場合にリクエストを拒否できます。 その側で遅延が記録される場合などがあります。

プロキシは接続レベルでも「何かを行う」ことができます。 たとえば、Foo 側の linkerd-proxy は TLS 接続を開始し、Bar 側の linkerd-proxy はそれを終了でき、双方が互いの TLS 証明書* を検証できます。 これにより、サービス間の暗号化だけでなく、サービスを識別するための暗号的に安全な方法も提供されます。Foo と Bar は、自分たちが誰であるかを「証明」できます。

※「友人の相互」とは、クライアント証明書も検証されている（相互TLS）ことを意味します。 「クラシック」TLS では、たとえばブラウザとサーバーの間では、通常、片側 (サーバー) の証明書のみが検証されます。

リクエスト レベルで動作するか接続レベルで動作するかに関係なく、すべてのサービス メッシュ機能が機能することを強調することが重要です。 運用可能 キャラクター。 Linkerd は、JSON フラグメントにフィールドを追加したり、protobuf を変更したりするなど、ペイロードのセマンティクスを変換できません。 この重要な機能については、後で ESB とミドルウェアについて説明するときに説明します。

これは、サービス メッシュが提供する一連の機能です。 なぜそれらをアプリケーションに直接実装しないのか?という疑問が生じます。 そもそも、なぜわざわざプロキシを使用するのでしょうか?

サービス メッシュが良いアイデアである理由

サービス メッシュの機能は魅力的ですが、その中核となる価値は実際にはその機能にありません。 結局のところ私たちは できる それらをアプリケーションに直接実装します (これがサービス メッシュの起源であることが後でわかります)。 一言でまとめると、サービス メッシュの値は次のようになります。 最新のサーバー ソフトウェアを実行するために重要な機能をスタック全体にわたって一貫した方法で、アプリケーション コードから独立して提供します。.

この提案を分析してみましょう。

«最新のサーバー ソフトウェアを実行するために重要な機能」 パブリック インターネットに接続され、外部からのリクエストを受け入れて短時間内に応答するトランザクション サーバー アプリケーション (Web アプリケーション、API サーバー、その他の最新アプリケーションの大部分など) を作成している場合- そして、それを相互に同期して対話する一連のサービスとして実装する場合、およびこのソフトウェアを常にアップグレードして新機能を追加する場合、および変更プロセス中にこのシステムを正常に動作する状態に維持する必要がある場合には、この中でおめでとうございます。最新のサーバー ソフトウェアを作成されています。 そして、上に挙げたこれらの優れた機能はすべて、実際にあなたにとって重要であることがわかります。 アプリケーションは信頼性があり、安全である必要があり、アプリケーションが何を行っているかを観察できなければなりません。 これらはまさにサービス メッシュが解決する問題です。

(OK、前の段落には、このアプローチがサーバー ソフトウェアを作成する最新の方法であるという私の信念がまだ含まれています。モノリス、「リアクティブ マイクロサービス」、および上記の定義に当てはまらないその他のものの開発を好む人もいます。これらの人々はおそらく、私は彼らの意見が「間違っている」と考えていますが、いずれにしてもサービス メッシュは彼らにとってあまり役に立ちません)。

«スタック全体で均一」 サービス メッシュによって提供される機能は、ミッションクリティカルなだけではありません。 これらは、サービスがどの言語で書かれているか、どのフレームワークが使用されているか、誰が作成したか、どのようにデプロイされたか、その他の開発と使用の微妙な点に関係なく、アプリケーション内のすべてのサービスに適用されます。

«アプリケーションコードから独立した」 最後に、サービス メッシュは、スタック全体にわたって一貫した機能を提供するだけでなく、アプリケーションの編集を必要としない方法でそれを提供します。 構成、更新、運用、メンテナンスなどのタスクを含むサービス メッシュ機能の基本的な基盤は、完全にプラットフォーム レベルに存在し、アプリケーションからは独立しています。 アプリケーションは、サービス メッシュに影響を与えることなく変更できます。 さらに、サービス メッシュはアプリケーションの関与なしに変更できます。

つまり、サービス メッシュは重要な機能を提供するだけでなく、グローバルで統一された、アプリケーションに依存しない方法で提供します。 そのため、サービス メッシュ機能はサービス コードで (たとえば、各サービスに含まれるライブラリとして) 実装できますが、このアプローチでは、サービス メッシュの場合に非常に価値のある均一性と独立性が提供されません。

必要なのは、多数のプロキシを追加することだけです。 これらのプロキシの追加に関連する運用コストについては、近いうちに検討することをお約束します。 しかし、まず立ち止まって、この独立性という考え方をさまざまな視点から見てみましょう。 人々.

サービス メッシュは誰を助けますか?

たとえ不便であっても、テクノロジーがエコシステムの重要な部分になるためには、人々に受け入れられなければなりません。 では、サービス メッシュに興味がある人は誰でしょうか? それを使用することで誰が利益を得ますか?

最新のサーバー ソフトウェアを開発している場合、チームをグループとして大まかに考えることができます。 サービス所有者ビジネス ロジックを共同で開発および実装するメンバー、および プラットフォーム所有者、これらのサービスが動作する内部プラットフォームを開発します。 小規模な組織では、これらは同じメンバーである可能性がありますが、会社が成長するにつれて、これらの役割はより顕著になる傾向があり、さらにはサブ役割に分割されることさえあります... (DevOps の性質の変化についてはここで多くのことが述べられています。マイクロサービスの組織への影響など) n. しかし、今のところ、これらの説明を与えられたものとして受け入れましょう)。

この観点から見ると、サービス メッシュの明らかな受益者はプラットフォームの所有者です。 結局のところ、プラットフォーム チームの最終的な目標は、サービス所有者がビジネス ロジックを実装できる内部プラットフォームを作成し、運用の曖昧な詳細から可能な限り独立した方法で実装することです。 サービス メッシュは、この目標を達成するために重要な機能を提供するだけでなく、サービス所有者に依存関係を課さない方法で提供します。

より間接的な形ではありますが、サービス所有者も恩恵を受けます。 サービス所有者の目標は、ビジネス プロセスのロジックの実装において可能な限り生産性を高めることであり、運用上の問題について心配する必要が少なければ少ないほど良いのです。 たとえば、再試行ポリシーや TLS の実装に対処する代わりに、ビジネス目標のみに集中し、残りはプラットフォームに任せることができます。 これは彼らにとって大きな利点です。

プラットフォームとサービスの所有者間のこのような部門の組織的価値は、過大評価することはできません。 彼女は貢献していると思う основной サービスメッシュの価値への貢献。

初期の Linkerd ファンがサービス メッシュを選択した理由を語ったとき、私たちはこの教訓を学びました。それは、「おしゃべりを最小限に抑える」ことができるからです。 詳細は次のとおりです。ある大企業の社員は、自社のプラットフォームを Kubernetes に移行しました。 アプリケーションは機密情報を扱うため、クラスター間のすべての通信を暗号化する必要がありました。 しかし、数百のサービスと数百の開発チームの存在により、状況は複雑になりました。 全員に連絡を取り、計画に TLS サポートを含めるよう説得するという見通しは、彼らをまったく満足させませんでした。 Linkerd をインストールした後、転送されました 責任 開発者 (これは不必要なトラブルであるという観点から) から、これが最優先事項であるプラットフォーマーまでです。 言い換えれば、Linkerd は技術的な問題ではなく、組織的な問題を解決したということです。

つまり、サービス メッシュは技術的なものではなく、むしろソリューションです。 社会技術的 問題。 （ありがとう シンディ・スリダラン この用語を紹介するために。）

サービス メッシュはすべての問題を解決しますか?

はい。 つまり、いいえ！

上で概説した XNUMX つのクラスの機能 (信頼性、セキュリティ、可観測性) を見ると、サービス メッシュがこれらの問題のいずれに対しても完全な解決策ではないことが明らかです。 Linkerd はリクエストを再発行できますが (冪等であることがわかっている場合)、サービスが永続的に失敗した場合にユーザーに何を返すかを決定することはできません。これらの決定はアプリケーションが行う必要があります。 Linkerd は成功したリクエストの統計を保持できますが、サービスを調べて内部メトリクスを提供することはできません。アプリケーションにはそのようなツールが必要です。 Linkerd は mTLS を構成できますが、本格的なセキュリティ ソリューションにはさらに多くのものが必要です。

サービス メッシュによって提供されるこれらの領域の機能のサブセットは、以下に関連します。 プラットフォームの機能。 これは次のような関数を意味します。

1. ビジネスロジックから独立した。 Foo と Bar の間の呼び出しヒストグラムが構築される方法は、 理由 フーはバーに電話します。
2. 正しく実装するのが難しい。 Linkerd では、再試行は再試行バジェットなどのあらゆる種類の派手なものでパラメータ化されます。 (再試行予算)なぜなら、そのようなことを実装するための洗練されていない真正面からのアプローチは、いわゆる「要求の雪崩」の出現に確実につながるからです。 (リトライの嵐) 分散システムに特有のその他の問題。
3. 均一に塗布すると最も効果的です。 TLS メカニズムは、あらゆる場所に適用されて初めて意味を持ちます。

これらの機能は (アプリケーション レベルではなく) プロキシ レベルで実装されるため、サービス メッシュはこれらの機能を プラットフォーム、アプリケーションではありません。 したがって、サービスがどの言語で書かれているか、どのようなフレームワークを使用しているか、誰がどのような理由でサービスを書いたかは関係ありません。 プロキシはこれらすべての詳細の外部で動作し、構成、更新、運用、メンテナンスなどのタスクを含むこの機能の基本的な基盤はもっぱらプラットフォーム レベルにあります。

サービスメッシュ機能の例

要約すると、サービス メッシュは、信頼性、可観測性、セキュリティの完全なソリューションではありません。 これらの領域の範囲には、サービス所有者、運用/SRE チーム、およびその他の企業エンティティの参加が必要です。 サービス メッシュは、これらの各領域に対してプラットフォーム レベルの「スライス」のみを提供します。

なぜ今サービス メッシュが人気になっているのでしょうか?

ここまでで、あなたはおそらく次のように疑問に思っているでしょう。サービス メッシュがそれほど優れているのであれば、なぜ XNUMX 年前に何百万ものプロキシをスタックにデプロイし始めなかったのでしょう?

この質問に対するありきたりな答えがあります。XNUMX 年前は誰もがモノリスを構築しており、サービス メッシュを必要とする人は誰もいませんでした。 これは真実ですが、私の意見では、この答えは要点を外しています。 XNUMX 年前でさえ、大規模システムを構築するための有望な方法としてのマイクロサービスの概念は広く議論され、Twitter、Facebook、Google、Netflix などの企業で適用されていました。 少なくとも私が接した業界では、たとえそれが非常に困難だったとしても、マイクロサービスは大規模システムを構築する「正しい方法」であるというのが一般的な見方でした。

もちろん、XNUMX 年前にもマイクロサービスを運用している企業はありましたが、サービス メッシュを形成するためにあらゆる場所にプロキシを配置していたわけではありません。 しかし、よく見ると、彼らも同様のことを行っていました。これらの企業の多くは、ネットワーク通信に特別な内部ライブラリ (シック クライアント ライブラリと呼ばれることもあります) の使用を必要としていました。 ファットクライアントライブラリ).

Netflix には Hysterix があり、Google には Stubby があり、Twitter には Finagle ライブラリがありました。 たとえば、Finagle は Twitter 上のすべての新しいサービスに必須でした。 クライアント側とサーバー側の両方の接続を処理し、繰り返しのリクエストを許可し、リクエストのルーティング、負荷分散、測定をサポートしました。 これにより、サービスが何をしていたかに関係なく、Twitter スタック全体にわたって一貫した信頼性と可観測性の層が提供されました。 もちろん、これは JVM 言語でのみ機能し、アプリケーション全体で使用する必要があるプログラミング モデルに基づいていました。 ただし、その機能はサービス メッシュとほぼ同じでした。 (実際、Linkerd の最初のバージョンは、単に Finagle をプロキシ形式でラップしたものでした。)

したがって、XNUMX 年前には、マイクロサービスだけでなく、今日サービス メッシュが解決しているのと同じ問題を解決する特別なプロト サービス メッシュ ライブラリもありました。 ただし、当時はサービス メッシュ自体が存在していませんでした。 彼女が現れるまでには、もう XNUMX 回シフトする必要がありました。

そして、ここに、過去 10 年間に起こった別の変化に隠された、より深い答えがあります。それは、マイクロサービスの導入コストが劇的に下がったことです。 XNUMX 年前にマイクロサービスを使用していた上記の企業 (Twitter、Netflix、Facebook、Google) は、巨大な規模と膨大なリソースを持った企業でした。 彼らは、大規模なマイクロサービスベースのアプリケーションを構築、展開、運用する必要があるだけでなく、その能力も持っていました。 Twitter エンジニアがモノリシックからマイクロサービスへのアプローチに移行するために注いだエネルギーと努力は驚くべきものです。 (公平を期すために、それが成功したという事実も同様です。) このような種類のインフラストラクチャ戦略は、当時の中小企業には不可能でした。

現在に早送りしてください。 現在、マイクロサービスと開発者の比率が 5:1 (あるいはそれさえも) のスタートアップ企業もあります。 10:1）、そしてさらに、彼らはそれらにうまく対処します！ 5 人のスタートアップが 50 個のマイクロサービスを簡単に運用できる場合、実装コストが明らかに削減されたことになります。

Monzo には 1500 のマイクロサービス。 各行は、トラフィックを許可する規定のネットワーク ルールです。

マイクロサービスの運用コストの劇的な削減は、次の XNUMX つのプロセスの結果です。 コンテナの人気が高まる и オーケストレーター。 これはまさに、サービス メッシュの出現に何が寄与したのかという質問に対する深い答えです。 Kubernetes と Docker という同じテクノロジーにより、サービス メッシュとマイクロサービスの両方が魅力的になりました。

なぜ？ さて、Docker は XNUMX つの大きな問題、つまりパッケージ化の問題を解決します。 Docker は、アプリケーションとその (ネットワーク以外の) ランタイム依存関係をコンテナーにパッケージ化することで、アプリケーションをどこでもホストして実行できる交換可能なユニットに変えます。 同時に操作が大幅に簡素化されます 多言語 スタック: コンテナーはデプロイメントと運用の目的において実行のアトミックな単位であるため、JVM、Node、Go、Python、Ruby アプリケーションなど、その中に何があるかは関係ありません。 起動するだけで完了です。

Kubernetes はすべてを次のレベルに引き上げます。 現在、「実行するもの」とそれらを実行するマシンが大量にあるため、それらを相互に関連付けることができるツールが必要です。 広い意味では、Kubernetes に多数のコンテナと多数のマシンを与え、それらを相互にマッピングします (もちろん、これは動的で常に変化するプロセスです。新しいコンテナがシステム内を移動し、マシンが起動および停止します)など。ただし、Kubernetes はこれらすべてを考慮します)。

Kubernetes が構成されたら、100 つのサービスをデプロイして運用するのにかかる時間コストは、XNUMX 個のサービスをデプロイして運用するのにかかるコストとほとんど変わりません (実際、XNUMX 個のサービスでもほぼ同じです)。 多言語実装を促進するパッケージング メカニズムとしてこのコンテナーに追加すると、さまざまな言語で書かれたマイクロサービスの形式で実装された新しいアプリケーションのホストが得られます。これは、まさにサービス メッシュが非常に適した種類の環境です。

そこで、なぜサービス メッシュという考え方が今普及しているのかという疑問に対する答えにたどり着きます。Kubernetes がサービスに提供する均一性は、サービス メッシュが直面する運用上の課題に直接当てはまります。 プロキシをコンテナにパッケージ化し、可能な限りどこにでもプロキシを貼り付けるタスクを Kubernetes に与えれば、出来上がりです。 その結果、サービス メッシュが得られ、そのデプロイメントの仕組みはすべて Kubernetes によって管理されます。 (少なくとも俯瞰的に見ると。もちろん、このプロセスには多くの微妙な違いがあります。)

要約すると、サービス メッシュが XNUMX 年前ではなく現在普及している理由は、Kubernetes と Docker が大幅に増加しただけでなく、 必要 これにより、アプリケーションの実装が多言語マイクロサービスのセットとして簡素化されましたが、大幅に削減されました。 費用 その運用のために、サイドカー プロキシ フリートを展開およびサポートするためのメカニズムを提供します。

サービス メッシュについてこれほど話題になっているのはなぜですか?

警告: このセクションでは、あらゆる種類の仮定、推測、捏造、内部情報を利用します。

「サービス メッシュ」で検索すると、大量のリサイクルされた低カロリー コンテンツ、奇妙なプロジェクト、そしてエコー チェンバーにふさわしい歪みの万華鏡が見つかります。 優れた新しいテクノロジであればこれを実現できますが、サービス メッシュの場合、問題は特に深刻です。 なぜ？

まあ、それの一部は私のせいです。 私は、数え切れないほどのブログ投稿やこのような記事を目にする機会があるたびに、Linkerd とサービス メッシュを宣伝するために懸命に取り組んできました。 でも、私はそんなに力がありません。 この質問に本当に答えるには、全体的な状況について少し話す必要があります。 そして、XNUMX つのプロジェクトに触れずにそれを語ることはできません。 イスティオ は、Google、IBM、Lyft が共同開発したオープンソースのサービス メッシュです。

(XNUMX 社の役割は大きく異なります。Lyft の関与は名ばかりのようです。彼らは Envoy の作成者ですが、Istio の開発に使用または参加していません。IBM は Istio の開発に関与し、使用しています。Google は Istio の開発に積極的に関与しています)開発中ですが、私の知る限り実際には使用していません。)

Istio プロジェクトは XNUMX つの点で注目に値します。 まず、特に Google がこのプロモーションに注力している多大なマーケティング努力があります。 今日サービス メッシュの概念を知っているほとんどの人は、最初に Istio を通じてそれを知ったと推測します。 XNUMX つ目は、Istio の評判が悪かったことです。 この件に関して、私は明らかに利害関係者ですが、可能な限り客観的であり続けようと努めていますが、依然として協力することはできません。 マーク весьма ネガティブ 気分、あまり特徴的ではありません (ユニークではありませんが、systemd が思い浮かびますが、 比較 行われた すでに 繰り返し...) オープンソース プロジェクトの場合。

(実際には、Istio には複雑さと UX だけでなく、パフォーマンスにも問題があるようです。たとえば、 Linkerd のパフォーマンス評価サードパーティの調査では、研究者らは、Istio のテール レイテンシーが Linkerd の 100 倍高い状況や、Istio が完全に動作しなくなったにもかかわらず Linkerd が正常に機能し続けるリソース不足の状況を発見しました。)

なぜこれが起こったのかについての私の理論はさておき、サービスメッシュに関する圧倒的な興奮はGoogleの参加によって説明されると私は信じています。 つまり、次の XNUMX つの要素の組み合わせです。

1. Google による Istio の押し付けがましいプロモーション。
2. プロジェクトに対するそれに対応する不承認的で批判的な態度。
3. 最近、Kubernetes の人気が急速に高まり、その記憶はまだ新しいです。

これらの要因が組み合わさって、理性的な判断能力が弱まり、奇妙な多様性だけが残る、呆気なく酸素のない環境が生み出されます。 チューリップマニア.

リンカードの観点からすると、これは...私が言うところの「混合の祝福」です。 つまり、サービス メッシュが、Linkerd が最初に開始された 2016 年にはなかった形で主流になったことは素晴らしいことですが、このプロジェクトに人々の注目を集めるのは非常に困難でした。 今ではそのような問題はありません！ しかし、悪いニュースは、今日のサービス メッシュの状況が非常に混乱しており、どのプロジェクトが実際にサービス メッシュ カテゴリに属する​​かを理解することがほぼ不可能であるということです (特定のユースケースにどのプロジェクトが最適であるかを理解することはおろか)。 これは間違いなく誰にとっても問題です (そして、Linkerd はまだ普遍的なソリューションではないため、Istio または別のプロジェクトの方が Linkerd よりも適しているケースも確かにあります)。

Linkerd 側の戦略は、ノイズを無視し、実際のコミュニティの問題の解決に集中し続け、基本的に誇大宣伝が静まるのを待つことでした。 最終的には、誇大宣伝は静まり、落ち着いて仕事を続けることができます。

それまでの間、私たちは皆、少し辛抱しなければなりません。

サービス メッシュは、しがないソフトウェア エンジニアである私にとって役立つでしょうか?

次のアンケートは、この質問に答えるのに役立ちます。

ビジネス ロジックの実装のみに携わっていますか? この場合、サービス メッシュは役に立ちません。 もちろん、興味があるかもしれませんが、理想的には、サービス メッシュは環境内の何にも直接影響を与えるべきではありません。 お金をもらって仕事をし続けてください。

Kubernetes を使用している企業でプラットフォームをサポートしていますか? はい、この場合はサービス メッシュが必要です (もちろん、モノリスまたはバッチ処理を実行するためだけに K8 を使用している場合は別ですが、なぜ K8 が必要なのかを尋ねたいと思います)。 最終的には、さまざまな人によって作成された多数のマイクロサービスが作成される可能性があります。 これらはすべて相互に影響し合い、ランタイムの依存関係が複雑に絡み合っているため、それらすべてに対処する方法を見つける必要があります。 Kubernetes を使用すると、「自分用」のサービス メッシュを選択できます。 これを行うには、その機能と特徴を理解し、利用可能なプロジェクトが自分に適しているかどうかという質問に答えてください (Linkerd から調査を始めることをお勧めします)。

Kubernetesを使わずマイクロサービスを使っている会社のプラットフォーム企業ですか？ この場合、サービス メッシュは役に立ちますが、その使用は簡単ではありません。 もちろんできます 模倣する サービス メッシュは多数のプロキシを配置することで機能しますが、Kubernetes の重要な利点はデプロイメント モデルにあります。これらのプロキシを手動で維持するには、より多くの時間、労力、費用が必要になります。

あなたはモノリスを扱う企業でプラットフォームの責任者ですか? この場合、おそらくサービス メッシュは必要ありません。 明確に定義され、ほとんど変化しない対話パターンを持つモノリス (またはモノリスのコレクション) を操作している場合、サービス メッシュが提供できるものはほとんどありません。 だから、ただ無視して、悪い夢のように消え去ることを望むことができます...

まとめ

おそらく、サービス メッシュはまだ「世界で最も誇大宣伝されているテクノロジー」と呼ばれるべきではありません。この疑わしい名誉はおそらくビットコインまたは AI に属します。 彼女はおそらくトップXNUMXに入るでしょう。 しかし、ノイズの層を切り抜けると、サービス メッシュが Kubernetes 上でアプリケーションを構築する人々に真のメリットをもたらすことが明らかになります。

Linkerd を Kubernetes クラスター (またはラップトップ上の Minikube) にインストールして試してみてください。 約60秒かかります, そして私が何を言っているのかは自分の目で確認してください。

よくある質問

— サービス メッシュを無視すると、サービス メッシュは消えてしまいますか?
— 残念ですが、サービス メッシュは長い間私たちに提供されてきました。

- でもサービス メッシュは使いたくない!
- そうですね、その必要はありません！ 上記の私のアンケートを読んで、少なくともその基本を理解しておくべきかどうかを理解してください。

— これは古き良きESB/ミドルウェアに新しいソースを加えたものではないでしょうか？
— サービス メッシュは、セマンティック ロジックではなく、操作ロジックを扱います。 これが主な欠点でした エンタープライズ サービス バス (ESB）。 この分離を維持することで、サービス メッシュが同じ運命を避けることができます。

— サービス メッシュは API ゲートウェイとどう違うのですか?
— このトピックに関する記事は XNUMX 万件あります。 Googleで調べてみてください。

— Envoy はサービス メッシュですか?
- いいえ、Envoy はサービス メッシュではなく、プロキシ サーバーです。 これは、サービス メッシュを整理するために使用できます (汎用プロキシであることなど)。 しかし、それ自体はサービス メッシュではありません。

— Network Service Mesh はサービス メッシュですか?
- いいえ。 名前にもかかわらず、これはサービス メッシュではありません (マーケティングの奇跡が好きですか?)。

— サービス メッシュは、メッセージ キュー ベースのリアクティブ非同期システムに役立ちますか?
- いいえ、サービス メッシュは役に立ちません。

— どのサービス メッシュを使用すればよいですか?
- リンカード、 非常に簡単、考える必要のない。

- 記事は最悪です！ / 作者様大歓迎！
— 友達全員が見られるように、リンクを共有してください。

感謝

タイトルから推測できるかもしれませんが、この記事はジェイ・クレプスの素晴らしい論文「ログ: リアルタイム データの統一的な抽象化についてすべてのソフトウェア エンジニアが知っておくべきこと」 XNUMX 年前に Linked In でインタビューしたときにジェイに会ったのですが、それ以来、彼は私にとってインスピレーションの源です。

私は自分のことを「Linkerd 開発者」と呼びたいのですが、実際にはプロジェクトの README.md ファイルの管理者に近いです。 Linkerd は今日作業中です 非常に, 非常に, 非常に много このプロジェクトは、貢献者とユーザーからなる素晴らしいコミュニティの参加がなければ実現しなかったでしょう。

最後に、Linkerd の作成者に特別な感謝を申し上げます。 オリバー・グールド (プリムス・インター・パレス)彼は、何年も前に私と一緒に、サービス メッシュに関するこのすべての大騒ぎに真っ向から飛び込みました。

翻訳者からの追伸

私たちのブログもお読みください:

• «サービス メッシュとは何ですか? [マイクロサービスを備えたクラウド アプリケーションに] サービス メッシュが必要な理由は何ですか?";
• «Traefik 2.0: TCP サポートと新しい Web インターフェイスを備えたサービス メッシュのアップデート";
• «Maesh - Traefik の作者による Kubernetes 用の新しいシンプルなサービス メッシュ";
• «Istio を使用したマイクロサービスに戻ります。 パート1";
• «Conduit - Kubernetes 用の軽量サービス メッシュ'。

出所： habr.com