eBPFによるE2E監視の取り組み #CNDT2023

12.3K Views

December 11, 23

スライド概要

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

eBPFによるE2E監視の取り組み 2023-12-11 CloudNative Days Tokyo 2023 Seiko Solutions Inc. Tomohiro Mano ©2023 Seiko Solutions Inc. All rights reserved.

2.

自己紹介 Tomohiro Mano [email protected]  セイコーソリューションズ株式会社 2020年新卒入社  大学時代の興味 • 物性物理  入社後の興味 • Kubernetes / Go言語 / eBPF ©2023 Seiko Solutions Inc. All rights reserved. 1

3.

背景: 最近気になっていること① レイテンシ・センシティブな分散システム 例えば: IoT 例えば: ロボットOS 出典: https://ccrd.nii.ac.jp/sc21/SINETStream/ その他: 自動運転, 遠隔コラボレーション, etc.. cf. https://spectrum.ieee.org/breaking-the-latency-barrier ©2023 Seiko Solutions Inc. All rights reserved. 2

4.

背景: 最近気になっていること② レイテンシ・センシティブな分散システムの監視 現状の監視の枠組みで十分か? 今すぐ困っていなくても 将来的に困りそうなことはないか? ©2023 Seiko Solutions Inc. All rights reserved. 3

5.

本日の内容 サービス間通信の監視 with 実測で効果検証 ©2023 Seiko Solutions Inc. All rights reserved. 4

6.

本セッションの構成 テーマ 分散システムのEnd to Endでの可観測性向上 第1部 そもそも分散システムをどのように監視すべきか? 何が足りていないか? 第2部 サービス間通信の監視 with eBPF 実運用での事例紹介 第3部 技術的な取り組み紹介 eBPF利用時の注意点 timestamp / kprobe miss-hit (ニッチな) ©2023 Seiko Solutions Inc. All rights reserved. 5

7.

そもそも 第1部 分散システムをどのように監視すべきか? 何が足りていないか? ©2023 Seiko Solutions Inc. All rights reserved.

8.

分散システムがもたらす恩恵の裏側 モノリシック • ステップ実行◎ • パターン化された障害箇所 オートスケール セルフヒーリング etc. 分散システム • 複雑かつ動的な依存関係 • 不安定なネットワーク ©2023 Seiko Solutions Inc. All rights reserved. 7

9.

分散システムの監視 新機能追加(開発フェーズ) or 障害対応(運用フェーズ)に 目的 • 速やかにボトルネックを把握をしたい • システム全体として安定稼働しているか確認したい 『オブザーバビリティ』 道具 CNCF whitepaper: https://github.com/cncf/tag-observability/blob/main/whitepaper.md システムの内部状態をいかに正しく説明できるか? ©2023 Seiko Solutions Inc. All rights reserved. Primary Signals • Metrics • Log • Trace 8

10.

Trace使ってます…? 個人談: 社内開発環境( !=分散システム) Metrics : 死活監視・Kube-prometheus Master Node Log : 詳細な状況把握・トラシュー Trace k8sクラスタに属さない 開発サーバ群 なし ©2023 Seiko Solutions Inc. All rights reserved. (でも、本日のフォーカス) 9 9

11.

Traceのよくある説明 Trace IDを付与 HTTP リクエストX HTTPリクエストXに対するTrace Time A 処理A B 処理B 処理C C 処理D E D 処理E SPANは各サービスの処理時間 ©2023 Seiko Solutions Inc. All rights reserved. 10

12.

Traceによる分散システムのE2E監視 分散システム(HTTP以外でも) End End Trace ID伝搬のための計装 (バックエンド例) E2Eで実際の 通信状況を監視 (出典) https://istio.io/latest/docs/tasks/observability/distributed-tracing/jaeger/ ©2023 Seiko Solutions Inc. All rights reserved. 11

13.

理想のE2E監視を考える TraceとSpanは分散システムをE2E監視するための武器 https://opentelemetry.io/docs/concepts/signals/traces/ Traceはリクエストに何が起きたのか全体像を与えるもの SpanはTraceのビルディングブロックで作業単位 捉え直すと・・・ Traceからたどり着ける論理的な最小要素がSpan 実体は(名前 / 開始と終了のTimestamp / 任意のKey:Value) 必要十分な情報を含む設計が必要 どんな情報を含むべきか? ©2023 Seiko Solutions Inc. All rights reserved. 特にレイテンシを 気にするシステム 12

14.

最終的にTraceで辿り着きたい情報を考えるため・・・ ここからは2サービス間通信に着目 ©2023 Seiko Solutions Inc. All rights reserved. 13

15.

Trace再考: サービス間通信に着目 モノリシック Service B Service A 理想は一撃で状況把握 分散システムの一部(サービス間通信) Service A Network ©2023 Seiko Solutions Inc. All rights reserved. Service B 14

16.

Trace再考: サービス間通信の内部状態 Network Service A 内部状態 変化 • • • Service B リクエストIDによって異なるパス通過 タイミング依存なサービス間通信レイテンシ コンテナのノード移動による実行環境変化 (理想的には) 性能劣化ポイントにより対応が異なるのでTraceから辿りたい ©2023 Seiko Solutions Inc. All rights reserved. 15

17.

現状のTraceで説明できないこと Appで打刻したタイムスタンプベースのSPAN Service A Service B 計装 計装 送信処理SPANの 開始タイムスタンプ 受信処理SPANの 開始タイムスタンプ 𝑻𝑨 𝑻𝑩 ©2023 Seiko Solutions Inc. All rights reserved. 16

18.

現状のTraceで説明できないこと Appで打刻したタイムスタンプベースのSPAN Service A Service B 計装 計装 送信処理SPANの 開始タイムスタンプ あるリクエストで レイテンシ悪化 受信処理SPANの 開始タイムスタンプ 𝑻𝑩 𝑻𝑨 (𝑻𝑩 −𝑻𝑨 ) の増加は確認できる なぜ? 誰(どこ)に責任があるか? ©2023 Seiko Solutions Inc. All rights reserved. 17

19.

何が足りていないか? Traceを辿っても客観的に明確な責任分界点が見えてこない 例えば以下の切り分けをしたい (Traceから辿りたい) TXホスト Service A ホスト内遅延 中継装置 ネットワーク機器 TURNサーバ メッセージブローカ etc. ネットワーク遅延 (App or Kernel) RXホスト Service B ホスト内遅延 (App or Kernel) 装置内の滞留時間 ©2023 Seiko Solutions Inc. All rights reserved. 18

20.

既存の仕組みで解決できる? ① 計装を頑張る TXホスト RXホスト 中継装置 Service B Service A 計装 計装 ? ? ? どれだけAppに計装をしても、インフラはAPIで抽象化 可観測性は向上しない (良い点) インフラの複雑性を隠蔽 ⇒ 可搬性 ©2023 Seiko Solutions Inc. All rights reserved. 19

21.

既存の仕組みで解決できる? ② ping TXホスト 中継装置 RXホスト Service B Service A PING ? テストパケットのラウンドトリップ時間 実サービス通信についてほぼ何も分からない (メトリクスとして全体傾向は掴める) ©2023 Seiko Solutions Inc. All rights reserved. 20

22.

既存の仕組みで解決できる? ③ INT In-band Network Telemetry 専用HW TXホスト INT対応スイッチ RXホスト Service B Service A ? ? INTコレクタ 実サービスパケットの片方向遅延が計測可能 ホスト内部は見えない (INT対応スイッチのキュー / ドロップ状況が分かる) ©2023 Seiko Solutions Inc. All rights reserved. 21

23.

新たな登場人物 カーネルの仕組み 実サービスパケットに計装なしで タイムスタンプ打刻が可能に (実際はもっと色々できる) ©2023 Seiko Solutions Inc. All rights reserved. 22

24.

どうすれば解決できる? 実サービスパケットに eBPFにより、責任分界点でタイムスタンプを押す そして、そのタイムスタンプをTraceに組み込む (本発表の対象外) TXホスト 中継装置 RXホスト Service B Service A 最終的にEnd to Endでの可観測性向上に繋がるはず!! ©2023 Seiko Solutions Inc. All rights reserved. 23

25.

第2部 サービス間通信の監視 with eBPF とはいえ、pingで十分では? 推測するな、計測せよ ©2023 Seiko Solutions Inc. All rights reserved.

26.

実際にやったこと(詳細は後述) 計装なしで実サービスパケットにタイムスタンプを押し集約 TXホスト 中継装置 RXホスト Service B Service A コンテナ デプロイ … ストリーミング処理 ダッシュボード表示 (将来はTrace, Spanの枠組みに統合したい) ©2023 Seiko Solutions Inc. All rights reserved. 25

27.

実測結果① (webRTC, AWS間)  App to Appの遅延 ©2023 Seiko Solutions Inc. All rights reserved. 26

28.

実測結果① (webRTC, AWS間)  App to Appの遅延  ネットワーク遅延  ホスト内遅延 ©2023 Seiko Solutions Inc. All rights reserved. 27

29.

ちなみに: AWS間の片方向遅延の評価  App to Appの遅延 (東京⇒北米) 数分ごとに2ms程度ステップ TXとRXを逆転 逆方向のレイテンシ (北米⇒東京) (表面の微細な振動の差はApp実装の違い) ステップのタイミングが変化 RTT / 2では精度良く評価できない ©2023 Seiko Solutions Inc. All rights reserved. 28

30.

実測結果②: App視点のレイテンシ(webRTC+TURN) TX App TURN RX App App視点のレイテンシ ©2023 Seiko Solutions Inc. All rights reserved. 29

31.

実測結果②: レイテンシの細分化 (webRTC+TURN) TX App RX App TURN ネットワーク遅延 滞留時間 ネットワーク遅延 ©2023 Seiko Solutions Inc. All rights reserved. 30

32.

実測結果より: eBPFが可能にすること Appベースの計装では性能劣化ポイントが不明 Peer Peer 計装 計装 Appから見えないインフラの 複雑性に向き合う + eBPFタイムスタンプにより責任分界点を明確化 Peer ホスト内遅延 TURN ネットワーク遅延 Peer ホスト内遅延 装置内の滞留時間 ©2023 Seiko Solutions Inc. All rights reserved. 31

33.

初見の方向け: こういうことができるeBPFとは? eBPF (extended Berkeley Packet Filter) • カーネルの仕組み • カーネル内でイベントドリブンにユーザ定義のバイトコードを実行 拡張(2013~) カーネル空間でのパケットフィルタによ るパフォーマンス向上について(1992) https://www.tcpdump.org/papers/bpf-usenix93.pdf カーネルの仕組みなので Appに計装不要 Appからは通常追えない Appが叩いたAPIのその先まで追える技術 ©2023 Seiko Solutions Inc. All rights reserved. 32

34.

eBPFの位置づけ: 第3のカーネル拡張手段 ① カーネル本体に組み込む • • 変更必要性をメンテナに訴える 数年後、世界中で利用可能に ② カーネルモジュール • • プラグインとしてカーネル拡張 カーネル側の変更やバグでクラッシュの危険 ③ eBPF • カーネル内のフックポイントに動的検証されるバイトコードをアタッチ ポータブルで安全なカーネル拡張 Networking / Security / Observability ©2023 Seiko Solutions Inc. All rights reserved. 33

35.

eBPFの仕組み - “This allows user-defined instrumentation on a live kernel image that can never crash, hang or interefere with kernel negatively.” 引用:lkml post(2015) https://lkml.org/lkml/2015/4/14/232 制限付きの C言語で作成 フックポイントで コード実行 動的検証 多様な フックポイント 出典: https://ebpf.io/what-is-ebpf/ ©2023 Seiko Solutions Inc. All rights reserved. Syscall Kernel Func. NIC(XDP) etc. 34

36.

(余談) eBPFの個人的な面白ポイント: Verifier • 無限ループの禁止、範囲外アクセスの禁止、命令数・スタックサイズ制限、etc • Verifierは進化を続けているので、まずは通過するか試してみるべし by kernel doc https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html#q-what-are-the-verifier-limits  verifierに弾かれる例 char array[4] = xxx u32 i = yyy (外部から取得した数値代入) return array[i]; // INVALID 「i &= 0x3」などが必要  verifierの言い分 array[i] -> iはu32 -> array[2^32 – 1] // OUT-OF-BOUND (怒るばかりではなく、実は最適化処理もしてくれている…) 出典: https://ebpf.io/what-is-ebpf/ ©2023 Seiko Solutions Inc. All rights reserved. 35

37.

オブザーバビリティ with eBPFの例 bpftrace / BCC その他の例: cf. https://ebpf.io/ github上に便利ツール多数 https://github.com/iovisor/bpftrace https://github.com/iovisor/bcc (出典) Brendan Greggさんblog https://www.brendangregg.com/blog/2019 -07-15/bpf-performance-tools-book.html 例) tcpconnlat (bcc) ©2023 Seiko Solutions Inc. All rights reserved. 36

38.

改めて: 構築したシステム 計装なしで実サービスパケットにタイムスタンプを押し集約 TXホスト 中継装置 RXホスト Service B Service A INT対応スイッチ … ストリーミング処理 ダッシュボード表示 (将来はTrace, Spanの枠組みに統合したい) ©2023 Seiko Solutions Inc. All rights reserved. コンテナ デプロイ 37

39.

タイムスタンプ打刻位置 MP EP(TX) App Socket MP ① EP(RX) ④ 計測対象 の通信 L4 L3 TXホスト内遅延 ①~② ネットワーク遅延 ②~③ RXホスト内遅延 ③~④ L3 ③ ② ③ • • • Socket L4 L3 ② App TURNサーバ INT対応スイッチ 専用プローブ 装置内滞留時間 ③~② or 通過時刻 ③ ©2023 Seiko Solutions Inc. All rights reserved. L3 ③ ① send_tcp/udp() ② tc-bpf ③ XDP ④ recv_tcp/udp() 38

40.

eBPFの恩恵: 細分化計測によるボトルネック把握  App to Appの遅延  ネットワーク遅延 (クラウド環境, 非力なマシン、実装がイマイチな場合等に変動しがち)  ホスト内遅延 ©2023 Seiko Solutions Inc. All rights reserved. 39

41.

その他の恩恵: 計装を取り巻く悩みの解決 よく知らないアプリケーションに 計装なんかできない 計装のせいで新たな障害箇所が 生まれていないか・・・? 監視対象のバージョンアップや 監視項目を追加したい。 既存計装に手を入れる・・・? ©2023 Seiko Solutions Inc. All rights reserved. 40

42.

その他の恩恵: 計装を取り巻く悩みの解決 よく知らないアプリケーションに 計装なんかできない Appに計装しない 計装のせいで新たな障害箇所が 監視するレイヤーと 監視されるレイヤーを分離 ⇒ 個別メンテ 生まれていないか・・・? 監視対象のバージョンアップや 監視項目を追加したい。 既存計装に手を入れる・・・? ©2023 Seiko Solutions Inc. All rights reserved. メンテコスト 低下 41

43.

(補足①) 計装しない? サイドカーは?? “How eBPF will solve Service Mesh – Goodbye Sidecars” – cilium https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh/ vs “eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay” – solo.io https://www.solo.io/blog/ebpf-for-service-mesh/ (出典) https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh/ 今回はより低レイテンシに App処理の中身まで (Traceで)追いたい (出典) https://www.solo.io/blog/istio-ambient-mesh-evolution-service-mesh/ ©2023 Seiko Solutions Inc. All rights reserved. 42

44.

(補足②) Trace IDの自動伝搬 ここまで2サービス間通信に注目 Traceに組み込むにはE2Eで TraceIDの伝搬が必要 + Trace IDの自動伝搬で 計装漏れによる Trace破壊を防止 ©2023 Seiko Solutions Inc. All rights reserved. 43

45.

ネットワーク 監視で 第3部 eBPF利用時の注意点 ①timestamp / ②kprobe miss-hit ©2023 Seiko Solutions Inc. All rights reserved. (ニッチな)

46.

その①(1/5): eBPFでタイムスタンプ打刻 Kernel5系 TXホスト RXホスト 中継装置 Service B Service A ※ 各ホストの時刻同期は前提 通常の場合: clock_gettime()システムコール カーネルのクロック情報を取得するために設計 eBPFの場合: bpf_ktime_get_ns()ヘルパー関数 パフォーマンス計測を想定して設計 ©2023 Seiko Solutions Inc. All rights reserved. 45

47.

その①(2/5): カーネルのクロック Wall Clock vs Monotonic Clock Wall Clock (Realtime Clock) • dateコマンドで取得できるUTC時系 • UNIXエポック(起点)からの経過時間を保持 • ユーザ空間から調整可能 Monotonic Clock • システムブート時から単調増加するローカル時系 • ユーザ空間から調整不可 • パフォーマンス計測に適している ©2023 Seiko Solutions Inc. All rights reserved. 46

48.

その①(3/5): 問題点  clock_gettime(clockid_t clk_id, struct timespec *tp)の場合 Wall Clock CLOCK_REALTIME CLOCK_MONOTONIC CLOCK_MONOTONIC_RAW CLOCK_BOOTTIME etc. (man参照) Monotonic Clock (参考) GoのTimeパッケージは、内部でこれらを使い分けている 2か所の時刻の比較(差分)は勝手にMonotonic Clockを利用等  bpf_ktime_get_ns()の場合 Monotonic Clockのみ (パフォーマンス計測用のため) 他ホスト上の値と比較するには Wall Clockへの変換が必要 ©2023 Seiko Solutions Inc. All rights reserved. 47

49.

その①(4/5): eBPFによる解決  変換方法 Monotonic Clock /include/linux/timekeeper_internal.h + offs_real timekeeper構造体のoffs_real Wall Clock  どうやって正確なオフセットを知る? eBPFでoffs_realをメンテする関数(tk_set_wall_to_mono)を監視 更新時にだけ処理が走るミニマムな実装に! ネットワーク計測に必要なホスト間タイムスタンプ比較が可能に!! ©2023 Seiko Solutions Inc. All rights reserved. 48

50.

その①(5/5):新しいカーネルの場合 Kernel 6.2 ~ 新しいヘルパー関数 bpf_ktime_get_tai_ns() Wall clockを取得可能 https://elixir.bootlin.com/linux/v6.2/source/kernel/bpf/helpers.c#L204 eBPFの進化は早い + 5系を使っている方は注意! ©2023 Seiko Solutions Inc. All rights reserved. 49

51.

その②(1/4): ネットワーク周りで遭遇したトラブル 受信パケットの通過数をkprobeでカウント時、謎のロスト App udp_recvmsg() 60418 pkts netif_receive_skb() 60358 pkts Socket L4 L3 パケット受信 iperf3でUDPパケットを生成 残りの60 pktsは どこへ・・・? 60418 pkts ©2023 Seiko Solutions Inc. All rights reserved. 50

52.

その②(2/4): 先に結論 同タイミングでnetif_receive_skb()のkprobe miss-hitが増加 パケット数の矛盾はなくなった App udp_recvmsg() 60418 pkts netif_receive_skb() 60358 pkts Socket L4 L3 kprobe miss-hit パケット受信 60 pkts 60418 pkts 60418 pkts ©2023 Seiko Solutions Inc. All rights reserved. 51

53.

その②(3/4): 調べたこと  とりあえずkprobeのDocを読む https://www.kernel.org/doc/Documentation/ trace/kprobetrace.txt kprobeにはmiss-hitなるものがあるらしい  netif_receive_skb()に手動でkprobeをアタッチ 発火回数 miss-hit数 ©2023 Seiko Solutions Inc. All rights reserved. iperf3でテストパケット 生成・受信 52

54.

その②(4/4): 分かったこと  miss-hitをカウントしているコードを追跡 ここでmiss-hitを カウント https://github.com/torvalds/linux/blob/v5.1 7/arch/x86/kernel/kprobes/core.c#L907 割り込みコンテキストで kprobeを仕掛けると kprobe自体発火しない ことがある  ネットワーク系の関数は割り込みコンテキストを持つ場合がある  kprobeを使う場合は注意(ftraceでは発生未確認) ©2023 Seiko Solutions Inc. All rights reserved. 53

55.

まとめ  分散システムの構成要素である2サービス間通信に着目 従来のAppベースの測定では性能劣化ポイント不明  アプローチ: eBPFにより責任分界点でタイムスタンプを押す TXホスト 中継装置 RXホスト Service B Service A  実測により、タイムスタンプによる細分化が性能劣化ポイントの 特定に役立つことを確認 ©2023 Seiko Solutions Inc. All rights reserved. 54

56.

©2023 Seiko Solutions Inc. All rights reserved.