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
910
0
Share
OpenTelemetryのバックエンドを作ってparquetと戯れている話
mrasu
September 28, 2023
Other Decks in Programming
See All in Programming
PHP 7.4でもOpenTelemetryゼロコード計装がしたい! / PHPerKaigi 2026
arthur1
1
460
AI-DLC 入門 〜AIコーディングの本質は「コード」ではなく「構造」〜 / Introduction to AI-DLC: The Essence of AI Coding Is Not “Code” but “Structure”
seike460
PRO
0
160
モックわからないマン卒業記 ~振る舞いを起点に見直した、フロントエンドテストにおけるモックの使いどころ~
tasukuwatanabe
3
440
GoのDB アクセスにおける 「型安全」と「柔軟性」の両立 - Bob という選択肢
tak848
0
300
Smarter Angular mit Transformers.js & Prompt API
christianliebel
PRO
1
110
見せてもらおうか、 OpenSearchの性能とやらを!
shunta27
1
170
条件判定に名前、つけてますか? #phperkaigi #c
77web
2
910
ネイティブアプリとWebフロントエンドのAPI通信ラッパーにおける共通化の勘所
suguruooki
0
230
Agentic AI: Evolution oder Revolution
mobilelarson
PRO
0
220
仕様漏れ実装漏れをなくすトレーサビリティAI基盤のご紹介
orgachem
PRO
8
3.9k
車輪の再発明をしよう!PHP で実装して学ぶ、Web サーバーの仕組みと HTTP の正体
h1r0
2
480
事業会社でのセキュリティ長期インターンについて
masachikaura
0
130
Featured
See All Featured
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
250
[SF Ruby Conf 2025] Rails X
palkan
2
880
The untapped power of vector embeddings
frankvandijk
2
1.6k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
The Cost Of JavaScript in 2023
addyosmani
55
9.8k
Being A Developer After 40
akosma
91
590k
SEO for Brand Visibility & Recognition
aleyda
0
4.4k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
2
620
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
470
Ethics towards AI in product and experience design
skipperchong
2
240
What's in a price? How to price your products and services
michaelherold
247
13k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
110
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)もよろしくお願いします。