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
NixOS + Kubernetesで構築する自宅サーバーのすべて
ichi_h3
0
730
明日から始めるリファクタリング
ryounasso
0
140
After go func(): Goroutines Through a Beginner’s Eye
97vaibhav
0
390
Advance Your Career with Open Source
ivargrimstad
0
510
(Extension DC 2025) Actor境界を越える技術
teamhimeh
1
250
その面倒な作業、「Dart」にやらせませんか? Flutter開発者のための業務効率化
yordgenome03
1
130
CSC305 Lecture 04
javiergs
PRO
0
270
登壇は dynamic! な営みである / speech is dynamic
da1chi
0
310
はじめてのDSPy - 言語モデルを『プロンプト』ではなく『プログラミング』するための仕組み
masahiro_nishimi
0
190
Introducing ReActionView: A new ActionView-Compatible ERB Engine @ Kaigi on Rails 2025, Tokyo, Japan
marcoroth
3
1k
オープンソースソフトウェアへの解像度🔬
utam0k
15
2.8k
Server Side Kotlin Meetup vol.16: 内部動作を理解して ハイパフォーマンスなサーバサイド Kotlin アプリケーションを書こう
ternbusty
3
180
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
232
18k
Fireside Chat
paigeccino
40
3.7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
189
55k
Practical Orchestrator
shlominoach
190
11k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.5k
Keith and Marios Guide to Fast Websites
keithpitt
411
23k
GraphQLとの向き合い方2022年版
quramy
49
14k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.2k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
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)もよろしくお願いします。