SRE NEXT 2026 - Speaker Deck

SRE NEXT 2026

by Akira Goto

Embed

Start on current slide

Slide 1

Slide 1 text

1 © M3, Inc. 2026 #srenext_a © M3, Inc. 2026 エムスリー株式会社後藤祥 (Akira Goto) Engも、Bizも、CSも。組織横断タスクフォースで実現したライブ配信サービスの信頼性向上

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

3 © M3, Inc. 2026 #srenext_a Index ● ライブ配信サービスの説明 ● エンジニアリング観点での信頼性向上の取り組み ● 組織横断TFでの安定運用への取り組み ● まとめ

Slide 4

Slide 4 text

4 © M3, Inc. 2026 #srenext_a ライブ配信サービスの説明

Slide 5

Slide 5 text

5 © M3, Inc. 2026 #srenext_a テクノロジーを創造的に活用し、健康で楽しく長生きする人を 1人でも増やし、不必要な医療コストを1円でも減らすこと (※) 2025年3月時点日本の医師のエムスリー会員率エムスリーが事業展開している国の数全世界の医師におけるエムスリー会員の割合全世界で医師会員合計 18 カ国 (※) 50 %以上 (※) 650 万人以上 (※) 90 %以上エムスリーが展開する医療従事者向け情報サイト「m3.com」は33万人を突破、日本の医師の9割以上が会員。(※)

Slide 6

Slide 6 text

6 © M3, Inc. 2026 #srenext_a 私たちはプラットフォームとプロダクトの力を用いて様々な医療課題の解決に取り組んでいます。主に医療従事者に対してアプローチしながらも、同時にその先の一般の方々に対してもサービス提供を行い、総合的に人々の健康的な毎日を少しでも改善することを目指し様々なプロダクトの開発を行っております。多くの医療者をユーザーに抱えるエムスリーだからこそできるやり方で、多くの人々の健康に対して貢献しています。 Platform × Product 健康で幸せな毎日をもっとよくするために

Slide 7

Slide 7 text

7 © M3, Inc. 2026 #srenext_a 日本の医師の90%以上が登録する国内最大級の医療従事者向けポータルサイト、m3.comを運営

Slide 8

Slide 8 text

8 © M3, Inc. 2026 #srenext_a ライブ配信サービス ● m3.comプラットフォーム上で医療従事者に向けた様々な動画コンテンツを届けるサービス主催者視聴者 m3.com

Slide 9

Slide 9 text

9 © M3, Inc. 2026 #srenext_a エンジニアリング観点での信頼性向上の取り組み

Slide 10

Slide 10 text

10 © M3, Inc. 2026 #srenext_a SRE目線でみるライブ配信サービス ● 配信の規模は大小様々 ● 配信時間帯にアクセスが集中 ● 開始時刻のアクセスのスパイク ● 事前予約があるため大まかなアクセス数の予測ができる ● 配信以外にもいくつか付随する周辺機能がある ● ライブ中は絶対に落とせないあなたならどういう設計にしますか?

Slide 11

Slide 11 text

11 © M3, Inc. 2026 #srenext_a アーキテクチャ概要フロントエンドバックエンド DB、キャッシュスケーリングバッチ遅延処理外部API呼び出し (イベント駆動) モニタリング

Slide 12

Slide 12 text

12 © M3, Inc. 2026 #srenext_a 守りたいポイントを明確化しよう!!

Slide 13

Slide 13 text

13 © M3, Inc. 2026 #srenext_a 守りたいポイントの明確化サービスにおいて最も大事なのは「ライブ配信時間中にユーザが正常に配信を視聴できること」 1 2 3 独自ロジックでの負荷予測とスケーリング重要処理を守るための処理の非同期化万が一のケースに備える機能縮退 4 ユーザ体験を全体を監視するブラウザテスト

Slide 14

Slide 14 text

14 © M3, Inc. 2026 #srenext_a 1. 独自ロジックでの負荷予測とスケーリング独自ロジックとオートスケールのハイブリット ● 独自ロジック ○ 配信開始前にスケールさせてスパイクに対応 ○ 負荷予測に応じて柔軟にスケールアウト ● オートスケール ○ CPU使用率ベースのシンプルなもの ○ 保険的な立ち位置 Writer/Read replicaのシンプルな構成 WriteとReadはアプリケーションレベルで分離 Read HeavyなのでスケールはRead replicaの追加

Slide 15

Slide 15 text

15 © M3, Inc. 2026 #srenext_a 2. 重要処理を守るための処理の非同期化処理の適切な非同期化はコアな機能を守ることにつながる非同期にすべき処理の洗い出しとその徹底が重要で、コードレビューのチェック項目にも含めている SQS+Lambdaで遅延処理連携サービスAPI イベント駆動による非同期化

Slide 16

Slide 16 text

16 © M3, Inc. 2026 #srenext_a 3. 万が一のケースに備える機能縮退高い負荷が予測される場合、視聴体験を守るために一部機能を縮退することができる管理画面からの機能On/Off 独自APIゲートウェイによる負荷コントロール簡易的な画面へのフォールバック

Slide 17

Slide 17 text

17 © M3, Inc. 2026 #srenext_a 4. ユーザ体験を全体を監視するブラウザテストサービス単体が稼働していても動線上で問題が発生しているとユーザ体験が守れているとはいえないクリティカルユーザジャーニーが担保されていることを監視する必要があるログイン全体トップ遷移視聴画面遷移 DataDogのブラウザテストで一連の画面遷移を定常的に確認

Slide 18

Slide 18 text

18 © M3, Inc. 2026 #srenext_a ここまでのまとめ ● “サービスの信頼性を高める”という抽象的な目標のままでは場当たり的な対応になってしまいがち ● コンセプトをしっかりともつことが重要 ● 「ライブ配信時間中にユーザが正常に配信を視聴できること」を何よりも重視して守るようにしている

Slide 19

Slide 19 text

19 © M3, Inc. 2026 #srenext_a 組織横断TFでの安定運用への取り組み

Slide 20

Slide 20 text

20 © M3, Inc. 2026 #srenext_a MTBF/MTTR (とMTTD) ここまではサービスを落とさないための工夫 MTBF: 平均故障間隔それでも障害を0件にはできないので、最速で復旧するための取り組みも必要 MTTD + MTTR: 平均検出時間 + 平均修復時間 MTBF MTTD + MTTR ここまでの話ここからの話

Slide 21

Slide 21 text

21 © M3, Inc. 2026 #srenext_a なぜ組織横断での連携が必要かサービスの早期復旧はエンジニアだけが頑張れば実現できるのか?

Slide 22

Slide 22 text

22 © M3, Inc. 2026 #srenext_a なぜ組織横断での連携が必要かサービスの早期復旧はエンジニアだけが頑張れば実現できるのか? => No エンジニア主催者プロダクトマネージャー視聴者カスタマーサポート営業サービスオペレーター

Slide 23

Slide 23 text

23 © M3, Inc. 2026 #srenext_a 組織横断タスクフォース関係部署の担当者を集めてタスクフォースを結成 ● 安定運用に関わる課題の抽出、対応の推進 ● 障害対応マニュアルの整備、ロープレ訓練 ● 障害発生時のサービス復旧含む全体対応アドホックに対応するよりも体制をしっかり作っておくメリットは大きい ● 部署横断で認識を合わせおくことでスピーディーな対応を実現できる ● 改善サイクルを回すことができる

Slide 24

Slide 24 text

24 © M3, Inc. 2026 #srenext_a 障害対応フローの全体像 1 2 3 障害検知と対応方針策定サービス復旧クロージング問題発生から復旧作業開始までの時間を如何にして短縮するか (MTTD) 役割分担にしたがって各自が役割を果たす (MTTR) 状況の正確振り返りと再発防止策の推進

Slide 25

Slide 25 text

25 © M3, Inc. 2026 #srenext_a 障害対応フロー〜障害検知と対応方針策定〜問題発生から復旧作業開始までの時間を如何にして短縮するか ① 問題発生 ② アラート発報 ③ アラートを検知 ④ 体制の立ち上げ ⑤ 初動調査 ⑥ 対応方針の策定アラートを検知したら即時にオンライン会議を立ち上げて対応メンバーを招集するルール各部署で決定権のある責任者をメンバーとして招集する実効性のある対策をその場で決定する

Slide 26

Slide 26 text

26 © M3, Inc. 2026 #srenext_a 障害対応フロー〜サービス復旧〜エンジニア主催者プロダクトマネージャー視聴者カスタマーサポート営業サービスオペレーター全体の対応リード復旧作業対応状況の報告ユーザコミュニケーション決定した方針にしたがって各自が役割を着実にこなす

Slide 27

Slide 27 text

27 © M3, Inc. 2026 #srenext_a 障害対応フロー〜サービス復旧〜エンジニア主催者プロダクトマネージャー視聴者カスタマーサポート営業サービスオペレーター全体の対応リード復旧作業対応状況の報告ユーザコミュニケーション決定した方針にしたがって各自が役割を着実にこなす集中して取り組むことで作業効率最大化

Slide 28

Slide 28 text

28 © M3, Inc. 2026 #srenext_a 障害対応フロー〜サービス復旧〜エンジニア主催者プロダクトマネージャー視聴者カスタマーサポート営業サービスオペレーター全体の対応リード復旧作業対応状況の報告ユーザコミュニケーション決定した方針にしたがって各自が役割を着実にこなすそれぞれの専門メンバーによる対応スピードUPとミス低減による2次被害の抑制

Slide 29

Slide 29 text

29 © M3, Inc. 2026 #srenext_a 障害対応フロー〜クロージング〜関係者間でコンテキストがしっかりと共有されているので効果的に進めることができる ● ポストモーテム、報告書の作成 ○ ポストモーテムを用いた全体の対応振り返り ○ ユーザ、クライアント、社内に向けた復旧の連絡と報告書の作成 ○ 各メンバーが初動から対応に入って状況を理解できているため、正確かつ素早く作成できる ● 再発防止 ○ ビジネスサイドのメンバーも含めて、影響度も勘案した再発防止策を作る ○ プロダクトマネージャーも状況を理解していることで開発タスクとの優先度も考慮して再発防止策を推進できる

Slide 30

Slide 30 text

30 © M3, Inc. 2026 #srenext_a 実際に運用した結果組織横断体制を発足してから3年ほど運用して着実に成果を残せている ● 即効性のある取り組み ○ アラートを検知したら即招集のルール ○ 責任者を組み込んだ体制 ○ 復旧作業時の役割分担と体制 ● 中長期的な運用で効果がでてくる取り組み ○ 効果的な再発防止策の策定 ○ 障害対応フローの改善昨年度重大な障害ゼロを達成!!!!!

Slide 31

Slide 31 text

31 © M3, Inc. 2026 #srenext_a 実際に運用した結果その他の気付き ● オオカミ少年アラートが減った ○ エンジニアのみだと問題ないアラートを脳内で判断して放置してしまうケースも ○ アラート発生時にすぐに招集するルールによってアラート精度向上のインセンティブが生まれた ● ユーザへの通知を止めることの重要性 ○ 障害対応ではユーザへの状況報告のアナウンスに目が行きがち ○ 正常なユーザ体験を提供できていない間は通知やメルマガを止めることも重要