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