サービスメッシュが分散マイクロサービスの管理にどのように役立つか

サービス メッシュは、サービス通信にセキュリティ、回復力、可視性をもたらし、開発者がそれらを行う必要性を解放します。

デジタル変革のトレンドの結果として IT で起こっている変化の 1 つは、大規模なモノリシック アプリケーションをマイクロサービスに分解することです。これらの小さな個別の機能ユニットはコンテナ内で実行されます。コンテナのソフトウェア パッケージにはサービスのすべてのコードが含まれており、分離してサーバー間で簡単に移動できます。

[[271022]]

このようなコンテナ化されたアーキテクチャは、クラウド内で簡単に拡張および実行でき、個々のマイクロサービスを迅速に展開および反復できます。ただし、アプリケーションが大きくなり、同じサービスの複数のインスタンスが同時に実行されるようになると、これらのマイクロサービス間の通信はますます複雑になります。サービス メッシュは、管理とプログラミングのオーバーヘッドを削減しながら、これらのマイクロサービスを動的に接続することを目的とした新しいアーキテクチャ形式です。

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

広い意味では、サービス メッシュは、Red Hat の説明によると、「アプリケーションのさまざまな部分がどのようにデータを共有するかを制御する方法」です。

しかし、この説明はさまざまなことを意味する可能性があります。実際、これは、ほとんどの開発者がクライアント サーバー アプリケーションで使い慣れているミドルウェアによく似ています。

サービス メッシュのユニークな点は、分散型マイクロサービス環境のユニークな性質に対応するように構築されていることです。マイクロサービスで構築された大規模なアプリケーションでは、特定のサービスのインスタンスが複数存在し、異なるローカル サーバーまたはクラウド コンピューティング サーバー上で実行されることがあります。明らかに、これらすべての可動部分により、個々のマイクロサービスが通信する必要がある他のサービスを見つけることが困難になります。サービス メッシュは、サービスの検出と接続をオンザフライで自動的に処理するため、開発者やマイクロサービスが処理する必要がありません。

サービス メッシュは、オープン システム相互接続 (OSI) ネットワーク モデルのレベル 7 のソフトウェア定義ネットワーク (SDN) に相当するものと考えてください。ソフトウェア定義ネットワーク (SDN) が抽象化レイヤーを作成してネットワーク管理者が物理的なネットワーク接続を処理する必要がないように、サービス メッシュは、アプリケーションの基盤となるインフラストラクチャを、企業が対話する抽象アーキテクチャから切り離します。

開発者が本当に大規模な分散アーキテクチャの問題に取り組み始めると、サービス メッシュの概念が生まれました。 Linkerd は、Twitter 社内プロジェクトから派生したこの分野初のプロジェクトです。 Istio は、Lyft が開発した、大手企業の支援を受けているもう 1 つの人気のサービス メッシュです。

サービスメッシュ負荷分散

サービス メッシュが提供する重要な機能は負荷分散です。多くの場合、負荷分散はネットワーク機能と考えられており、企業は、いずれかのサーバーまたはネットワーク リンクがトラフィックによって圧倒されることを防ぎ、それに応じてパケットをルーティングできるようにします。 Twain Taylor が説明しているように、サービス メッシュがアプリケーション レベルで同様のことを実行することを理解すると、サービス メッシュがアプリケーション層でソフトウェア定義ネットワークに似ていることがよくわかります。

本質的に、サービス メッシュの役割の 1 つは、インフラストラクチャ全体に分散されたさまざまなマイクロサービスのどのインスタンスが最も「健全」であるかを追跡することです。インスタンスの状態を確認するためにポーリングを行ったり、サービス要求への応答が遅いインスタンスを追跡して、後続の要求を他のインスタンスに送信したりする場合があります。サービス メッシュは、ネットワーク ルーティングに対しても同様の作業を実行でき、メッセージが宛先に到達するまでに長い時間がかかっている場合にそれを検出し、それを補うために代替ルートを取ります。これらの速度低下は、基盤となるハードウェアの問題、または単にサービスがリクエストで過負荷になっていることが原因である可能性があります。重要なのは、サービス メッシュが同じサービスの別のインスタンスを見つけてそのインスタンスにルーティングし、アプリケーション全体の容量を最も効率的に使用できることです。

サービスメッシュとKubernetes

コンテナベースのアーキテクチャに多少なりとも精通している方であれば、人気のオープンソース コンテナ オーケストレーション プラットフォームである Kubernetes がこの図のどこに当てはまるのか疑問に思うかもしれません。結局のところ、Kubernetes の目的は、コンテナが互いに通信する方法を管理することではないでしょうか? Kublr が企業ブログで述べているように、Kubernetes のサービス リソースは、サービス検出とラウンドロビン リクエスト バランシングを提供するため、非常に基本的なサービス メッシュと考えることができます。しかし、フル機能のサービス メッシュでは、セキュリティ ポリシーや暗号化の管理、応答が遅いインスタンスへのリクエストを一時停止する「回路遮断」など、さらに多くの機能が提供されます。

理解する必要があるのは、ほとんどのサービス メッシュには Kubernetes のようなオーケストレーション システムが必要であるということです。サービス メッシュは機能を置き換えるのではなく、拡張します。

サービスメッシュと API ゲートウェイ

各マイクロサービスは、他のサービスが通信するための手段として、アプリケーション プログラミング インターフェイス (API) を提供します。これにより、サービス メッシュと、API ゲートウェイなどの他の従来の API 管理形式との違いについて疑問が生じます。 IBM の説明によると、API ゲートウェイはマイクロサービス セットと外部世界の間に位置し、必要に応じてサービス要求をルーティングするため、要求者はマイクロサービス ベースのアプリケーションを扱っていることを意識する必要がありません。一方、サービス メッシュはマイクロサービス アプリケーション内のリクエストを仲介し、ユーザーが環境を完全に把握していることを要求します。

Justin Warren 氏が指摘しているように、別の考え方としては、サービス メッシュはクラスター内の東西トラフィック用であり、API ゲートウェイはクラスター内外の南北トラフィック用である、というものがあります。しかし、サービス メッシュのアイデアはまだ初期段階にあり、常に変化しています。 Linkerd や Istio を含む多くのサービス メッシュでは、現在、North-South トラフィック機能も提供されています。

サービスメッシュアーキテクチャ

サービス メッシュの概念はここ数年で登場したばかりで、「サービス メッシュ」問題、つまりマイクロサービスの通信の管理を解決するためのさまざまなアプローチが存在します。 Aspen Mesh の Andrew Jenkins 氏は、サービス メッシュによって作成された通信層を配置する場所として、次の 3 つのオプションを挙げています。

• 各マイクロサービスによってインポートされるライブラリ内。
• 特定のノード上のすべてのコンテナにサービスを提供するノード エージェント内。
• アプリケーション コンテナーと並行して実行されるサイドカー コンテナー内。

Sidecar は、アプリケーション コンポーネントを個別のプロセスまたはコンテナーにデプロイして、分離とカプセル化を実現します。サイドカー ベースのパターンは、最も人気のあるサービス メッシュ パターンの 1 つであり、一部の分野ではサービス メッシュと同義語として使われることがよくあります。厳密に言えば、サイドカー コンテナ アプローチは多くの注目を集めており、これは人々が詳しく検討する必要があるアーキテクチャです。

サービスメッシュのサイドカー

「アプリケーション コンテナと並行して実行されるサイドカー コンテナ」とは何ですか? Red Hat には良い説明があります。このタイプのサービス メッシュ内の各マイクロサービス コンテナーには、別の対応するプロキシ コンテナーがあります。サービス間通信に必要なすべてのロジックはマイクロサービスから抽象化され、サイドカーに組み込まれます。

これは複雑に思えるかもしれません。結局のところ、エンタープライズ アプリケーション内のコンテナーの数は実質的に 2 倍になっています。しかし、分散アプリケーションを簡素化するための鍵となる設計パターンも使用しています。すべてのネットワークおよび通信コードを別のコンテナに配置することで、それらをインフラストラクチャの一部にすることができ、開発者はそれをアプリケーションの一部として実装する必要がなくなります。

本質的には、残っているのはビジネス ロジックに集中できるマイクロサービスです。マイクロサービスは、複雑な環境内の他のすべてのサービスと通信する方法を知る必要はありません。サイドカーとの通信方法を知るだけで、残りの作業はサイドカーが処理します。

サービスメッシュ: Linkerd、Envio、Istio、Consul

では、どのようなサービス メッシュが利用できるのでしょうか?商業的に提供されるものはありません。ほとんどのサービス メッシュは、最終的な実装を必要とするオープン ソース プロジェクトです。よく知られている製品には次のようなものがあります。

• Linkerd — 2016 年にリリースされた最も古い製品である Linkerd は、Twitter で開発されたライブラリから派生したものです。この分野のもう一つの主要製品である Conduit は Linkerd プロジェクトに導入され、Linkerd 2.0 の基礎を形成しています。
• Envio — Lyft で作成された Envoy は、サービス メッシュの「データ プラットフォーム」部分を占めています。完全なサービス メッシュを提供するには、「コントロール プレーン」と組み合わせる必要があります。
• Istio - Lyft、IBM、Google によって開発された Istio は、Envoy のようなサービス プロキシ サービスです。 Istio と Envoy はデフォルトのペアリングですが、それぞれ他のプラットフォームとペアリングすることもできます。
• HashiCorp Consul – Consul 1.2 と同時にリリースされた Connect と呼ばれるこの機能は、サービスの検出と構成のための HashiCorp の分散システムにサービス暗号化と ID ベースの認証を追加し、完全なサービス メッシュに変えます。

では、どのサービス メッシュを採用するのが良いのでしょうか?比較するのは難しいですが、これらの製品はすべて、大規模で要求の厳しい環境で実証されています。 Linkerd と Istio には豊富な機能セットがありますが、どちらも急速に進化しています。

また、いつでも新しい競合相手が市場に現れる可能性があることも覚えておいてください。たとえば、Amazon は 2018 年 11 月に AWS Service Mesh のパブリックプレビューの提供を開始しました。 Amazon のパブリッククラウドを採用しているユーザーの数が多いことを考えると、AWS App Mesh のリリースは大きな影響を与えるはずです。