Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

大規模イベントを成功させるための負荷・障害・セキュリティ対策 / 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

CyberAgent
PRO

April 19, 2023
Tweet

More Decks by CyberAgent

Other Decks in Technology

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. シーケンス分析xトラフィック分析に基づく方針
    クリティカルパスとなる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は1プロジェクト1DBまで
    ● プロジェクト単位で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