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

by CyberAgent

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

プロジェクト概要

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

システムリソースの確保

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

実施する上でのポイント

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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 ・・・

Slide 23

Slide 23 text

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 ・・・・・・

Slide 24

Slide 24 text

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 ・・・・・・・・・

Slide 25

Slide 25 text

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 ・・・・・・・・・

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

負荷試験・障害試験

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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)

Slide 42

Slide 42 text

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)

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

監視体制の確立

Slide 55

Slide 55 text

監視体制の確立 ~ファクト~ 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)

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

本番どうだったか

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

今後について

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

No content