OpenShift Service Mesh とは？ – アーキテクチャのご紹介

こんにちは。サイオステクノロジーの塙です。

今回はRHが提供のOpenShift Container Platform（以下、OCP）製品に含まれる OpenShift Service Mesh（以下、OSM）についてご紹介します。

OpenShiftが何を目的とした製品なのか、何が出来るのかといった内容は割愛しています。

サービスメッシュ(Service Mesh)とは？

Kubernetesやコンテナ環境でアプリケーション開発などをしていると、サービスメッシュという言葉を聞いたことがあるのではないでしょうか。

サービスメッシュとは主に、アプリケーション間の通信制御などをインフラ側で制御してしまおうという技術です。

今までは、アプリケーション側で考慮してた可能性のある以下のようなものがありました。

これらをインフラ側で汲み取る事によってアプリケーションから通信処理を分離しています。

例えば上記だと、それぞれFrontend, Backend, Database アプリケーションが存在しますが、通信部分に関しては、サイドカー(Sidecar)として常駐しているコンテナ（Data Planeと呼ばれる）が担っているような形です。

別途、Control Planeが Data Planeと通信を行い、それらを監視し制御しています。

近年の傾向では、サービス（アプリケーション）の提供の迅速化や、システムの複雑化からの解消のため、マイクロサービス化の考えが浸透し始めてきたかと思います。一早くサービスの提供を目指す企業、そして開発者にとっては、アプリケーションの開発に集中出来るようになってくるわけですね。

またマイクロサービスの概要については、以下の記事でも詳しく書かれているのでご参考いただければと思います。

OpenShift Service Mesh は、サービスメッシュの実現に必要な複数のOSSを組み込んで成り立っています。

これは、OCPを拡張し、開発者の操作性を向上することを目的の一つとしています。

主に組み込まれているOSSは以下です。

istio
- 主にサービスメッシュ機能を提供しているメインとなるツールです。
  istio
Jaeger
- アプリケーション間のトレースを一元化および表示します。
  トレースには通信に関する様々な情報が含まれています。
  Jaeger
ElasticSearch
- JSON ベースの分散/検索/分析エンジンです。
  Jaeger によって生成されたトレースとログを保存します。
  ElasticSearch
kiali
- サービスメッシュの可観測性を提供します。
  kiali
Prometheus
- リソース使用状況などを監視するMonitoringツール。
  kialiに利用され、メトリクス、ヘルスステータスなどを取得しています。
  Prometheus

OSMでも、Control PlaneとData Planeの２つのコンポーネントで構成されています。

サービス間（上記各Pod間）の全てのInbound, Outboundトラフィックは、プロキシを通過することができます。

Control PlaneとData Plane それぞれについては、以下のような機能とコンポーネントが含まれています。

■ Control Plane

コンポーネント
- istiod
  - Pilot：サービス検出、トラフィック管理機能、耐障害性
  - Citadel：TLS証明書を発行してローテートを行ったり、サービス間通信の認証
  - Galley：サービスメッシュの設定を監視-> 検証 -> Proxyへ配布
機能
- Data Plane の設定、ポリシー管理

■ Data Plane

コンポーネント
- Envoy Proxy
- 各Envoy Proxyで実行されている(含まれている) istio-agent
  - 証明書のローテート、ルーティング、DNSドメイン設定などを自動化
機能
- サービスの追跡・監視
- サービスのヘルスチェック
- サービス間のトラフィック量の調整、ルーティング、サーキットブレーカーの役割
- mTLS（相互TLS認証）
- メトリクス、ログ、分散トレーシングの収集