サービスメッシュ必読ガイド - 第2版: 次世代のマイクロサービス開発

原文(投稿日：2021/09/09)へのリンク

この数年で、サービスメッシュテクノロジーは長い道のりを歩んできました。サービスメッシュは、さまざまな組織によるクラウドネイティブの採用において重要な役割を果たしています。接続性、信頼性、可観測性、セキュリティの4つの主要なタイプの機能を提供することにより、サービスメッシュは IT 組織のテクノロジーとインフラストラクチャの最新化の取り組みのコアコンポーネントになりました。サービスメッシュは、開発と運用チームにインフラストラクチャレベルでこれらの機能を実装できるため、アプリケーションチームは、横断的な非機能要件に関して車輪の再発明を行う必要がありません。

2020年2月にこの記事の初版を公開して以来、サービスメッシュテクノロジは大幅なイノベーションを経て、進化し続けるサービスメッシュス分野にいくつかの新しいアーキテクチャトレンド、テクノロジ機能、およびサービスメッシュプロジェクトが登場しました。

昨年、サービスメッシュプロダクトは、Kubernetes プラットフォームでホストされていないために Kubernetes のみでしかサービスメッシュのメリットを得られなかったアプリのソリューションからそれをはるかに超えるものに進化しました。すべての組織がすべてのビジネスアプリと IT アプリを Kubernetes クラウドプラットフォームに移行しているわけではありません。そのため、サービスメッシュの開始以来、このテクノロジーがさまざまな IT インフラストラクチャ環境で機能する必要がありました。

マイクロサービスアーキテクチャの採用が進むにつれ、アプリケーションシステムは、クラウドプロバイダ、インフラストラクチャ (Kubernetes、VM、ベアメタルサーバ)、地域、さらにはサービスメッシュ統合環境で管理されるワークロードの種類が明確に分離および分散されています。

まず、サービスメッシュがどのようにして生まれたのかという歴史から始めましょう。

2016年頃「サービスメッシュ」という用語は、マイクロサービス、クラウドコンピューティング、DevOpsの分野に登場しました。楽天的なあるチームは、2016年にこの用語を使用して彼らの製品である Linkerd を説明しました。コンピューティングの多くの概念と同様に、実際には、関連するパターンとテクノロジーの長い歴史があります。

サービスメッシュの登場は、主に IT ランドスケープの最悪の状況によるものでした。開発者は、複数言語 (ポリグロット) アプローチを使用して分散システムの構築を開始し、動的なサービスディスカバリーを必要としていました。運用は一時的なインフラストラクチャの使用を開始し、避けられない通信障害を適切に処理し、ネットワークポリシーを適用したいと考えていました。プラットフォームチームは、Kubernetes などのコンテナオーケストレーションシステムの採用を開始し、Envoy などの最新の API 駆動のネットワークプロキシを使用して、システムおよびシステム周辺のトラフィックを動的にルーティングしたいと考えていました。

この記事は、次のようなソフトウェアアーキテクトやテクニカルリーダーに関連する質問に答えることを目的としています。サービスメッシュとは何でしょうか? サービスメッシュは必要でしょうか? さまざまなサービスメッシュ製品を評価するにはどうすればよいでしょうか?

ページの下部にある[目次]メニューを使って、このガイドをすばやくナビゲートできます。

サービスメッシュパターン

サービスメッシュパターンは、分散ソフトウェアシステムのすべてのサービス間通信の管理に重点を置いています。

コンテキスト

このパターンのコンテキストは2つあります: 1つは、エンジニアは、複数の (理想的には単一目的で独立してデプロイ可能な) サービスを一緒に構成することでアプリケーションを構築するマイクロサービスアーキテクチャパターンを採用しています。次に、組織は、コンテナ (Dockerなど)、オーケストレーター (Kubernetesなど)、ゲートウェイなどのクラウドネイティブプラットフォームテクノロジーを採用しています。

意図

サービスメッシュパターンが解決しようとする問題は次のとおりです:

• サービスディスカバリー、ルーティング、およびアプリケーションレベル (レイヤー 7) の非機能通信要件を処理するために、言語固有の通信ライブラリを個々のサービスにコンパイルする必要がなくなります。
• 外部サービスのネットワークロケーション、セキュリティクレデンシャル、サービス品質ターゲットなど、サービス通信構成の外部化。
• 他のサービスのパッシブおよびアクティブな監視を提供します。
• 分散システム全体にポリシーの適用を分散化する。
• 可観測性にデフォルトを提供し、関連データの収集を標準化します。
  • リクエストロギングの有効化
  • 分散トレーシングの構成
  • メトリクスの収集

構造

サービスメッシュパターンは、主に「東西 (east-west)」リモートプロシージャコール (RPC) ベーストラフィックと呼ばれる従来の処理に重点を置いています。データセンタから発信され、サービス間を移動するリクエスト/レスポンスタイプの通信です。これは、外部から発信され、データセンタのエンドポイントやサービスに入る通信である「南北 (north-south)」トラフィックを処理するように設計された API ゲートウェイやエッジプロキシとは対照的です。

サービスメッシュ機能

サービスメッシュの実装は通常、次の機能の1つ以上を提供します:

• ネーミングの正規化と論理ルーティングの追加 (たとえば、コードレベル名「user-service」をプラットフォーム固有の場所「AWS-us-east-1a/prod/users/v4」にマッピングします)
• トラフィックシェーピングとトラフィックシフトの提供
• 通常構成可能なアルゴリズムを使用した負荷分散の維持
• サービスのリリース制御の提供 (カナリアリリースやトラフィック分割など)
• リクエストごとのルーティングの提供 (トラフィックシャドウイング、フォールトインジェクション、デバッグの再ルーティングなど)
• ヘルスチェック、タイムアウト/期限、サーキットブレーカ、リトライ (予算) などのベースラインの信頼性の追加
• 透過的な相互 (mutual) トランスポートレベルセキュリティ (TLS) およびアクセス制御リスト (ACL) などのポリシーを介したセキュリティ強化
• トップラインメトリクス (リクエスト量、成功率、レイテンシー)、分散トレースのサポート、リアルタイムのサービス間通信を「タップ」して検査する機能などの追加の可観測性と監視の提供
• プラットフォームチームが「適切なデフォルト」を構成して、システムを不正な通信からの保護の有効化

サービスメッシュは、下のリストのように4つの領域に分類できる能力があります:

• 接続性
• 信頼性
• セキュリティ
• 可観測性

これらの各領域でサービスメッシュテクノロジーが提供できる機能を見てみましょう。

接続性:

• トラフィック制御 (ルーティング、分割)
• ゲートウェイ (Ingress, Egress)
• サービスディスカバリー
• A/B テスト、カナリア
• サービスタイムアウト、リトライ

信頼性:

• サーキットブレーカー
• フォールトインジェクション/カオステスト

セキュリティ:

• サービス間認証 (mTLS)
• 証明書管理
• ユーザ認証 (JWT)
• ユーザ認可 (RBAC)
• 暗号化

可観測性:

• 監視
• テレメトリ、計測、メトリクス
• 分散トレース
• サービスグラフ

サービスメッシュアーキテクチャ: 覆いの下を見る

サービスメッシュは、データプレーンとコントロールプレーンの2つのハイレベルコンポーネントで構成されています。Envoy Proxy の作者である Matt Klein 氏は「サービスメッシュデータプレーンとコントロールプレーン」のトピックについて優れた詳細を記述しています。

大まかに言えば、データプレーンは「作業を行い」、「ネットワークエンドポイントとの間で送受信されるすべてのネットワークパケットを条件付きで変換、転送、および監視する」責任があります。最新のシステムでは、データプレーンは通常、プロキシ (Envoy、HAProxy、MOSN など) として実装され、各サービスと一緒に「サイドカー」としてアウトプロセスで実行されます。Linkerd は、サービスメッシュサイドカーのユースケース向けに最適化されたマイクロプロキシアプローチを使用しています。

コントロールプレーンは「作業を監視」し、データプレーンのすべての個々のインスタンス (分離されたステートレスサイドカープロキシのセット) を取得して、それらを分散システムに変換します。コントロールプレーンはシステム内のパケット/リクエストに触れませんが、かわりに、人のオペレーターがメッシュで実行中のすべてのデータプレーンにポリシーと構成を提供できるようにします。コントロールプレーンは、データプレーンのテレメトリを収集して一元化し、オペレータがすぐに使用できるようにもします。

コントロールプレーンとデータプレーンを組み合わせると、ポリシーを一元的に定義および管理できるという意味で、両方の長所が得られます。同時に、同じポリシーを分散化された方法で、Kubernetes クラスタの各ポッドにローカルで適用できます。ポリシーは、セキュリティ、ルーティング、サーキットブレーカー、または監視に関連付けることができます。

以下の図は、Istio アーキテクチャのドキュメントから抜粋したものであり、ラベル付けされたテクノロジーは Istio 固有のものですが、コンポーネントはすべてのサービスメッシュ実装に共通です。

Istio アーキテクチャがコントロールプレーンとプロキシデータプレーンがどのように相互作用するか (提供: Istio ドキュメント)

ユースケース

サービスメッシュには有効化またはサポートできるさまざまなユースケースがあります。

動的サービスディスカバリーとルーティング

サービスメッシュは、テスト用のトラフィックシャドウイング (複製)、カナリアリリースおよび A/B タイプの実験用のトラフィック分割など、動的なサービスディスカバリーとトラフィック管理を提供します。

サービスメッシュで使用されるプロキシは、通常「アプリケーション層」を認識します (OSI ネットワークスタックのレイヤー 7 で動作します)。これは、トラフィックルーティングの決定とメトリクスのラベル付けに HTTP ヘッダまたは他のアプリケーション層プロトコルメタデータのデータを利用できることを意味します。

サービス間通信の信頼性

サービスメッシュは、リクエストのリトライ、タイムアウト、レート制限、サーキットブレーカーなど、分野横断的な信頼性要件の実装と実行をサポートします。サービスメッシュは、8つの分散コンピューティングの落とし穴に対処するための補償 (またはカプセル化) によく使用されます。サービスメッシュはワイヤレベルの信頼性サポート (HTTPリクエストの再試行など) のみを提供でき、最終的には、サービスは複数の (べき等ではない) HTTP POST リクエストの回避など関連するビジネスへの影響を担当する必要があることに注意してください。

トラフィックの可観測性

サービスメッシュは、システムで処理されるすべてのリクエストのクリティカルパス上にあるため、リクエストの分散トレース、HTTP エラーコードの頻度、グローバルおよびサービス間のレイテンシなど、追加の「可観測性」を提供することもできます。エンタープライズの分野では非常に使い古されたフレーズですが、システム全体のトラフィックフローの「一括管理」ビューを実装するために必要なすべてのデータをキャプチャする方法として、サービスメッシュが提案されることがよくあります。

通信セキュリティ

サービスメッシュは (x509 証明書を介した) サービス ID の提供、すべての通信が (TLS を介して) 暗号化されていることを確認してアプリケーションレベルのサービス/ネットワークセグメンテーション (「サービス A」が「サービス B」と通信できるが、「サービス C」とはできない）を有効化し、有効なユーザレベルの ID トークンまたは「パスポート」が存在することを確認する、分野横断的なセキュリティ要件の実装と実行もサポートします。

アンチパターン

アンチパターンの使用が出現した場合、それはテクノロジーが成熟している兆候であることがよくあります。サービスメッシュも例外ではありません。

多すぎるトラフィック管理レイヤ (ずっと下まで重なった亀)

このアンチパターンは、開発者がプラットフォームまたは運用チームと調整せず、サービスメッシュを介して現在実装されているコードで既存の通信処理ロジックを増やした場合に発生します。たとえば、サービスメッシュ構成によって提供されるワイヤーレベルのリトライポリシーに加えて、コードにもリトライポリシーを実装しているアプリケーションです。このアンチパターンは、トランザクションの重複などの問題を引き起こす可能性があります。

銀の弾丸のサービスメッシュ

IT では「銀の弾丸」のようなものはありませんが、ベンダーはこのラベルで新しいテクノロジーに油を注ぐように誘惑することがあります。サービスメッシュは、マイクロサービス、Kubernetes などのコンテナオーケストレーター、またはクラウドネットワーキングとのすべての通信の問題を解決するわけではありません。サービスメッシュは、サービス間 (東西) 通信のみを容易にすることを目的としており、サービスメッシュのデプロイと実行には明確に運用コストがかかります。

エンタープライズ・サービス・バス (ESB) 2.0

マイクロサービス以前のサービス指向アーキテクチャ (SOA) 時代に、ソフトウェアコンポーネント間の通信システムのエンタープライズ・サービス・バス (ESB) が実装されました。ESB 時代の過ちの多くが、サービスメッシュを使用して繰り返されるのではないかと懸念する人もいます。

ESB を介して提供される通信の集中管理には明らかな価値がありました。しかし、テクノロジの開発はベンダーによって推進されたため、ESB 間の相互運用性の欠如、業界標準の特注拡張 (WS-* 準拠のスキーマへのベンダー固有構成の追加など) などの複数の問題と高コストが発生しました。ESB ベンダーは、ビジネスロジックの通信バスへの統合や密結合を妨げることもしませんでした。

ビッグバン・デプロイメント

IT 全体では、デプロイメントへのビッグバンアプローチが最も管理しやすいアプローチであると信じる誘惑がありますが、Accelerate (LeanとDevOpsの科学) と State of DevOps Report の調査によればそうではありません。サービスメッシュの完全なロールアウトは、このテクノロジがすべてのエンドユーザのリクエストを処理するクリティカルパス上にあることを意味するため、ビッグバン・デプロイメントは非常にリスクが高くなります。

デススター・アーキテクチャ

組織がマイクロサービスアーキテクチャを採用し、開発チームが新しいマイクロサービスの作成を開始したり、アプリケーションで既存のサービスを活用したりすると、サービス間通信がアーキテクチャの重要な部分になります。優れたガバナンスモデルがないと、これは異なるサービス間の密結合につながる可能性があります。また、プロダクションでシステム全体で問題が発生した場合、どのサービスに問題があるのかを特定することも困難になります。

サービスの通信戦略とガバナンスモデルがない、このアーキテクチャは「デススター・アーキテクチャ」と呼ばれるものになります。

このアーキテクチャのアンチパターンの詳細については、クラウドネイティブアーキテクチャの採用についての記事 Part1、Part2、および Part3 を確認してください。

ドメイン固有サービスメッシュ

サービスメッシュのローカル実装と過度の最適化により、サービスメッシュデプロイメントの範囲が狭すぎる場合があります。開発者は、独自のビジネスドメインに固有のサービスメッシュインスタンスを好む場合がありますが、このアプローチには利点よりも欠点があります。組織 (財務、人事、経理など) それぞれのビジネスまたは機能ドメイン固有のサービスメッシュのように、きめ細かい範囲のサービスメッシュを実装することは望ましくありません。これは、エンタープライズレベルのサービスディスカバリーやクロスドメインのサービスルーティングなどの能力のあるサービスメッシュのような共通のサービスオーケストレーションソリューションを持つという目的を打ち破ります。

サービスメッシュの実装とプロダクト

以下は、網羅できてはいませんが現在のサービスメッシュ実装のリストです:

• Linkerd (CNCF を卒業したプロジェクト)
• Istio
• Consul
• Kuma (CNCF のサンドボックスプロジェクト)
• AWS App Mesh
• NGINX Service Mesh
• AspenMesh
• Kong
• Solo Gloo Mesh
• Tetrate Service Bridge
• Traefik Mesh (以前は Maesh)
• Meshery
• Open Service Mesh (CNCF のサンドボックスプロジェクト)

また、DataDog などの他のプロダクトは、Linkerd、Istio、Consul Connect、AWS App Mesh などのサービスメッシュテクノロジーとの統合を提供し始めています。

サービスメッシュの比較: どのサービスメッシュにしますか?

サービスメッシュの分野は非常に高速に移り変わるため、比較を作成しようとしてもすぐに古くなる可能性があります。ただし、いくつかの比較は存在します。出典のバイアス (ある場合) と比較が行われた日付を理解するように注意が必要です:

• https://layer5.io/landscape
• https://kubedex.com/istio-vs-linkerd-vs-linkerd2-vs-consul/ (2021年8月現在)
• https://platform9.com/blog/kubernetes-service-mesh-a-comparison-of-istio-linkerd-and-consul/ (2019年10月現在の最新)
• https://servicemesh.es/ (2021年8月最新公開)

InfoQ は常にサービスメッシュの採用者がそれぞれの製品に対して独自のデューデリジェンスと実験を行うことを推奨しています。

サービスメッシュチュートリアル

複数のサービスメッシュを試してみたいエンジニアやアーキテクトは、次のチュートリアル、プレイグラウンド、ツールが利用できます:

• Layer 5 Meshery—複数のサービスメッシュ管理プレーン
• Solo’s Gloo Mesh—サービスメッシュオーケストレーションプラットフォーム
• KataCoda Istio tutorial
• Consul service mesh tutorial
• Linkerd tutorial
• NGINX Service Mesh Tutorial

サービスメッシュの歴史

InfoQ は、Airbnb が新しい「マイクロサービス」スタイルのアーキテクチャに外部プロセスのサービスディスカバリーメカニズム (HAProxy を使用) を提供する SmartStack をリリースした2013年後半から、現在サービスメッシュと呼ばれているトピックを追跡しています。これまでに「ユニコーン」とラベル付けされた組織の多くは、この日付以前に同様のテクノロジーに取り組んでいました。2000年代初頭から Google は gRPC に進化する Stubby RPC フレームワークと、Istio にその特徴が見られる Google Frontend (GFE) とグローバルソフトウェアロードバランサ (GSLB) を開発していました。2010年代初頭、Twitter は、Linkerd サービスメッシュの登場から Scala を利用した Finagle の開発を開始しました。

2014年後半、Netflix は、任意の言語で記述されたアプリケーションサービスが HTTP 経由でライブラリのスタンドアロンインスタンスと通信できるようにする「サイドカー」プロセスである Prana を含む JVM ベースのユーティリティのスイート全体をリリースしました。2016年、NGINX チームは、サービスメッシュに非常によく似た「ファブリックモデル」について話し始めましたが、実装には有償の NGINX Plus 製品を使用する必要がありました。また、Linkerd v0.2 は2016年2月に発表されましたが、チームはそれをサービスメッシュと呼び始めました。

サービスメッシュの歴史の他のハイライトでは、2017年5月の Istio のリリース、2018年7月の Linkerd 2.0、2018年11月の Consul Connect と Gloo Mesh、2019年5月のサービスメッシュインターフェイス (SMI)、Maesh (現在は Traefik Mesh と呼ばれています) および2019年9月の Kuma が含まれます。

HashiCorp の Consul など、ユニコーン外部に登場したサービスメッシュでさえ、前述のテクノロジーからインスピレーションを得て、CoreOS の造語である Google インフラストラクチャを他のすべての人のために (Google infrastructure for everyone else) を意味する「GIFEE」の概念を実装することを目的としていました。

現代のサービスメッシュの概念がどのように進化したかについての歴史を深く掘り下げるために、Phil Calçado 氏は包括的な記事「パターン: サービスメッシュ」を作成しました。

サービスメッシュ標準

サービスメッシュテクノロジーは過去数年間、毎年大きな変革を遂げてきましたが、サービスメッシュの標準はイノベーションに追いついていません。

サービスメッシュソリューションを使用するための主な標準は、サービスメッシュインターフェイス (SMI) です。サービスメッシュインターフェースは、Kubernetes で実行されるサービスメッシュの仕様です。サービスメッシュ自体は実装していませんが、さまざまなサービスメッシュプロバイダが実装できる共通の標準を定義しています。

SMI API の目標は、Kubernetes ユーザがプロバイダに依存しない方法で使用できる共通のポータブルなサービスメッシュ API のセットを提供することです。このようにして、特定の実装に厳密に拘束されることなく、サービスメッシュテクノロジーを使用するアプリケーションを定義できます。

SMI は基本的に、Kubernetes カスタムリソース定義 (CRD) と拡張 API サーバのコレクションです。これらの API は、任意の Kubernetes クラスタにインストールし、標準ツールを使用して操作できます。これらの API をアクティブ化するために、SMI プロバイダが Kubernetes クラスタで実行されます。

SMI 仕様では、エンドユーザ向けの標準化とサービスメッシュテクノロジーのプロバイダによるイノベーションの両方が可能です。SMI は柔軟性と相互運用性を可能にし、最も一般的なサービスメッシュ機能をカバーします。現在のコンポーネント仕様は、サービスメッシュ機能の接続性の側面に焦点を当てています。API 仕様には次のものが含まれます:

• トラフィックアクセスコントロール
• トラフィックメトリックス
• トラフィックスペック
• トラフィック分割

現在の SMI エコシステムには、Istio、Linkerd、Consul Connect、Gloo Mesh などの幅広いサービスメッシュが含まれています。

SMI 仕様は、Apache License バージョン 2.0 でライセンスされています。

SMI 仕様と API の詳細について詳しく知りたい場合は、次のリンクを確認してください。

• Core Specification (現在のバージョン: 0.6.0)
• Specification Github project
• How to Contribute

サービスメッシュベンチマーク

サービスメッシュパフォーマンスは、インフラストラクチャのキャパシティ、サービスメッシュ構成、およびワークロードのメタデータの詳細をキャプチャするための標準です。SMP 仕様は、次の詳細をキャプチャするために使用されます:

• 環境とインフラストラクチャの詳細
• ノード、オーケストレーターの数とサイズ
• サービスメッシュとその構成
• ワークロード/アプリケーションの詳細
• パフォーマンスを特徴付ける統計分析

Linkerd チームの William Morgan 氏は、Linkerd と Istio のパフォーマンスのベンチマークについて書いています。サービスメッシュパフォーマンスのベンチマークに関する Istio のベストプラクティスに関する2019年の記事もあります。

他のパフォーマンスベンチマークと同様に、特にプロダクトベンダーによるこれらの外部の出版物に過度の重みをかけないように注意することが重要です。サーバ環境で独自のパフォーマンステストを設計および実行して、どの特定のプロダクトがアプリケーションのビジネス要件および非機能要件に適合するかを検証する必要があります。

サービスメッシュの未来 (の可能性) を探る

Kasun Indrasiri 氏は「The Potential for Using a Service Mesh for Event-Driven Messaging (イベント駆動メッセージングでサービスメッシュを使用する潜在力)」を調査し、サービスメッシュ内にメッセージングサポートを実装するための2つの主要な新しいアーキテクチャパターンであるプロトコルプロキシサイドカーと HTTP ブリッジサイドカーについて説明しました。これはサービスメッシュコミュニティで活発に開発されている分野であり、Envoy で Apache Kafka をサポートするための作業が大きな注目を集めています。

Christian Posta 氏は以前「Towards a Unified, Standard API for Consolidating Service Meshes (サービスメッシュ統合のための標準 API 統一に向けて)」で、サービスメッシュの使用を標準化する試みについて書いています。この記事では、Microsoft と KubeCon EU のパートナによる2019年に発表されたサービスメッシュインターフェイス (SMI) についても説明しています。SMI は、Istio、Linkerd、Consul Connect などのさまざまなサービスメッシュテクノロジー間での相互運用性を開発者に提供することを目的とした一連の共通のポータブル API を定義します。

サービスメッシュをプラットフォームファブリックと統合するトピックは、さらに2つのサブトピックに分けることができます。

まず、サービスメッシュデータプレーンによって導入されるネットワークオーバーヘッドを削減するために実施されている作業があります。これには、データプレーン開発キット (DPDK) が含まれます。これは「Linux カーネルネットワークスタックの重いレイヤをバイパスし、ネットワークハードウェアと直接通信する」ユーザスペースアプリケーションです。Linux カーネルの拡張 Berkley Packet Filter (eBPF) 機能を利用して「非常に効率的なネットワーキング、ポリシー適用、および負荷分散機能」を実現する、Cilium チームによる Linux ベースの BPF ソリューションもあります。別のチームでは「クラウドネイティブな方法でネットワーク機能の仮想化 (NFV) を再考する」試みとして、ネットワークサービスメッシュを使用してサービスメッシュの概念を L2/L3 ペイロードにマッピングしています。

次に、AWS App Mesh、GCP Traffic Director、Azure Service Fabric Mesh の導入に見られるように、サービスメッシュをパブリッククラウドプラットフォームとより緊密に統合するための複数のイニシアチブがあります。

Buoyant チームは、サービスメッシュテクノロジーの効果的な人間中心のコントロールプレーンの開発を主導しています。彼らは最近、Kubernetes を運用するプラットフォームチーム向けの SaaS ベースの「チームコントロールプレーン」である Buoyant Cloud をリリースしました。このプロダクトについては、以下のセクションで詳しく説明します。

昨年以来、サービスメッシュ領域にもいくつかのイノベーションがありました。これらのイノベーションのいくつかを見てみましょう。

マルチクラウド、マルチクラスタ、マルチテナントのサービスメッシュ

近年、さまざまな組織によるクラウドの採用により、単一のクラウドソリューション (プライベートまたはパブリック) から、複数の異なるベンダー (AWS、Google、 Microsoft Azureなど) による、マルチクラウド (プライベート、パブリックやハイブリッド) の新しいインフラストラクチャベースへの変化があります。また、統合されたクラウドアーキテクチャを実現するには、多様なワークロード (トランザクション、バッチ、ストリーミング) サポートの必要性が重要です。

これらのビジネスと非機能要件により、サービスメッシュソリューションを異種インフラストラクチャ (ベアメタル、VM、Kubernetes) にデプロイする必要が生じます。サービスメッシュアーキテクチャは、これらの多様なワークロードとインフラストラクチャをサポートするために、それらに応じて変換する必要があります。

Kuma のようなテクノロジーは、マルチメッシュコントロールプレーンをサポートして、ビジネスアプリケーションをマルチクラスタおよびマルチクラウドサービスメッシュ環境で機能させます。これらのソリューションは、複数のゾーンにわたるサービスメッシュポリシーの同期と、それらのゾーン間のサービス接続 (およびサービスディスカバリー) を抽象化します。

マルチクラスタサービスメッシュテクノロジーのもう1つの新しいトレンドは、エッジコンピューティングレイヤ (IoTデバイス) からメッシュレイヤへのアプリケーション/サービス接続の必要性です。

メディアサービスメッシュ

Cisco Systems で開発された Media Streaming Mesh またはメディアサービスメッシュは、Kubernetes クラウドプラットフォームでサービスメッシュテクノロジーを使用して、マルチプレーヤゲーム、マルチパーティビデオ会議、CCTV ストリーミングなどのリアルタイムアプリケーションを調整するために使用されます。これらのアプリケーションは、モノリシックアプリケーションからマイクロサービスアーキテクチャへとますます移行しています。サービスメッシュは、負荷分散、暗号化、可観測性などの機能を提供することにより、アプリケーションを支援することができます。

カオスメッシュ

CNCF がホストするプロジェクトである Chaos Mesh は、Kubernetes でホストされるアプリケーション向けのオープンソースでクラウドネイティブのカオスエンジニアリングプラットフォームです。サービスメッシュの直接の実装ではありませんが、Chaos Mesh は、アプリケーションへのフォールトインジェクション動作を調整することにより、Chaos エンジニアリングの実験を可能にします。フォールトインジェクションはサービスメッシュテクノロジーの重要な機能です。

Chaos Mesh は、アプリケーション開発者が実際のカオス実験に集中できるように、基盤となる実装の詳細を隠します。Chaos Mesh は、サービスメッシュと一緒に使用できます。チームが Linkerd と Chaos Mesh を使用して、プロジェクトのカオス実験をどのように実施したかについては、このユースケースを確認してください。

サービスメッシュ・アズ・ア・サービス

Buoyant などの一部のサービスメッシュベンダーは、マネージドサービスメッシュまたは「サービスとしてのサービスメッシュ」ソリューションを提供しています。今年の初めに、Buoyant は、Buoyant Cloud と呼ばれる SaaS アプリケーションのパブリックベータリリースを発表しました。これにより、顧客組織は、Linkerd サービスメッシュのオンデマンドサポート機能を備えたマネージドサービスメッシュを利用できます。

Buoyant Cloud ソリューションが提供する機能には、次のものがあります:

• Linkerd データプレーンとコントロールプレーンの状態の自動追跡
• Kubernetes プラットフォーム上のポッド、プロキシ、クラスタ全体でサービスメッシュのライフサイクルとバージョンの管理
• サービスレベル目標 (SLO)、ワークロードゴールデンメトリックストラッキング、変更トラッキングなど、SRE に重点を置いたツール

ネットワークサービスメッシュ (NSM)

別の Cloud Native Computing Foundation サンドボックスプロジェクトであるネットワークサービスメッシュ (NSM) は、ハイブリッドのマルチクラウド IP サービスメッシュを提供します。NSM は、サービスメッシュのコア機能であるネットワークサービス接続、セキュリティ、可観測性などの機能を有効にします。NSM は、既存のコンテナネットワークインターフェイス (CNI) 実装と連携します。

サービスメッシュ拡張

サービスメッシュ拡張は、多くのイノベーションが見られるもう1つの領域です。サービスメッシュ拡張の開発には、次のものが含まれます:

• カスタム認証局プラグインを含むマイクロサービス接続を保護するためのID管理の強化
• サービスの可用性とスケーラビリティを高めるための適応ルーティング機能
• サイドカープロキシの強化

サービスメッシュの運用

サービスメッシュ採用のもう1つの重要な領域は、サービスメッシュライフサイクルの運用側です。マルチクラスタ機能の構成や、VM インフラストラクチャでホストされているサーバへの Kubernetes ワークロードの接続、マルチクラスタサービスメッシュのインストールのすべての機能と API を管理する開発者ポータルなどの運用面は、プロダクションでのサービスメッシュソリューションの全体的なデプロイメントとサポートにおいて重要な役割を果たします。

FAQ

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

サービスメッシュは、分散型 (マイクロサービスベースの可能性がある) ソフトウェアシステムのすべてのサービス間 (東西) トラフィックを管理するテクノロジーです。ルーティングなどのビジネスに焦点を合わせた機能操作と、セキュリティポリシーの適用、サービス品質、レート制限などの非機能サポートの両方を提供します。これは通常 (排他的ではありませんが)、すべてのサービスが通信するサイドカープロキシを使用して実装されます。

サービスメッシュは API ゲートウェイとどう違うのですか?

サービスメッシュの定義については、上記を参照してください。

他方、API ゲートウェイは、クラスタへのすべての入力 (南北) トラフィックを管理し、機能の枠を超えた通信要件に対する追加のサポートを提供します。これは、システムへの単一のエントリポイントとして機能し、複数の API またはサービスがまとまって動作し、ユーザに均一なエクスペリエンスを提供できるようにします。

マイクロサービスのデプロイには、サービスメッシュが必要ですか?

必ずしもそうではありません。サービスメッシュはテクノロジースタックに運用上の複雑さを追加するため、通常、組織がサービス間通信のスケーリングに問題がある場合や、または解決する特定のユースケースがある場合にのみデプロイされます。

マイクロサービスでサービスディスカバリーを実装するには、サービスメッシュが必要ですか?

いいえ。サービスメッシュは、サービスディスカバリーを実装する1つの方法を提供します。他のソリューションには、言語固有のライブラリ (Ribbon、Eureka、Finagle など) があります。

サービスメッシュは、サービス間の通信にオーバーヘッド/遅延を追加しますか?

はい。サービスメッシュは、サービスが別のサービスと通信しているときに、少なくとも2つの追加のネットワークホップを追加します (1つ目は送信元のアウトバウンド接続を処理するプロキシからのもので、2つ目は宛先のインバウンド接続を処理するプロキシからのものです)。ただし、この追加のネットワークホップは通常、ローカルホストまたはループバックネットワークインターフェイスを介して発生し、わずかな遅延 (ミリ秒オーダ) のみ追加します。これがターゲットのユースケースの問題であるかどうかを実験して理解することは、サービスメッシュの分析と評価の一部としなければなりません。

サービスメッシュは、アプリケーションがデプロイされている Kubernetes または「クラウドネイティブプラットフォーム」の一部であるべきではないのですか?

そうかもしれません。クラウドネイティブプラットフォームコンポーネント内 (たとえば、Kubernetes はコンテナオーケストレーションの提供を担当し、サービスメッシュはサービス間通信を担当します) で関心の分離を維持することには議論があります。ただし、サービスメッシュのような機能を最新の Platform-as-a-Service (PaaS) 製品にプッシュする作業が進行中です。

サービスメッシュの実装、デプロイ、またはロールアウトはどうすればよいですか?

最善のアプローチは、さまざまなサービスメッシュプロダクト (上記参照) を分析し、選択したメッシュ固有の実装ガイドラインに従うことです。一般的に、すべてのステークホルダと協力し、新しいテクノロジーを段階的にプロダクションにデプロイすることが最善です。

独自のサービスメッシュを構築できますか?

はい、しかしもっと適切な質問は、それはあなたがすべきことでしょうか? サービスメッシュの構築は組織のコアコンピテンシーですか? より効果的な方法で顧客に価値を提供できるのでしょうか? また、独自のメッシュを維持し、セキュリティ問題にパッチを適用し、新しいテクノロジーを活用するために常に更新することに取り組んでいますか? 現在利用可能なオープンソースおよび商用サービスメッシュ製品の範囲では、既存のソリューションを使用する方がおそらくより効果的です。

ソフトウェアデリバリー組織の中でサービスメッシュを所有しているチームはどこですか?

通常、プラットフォームまたは運用チームが、Kubernetes および継続的デリバリーパイプラインインフラストラクチャとともに、サービスメッシュを所有しています。ただし、開発者はサービスメッシュのプロパティを構成するため、両方のチームが緊密に連携する必要があります。多くの組織は、Netflix、Spotify、Google などのクラウドの先駆者の先導に従い、フルサイクルのプロダクト中心の開発チームにツールとサービスを提供する内部プラットフォームチームを作成しています。

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

いいえ。Envoy は、もともと Lyft チームによって設計および構築されたクラウドネイティブプロキシです。Envoy は、サービスメッシュを使用したデータプレーンとしてよく使用されます。しかし、サービスメッシュと見なされるには、Envoyが、サービスメッシュになるためのテクノロジーのコレクションで、コントロールプレーンと組み合わせて使用する必要があります。コントロールプレーンは、一元化された構成ファイルリポジトリとメトリックスコレクターのような単純な場合もあれば、Istio のように包括的/複雑な場合もあります。

「Istio」と「サービスメッシュ」という言葉は同じ意味で使用できますか?

いいえ。Istio はサービスメッシュの一種です。サービスメッシュカテゴリが出現したときの Istio の人気により、一部のソースは Istio とサービスメッシュを混同していました。この混同の問題は、サービスメッシュ固有のものではありません。同じ課題が、Docker とコンテナテクノロジーで発生しました。

どのサービスメッシュを使用すべきですか?

この質問に対する単一の答えはありません。エンジニアは、現在の要件と、実装チームが利用できるスキル、リソース、および時間を理解する必要があります。上記のサービスメッシュ比較リンクは、調査の開始点として適していますが、組織に最適なプロダクト、テクノロジー、ワークフローを理解するために、少なくとも2つのメッシュを試してみることを強くお勧めします。

Kubernetes 以外でサービスメッシュを使用できますか?

はい。多くのサービスメッシュにより、さまざまなインフラストラクチャでのデータプレーンプロキシと関連するコントロールプレーンのインストールと管理が可能になります。HashiCorp の Consul はこの最もよく知られた例であり、Istio は Cloud Foundry でも実験的に使用されています。

追加リソース

• InfoQ Service Mesh homepage
• The InfoQ eMag—Service Mesh: Past, Present, and Future
• The Service Mesh: What Every Software Engineer Needs to Know about the World’s Most Over-Hyped Technology
• Service Mesh Comparison
• Service Meshes
• Adoption of Cloud Native Architecture, Part 3: Service Orchestration and Service Mesh (クラウドネイティブアーキテクチャの導入 パート3: サービスオーケストレーションとサービスメッシュ)

用語集

API ゲートウェイ: クラスタへのすべての入力 (南北) トラフィックを管理し、機能の枠を超えた通信要件に対する追加のサポートを提供します。これは、システムへの単一のエントリポイントとして機能し、複数の API またはサービスがまとまって動作し、ユーザーに均一なエクスペリエンスを提供できるようにします。

Consul: HashiCorp の Go ベースのサービスメッシュ。

コンテナ化: コンテナは、コードとそのすべての依存関係をパッケージ化するソフトウェアの標準ユニットであるため、アプリケーションは、あるコンピューティング環境から別のコンピューティング環境へと迅速かつ確実に実行されます。

コントロールプレーン: データプレーン (プロキシ) のすべての個々のインスタンスを取得し、オペレーターが視覚化および制御できる分散システムに変換します。

サーキットブレーカ: リモートサービスに接続する際の障害またはタイムアウトを処理します。アプリケーションの安定性と回復力を向上させるのに役立ちます。

データプレーン: サービスネットワークエンドポイントとの間で送受信されるすべてのネットワークパケットを条件付きで変換、転送、および監視するプロキシ。

Docker: Docker コンテナイメージは、アプリケーションの実行に必要なすべてのもの (コード、ランタイム、システムツール、システムライブラリ、設定) を含む、軽量でスタンドアロンの実行可能なソフトウェアパッケージです。

東西 (East-West) トラフィック: データセンタ、ネットワーク、または Kubernetes クラスタ内のネットワークトラフィック。従来ネットワーク図は、サービス間 (データセンター内) のトラフィックが図の左から右 (東から西) に流れるように描かれていました。

Envoy Proxy: クラウドネイティブアプリケーション向けに設計されたオープンソースのエッジおよびサービスプロキシ。Envoyは、サービスメッシュ実装のデータプレーンとしてよく使用されます。

入力 (Ingress) トラフィック: データセンタ、ネットワーク、または Kubernetes クラスタの外部から発信されるネットワークトラフィック。

Istio: C++ (データプレーン) および Go (コントロールプレーン) ベースのサービスメッシュ。元々は、Lyft の Envoy チームと協力して Google と IBM によって作成されました。

Kubernetes: Google が開発した CNCF がホストするコンテナオーケストレーションおよびスケジューリングフレームワーク。

Kuma: Kong の Go ベースのサービスメッシュ。

Linkerd: Twitter の初期の JVM ベースの通信フレームワークから派生した Rust (データプレーン) および Go (コントロールプレーン) を利用したサービスメッシュ。

Maesh: Traefik API ゲートウェイのメンテナである Containous の Go ベースのサービスメッシュ。

MOSN: (Envoy) xDS API を実装する Ant Financial チームの Go ベースのプロキシ。

南北 (North-South) トラフィック: データセンタ、ネットワーク、または Kubernetes クラスタに入る (または入力) ネットワークトラフィック。従来ネットワーク図は、ページ上部でデータセンタに入り、ネットワークに流れ込む (北から南へ) 入力トラフィックを使用して作成されました。

Proxy: エンドポイントコンポーネント間の仲介役として機能するソフトウェアシステム。

セグメント化: ネットワークまたはクラスタを複数のサブネットワークに分割する。

サービスメッシュ: 分散型 (マイクロサービスベースの可能性がある) ソフトウェアシステムのすべてのサービス間 (東西) トラフィックを管理します。ルーティングなどの機能的な操作と、セキュリティポリシーの適用、サービス品質、レート制限などの非機能的なサポートの両方を提供します。

サービスメッシュインターフェイス (SMI): Kubernetes にデプロイされるサービスメッシュの標準インターフェース。

サービスメッシュポリシー: サービス/エンドポイントのコレクションが相互に通信したり、他のネットワークエンドポイントとどのように通信するかの仕様。

サイドカー: 追加のプロセス、サービス、またはコンテナが既存のサービスと一緒にデプロイされる (オートバイのサイドカーを考えてください) デプロイメントパターン。

一括管理 (single pane of glass): 複数のソースのデータを統合したディスプレイに表示する UI または管理コンソール。

トラフィックシェーピング: レート制限や負荷制限など、ネットワーク全体のトラフィックフローを変更します。

トラフィックシフティング: ある場所から別の場所へのトラフィックの移行。

トラフィック分割: ユーザがさまざまなサービス間でトラフィックの割合を段階的に誘導できるようにします。入力コントローラやサービスメッシュサイドカーなどのクライアントが、発信トラフィックをさまざまな宛先に分割するために使用します。

現代のソフトウェアアーキテクトの役割は絶えず変化しています。InfoQ の Software Architects のニュースレターを購読して、先に進みましょう。

著者について

Srini Penchikala 氏 は、テキサス州オースティンを拠点とするシニア IT アーキテクトです。彼はソフトウェアアーキテクチャ、設計、開発で25年以上の経験があり、現在はクラウドネイティブアーキテクチャ、マイクロサービスとサービスメッシュ、クラウドデータパイプライン、継続的デリバリーにフォーカスしています。Penchikala 氏は、Big-Data Processing with Apache Spark を著し、Manning の Spring Roo in Action を共同執筆しました。彼は頻繁にカンファレンスで講演し、ビッグデータトレーナで、さまざまな技術 Web サイトでいくつかの記事を公開しています。