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
850
OpenTelemetryのバックエンドを作ってparquetと戯れている話
mrasu
September 28, 2023
Tweet
Share
Other Decks in Programming
See All in Programming
今話題のMCPサーバーをFastAPIでサッと作ってみた
yuukis
0
110
サービスレベルを管理してアジャイルを加速しよう!! / slm-accelerate-agility
tomoyakitaura
1
200
VitestのIn-Source Testingが便利
taro28
8
2.4k
Boost Your Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
740
AIコーディングエージェントを 「使いこなす」ための実践知と現在地 in ログラス / How to Use AI Coding Agent in Loglass
rkaga
4
1.2k
20250429 - CNTUG Meetup #67 / DevOps Taiwan Meetup #69 - Deep Dive into Tetragon: Building Runtime Security and Observability with eBPF
tico88612
0
160
状態と共に暮らす:ステートフルへの挑戦
ypresto
3
1.1k
プロダクト横断分析に役立つ、事前集計しないサマリーテーブル設計
hanon52_
3
530
iOSアプリで測る!名古屋駅までの 方向と距離
ryunakayama
0
150
M5UnitUnified 最新動向 2025/05
gob
0
120
The Nature of Complexity in John Ousterhout’s Philosophy of Software Design
philipschwarz
PRO
0
160
RubyKaigi Dev Meeting 2025
tenderlove
1
1.3k
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
68
11k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
Gamification - CAS2011
davidbonilla
81
5.3k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
13
820
Building Applications with DynamoDB
mza
94
6.4k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
The Cult of Friendly URLs
andyhume
78
6.3k
Mobile First: as difficult as doing things right
swwweet
223
9.6k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
227
22k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
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)もよろしくお願いします。