サービスメッシュが必要なのは誰ですか?

[[433819]]

クラウド ネイティブ時代の到来により、マイクロサービス アーキテクチャを使用する友人たちは、新しい技術用語である「サービス メッシュ」(今ではもう新しい用語ではありません) を聞き始めました。

新しいテクノロジーを学ぶときには、常に 2 つの問題が生じます。

• それは何ですか？
• なぜそれが必要なのですか?

この記事では、これら 2 つの問題に焦点を当て、Service Mesh の一般的な理解を深めることを目的としています。

最後に、核となる考えが浮かび上がります。

サービスメッシュが必要なのは誰ですか?

1. サービスメッシュとは

Service Meshは国内では「サービスグリッド」と翻訳されています。

最も広く受け入れられている定義は、Buoyant の CEO である William Morgan によるものです。

サービス メッシュは、サービス間通信を処理するための特殊なインフラストラクチャ レイヤーです。 Cloud Native には、リクエストを確実に配信する役割を担う複雑なサービス トポロジがあります。実際には、サービス メッシュは通常、アプリケーションが認識することなくアプリケーション コードと一緒にデプロイされる軽量ネットワーク プロキシのセットとして実装されます。

この定義は少し複雑に思えるかもしれません。キーワードを抽出すれば、もっと明確になるかもしれません:

• サービス間通信のためのインフラストラクチャ層（ポジショニング）
• 複雑なサービストポロジーでリクエストを確実に配信する（目標）
• 軽量ネットワークプロキシ実装（実装）
• アプリケーション非対応（機能）

ポジショニング、目標、特徴の観点から、私たちは何を考えていますか？

そうです、TCP/IP プロトコルです!

クラウドネイティブ マイクロサービスの場合、サービス メッシュは TCP/IP プロトコルと同等のインフラストラクチャであり、ネットワーク呼び出し、ルーティング管理、電流制限、サービス間の監視を担当します。

Service Mesh を使用すると、Spring Cloud、Dubbo などのアプリケーションを作成するときに、サービス呼び出しのフレームワークの適応とアップグレードについて心配する必要がなくなります。過去にアプリケーションを作成したときと同じように、基本的に TCP/IP 層の問題に注意を払う必要がなくなりました。

さらに、実装の観点から、この軽量ネットワーク プロキシ実装は、サイドカー (実際にはプロキシ) と呼ばれることがよくあります。

Service Mesh のアーキテクチャを見てみましょう。

(画像は https://philcalcado.com/2017/08/03/pattern_service_mesh.html より)

サービス メッシュは、次の 2 つのコア部分で構成されます。

• データプレーン。 Sidecar をデータ プレーン ノードとして使用すると、アプリケーションに対して完全に透過的になり、すべての受信トラフィックと送信トラフィックが Sidecar を通過します。
• コントロールプレーン。集中型コントロール プレーンは、統合された上位層の運用および保守ポータルを提供します。すべての Sidecar プロキシ コンポーネントは、コントロール プレーンと対話して、ネットワーク トポロジ戦略を更新し、単一マシンのデータを報告します。

2. なぜサービスメッシュが必要なのか?

新しい技術の出現と導入は、既存の問題を解決することを目的としていなければなりません。 Service Mesh を導入する理由は、既存のマイクロサービス フレームワークに存在する問題を解決するためです。

Service Mesh が解決する問題をより深く理解するために、Phil Calçado の記事「Pattern: Service Mesh」と合わせて、サービス開発パターンと Service Mesh テクノロジーの進化を振り返ってみましょう。

1) オリジナルコミュニケーション時代1.0

原始的な通信時代 (TCP プロトコルの出現以前) では、パケット損失、障害、再試行など、ネットワーク通信が直面する一連のフロー制御の問題を処理するサービスが必要でした。したがって、ビジネス ロジック コードに加えて、ネットワーク転送の問題に対処する方法も考慮する必要があります。

2) オリジナルコミュニケーション時代2.0

このビジネスに依存しないネットワーク伝送問題を解決するために、TCP/IP プロトコルが登場し、フロー制御の問題のこの部分をオペレーティング システム レベルに「沈め」ました。ビジネス開発では、ネットワーク伝送の問題に集中する必要がなくなり、ビジネス ロジックの開発に集中できるようになります。

3) マイクロサービス サービス ガバナンス 1.0

マイクロサービスアーキテクチャの推進により、モノリシックサービスは徐々に分散システムへと発展し、サービス間の呼び出しはますます複雑になっています。

現時点では、サービスの登録と検出、電流制限、回路遮断など、マイクロサービス アーキテクチャにおける「フロー制御」の問題が引き続き発生しています。したがって、ビジネス ロジック コードでは、このようなビジネスとは関係のない問題を解決するためのモジュールをいくつか開発する必要があります。

4) マイクロサービス ガバナンス 2.0 - マイクロサービス フレームワーク

マイクロサービス アーキテクチャにおける一般的な通信問題を解決するために、さまざまなマイクロサービス フレームワークが登場し始めました。このような一般的な問題を解決するために、Spring Cloud や Dubbo などのフレームワークが作成されました。

これらのフレームワークは、サービス登録と検出、電流制限、クライアント依存パッケージの形式での回路遮断などの処理ロジックからビジネス開発を保護します。比較的堅牢なマイクロサービス アーキテクチャは、単純な構成だけで完成できます。

5) マイクロサービスガバナンス3.0 — サービスメッシュ

マイクロサービス フレームワークは一般的なサービス ガバナンスの問題を解決できますが、実際には次のような欠点もあります。

• クライアント依存パッケージは、開発言語に強く結び付けられることになります。より主流のマイクロサービス フレームワークは基本的に Java で実装されています。ビジネスアーキテクチャ内に他言語のサービスが存在する場合、同様の利便性を享受することは難しくなります。異なる言語用のマイクロサービス フレームワークを開発するのは、比較的コストがかかり、保守も困難です。マイクロサービス フレームワークの開発言語によって制限されるのは、明らかに良いことではありません。
• クライアント依存パッケージの形式は、ビジネスが依存パッケージのアップグレードと適応に注意を払う必要があることを意味します。複雑なプロジェクトの中には、多くのパッケージに依存しており、パッケージの競合に対処する必要があるものもあり、これは頭痛の種です。同時に、フレームワーク ライブラリのアップグレードはサービスに対して透過的ではなく、ビジネスを促進することによって完了する必要があります。ビジネス開発者とフレームワークメンテナンスの学生は非常に疲れています、ため息〜〜

サービス ガバナンスを「シンク」し、TCP/IP などのアプリケーション サービスから完全に切り離すことができれば、上記の問題を解決できます。

そこで、Linkerd、Envoy、NginxMeshに代表されるサイドカーモードのサービスメッシュ製品が誕生しました。サービスの登録と検出、電流制限、回路遮断、監視などの機能など、マイクロサービス通信の一般的な問題をサイドカー サービスに分離し、サービス間のネットワーク通信を完全に引き継ぎ、ビジネス アプリケーションから完全に切り離して独立して実行します。これにより、従来のクライアント側マイクロサービス フレームワークの問題点が解決されます。

その後、istiol に代表されるサービス メッシュ製品では、管理、保守、更新を容易にするために、サイドカー モデル (istio のサイドカーは Envoy を使用) に基づく統合コントロール プレーンが導入されました。

この時点で、「なぜサービス メッシュが必要なのか」について深く理解できたと思います。上記の進化の歴史に基づいて、現在のマイクロサービス サービス ガバナンス ソリューションである Service Mesh が誕生しました。

3. サービス メッシュが必要なのは誰ですか?

Service Mesh はこんなに優れているので、迷わずに使用できるのでしょうか?実際のところ、答えはノーです。

なぜ？

実際のところ、サービス メッシュには、サービス ガバナンスにおける新しい「機能的」な特徴はそれほど多くありません。より魅力的な基本機能は次のとおりです。

• 自然なクラウドネイティブコンポーネント
• 独立してアップグレードおよび進化が可能
• 言語の独立性

しかし、現時点では、比較的成熟した本番環境では、Dubbo、Spring Cloud、自社開発のマイクロサービス フレームワークのいずれであっても、比較的成熟しており、ガバナンス機能が比較的完全であるため、アップグレードや拡張が必要になることはほとんどありません。

特に、サービス登録と検出のコア機能が変更されていない場合、一部の拡張機能のアップグレードでは、基本的にすべてのバックエンド サービスをアップグレードして適応させる必要はありません。

そうすると、「独自にアップグレードして進化できる」という特徴はそれほど説得力がなく、少なくとも、それほど大きな「ビジネス価値」によって推進されているわけではない。

では、Service Mesh を導入するのに適した人は誰でしょうか?

1) クラウドネイティブをベースとした新事業（新生産ライン）

ゼロからスタートし、クラウドネイティブ テクノロジー スタックをベースとする新しい企業は、Service Mesh を直接導入するのに非常に適しています。

クラウドネイティブ サービスの登録と検出、サービス ガバナンス、クラウドネイティブの可観測性はすべて、サービス メッシュを中心に展開されます。ビジネス開発では、ビジネスに関係のないインフラストラクチャの反復を心配することなく、ビジネスの反復に集中できるようになります。

もちろん、クラウド ネイティブ テクノロジー スタックを深く理解しているインフラストラクチャ保守担当者も不可欠です。

2) 多様なテクノロジースタックを持つ成熟した企業

比較的成熟した企業の場合、マイクロサービス フレームワーク、構成センター、フルリンク追跡システムなどは既に比較的成熟しており、ガバナンス機能も比較的完備しているため、アップグレードや拡張が必要になることはほとんどありません。

そのため、サービス メッシュの導入は、主に「テクノロジー スタックの多様化」の要求に基づいています。

いわゆる「テクノロジー スタックの多様化」には次のものが含まれます。

• ビジネスシナリオにはさまざまな特性があります。たとえば、Web プロジェクトでは Java を使用し、バックエンドの高性能コンピューティング サービスでは go/c++ を使用し、ビジネス リクエストのボリュームが急激に変動するビジネスでは Faas を使用し、フロントエンドのマイクロサービスでは nodejs を使用します。
• 特別な採用ニーズがあります。

「テクノロジー スタックの多様性」によってもたらされた複雑なアーキテクチャは、従来のマイクロサービス フレームワークに大きな課題をもたらしました。クライアント側モード (強力な言語バインディング) のマイクロサービス フレームワークでは、このような複雑な要件を満たすことができなくなりました。

したがって、クラウドネイティブ アーキテクチャでは、Service Mesh の「言語に依存しない」機能により、異種アプリケーションの実現可能性が高まり、ユーザーは複雑な環境と複雑な依存関係を持つアプリケーションを迅速にオーケストレーションできるようになります。

4. まとめ

この記事では、「サービス メッシュとは何か」と「なぜサービス メッシュが必要なのか」という 2 つのトピックを中心に、サービス メッシュの概要を説明します。

最後に、本番実装の実際の状況に基づいて、Service Mesh 実装に本当に適したシナリオについて考えました。

皆さんにとって刺激となることを願っています。