PostgreSQLにおける 分散トレーシングの現在 PostgreSQLアンカンファレンス 2024/12/20 NTT OSSセンタ 清野 裕貴

1 © NTT CORPORATION 2024 本講演の要旨 本日、話すこと #DBA目線でお話しします • 分散トレーシングの簡易的な前提知識 # 時間の都合上少しだけ。何となくだけでも知っておいてほしい知識。 • PostgreSQLにおける分散トレーシングの手法 本日、話さないこと • 分散システムやマイクロサービス、オブザーバビリティ、分散トレーシングの 一般的な話 • 関連技術(OpenTelemetry、eBPF等)の詳細仕様 講演資料は https://speakerdeck.com/seinoyu にて公開。

2 © NTT CORPORATION 2024 Question ある分散システムに組み込むデータベースのDBAを任されました ・アプリケーション開発者 からの質問 「トレースIDをデータベース側に送りたいのですが、どの形式で 送ればいいですか？」 ・基盤リーダー からの指示 「この規格に沿ってデータベースのトレースをコレクターに送っ てください。」 どのように答えますか？ 本日は、このQに対して、 少しだけ理解・会話ができ るようになることが目標！

3 © NTT CORPORATION 2024 アジェンダ • イントロダクション（分散トレーシング） • PostgreSQLにおける分散トレーシングの意義 • PostgreSQLにおける分散トレーシングの手法 • まとめ

4 © NTT CORPORATION 2024 アジェンダ • イントロダクション（分散トレーシング） • PostgreSQLにおける分散トレーシングの意義 • PostgreSQLにおける分散トレーシングの手法 • まとめ

5 © NTT CORPORATION 2024 分散システムやマイクロサービスにおいて、オブザーバビリティ:可観測性の担保 が必須。ベンダニュートラルとして普及したOpenTelemetry(以後、Otel)が下記 の4要素をサポート。 • オブザーバビリティの要素(テレメトリ) 1. メトリクス › リソース情報(CPU, Mem,…) › PostgreSQLの稼働統計情報 2. ログ › システムログ(/var/log/message) › PostgreSQLサーバログ 3. 分散トレーシング 4. 継続的プロファイリング#2024.4 Otelサポート開始 オブザーバビリティとテレメトリ DB AP AP AP1 Otel Collector Otel DB1 AP2 AP3 DB2 Otel Otel Otel Otel Monitoring Tool テレメトリ マイクロサービスのイメージ

6 © NTT CORPORATION 2024 分散トレーシング 分散トレーシングの目的 • パフォーマンスの可視化 • 各サービスやコンポーネントがリクエスト処理にど の程度時間を費やしているかを追跡 • e.g. それぞれのタスクの処理時間 を明らかに する • 問題の特定 • ボトルネックや障害が発生している箇所を特定 DB AP AP AP1 Otel Collector Otel DB1 AP2 AP3 DB2 Otel Otel Otel Otel Monitoring Tool ターンアラウンドタイム AP1の処理時間 AP2の処理時間 DB1… DB2… End Start AP1 AP2 マイクロサービスのイメージ トレースを可視化した際のUIイメージ DB1 A C D E F

7 © NTT CORPORATION 2024 分散トレーシング 普及の背景 • 分散システムやマイクロサービスの普及 • コンポーネント間の追跡がより重要に • OtelによるAP毎のトレーシング開発コストの 低減 • eBPFによるトレーシングのための性能オーバ ヘッド低減 • eBPF : カーネルの機能をフックして、動的拡張が 可能。 DB AP AP AP1 Otel Collector Otel DB1 AP2 AP3 DB2 Otel Otel Otel Otel Monitoring Tool ターンアラウンドタイム AP1の処理時間 AP2の処理時間 DB1… DB2… Start マイクロサービスのイメージ トレースを可視化した際のUIイメージ End

8 © NTT CORPORATION 2024 分散トレーシングの用語 • traceId • トレースを一意に識別するID traceId 分散トレーシングのUI

9 © NTT CORPORATION 2024 分散トレーシングの用語 • traceId • トレースを一意に識別するID • span • トレース情報の最小単位 span traceId 分散トレーシングのUI

10 © NTT CORPORATION 2024 分散トレーシングの用語 • traceId • トレースを一意に識別するID • span • トレース情報の最小単位 • spanId(parentId) • スパンを一意に識別するID(親子関係にも使用) • attribute • スパンは様々な属性を持つことができる › e.g. IPアドレス、ホスト名、クエリテキスト、 テーブル名、サービス名 span spanId attribute traceId 分散トレーシングのUI

11 © NTT CORPORATION 2024 PostgreSQL 従来のPostgreSQLの分散トレーシング • クエリトレーシング • ログ(log_min_duration_statement, auto_explain) • EXPLAIN ANALYZE • pg_stat_statements • 動的追跡(DTrace:SystemTap) • トレーシングやプロファイリングを実現 • プローブ組み込みによるオーバヘッドが大きい • クエリ関連や内部処理に関する50以上のプローブを提供 › E.g. transaction-start : トランザクションの開始を捕捉 › transaction-commit : トランザクションの正常終了を捕捉 › checkpoint-start : チェックポイントの開始を捕捉 # 従来のトレーシング手順の一例 (DBボトルネックを前提とする) ① リクエスト中のボトルネック箇所の特定 - APサーバ(APログ、アクセスログ)の解析 ② DBサーバのボトルネックの特定 - ログや稼働統計情報の解析 - リソース利用状況の解析(sar, ps, …) ③ リソース占有処理の特定 - プロファイリングによる解析 AP DB CL 遅延検出 ① ② ③

12 © NTT CORPORATION 2024 アジェンダ • イントロダクション（分散トレーシング） • PostgreSQLにおける分散トレーシングの意義 • PostgreSQLにおける分散トレーシングの手法 • まとめ

13 © NTT CORPORATION 2024 データベースにおけるユースケースの移り変わり • 分散システム、マイクロサービスへのDB組み込みが普及 • コンテナ環境での利用も一般的に（スケールの機会も増加し、デプロイ処理も 活発に） • 膨大なコンポーネントが存在する中で、従来の方法で個別手動で解析(トレー シング)していくことは困難 Simple Architecture Distributed Architecture

14 © NTT CORPORATION 2024 アジェンダ • イントロダクション（分散トレーシング） • PostgreSQLにおける分散トレーシングの意義 • PostgreSQLにおける分散トレーシングの手法 • まとめ

15 © NTT CORPORATION 2024 PostgreSQLにおける分散トレーシングの手法 クライアントとサーバで手法が異なる。本日は(★)を紹介。 • クライアントサイド(アプリケーションサイド) • OpenTelemetry(SDK)によるインストルメント(手動計装、自動計装) • eBPFベース › 製品例 : NewRelic/Pixie、Coroot • サーバサイド(PostgreSQLサーバ) › OpenTelemetry(SDK)がC言語に対応していないため、PostgreSQLに対して、トレース手 法として一般的なインストルメント(手動計装、自動計装)が利用できない › PostgreSQLの拡張機能としてトレース機構を独自実装 » 製品例：pg_tracing (★)

16 © NTT CORPORATION 2024 • 2023年7月からpgsql-hackers で議論開始 • POC: Extension for adding distributed tracing - pg_tracing • CommitFest：pg_tracing • 将来的には contrib を目標としており、安定するまでGitHubに て開発を進める方針 • DataDog/pg_tracing • 現在はPG15, 16をサポート • masterブランチを見るとPG17,18の対応も進められている pg_tracing について

17 © NTT CORPORATION 2024 特徴 • 拡張機能として実装 • C言語用の OpenTelemetry SDK が存在しないため、独自実装 主な機能 • サンプリング、トレースコンテキストの伝搬 • 2種類の伝搬方法を提供 › SQLCommenter › GUCパラメータ(trace_context) • スパンの保存、ビューの提供 • スパンの送信機能 • OTLP HTTP/JSON プロトコルによる Otel Collector等 への送信 概要 #pg_tracing 分散トレーシングでは通常、HTTPヘッダ(W3C Trace Contextフォー マット)でトレースコンテキスト(TraceID等)を持ちまわることが一般的

18 © NTT CORPORATION 2024 クエリ処理中の内部処理をトレース トレース内容 詳細 PostgreSQL 内部関数 Planner、ProcessUtility、ExecutorRun、ExecutorFinish ステートメント SELECT、INSERT、DELETE... ユーティリティ ALTER、SHOW、TRUNCATE、CALL... 実行プラン 実行プランの各ノード (SeqScan、NestedLoop、HashJoin など) に対してスパンを作成 ネストされたクエリ 別のステートメント内で呼び出されるステートメント (関数など) トリガー BEFOREトリガーとAFTERトリガーを通じて実行されたステートメントをトレース 並列ワーカー 並列SeqScansのような処理するための並列プロセスをトレース トランザクションコミット: WAL の変更にかかった時間 トレース対象 #pg_tracing

19 © NTT CORPORATION 2024 • SQLのコメントにトレースコンテキストを記載して、ト レース情報を伝搬する方法 トレースの伝搬１ SQLCommenter #pg_tracing -- Query with trace context and sampled flag enable /*traceparent='00-00000000000000000000000000000123-0000000000000123-01'*/ SELECT 1; -- Check the generated spans select trace_id, parent_id, span_id, span_start, span_end, span_type, span_operation from pg_tracing_consume_spans order by span_start; trace_id | parent_id | span_id | span_start | span_end | span_type | span_operation ----------------------------------+------------------+------------------+-------------------------------+-------------------------------+--------------+---------------- 00000000000000000000000000000123 | 0000000000000123 | 4268a4281c5316dd | 2024-03-19 13:46:43.97958+00 | 2024-03-19 13:46:43.980121+00 | Select query | SELECT $1; 00000000000000000000000000000123 | 4268a4281c5316dd | 87cb96b6459880a0 | 2024-03-19 13:46:43.979642+00 | 2024-03-19 13:46:43.979978+00 | Planner | Planner 00000000000000000000000000000123 | 4268a4281c5316dd | f5994f9159d8e80d | 2024-03-19 13:46:43.980081+00 | 2024-03-19 13:46:43.980111+00 | Executor | ExecutorRun コメントを付与して、SQL実行 （通常はAP側で付与して利用することを想定） トレース情報ビューを確認 AP1 DB1 from google.cloud.sqlcommenter.psycopg2.extension import CommenterCursorFactory ~ ~ cursor.execute(“SELECT 1”) ~ ~ SQL Commenter /*traceparent='00- 00000000000000000000000 000000123- 0000000000000123-01'*/ SELECT 1;

20 © NTT CORPORATION 2024 • GUCパラメータ(trace_context)にトレースコンテキストを設定することによ りトレース情報を伝搬 トレースの伝搬2 GUCパラメータ #pg_tracing BEGIN; SET LOCAL pg_tracing.trace_context='traceparent=''00-00000000000000000000000000000005-0000000000000005-01'''; UPDATE pgbench_accounts SET abalance=1 where aid=1; COMMIT; -- Check generated span select trace_id, span_start, span_end, span_type, span_operation from pg_tracing_consume_spans order by span_start; trace_id | span_start | span_end | span_type | span_operation ----------------------------------+-------------------------------+-------------------------------+-------------------+------------------------------------------------- ---------- 00000000000000000000000000000005 | 2024-07-05 14:24:55.305234+00 | 2024-07-05 14:24:55.305988+00 | Update query | UPDATE pgbench_accounts SET abalance=$1 where aid=$2; 00000000000000000000000000000005 | 2024-07-05 14:24:55.305266+00 | 2024-07-05 14:24:55.30552+00 | Planner | Planner 00000000000000000000000000000005 | 2024-07-05 14:24:55.305586+00 | 2024-07-05 14:24:55.305906+00 | ExecutorRun | ExecutorRun 00000000000000000000000000000005 | 2024-07-05 14:24:55.305591+00 | 2024-07-05 14:24:55.305903+00 | Update | Update on pgbench_accounts 00000000000000000000000000000005 | 2024-07-05 14:24:55.305593+00 | 2024-07-05 14:24:55.305806+00 | IndexScan | IndexScan using pgbench_accounts_pkey on pgbench_accounts 00000000000000000000000000000005 | 2024-07-05 14:24:55.649757+00 | 2024-07-05 14:24:55.649792+00 | Utility query | COMMIT; 00000000000000000000000000000005 | 2024-07-05 14:24:55.649787+00 | 2024-07-05 14:24:55.649792+00 | ProcessUtility | ProcessUtility 00000000000000000000000000000005 | 2024-07-05 14:24:55.649816+00 | 2024-07-05 14:24:55.650613+00 | TransactionCommit | TransactionCommit トレース情報ビューを確認 GUCパラメータにトレースコンテキストを設定

21 © NTT CORPORATION 2024 インストール # 拡張機能インストール $ git clone https://github.com/DataDog/pg_tracing.git $ cd pg_tracing && make install $ vi data/postgresql.conf # shared_preload_libraries = ‘pg_tracing’他 (詳細は次頁) $ pg_ctl restart $ psql –c “CREATE EXTENSION pg_tracing” # jeager起動(トレーシングモニタリングツール) $ docker run --rm --name jaeger -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 -p 16686:16686 -p 4317:4317 -p 4318:4318 -p 14250:14250 -p 14268:14268 -p 14269:14269 -p 9411:9411 jaegertracing/all-in-one:1.63.0 # SQL実行 $ psql –c “SELECT 1” http://localhost:16686/ jeagerのダッシュボードから確認 拡張機能をコンパイル GUCパラメータを追加 CREATE EXTENSION SQL実行 Jeager起動

22 © NTT CORPORATION 2024 主なパラメータ #pg_tracing 処理 詳細 検証値 pg_tracing.max_span 保存するスパンの最大値 1つのスパンあたり約370バイトのメモリ消費 100000 pg_tracing.track スパン作成対象のステートメントを制御 ・top : 最上位レベルのステートメント ・all : ネストを含むステートメント ・none : スパンを作成しない all pg_tracing.sample_rate サンプルレート - (次頁参照) pg_tracing.otel_endpoint Otelコレクターのエンドポイント http://127.0.0.1:4318/v1/traces pg_tracing.otel_naptime Otelコレクターへのアップロード間隔(ms) 2000

23 © NTT CORPORATION 2024 ベンチマーク #pg_tracing • バリエーション • パターン 1. pg_tracing.sample_rate = 0 ※取得しない 2. pg_tracing.sample_rate = 0.1 3. pg_tracing.sample_rate = 0.5 4. pg_tracing.sample_rate = 1.0 ※全て取得 5. pg_tracing = off • クライアント数 › 20, 40, 80, 100, 120 • ワークロード › pgbench –i –s 100 › pgbench -c $client –T 90 pgbench PostgreSQL pg_tracing Query 構成 jeager Trace • 目的 • pg_tracing によるオー バヘッドの測定

24 © NTT CORPORATION 2024 • Ubuntu 24.04 LTS on Hyper-V on Windows11 • PostgreSQL 16 STABLE (pgbench, server) • pg_tracing 検証バージョン (43e89ca94e3c94d4b6db3af44a89fcc874251a06) 補足 : ベンチマーク環境

25 © NTT CORPORATION 2024 性能検証の結果（TPS, Latency） #pg_tracing 600 700 800 900 1000 1100 1200 1300 20 40 60 80 100 120 TPS クライアント数 sample_rate=0 sample_rate=0.1 sample_rate=0.5 sample_rate=1.0 pg_tracing=off 0 20 40 60 80 100 120 140 20 40 60 80 100 120 レイテンシ クライアント数 sample_rate=0 sample_rate=0.1 sample_rate=0.5 sample_rate=1.0 pg_tracing=off ※ 試行回数3回の平均 ※ 環境やワークロードにより性能傾向が異なる可能性があるため、あくまで参考値 最大20%程度の性能劣化 (sample_rate=1.0 vs pg_tracing_off) Better Better 最大20%程度の性能劣化 (sample_rate=1.0 vs pg_tracing_off)

26 © NTT CORPORATION 2024 性能検証の結果（CPU） #pg_tracing ※ 試行回数3回の平均 ※ pgbench開始後30秒経過後のメトリクス(30秒間)から算出 ※ 環境やワークロードにより性能傾向が異なる可能性があるため、あくまで参考値 %user : わずかに負荷上昇 0 10 20 30 40 50 60 20 40 60 80 100 120 CPU クライアント数 sample_rate=0(%user) sample_rate=0.1(%user) sample_rate=0.5(%user) sample_rate=1.0(%user) pg_tracing=off(%user) sample_rate=0(%iowait) sample_rate=0.1(%iowait) sample_rate=0.5(%iowait) sample_rate=1.0(%iowait) pg_tracing=off(%iowait) sample_rate=0(%system) sample_rate=0.1(%system) sample_rate=0.5(%system) sample_rate=1.0(%system) pg_tracing=off(%system) %system : わずかに負荷上昇 %iowait : ほぼ変化なし Better

27 © NTT CORPORATION 2024 紹介した分散トレーシング手法のサマリ pg_tracing 目的 • PostgreSQLの内部処理をトレース アーキテクチャ • PostgreSQL本体に対し拡張機能として追加 • OtelSDKが利用できないため、テレメトリ収 集・保存・送信処理は独自実装 ステータス • 開発中 監視するコンポーネント • PostgreSQLの関数(e.g. Excuter, Planner) パフォーマンス • sample_rate 次第で大きなオーバヘッドの可 能性がある

28 © NTT CORPORATION 2024 補足：他のデータベース製品の対応状況 • MySQL • OTelに準拠したトレースでサーバ内のアクションを可視化 • OracleDatabase • トレースファイルという従来からの機能は存在するものの、現状、サー バ内のトレースをOtelエクスポートする機能は提供されていない。 • Driver側でOtelトレースを提供しているものもある。 › OracleJDBC、ODP.NET • CloudSQL（MySQL） • sqlcommenter を使用して計測。

29 © NTT CORPORATION 2024 アジェンダ • イントロダクション（分散トレーシング） • PostgreSQLにおける分散トレーシングの意義 • PostgreSQLにおける分散トレーシングの手法 • まとめ

30 © NTT CORPORATION 2024 まとめ • 分散トレーシングにおけるPostgreSQLのトレース手法を紹介。 • 分散システムやマイクロサービスの設計をしていく中で、デー タベースにおいてもオブザーバビリティへの追従は必須。 • それぞれのトレーシング手法の目的とシステム要件を踏まえて、 選定することが大事。 • 性能影響を考慮し、チューニングを適切に行う。

31 © NTT CORPORATION 2024 参考にさせていただいた資料 • ブログ、講演資料 • Cloud-native Postgres observability: from client apps to underlying cloud resources › Corootの講演資料。Postgres Conference 2024 USで紹介されたもの。 • eBPFに3日で入門した話

Your Value Partner

33 © NTT CORPORATION 2024 補足スライド

34 © NTT CORPORATION 2024 補足 : SQLCommenter • SQL接続クラス(ORM等)と連携し、SQLにコメント(任意の情報)を追 加できる • 例：APからDBに対して発行されたサンプルSQL › 赤字部分がSQLCommenterにより付与された情報（下記は抜粋） • 様々な言語、フレームワーク、データベースに対応 2019-05-28 11:54:50.780 PDT [64128] LOG: statement: SELECT * FROM FOO /*action='%2Fparam*d',controller='index,'framework='spring', traceparent='00-5bd66ef5095369c7b0d1f8f4bd33716a-c532cb4098ac3dd2-01', tracestate='congo%3Dt61rcWkgMzE%2Crojo%3D00f067aa0ba902b7'*/ 項目 値 framework spring traceparent (W3C TraceContext) 00-5bd66ef5095369c7b0d1f8f4bd33716a-c532cb4098ac3dd2-01 tracestate (W3C TraceContext) congo%3Dt61rcWkgMzE%2Crojo%3D00f067aa0ba902b7

35 © NTT CORPORATION 2024 補足：eBPF • ユーザ空間の処理をカーネル空間 にオフロード • K8sのコンテナ間通信による活用が eBPF普及の大きな要因 • netfilter/iptables によるのコンテナ間 通信をeBPFの活用によりオーバヘッド 削減(例：Cilium) ユーザ空間とカーネル空 間でやり取りするパケッ ト量が多く、性能負荷が 大きい パケットのフィルタリング処理を カーネル空間にオフロード。多く の処理がカーネル空間で完結し、 パフォーマンスが向上する

36 © NTT CORPORATION 2024 • eBPFキャプチャにより継続的プロファイリングを提供 • CPU使用量を取得、ヒートマップを作成 • シンボル付きプログラムでなくともユーザシンボルが表示できる 補足 : 継続的プロファイリング #Coroot

37 © NTT CORPORATION 2024 補足スライド #Coroot

38 © NTT CORPORATION 2024 • エンタープライズ製品である NewRelic, Datadog の代替を目指す OSSの統合監視ツール(APM) • 製品紹介は割愛。（Live demo で機能や使用感を体験できる） Coroot について 直感的なUI アーキテクチャ

39 © NTT CORPORATION 2024 • eBPFベースのトレーシング • システムコールをキャプチャ • connect() から PID, IP, PORT, クエリステータスを取得 • write(), sendmsg()等から、PostgreSQL L7プロトコル（ワイヤープロトコル）の のカーネル空間のペイロードを取得 › ペイロードをパースしてからクエリテキストを抽出 • クライアント側で計測される • ネットワークレイテンシを含む coroot-node-agent #Coroot AP1 DB1 User ③トレース情報の提供 ①クエリ発行 ②結果返却 kernel ※詳細は割愛しています eBPF Program クエリテキスト AP coroot- node- agent

40 © NTT CORPORATION 2024 前提条件 #Coroot • eBPFに依存するため、Linuxカーネル4.16以上が必要 • Ubuntu 20.10以上、Debian 11以上、RHEL 8.2以上 • Coroot対応環境 • Kubernetes › Docker in Docker はサポートされていないため minikube(デフォルト) は実行できない » minikube with VM-based Driver は実行可能 (e.g. minikube start –driver=kvm) › WSLはサポートされていない • Docker、Docker Swarm、Ubuntu ＆ Debian、RHEL & CentOS • Corootが捕捉するテレメトリはコンテナのみ(cgroup内で実行 されるプロセス) • systemdサービスはコンテナとみなされる

41 © NTT CORPORATION 2024 インストール #Coroot $ curl -fsS https://raw.githubusercontent.com/coroot/coroot/main/deploy/docker-compose.yaml | docker compose -f - up –d $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 9451a61a8136 ghcr.io/coroot/coroot:latest "/opt/coroot/coroot …" 33 seconds ago Up 31 seconds 0.0.0.0:8080- >8080/tcp, :::8080->8080/tcp root-coroot-1 e81fdd93cffc clickhouse/clickhouse-server:24.3 "/entrypoint.sh" 33 seconds ago Up 32 seconds 8123/tcp, 9009/tcp, 127.0.0.1:9000->9000/tcp root-clickhouse-1 9e8b809db618 prom/prometheus:v2.45.4 "/bin/prometheus --c…" 33 seconds ago Up 32 seconds 127.0.0.1:9090- >9090/tcp root-prometheus-1 6431fb47f21a ghcr.io/coroot/coroot-node-agent "coroot-node-agent -…" 3 hours ago Up 32 seconds root-coroot-node-agent-1 ・coroot : UI、テレメトリのプロキシ ・clickhouse：ログ、トレース、プロファイル用のデータストア ・Prometheus：メトリクスのデータストア ・coroot-node-agent：ノードに常駐してテレメトリ収集するエージェント docker-compose を実行 コンテナ一覧を確認

42 © NTT CORPORATION 2024 ベンチマーク #Coroot • 目的 • eBPFキャプチャのオーバヘッドを測定 • バリエーション • パターン ※ › coroot-node-agent 有 › coroot-node-agent 無 • クライアント数 › 20, 40, 80, 100, 120 • ワークロード › pgbench –i –s 100 › pgbench -c $client –T 90 pgbench PostgreSQL ホスト コンテナ coroot- node-agent coroot clickhouse Query eBPF キャプチャ Trace Trace 凡例： 構成 ※ coroot-node-agent は eBPFキャプチャ以外にも役割（ログ やメトリクス収集等）があるため、厳密には eBPFキャプチャ のオーバヘッドのみを図れる手法ではない

43 © NTT CORPORATION 2024 ベンチマーク結果（TPS, Latency） #Coroot ※ 試行回数3回の平均 ※ 環境やワークロードにより性能傾向が異なる可能性があるため、あくまで参考値 0 10 20 30 40 50 60 70 20 40 60 80 100 120 レイテンシ クライアント数 coroot-node-agent=on coroot-node-agent=off 0 500 1000 1500 2000 2500 20 40 60 80 100 120 TPS クライアント数 coroot-node-agent=on coroot-node-agent=off わずかに on が性能劣化 わずかに on が性能劣化 Better Better

44 © NTT CORPORATION 2024 ベンチマーク結果（CPU, Memory） #Coroot ※ 試行回数3回の平均 ※ pgbench開始後30秒経過後のメトリクス(30秒間)から算出 ※ 環境やワークロードにより性能傾向が異なる可能性があるため、あくまで参考値 0 10 20 30 40 50 60 70 80 20 40 60 80 100 120 CPU クライアント数 coroot-node-agent=on(%user) coroot-node-agent=off(%user) coroot-node-agent=on(%system) coroot-node-agent=off(%system) coroot-node-agent=on(%iowait) coroot-node-agent=off(%iowait) 0 2 4 6 8 10 12 14 16 18 20 20 40 60 80 100 120 %MEMUSED クライアント数 coroot-node-agent=on coroot-node-agent=off on の方がメモリ使用率が高い on, off で大きな差はない Better Better

45 © NTT CORPORATION 2024 紹介した分散トレーシング手法のサマリ Coroot 目的 • NewRelicやDataDogの代替を目指すOSS • コンテナのテレメトリを捕捉して、メトリクス・ ログ・トレース・プロファイリングを取得、管 理、可視化 アーキテクチャ • UIを含む多数のコンポーネント - coroot - coroot-node-agent (OtelSDK) - Prometheus - ClickHouse ステータス • プロダクション向けリリース済み 監視するコンポーネント (coroot-node-agent) • コンテナ(クライアントサイド)のシステムコー ル by eBPF パフォーマンス (coroot-node-agent) • eBPFトレースによるオーバヘッドは極小 その他 (coroot-node-agent) • eBPFによるトレース情報取得時にAPの情 報がないため、アプリケーションのトレース と連結できてない（と思われる）