Goで挑む大規模データ処理

hatena.go #2 Goで挑む大規模データ処理 2025.10.31 ja.mackerel.io

オブザーバビリティ プラットフォーム やってます 2

名前は Mackerel 3

出会った問題と対策、話します 4

自己紹介 杉中 宏亮 （id:mrasu / @m_rasu） ● Mackerelのアプリケーションエンジニア ● Web ~ DevOps あたりが興味範囲 ● 最近の興味は、Apache Paimon, Vortex 5

目次 1. はじめに 2. 問題 3. 調査 4. 統計画面を高速化 5. 検索画面を高速化 6. 終わりに 6

目次 1. はじめに 2. 問題 3. 調査 4. 統計画面を高速化 5. 検索画面を高速化 6. 終わりに 7

はじめに ※ 注意 今日話す内容は、話者が経験したことを基にしたものです。 各種資料は発表のために再現したものです。 極力再現していますが、実際とは違うデータです。 8

本日の主役 - APM APMとは、レイテンシーやトレースなど見れるもの 9

本日の主役 - APM APMは、OpenTelemetryから来るトレースをAthenaで検索している AWS 検索 S3 Athena サーバー 簡略図 10

オブザーバビリティプラットフォームのデータ量 (参考) Pinterest (Goku): 毎日4.5兆のデータポイント > Goku was ingesting 4.5 trillion datapoints daily and serving 15K queries per second with a p99 latency of 100 millisecond Goku: A Schemaless Time Series Database for Large Scale Monitoring at Pinterest AbemaTV: 165万スパン / 秒 > ピーク時165万スパン/秒に立ち向かえ！オブザーバビリティコストを 効率化する ABEMA におけるトレースサンプリングの実践的事例 Observability Conference Tokyo 2025 11

目次 1. はじめに 2. 問題 3. 調査 4. 統計画面を高速化 5. 検索画面を高速化 6. 終わりに 12

問題 APMが正式リリース トレースの保存期間が増加 (3日 -> 14日) 表示できる期間が増えた 13

遅い 長期間を表示しようとすると、 ローディングが終わらないテナント(オーガニゼーション)を発見 14

目次 1. はじめに 2. 問題 3. 調査 4. 統計画面を高速化 5. 検索画面を高速化 6. 終わりに 15

調査開始 Athenaのクエリが遅いと判明 「30秒近くかかってる」 確かに大規模で回すと何十分もかかることはある。 けど、そんな使い方はしていない。 16

調査 - Explain まずは、explain Athenaには挙動がわかるものがいくつかある ● 「Execution details」ボタン ● Explain ● Explain Analyze 例:「Execution details」の結果 17

調査 - Explain 1番好きなのは「explain analyze verbose」 「explain analyze」はクエリを実行して動作を教えてくれる 「verbose」をつけるとCPUなどの実行時間や回数がわかる 18

調査 - Explain Analyze Verbose explain analyze verbose してみる (注: ダミーデータです) 19

調査 - Explain Analyze Verbose explain analyze verbose してみる 24万！！！ (注: ダミーデータです) 20

調査 - small files problem 24万ファイルスキャンしているのはおかしい ファイルが多すぎる、いわゆる「small files problem」 S3でも503 (SlowDown: Please reduce your request rate) エ ラーが発生 21

「ファイル数減らすぞ！」 22

変更対象 遅いクエリを出している画面は2種類ある ● 統計画面 ● トレース検索画面 それぞれ対応することに 23

目次 1. はじめに 2. 問題 3. 調査 4. 統計画面を高速化 5. 検索画面を高速化 6. 終わりに 24

統計画面 MackerelはDBやHTTPの統計を出せる 25

統計画面を高速化 DB画面ではSQLごとの合計時間やP95などを出している 26

統計画面を高速化 期間を広げるとずっと出なかった 27

統計 「統計、毎回計算する必要ある？」 28

事前集計 事前に計算しておけば、被っている部分の計算を省略できる 集計範囲 集計済み期間 事前集計部分からはみ出した期間 集計前の期間 29

事前集計 合計値や平均は事前に計算しておくのは簡単 ただし、パーセンタイルを出すためにはソートがいる そんな時に使えるのが、t-digest (パーセンタイルの近似値) これらを事前に計算しておく 30

事前集計 - 定期実行 EventBridge を起点に、定期的に集計 集計 Athena 定期実行 EventBridge 保存 S3 31

事前集計 - 定期実行 Athenaの結果を取得する時は、iter.Seqを利用し、結果をs3に保存 (イメージ) 32

事前集計 - できた 2週間を表示できるようになった HTTP画面 33

目次 1. はじめに 2. 問題 3. 調査 4. 統計画面を高速化 5. 検索画面を高速化 6. 終わりに 34

検索 Mackerelの トレース 検索画面 35

検索 実行時間分布 も出る 36

検索 期間が長いと ずっと 出なかった 37

検索 - 柔軟性が必要 トレースは色々な条件で検索したい ● 実行時間 ● HTTPステータス ● SQL ● etc.. だから、事前に計算するのは難しい 38

検索 - 理由 遅い理由は「ファイル数が多かったから」と同じ (2x万ファイル) データ量が同じでもファイル数が減れば速くなる ダミーデータで計測したら 30秒 -> 2秒 39

検索 「ファイル、まとめよう」 40

検索 - ファイル ファイルはParquetフォーマットで保存している Parquetは変更は苦手 Parquet 愚直にやると、メモリを大量に使う (CPUも使う) 41

検索 - ファイルをまとめる けれど、ParquetはRowGroup単位で分けられている → RowGroupごとにまとめると省メモリ 42

検索 - ファイルをまとめる まとめる処理は ● 定期処理 ● 負荷が高い -> AWS Lambdaで実行 43

検索 - ファイルをまとめる S3には「削除と同時に追加」という原子的な操作はできない つまり、クエリ実行すると重複が起きる可能性がある 重複を起こさないために、複数テーブルにして合算 小さいファイル用のテーブル (まとめる前) まとめたファイル用のテーブル 44

検索 - 速くなった 2週間でも でるようになった 45

目次 1. はじめに 2. 問題 3. 調査 4. 統計画面を高速化 5. 検索画面を高速化 6. 終わりに 46

終わりに これで、終わらないローディングが終わるようになった 色々対策考えたけれど、無難な方法に落とし込めてよかった 47

終わりに 以上。 ご清聴、ありがとうございました。 48