Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
OpenTelemetryのバックエンドを作ってparquetと戯れている話
Search
mrasu
September 28, 2023
Programming
0
890
OpenTelemetryのバックエンドを作ってparquetと戯れている話
mrasu
September 28, 2023
Tweet
Share
Other Decks in Programming
See All in Programming
Testing Trophyは叫ばない
toms74209200
0
860
詳解!defer panic recover のしくみ / Understanding defer, panic, and recover
convto
0
240
Flutter with Dart MCP: All You Need - 박제창 2025 I/O Extended Busan
itsmedreamwalker
0
150
Amazon RDS 向けに提供されている MCP Server と仕組みを調べてみた/jawsug-okayama-2025-aurora-mcp
takahashiikki
1
110
JSONataを使ってみよう Step Functionsが楽しくなる実践テクニック #devio2025
dafujii
1
530
AWS発のAIエディタKiroを使ってみた
iriikeita
1
180
Namespace and Its Future
tagomoris
6
700
プロポーザル駆動学習 / Proposal-Driven Learning
mackey0225
2
1.3k
アプリの "かわいい" を支えるアニメーションツールRiveについて
uetyo
0
260
Kiroの仕様駆動開発から見えてきたAIコーディングとの正しい付き合い方
clshinji
1
210
テストコードはもう書かない:JetBrains AI Assistantに委ねる非同期処理のテスト自動設計・生成
makun
0
260
HTMLの品質ってなんだっけ? “HTMLクライテリア”の設計と実践
unachang113
4
2.8k
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
520
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
Agile that works and the tools we love
rasmusluckow
330
21k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Embracing the Ebb and Flow
colly
87
4.8k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Gamification - CAS2011
davidbonilla
81
5.4k
Context Engineering - Making Every Token Count
addyosmani
2
41
How STYLIGHT went responsive
nonsquared
100
5.8k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.8k
Transcript
OpenTelemetryのバックエンド を作ってparquetと戯れている話 株式会社Vaxila Labs 杉中宏亮
⾃⼰紹介 • 杉中 宏亮 (@m_rasu) • 株式会社 Vaxila Labs •
趣味では昔からGo、仕事では 1年ぐらい
SRE NEXTに 落ちたので来ました
SRE NEXTに落ちたので来ました SRE NEXTは明⽇。 SRE NEXTではOpenTelemetry関連のOSSの話をしようと 思ってましたが、 Goの⼈たちの前なので僕が書いている実装の話をします。
OpenTelemetryネィティブの監視SaaSで 会社を作りました
話したいこと Parquetのためにしてる⼯夫 -> Parquet 楽しい
⽬次 1. Parquetとは 2. OpenTelemetryとは 3. Vaxilaとは 4. Parquetと遊ぶ a.
ファイルの内容を考える b. Athenaと遊ぶ
⽬次 1. Parquetとは 2. OpenTelemetryとは 3. Vaxilaとは 4. Parquetと遊ぶ a.
ファイルの内容を考える b. Athenaと遊ぶ
Parquetとは • 列指向のファイルフォーマット ◦ CSVやJSONは⾏指向 • ⼤規模なデータを保存するときによく使われる • カラム単位でエンコーディング⽅法を変えられる •
Readに強い代わりに、Writeはダメ
Parquetのエンコーディング⽅法 代表例 • Run length Encoding ◦ 「a,a,a,b,b,b,a,a」 -> 「a3b3a2」みたいな
• Delta Encoding ◦ 差分を書くことで容量圧縮 ◦ 時間の列で⾼威⼒ ◦ 「7,5,3,1」 -> 「7,-2, 3 (最初が7で、-2を連続3回)」みたいな • zstd,snappy,lz4 なども
Goで使う Goなら • xitongsys/parquet-go • parquet-go/parquet-go Vaxilaでは「parquet-go/parquet-go」を使⽤
⽬次 1. Parquetとは 2. OpenTelemetryとは 3. Vaxilaとは 4. Parquetと遊ぶ a.
ファイルの内容を考える b. Athenaと遊ぶ
OpenTelemetry とは OpenTelemetry is a vendor-neutral open-source Observability framework -
公式 https://opentelemetry.io/docs/
OpenTelemetry とは 簡単に⾔うと、 • 分散トレーシング • メトリクス • ログ を作ったり、送信したりするのに必要なSDK、プロトコルな
ど⼀式 ベンダー⾮依存が特徴
OpenTelemetryの流れ
OpenTelemetry で分散トレーシング 分散トレーシングという名前だが、分散環境じゃなくても便利 下図の1本1本がSpan SpanにはHTTPのパスやSQLなど⾊々記録している
OpenTelemetry は Protocol Buffers • データを送信する時は基本的にProtocol Buffers • json もできる
• Apache Arrow の実装もそのうちできそう
Protocol Buffers例 message TracesData { repeated ResourceSpans resource_spans; } message
ResourceSpans { repeated ScopeSpans scope_spans; } message ScopeSpans { repeated Span spans; } message Span { bytes trace_id; bytes span_id; repeated KeyValue attributes; } 例えば、トレーシングのProtocol Buffersはこんな感じ attributes の中に、 URLや実⾏したSQLが⼊ってい る
OpenTelemetry は Protocol Buffers VaxilaではParquetのフォーマットで保存している
⽬次 1. Parquetとは 2. OpenTelemetryとは 3. Vaxilaとは 4. Parquetと遊ぶ a.
ファイルの内容を考える b. Athenaと遊ぶ
Vaxilaとは • 問題を解決するための監視ツール • OpenTelemetryを使ってエラーや速度低下の原因を探し て教える 「SLOを良くするために」
なんで作った? • 原因を⾒つけるために⾊々な特徴を探してた 「これ、⼈間がやる必要ある?」 -> 機械がやれよ • 「それ、前からエラー鳴ってたみたいですが、 全員無視してますね‧‧‧」を無くしたい • 安く
SLOに問題が! 原因特定の流れ
エラーのトレースと、それ以外を⽐べて原因を推測する 原因特定の流れ
attributes の分布からエラー原因を探すことも 原因特定の流れ
アーキテクチャ S3にParquet
⽬次 1. Parquetとは 2. OpenTelemetryとは 3. Vaxilaとは 4. Parquetと遊ぶ a.
ファイルの内容を考える b. Athenaと遊ぶ
Parquetと遊んでいます • S3にParquet • Athenaで検索
Parquet (OpenTelemetry) ファイルから原因を探す • 例外が起きたか? • 実⾏時間が⻑すぎないか? • エラーではないSpanと⽐較すれば ◦
「user_idが99のときだけエラー起きてるな」 ◦ 「このインスタンスだけ遅いから捨てよう」 というのがわかる
⽬次 1. Parquetとは 2. OpenTelemetryとは 3. Vaxilaとは 4. Parquetと遊ぶ a.
ファイルの内容を考える b. Athenaと遊ぶ
OpenTelemetryのフォーマットは使わない Athena (trino) は配列内に触れるとスキャン量がかなり増える -> GoではSpanをトップレベルに type TraceSpan struct {
TraceID []byte `parquet:"trace_id"` SpanID []byte `parquet:"span_id"` Attributes []Attribute `parquet:"attributes,list"` Scope InstrumentationScope `parquet:"scope"` } message ScopeSpans { InstrumentationScope scope; repeated Span spans; } message Span { bytes trace_id; bytes span_id; repeated KeyValue attributes; } go pb
エンコーディングを選ぶ 今は無難なところを指定している • stringの列はzstd • 時間を表す列はdelta encoding type TraceSpan struct
{ SpanID []byte `parquet:"span_id"` Name string `parquet:"name,zstd"` StartTimeUnixNano uint64 `parquet:"start_time_unix_nano,delta"` EndTimeUnixNano uint64 `parquet:"end_time_unix_nano,delta"` }
頻出フィールドを冗⻑化する Spanの属性には “service.name” というキーがよく検索条件になる -> トップレベルにフィールドを作る 他にも、 「例外が起きたか」 などを事前に計算 type
TraceSpan struct { TraceID []byte `parquet:"trace_id"` ServiceName string `parquet:"service_name,zstd,dict"` HasExceptionEvent bool `parquet:"has_exception_event"` } トレース検索の絞り込み
⽬次 1. Parquetとは 2. OpenTelemetryとは 3. Vaxilaとは 4. Parquetと遊ぶ a.
ファイルの内容を考える b. Athenaと遊ぶ
Athenaを使う = SQL を書く SQLは頑張る • Athenaは途中の結果を再使⽤しない ◦ 2回参照したら2回読み込まれる ->
遅い‧お⾦かかる • つまり、UNIONと相性が悪い -> concat, case, filter などで1回しか読まなくてもい いように頑張る
ファイル数を減らして⾼速化 Athenaはファイルを参照するのは時間がかかる 「⼩さいファイルが⼀杯」よりも、「巨⼤なファイルが 少々」の⽅が速い (Parquetの効率も良くなる)
×「データが来るたびにファイルを作る」 ◦「数秒待って1ファイルにまとめる」 キューで⼀括保存
別DBにある項⽬で絞り込み 検索項⽬がRDB(Aurora)にあることがある 「この問題が起きたTraceの中から検索したい」 -> 100万Traceあったら100万個のORがついたSQLが必要ってこと ‧‧‧? -> TraceIdを全部⼊れたファイルを⼀時的にアップロードしてAthena 上でTraceIdを取得できるようにする トレース検索の絞り込み
と、⾊々している
結論 Parquet 楽しい
以上 X(@vaxila_labs)もよろしくお願いします。