FIFA ワールドカップ 2022に向けたキャパシティ確保の軌跡 / Trajectory of securing system capacity for FIFA World Cup 2022

これまで経験したことがない規模の配信を迎えるにあたり、我々SREチームが行った、キャパシティプランニング・リソース調達・負荷試験等のキャパシティ確保に向けた活動から本番での監視体制や実際にどういった負荷傾向があったのか等、可能な限りお話したいと思います。大規模なイベントに向けた対策の参考になればと思いますので、運用担当者の方ぜひお聞きください。

https://developer.abema.io/2023/sessions/axlOoyAFHa/?utm_medium=social&utm_source=speakerdeck

Transcript

1. View Slide

2. 今日お話すること
   「FIFA ワールドカップ カタール 2022」配信に向け、
   キャパシティの確保を中心とした
   SREチームの活動についてお話します
   ※ 以降は 「FIFA ワールドカップ カタール 2022」 を 「 ワールドカップ」 とする
   

   View Slide

3. 自己紹介
   岩永 勇祐
   2017年株式会社サイバーエージェント入社
   2018年株式会社AbemaTVのSREチームに移動
   Twitter @nagaa052
   ABEMA SRE
   

   View Slide

4. 遡ること2022年4月...
   対策プロジェクト発足
   

   View Slide

5. 過去最大規模の
   同接目標が発表された
   

   View Slide

6. プロジェクト概要
   

   View Slide

7. プロジェクトについて
   負荷対策PJ
   視聴体験PJ
   残存PJ
   運用PJ
   10/31
   コードフリーズ
   11/20
   配信開始
   

   View Slide

8. プロジェクトについて
   負荷対策PJ
   視聴体験PJ
   残存PJ
   運用PJ
   10/31
   コードフリーズ
   11/20
   配信開始
   プロジェクトの責務「ワールドカップの安定配信 」
   ミッション
   ・全64試合のライブ配信の視聴をインフラの不備なく提供する
   ・発生した問題に迅速に対応し、最速で復旧する
   ・発生する可能性を早期に推察し、最大限の予防対応を実行する
   活動
   キャパシティ確保、障害の局所化、クラウド基盤・ Web基盤改善
   攻撃対策、シーケンス改善、負荷試験 等
   

   View Slide

9. プロジェクトについて
   負荷対策PJ
   視聴体験PJ
   残存PJ
   運用PJ
   10/31
   コードフリーズ
   11/20
   配信開始
   プロジェクトの責務「ワールドカップの安定配信」
   ミッション
   ・全64試合のライブ配信の視聴をインフラの不備なく提供する
   ・発生した問題に迅速に対応し、最速で復旧する
   ・発生する可能性を早期に推察し、最大限の予防対応を実行する
   活動
   キャパシティ確保、障害の局所化、クラウド基盤・ Web基盤改善
   攻撃対策、シーケンス改善、負荷試験 等
   SRE Team Missions
   視聴開始までに至るシステムリソースの確保を行うこと
   視聴開始までに至る負荷試験・障害試験を実施すること
   配信期間中における監視体制を確立すること
   

   View Slide

10. システムリソースの確保
    

    View Slide

11. リソース確保の対象範囲について
    Google Cloud
    CDN & LB
    Akamai
    Microservices
    (e.g,GKE, BigTable,
    Pub/Sub,GCS,etc.)
    社内関連サービス
    (e.g, 決済,レコメンド,FeatureFlag,
    投稿チェック ,etc.)
    AWS
    Media Services
    Amazon
    CloudFront
    User
    国内中継地点
    

    View Slide

12. リソース確保の対象範囲について
    Google Cloud
    CDN & LB
    Akamai
    Microservices
    (e.g,GKE, BigTable,
    Pub/Sub,GCS,etc.)
    社内関連サービス
    (e.g, 決済,レコメンド,FeatureFlag,
    投稿チェック ,etc.)
    AWS
    Media Services
    Amazon
    CloudFront
    User
    国内中継地点
    視聴
    アクセス~視聴開始
    

    View Slide

13. リソース確保の対象範囲について
    Google Cloud
    CDN & LB
    Akamai
    Microservices
    (e.g,GKE, BigTable,
    Pub/Sub,GCS,etc.)
    社内関連サービス
    (e.g, 決済,レコメンド,FeatureFlag,
    投稿チェック ,etc.)
    AWS
    Media Services
    Amazon
    CloudFront
    User
    国内中継地点
    視聴
    アクセス~視聴開始
    CTO & 配信チーム
    

    View Slide

14. リソース確保の対象範囲について
    Google Cloud
    CDN & LB
    Akamai
    Microservices
    (e.g,GKE, BigTable,
    Pub/Sub,GCS,etc.)
    社内関連サービス
    (e.g, 決済,レコメンド,FeatureFlag,
    投稿チェック ,etc.)
    AWS
    Media Services
    Amazon
    CloudFront
    User
    国内中継地点
    視聴
    アクセス~視聴開始
    SRE & プロダクトチーム
    CTO & 配信チーム
    

    View Slide

15. 実施する上でのポイント
    

    View Slide

16. 実施する上でのポイント
    1. リソース調整依頼は早めに行う必要がある
    ● クラウド、関連サービス共に内部のリソース調整が必要になるケースがあるため
    

    View Slide

17. 実施する上でのポイント
    1. リソース調整依頼は早めに行う必要がある
    2. 同時並行で進行しているプロジェクトが複数ある
    ● ワールドカップ向け機能開発・機能改善
    ● クラウドのリージョン移設 (台湾 -> 東京)
    ● DBの分割、および移設など
    ● クラウド、関連サービス共に内部のリソース調整が必要になるケースがあるため
    

    View Slide

18. 実施する上でのポイント
    1. リソース調整依頼は早めに行う必要がある
    2. 同時並行で進行しているプロジェクトが複数ある
    3. 配信特性や運用施策を考慮して見積もること
    ● ワールドカップ向け機能開発・機能改善
    ● クラウドのリージョン移設 (台湾 -> 東京)
    ● DBの分割、および移設など
    ● 番組特性
    ● 配信形態
    ● 訴求方法など
    ● クラウド、関連サービス共に内部のリソース調整が必要になるケースがあるため
    

    View Slide

19. 実施する上でのポイント
    1. リソース調整依頼は早めに行う必要がある
    2. 同時並行で進行しているプロジェクトが複数ある
    3. 配信特性や運用施策を考慮して見積もること
    ● W杯向け機能開発・レコメンドシステムの内製化
    ● クラウドのリージョンの移設 (台湾 -> 東京)
    ● DBの分割、および移設など
    ● 番組特性
    ● 配信形態
    ● 訴求方法など
    ● クラウド、外部サービス共に内部のリソース調達が必要になるケースがあるため
    ~ 方針 ~
    「精度は低くても、大枠の規模感を正しく見積もる」
    (後続の工程で精度を上げていく)
    

    View Slide

20. リソース確保の対象範囲について
    Google Cloud
    CDN & LB
    Akamai
    Microservices
    (e.g,GKE, BigTable,
    Pub/Sub,GCS,etc.)
    社内関連サービス
    (e.g, 決済,レコメンド,FeatureFlag,
    投稿チェック ,etc.)
    AWS
    Media Services
    Amazon
    CloudFront
    User
    国内中継地点
    視聴
    アクセス~視聴開始
    SRE & プロダクトチーム
    CTO & 配信チーム
    

    View Slide

21. Google Cloudリソースの確保
    1. 対象コンポーネントの洗い出し
    L7LB
    (asia-northeast1)
    GKE Node
    (asia-northeast1)
    BigTable
    (asia-northeast1)
    Pub/Sub
    (project A)
    Memory
    store
    (asia-northeast1)
    ・
    ・
    ・
    Components
    

    View Slide

22. Google Cloudリソースの確保
    1. 対象コンポーネントの洗い出し
    2. 各コンポーネントの見積もり要素確認
    L7LB
    (asia-northeast1)
    QPS
    IngressGbps
    Egress Gbps
    GKE Node
    (asia-northeast1)
    Core
    RAM
    Storage
    BigTable
    (asia-northeast1)
    Nodes
    Storage
    IngressGbps
    Egress Gbps
    Publisher Throughput
    Subscriber Throughput
    Pub/Sub
    (project A)
    Instances
    Memory
    Memory
    store
    (asia-northeast1)
    ・
    ・
    ・
    Metrics
    Components
    ・
    ・
    ・
    

    View Slide

23. Google Cloudリソースの確保
    1. 対象コンポーネントの洗い出し
    2. 各コンポーネントの見積もり要素確認
    3. 参考とする過去配信の決定と各利用量の確認
    L7LB
    (asia-northeast1)
    QPS
    IngressGbps
    Egress Gbps
    GKE Node
    (asia-northeast1)
    Core
    RAM
    Storage
    BigTable
    (asia-northeast1)
    Nodes
    Storage
    IngressGbps
    Egress Gbps
    Publisher Throughput
    Subscriber Throughput
    Pub/Sub
    (project A)
    Instances
    Memory
    Memory
    store
    (asia-northeast1)
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    ・
    ・
    ・
    Metrics Source
    Components
    ・
    ・
    ・
    ・
    ・
    ・
    

    View Slide

24. Google Cloudリソースの確保
    1. 対象コンポーネントの洗い出し
    2. 各コンポーネントの見積もり要素確認
    3. 参考とする過去配信の決定と各利用量の確認
    4. 同時接続数を係数とした試算
    5. 並行プロジェクトによる変更の影響確認
    L7LB
    (asia-northeast1)
    QPS
    IngressGbps
    Egress Gbps
    GKE Node
    (asia-northeast1)
    Core
    RAM
    Storage
    BigTable
    (asia-northeast1)
    Nodes
    Storage
    IngressGbps
    Egress Gbps
    Publisher Throughput
    Subscriber Throughput
    Pub/Sub
    (project A)
    Instances
    Memory
    Memory
    store
    (asia-northeast1)
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    ・
    ・
    ・
    Metrics Source Target
    Components
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    

    View Slide

25. Google Cloudリソースの確保
    1. 対象コンポーネントの洗い出し
    2. 各コンポーネントの見積もり要素確認
    3. 参考とする過去配信の決定と各利用量の確認
    4. 同時接続数を係数とした試算
    5. 並行プロジェクトによる変更の影響確認
    6. Google Cloud側にリソース調整の依頼
    L7LB
    (asia-northeast1)
    QPS
    IngressGbps
    Egress Gbps
    GKE Node
    (asia-northeast1)
    Core
    RAM
    Storage
    BigTable
    (asia-northeast1)
    Nodes
    Storage
    IngressGbps
    Egress Gbps
    Publisher Throughput
    Subscriber Throughput
    Pub/Sub
    (project A)
    Instances
    Memory
    Memory
    store
    (asia-northeast1)
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    xx
    ・
    ・
    ・
    Metrics Source Target
    Components
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    

    View Slide

26. リソース確保の対象範囲について
    Google Cloud
    CDN & LB
    Akamai
    Microservices
    (e.g,GKE, BigTable,
    Pub/Sub,GCS,etc.)
    社内関連サービス
    (e.g, 決済,レコメンド,FeatureFlag,
    投稿チェック ,etc.)
    AWS
    Media Services
    Amazon
    CloudFront
    User
    国内中継地点
    視聴
    アクセス~視聴開始
    SRE & プロダクトチーム
    CTO & 配信チーム
    

    View Slide

27. 関連外部サービスのリソース調整
    1. 社内関連サービスと連携体制の構築
    ABEMA 関連サービス
    

    View Slide

28. 関連外部サービスのリソース調整
    1. 社内関連サービスと連携体制の構築
    2. サービスごとに見積もり元となる
    情報の整理
    ABEMA 関連サービス
    Date Metrics
    Service
    ServiceA 01/01
    Target
    x10
    ServiceB 02/01 x5
    ServiceC RPS xxx
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    

    View Slide

29. 関連外部サービスのリソース調整
    1. 社内関連サービスと連携体制の構築
    2. サービスごとに見積もり元となる
    情報の整理
    3. 各サービスにリソース確認、および
    調達の依頼
    ABEMA 関連サービス
    Date Metrics
    Service
    ServiceA 01/01
    Target
    x10
    ServiceB 02/01 x5
    ServiceC RPS xxx
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ・
    ※ 色による違いは実態とは異なります。
    

    View Slide

30. システムリソースの確保
    SRE Team Missions
    視聴開始までに至るシステムリソースの確保を行うこと
    視聴開始までに至る負荷試験・障害試験を実施すること
    配信期間中における監視体制の確立すること
    リソース確保の調整完了
    (配信まで残り：4.5ヶ月)
    

    View Slide

31. 負荷試験・障害試験
    

    View Slide

32. 実施条件
    1. 10月31日まで (残り4ヶ月) にはすべての工程を終えること
    2. 極力実際の配信と同等の状態を再現した試験を行うこと
    3. 可能な限り考えられるワーストケースの試験を含めること
    

    View Slide

33. 負荷試験・障害試験
    試験範囲 シナリオ
    環境
    試験実施
    試験準備
    

    View Slide

34. 負荷試験・障害試験
    試験範囲 シナリオ
    環境
    試験実施
    試験準備
    

    View Slide

35. ※ イメージ図
    Microservices DB Services
    試験準備 ~試験範囲と実施方法~
    Edge POP
    MicroserviceA
    DB A
    DB B
    MicroserviceC
    Cloud Amor
    Loadbalancer
    Cloud CDN
    Gateway A
    Gateway B
    Gateway C
    MicroserviceB
    

    View Slide

36. ※ イメージ図
    Microservices DB Services
    試験準備 ~試験範囲と実施方法~
    Edge POP
    MicroserviceA
    DB A
    DB B
    MicroserviceC
    Cloud Amor
    Loadbalancer
    Cloud CDN
    Gateway A
    Gateway B
    Gateway C
    MicroserviceB
    特定領域での試験の組み合わせによる
    正しく測定出来ないポイントが許容できない
    

    View Slide

37. ※ イメージ図
    Microservices DB Services
    試験準備 ~試験範囲と実施方法~
    Edge POP
    MicroserviceA
    DB A
    DB B
    MicroserviceC
    Cloud Amor
    Loadbalancer
    Cloud CDN
    Gateway A
    Gateway B
    Gateway C
    MicroserviceB
    考えられる本番でのリクエストを 統
    合的に負荷実施
    特定領域での試験の組み合わせによる
    正しく測定出来ないポイントが許容できない
    

    View Slide

38. 負荷試験・障害試験
    試験範囲
    の
    確定
    シナリオ
    環境
    試験準備
    試験実施
    

    View Slide

39. 試験準備 ~環境~
    ● 既存負荷試験ツールが目標とする 負荷を生成出来ない
    ● 既存負荷試験ツールでは 大量のコアを用意する必要がある
    ● 試験環境はリージョン移設前の環境なのでネットワーク 経路が違う
    ● 大規模なE2Eでの負荷試験環境は 最新の状態ではない
    現状
    ① 負荷試験ツールは新しいソリューションを検証・導入
    ② 試験環境はゼロベースで構築(送信側・受信側)
    

    View Slide

40. Project Load
    試験準備 ~環境~
    Cluster A (asia-notheast1) Cluster B (asia-notheast1)
    1. 東京リージョンに送信側・受信側2つのクラスタを準備
    

    View Slide

41. Project Load
    試験準備 ~環境~
    Cluster A (asia-notheast1) Cluster B (asia-notheast1)
    Global LB
    DBs
    Microservices
    Kind:
    Job
    Kind:
    k6
    Operator
    1. 東京リージョンに送信側・受信側2つのクラスタを準備
    2. 送信側をSRE、受信側を開発者で環境構築
    Cluster B (asia-notheast1)
    

    View Slide

42. Project Load
    試験準備 ~環境~
    Cluster A (asia-notheast1) Cluster B (asia-notheast1)
    Global LB
    Cluster C (asia-east1)
    DBs
    Microservices
    Prometheus
    Prometheus
    Kind:
    Job
    PipCD
    Victoria
    Metrics
    Internal LB
    Grafana
    Kind:
    k6
    Operator
    1. 東京リージョンに送信側・受信側2つのクラスタを準備
    2. 送信側をSRE、受信側を開発者で環境構築
    3. CI、モニタリング、Quotaの緩和等もクラプラと協力し準備
    Cluster B (asia-notheast1)
    

    View Slide

43. 負荷試験・障害試験
    試験範囲 シナリオ
    環境
    実施準備
    試験実施
    

    View Slide

44. 試験準備 ~シナリオ~
    ● 番組内容や配信形態 によって同じ同接数でもワークロードが異なる
    ● 配信期間中も通常の配信は行われている
    ● 期間中に通常利用者の増加も考えれらる
    ポイント
    後に細かな調整を可能にするため、以下 パターンの組み合わせ を構築
    1. 通常のサイト利用シナリオ
    2. ワールドカップ1試合を想定したシナリオ
    3. ワーストケースシナリオ
    ○ ゴールによるコメントのバースト
    ○ 外部訴求(Push通知など)による一斉流入
    ○ ユーザー種別の違いなど
    

    View Slide

45. 試験準備 ~シナリオ~
    通常利用シナリオ
    ・APIごとの重要度・コール数 などから対象パスの決定
    ・直近の大型配信 から各APIの高さを決定
    ※ イメージ図
    通常利用 (既存)
    通常利用 (残存)
    

    View Slide

46. ※ イメージ図
    試験準備 ~シナリオ~
    通常利用 (既存)
    通常利用 (残存)
    流入
    平時 番組開始
    前半戦
    開始周辺
    前半戦 ハーフタイム
    後半戦
    開始周辺
    後半戦 試合終了後 平時
    流入
    視聴
    流入
    視聴
    視聴
    流入
    回遊
    視聴
    流入
    視聴
    流入
    視聴
    流入
    回遊
    タイムシフ
    ト視聴
    視聴
    通常利用シナリオ
    ・APIごとの重要度・コール数 などから対象パスの決定
    ・直近の大型配信 から各APIの高さを決定
    ワールドカップシナリオ
    ・ワールドカップで想定される視聴動線を確認
    ・過去の配信から想定出来る時間経過ごとのユーザー分布
    を調査
    ・1試合を想定したタイムラインを定義し、マッピング
    ※ イメージ図
    通常利用 (既存)
    通常利用 (残存)
    平時
    番組
    開始
    前半戦
    ハーフ
    タイム
    後半戦
    試合
    終了
    平時
    流入
    流入
    視聴
    流入
    視聴
    視聴
    流入
    回遊
    視聴
    流入
    視聴
    流入
    視聴
    流入
    回遊
    タイムシフ
    ト視聴
    視聴
    

    View Slide

47. 試験準備 ~シナリオ~
    通常利用シナリオ
    ・APIごとの重要度・コール数 などから対象パスの決定
    ・直近の大型配信 から各APIの高さを決定
    ワールドカップシナリオ
    ・ワールドカップで想定される視聴動線を確認
    ・過去の配信から想定出来る時間経過ごとのユーザー分布
    を調査
    ・1試合を想定したタイムラインを定義し、マッピング
    ワーストケースシナリオ
    ・施策担当者からの ヒアリングや過去配信の確認
    ・ネガティブチェック を繰り返す
    ※ イメージ図
    通常利用 (既存)
    通常利用 (残存)
    平時
    番組
    開始
    前半戦
    ハーフ
    タイム
    後半戦
    試合
    終了
    平時
    流入
    流入
    視聴
    流入
    視聴
    視聴
    流入
    回遊
    視聴
    流入
    視聴
    流入
    視聴
    流入
    回遊
    タイムシフ
    ト視聴
    視聴
    流入
    バースト
    コメント
    バースト
    

    View Slide

48. 負荷試験・障害試験
    試験範囲 シナリオ
    環境
    試験準備
    試験実施
    

    View Slide

49. 負荷試験・障害試験
    試験範囲 シナリオ
    環境
    試験実施
    試験準備
    

    View Slide

50. 試験実施
    ① 統合負荷試験
    ・目標同接まで段階的に繰り返し実施 & 負荷対策
    ・想定ワーストケースの組み合わせも合わせて実施
    ・トレーシングの導入やダッシュボードの整備なども並行して行った
    ② 合同負荷試験
    ・社内周辺サービス (広告・ログ等)とも結合し合同負荷試験を実施
    ・リージョン単位で共有するリソースや SPOFがないかの確認
    ③ 障害試験
    ・周辺サービス・クラウドの障害時の影響・復旧の確認
    ・影響範囲・発生確率・再現難易度などから試験対象を決定
    

    View Slide

51. 試験実施
    ① 統合負荷試験
    ・目標同接まで段階的に繰り返し実施 & 負荷対策
    ・想定ワーストケースの組み合わせも合わせて実施
    ・トレーシングの導入やダッシュボードの整備なども並行して行った
    ② 合同負荷試験
    ・社内周辺サービス (広告・ログ等)とも結合し合同負荷試験を実施
    ・リージョン単位で共有するリソースや SPOFがないかの確認
    ③ 障害試験
    ・周辺サービス・クラウドの障害時の影響・復旧の確認
    ・影響範囲・発生確率・再現難易度などから試験対象を決定
    

    View Slide

52. 試験実施
    ① 統合負荷試験
    ・目標同接まで段階的に繰り返し実施 & 負荷対策
    ・想定ワーストケースの組み合わせも合わせて実施
    ・トレーシングの導入やダッシュボードの整備なども並行して行った
    ② 合同負荷試験
    ・社内周辺サービス (広告・ログ等)とも結合し合同負荷試験を実施
    ・リージョン単位で共有するリソースや SPOFがないかの確認
    ③ 障害試験
    ・周辺サービス・クラウドの 障害時の影響・復旧 の確認
    ・影響範囲・発生確率・再現難易度 などから試験対象を決定
    

    View Slide

53. 負荷試験・障害試験
    SRE Team Missions
    視聴開始までに至るシステムリソースの確保を行うこと
    視聴開始までに至る負荷試験・障害試験を実施すること
    配信期間中における監視体制の確立すること
    負荷試験・障害試験完了
    (配信まで残り：3週間)
    

    View Slide

54. 監視体制の確立
    

    View Slide

55. 監視体制の確立 ~ファクト~
    11/20
    (SUN)
    オープニング
    カタール
    x
    エクアドル
    19:00
    30:00
    イングランド
    x
    イラン
    セネガル
    x
    オランダ
    アメリカ
    x
    ウェーアルズ
    アルゼンチン
    x
    サウジアラビア
    デンマーク
    x
    チュニジア
    メキシコ
    x
    ポーランド
    フランス
    x
    オーストリア
    A組1位
    x
    B組2位
    C組1位
    x
    D組2位
    D組1位
    x
    C組2位
    B組1位
    x
    A組2位
    ???
    x
    ???
    ???
    x
    ???
    ???
    x
    ???
    ???
    x
    ???
    ???
    x
    ???
    ・・・
    11/21
    (MON)
    グループステージ
    11/22
    (TUE)
    ベスト16 ベスト8 ベスト4
    ・・・
    ???
    x
    ???
    ???
    x
    ???
    3位決定戦
    ???
    x
    ???
    決勝戦
    12/03
    (SAT)
    12/04
    (SUN)
    12/09
    (FRI)
    12/10
    (SAT)
    12/13
    (TUE)
    12/14
    (WED)
    12/17
    (SAT)
    FIFA ワールドカップ カタール 2022 日程表
    12/18
    (SUN)
    ・・・ ・・・
    ・ワールドカップ期間は約1ヶ月 (11/20~12/18)
    ・最大連続配信日数は17日 (ベスト16まで)
    ・1日の配信最長時間は11時間 (19:00~30:00)
    

    View Slide

56. 監視体制の確立
    ● 張り付くべきか、アラート対応にするか
    ● どのチームが監視に参加してもらうか
    ● 土日含めた勤務体制を組む必要がある
    決めること・確認すること
    ● 連続深夜なので健康面の確保はどうか
    ● 通常の開発とのバランスはどうするか
    ● 労働基準周りは問題ないか
    

    View Slide

57. 監視体制の確立
    ● 張り付くべきか、アラート対応にするか
    ● どのチームが監視に参加してもらうか
    ● 土日含めた勤務体制を組む必要がある
    決めること・確認すること
    ① 初戦の数試合＋同接予測の高い試合は張り付き
    ② それ以外は基本アラート待機
    ③ クライアント含めた全チームに交代制による監視依頼
    ④ 監視に参加する場合は勤務条件は必ず守ること(連続勤務・稼働時間等)
    ⑤ 主要メンバーで各試合1名以上の張り付き監視を行うこと
    ● 連続深夜なので健康面の確保はどうか
    ● 通常の開発とのバランスはどうするか
    ● 労働基準周りは問題ないか
    

    View Slide

58. SRE Team Missions
    監視体制の確立
    視聴開始までに至るシステムリソースの確保を行うこと
    視聴開始までに至る負荷試験・障害試験を実施すること
    配信期間中における監視体制の確立すること
    監視体制の確立完了
    (配信まで残り：1週間)
    

    View Slide

59. そして、本番配信を迎える..
    

    View Slide

60. 大きな事故なく
    全64試合の配信完了!!
    

    View Slide

61. 本番どうだったか
    

    View Slide

62. 本番どうだったか ~トラフィック~
    サイト流入 (日本xドイツ)
    ① 番組開始後から徐々に増え、
    試合開始10分前程から流入速度が上がる
    ② ハーフタイム突入と後半戦開始。2回の波が
    あることがわかる
    ③ 日本のゴールにより流入スパイク
    ④ 試合終了後のダイジェストが公開され、
    一度離脱した人が戻ってくる
    ① ②
    ③
    ④
    

    View Slide

63. 本番どうだったか ~トラフィック~
    サイト内回遊 (日本xドイツ)
    ① ハーフタイム突入で一気にサイト内を回遊し、後半
    戦開始と共に落ち着く
    ② タイムシフトやダイジェストの公開により
    長時間回遊していることがわかる
    ① ②
    コメント投稿(日本xドイツ)
    ③ 日本のゴールと試合終了時に
    コメントスパイクが確認出来る
    ③
    

    View Slide

64. 本番どうだったか ~シナリオとの乖離 (流入)~
    実トラフィック
    ※ イメージ図
    通常利用 (既存)
    通常利用 (残存)
    流入
    平時
    番組
    開始
    前半戦
    ハーフタ
    イム
    後半戦
    試合
    終了
    平時
    流
    入
    視
    聴
    流入
    視聴
    視聴
    流入
    回遊
    視聴
    流
    入
    視
    聴
    流入
    視聴
    流入
    回遊
    タイムシ
    フト視聴
    視聴
    流入
    バース
    ト
    コメン
    ト
    バース
    ト
    シナリオ
    番組開始 前半戦 ハーフタ
    イム
    後半戦 試合終了
    想定通りだったのは「前半戦開始」「後半戦開始」
    想定外だったのは「ハーフタイム突入」「ゴール流入」「試合終了」
    より厳しい条件でテストを行っていたので問題ないと判断
    

    View Slide

65. 本番どうだったか ~その他~
    全試合通して、概ね試験範囲内のトラフィックで収まった
    配信期間中にもキャパプラとの乖離確認と試算を繰り返し行っていた
    想定外の事象について
    ● 日本戦での2試合同時配信によりサイト内での激しい移動が発生
    ● 日本戦での高負荷により一部 モニタリングメトリクスの欠損 が発生
    それぞれの担当者で迅速に対応し、大事には至らず
    (日本戦の緊張感と決勝戦後に流れたダイジェストの感動は忘れられない思い出)
    

    View Slide

66. 今後について
    

    View Slide

67. 今後について
    良かった点
    課題点
    ① 入念な試験により様々な潜在的課題の発掘 と改善に繋がった
    ② 原始的な張り付きでの監視により、 リスクの早期発見に繋がった
    ① 試験の完了までにかなり 時間をかけてしまった
    ② 横断的なリソース調整や負荷試験は非常に 認知負荷が高い活動だった
    

    View Slide

68. 今後について
    良かった点
    課題点
    ① 入念な試験により様々な潜在的課題の発掘 と改善に繋がった
    ② 原始的な張り付きでの監視により、 リスクの早期発見に繋がった
    ① 試験の完了までにかなり 時間をかけてしまった
    ② 横断的なリソース調整や負荷試験は非常に 認知負荷が高い活動だった
    負荷試験や障害試験などをより簡易に実施出来る環境作り
    開発チームが自律的に試験が実施出来る状態作り
    継続的に大型配信を想定した準備体制
    

    View Slide

69. View Slide