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

2. 今日お話すること 「FIFA ワールドカップ カタール 2022」配信に向け、 キャパシティの確保を中心とした SREチームの活動についてお話します ※ 以降は 「FIFA ワールドカップ カタール 2022」 を 「 ワールドカップ」 とする
3. 自己紹介 岩永 勇祐 2017年株式会社サイバーエージェント入社 2018年株式会社AbemaTVのSREチームに移動 Twitter @nagaa052 ABEMA SRE
4. 遡ること2022年4月... 対策プロジェクト発足
5. 過去最大規模の 同接目標が発表された
6. プロジェクト概要
7. プロジェクトについて 負荷対策PJ 視聴体験PJ 残存PJ 運用PJ 10/31 コードフリーズ 11/20 配信開始
8. プロジェクトについて 負荷対策PJ 視聴体験PJ 残存PJ 運用PJ 10/31 コードフリーズ 11/20 配信開始 プロジェクトの責務「ワールドカップの安定配信 」 ミッション ・全64試合のライブ配信の視聴をインフラの不備なく提供する ・発生した問題に迅速に対応し、最速で復旧する ・発生する可能性を早期に推察し、最大限の予防対応を実行する 活動 キャパシティ確保、障害の局所化、クラウド基盤・ Web基盤改善 攻撃対策、シーケンス改善、負荷試験 等
9. プロジェクトについて 負荷対策PJ 視聴体験PJ 残存PJ 運用PJ 10/31 コードフリーズ 11/20 配信開始 プロジェクトの責務「ワールドカップの安定配信」 ミッション ・全64試合のライブ配信の視聴をインフラの不備なく提供する ・発生した問題に迅速に対応し、最速で復旧する ・発生する可能性を早期に推察し、最大限の予防対応を実行する 活動 キャパシティ確保、障害の局所化、クラウド基盤・ Web基盤改善 攻撃対策、シーケンス改善、負荷試験 等 SRE Team Missions 視聴開始までに至るシステムリソースの確保を行うこと 視聴開始までに至る負荷試験・障害試験を実施すること 配信期間中における監視体制を確立すること
10. システムリソースの確保
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 国内中継地点
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 国内中継地点 視聴 アクセス~視聴開始
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 & 配信チーム
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 & 配信チーム
15. 実施する上でのポイント
16. 実施する上でのポイント 1. リソース調整依頼は早めに行う必要がある • クラウド、関連サービス共に内部のリソース調整が必要になるケースがあるため
17. 実施する上でのポイント 1. リソース調整依頼は早めに行う必要がある 2. 同時並行で進行しているプロジェクトが複数ある • ワールドカップ向け機能開発・機能改善 • クラウドのリージョン移設 (台湾 -> 東京) • DBの分割、および移設など • クラウド、関連サービス共に内部のリソース調整が必要になるケースがあるため
18. 実施する上でのポイント 1. リソース調整依頼は早めに行う必要がある 2. 同時並行で進行しているプロジェクトが複数ある 3. 配信特性や運用施策を考慮して見積もること • ワールドカップ向け機能開発・機能改善 • クラウドのリージョン移設 (台湾 -> 東京) • DBの分割、および移設など • 番組特性 • 配信形態 • 訴求方法など • クラウド、関連サービス共に内部のリソース調整が必要になるケースがあるため
19. 実施する上でのポイント 1. リソース調整依頼は早めに行う必要がある 2. 同時並行で進行しているプロジェクトが複数ある 3. 配信特性や運用施策を考慮して見積もること • W杯向け機能開発・レコメンドシステムの内製化 • クラウドのリージョンの移設 (台湾 -> 東京) • DBの分割、および移設など • 番組特性 • 配信形態 • 訴求方法など • クラウド、外部サービス共に内部のリソース調達が必要になるケースがあるため ~ 方針 ~ 「精度は低くても、大枠の規模感を正しく見積もる」 (後続の工程で精度を上げていく)
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 & 配信チーム
21. Google Cloudリソースの確保 1. 対象コンポーネントの洗い出し L7LB (asia-northeast1) GKE Node (asia-northeast1) BigTable (asia-northeast1) Pub/Sub (project A) Memory store (asia-northeast1) ・ ・ ・ Components
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 ・ ・ ・
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 ・ ・ ・ ・ ・ ・
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 ・ ・ ・ ・ ・ ・ ・ ・ ・
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 ・ ・ ・ ・ ・ ・ ・ ・ ・
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 & 配信チーム
27. 関連外部サービスのリソース調整 1. 社内関連サービスと連携体制の構築 ABEMA 関連サービス
28. 関連外部サービスのリソース調整 1. 社内関連サービスと連携体制の構築 2. サービスごとに見積もり元となる 情報の整理 ABEMA 関連サービス Date Metrics Service ServiceA 01/01 Target x10 ServiceB 02/01 x5 ServiceC RPS xxx ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・
29. 関連外部サービスのリソース調整 1. 社内関連サービスと連携体制の構築 2. サービスごとに見積もり元となる 情報の整理 3. 各サービスにリソース確認、および 調達の依頼 ABEMA 関連サービス Date Metrics Service ServiceA 01/01 Target x10 ServiceB 02/01 x5 ServiceC RPS xxx ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ※ 色による違いは実態とは異なります。
30. システムリソースの確保 SRE Team Missions 視聴開始までに至るシステムリソースの確保を行うこと 視聴開始までに至る負荷試験・障害試験を実施すること 配信期間中における監視体制の確立すること リソース確保の調整完了 (配信まで残り：4.5ヶ月)
31. 負荷試験・障害試験
32. 実施条件 1. 10月31日まで (残り4ヶ月) にはすべての工程を終えること 2. 極力実際の配信と同等の状態を再現した試験を行うこと 3. 可能な限り考えられるワーストケースの試験を含めること
33. 負荷試験・障害試験 試験範囲 シナリオ 環境 試験実施 試験準備
34. 負荷試験・障害試験 試験範囲 シナリオ 環境 試験実施 試験準備
35. ※ イメージ図 Microservices DB Services 試験準備 ~試験範囲と実施方法~ Edge POP MicroserviceA DB A DB B MicroserviceC Cloud Amor Loadbalancer Cloud CDN Gateway A Gateway B Gateway C MicroserviceB
36. ※ イメージ図 Microservices DB Services 試験準備 ~試験範囲と実施方法~ Edge POP MicroserviceA DB A DB B MicroserviceC Cloud Amor Loadbalancer Cloud CDN Gateway A Gateway B Gateway C MicroserviceB 特定領域での試験の組み合わせによる 正しく測定出来ないポイントが許容できない
37. ※ イメージ図 Microservices DB Services 試験準備 ~試験範囲と実施方法~ Edge POP MicroserviceA DB A DB B MicroserviceC Cloud Amor Loadbalancer Cloud CDN Gateway A Gateway B Gateway C MicroserviceB 考えられる本番でのリクエストを 統 合的に負荷実施 特定領域での試験の組み合わせによる 正しく測定出来ないポイントが許容できない
38. 負荷試験・障害試験 試験範囲 の 確定 シナリオ 環境 試験準備 試験実施
39. 試験準備 ~環境~ • 既存負荷試験ツールが目標とする 負荷を生成出来ない • 既存負荷試験ツールでは 大量のコアを用意する必要がある • 試験環境はリージョン移設前の環境なのでネットワーク 経路が違う • 大規模なE2Eでの負荷試験環境は 最新の状態ではない 現状 ① 負荷試験ツールは新しいソリューションを検証・導入 ② 試験環境はゼロベースで構築(送信側・受信側)
40. Project Load 試験準備 ~環境~ Cluster A (asia-notheast1) Cluster B (asia-notheast1) 1. 東京リージョンに送信側・受信側2つのクラスタを準備
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)
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)
43. 負荷試験・障害試験 試験範囲 シナリオ 環境 実施準備 試験実施
44. 試験準備 ~シナリオ~ • 番組内容や配信形態 によって同じ同接数でもワークロードが異なる • 配信期間中も通常の配信は行われている • 期間中に通常利用者の増加も考えれらる ポイント 後に細かな調整を可能にするため、以下 パターンの組み合わせ を構築 1. 通常のサイト利用シナリオ 2. ワールドカップ1試合を想定したシナリオ 3. ワーストケースシナリオ ◦ ゴールによるコメントのバースト ◦ 外部訴求(Push通知など)による一斉流入 ◦ ユーザー種別の違いなど
45. 試験準備 ~シナリオ~ 通常利用シナリオ ・APIごとの重要度・コール数 などから対象パスの決定 ・直近の大型配信 から各APIの高さを決定 ※ イメージ図 通常利用 (既存) 通常利用 (残存)
46. ※ イメージ図 試験準備 ~シナリオ~ 通常利用 (既存) 通常利用 (残存) 流入 平時 番組開始 前半戦 開始周辺 前半戦 ハーフタイム 後半戦 開始周辺 後半戦 試合終了後 平時 流入 視聴 流入 視聴 視聴 流入 回遊 視聴 流入 視聴 流入 視聴 流入 回遊 タイムシフ ト視聴 視聴 通常利用シナリオ ・APIごとの重要度・コール数 などから対象パスの決定 ・直近の大型配信 から各APIの高さを決定 ワールドカップシナリオ ・ワールドカップで想定される視聴動線を確認 ・過去の配信から想定出来る時間経過ごとのユーザー分布 を調査 ・1試合を想定したタイムラインを定義し、マッピング ※ イメージ図 通常利用 (既存) 通常利用 (残存) 平時 番組 開始 前半戦 ハーフ タイム 後半戦 試合 終了 平時 流入 流入 視聴 流入 視聴 視聴 流入 回遊 視聴 流入 視聴 流入 視聴 流入 回遊 タイムシフ ト視聴 視聴
47. 試験準備 ~シナリオ~ 通常利用シナリオ ・APIごとの重要度・コール数 などから対象パスの決定 ・直近の大型配信 から各APIの高さを決定 ワールドカップシナリオ ・ワールドカップで想定される視聴動線を確認 ・過去の配信から想定出来る時間経過ごとのユーザー分布 を調査 ・1試合を想定したタイムラインを定義し、マッピング ワーストケースシナリオ ・施策担当者からの ヒアリングや過去配信の確認 ・ネガティブチェック を繰り返す ※ イメージ図 通常利用 (既存) 通常利用 (残存) 平時 番組 開始 前半戦 ハーフ タイム 後半戦 試合 終了 平時 流入 流入 視聴 流入 視聴 視聴 流入 回遊 視聴 流入 視聴 流入 視聴 流入 回遊 タイムシフ ト視聴 視聴 流入 バースト コメント バースト
48. 負荷試験・障害試験 試験範囲 シナリオ 環境 試験準備 試験実施
49. 負荷試験・障害試験 試験範囲 シナリオ 環境 試験実施 試験準備
50. 試験実施 ① 統合負荷試験 ・目標同接まで段階的に繰り返し実施 & 負荷対策 ・想定ワーストケースの組み合わせも合わせて実施 ・トレーシングの導入やダッシュボードの整備なども並行して行った ② 合同負荷試験 ・社内周辺サービス (広告・ログ等)とも結合し合同負荷試験を実施 ・リージョン単位で共有するリソースや SPOFがないかの確認 ③ 障害試験 ・周辺サービス・クラウドの障害時の影響・復旧の確認 ・影響範囲・発生確率・再現難易度などから試験対象を決定
51. 試験実施 ① 統合負荷試験 ・目標同接まで段階的に繰り返し実施 & 負荷対策 ・想定ワーストケースの組み合わせも合わせて実施 ・トレーシングの導入やダッシュボードの整備なども並行して行った ② 合同負荷試験 ・社内周辺サービス (広告・ログ等)とも結合し合同負荷試験を実施 ・リージョン単位で共有するリソースや SPOFがないかの確認 ③ 障害試験 ・周辺サービス・クラウドの障害時の影響・復旧の確認 ・影響範囲・発生確率・再現難易度などから試験対象を決定
52. 試験実施 ① 統合負荷試験 ・目標同接まで段階的に繰り返し実施 & 負荷対策 ・想定ワーストケースの組み合わせも合わせて実施 ・トレーシングの導入やダッシュボードの整備なども並行して行った ② 合同負荷試験 ・社内周辺サービス (広告・ログ等)とも結合し合同負荷試験を実施 ・リージョン単位で共有するリソースや SPOFがないかの確認 ③ 障害試験 ・周辺サービス・クラウドの 障害時の影響・復旧 の確認 ・影響範囲・発生確率・再現難易度 などから試験対象を決定
53. 負荷試験・障害試験 SRE Team Missions 視聴開始までに至るシステムリソースの確保を行うこと 視聴開始までに至る負荷試験・障害試験を実施すること 配信期間中における監視体制の確立すること 負荷試験・障害試験完了 (配信まで残り：3週間)
54. 監視体制の確立
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)
56. 監視体制の確立 • 張り付くべきか、アラート対応にするか • どのチームが監視に参加してもらうか • 土日含めた勤務体制を組む必要がある 決めること・確認すること • 連続深夜なので健康面の確保はどうか • 通常の開発とのバランスはどうするか • 労働基準周りは問題ないか
57. 監視体制の確立 • 張り付くべきか、アラート対応にするか • どのチームが監視に参加してもらうか • 土日含めた勤務体制を組む必要がある 決めること・確認すること ① 初戦の数試合＋同接予測の高い試合は張り付き ② それ以外は基本アラート待機 ③ クライアント含めた全チームに交代制による監視依頼 ④ 監視に参加する場合は勤務条件は必ず守ること(連続勤務・稼働時間等) ⑤ 主要メンバーで各試合1名以上の張り付き監視を行うこと • 連続深夜なので健康面の確保はどうか • 通常の開発とのバランスはどうするか • 労働基準周りは問題ないか
58. SRE Team Missions 監視体制の確立 視聴開始までに至るシステムリソースの確保を行うこと 視聴開始までに至る負荷試験・障害試験を実施すること 配信期間中における監視体制の確立すること 監視体制の確立完了 (配信まで残り：1週間)
59. そして、本番配信を迎える..
60. 大きな事故なく 全64試合の配信完了!!
61. 本番どうだったか
62. 本番どうだったか ~トラフィック~ サイト流入 (日本xドイツ) ① 番組開始後から徐々に増え、 試合開始10分前程から流入速度が上がる ② ハーフタイム突入と後半戦開始。2回の波が あることがわかる ③ 日本のゴールにより流入スパイク ④ 試合終了後のダイジェストが公開され、 一度離脱した人が戻ってくる ① ② ③ ④
63. 本番どうだったか ~トラフィック~ サイト内回遊 (日本xドイツ) ① ハーフタイム突入で一気にサイト内を回遊し、後半 戦開始と共に落ち着く ② タイムシフトやダイジェストの公開により 長時間回遊していることがわかる ① ② コメント投稿(日本xドイツ) ③ 日本のゴールと試合終了時に コメントスパイクが確認出来る ③
64. 本番どうだったか ~シナリオとの乖離 (流入)~ 実トラフィック ※ イメージ図 通常利用 (既存) 通常利用 (残存) 流入 平時 番組 開始 前半戦 ハーフタ イム 後半戦 試合 終了 平時 流 入 視 聴 流入 視聴 視聴 流入 回遊 視聴 流 入 視 聴 流入 視聴 流入 回遊 タイムシ フト視聴 視聴 流入 バース ト コメン ト バース ト シナリオ 番組開始 前半戦 ハーフタ イム 後半戦 試合終了 想定通りだったのは「前半戦開始」「後半戦開始」 想定外だったのは「ハーフタイム突入」「ゴール流入」「試合終了」 より厳しい条件でテストを行っていたので問題ないと判断
65. 本番どうだったか ~その他~ 全試合通して、概ね試験範囲内のトラフィックで収まった 配信期間中にもキャパプラとの乖離確認と試算を繰り返し行っていた 想定外の事象について • 日本戦での2試合同時配信によりサイト内での激しい移動が発生 • 日本戦での高負荷により一部 モニタリングメトリクスの欠損 が発生 それぞれの担当者で迅速に対応し、大事には至らず (日本戦の緊張感と決勝戦後に流れたダイジェストの感動は忘れられない思い出)
66. 今後について
67. 今後について 良かった点 課題点 ① 入念な試験により様々な潜在的課題の発掘 と改善に繋がった ② 原始的な張り付きでの監視により、 リスクの早期発見に繋がった ① 試験の完了までにかなり 時間をかけてしまった ② 横断的なリソース調整や負荷試験は非常に 認知負荷が高い活動だった
68. 今後について 良かった点 課題点 ① 入念な試験により様々な潜在的課題の発掘 と改善に繋がった ② 原始的な張り付きでの監視により、 リスクの早期発見に繋がった ① 試験の完了までにかなり 時間をかけてしまった ② 横断的なリソース調整や負荷試験は非常に 認知負荷が高い活動だった 負荷試験や障害試験などをより簡易に実施出来る環境作り 開発チームが自律的に試験が実施出来る状態作り 継続的に大型配信を想定した準備体制