Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Service Mesh in 2022

id
September 07, 2022

Service Mesh in 2022

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

id

September 07, 2022
Tweet

More Decks by id

Other Decks in Technology

Transcript

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

    View full-size slide

  2. © Hitachi, Ltd. 2022. All rights reserved.
    内容
    1. Service Meshの背景
    2. Service Meshのトレンド
    3. Service Meshの今後
    1

    View full-size slide

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

    View full-size slide

  4. © Hitachi, Ltd. 2022. All rights reserved.
    1. Service Meshの背景
    3

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  7. © Hitachi, Ltd. 2022. All rights reserved.
    Microservicesの運用
    Microservicesをどのように運用するか?
    ◇ サービス間のルーティングは?
    ◇ 通信のアクセス制御は?
    ◇ システム全体の可視化は?
    6

    View full-size slide

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

    View full-size slide

  9. © Hitachi, Ltd. 2022. All rights reserved.
    Service Meshのアイデア
    各サービスは通信で連携している


    8
    Svc1 Svc2
    サービス間通信
    運用者

    View full-size slide

  10. © Hitachi, Ltd. 2022. All rights reserved.
    Service Meshのアイデア
    各サービスは通信で連携している
    → サービスの前段に配置したプロキシ(Sidecar Proxy)で、サービス間通信を制御し、運用機能を適用

    9
    Proxy Proxy
    Svc1 Svc2
    サービス間通信
    宛先の変更
    通信暗号化
    アクセス制御
    メトリクス出力
    運用者

    View full-size slide

  11. © Hitachi, Ltd. 2022. All rights reserved.
    Service Meshのアイデア
    各サービスは通信で連携している
    → サービスの前段に配置したプロキシ(Sidecar Proxy)で、サービス間通信を制御し、運用機能を適用
    → 多量に出てくるプロキシはコントロールプレーンで一元的に管理
    10
    Proxy Proxy
    Svc1 Svc2
    サービス間通信
    宛先の変更
    通信暗号化
    アクセス制御
    メトリクス出力
    運用者
    Control
    Plane
    制御
    操作

    View full-size slide

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

    View full-size slide

  13. © Hitachi, Ltd. 2022. All rights reserved.
    2. Service Meshのトレンド
    12

    View full-size slide

  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配下の団体

    View full-size slide

  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の利用率
    本番利用中 評価中 不使用

    View full-size slide

  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年 ツール別利用率(含 計画中)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  19. © Hitachi, Ltd. 2022. All rights reserved.
    3. Service Meshの今後
    18

    View full-size slide

  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活用イメージ

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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/

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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/

    View full-size slide