SRE 視点で事業横断でのオブザーバ ビリティの民主化に取り組んでいる話

2026/2/13 に開催された Genda Talk イベントの「少人数SREでマルチプロダクトを支えるPlatform設計」で少人数SREでマルチプロダクトを支えるPlatform設計：PlatformとEmbedで回す、効率的なSRE活動の実践知の共有としてトークしました。

Transcript

1. ©MIXI ©MIXI SRE 視点で事業横断でのオブザーバ ビリティの⺠主化に取り組んでいる話 少⼈数SREでマルチプロダクトを⽀えるPlatform設計 2026/02/13 株式会社MIXI 開発本部 CTO 室 Platform Engineering グループ ⼤野⼀樹
2. 22 ©MIXI 自己紹介 大野一樹 X: @i2tsuki_ MIXI2: @itsuki ❖ SRE 9 年目くらい(?)のシニアな SRE ❖ 2024 年 1 月 株式会社MIXI 入社 開発本部 CTO 室 Platform Engineering グループ ❖ 普段は関西でリモート勤務 & 月 1,2 出社 ❖ 得意なことはパフォーマンス最適化
3. 3 ©MIXI ライフスタイル デジタルエンターテイメント スポーツ 株式会社MIXI のパーパス 「豊かなコミュニケーションを広げ、世界を幸せな驚きで包む。」
4. 4 ©MIXI ライフスタイル デジタルエンターテイメント スポーツ 開発本部 CTO 室 SRE ❖ サービスを技術面で支援する ❖ Embedded, Enabling の両輪でプロダクトの SRE を支援していた(〜2025年)
5. 5 ©MIXI ❖ 2024年: Embedded SREと Enabling SRE 開発本部 CTO 室の変遷 SRE グループ 2024 2025 2026 Embedding の終了で組織再編
6. 6 ©MIXI ❖ ミドルウェアの EOL 対応ができず、日々の運用を Embedded SRE が行っていた ➢ Embedded SRE へのオフロード ❖ 障害発生時に推測している ➢ 計測から仮説を立てて調査できていない ➢ Embedded SRE がポストモーテムを回す Embedding だけでは解決できない SRE の実情 SRE
7. 7 ©MIXI ❖ 2024年: Embedded SREと Enabling SRE ❖ 2025年: 共通化とプラットフォーム構想 開発本部 CTO 室の変遷 SRE グループ 2024 2025 2026 Embedding の終了で組織再編 開発基盤グループ Platform Engineering グループ SaaS, IaaS アカウントの管理 Central SRE + Platform SRE
8. 8 ©MIXI Embedding で対応してきた SRE の実情 ❖ サービスが正しく動いているだけで正常扱いになっている ❖ サービスの信頼性目標が決まっていない ➢ 計測できていない ➢ アラートが決まらない ❖ システムメトリクスでアラートを設定している ➢ 大量のアラートが暗黙知で無視されている
9. 9 ©MIXI Embedding で対応してきた SRE の実情 ❖ サービスが正しく動いているだけで正常扱いになっている ⇒ エラーログを観測する ❖ サービスの信頼性目標が決まっていない ➢ 計測できていない ➢ アラートが決まらない ⇒ ユーザー体験を観測する ❖ システムメトリクスでアラートを設定している ➢ 大量のアラートが暗黙知で無視されている ⇒ トレースを観測し調査可能にする
10. 10 ©MIXI ❖ オブザーバビリティはシステムの内部状態 を推測する能⼒ ❖ ログ‧メトリクス‧トレースの 3 要素のテ レメトリでシステムを観測 ❖ サービスの状態把握を誰でも可能にして問 題解決を⽀援する ⇒ SRE に依存しないチームを作る ⇒ オブザーバビリティはエンジニアだけのも のではない オブザーバビリティから始めよう https://www.oreilly.co.jp/books/9784814400126/
11. ©MIXI ゴールはオブザーバビリティの⺠主化
12. 12 ©MIXI ❖ 2024年: Embedded SREと Enabling SRE ❖ 2025年: 共通化とプラットフォーム構想 2026年: オブザーバビリティの⺠主化 ゴールはオブザーバビリティが向上して サービスの戦略や意思決定ができる状態 (サービスごとの投資判断、原価率計算) オブザーバビリティの⺠主化という⽬標 SRE グループ 2024 2025 2026 Embedding の終了で組織再編 事業横断的なオブザーバビリティの成熟 開発基盤グループ Platform Engineering グループ SaaS, IaaS アカウントの管理 Central SRE + Platform SRE
13. 13 ©MIXI オブザーバビリティの⽀援の課題 ❖ オブザーバビリティの成熟度 はサービスによって異なる ➢ サービスの SRE 成熟度が組織の外部からわからないように オブザーバビリティの成熟度も組織の外部からはわからない ▪ ログが構造化されているか ▪ ユーザー体験を表すサービスメトリクスが取得できているか ▪ ビジネス層がオブザーバビリティを獲得してサービス戦略を立てられているか
14. 14 ©MIXI オブザーバビリティの⽀援の課題 ❖ オブザーバビリティの成熟度 はサービスによって異なる ➢ サービスの SRE 成熟度が組織の外部からわからないように オブザーバビリティの成熟度も組織の外部からはわからない ▪ ログが構造化されているか ▪ ユーザー体験を表すサービスメトリクスが取得できているか ▪ ビジネス層がオブザーバビリティを獲得してサービス戦略を立てられているか Embedded としてスコープを限定して サービスに関わる
15. 15 ©MIXI オブザーバビリティの⽀援その1 ❖ グラフチェックダッシュボードを見る会の支援 ➢ とあるサービスでは週に 1 回ダッシュボードを見る会が開催されている ➢ ファシリテーション担当は持ち回りでレポートを作成して議論する ▪ 目的はダッシュボードで発生しているエラーや傾向からサービスに詳しくなるため ⇒ 実際に Embedded として担当してみる..
16. 16 ©MIXI オブザーバビリティの⽀援その1 ❖ グラフチェックダッシュボードを見る会の支援 ➢ とあるサービスでは週に 1 回ダッシュボードを見る会が開催されている ➢ ファシリテーション担当は持ち回りでレポートを作成して議論する ▪ 目的はダッシュボードで発生しているエラーや傾向からサービスに詳しくなるため ⇒ 実際に Embedded として担当してみる.. • サービスの固有の知識が⾔語化されていない ◦ 無視していいアラートがある(以前から発⽣しているなど) ◦ 無視していいエラーと無視してはだめなエラーがわからない • レポートの品質が個⼈の知識に偏ってしまう現状
17. 17 ©MIXI オブザーバビリティの⽀援その1 ❖ グラフチェックダッシュボードを見る会の支援 ➢ サービス固有の知識を言語化する⇒知識のサイロ化を防ぐ ➢ 前回までのダッシュボードのレポートを知識としてまとめる ▪ 人間がサービス固有の知識を知っておく必要がなくしたい 何ができるか...
18. 18 ©MIXI オブザーバビリティの⽀援その1 ❖ グラフチェックダッシュボードを見る会の支援 ➢ サービス固有の知識を言語化する⇒知識のサイロ化を防ぐ ➢ 前回までのダッシュボードのレポートを知識としてまとめる AI を利⽤したダッシュボードレポートを⾃動作成(OpenAI API) 熟練したエンジニアでなくても何が起こっているかがわかるようになる! 時系列データベース & プロンプト LLM レポート レポート出⼒ コンテキスト として⼊⼒ ナレッジ
19. 19 ©MIXI オブザーバビリティの⽀援その2 ❖ リアーキテクティングに伴うオブザー バビリティの充実 ➢ サービスでの構成変更に伴うボト ルネックを調査したい (計測手段について明るくない) ▪ 外部との通信にどれくらい時 間がかかるか ⇒ ログを出力して計測するか ▪ マネージドサービスのメトリ クスをどのように取得するか ⇒ CloudWatch Exporter
20. 20 ©MIXI オブザーバビリティの⽀援その2 ❖ リアーキテクティングに伴うオブザー バビリティの充実 ➢ あるサービスでの構成変更に伴う ボトルネックを調査したい (計測手段について明るくない) ▪ 外部との通信にどれくらい時 間がかかるか ⇒ ログを出力して計測するか ▪ マネージドサービスのメトリ クスをどのように取得するか ⇒ CloudWatch Exporter https://github.com/percona/rds_exporter 適切な⽅法を選択する New Relic APM のトレーススパンを作成する (ログを使わず適切な計装を提案する )
21. 21 ©MIXI オブザーバビリティの⽀援その3 ❖ サービスごとにオブザーバビリティの要件が異なる ➢ APM だけ利用できればいい、どういったアラートを設定すべきか ➢ 1 年前のメトリクスをダウンサンプリング無しで保存したい ➢ AI を利用したい
22. 22 ©MIXI オブザーバビリティの⽀援その3 ❖ サービスごとにオブザーバビリティの要件が異なる ➢ APM だけ利用できればいい、どういったアラートを設定すべきか ➢ 1 年前のメトリクスをダウンサンプリング無しで保存したい ➢ AI を利用したい それぞれの要件に合ったオブザーバビリティツールを提案して導⼊をサポートする 機能要件ヒアリング、コスト⽐較、社内での実績紹介、開発者への導⼊までやる New Relic self-hosted Victoria Metrics Grafana Cloud パフォーマンス計測したい 新規のエラーログ⾒たい メトリクスの保存コス トを抑えたい OpenTelemetry を利⽤し たまま AI を利⽤したい
23. 23 ©MIXI オブザーバビリティの⽀援でわかったこと ❖ よかったこと ➢ 様々なサービスに関わることができる ➢ サービスごとのオブザーバビリティの成熟度を比較できる ➢ オブザーバビリティの流行に敏感になれる ❖ 難しかったこと ➢ サーバーインフラ (IaaS, IaC) がサービスごとに異なる ▪ メトリクスを増やそうとしてもサービスのサーバーインフラに関するドメ イン知識が必要になる ➢ オブザーバビリティのプラットフォームを統一できない難しさ ▪ サービスに主導権がある、Single Sign On の基盤も違う
24. 24 ©MIXI 今後の課題 ❖ Embedding としてサービスに関わる際の課題 ➢ いつまで Embedding としてサービスのオブザーバビリティを支援するか ➢ オブザーバビリティをプロダクトを推進するための強力なツールとして 認識してもらうまでを頑張る i. 支援の期限を決める ii. オブザーバビリティの成熟度モデルを作成してサービスを評価する
25. 25 ©MIXI 今後の課題 ❖ Embedding としてサービスに関わる際の課題 ➢ いつまで Embedding としてサービスのオブザーバビリティを支援するか Platform Engineer, Central SRE だけがオブザーバビリティを理解して利用 しているだけではだめ ⇒サービス全体でオブザーバビリティが民主化されなければならない オブザーバビリティのサイクルを回しサービスの意思決定に利用できる状態 =>すぐにゴールを達成することは難しいので段階的に評価する ➢ Embedded SRE が抜ける時期を決めるようにマイルストーンとして期限も決め る
26. 26 ©MIXI まとめ ❖ Embedded SRE では解決できなかった問題を解決する ➢ 推測ではなく計測できるようになる ➢ ゴールはオブザーバビリティの民主化 ❖ オブザーバビリティに注目して横断的にアプローチしている ➢ オブザーバビリティを浸透するために、アプローチを使い回せる ▪ ダッシュボードレポートの AI レポート作成、トレースの取得 ➢ 様々なオブザーバビリティツールに触れることで、最適解を提案する ▪ 社内での事例を知っていることで説得力のある提案ができる ➢ 横断的に支援することでオブザーバビリティの成熟度が見えてくる ▪ オブザーバビリティの底上げをする、ビジネスの戦略を支援する