GigaViewerにおけるMackerel APM導入の裏側

GigaViewerにおけるMackerel APM導入の裏側 - 自社ソリューションとOpenTelemetry活用で実現した分散トレースの今とこれから

https://mackerelio.connpass.com/event/351815/

Transcript

1. GigaViewerにおける Mackerel APM導入の裏側 id:koudenpa 2025-05-28 Mackerel APM リリースパーティ 1
2. 概要 • GigaViewerにおけるMackerel APM導入の裏 側 - 自社ソリューションとOpenTelemetry活 用で実現した分散トレースの今とこれから ◦ Geminiに「アウトラインからタイトルを考案して」 と頼んだらタイトルスライドに収まらなかったもの • 概ねこの通りの内容 2
3. 自己紹介 • id:koudenpa ◦ コウデン • はてなでの役割 ◦ マンガメディア開発チーム ◦ テックリード ▪ エンジニアリングを広く見る 3
4. Mackerelとの付き合い • 中途での入社前から使っていた • 入社後も公私で普通に使っていた • 結果、アンバサダーになり損ねた 4
5. Mackerel アンバサダープログラム • https://mackerel.io/ja/blog/entry/amba ssador/about • これ（2019年1月） • 入社（2018年11月） 5
6. Mackerel以外のAPM • 私用ではApplication Insights ◦ Microsoftの技術スタック ◦ https://koudenpa.hatenablog.com/search?q=Ap plication+Insights • 他は後述のX-Ray程度 6
7. 発信傾向 • どうやら自分の発表は • 「あたりまえのことしてます」 • になりがち ◦ 今回も多分そう ◦ つまりOpenTelemetryでのトレース1事例 7
8. 目次 • 導入前の状態・状況 • 導入感 • 導入直後感 • エピソード • これから 8
9. 9 導入前の状態・状況
10. GigaViewer • そこそこ歴史のあるWebマンガビューワ • 最古のPR（プレスリリースの方） ◦ 2017-01-18 ◦ https://hatena.co.jp/solutions/gigaviewer 10
11. GigaViewerのホスティング • AWSのマネージドサービス ◦ CloudFront/ALB/RDS Aurora/etc • コンピューティングは主にECS Fargate ◦ 過去には主にEC2 11
12. Mackerelの利用状況 • メトリクス収集 ◦ mackerel-agent/container-agent ◦ AWSインテグレーション • 可視化、監視 • 身近、日常 12
13. APMの状況 • AWS X-Ray ◦ パフォーマンス上のボトルネック特定 ◦ 負荷試験時のパフォーマンス確認 • 非日常 13
14. 14 導入感
15. Why Mackerel • 率直には自社ソリューションなので 15
16. Why OpenTelemetry • 分散トレース ◦ 今後システムを分散化していく予定がある • 今後の業界標準の仕組み ◦ 検討中のミドルウェアもOpenTelemetry対応 • ちょうど自社で賄えるように ◦ なのでどうせならMackerelで 16
17. 17 導入直後感
18. APMの現在地 • 一番素朴な分散トレース ◦ フロントエンドと主バックエンドのトレース ◦ Next.js SSR -> GraphQL API • 今後追加するロールのトレースレディ ◦ GraphQL FederationのRouter ▪ GraphQL APIの段階的マイグレーション検討中 18
19. 一番素朴な分散トレース 19 Next.js SSR GraphQL API
20. 今後追加するロールのトレースレディ 20 Next.js SSR GraphQL Router GraphQL API この辺に移行後 GraphQL APIが増 える見込み
21. 導入直後感 • APMが身近になった ◦ 元々身近だったところの隣に生えた ◦ 概観からトレースへの移動をしやすい • それ以上は……「これから」 21
22. 22 エピソード
23. エピソードいくつか • OpenTelemetry、簡単ではない • クライアントからみたDBクエリの統計 • APMが身近になった（エピソード） 23
24. OpenTelemetry、簡単ではない • Mackerel好きな理由 ◦ mackerel-agentの導入簡単 ◦ メトリック管理簡単 • OpenTelemetry計装、otel-collector導入 ◦ 簡単ではない…… 24
25. 簡単ではない • OpenTelemetry自体 ◦ 仕様が（まだ）安定していない ◦ 実装が仕様通りとは限らない • otel-collector ◦ 要否やどこでどう動かすのかまで ◦ 選択肢が多すぎる 25
26. サンプリングレート • 全量だと相当量->間引きたい • トレース予算に合わせた量にサンプリング ◦ X-Rayでのトレースがベース ◦ 悲観的な割合で開始 26
27. 今のところ • otel-collector ◦ ECSのサイドカーに配置 ▪ X-Ray daemon/mackerel-container-agentなどでの慣れ ◦ 最低限の設定 • 経路 ◦ バックエンドPerl ▪ 元々あったX-Ray向けの実装 -> AWS X-Ray Receiver ◦ 他 ▪ 自動計装やミドルウェアの計装 -> otlp 27
28. MackerelとOpenTelemetry • Mackerelでいい感じにOpenTelemetry ◦ 主に例示がされているが？ • まだこなれていない感 • こなれていくことを期待 ◦ そのための社内FBは適宜やっていく 28
29. クライアントからみたDBクエリの統計 • AuroraのPerformance Insights ◦ DBサーバ上の所要時間統計 ◦ これまで主に見ていたもの • APMのデータベースタブ ◦ クライアントアプリケーション上の所要時間統計 ◦ 今回改めて目にするようになったもの 29
30. DBセッションの設定クエリが見えた 30 あるデータベースクエリ
31. たかが1ミリ秒、されど1ミリ秒 • `SET`3回を1回のクエリに • 結果、全リクエストが1ミリ秒程度高速化 ◦ チームメンバーからの反応 ◦ 「まぁ、遅くなるよりはいいですよね」 31
32. APMが身近になった • 元々身近だったところの隣に生えた ◦ Mackerelは元々見ていた ◦ パフォーマンスなどを気にしてメトリックを見にき て、隣にAPMがある 32
33. APMが身近になった • 概観からトレースへの移動をしやすい ◦ 「HTTPサーバー」「トレース」タブ ◦ 実際見たい「遅いエンドポイント」「遅いクエリ」 ◦ 現状ちょうどよい 33 素朴に便利
34. APMが身近になった • 実際見たい「遅いエンドポイント」「遅いク エリ」 ◦ それぞれログの集計やDBの統計で見てはいた ◦ APM機能で分かりやすく詳細（トレース）と繋がった ▪ 遅いエンドポイントの中身 ▪ 遅いクエリがどこから、どんな他のクエリと一緒に 34
35. 35 これから
36. これから • APMを活用する切っ掛けにはなった • 身近になったAPMを日常に ◦ 定期的にメトリクスを見ている場でAPMも見る ▪ パフォーマンス改善ポイントのピックアップ、改善の追跡に 繋げる • 新規要素追加時のパフォーマンス評価に活用 ◦ GraphQL Federation導入に当たっての目途は立った 36
37. GigaViewerもよろしく 37 37