SRE NEXT 2026

SRE NEXT 2026 発表資料
Engも、Bizも、CSも。組織横断タスクフォースで実現したライブ配信サービスの信頼性向上

1. 1 © M3, Inc. 2026 #srenext_a © M3, Inc. 2026 エムスリー株式会社 後藤 祥 (Akira Goto) Engも、Bizも、CSも。 組織横断タスクフォースで実現した ライブ配信サービスの信頼性向上
2. 2 © M3, Inc. 2026 #srenext_a エムスリー株式会社 ゼネラルマネージャー/SREチーム チームリーダー 後藤 祥 SIerのシステムエンジニアを経て、エムスリー入社時に プロダクトチームのEmbedded SREとしてSREの キャリアをスタートした。 現在は横断SREチームのリーダーとして全社レベルでの 施策を推進している。 SRE NEXT 2024登壇。 Akira Goto https://speakerdeck.com/akiragoto/central-sretoembedded-srenohaiburitudoti-zhi-demu-zhi-suzui-gao-nosrezu-zhi
3. 3 © M3, Inc. 2026 #srenext_a Index • ライブ配信サービスの説明 • エンジニアリング観点での信頼性向上の取り組み • 組織横断TFでの安定運用への取り組み • まとめ
4. 4 © M3, Inc. 2026 #srenext_a ライブ配信サービスの説明
5. 5 © M3, Inc. 2026 #srenext_a テクノロジーを創造的に活用し、健康で楽しく長生きする人を 1人でも増やし、不必要な医療コストを1円でも減らすこと (※) 2025年3月時点 日本の医師のエムスリー会員率 エムスリーが事業展開している国の数 全世界の医師におけるエムスリー会員の割合 全世界で医師会員合計 18 カ国 (※) 50 %以上 (※) 650 万人以上 (※) 90 %以上 エムスリー が展開する医療従事者向け情報 サイト「m3.com」は33万人を突破、日本 の医師の9割以上が会員。(※)
6. 6 © M3, Inc. 2026 #srenext_a 私たちはプラットフォームとプロダクトの力を用いて様々 な医療課題の解決に取り組んでいます。 主に医療従事者に対してアプローチしながらも、同時にそ の先の一般の方々に対してもサービス提供を行い、総合的 に人々の健康的な毎日を少しでも改善することを目指し 様々なプロダクトの開発を行っております。 多くの医療者をユーザーに抱えるエムスリーだからこそで きるやり方で、多くの人々の健康に対して貢献していま す。 Platform × Product 健康で幸せな毎日を もっとよくするために
7. 7 © M3, Inc. 2026 #srenext_a 日本の医師の90%以上が登録する 国内最大級の医療従事者向けポータルサイト、m3.comを運営
8. 8 © M3, Inc. 2026 #srenext_a ライブ配信サービス • m3.comプラットフォーム上で医療従事者に向けた様々な動画コンテンツを届けるサービス 主催者 視聴者 m3.com
9. 9 © M3, Inc. 2026 #srenext_a エンジニアリング観点での 信頼性向上の取り組み
10. 10 © M3, Inc. 2026 #srenext_a SRE目線でみるライブ配信サービス • 配信の規模は大小様々 • 配信時間帯にアクセスが集中 • 開始時刻のアクセスのスパイク • 事前予約があるため大まかなアクセス数の予測ができる • 配信以外にもいくつか付随する周辺機能がある • ライブ中は絶対に落とせない あなたならどういう設計にしますか?
11. 11 © M3, Inc. 2026 #srenext_a アーキテクチャ概要 フロントエンド バックエンド DB、キャッシュ スケーリングバッチ 遅延処理 外部API呼び出し (イベント駆動) モニタリング
12. 12 © M3, Inc. 2026 #srenext_a 守りたいポイントを明確化しよう!!
13. 13 © M3, Inc. 2026 #srenext_a 守りたいポイントの明確化 サービスにおいて最も大事なのは 「ライブ配信時間中にユーザが正常に配信を視聴できること」 1 2 3 独自ロジックでの負荷予測とスケーリング 重要処理を守るための処理の非同期化 万が一のケースに備える機能縮退 4 ユーザ体験を全体を監視するブラウザテスト
14. 14 © M3, Inc. 2026 #srenext_a 1. 独自ロジックでの負荷予測とスケーリング 独自ロジックとオートスケールのハイブリット • 独自ロジック ◦ 配信開始前にスケールさせてスパイクに対応 ◦ 負荷予測に応じて柔軟にスケールアウト • オートスケール ◦ CPU使用率ベースのシンプルなもの ◦ 保険的な立ち位置 Writer/Read replicaのシンプルな構成 WriteとReadはアプリケーションレベルで分離 Read HeavyなのでスケールはRead replicaの追加
15. 15 © M3, Inc. 2026 #srenext_a 2. 重要処理を守るための処理の非同期化 処理の適切な非同期化はコアな機能を守ることにつながる 非同期にすべき処理の洗い出しとその徹底が重要で、コードレビューのチェック項目にも含めている SQS+Lambdaで遅延処理 連携サービスAPI イベント駆動による非同期化
16. 16 © M3, Inc. 2026 #srenext_a 3. 万が一のケースに備える機能縮退 高い負荷が予測される場合、視聴体験を守るために一部機能を縮退することができる 管理画面からの機能On/Off 独自APIゲートウェイによる 負荷コントロール 簡易的な画面へのフォールバック
17. 17 © M3, Inc. 2026 #srenext_a 4. ユーザ体験を全体を監視するブラウザテスト サービス単体が稼働していても動線上で問題が発生しているとユーザ体験が守れているとはいえない クリティカルユーザジャーニーが担保されていることを監視する必要がある ログイン 全体トップ遷移 視聴画面遷移 DataDogのブラウザテストで一連の画面遷移を定常的に確認
18. 18 © M3, Inc. 2026 #srenext_a ここまでのまとめ • “サービスの信頼性を高める”という抽象的な目標のままでは場当たり的な対応になってしまいがち • コンセプトをしっかりともつことが重要 • 「ライブ配信時間中にユーザが正常に配信を視聴できること」 を何よりも重視して守るようにしている
19. 19 © M3, Inc. 2026 #srenext_a 組織横断TFでの安定運用への取り組み
20. 20 © M3, Inc. 2026 #srenext_a MTBF/MTTR (とMTTD) ここまではサービスを落とさないための工夫 MTBF: 平均故障間隔 それでも障害を0件にはできないので、最速で復旧するための取り組みも必要 MTTD + MTTR: 平均検出時間 + 平均修復時間 MTBF MTTD + MTTR ここまでの話 ここからの話
21. 21 © M3, Inc. 2026 #srenext_a なぜ組織横断での連携が必要か サービスの早期復旧はエンジニアだけが頑張れば実現できるのか?
22. 22 © M3, Inc. 2026 #srenext_a なぜ組織横断での連携が必要か サービスの早期復旧はエンジニアだけが頑張れば実現できるのか? => No エンジニア 主催者 プロダクトマネージャー 視聴者 カスタマーサポート 営業 サービスオペレーター
23. 23 © M3, Inc. 2026 #srenext_a 組織横断タスクフォース 関係部署の担当者を集めてタスクフォースを結成 • 安定運用に関わる課題の抽出、対応の推進 • 障害対応マニュアルの整備、ロープレ訓練 • 障害発生時のサービス復旧含む全体対応 アドホックに対応するよりも体制をしっかり作っておくメリットは大きい • 部署横断で認識を合わせおくことでスピーディーな対応を実現できる • 改善サイクルを回すことができる
24. 24 © M3, Inc. 2026 #srenext_a 障害対応フローの全体像 1 2 3 障害検知と対応方針策定 サービス復旧 クロージング 問題発生から復旧作業開始までの時間を如何にして短縮するか (MTTD) 役割分担にしたがって各自が役割を果たす (MTTR) 状況の正確振り返りと再発防止策の推進
25. 25 © M3, Inc. 2026 #srenext_a 障害対応フロー 〜障害検知と対応方針策定〜 問題発生から復旧作業開始までの時間を如何にして短縮するか ① 問題発生 ② アラート発報 ③ アラートを検知 ④ 体制の立ち上げ ⑤ 初動調査 ⑥ 対応方針の策定 アラートを検知したら即時にオンライン会議を立ち上げて 対応メンバーを招集するルール 各部署で決定権のある責任者をメンバーとして招集する 実効性のある対策をその場で決定する
26. 26 © M3, Inc. 2026 #srenext_a 障害対応フロー 〜サービス復旧〜 エンジニア 主催者 プロダクトマネージャー 視聴者 カスタマーサポート 営業 サービスオペレーター 全体の対応リード 復旧作業 対応状況の報告 ユーザコミュニケーション 決定した方針にしたがって各自が役割を着実にこなす
27. 27 © M3, Inc. 2026 #srenext_a 障害対応フロー 〜サービス復旧〜 エンジニア 主催者 プロダクトマネージャー 視聴者 カスタマーサポート 営業 サービスオペレーター 全体の対応リード 復旧作業 対応状況の報告 ユーザコミュニケーション 決定した方針にしたがって各自が役割を着実にこなす 集中して取り組むことで 作業効率最大化
28. 28 © M3, Inc. 2026 #srenext_a 障害対応フロー 〜サービス復旧〜 エンジニア 主催者 プロダクトマネージャー 視聴者 カスタマーサポート 営業 サービスオペレーター 全体の対応リード 復旧作業 対応状況の報告 ユーザコミュニケーション 決定した方針にしたがって各自が役割を着実にこなす それぞれの専門メンバーによる対応 スピードUPとミス低減による2次被害の抑制
29. 29 © M3, Inc. 2026 #srenext_a 障害対応フロー 〜クロージング〜 関係者間でコンテキストがしっかりと共有されているので効果的に進めることができる • ポストモーテム、報告書の作成 ◦ ポストモーテムを用いた全体の対応振り返り ◦ ユーザ、クライアント、社内に向けた復旧の連絡と報告書の作成 ◦ 各メンバーが初動から対応に入って状況を理解できているため、正確かつ素早く作成できる • 再発防止 ◦ ビジネスサイドのメンバーも含めて、影響度も勘案した再発防止策を作る ◦ プロダクトマネージャーも状況を理解していることで開発タスクとの優先度も考慮して再発防止策を推進できる
30. 30 © M3, Inc. 2026 #srenext_a 実際に運用した結果 組織横断体制を発足してから3年ほど運用して着実に成果を残せている • 即効性のある取り組み ◦ アラートを検知したら即招集のルール ◦ 責任者を組み込んだ体制 ◦ 復旧作業時の役割分担と体制 • 中長期的な運用で効果がでてくる取り組み ◦ 効果的な再発防止策の策定 ◦ 障害対応フローの改善 昨年度 重大な障害ゼロを達成!!!!!
31. 31 © M3, Inc. 2026 #srenext_a 実際に運用した結果 その他の気付き • オオカミ少年アラートが減った ◦ エンジニアのみだと問題ないアラートを脳内で判断して放置してしまうケースも ◦ アラート発生時にすぐに招集するルールによってアラート精度向上のインセンティブが生まれた • ユーザへの通知を止めることの重要性 ◦ 障害対応ではユーザへの状況報告のアナウンスに目が行きがち ◦ 正常なユーザ体験を提供できていない間は通知やメルマガを止めることも重要
32. 32 © M3, Inc. 2026 #srenext_a まとめ
33. 33 © M3, Inc. 2026 #srenext_a まとめ • サービスの特性を理解して守りたい部分を明確化することが重要 • サービスに関わる各役割のメンバーが協力することで迅速で効果的な障害対応が実現できる • 継続と改善は強い