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
toittaにOpenTelemetryを導入した話 / Mackerel APM リリースパーティ
Search
cohalz
May 28, 2025
Technology
1
640
toittaにOpenTelemetryを導入した話 / Mackerel APM リリースパーティ
https://mackerelio.connpass.com/event/351815/
の発表資料です
cohalz
May 28, 2025
Tweet
Share
More Decks by cohalz
See All by cohalz
はてなにおけるfujiwara-wareの活用やecspressoのCI/CD構成 / Fujiwara Tech Conference 2025
cohalz
3
6.9k
はてなのSRE組織2024 / Road to SRE NEXT@福岡
cohalz
2
1.9k
SREのキャリア、 あるいは生態 / #ya8
cohalz
11
1.7k
カンファレンスのボランティアスタッフって何やるの? / DAIMYO Meetup #4
cohalz
0
170
小さなものでも Step Functions / Serverless Meetup Fukuoka Re:boot
cohalz
0
210
ECSのCI/CD改善と標準化の取り組み / JAWS FESTA 2023 in Kyushu
cohalz
8
7.3k
ecspressoへの貢献を振り返る / JAWS-UG コンテナ支部 #24 ecspresso MeetUp
cohalz
1
7.4k
はてなフォトライフをECSに移行した話 / Hatena Engineer Seminar #20
cohalz
1
19k
SREの異動と働き方 〜はてなブログ編〜 / Hatena Engineer Seminar #13
cohalz
0
2.4k
Other Decks in Technology
See All in Technology
Introduction to Bill One Development Engineer
sansan33
PRO
0
260
〜『世界中の家族のこころのインフラ』を目指して”次の10年”へ〜 SREが導いたグローバルサービスの信頼性向上戦略とその舞台裏 / Towards the Next Decade: Enhancing Global Service Reliability
kohbis
3
1.5k
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
19
7.6k
振り返りTransit Gateway ~VPCをいい感じでつなげるために~
masakiokuda
4
210
無理しない AI 活用サービス / #jazug
koudaiii
0
100
AIでテストプロセス自動化に挑戦する
sakatakazunori
1
540
Amazon SNSサブスクリプションの誤解除を防ぐ
y_sakata
3
190
AI エージェントと考え直すデータ基盤
na0
20
8k
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
39k
ClaudeCodeにキレない技術
gtnao
1
870
モニタリング統一への道のり - 分散モニタリングツール統合のためのオブザーバビリティプロジェクト
niftycorp
PRO
1
520
SREのためのeBPF活用ステップアップガイド
egmc
2
1.3k
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
840
The World Runs on Bad Software
bkeepers
PRO
70
11k
Designing for Performance
lara
610
69k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Transcript
toittaに OpenTelemetryを 導入した話 id:cohalz / @cohalz 2025-05-28 Mackerel APM リリースパーティ
1
自己紹介 • こはる(@cohalz) • 好きなOpenTelemetryの機能 ◦ Exponential Histogram 2
目次 • toittaの運用における課題 • OpenTelemetry導入による変化と展望 • Next.jsを例にサービス計装の流れを紹介 ◦ 時間があれば 3
toittaについて • 2024年7月にリリース • インタビュー動画をアッ プロードし、生成AIに よってその発話を分析す るサービス 4
toittaのシステム構成 • Google Cloud上に構築されたWebアプリ ◦ Cloud Run(Next.js) ◦ Cloud SQL(PostgreSQL)
• 生成AIを利用 ◦ Vertex AIとAzure OpenAI Service 5
6 なぜOTel導入をしたか
7 ブラックボックスな 部分が多いサービス
サービスの特性 として... • 入力 ◦ ユーザの動画ファイル • 出力 ◦ クラウド/生成AI処理
• 規約で許可なく 閲覧ができない 8
多種多様なエラー・ハルシネーション • 考えられる原因として... ◦ ファイルの形式が正しくない? ◦ クラウドの一時的な不調?クォータ制限? ◦ リリース起因? ◦
ファイルの音質や収音環境の問題? ◦ その他考慮してない部分があった? 9
これらに対処するために • 今まではログを中心に運用していた ◦ アラートやダッシュボードを作成 ◦ 実行時間、エラーの種別、SLOのダッシュボードも • 改善はしていたものの対応には時間がかかる 10
細かいデータが見れていない課題 • 例1: サービスのレイテンシ ◦ 動画アップロードで平均やp95が跳ね上がる ◦ この画面が遅いとかの分析が難しい • 例2:
エラーの状況がわかりづらい ◦ なんの処理が失敗してどこまで成功しているか ◦ エラーから処理時間を見るのも意外と面倒 11
状況を改善したいが... • ログとその活用で手作り対応が手間 ◦ 新機能の開発時に対応が漏れる ◦ 言語やフレームワークも違うことがある • その結果対応の属人性が高くなっていた ◦
典型エラーはドキュメントにまとめているが... ◦ アラートからログとドキュメントを開く手間 12
そんな中 • MackerelでAPM機能の開発が活発に ◦ 社内のサポートとフィードバックができるように • この機会にOTel導入をすることに ◦ ちなみに、チームに知見はない状態からスタート 13
14 OTel導入がスタート
計装への道のり • アプリケーションに計装する • ローカルでcollectorを立てて動作確認 • サービス上にサイドカー等で導入 • 扱いやすいように微調整 •
その後手動計装が必要なものにも導入 15
16 (実装の話は後半パート もしくは懇親会で)
17 OTelのトレース導入 による変化
課題は解決できたのか? • 課題の再掲 ◦ 各画面のレイテンシなどわかりたい ◦ エラー状況を把握したい ◦ 対応をスムーズにしたい 18
パスごとの統計情報がわかる 19
エラー状況が確認できる 20
エラーと対応を一緒に確認できる 21
開発の役に立った事例も • 一部のAPI呼び出しでスロットリングの実装を追加 • その際に処理時間の95%tileを見て方針を決定 ◦ 開発メンバーがMackerelを見ただけで進められた ◦ テナント単位などで集計して状況を確認しやすかった声も 22
OpenTelemetryの良さ • 標準の規格に乗ることで ◦ 世の中にナレッジ・ツールがあって情報を探しやすい • 他のサービスに送るといったこともすぐできる ◦ いろんなサービスを試しやすい ◦
乗り換えも実装がそのまま使える ◦ (Mackerelへのフィードバックも) 23
MackerelのAPM機能の良さ • 必要な情報にすぐ辿り着ける ◦ 目的ごとにタブが分かれている ◦ 必要な画面や検索欄も最小限で迷いにくい ◦ HTTPサーバーとデータベースの統計情報が特に見やすい ◦
課題(エラー)機能はその後の対応までまとめられる • => 迷いにくく慣れてない開発者もとっつきやすい 24
25 OTel導入の今後
OTel導入の今後 • メトリック情報も取れるようにする • アラートをMackerelに移行 • トレース情報を強化していく 26
メトリック情報も取れるようにする • 今は短期のメトリックをGoogle Cloud上で確認 ◦ クラウドのコンソール上は遅い、期限が短いなど課題 • Mackerelで確認できるようにしていく ◦ 長期のメトリックでキャパシティプランニング
◦ トレースから飛べる(逆も)も期待できる 27
アラートをMackerelに移行 • 現在はGoogle Cloud上でアラートを設定 • Mackerelのアラートに移行したい ◦ アラートの閾値や通知周りなど調整がやりやすい ◦ 慣れた画面で学習コストを減らせる(開発者も触りやすい)
◦ アラートの通知から対応・可視化など自動化も作りやすい 28
Tips: アラートにトレースのリンクをつける 29
トレースに情報を増やす • 分散トレーシングを強化 ◦ 例えば「こういうファイルの時にこういうエラーにな る」がログを見なくてもわかるように ◦ 外部サービス呼び出しの状況を把握する 30
LLMのトレース情報 • LLMに関する情報もトレースに載せる ◦ OpenLLMetryを利用? ◦ 入出力のトークン数 ◦ モデルの変化による振る舞いの変化を追えるように ◦
実際の入出力は閲覧できないのでマスクの必要も 31
32 付録: Next.jsを計装する までにやったこと
計装への道のり(再掲) • アプリケーションに計装する • ローカルでcollectorを立てて動作確認 • サービス上にサイドカー等で導入 • 扱いやすいように微調整 •
その後手動計装が必要なものにも導入 33
1. アプリケーションに計装する • 自動計装等で実装する ◦ @opentelemetry/auto-instrumentations-node ◦ @prisma/instrumentation • (重要)
dynamic importを使って読み込み ◦ Next.jsならInstrumentation機能を使う ◦ これをしないと計装のコードが読み込まれない 34
2. ローカルで確認する • (重要) 最初はConsoleSpanExporterでログに出す ◦ 実装か通信か問題を切り分けやすい • 手元でcollectorとバックエンドを立てて確認 ◦
いきなり送るとトレースやスパン数の爆発も • 複数のサービスに送って動作確認・切り分け ◦ 検証時はjaeger, mackerel, debug(ログ)に送っていた 35
3. データを整える • 送られたデータを見て運用できそうか確認 ◦ 正常・異常時に意図したトレースになっているか? • 本番データに送って大丈夫な量と内容か確認 ◦ サンプリング
◦ データのマスク 36
Tips: collector側で大体できる • 属性を追加・削除 ◦ Attributes Processor • ルールを決めてサンプリング ◦
Tail Sampling Processor • ロジックを書いて属性等を変換 ◦ Transform Processor 37
Tips: Transform Processorが高機能 • OTTLという言語で変換処理を記述 • 例1: 正規表現で属性をまとめる ◦ replace_pattern(span.attributes["http.route"],
"_rsc=[a-z0-9]{5}", "_rsc=*****") • 例2: 特定の条件で属性を削る ◦ delete_key(span.attributes, "xxx") where span.attributes["yyy"] == "zzz" 38
4. 本番に導入 • Cloud Runの場合 ◦ YAML形式の設定ファイルに移行が必要 ◦ https://github.com/GoogleCloudPlatform/openteleme try-cloud-run
• 各サービスのResource Detectionも追加 ◦ リビジョンやリージョンなどを埋めてくれる 39
5. 計装対象を増やす • 手動計装 ◦ 主にHTTPリクエストベースでないものには手動で ◦ 非同期処理にはAsyncHooksContextManagerを利用 • トレースの伝播
◦ Propagatorを利用してサービス間で伝播 ◦ データの渡し方は自由(独自ヘッダで渡すのが良いかも?) 40
感想など • APMって意外と難しくないという印象に ◦ 目的の情報にすぐ辿り着ける ◦ 開発メンバーと育てていけそう • 最初にデータを送るまでは大変ではある ◦
データが送られてない、まとまってないなど ◦ やり方は決まってるのでその後はスムーズ 41