サービスメッシュとは

サービスメッシュは、サービス間の通信を処理するソフトウェア・アプリケーション内の専用インフラストラクチャ層です。トラフィックルーティング、セキュリティ、可観測性、および回復力の機能を処理するとともに、これらの複雑性を個々のサービスから抽象化します。

先進的なアプリケーションは、相互に通信するサービスを利用しています。オンラインストアに最近アクセスしたときの状況を思い出してみてください。サイトの検索バーを使用して商品をブラウズしたのではないでしょうか。この検索がサービスです。関連商品のお勧めを見たことや、オンライン・ショッピング・カートに品物を追加したこともあるでしょう。これも両方ともサービスです。インベントリー・データベースと通信するサービスは商品の Web ページと通信する必要があり、Web ページはユーザーのオンライン・ショッピング・カートと通信する必要があります。小売業者は、ユーザーにアプリ内で商品を推奨するサービスも提供している場合があります。このサービスは商品タグのデータベースと通信してお勧めを提案しますが、商品のページが必要とするものと同じインベントリー・データベースとも通信する必要があります。

先進的なアプリケーションはこのような方法で分割されていることが多く、サービスのネットワークがそれぞれ固有の機能を実行します。サービスの機能を実行するため、時には 1 つのサービスが複数の他のサービスにデータを要求する必要があります。では、小売業者のインベントリー・データベースのような、一部のサービスが要求で過負荷になった場合、どうなるでしょうか。ここで登場するのが、サービスメッシュです。サービスメッシュはサービス間の通信を管理し、すべての構成要素が最適に連携できるようにします。

サービスメッシュは、マイクロサービス・アーキテクチャ・パターンと考えることができます。マイクロサービスは、独立したサービスの集合が軽量 API (アプリケーション・プログラミング・インタフェース) を通じて通信するアプリケーション・アーキテクチャのスタイルです。マイクロサービス・アーキテクチャはソフトウェア構築のクラウドネイティブ・アプローチで、アプリケーション内のコア機能のそれぞれが独立して存在できるようにするものです。他のアーキテクチャでのアプリ開発とは異なり、個々のマイクロサービスは小規模のチームで構築され、固有のツールとコーディング言語を選べる柔軟性を備えています。マイクロサービスは個々が独立して構築されて相互に通信します。障害は発生してもマイクロサービスの内部にとどまり、アプリケーション全体の障害へと発展することはありません。

マイクロサービスを成り立たせているのは、サービス間通信です。マイクロサービス・アーキテクチャが拡大するにつれて、管理はより複雑になります。アプリケーションに数十あるいは数百の相互に通信するサービスが含まれる場合、ネットワーク障害、監視と追跡、トラフィック負荷の分散、さまざまなマイクロサービス間の通信のセキュリティ保護に関する課題が生じます。これらの問題にカスタムコードだけで対処するのは非効率的です。サービスメッシュは、個々のサービスのコードを変更することなく、こうした課題に対処するための一貫したソリューションを提供します。

サービスメッシュは、データプレーンとコントロールプレーンを使用してサービス間の通信を管理します。サービスメッシュは、アプリケーションのランタイム環境に新しい機能をもたらすものではありません。どのアーキテクチャでも、アプリケーションは常に、A から B にリクエストを渡す方法を指定するために必要なルールを備えています。サービスメッシュの特異な点は、サービス間通信を規定するロジックを個々のサービスから抜き出し、インフラストラクチャのレイヤーに抽象化していることです。

このために、サービスメッシュはネットワークプロキシのアレイとしてアプリケーションに組み込まれています。プロキシは馴染みのある概念です。この Web ページに職場のコンピュータからアクセスしているなら、高い確率でプロキシを使用しているでしょう。方法は以下の通りです。

1. このページへのリクエストが送信されると、ユーザーの会社の Web プロキシが受信します。
2. プロキシのセキュリティ対策を通過すると、このページをホストするサーバーに送信されます。
3. 次に、このページはプロキシに返され、もう一度セキュリティ対策でチェックされます。
4. その後、プロキシからユーザーに送信されます。

サービスメッシュでは、各サービスインスタンスは「サイドカー」プロキシとペアになっています。サイドカープロキシは各サービスと並行して実行され、すべての送受信ネットワーク・トラフィックをインターセプトします。各サイドカープロキシはマイクロサービスと並んで存在し、他のプロキシ間でリクエストを転送します。プロキシは、トラフィックルーティング、負荷分散、セキュリティポリシーの適用、テレメトリーデータの収集などのタスクを処理します。サービスは相互に直接通信するのではなく、サイドカーを介してリクエストを送信します。このサイドカーがサービス間の通信を処理します。これらすべてがデータプレーンを構成します。

コントロールプレーンは、データプレーン全体の構成とポリシーの配布を管理します。コントロールプレーンは、トラフィック・ルーティング・ルールの配布、サービス間のセキュリティ証明書の管理、ポリシー適用のためのコンポーネントの構成、テレメトリーの収集も行います。

サービスメッシュがなければ、各マイクロサービスはサービス間通信を規定するロジックをコーディングする必要があります。その場合はサービス間通信を規定するロジックが各サービス内に隠蔽されるので、通信エラーの診断が難しくなります。

マイクロサービスについての詳細

Istio とはオープンソースのサービスメッシュ・プラットフォームで、マイクロサービス相互のデータ共有を制御します。トラフィックフローを制御し、ポリシーを適用し、マイクロサービス環境での通信を監視します。Istio をあらゆるロギング・プラットフォーム、テレメトリー、またはポリシーシステムに統合する API も含まれています。Istio は、オンプレミス、クラウド、コンテナ化、仮想化といったさまざまな環境で実行できます。

Istio のアーキテクチャはデータプレーンとコントロールプレーンに分かれています。Istio は Envoy プロキシを使用します。これは、サイドカーとしてデプロイされ、サービスメッシュ内のすべてのサービスのトラフィックを仲介する高性能プロキシです。データプレーンでは、開発者は環境内にサイドカープロキシをデプロイすることで、Istio サポートをサービスに追加できます。

Istio のサービスメッシュには新しいアンビエントモードが含まれています。これにより、サービスメッシュ内のサイドカープロキシは不要になり、ノードレベルのプロキシとウェイポイントと呼ばれる中間ゲートウェイに置き換えられます。ウェイポイントプロキシはアプリケーション Pod の外部で動作し、アプリケーションから独立して管理されます。

Red Hat Developer で Istio の詳細を見る

アプリケーションに新しいサービス、またはコンテナで実行される既存のサービスの新しいインスタンスが追加されるたびに、通信環境が複雑になり、新たな障害点が発生します。複雑なマイクロサービス・アーキテクチャでは、サービスメッシュがなければ、問題を突き止めるのはほぼ不可能と言えます。

サービスメッシュを使用するメリットには次のようなものがあります。

• セキュリティの強化：サービスメッシュは相互トランスポート層セキュリティ (mTLS) を使用します。これにより、サービス間通信の暗号化とセキュリティ保護を実現し、機密性の高いユーザーデータを保護します。そのため、各サービスに手作業で暗号化を追加することなくセキュリティ層を追加できます。サービスメッシュは、ロールベースのアクセス制御 (RBAC) と API を保護するためのポリシーを改善できます。また、証明書管理とキーのローテーションを自動化できます。
• ポリシー適用：サービスメッシュには、クォータ、レート制限、認証と認可などのサービスポリシーの構成が一元化されています。サービスメッシュはアクセスポリシーを通じてサービス間のやり取りを制御します。ポリシーはプロキシレベルで適用されるため、サービス間の一貫性を確保できます。
• トラフィック管理：サービスメッシュは、アプリケーションが負荷条件、バージョン、ユーザー固有のルールに基づいて個々のサービスへのトラフィックを管理するのに役立ちます。たとえば、新しいバージョンのインベントリーサービスを展開する場合、カナリアデプロイメントを使用して、トラフィックの 5% のみを新しいサービスに送信できます。(カナリアとは小規模なテストデプロイのことです。) それがうまくいったことを確認して、トラフィックを増やすことができます。
• ヘルスチェックと可観測性：マイクロサービスのやり取りをリアルタイムで確認するのは難しい場合がありますが、サービスメッシュを使用すれば、分散トレースやメトリクス収集などの組み込み可観測性ツールを実装できます。サービスメッシュ内のサイドカーはメトリクス (リクエスト数、レイテンシー、エラー率) を収集し、それらをコントロールプレーンまたは監視ツールに送信します。
• フォールトトレランスと回復力の向上：マイクロサービスで障害が発生した場合もサービスメッシュが役立ちます。再試行とフォールバックが自動化されているからです。サービスが失敗したり、応答しなくなったりした場合、サービスメッシュは事前に定義されているルールに基づいて再試行し、トラフィックを代替サービスに再ルーティングすることができます。つまり、あるサービスが利用できなくなったとしても、アプリケーションは障害を適切に処理できるため、良好なユーザーエクスペリエンスが維持されます。サービスメッシュは、再試行が成功するまでにかかった時間に関するデータも収集します。このデータは、最適な待機時間に関する今後のルール設定に有益な情報であり、不必要な再試行によるシステムへの過負荷を防ぐことができます。

サービスメッシュがあると、開発チームと運用チームはモノリシック・アプリケーションからクラウドネイティブ・アプリケーション (小型で独立した、疎結合のマイクロサービス・アプリケーションの集合) への移行に対処しやすくなります。 

サービスメッシュを実装する際には、次のような課題に直面することがあります。

• 複雑性と既存のシステムとの統合：サービスメッシュは、セットアップ、管理、既存のシステムとの統合が難しい場合があります。マルチクラウドとオンプレミスのシステムにまたがる大規模な分散環境で作業している場合や、これまで環境内でサービスメッシュを使用したことがない場合は、課題に直面する可能性があります。
• リソース要件と運用オーバーヘッド：サービスメッシュでは、各サービスインスタンスにサイドカープロキシが追加され、CPU とメモリーの使用量が増えるため、アプリケーション管理の運用オーバーヘッドが増加する可能性があります。特に大規模なデプロイメントでは、管理とトラブルシューティングが複雑になる場合があり、その結果、パフォーマンスとスケールの維持はより困難になります。
• スキルギャップ：各チームにはサービスメッシュの機能、構成、ベストプラクティスを理解するためのトレーニングが必要です。デバッグの失敗は、特に複雑なルーティングルールや mTLS の構成ミスによって問題が発生した場合、深刻なものになる可能性があります。多くの組織は、既存のチームのサービスメッシュ・テクノロジーに関する専門知識が不足しており、サービスメッシュを使い始めることや効果的に活用することが困難になる可能性があることを認識しています。

API ゲートウェイは、クライアントとバックエンドサービスのコレクションの間に位置する API 管理ツールです。この場合、クライアントはユーザーのデバイス上のアプリケーションであり、バックエンドサービスはエンタープライズサーバー上のサービスです。API ゲートウェイを使うことにより、顧客のインタフェースをバックエンド実装から分離できます。API ゲートウェイは顧客の要求を複数の要求に分割し、それらを適切な場所にルーティングして応答を生成し、すべてを追跡します。

サービスメッシュは、内部サービスの通信を保護するとともに、API ゲートウェイを介した外部トラフィックを可能にします。サービスメッシュを API ゲートウェイと併用すると、内部サービス全体にポリシーを均一に適用できます。 

Red Hat 3scale API Management の詳細

Red Hat は、統合型の API 管理、サービスメッシュ、インフラストラクチャ・プラットフォーム製品を提供して、包括的なサービス管理アーキテクチャの構築を支援します。Red Hat® OpenShift® Service Mesh は、マイクロサービスベースのアプリケーションを接続、管理、監視する方法を統一することができます。サービスメッシュ内でネットワーク化されたマイクロサービスの動作を分析および制御することができます。

OpenShift Service Mesh は、オープンソースの Istio プロジェクトをベースに、Kiali (Istio コンソール) や Jaeger (分散トレース) といった他のオープンソースプロジェクトを取り込むことで機能を追加し、Istio コミュニティの主要メンバーとの協業をサポートしています。OpenShift Service Mesh によって、開発者は、アプリケーションコードを変更したり、言語固有のライブラリを統合したりしなくても、通信ポリシーを統合することで生産性を高めることができます。

Red Hat OpenShift Service Mesh は Red Hat OpenShift 用にプリインストールされ、テストされ、最適化されています。Operator や継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインなど、OpenShift 固有の機能との互換性を備えています。Red Hat のエンタープライズサポートが付属しており、定期的な更新とパッチ適用によりセキュリティと安定性が高められています。OpenShift Service Mesh は複数の Red Hat OpenShift クラスタ間で機能し、ハイブリッドクラウド環境やマルチクラウド環境全体で一貫性を実現します。