サービスメッシュ、Istioがマイクロサービスのトラフィック制御、セキュリティ、可観測性に欠かせない理由：Cloud Nativeチートシート（9）

Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、近年注目を集める「サービスメッシュ」と、そのツールとして人気の高い「Istio」について解説します。

[北村卓也, 毛利健太郎, 望月敬太, 佐藤優太, 岡本隆史，株式会社NTTデータ]

近年注目のサービスメッシュ

　コンテナ技術やクラウドネイティブを語る文脈の中で、「サービスメッシュ」という単語を耳にする機会が増えてきたのではないでしょうか。Linux Foundation傘下のCloud Native Computing Foundation（CNCF）が2020年5〜6月に行った調査「CNCF SURVEY 2020」でも、調査対象のうち27％の組織が既に商用環境でサービスメッシュを利用しており、42％の組織が評価および計画フェーズにあると回答しています。

サービスメッシュの利用状況調査結果（「CNCF SURVEY 2020」から引用）

　このように注目のサービスメッシュとは何なのでしょうか。

　Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。今回から数回に分けてサービスメッシュの基本的な概念や、サービスメッシュのツールとして人気の高い「Istio」について説明します。

目次

• 「サービスメッシュ」とは
  • マイクロサービスアーキテクチャ
  • マイクロサービスアーキテクチャの課題
  • あらためてサービスメッシュとは
• サービスメッシュの基本アーキテクチャ
• サービスメッシュソフトウェアの比較
• コラム　Service Mesh InterfaceとOpen Service Mesh
• 「Istio」とは
• Istioのアーキテクチャ概要
  • データプレーン（Envoy）
  • コントロールプレーン（Istiod）
• Istioの機能
  • Traffic Management（トラフィック制御）
  • Security（セキュリティ）
  • Observability（可観測性）

「サービスメッシュ」とは

　サービスメッシュとは一言で表すと、「マイクロサービスアーキテクチャにおけるネットワーク面での課題を解決する機能群」といえます。そのため、サービスメッシュの説明をする前に、あらためて「マイクロサービスアーキテクチャ」とは何か、またどのような課題があるのかを解説します。

マイクロサービスアーキテクチャ

　従来のシステム開発では、アプリケーションに必要な全ての機能を1つのコンポーネント（サーバなど）にまとめて実装する「モノリシックアーキテクチャ」が主流でした。

　近年はコンテナ技術の台頭により、アプリケーションに必要な機能を1つのサービスと見なしてコンポーネント分離し、各サービス間を連携させることでアプリケーション全体を構成するマイクロサービスアーキテクチャが脚光を浴びています。マイクロサービスアーキテクチャを採用することで各サービス間の依存関係を疎結合にしたアーキテクチャを設計しやすくなるので、再利用性の向上や開発単位の最小化によるリリースサイクルの高速化、サービス単位でのスケールイン／スケールアウトのしやすさといったメリットが得られるようになります。

マイクロサービスアーキテクチャの課題

　マイクロサービスアーキテクチャでは、複数のサービスが連携して1つのシステムを構成する特徴からモノリシックアーキテクチャでは考慮する必要のなかった以下のような点が課題となります。

• サービス間のトラフィック制御
1. あるサービスから複数バージョンを有するサービスへのルーティングをどのように制御するか（BlueGreen Deployment、Canary Releaseをどのように行うか）
2. あるサービスが障害によって応答できなくなった場合の影響を局所化するために、障害が発生したサービスをどのように切り離すか
3. 特定のサービスに向けた想定を上回るリクエストが発生した際、リクエストをどう処理するか

• サービス間通信のセキュリティ確保
1. サービス間の通信をどのように保護するか
2. サービス間の通信可否をどのように制御するか

• アーキテクチャ全体像やサービス間のつながりの把握
1. 多数のサービスを連携させることで複雑になったシステム構成や通信の流れをどのように把握するか

あらためてサービスメッシュとは

　サービスメッシュという言葉を直訳すると「サービスの網」、つまりはマイクロサービスのように多数のサービスが複雑に接続された状態を指します。そこから転じて、一般的には上記のようなサービス間のトラフィック制御やセキュリティ、可観測性の確保といったマイクロサービスアーキテクチャを用いる場合に発生する課題を解決するための機能群を提供するプロダクトを指すケースが多いです。

　またマイクロサービスアーキテクチャは上記で述べた通り、多数のサービスを柔軟に起動、管理できる必要があることから、仮想マシンと比べてサービス起動やスケールコストの低いコンテナを用いて構成し、そこにサービスメッシュの機能を持たせることが一般的です。

　そのため、以下ではコンテナ基盤として代表的なKubernetes上でマイクロサービスアーキテクチャおよびサービスメッシュを扱う前提で説明を進めます。

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

　前述のマイクロサービスアーキテクチャの課題を解決するには、各マイクロサービスの単位で下記の機能を有する必要があります。

• サービスから出ていく通信の制御
• サービスに入ってくる通信の制御
• サービスに出入りする通信メトリクスの外部への送付

　これらの最も単純な実現方法としては、各サービスを構成するアプリケーションに、サービス間通信を規定するロジックを実装する方法が考えられます。しかし開発の進行に合わせて全てのサービス横通しで該当ロジックを維持することは困難なので、このアプリケーション層で全て吸収する方法はあまり現実的ではありません。

　そこで、早い段階からマイクロサービスを実践してきた企業は、各言語向けのライブラリを共通機能として実装することで、アプリケーション開発者をビジネスロジックに集中させるように努めてきました。

ライブラリを用いたサービス間通信

　しかし、この方法には下記のような課題がありました。

• 利用できる言語が限定されてしまう
• 言語ごとにライブラリを準備したとしても言語間で機能の整合性を保つのが難しい（例：Javaのライブラリに変更があった場合にGoのライブラリでも機能修正が必要となる）

　特にマイクロサービスアーキテクチャを採用する場合は、各サービス間で異なる言語を用いるケースも多いはずです。

　こうした課題を背景として、現在サービスメッシュを実装するアプローチとしてはアプリケーション層ではなくインフラストラクチャ層に機能を挿入する方法が一般的です。インフラストラクチャ層に挿入することで、ライブラリを用いた場合と比較して、言語にとらわれず一貫した機能を実装できるメリットがあります。

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

　また、一般的なサービスメッシュを構成するソフトウェアは、サイドカーとして実行されるL7プロキシと、プロキシの管理プロセスで構成されます。サイドカーはサービスメッシュの「データプレーン」と呼ばれ、管理プロセスは「コントロールプレーン」と呼ばれます。

・コントロールプレーン

　コントロールプレーンには、サービスメッシュの管理をサポートするコンポーネントがあります。例として、データプレーンのトラフィックルールを管理するコンポーネントや証明書などのセキュリティの側面を管理するコンポーネント、メトリックを収集して集計するコンポーネントなどが存在します。

・データプレーン

　データプレーンは、通常サイドカーとして透過的に挿入されるプロキシで構成されます。このプロキシは、アプリケーション間の全てのネットワークトラフィックを制御するように構成されています。これにより、プロキシは、トラフィック制限やセキュリティ保護、メトリック収集などができます。

サービスメッシュソフトウェアの比較

　CNCF SURVEY 2020によると、サービスメッシュの機能を提供するソフトウェアを商用環境で使用している人の中で最も人気があるのは、Istio、「Linkerd」「Consul」であり、今後も利用が大幅に増加することが示唆されています。多少の差異はありますが、類似のアーキテクチャとなっています。以降では、具体的なサービスメッシュの具体的なソフトウェア構成やその特徴を見ていきます。

　本記事では全ての機能を比較できませんが、ソフトウェアの特徴は下表のように整理できます。

	Istio	Linkerd	Consul
最新バージョン （2021年9月8日現在）	1.11.2	2.10.2	1.10.2
GitHub Stars （2021年9月8日現在）	2万7900	7500	2万2800
Service Proxy	Envoy	Linkerd2-proxy	Envoy（変更可）
メリット	・WebAssemblyによって、任意の言語を用いてService Proxyの拡張が可能 ・他の製品と比較して多くの機能を保持する（*1）	・他の製品と比較して、パフォーマンスの面で優れている（*2） ・機能が限定的なので、導入検討が容易	・HashiCorpによる有償版が提供されており、サポートが充実している ・Kubernetes以外への適応が可能
SMI対応方式	アダプター形式	標準対応（一部機能）	標準対応（一部機能）
*1：Service Mesh Comparison *2：Benchmarking Linkerd and Istio

　いずれのソフトウェアも非常に人気があり、どれを選択するかは判断が難しいところですが、本記事ではIstioを紹介します。

コラム　Service Mesh InterfaceとOpen Service Mesh

　Service Mesh Interface（SMI）は、サービスメッシュではなく、サービスメッシュ機能のAPI仕様です。現在、サービスメッシュを提供するソフトウェアはそれぞれAPIが異なるので、サービスメッシュを利用するアプリケーションは、特定のサービスメッシュソフトウェアに依存したものにならざるを得ません。

　そこで、サービスメッシュソフトウェアに依存せずにサービスメッシュ機能を設定するためのAPI仕様がMicrosoft、Buoyant（Linkerdの開発企業）、HashiCorp（Consulの開発企業）によって発表されています。

　APIは、KubernetesのCustom Resource Definitions（CRD）として定義されているため、サービスメッシュのユーザーは設定を変更することなく、サービスメッシュのソフトウェアを変更できます。

　現時点では、4つのAPIが提供されています。

• Traffic Access Control
  トラフィックのアクセス制御ポリシーを指定
• Traffic Metrics
  指定したトラフィックのメトリクスを出力
• Traffic Specs
  他のAPIの対象となるトラフィックを指定し、使用できるルートを定義
• Traffic Split
  トラフィックを指定した割合で分割

　こうしたSMIの仕様に関するレファレンス実装としてMicrosoftが発表したソフトウェアが、「Open Service Mesh（OSM）」です。IstioやLinkerd、Consulといった他のサービスメッシュソフトウェアと同様に標準的なサービスメッシュの機能を持っており、Service ProxyにはEnvoy（後述）を使用しています。2021年6月1日時点で最新バージョンは0.8.4であり、将来CNCFに寄贈することも発表されています。

「Istio」とは

　Istioは、Google、IBM、Lyftが開発したサービスメッシュのオープンソースソフトウェア（OSS）です。2018年7月にバージョンが1.0に到達しています。当初、IstioはKubernetesのみを対象としていましたが、現在ではプラットフォームに依存せず、クラウドやオンプレミス、Kubernetesなど、さまざまな環境で動作するように設計されています。

　近年ではIstioをベースとした製品として、Googleが提供する「Anthos Service Mesh」やRed Hatが提供する「Red Hat OpenShift Service Mesh」などを採用することで商用サポートを受けることも可能となっています。

Istioのアーキテクチャ概要

　Istioのアーキテクチャは、下図の通りです。「サービスメッシュの基本アーキテクチャ」で紹介した、データプレーンとコントロールプレーンで構成されています。

アーキテクチャ図（Istio公式サイトから引用）

　それぞれ、詳細を紹介します。

データプレーン（Envoy）

　Istioのデータプレーンには、「Envoy」というソフトウェアの拡張バージョンが利用されています。Envoyは、C++で開発された高性能プロキシOSSです。L3/L4/L7レイヤーをカバーしており、HTTP、HTTPS、gRPC、TCPに対応しています。2017年9月にCNCFにホストされ、2018年11月にはGraduatedプロジェクトとして認定されました。

　IstioはEnvoyプロキシを、サイドカープロキシとして各アプリケーションPodに展開します。Envoyは各Podの全ての通信を仲介し、通信の制御や、通信のテレメトリー（通信の内容、応答時間、トレース情報など）の収集を行います。

　Envoyプロキシの展開は、Kubernetesの「Admission Webhook」という仕組みを利用して、Istioに自動で実行させることができます。また、Envoyはサイドカープロキシとして動作しているので、アプリケーションはプロキシの存在を意識する必要がありません。そのため、開発者はデプロイ方法やコードを変更することなく、既存のアプリケーションにIstioを適用できます。

　ただし、認証や分散トレーシングを導入する場合には、アプリケーションの実装も必要となります。認証のアクセストークンや、分散トレーシングに必要なトレースコンテキストをリクエストヘッダに伝搬するのは、アプリケーションの役割だからです。例えばトレースコンテキストの伝搬は、「OpenTracing」「Spring Cloud Sleuth」といったライブラリをアプリケーションに導入することで実現できます。

コントロールプレーン（Istiod）

　Istioにおいてコントロールプレーンの役割を果たすのは、「Istiod」というコンポーネントです。Istiodは単一バイナリとして提供されており、サービスディスカバリ、構成管理、証明書管理といった機能を持っています。各機能はIstiod内部に存在する「Pilot」「Citadel」「Galley」というコンポーネントが担っています。

• Pilot
  Envoyプロキシのサービスディスカバリを提供するコンポーネント。また、ルーティングルールを各Envoyプロキシに伝搬することで、トラフィック制御（A/Bテスト、Canary Releaseなど）を実現する
• Galley
  Istioの構成検証、配布を行うコンポーネント。基盤となるプラットフォーム（Kubernetes、VMなど）とIstioを分離する役割を果たす
• Citadel
  認証局（CA）として機能し、サービス間およびエンドユーザー認証を可能にする

Istioの機能

　Istioの機能を用いることでアプリケーションに手を加えずにトラフィックを制御し、セキュリティと可観測性を向上させることができます。

Traffic Management（トラフィック制御）

　Istioのトラフィック制御機能により、サービス間のトラフィックとAPI呼び出しのフローを制御できます。

　以下の表はIstioのトラフィック制御機能に利用する代表的なリソースです。トラフィック制御に関わるその他のIstioリソースは、Istioの公式サイトを参照してください。

Istioのリソース	リソース概要	機能詳細
Gateway	メッシュに出入りするトラフィックを管理できる Ingress Gatewayはメッシュの境界に位置し、メッシュ外からの通信を受信する	・公開するポートの設定 ・ホスト単位のルーティング設定 ・エンドポイントのTLS設定 ・HTTP接続のHTTPSへのリダイレクト
Virtual Service	サービスメッシュ内のサービスにリクエストをルーティングする方法を構成できる	・PATHベースルーティング ・パーセンテージベースのトラフィック分割 ・HTTPリクエストのヘッダの追加や削除 ・HTTPリクエストのURL書き換え ・HTTPリクエストのタイムアウト設定 ・HTTPリクエストのリトライ設定 ・サーキットブレーカー ・トラフィックのミラーリング ・フォールトインジェクション
Destination Rule	ルーティングの宛先に対するトラフィックの挙動を構成する	・ロードバランサーアルゴリズムの設定 ・ワークロードの実行地域に応じたルーティング制御 ・TCPまたはHTTPでのコネクションプールの設定 ・異常ホストへのサーキットブレーカーの設定 ・接続のTLS設定 ・HTTP接続の制御（最大数、リトライ数、タイムアウト制御など）
Service Entry	内部サービスレジストリに外部サービスのエントリを追加できる	・メッシュ外のインスタンスをレジストリに追加 ・適切な外部サービスへのルーティング

トラフィック制御の模式図

Security（セキュリティ）

　Istioでは、アプリケーションコードとインフラストラクチャを変更することなく、マイクロサービスを保護できます。Istioのセキュリティ機能は、強力なID、強力なポリシー、透過的なTLS暗号化、および認証、承認、監査ツールを提供して、サービスとデータを保護します。これによって、いわゆる「ゼロトラストネットワーク」を構築できます。

　下表はセキュリティに関わるIstioの代表的なリソースです。その他のリソースはIstioの公式サイトを参照してください。

Istioのリソース	概要
Authorization Policy	メッシュ内のワークロードのアクセス制御を可能にする
Peer Authentication	ワークロードの相互TLS設定を定義する
Request Authentication	ワークロードでサポートされる要求認証方法を定義する

Observability（可観測性）

　マイクロサービスアーキテクチャではマイクロサービス間の通信が複雑化するので、従来のアーキテクチャ以上にトラフィックの情報収集など観測性が重要になります。Istioは可観測性を支える、メトリクス、ログ、トレーシングの機能を備えておりシステムの全体像やトラフィック状況を把握することが容易になります。

可観測性の種類	概要
メトリクス	・リクエストとレスポンスのメトリクスを収集できるので、通信の状況を把握するのに役立つ ・メトリクスは「Prometheus」で収集し、Grafanaなどの可視化ツールを用いて可視化できる
ログ	・サイドカープロキシでコンテナを出入りする通信のアクセスログを収集できる
トレーシング	・サービスのコールフローをトレースできるので、性能低下時のボトルネック解析に活用できる ・「Kiali」「Jaeger」などの可視化ツールを用いてアーキテクチャ全体像や通信を可視化できる

まとめ

　今回は、マイクロサービスアーキテクチャの課題にひも付けてサービスメッシュの概念や、サービスメッシュのOSS、Istioの概要を紹介しました。サービスメッシュはその言葉自体が抽象的だったり、その中に多くの機能が含まれていたりと理解が難しい面もありますが、近年注目を集めている重要な技術です。

　次回からは、今回紹介したIstioを使って、サービスメッシュの機能を動かしながら解説します。