eBPFによるE2E監視の取り組み #CNDT2023
16.1K Views
December 11, 23
スライド概要
関連スライド
各ページのテキスト
eBPFによるE2E監視の取り組み 2023-12-11 CloudNative Days Tokyo 2023 Seiko Solutions Inc. Tomohiro Mano ©2023 Seiko Solutions Inc. All rights reserved.
自己紹介 Tomohiro Mano [email protected] セイコーソリューションズ株式会社 2020年新卒入社 大学時代の興味 • 物性物理 入社後の興味 • Kubernetes / Go言語 / eBPF ©2023 Seiko Solutions Inc. All rights reserved. 1
背景： 最近気になっていること① レイテンシ・センシティブな分散システム 例えば： 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
背景： 最近気になっていること② レイテンシ・センシティブな分散システムの監視 現状の監視の枠組みで十分か？ 今すぐ困っていなくても 将来的に困りそうなことはないか？ ©2023 Seiko Solutions Inc. All rights reserved. 3
本日の内容 サービス間通信の監視 with 実測で効果検証 ©2023 Seiko Solutions Inc. All rights reserved. 4
本セッションの構成 テーマ 分散システムのEnd to Endでの可観測性向上 第１部 そもそも分散システムをどのように監視すべきか？ 何が足りていないか？ 第２部 サービス間通信の監視 with eBPF 実運用での事例紹介 第３部 技術的な取り組み紹介 eBPF利用時の注意点 timestamp / kprobe miss-hit （ニッチな） ©2023 Seiko Solutions Inc. All rights reserved. 5
そもそも 第1部 分散システムをどのように監視すべきか？ 何が足りていないか？ ©2023 Seiko Solutions Inc. All rights reserved.
分散システムがもたらす恩恵の裏側 モノリシック • ステップ実行◎ • パターン化された障害箇所 オートスケール セルフヒーリング etc. 分散システム • 複雑かつ動的な依存関係 • 不安定なネットワーク ©2023 Seiko Solutions Inc. All rights reserved. 7
分散システムの監視 新機能追加（開発フェーズ） 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
Trace使ってます…？ 個人談： 社内開発環境（ !=分散システム） Metrics : 死活監視・Kube-prometheus Master Node Log : 詳細な状況把握・トラシュー Trace k8sクラスタに属さない 開発サーバ群 なし ©2023 Seiko Solutions Inc. All rights reserved. （でも、本日のフォーカス） 9 9
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
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
理想の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
最終的にTraceで辿り着きたい情報を考えるため・・・ ここからは２サービス間通信に着目 ©2023 Seiko Solutions Inc. All rights reserved. 13
Trace再考： サービス間通信に着目 モノリシック Service B Service A 理想は一撃で状況把握 分散システムの一部（サービス間通信） Service A Network ©2023 Seiko Solutions Inc. All rights reserved. Service B 14
Trace再考： サービス間通信の内部状態 Network Service A 内部状態 変化 • • • Service B リクエストIDによって異なるパス通過 タイミング依存なサービス間通信レイテンシ コンテナのノード移動による実行環境変化 （理想的には） 性能劣化ポイントにより対応が異なるのでTraceから辿りたい ©2023 Seiko Solutions Inc. All rights reserved. 15
現状のTraceで説明できないこと Appで打刻したタイムスタンプベースのSPAN Service A Service B 計装 計装 送信処理SPANの 開始タイムスタンプ 受信処理SPANの 開始タイムスタンプ 𝑻𝑨 𝑻𝑩 ©2023 Seiko Solutions Inc. All rights reserved. 16
現状のTraceで説明できないこと Appで打刻したタイムスタンプベースのSPAN Service A Service B 計装 計装 送信処理SPANの 開始タイムスタンプ あるリクエストで レイテンシ悪化 受信処理SPANの 開始タイムスタンプ 𝑻𝑩 𝑻𝑨 (𝑻𝑩 −𝑻𝑨 ) の増加は確認できる なぜ？ 誰（どこ）に責任があるか？ ©2023 Seiko Solutions Inc. All rights reserved. 17
何が足りていないか？ Traceを辿っても客観的に明確な責任分界点が見えてこない 例えば以下の切り分けをしたい （Traceから辿りたい） TXホスト Service A ホスト内遅延 中継装置 ネットワーク機器 TURNサーバ メッセージブローカ etc. ネットワーク遅延 (App or Kernel) RXホスト Service B ホスト内遅延 (App or Kernel) 装置内の滞留時間 ©2023 Seiko Solutions Inc. All rights reserved. 18
既存の仕組みで解決できる？ ① 計装を頑張る TXホスト RXホスト 中継装置 Service B Service A 計装 計装 ？ ？ ？ どれだけAppに計装をしても、インフラはAPIで抽象化 可観測性は向上しない （良い点） インフラの複雑性を隠蔽 ⇒ 可搬性 ©2023 Seiko Solutions Inc. All rights reserved. 19
既存の仕組みで解決できる？ ② ping TXホスト 中継装置 RXホスト Service B Service A PING ？ テストパケットのラウンドトリップ時間 実サービス通信についてほぼ何も分からない （メトリクスとして全体傾向は掴める） ©2023 Seiko Solutions Inc. All rights reserved. 20
既存の仕組みで解決できる？ ③ INT In-band Network Telemetry 専用HW TXホスト INT対応スイッチ RXホスト Service B Service A ？ ？ INTコレクタ 実サービスパケットの片方向遅延が計測可能 ホスト内部は見えない （INT対応スイッチのキュー / ドロップ状況が分かる） ©2023 Seiko Solutions Inc. All rights reserved. 21
新たな登場人物 カーネルの仕組み 実サービスパケットに計装なしで タイムスタンプ打刻が可能に （実際はもっと色々できる） ©2023 Seiko Solutions Inc. All rights reserved. 22
どうすれば解決できる？ 実サービスパケットに eBPFにより、責任分界点でタイムスタンプを押す そして、そのタイムスタンプをTraceに組み込む （本発表の対象外） TXホスト 中継装置 RXホスト Service B Service A 最終的にEnd to Endでの可観測性向上に繋がるはず！！ ©2023 Seiko Solutions Inc. All rights reserved. 23
第２部 サービス間通信の監視 with eBPF とはいえ、pingで十分では？ 推測するな、計測せよ ©2023 Seiko Solutions Inc. All rights reserved.
実際にやったこと（詳細は後述） 計装なしで実サービスパケットにタイムスタンプを押し集約 TXホスト 中継装置 RXホスト Service B Service A コンテナ デプロイ … ストリーミング処理 ダッシュボード表示 （将来はTrace, Spanの枠組みに統合したい） ©2023 Seiko Solutions Inc. All rights reserved. 25
実測結果① (webRTC, AWS間) App to Appの遅延 ©2023 Seiko Solutions Inc. All rights reserved. 26
実測結果① (webRTC, AWS間) App to Appの遅延 ネットワーク遅延 ホスト内遅延 ©2023 Seiko Solutions Inc. All rights reserved. 27
ちなみに： AWS間の片方向遅延の評価 App to Appの遅延 （東京⇒北米） 数分ごとに2ms程度ステップ TXとRXを逆転 逆方向のレイテンシ （北米⇒東京） （表面の微細な振動の差はApp実装の違い） ステップのタイミングが変化 RTT / 2では精度良く評価できない ©2023 Seiko Solutions Inc. All rights reserved. 28
実測結果②： App視点のレイテンシ(webRTC+TURN) TX App TURN RX App App視点のレイテンシ ©2023 Seiko Solutions Inc. All rights reserved. 29
実測結果②： レイテンシの細分化 (webRTC+TURN) TX App RX App TURN ネットワーク遅延 滞留時間 ネットワーク遅延 ©2023 Seiko Solutions Inc. All rights reserved. 30
実測結果より： eBPFが可能にすること Appベースの計装では性能劣化ポイントが不明 Peer Peer 計装 計装 Appから見えないインフラの 複雑性に向き合う + eBPFタイムスタンプにより責任分界点を明確化 Peer ホスト内遅延 TURN ネットワーク遅延 Peer ホスト内遅延 装置内の滞留時間 ©2023 Seiko Solutions Inc. All rights reserved. 31
初見の方向け： こういうことができる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
eBPFの位置づけ: 第3のカーネル拡張手段 ① カーネル本体に組み込む • • 変更必要性をメンテナに訴える 数年後、世界中で利用可能に ② カーネルモジュール • • プラグインとしてカーネル拡張 カーネル側の変更やバグでクラッシュの危険 ③ eBPF • カーネル内のフックポイントに動的検証されるバイトコードをアタッチ ポータブルで安全なカーネル拡張 Networking / Security / Observability ©2023 Seiko Solutions Inc. All rights reserved. 33
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
（余談） 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
オブザーバビリティ 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
改めて： 構築したシステム 計装なしで実サービスパケットにタイムスタンプを押し集約 TXホスト 中継装置 RXホスト Service B Service A INT対応スイッチ … ストリーミング処理 ダッシュボード表示 （将来はTrace, Spanの枠組みに統合したい） ©2023 Seiko Solutions Inc. All rights reserved. コンテナ デプロイ 37
タイムスタンプ打刻位置 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
eBPFの恩恵： 細分化計測によるボトルネック把握 App to Appの遅延 ネットワーク遅延 （クラウド環境, 非力なマシン、実装がイマイチな場合等に変動しがち） ホスト内遅延 ©2023 Seiko Solutions Inc. All rights reserved. 39
その他の恩恵： 計装を取り巻く悩みの解決 よく知らないアプリケーションに 計装なんかできない 計装のせいで新たな障害箇所が 生まれていないか・・・？ 監視対象のバージョンアップや 監視項目を追加したい。 既存計装に手を入れる・・・？ ©2023 Seiko Solutions Inc. All rights reserved. 40
その他の恩恵： 計装を取り巻く悩みの解決 よく知らないアプリケーションに 計装なんかできない Appに計装しない 計装のせいで新たな障害箇所が 監視するレイヤーと 監視されるレイヤーを分離 ⇒ 個別メンテ 生まれていないか・・・？ 監視対象のバージョンアップや 監視項目を追加したい。 既存計装に手を入れる・・・？ ©2023 Seiko Solutions Inc. All rights reserved. メンテコスト 低下 41
（補足①） 計装しない？ サイドカーは？？ “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
（補足②） Trace IDの自動伝搬 ここまで2サービス間通信に注目 Traceに組み込むにはE2Eで TraceIDの伝搬が必要 + Trace IDの自動伝搬で 計装漏れによる Trace破壊を防止 ©2023 Seiko Solutions Inc. All rights reserved. 43
ネットワーク 監視で 第3部 eBPF利用時の注意点 ①timestamp / ②kprobe miss-hit ©2023 Seiko Solutions Inc. All rights reserved. （ニッチな）
その①（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
その①（2/5）： カーネルのクロック Wall Clock vs Monotonic Clock Wall Clock (Realtime Clock) • dateコマンドで取得できるUTC時系 • UNIXエポック（起点）からの経過時間を保持 • ユーザ空間から調整可能 Monotonic Clock • システムブート時から単調増加するローカル時系 • ユーザ空間から調整不可 • パフォーマンス計測に適している ©2023 Seiko Solutions Inc. All rights reserved. 46
その①（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
その①（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
その①（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
その②（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
その②（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
その②（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
その②（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
まとめ 分散システムの構成要素である2サービス間通信に着目 従来のAppベースの測定では性能劣化ポイント不明 アプローチ： eBPFにより責任分界点でタイムスタンプを押す TXホスト 中継装置 RXホスト Service B Service A 実測により、タイムスタンプによる細分化が性能劣化ポイントの 特定に役立つことを確認 ©2023 Seiko Solutions Inc. All rights reserved. 54
©2023 Seiko Solutions Inc. All rights reserved.