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

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

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

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

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

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

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

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

• 通信間の暗号化
• 通信のトレーシングやメトリクス
• HTTP通信内の制御など

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

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

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

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

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

[CNDT2020]サービスメッシュって何？

OpenShift Service Mesh 概要

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

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

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

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

OpenShift Service Mesh アーキテクチャ

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認証）
  • メトリクス、ログ、分散トレーシングの収集

上記の図のようにトラフィックに関わる部分はData Planeが担っており、サービス（アプリケーション）から分離しているということがイメージしやすいかと思います。

また詳細については、以下を参考いただければと思います。

https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html-single/service_mesh/index#ossm-architecture_ossm-architecture

https://istio.io/latest/docs/ops/deployment/architecture/

まとめ

今回は、OpenShift Service Mesh のアーキテクチャについて紹介させていただきました。

様々なアプリケーションがプラットフォーム内部で混在し、管理が複雑になってくると、サービスメッシュの実用性についても少し感じられてくるのかなと思った次第です。

次回は、OpenShift Service Mesh のインストールから検証したいと思います。

About nha 9 Articles

2023年にSIOSへ入社。前職では、インフラでOSS系をメインとしたシステム構築や自動化系(CI/CD)のタスクに従事。コードもたまに書いてます。コンテナを中心とした対応を行っています。