FIFA ワールドカップ 2022を支えたデータ基盤リアーキテクチャ/ Rearchitecturing of ABEMA's Data Platform that supported the FIFA World Cup 2022

データマネジメントチームでは、FIFA ワールドカップ カタール 2022の過去最大規模のログのインジェストをスムーズに実施するため、データ基盤のリアーキテクチャを行いました。その際の要件や課題について整理し、パブリッククラウドの機能を最大限に活用した現行データ基盤の解説を行います。

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

Transcript

2. 本日お伝えする内容 FIFA ワールドカップ カタール 2022 (以降W杯と表記します) のレポーティングを死守するた め、ABEMAのデータ基盤にて行った改良や負荷対策についてお伝えします
3. 自己紹介 山村 英貴 株式会社サイバーエージェント2013年度新卒入社後、2019年 株式会社AbemaTVに異動 担当領域は、ログのインジェストに関するサーバー開発と、パイプラインの開発・運用 好きな事は、サーバーパフォーマンス最適化（ ISUCONなど） Twitter @hidekiy GitHub @hidekiy 株式会社AbemaTV > 開発本部 > ADC > データマネジメントチーム データエンジニア
4. 目次 1. 要件の整理 2. 今回のリアーキテクチャの設計思想とその背景 3. 期間中に実際に起こった事象 4. まとめ、今後のデータ基盤
5. 要件の整理
6. レポーティング要件 ABEMAでは早朝から日次集計バッチを実行しているが、過去最大のデイリーユーザー規模であっても、ログ の取り込み遅延＋バッチ処理時間の遅延の合計について、 数時間以内として欲しいというビジネス要件があった。 日次集計の遅延を数時間以内とする https://www.cyberagent.co.jp/news/detail/id=28258 プレスリリース（参考） :
7. 可用性要件 ABEMA内部では様々なコンポーネントが組み合わされ動作しているが、個々の耐障害性等が上手く機能し、 トータルで配信が実施出来ている状態であれば、必ずログも収集して欲しいという要件があった。 配信が実施できる限りログも収集する 配信状況 ログ収集状況 結果 〇 〇 OK（目標） 〇 × NG（欠測で成果不明 ） × 〇 OK（原因調査に役に立つ） × × OK（非常事態なので仕方ない）
8. 2種類の負荷観点について 負荷観点 考慮すべき点 流量A (瞬時負荷) リクエスト受信部分で利用する CPU、クオータ等 流量B (定常負荷) パイプライン全体のスループット
9. 負荷要件 通常 W杯 瞬時負荷想定 10 200 定常負荷想定 1 20 後々調整する前提で、各負荷想定はログ基盤の歴代最高の瞬時負荷を誇っていた恋愛リアリティショー最終 話の放送時のものを用いて、その同時接続数の比例計算で求めた。
10. インフラ要件 十分に安全を見越した負荷想定で試合を向かえる事は行うが、もし仮に上振れた場合があったとしても、状況 を見て次の試合までに追加のリソースを確保して望めるようにする必要があった。 試合ごとに柔軟にリソースを確保出来る 次の試合までに完了 リソース追加検討 キャパシティ確保 （クオータ相談など） スケールアウト等実施
11. 今回のリアーキテクチャの設計思想とそ の背景
12. リアーキテクチャ実施前
13. リアーキテクチャ実施前の懸念点 瞬時負荷に関しては初段の EC2のスケールアウトで対応出来そうではあったが、 それを乗り越えた後も、最大で平常時の 20倍程度の定常負荷が想定でき、 この取り込み遅延が翌日の日次バッチの開始遅延に影響するので十分なリソースを確保したいが、 迅速なリソース調達要求を満たせない懸念があった。 最大20倍の定常負荷の処理 ⇒ ログ基盤全体のパブリッククラウド完結が必要
14. リアーキテクチャ実施後 (バッチレイヤー) Point ・CloudFrontのアクセスログを使うことで、ログの喪失を抑止 ・全てのコンポーネントが処理負荷に応じて自動的に調整される
15. リアーキテクチャ実施後 (スピードレイヤー) Point ・バッチレイヤーで既に集計は担保出来ており、上記はストリーム側にのみ影響 ・各種キューの処理が遅延しないよう、リアルタイムでの流量監視と調整を実施
16. 期間中に実際に起こった事象
17. 実際に起こった事 特に問題なく12月5日 決勝トーナメント日本 vsクロアチアを含む、 過去最大規模のトラフィックを難なく捌いてくれた。 最大の変換遅延も1回目のリトライ(5分後) 以上は伸びず、全体的に安心感があった。 バッチレイヤー（CloudFront標準ログ利用部分）
18. 実際に起こった事 概ね大きな遅延は発生せず、数分以内でログのストリームを処理できていた。 Kinesis Data Streamsのシャード数の設定のみ手動設定が必要な箇所で、 あらかじめ十分な規模に設定しつつ、実際の負荷に合わせて調整する事で最適化を図った。 スピードレイヤー（CloudFrontリアルタイムログ利用部分）
19. まとめと今後のデータ基盤
20. W杯サービス要件を満たしたログ基盤を得られた まとめ • 日次集計の遅延を数時間以内とする ◦ 瞬時負荷を追う事だけに囚われず、バッチ処理を適切に使う等、最終的な利用要件で処理の仕方 を最適化することで、安定性、運用の容易性を高める事が達成できた。 • 配信が実施できる限りログも収集する ◦ マネージドな機能を最大限活用し、最低死守するラインをオブジェクトストレージで確保でき、安心 感があった。 • 試合ごとに柔軟にリソースを確保出来る ◦ 開催期間中、最低限運用が必要な箇所を、内部のメンバーで重点的に管理することで、 大規模なイベント時においても対応柔軟性を出す事ができた。
21. 今後のデータ基盤 複数のログを一括で送信するバルク送信の活用など、クライアント側も含めたログ収集の最適化や、 マルチクラウド活用により、クラウド障害に対する耐性の確保を予定しております。 ログのインジェストレイヤーの改良