Service Mesh in 2022

© Hitachi, Ltd. 2022. All rights reserved.
Service Mesh in 2022
Oracle Cloud Hangout Café 6 #1
株式会社日立製作所
研究開発グループ
サービスコンピューティング研究部
井出貴也

View Slide

内容
1. Service Meshの背景
2. Service Meshのトレンド
3. Service Meshの今後
1

View Slide

各サービスの前段に配置したプロキシをコントロールプレーンで制御するネットワークモデル
Service Meshとは
2
Service Mesh
嬉しさ
システム全体で一貫性の
ある運用機能をサービスへ
透過的に付与できる
主要機能
▪ トラフィック制御
▪ 信頼性向上
▪ 認証認可
▪ オブザーバビリティ(監視)
Proxy Proxy
Svc1 Svc2
サービス間通信
宛先の変更
通信暗号化
アクセス制御
メトリクス出力
運用者
Control
Plane
制御
操作

View Slide

1. Service Meshの背景
3

View Slide

Microservice Architecture
▪ 複数の小さなサービスを通信で連携させることでシステムを構成する設計方式
▪ サービスごとに小さなチームが存在し、自律的に開発・運用
▪ 利点：各サービスの独立性が高い
◇ 変更しやすい
◇ 仕様の自由度が高い
◇ 開発規模を広げやすい
4
Microservices Architecture
UI
決済
商品
推薦
注文
管理
商品
管理
ユーザ
管理
発注
決済サービス
チーム
発注サービス
チーム

View Slide

Microservicesの成長
▪ ビジネスの成長に伴いシステムは大きくなる
◇ サービスやサービスチームが増加
◇ それぞれのサービスが随時変化していく
◇ サービスの開発言語や品質も様々
5

View Slide

Microservicesの運用
Microservicesをどのように運用するか？
◇ サービス間のルーティングは？
◇ 通信のアクセス制御は？
◇ システム全体の可視化は？
6

View Slide

Microservices運用方法の模索
7
各サービスチームが課題を個別解決 →
▪ 開発・運用の工数が大きい
▪ 仕様や品質がバラバラになる
共通機能をライブラリ化し、各チームに提供 →
▪ サービスの言語ごとにライブラリを作る必要あり
▪ サービスのライフサイクルがライブラリに縛られる
各サービスからは透過的で、かつシステム全体に渡って一貫性のある
運用ポリシーの適用が望ましい
→ サービス間通信を利用できないか

View Slide

Service Meshのアイデア
各サービスは通信で連携している
→
→
8
Svc1 Svc2
運用者

View Slide

→ サービスの前段に配置したプロキシ(Sidecar Proxy)で、サービス間通信を制御し、運用機能を適用
→
9
Proxy Proxy
Svc1 Svc2
宛先の変更
通信暗号化
アクセス制御
運用者

View Slide

→ サービスの前段に配置したプロキシ(Sidecar Proxy)で、サービス間通信を制御し、運用機能を適用
→ 多量に出てくるプロキシはコントロールプレーンで一元的に管理
10
Proxy Proxy
Svc1 Svc2
宛先の変更
通信暗号化
アクセス制御
運用者
Control
Plane
制御
操作

View Slide

各サービスの前段に配置したプロキシをコントロールプレーンで制御するネットワークモデル
[再掲] Service Meshとは
11
嬉しさ
システム全体で一貫性の
ある運用機能をサービスへ
透過的に付与できる
主要機能
▪ トラフィック制御
▪ 信頼性向上
▪ 認証認可
▪ オブザーバビリティ(監視)
Service Mesh
Proxy Proxy
Svc1 Svc2
宛先の変更
通信暗号化
アクセス制御
運用者
Control
Plane
制御
操作

View Slide

2. Service Meshのトレンド
12

View Slide

CNCF※1 Service Mesh Micro Survey
▪ CNCFによるService Meshのユーザ調査
◇ 2022.5.17 公開
▪ 本サーベイおよび過去CNCF Surveyから
いくつかのデータを紹介
▪ 注意：CNCFサイトでのアンケートに基づく
データのためCloud Native有識者のバイアスあり
◇ 回答者の50%がソフトウェア企業
◇ また、50%がSRE or DevOps Engineer
13
画像引用元: https://www.cncf.io/wp-content/uploads/2022/05/CNCF_Service_Mesh_MicroSurvey_Final.pdf
※1 CNCF(Cloud Native Computing Foundation) : Linux Foundation配下の団体

View Slide

Service Mesh利用率の変遷
▪ CNCF Survey 2019-2022での利用率の変遷
▪ Service Meshの利用率は年々上昇（要バイアス考慮）
14
18%
27%
60%
47%
42%
29%
35%
31%
11%
2019
2020
2021
2022
(記載なし)
[年]
Service Meshの利用率
本番利用中評価中不使用

View Slide

ツール別利用率
▪ Linkerd、Istioが利用の中心。特にLinkerdの利用率は著しく増加
▪ 利用率上位はOSSが占める（何れもバイアスの考慮要）
15
73%
34%
11%
7%
6%
6%
8%
Linkerd
Istio
Traefik
Consul
AWS App Mesh
Open Service Mesh
Other
47%
41%
41%
30%
28%
24%
62%
Istio
Linkerd
Consul
Grey Master
Netflix Zuul
SuperGloo
Other
2022年ツール別利用率(利用計画中を含む)
(参考) 2020年ツール別利用率(含計画中)

View Slide

Service Meshの利用目的
▪ セキュリティやオブザーバビリティを目的としたService Meshの導入が多い
▪ ただし、特定機能のみを目的にService Meshを導入する場合、運用負荷に見合うか注意
16
Service Meshの利用目的
セキュリティ 79%
オブザーバビリティ 78%
トラフィック制御 62%
信頼性向上 56%

View Slide

Service Mesh導入における課題
▪ 技術面では、設計やサービスとの統合を課題視
▪ 技術以外では、人材やプラクティスの獲得に難あり
▪ Service Mesh導入時には、これら課題を乗り越えるだけの体制であるか検討要
17
1. サービスとの統合
2. 一貫性や信頼性の設計
3. ポリシーの設定
4. 監視やトレーシングの設計
技術的な課題
1. 有識者の不足
2. アーキテクチャの複雑さ
3. プラクティスの不足
4. ツールの選定
技術以外の課題

View Slide

3. Service Meshの今後
18

View Slide

Service MeshにおけるeBPF※1の活用
▪ Service Meshの一部機能や通信最適化にeBPFが活用され始めている
▪ eBPF：Kernel内のサンドボックス環境でプログラムを動作させるLinux Kernelの機能
◇ システムコールやネットワーク処理等のKernel内イベントをフックして動作
19
▪ カーネル/ユーザ空間の切り替えや
データコピーのオーバーヘッド削減
▪ Kernelネットワーク処理のバイパス
▪ プロキシレスで一部機能を利用可
能とすることでの導入の敷居低下
Service Meshにおける
eBPFの利点
画像引用元: https://eBPF.io/
※1 extended Berkeley Packet Filterが語源だが、左記の公式サイト曰く「もはや略称ではない」
Svc2
Svc1
...
Kernel Space User Space
System Call
TCP/IP
Socket
Traffic Control
Driver
イベントフック
通信転送
監視(L4)
アクセス
制御(L4)
Service MeshにおけるeBPF活用イメージ

View Slide

eBPFを使えばサイドカープロキシは不要になるのか
不要にはならない。サイドカープロキシは依然として必要と考えられる
▪ 安全のためeBPFの処理には制限があり、プロキシの機能置き換えは現状困難
▪ ホスト上のサービス全てを共通のeBPFで処理するとノイジーネイバーやセキュリティの懸念あり
20
▪ 共有ライブラリ不可、浮動小数点不可、
スタック領域は最大512バイト
▪ 特権ユーザ以外、命令数は4096個まで
▪ L4(TCP/UDP)より上の通信処理は自作要
→ 現状ではプロキシ機能の開発・保守難度高
eBPFの制限
▪ リソースを制限できないため、高負荷な
サービスがリソースを枯渇させうる
▪ ホスト上の全サービスのセキュリティ情報が
載るため、クラッキング時の被害が大きい
▪ 障害がホスト上のサービス全体に影響
共通のeBPFプログラムを用いた際の問題

View Slide

Service Meshの今後
今後はeBPFとサイドカープロキシが協調動作するようになるのではないか
▪ Service Meshの基本的な処理はサイドカープロキシで処理
▪ eBPFにてKernelのネットワーク処理をバイパスし処理高速化
▪ また、オブザーバビリティなどeBPFの得意な一部タスクがサイドカープロキシからオフロード
21
Node1
Service1 Pod
Sidecar Proxy
App
Service2 Pod
Sidecar Proxy
App
Service3 Pod
App
Service4 Pod
App
Node2
...
サイドカープロキシとeBPFの協調動作
基本処理は
プロキシで実施
Kernel処理を
バイパス
通信メトリクス収集
→ Service Mesh外の
サービスにも適用可
Sniffing Sniffing Sniffing Sniffing

View Slide

eBPFベースのツール
eBPFにて通信最適化やオブザーバビリティを実現しているツールとして以下を紹介
▪ Cilium : eBPFを用いたKubernetesのCNI(コンテナ間通信を実現するツール)
▪ Pixie : eBPFを用いたL7(HTTP, MySQL等)メトリクス収集ツール
22

View Slide

Node Node
Cilium
▪ eBPFにて通信最適化やL4(TCP/UDP)までのトラフィック制御を実現
◇ eBPFを用いた通信最適化はMerbridgeやistio-tcpip-bypass等も存在※1
▪ HTTPの処理などの高次機能はホスト単位に配備されたプロキシにて処理（Appendix参照）
23
Svc1 Pod
Sidecar Proxy
App
Loopback veth
TCP/IP
Ethernet Ethernet
eth0
Socket
TCP/IP
iptables
Ethernet
Socket
TCP/IP
Ethernet
Socket
TCP/IP
iptables
Ethernet
Svc1 Pod
Host Proxy
App
Socket Socket Socket
TCP/IP
Ethernet
※1 https://istio.io/latest/blog/2022/merbridge/ ベンチマークを見ると0~20%弱の改善効果
一般的なService Meshの通信処理 eBPFを用いた通信処理
eth0

View Slide

Pixie
▪ トラフィックのL7(HTTP, MySQLなど)メトリクスを解析・収集 (システムコールを利用)
▪ eBPFベースのメトリクス収集は暗号化通信の対応が課題
→ PixieはOpenSSL等の暗号化ライブラリへの入力を捕捉することで、一部の暗号化通信に対応
24
System Call
connect send recv close
App
暗号化ライブラリ
(例 openssl.so)
SSL_write SSL_read
収集
Pixie Edge
Module
解析・保存
PixieによるeBPFベースの通信メトリクス収集
User Space
Kernel Space

View Slide

まとめ
Service Meshとは
▪ プロキシを活用したネットワークモデル
▪ 各サービスからは透過的、かつシステム全体で一貫した運用を行う
トレンド
▪ CNCF Surveyによると利用者は年々増加、Linkerd・Istioの利用者が多い
▪ 既存サービスとの統合やプラクティスの獲得が課題
今後
▪ 通信最適化や監視などでeBPFが活用され始めている
▪ 将来的にはeBPFとプロキシが協調動作するようになるのではないか
25

View Slide

参考文献
1. William Morgan, “The Service Mesh: What every software engineer needs to know about the world’s most over-hyped technology”,
Buoyant, https://buoyant.io/service-mesh-manifesto (accessed Aug 26, 2022)
2. “CNCF Service Mesh Micro Survey 2022”, Cloud Native Computing Foundation,
https://www.cncf.io/wp-content/uploads/2022/05/CNCF_Service_Mesh_MicroSurvey_Final.pdf (accessed Aug 26, 2022)
3. “CNCF Survey 2020”, Cloud Native Computing Foundation,
https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf (accessed Aug 26, 2022)
4. “CNCF Survey 2019”, Cloud Native Computing Foundation,
https://www.cncf.io/wp-content/uploads/2020/08/CNCF_Survey_Report.pdf (accessed Aug 26, 2022)
5. “What is eBPF? An Introduction and Deep Dive into the eBPF Technology”
https://eBPF.io/what-is-eBPF (accessed Aug 26, 2022)
6. Brendan Gregg “Systems Performance, 2nd Edition” Addison-Wesley (2022)
7. William Morgan, “eBPF or Not, Sidecars are the Future of the Service Mesh”, The New Stack (2022)
8. BPF and XDP Reference Guide, https://docs.cilium.io/en/latest/bpf (accessed Aug 26, 2022)
9. “Try eBPF-powered Cilium Service Mesh - join the beta program!”, Cilium,
https://cilium.io/blog/2021/12/01/cilium-service-mesh-beta/ (accessed Aug 26, 2022)
10. “Next-Generation Mutual Authentication with Cilium Service Mesh”, Isovalent
https://isovalent.com/blog/post/2022-05-03-servicemesh-security/ (accessed Aug 26, 2022)
11. "Merbridge - Accelerate your mesh with eBPF" https://istio.io/latest/blog/2022/merbridge/ (accessed Aug 26, 2022)
12. “How Pixie uses eBPF“ https://docs.px.dev/about-pixie/pixie-eBPF/ (accessed Aug 26, 2022)
26

View Slide

商標
▪ Istioは、Open Usage Commonsの米国にまたはその他の国における登録商標または商標です
▪ Linux, Linkerd, eBPF, Cilium, Pixieは、
The Linux Foundationの米国またはその他の国における登録商標または商標です
▪ MerbridgeはDaoCloudの米国またはその他の国における登録商標または商標です
▪ istio-tcpip-bypassはIntelの米国またはその他の国における登録商標または商標です
▪ その他記載の会社名、製品名、サービス名、その他固有名詞は、
それぞれの会社の商標または登録商標です
▪ 本発表中の文章、図では、TM、🄬マークは表記しておりません。
27

View Slide

Appendix1 : プロキシの配置パターン
28
プロキシの配置パターンは幾つか存在。現在はProxy per Application Instanceが主流
方法 Single Proxy Proxy per Host
Proxy per
Application
Proxy per
Application Instance
概要
すべてのアプリケーションで一つ
のプロキシを共有
k8sのノードなど，マシンの単
位でプロキシを配置
Microserviceの単位でプロキ
シを配置
Podなどの各インスタンスの前
段にプロキシを配置 (Sidecar
Proxy)
利点
消費リソースが少ない。シンプ
ルな構成。通信時に経由する
プロキシが一つのみ
ホストごとに負荷が分散される。
ホスト内で閉じる通信はオーバ
ヘッドが少ない
従来のリバースプロキシの運用
に近いため，移行時の混乱が
が比較的少ない
インスタンスごとに負荷が分散
される。インスタンスごとのきめ
細かい暗号化ができる
欠点
負荷が1箇所に集中する。単
一障害点になりうる
ノイジーネイバーの問題が起こり
うる。また、障害や脆弱性を突
かれた際にホスト上のインスタ
ンス全てに影響が出る
障害時，アプリケーション内の
インスタンスすべてに影響が出
る
リソース消費が多い。プロキシ
のアップデートにはインスタンス
再起動が必要
採用例 -
Linkerd1.0
Cilium
-
Istio
Linkerd2.0
Kuma

View Slide

Appendix2: Proxy per Host
ホスト単位にプロキシを配置すると負荷の競合や設定複雑化などの問題あり
▪ プロキシにホスト上の全サービス分の設定が記述され保守性が低下
▪ 高負荷なアプリが他アプリに影響。QoSやリソース制限の仕組みは現状なし
▪ 秘密鍵などの情報が単一プロキシに集約され、クラッキング時の被害が大きい
▪ 障害時、ホスト全体に影響が出る
Linkerdは当初ホスト単位にプロキシを配置していたものの、上記の理由により
2017年、構成をサイドカープロキシ(proxy per application instance)に変更
参考: William Morgan, “eBPF or Not, Sidecars are the Future of the Service Mesh”, The New Stack
https://thenewstack.io/eBPF-or-not-sidecars-are-the-future-of-the-service-mesh/

View Slide

View Slide

Service Mesh in 2022

Service Mesh in 2022

id

More Decks by id

Other Decks in Technology

Featured

Transcript