大規模イベントを成功させるための負荷・障害・セキュリティ対策 / Load, failure, and security measures for successful large-scale events

FIFA ワールドカップ カタール 2022における大規模トラフィックを捌くための負荷・障害・セキュリティ対策について説明します。ユーザシナリオやアクセスログを元にクリティカルパスを抽出し、ユーザが必ず視聴できるように問題が起きても小さく壊れるためのアーキテクチャ改変を行いました。またイベント独特のピーキーなスパイク対策やDDoS対策なども行い、本イベントだけでなく社会インフラとして未来を見据えた対応を実施しました。

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

Transcript

1. View Slide

2. お伝えする内容
   FIFA ワールドカップ カタール 2022 で想定される
   大規模トラフィックを捌くために行った
   負荷・障害・セキュリティ対策についてお話します。
   

   View Slide

3. 自己紹介
   ● 2013/04~ サイバーエージェント新卒入社
   ● 2013/05~ ペコロッジ（ブラウザゲーム）
   ● 2013/09~ ミリオンチェイン（ネイティブゲーム）
   ● 2014/07~ AWA（音楽配信サービス）
   ● 2019/06~ AbemaTV（動画配信サービス）
   辻　純平
   

   View Slide

4. Index
   1. イベント対策を行う上で
   重要なことは何か
   3. 小さく壊れるための
   アーキテクチャ改変
   2. シーケンスとクリティカルAPI
   4. ピーキースパイク対策
   6. 今後どのようなことに
   取り組んでいきたいか
   5. セキュリティ対策
   

   View Slide

5. イベント対策を行う上で重要なことは何か
   

   View Slide

6. イベント対策を行う上で重要なこと
   システム障害やキャパシティ不足でサービスを落とさないこと
   普段の配信よりもピーキー（急激）なリクエストがくること
   攻撃者の対象になりやすいこと
   費用対効果
   

   View Slide

7. システムが落ちる事による影響
   集客・残存における機会損失が発生する
   ブランドイメージの低下
   ● ユーザからの信頼
   ● 提携する事業者との信頼
   

   View Slide

8. システムが落ちる事による影響
   集客・残存における機会損失が発生する
   ブランドイメージの低下
   ● ユーザからの信頼
   ● 提携する事業者との信頼
   システムに問題が発生しても
   サービスの価値を提供するコア機能は
   落としてはいけない
   

   View Slide

9. シーケンスとクリティカルAPI
   

   View Slide

10. 一般的にイベントで負荷が集中しやすい箇所
    認証
    視聴権限チェック（サブスクリプション、PPV、レンタル）
    構成要素の多いホーム画面
    

    View Slide

11. シーケンス分析
    ● ユーザーシナリオ（クライアントシーケンス）毎に呼ばれる APIを一覧化
    ● 視聴までに必須（問題があると視聴できなくなる）なクリティカル APIを洗い出す
    ○ API毎に障害発生時の影響度を把握
    

    View Slide

12. トラフィック分析
    ● THE MATCH 2022でのアクセスログから API毎のトラフィック割合・スパイク傾向を分析
    ● API毎のリスクを可視化
    ● ポーリングなどで無駄にトラフィックが高いリクエストのあぶり出し
    Route 総計 最大RPS 番組開始前RPS
    GET /users 1000000 20000 1000
    PUT /users 10000 300 200
    GET /channels 2000000 40000 500
    ･･･
    ︙
    

    View Slide

13. シーケンス分析ｘトラフィック分析に基づく方針
    クリティカルパスとなるAPIを死守
    スパイク対策は必須
    ポーリング間隔をサーバサイドでコントロールするなど
    不要なトラフィックの削減
    

    View Slide

14. 小さく壊れるためのアーキテクチャ改変
    

    View Slide

15. 背景
    ● 巨大なドメインになることが想定し得たため、初期からマイクロサービスを採用
    ● 開発スピードを優先して DBが共通利用されている部分がある
    ● 特定のマイクロサービスへの依存が多い
    Service A
    Service E
    Service D
    Common
    Database
    Service B
    Service C
    Gateway
    

    View Slide

16. 課題
    DBやサービスの共通利用によりキャパシティの計算が難しい
    一部のサービスが落ちると連鎖的に落ちうる
    レイテンシが劣化してもリクエストが詰まりOOMで落ちる
    整合性を重視して冗長化されていないサービスがある
    

    View Slide

17. 共通利用による障害パターン
    Service A
    Service B
    Service C
    LB
    Database
    

    View Slide

18. 共通利用による障害パターン
    Service A
    Service B
    Service C
    LB
    Database
    

    View Slide

19. 共通利用による障害パターン
    Service A
    Service B
    Service C
    LB
    Database
    

    View Slide

20. 共通利用による障害パターン
    Service A
    Service B
    Service C
    LB
    Database
    

    View Slide

21. 大規模トラフィックでよくある障害パターン
    Pod A
    Pod B
    Pod C
    Service
    Cloud
    Load
    Balancing
    100rps
    100rps
    100rps
    

    View Slide

22. 大規模トラフィックでよくある障害パターン
    1. キャパシティを超えたリクエストが来ると 徐々に
    レイテンシが悪化する
    

    View Slide

23. 大規模トラフィックでよくある障害パターン
    1. キャパシティを超えたリクエストが来ると徐々に
    レイテンシが悪化する
    2. 捌ききれず滞留するリクエストが増えると OOM
    が発生する
    Pod A
    Pod B
    Pod C
    Service
    Cloud
    Load
    Balancing
    100rps
    100rps
    100rps
    

    View Slide

24. 大規模トラフィックでよくある障害パターン
    1. キャパシティを超えたリクエストが来ると徐々に
    レイテンシが悪化する
    2. 捌ききれず滞留するリクエストが増えると OOM
    が発生する
    

    View Slide

25. 大規模トラフィックでよくある障害パターン
    1. キャパシティを超えたリクエストが来ると徐々に
    レイテンシが悪化する
    2. 捌ききれず滞留するリクエストが増えると OOM
    が発生する
    3. OOMが発生すると水平分散させていた 残りの
    Podに負荷が集中
    Pod A
    Pod B
    Pod C
    Service
    Cloud
    Load
    Balancing
    150rps
    150rps
    

    View Slide

26. 大規模トラフィックでよくある障害パターン
    1. キャパシティを超えたリクエストが来ると徐々に
    レイテンシが悪化する
    2. 捌ききれず滞留するリクエストが増えると OOM
    が発生する
    3. OOMが発生すると水平分散させていた 残りの
    Podに負荷が集中
    4. 1に戻る
    Pod A
    Pod B
    Pod C
    Service
    Cloud
    Load
    Balancing
    300rps
    

    View Slide

27. Blast Radius of Failureの最小化
    ＝小さく壊れることが重要
    

    View Slide

28. 小さく壊れるために行ったこと
    1. サービスの分割
    3. Circuit Breaker
    2. DBの分割
    4. timeoutの短縮
    6. Sidecar exclusion
    5. フォールバック
    etc…
    

    View Slide

29. サービスの分割
    ● トラフィック分析を元にドメイン分割できるサービ
    スを分離
    ○ a. 普段リクエストが少ないが重い
    ○ b. リクエストが多いが軽い
    ● aで詰まった時にbで一気にOOMになる問題を
    回避
    Service
    Cloud
    Load
    Balancing
    API-a 10rps
    API-b 1000rps
    Before
    

    View Slide

30. サービスの分割
    ● トラフィック分析を元にドメイン分割できるサービ
    スを分離
    ○ a. 普段リクエストが少ないが重い
    ○ b. リクエストが多いが軽い
    ● aで詰まった時にbで一気にOOMになる問題を
    回避
    Service A
    Cloud
    Load
    Balancing
    API-a 10rps
    Service B
    API-b 1000rps
    After
    

    View Slide

31. DBの分割
    ● MongoDBをGCE上にセルフホスティング
    ● 複数のマイクロサービスで共通利用
    Before
    Compute Engine
    Service A
    Service B
    Service C
    ︙
    

    View Slide

32. DBの分割
    ● マイクロサービス毎の利用コレクションやトラフィック、データ量の洗い出し
    Microservice Collections Max ops Data size
    user users
    devices
    10000 100GB
    coin wallets 100 1GB
    channel groups
    channels
    1000 100MB
    ︙
    ･･･
    

    View Slide

33. DBの分割
    ● コレクションを共通利用しないようアプリケーション実装の改修
    ○ DBに直接アクセスせずオーナーとなるマイクロサービス経由に
    Service A
    Admin Tool
    Admin
    User
    

    View Slide

34. DBの分割
    ● コレクションを共通利用しないようアプリケーション実装の改修
    ○ DBに直接アクセスせずオーナーとなるマイクロサービス経由に
    Service A
    Admin Tool
    Admin
    User
    

    View Slide

35. DBの分割
    ● マイクロサービス毎に MongoDBを
    16クラスタに分割
    ● 運用コストが上がるため マネージド
    サービス（MongoDB Atlas）へ移行
    ● ライブマイグレーションを行い
    ゼロダウンタイムで移行
    After
    Service A
    Service B
    Service C
    ︙
    

    View Slide

36. Project D
    Project C
    Project B
    DBの分割
    Project A
    ● Firestoreは１プロジェクト１DBまで
    ● プロジェクト単位でquotaがあるため共通利用す
    ると大きく壊れやすい
    Service A
    Service B
    Service C
    Cloud
    Firestore
    Cloud
    Firestore
    Cloud
    Firestore
    サービス毎にGoogle Cloudプロジェクトを個別で作成
    

    View Slide

37. Circuit Breaker
    ● 特定のPodが落ちた時のトラフィックが他の Pod
    に影響しないように、閾値を超えたら即座にエ
    ラーを返す
    ● マイクロサービス毎・ gRPC毎に設定
    ○ 閾値は負荷試験から算出
    ● 不確実性の高い外部 APIに対しても流量を制御
    Container
    A
    Service
    Container
    A
    100rps
    100rps
    100rps
    100rps
    Pod A
    Pod B
    

    View Slide

38. Circuit Breaker
    ● 特定のPodが落ちた時のトラフィックが他の Pod
    に影響しないように、 閾値を超えたら
    即座にエラーを返す
    ● マイクロサービス毎・ gRPC毎に設定
    ○ 閾値は負荷試験から算出
    ● 不確実性の高い外部 APIに対しても
    流量を制御
    Container
    A
    Service
    Container
    A
    200rps 100rps
    Pod A
    Pod B
    503 error
    

    View Slide

39. timeoutを短く
    ● SLOは基本的にAvailabilityとLatency
    ● Availabilityを上げるなら自動リトライや timeoutを
    長めに
    ● 大規模トラフィックの場合 少しでも詰まるとOOM
    でシステムが落ちる ため
    Latencyを短くすることを優先
    

    View Slide

40. フォールバック
    ● 外部APIコール、レコメンドなどでパーソナライズ
    処理が重いケース
    ● キャッシュ
    ○ Cache-Asideパターン
    ○ workerがコールドスタート用データを
    キャッシュ
    Cache
    External
    Service
    Service A
    

    View Slide

41. フォールバック
    ● 外部APIコール、レコメンドなどでパーソナライズ
    処理が重いケース
    ● キャッシュ
    ○ Cache-Asideパターン
    ○ workerがコールドスタート用データを
    キャッシュ
    ● 5xxエラー、timeout時にキャッシュした値を返却
    する
    Cache
    External
    Service
    Service A
    

    View Slide

42. DBアクセスはSidecarを経由させない
    ● 高負荷時においてIstio SidecarがDBアクセスでのボトルネックになるケースに遭遇
    ○ DB側のメトリクスは低レイテンシだが、分散トレースでは非常に遅い
    ● Sidecarを経由させないことで改善
    Before
    (600~800ms)
    After
    (46ms)
    

    View Slide

43. ピーキースパイク対策
    

    View Slide

44. 背景
    ● イベントでは開始時刻やCM明けにユーザが急速に流入する
    ● 平時の10~100倍になることもざらにある
    

    View Slide

45. 課題
    スパイクにはオートスケールが間に合わない
    常設するとシステムコストが高騰する
    Twitterやニュースアプリなど外部でバズって想定外のスパイクが来る
    可能性があり、正確に予測することは困難
    

    View Slide

46. API Throttlingの導入
    ● ユーザーシーケンスに CDNレイヤでスロットリン
    グをかける
    ● 閾値を超えるとバックエンドシステムにリクエスト
    が到達しないため防御できる
    ● AkamaiとCloudFrontのActive/Standbyで
    冗長化
    Service A
    Service B
    ①
    ②
    CDN
    Backend
    Akamai API
    Gateway
    

    View Slide

47. セキュリティ対策
    

    View Slide

48. 課題
    大規模イベントは攻撃者にも認知されやすく攻撃影響からしても標的に
    なりやすい
    攻撃手法は多々あり網羅することが難しい。また対策してもイタチごっこになりや
    すい
    誤検知（偽陽性）の区別に時間がかかる
    

    View Slide

49. DDoS対策
    攻撃と言っても手法によって対策も異なる
    攻撃手法 説明 例
    ボリューム攻撃 L3, L4, L7が攻撃対象のフ
    ラッドベース攻撃
    SYN Flood, UDP Flood
    演算処理を消費する攻撃 ↑のように帯域を枯渇させる
    のではなくCPUやメモリを消
    費させる攻撃
    HTTP GET/POST Flood
    非対称攻撃 クライアントとサーバが必要と
    する帯域・リソースの非対称
    性を悪用する攻撃
    DNS amp, NTP amp
    脆弱性を突く攻撃 ソフトウェアの脆弱性を悪用
    する攻撃
    log4j, SSL再ネゴシエーショ
    ン
    

    View Slide

50. DDoS対策
    Google Cloudが標準的にカバーしている領域
    攻撃手法 説明 例
    ボリューム攻撃 L3, L4, L7が攻撃対象のフ
    ラッドベース攻撃
    SYN Flood, UDP Flood
    演算処理を消費する攻撃 ↑のように帯域を枯渇させる
    のではなくCPUやメモリを消
    費させる攻撃
    HTTP GET/POST Flood
    非対称攻撃 クライアントとサーバが必要と
    するリソースの非対称性を悪
    用する攻撃
    DNS amp, NTP amp
    脆弱性を突く攻撃 ソフトウェアの脆弱性を悪用
    する攻撃
    log4j, SSL再ネゴシエーショ
    ン
    

    View Slide

51. DDoS対策
    サービス側でWAFを使って対応する部分
    攻撃手法 説明 例
    ボリューム攻撃 L3, L4, L7が攻撃対象のフ
    ラッドベース攻撃
    SYN Flood, UDP Flood
    演算処理を消費する攻撃 ↑のように帯域を枯渇させる
    のではなくCPUやメモリを消
    費させる攻撃
    HTTP GET/POST Flood
    非対称攻撃 クライアントとサーバが必要と
    するリソースの非対称性を悪
    用する攻撃
    DNS amp, NTP amp
    脆弱性を突く攻撃 ソフトウェアの脆弱性を悪用
    する攻撃
    log4j, SSL再ネゴシエーショ
    ン
    

    View Slide

52. Cloud Armor Adaptive Protection
    ● 機械学習を用いて通常のリクエストか攻撃か判
    断
    ● 攻撃と判断したリクエストを通知し、
    ブロックルールの自動生成
    ● サービス側は数クリックでルールを
    適用できる
    ref: https://cloud.google.com/armor/docs/adaptive-protection-use-cases
    

    View Slide

53. 事前構成されたWAFルール
    ● オープンソースの業界標準から集められた
    脆弱性対策のためのルール
    ● 感度レベルを調節することで偽陽性を
    減らせる
    攻撃 WAFルール
    XSS xss-v33-canary
    リモートコード実行 rce-v33-canary
    Log4j の脆弱性 cve-canary
    ︙
    

    View Slide

54. 今後どのようなことに取り組んでいきたいか
    

    View Slide

55. 今後の取り組み
    負荷試験をCIに組み込み、システムキャパシティの継続的な可視化
    Blast Radius of Failureの最小化を保証するためのカオスエンジニアリング
    チーム毎の生産性を最大化するための適切なサービス分割
    チーム毎にコストが可視化されコスト効率が高いシステム設計（FinOps）
    

    View Slide

56. まとめ
    

    View Slide

57. まとめ
    FIFA ワールドカップ カタール 2022を乗り切るためにアーキテクチャを大幅刷新
    した
    Blast Radius of Failureの最小化をとにかく徹底
    スパイク対策・セキュリティ対策も強化しより堅牢に
    

    View Slide

58. View Slide

59. View Slide