ABEMA SREの挑戦〜Frontend & Backend TeamへのEmbedded SRE導入〜

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Slide 3

Slide 3 text

1. 背景 ~ Embedded SRE 体制にいたるまで ~ 

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

AbemaTV, Inc. All Rights Reserved  2020年までの体制  9 Frontend Backend Platform Project B Project C Team A Team B Team C Team D SRE Project A ● 横断組織としてインフラを軸とした SREチーム ● 各チーム横軸で複数の開発が平行で動いている Cloud Platform

Slide 10

Slide 10 text

AbemaTV, Inc. All Rights Reserved  2020年までの活動  10 ● On-Call環境の改善   ● SLI/SLO基盤の開発   ● Production Readiness Checklist の作成  1. プラクティスの導入  ● GCP Networkの移設   ● 冗長Loadbalancerの構築   3. 基盤システムの改善  ● インフラキャパシティの確保   ● 各インフラのメンテナンス   ● システムコストの管理・改善   2. 基盤システムの運用 

Slide 11

Slide 11 text

Slide 12

Slide 12 text

AbemaTV, Inc. All Rights Reserved  2021年からの体制  12 Frontend Backend Platform Project B Project C Team A Team B Team C Team D Project A Frontend SRE Backend SRE SRE Cloud Platform ● 既存SRE一部メンバーをCloudPlatformとEmbeddedSREに役割変更 ● Frontendチームの一部メンバーがSREの役割も担う

Slide 13

Slide 13 text

AbemaTV, Inc. All Rights Reserved  2021年からの体制  13 体制変更の狙い  1. 注力するポイントの最適化   2. 担当チームと密にコミュニケーションを計り、各プラクティス導入の速度と質を上げる   3. チーム個別の課題やリスクを把握し、全体効率のよい施策の実施する   4. 改善プラクティスを他チーム (SRE) に伝播し、組織全体で信頼性の底上げを行う  

Slide 14

Slide 14 text

2. Backend Team's Embedded SRE 

Slide 15

Slide 15 text

AbemaTV, Inc. All Rights Reserved  Backend Team's Embedded SRE  15 ● (継続) : SLI / SLO の設定  ● (継続) : インシデントプロセスの改善  ● (継続) : Service Doc (design doc + α)  ● (継続) : Production Readiness Checklistの刷新  ● (新規) : 連携サービスのキャパシティ情報管理の半自動化  ● (新規) : 継続的負荷試験の導入  取り組み 

Slide 16

Slide 16 text

AbemaTV, Inc. All Rights Reserved  Backend Team's Embedded SRE  16 ● (継続) : SLI / SLO の設定  ● (継続) : インシデントプロセスの改善  ● (継続) : Service Doc (design doc + α)  ● (継続) : Production Readiness Checklistの刷新  ● (新規) : 連携サービスのキャパシティ情報管理の半自動化  ● (新規) : 継続的負荷試験の導入  取り組み  時間の関係で割愛 🙏  

Slide 17

Slide 17 text

Slide 18

Slide 18 text

AbemaTV, Inc. All Rights Reserved  SLI / SLO の設定  18 なぜ ABEMA にとって SLI / SLO が必要だと考えているのか  “ Reliability Is the   Most Important Feature ‘’  Ben Treynor, Google's VP   ● サービス特性である同時性の担保  ● 機能・システム・組織規模の拡大  ● 様々な改善やプラクティスへの活用性  ● 組織との共通言語化 

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

AbemaTV, Inc. All Rights Reserved  SLI / SLO の設定  28 映像配信システムにおける指標の策定  難しいポイント① : 指標の粒度を決めるのが難しい  ● 配信規格ごとに扱うリソースは様々 ● 配信形態ごとにやりとりする頻度や内容が異なる配信規格配信形態リニア VOD Payperview 低遅延配信追っかけ Playlist  TS  TS  TS  MPD  MP4  MP4  MP4  CM HLS mpeg- DASH

Slide 29

Slide 29 text

AbemaTV, Inc. All Rights Reserved  SLI / SLO の設定  29 映像配信システムにおける指標の策定  難しいポイント② : 単純なHTTPの成功・失敗のみでは信頼性を表現出来ない  ● 視聴プレイヤーのバッファリングにより映像ファイル取得の失敗 =映像の停止とならないケースがある ● ABRの仕組みにより映像ファイルの取得遅延 =映像の停止とならないケースがある出典: cloudinary. Product Updates 出典: Qiita HLSやMPEG-DASHの時間的な変化をグラフで理解する

Slide 30

Slide 30 text

AbemaTV, Inc. All Rights Reserved  SLI / SLO の設定  30 映像配信システムにおける指標の策定  難しいポイント③ : レスポンスの中身の検査が必要  ● e.g , 取得したmanifestが前回取得時の内容と整合性が取れているか ● e.g , 計画された配信スケジュール通りになっているか (番組やフィラーなど) manifest 番組表フィラー ↑正常 ↓異常

Slide 31

Slide 31 text

Slide 32

Slide 32 text

AbemaTV, Inc. All Rights Reserved  SLI / SLO の設定  32 映像配信システムにおける指標の策定  計画中のアプローチ  配信形態リニア VOD News PPV ... 配信規格 HLS DASH リソース種別 Manifest Segment 検査種別 Availability Latency Correctness ... x x x 各指標の組み合わせに対し、  計測方法(RUM/STM)と観測点(CDN/Origin)を選択して測定 

Slide 33

Slide 33 text

AbemaTV, Inc. All Rights Reserved  SLI / SLO の設定  33 映像配信システムにおける指標の策定  計画中のアプローチ  配信形態リニア VOD News PPV ... 配信規格 HLS DASH リソース種別 Manifest Segment 検査種別 Availability Latency Correctness ... x x x 各指標の組み合わせに対し、  計測方法(RUM/STM)と観測点(CDN/Origin)を選択して測定 

Slide 34

Slide 34 text

Slide 35

Slide 35 text

AbemaTV, Inc. All Rights Reserved  今後の挑戦していきたいこと  35 ● SLI / SLO  ○ 活用のユースケースを増やす   ■ e.g , 監視,リリース管理,パフォーマンステスト   ○ 設定の簡略化  ○ 開発フローへの組み込み   ● 潜在的リスクの発掘・改善  ○ 継続的負荷試験  ○ カオスエンジニアリング   ● 自律的防御システムの開発  ○ キャパシティに応じたトラフィック制御  

Slide 36

Slide 36 text

3. Frontend Team's Embedded SRE 

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

AbemaTV, Inc. All Rights Reserved  アラートの自動化と運用  50 SLOを設定すると自動でダッシュボードと   アラートに反映される仕組みを構築     ・バーンレートに基づくアラート設定   ・エラーバジェットの算出  ・AvailabilityとLatencyそれぞれに設定   Terraform による自動化  出典: https://sre.google/workbook/alerting-on-slos/

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

AbemaTV, Inc. All Rights Reserved  Frontend SRE の難しさ  54 スケール  モバイルアプリにおけるの課題  モニタリング  制御  変更管理  膨大なデバイスモデルと外部要因を考慮しながら   複数バージョンをサポートする等の制約が多い   モニタリングコストとして端末リソースや影響が   避けられない (全てを観測することは不可能)   ユーザーが更新しなければならず   バイナリの更新を強制できない   ロールバックができず   バージョンが長く残り続けてしまう   出典: https://sre.google/resources/practices-and-processes/engineering-reliable-mobile-applications/

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

4. 全体まとめ 

Slide 58

Slide 58 text

AbemaTV, Inc. All Rights Reserved  Embedded SRE 体制を振り返って  58 良かった点    ● Frontend、Backend間で協力関係が強化された  ● 各チームのナレッジがより共有されるようになった  ● チーム毎に異なっていた障害対応フローを統一できた  苦労した点    ● チームへのインストールコストが高い  ● 費用対効果を実感できるまでが長い  ● オーバーエンジニアリングの境界を見極めるのが難しい   