サービスメッシュとは

オープンソース・プロジェクトの Istio を始めとするサービスメッシュは、アプリケーションのさまざまな部分が互いにデータをどのように共有するかを制御する方法です。サービスメッシュはアプリケーションに直接組み込まれた専用インフラストラクチャ層であり、この点は同様に通信を管理するその他のシステムとは異なります。このインフラストラクチャ層は、アプリケーションの各種の部分の間の通信状況を文書化するため、通信を最適化し、アプリケーションを拡張するときのダウンタイムを防止することが容易になります。

アプリケーションの各部分は「サービス」と呼ばれ、他のサービスを利用してユーザーに必要なものを提供します。オンライン小売アプリのユーザーが何かを購入しようとする場合、商品の在庫があるかどうかを知る必要があります。そこで、企業のインベントリー・データベースと通信するサービスは商品の Web ページと通信する必要があり、Web ページ自体はユーザーのオンライン・ショッピング・カートと通信する必要があります。ビジネス価値を付加するため、この小売業者はユーザーに、アプリから商品のお勧めを提案するサービスを構築しようとします。この新しいサービスは商品タグのデータベースと通信してお勧めを提案しますが、商品のページが必要とするものと同じインベントリー・データベースとも通信する必要があります。このような再利用性が高く、可動性の高い複数のサービスはマイクロサービス・アーキテクチャでも使用されます。

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

マイクロサービス・アーキテクチャでは、開発者は全体をデプロイし直さなくても、アプリケーションのサービスを変更できます。他のアーキテクチャでのアプリ開発とは異なり、個々のマイクロサービスは小規模のチームで構築され、固有のツールとコーディング言語を選べる柔軟性を備えています。基本的に、マイクロサービスは個々が独立して構築されて相互に通信します。障害は発生してもマイクロサービスの内部にとどまり、アプリケーション全体の障害へと発展することはありません。

マイクロサービスを成り立たせているのは、サービス間通信です。通信を規定するロジックは、サービスメッシュ層なしで各サービスにコード化できます。ただし、通信が複雑になってくると、サービスメッシュの重要性が増してきます。マイクロサービス・アーキテクチャで構築されたクラウドネイティブ・アプリケーションの場合、サービスメッシュは、多数の独立したサービスを機能的なアプリケーションにまとめる手段となります。

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

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

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

サービスメッシュでは、リクエストはそれぞれのインフラストラクチャ層内のプロキシを通じてマイクロサービス間を転送されます。この理由で、サービスメッシュを構成する個々のプロキシを「サイドカー」と呼ぶことがあります。各サービスの内部ではなく、並んで実行されるからです。まとめると、各サービスから切り離されたこのような「サイドカー」プロキシが、メッシュネットワークを形成します。

サイドカープロキシはマイクロサービスと並んで存在し、リクエストを他のプロキシに転送します。これらのサイドカーがまとまってメッシュネットワークを形成します。

サービスメッシュがなければ、各マイクロサービスはサービス間通信を規定するロジックをコーディングする必要があり、これでは開発者はビジネス目標に専念できなくなります。また、サービス間通信を規定するロジックが各サービス内に隠蔽されるので、通信エラーの診断が難しくなります。

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

そこで、サービスメッシュはサービス間通信のあらゆる局面をパフォーマンスメトリクスとして獲得します。そのうち、サービスメッシュで可視化されたデータをサービス間通信のルールに適用できるようになり、サービスリクエストの効率と信頼性が向上します。

たとえば、あるサービスが失敗した場合、サービスメッシュは再試行が成功するまでにかかった時間に関するデータを収集できます。あるサービスのエラー回数のデータを集約すると、このサービスを再試行するまでの最適な待機時間を決定するルールを作成できます。これにより、不要な再試行によってシステムが過負荷になることを防止できます。

マイクロサービスを構築中ならおそらく、迅速な拡張やビジネスニーズを満たす新規機能の追加など、この先生じるニーズを見越しているでしょう。マイクロサービス・アーキテクチャは、運用開始から 1 年も経てばまったく様子が変わってしまいます。まず、マイクロサービス内に構築されたライブラリは、運用へ影響を及ぼすことなく、サービス間通信を処理できるようになります。拡張性と機能を向上させてマイクロサービスの可能性を引き出そうとするなら、長くは続かないでしょう。そのうちサービスがリクエストで過負荷になって問題が発生し、開発者が各サービスのリクエストロジックのコーディングにかける時間が増えていきます。

サービスメッシュによって、次のようなメリットが実現します。

• 開発者は、サービスの接続よりもビジネス価値の付加に集中できる
• Jaeger を介したリクエストの分散トレースは、サービスと可視化されたインフラストラクチャ層を作成するため、問題の特定と診断が容易になる
• サービスメッシュは障害が起きたサービスからリクエストを転送し直せるので、アプリケーションのダウンタイムに対する回復力が増す
• パフォーマンスメトリクスでランタイム環境の通信を最適化する方法を提案できる

将来の計画を開始し、Red Hat® OpenShift® Service Mesh でサービスメッシュを試してみましょう。サービスメッシュにおいてネットワーク化されたマイクロサービスの動作に関する洞察と制御を提供するプラットフォームで、統一された方法で実行するマイクロサービスベースのアプリケーションの接続、管理、監視を体験してください。OpenShift Service Mesh は Red Hat OpenShift で利用できます (無料)。

Red Hat Ansible Automation Platform の Automation mesh コンポーネントは、自動化をスケーリングするための、シンプルで信頼性の高いサービスメッシュ・フレームワークを提供します。Automation mesh は、柔軟な多方向通信レイヤーを備えており、組織のグローバル規模での運用能力を高めます。レイテンシーや接続の障害、およびネイティブピアリング機能による影響を受けにくいため、現在市場に出回っている他の自動化プラットフォームと比較して信頼性が高く、到達範囲を拡張できます。TLS 認証や暗号化などのセキュリティ機能を備え、アクセス制御も向上しており、Red Hat Ansible Automation Platform を利用して、組織の IT 資産全体でできることの限界を広げることができます。