Service Mesh in 2022

Service Meshの背景やトレンド、また今後の展望としてeBPF連携の動向を紹介します。

Transcript

1. © Hitachi, Ltd. 2022. All rights reserved. Service Mesh in 2022 Oracle Cloud Hangout Café 6 #1 株式会社 日立製作所 研究開発グループ サービスコンピューティング研究部 井出 貴也
2. © Hitachi, Ltd. 2022. All rights reserved. 内容 1. Service Meshの背景 2. Service Meshのトレンド 3. Service Meshの今後 1
3. © Hitachi, Ltd. 2022. All rights reserved. 各サービスの前段に配置したプロキシをコントロールプレーンで制御するネットワークモデル Service Meshとは 2 Service Mesh 嬉しさ システム全体で一貫性の ある運用機能をサービスへ 透過的に付与できる 主要機能 ▪ トラフィック制御 ▪ 信頼性向上 ▪ 認証認可 ▪ オブザーバビリティ(監視) Proxy Proxy Svc1 Svc2 サービス間通信 宛先の変更 通信暗号化 アクセス制御 メトリクス出力 運用者 Control Plane 制御 操作
4. © Hitachi, Ltd. 2022. All rights reserved. 1. Service Meshの背景 3
5. © Hitachi, Ltd. 2022. All rights reserved. Microservice Architecture ▪ 複数の小さなサービスを通信で連携させることでシステムを構成する設計方式 ▪ サービスごとに小さなチームが存在し、自律的に開発・運用 ▪ 利点：各サービスの独立性が高い ◇ 変更しやすい ◇ 仕様の自由度が高い ◇ 開発規模を広げやすい 4 Microservices Architecture UI 決済 商品 推薦 注文 管理 商品 管理 ユーザ 管理 発注 決済サービス チーム 発注サービス チーム
6. © Hitachi, Ltd. 2022. All rights reserved. Microservicesの成長 ▪ ビジネスの成長に伴いシステムは大きくなる ◇ サービスやサービスチームが増加 ◇ それぞれのサービスが随時変化していく ◇ サービスの開発言語や品質も様々 5
7. © Hitachi, Ltd. 2022. All rights reserved. Microservicesの運用 Microservicesをどのように運用するか？ ◇ サービス間のルーティングは？ ◇ 通信のアクセス制御は？ ◇ システム全体の可視化は？ 6
8. © Hitachi, Ltd. 2022. All rights reserved. Microservices運用方法の模索 7 各サービスチームが課題を個別解決 → ▪ 開発・運用の工数が大きい ▪ 仕様や品質がバラバラになる 共通機能をライブラリ化し、各チームに提供 → ▪ サービスの言語ごとにライブラリを作る必要あり ▪ サービスのライフサイクルがライブラリに縛られる 各サービスからは透過的で、かつシステム全体に渡って一貫性のある 運用ポリシーの適用が望ましい → サービス間通信を利用できないか
9. © Hitachi, Ltd. 2022. All rights reserved. Service Meshのアイデア 各サービスは通信で連携している → → 8 Svc1 Svc2 サービス間通信 運用者
10. © Hitachi, Ltd. 2022. All rights reserved. Service Meshのアイデア 各サービスは通信で連携している → サービスの前段に配置したプロキシ(Sidecar Proxy)で、サービス間通信を制御し、運用機能を適用 → 9 Proxy Proxy Svc1 Svc2 サービス間通信 宛先の変更 通信暗号化 アクセス制御 メトリクス出力 運用者
11. © Hitachi, Ltd. 2022. All rights reserved. Service Meshのアイデア 各サービスは通信で連携している → サービスの前段に配置したプロキシ(Sidecar Proxy)で、サービス間通信を制御し、運用機能を適用 → 多量に出てくるプロキシはコントロールプレーンで一元的に管理 10 Proxy Proxy Svc1 Svc2 サービス間通信 宛先の変更 通信暗号化 アクセス制御 メトリクス出力 運用者 Control Plane 制御 操作
12. © Hitachi, Ltd. 2022. All rights reserved. 各サービスの前段に配置したプロキシをコントロールプレーンで制御するネットワークモデル [再掲] Service Meshとは 11 嬉しさ システム全体で一貫性の ある運用機能をサービスへ 透過的に付与できる 主要機能 ▪ トラフィック制御 ▪ 信頼性向上 ▪ 認証認可 ▪ オブザーバビリティ(監視) Service Mesh Proxy Proxy Svc1 Svc2 サービス間通信 宛先の変更 通信暗号化 アクセス制御 メトリクス出力 運用者 Control Plane 制御 操作
13. © Hitachi, Ltd. 2022. All rights reserved. 2. Service Meshのトレンド 12
14. © Hitachi, Ltd. 2022. All rights reserved. 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配下の団体
15. © Hitachi, Ltd. 2022. All rights reserved. Service Mesh利用率の変遷 ▪ CNCF Survey 2019-2022での利用率の変遷 ▪ Service Meshの利用率は年々上昇（要バイアス考慮） 14 18% 27% 60% 47% 42% 29% 35% 31% 11% 2019 2020 2021 2022 (記載なし) [年] Service Meshの利用率 本番利用中 評価中 不使用
16. © Hitachi, Ltd. 2022. All rights reserved. ツール別利用率 ▪ 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年 ツール別利用率(含 計画中)
17. © Hitachi, Ltd. 2022. All rights reserved. Service Meshの利用目的 ▪ セキュリティやオブザーバビリティを目的としたService Meshの導入が多い ▪ ただし、特定機能のみを目的にService Meshを導入する場合、運用負荷に見合うか注意 16 Service Meshの利用目的 セキュリティ 79% オブザーバビリティ 78% トラフィック制御 62% 信頼性向上 56%
18. © Hitachi, Ltd. 2022. All rights reserved. Service Mesh導入における課題 ▪ 技術面では、設計やサービスとの統合を課題視 ▪ 技術以外では、人材やプラクティスの獲得に難あり ▪ Service Mesh導入時には、これら課題を乗り越えるだけの体制であるか検討要 17 1. サービスとの統合 2. 一貫性や信頼性の設計 3. ポリシーの設定 4. 監視やトレーシングの設計 技術的な課題 1. 有識者の不足 2. アーキテクチャの複雑さ 3. プラクティスの不足 4. ツールの選定 技術以外の課題
19. © Hitachi, Ltd. 2022. All rights reserved. 3. Service Meshの今後 18
20. © Hitachi, Ltd. 2022. All rights reserved. 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活用イメージ
21. © Hitachi, Ltd. 2022. All rights reserved. eBPFを使えばサイドカープロキシは不要になるのか 不要にはならない。サイドカープロキシは依然として必要と考えられる ▪ 安全のためeBPFの処理には制限があり、プロキシの機能置き換えは現状困難 ▪ ホスト上のサービス全てを共通のeBPFで処理するとノイジーネイバーやセキュリティの懸念あり 20 ▪ 共有ライブラリ不可、浮動小数点不可、 スタック領域は最大512バイト ▪ 特権ユーザ以外、命令数は4096個まで ▪ L4(TCP/UDP)より上の通信処理は自作要 → 現状ではプロキシ機能の開発・保守難度高 eBPFの制限 ▪ リソースを制限できないため、高負荷な サービスがリソースを枯渇させうる ▪ ホスト上の全サービスのセキュリティ情報が 載るため、クラッキング時の被害が大きい ▪ 障害がホスト上のサービス全体に影響 共通のeBPFプログラムを用いた際の問題
22. © Hitachi, Ltd. 2022. All rights reserved. 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 ... 画像引用元: https://eBPF.io/ サイドカープロキシとeBPFの協調動作 基本処理は プロキシで実施 Kernel処理を バイパス 通信メトリクス収集 → Service Mesh外の サービスにも適用可 Sniffing Sniffing Sniffing Sniffing
23. © Hitachi, Ltd. 2022. All rights reserved. eBPFベースのツール eBPFにて通信最適化やオブザーバビリティを実現しているツールとして以下を紹介 ▪ Cilium : eBPFを用いたKubernetesのCNI(コンテナ間通信を実現するツール) ▪ Pixie : eBPFを用いたL7(HTTP, MySQL等)メトリクス収集ツール 22
24. © Hitachi, Ltd. 2022. All rights reserved. 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 画像引用元: https://eBPF.io/
25. © Hitachi, Ltd. 2022. All rights reserved. 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ベースの通信メトリクス収集 画像引用元: https://eBPF.io/ User Space Kernel Space
26. © Hitachi, Ltd. 2022. All rights reserved. まとめ Service Meshとは ▪ プロキシを活用したネットワークモデル ▪ 各サービスからは透過的、かつシステム全体で一貫した運用を行う トレンド ▪ CNCF Surveyによると利用者は年々増加、Linkerd・Istioの利用者が多い ▪ 既存サービスとの統合やプラクティスの獲得が課題 今後 ▪ 通信最適化や監視などでeBPFが活用され始めている ▪ 将来的にはeBPFとプロキシが協調動作するようになるのではないか 25
27. © Hitachi, Ltd. 2022. All rights reserved. 参考文献 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
28. © Hitachi, Ltd. 2022. All rights reserved. 商標 ▪ Istioは、Open Usage Commonsの米国にまたはその他の国における登録商標または商標です ▪ Linux, Linkerd, eBPF, Cilium, Pixieは、 The Linux Foundationの米国またはその他の国における登録商標または商標です ▪ MerbridgeはDaoCloudの米国またはその他の国における登録商標または商標です ▪ istio-tcpip-bypassはIntelの米国またはその他の国における登録商標または商標です ▪ その他記載の会社名、製品名、サービス名、その他固有名詞は、 それぞれの会社の商標または登録商標です ▪ 本発表中の文章、図では、TM、🄬マークは表記しておりません。 27
29. © Hitachi, Ltd. 2022. All rights reserved. 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
30. © Hitachi, Ltd. 2022. All rights reserved. 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/