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

2. お伝えする内容 FIFA ワールドカップ カタール 2022 で想定される 大規模トラフィックを捌くために行った 負荷・障害・セキュリティ対策についてお話します。
3. 自己紹介 • 2013/04~ サイバーエージェント新卒入社 • 2013/05~ ペコロッジ（ブラウザゲーム） • 2013/09~ ミリオンチェイン（ネイティブゲーム） • 2014/07~ AWA（音楽配信サービス） • 2019/06~ AbemaTV（動画配信サービス） 辻　純平
4. Index 1. イベント対策を行う上で 重要なことは何か 3. 小さく壊れるための アーキテクチャ改変 2. シーケンスとクリティカルAPI 4. ピーキースパイク対策 6. 今後どのようなことに 取り組んでいきたいか 5. セキュリティ対策
5. イベント対策を行う上で重要なことは何か
6. イベント対策を行う上で重要なこと システム障害やキャパシティ不足でサービスを落とさないこと 普段の配信よりもピーキー（急激）なリクエストがくること 攻撃者の対象になりやすいこと 費用対効果
7. システムが落ちる事による影響 集客・残存における機会損失が発生する ブランドイメージの低下 • ユーザからの信頼 • 提携する事業者との信頼
8. システムが落ちる事による影響 集客・残存における機会損失が発生する ブランドイメージの低下 • ユーザからの信頼 • 提携する事業者との信頼 システムに問題が発生しても サービスの価値を提供するコア機能は 落としてはいけない
9. シーケンスとクリティカルAPI
10. 一般的にイベントで負荷が集中しやすい箇所 認証 視聴権限チェック（サブスクリプション、PPV、レンタル） 構成要素の多いホーム画面
11. シーケンス分析 • ユーザーシナリオ（クライアントシーケンス）毎に呼ばれる APIを一覧化 • 視聴までに必須（問題があると視聴できなくなる）なクリティカル APIを洗い出す ◦ API毎に障害発生時の影響度を把握
12. トラフィック分析 • THE MATCH 2022でのアクセスログから API毎のトラフィック割合・スパイク傾向を分析 • API毎のリスクを可視化 • ポーリングなどで無駄にトラフィックが高いリクエストのあぶり出し Route 総計 最大RPS 番組開始前RPS GET /users 1000000 20000 1000 PUT /users 10000 300 200 GET /channels 2000000 40000 500 ･･･ ︙
13. シーケンス分析ｘトラフィック分析に基づく方針 クリティカルパスとなるAPIを死守 スパイク対策は必須 ポーリング間隔をサーバサイドでコントロールするなど 不要なトラフィックの削減
14. 小さく壊れるためのアーキテクチャ改変
15. 背景 • 巨大なドメインになることが想定し得たため、初期からマイクロサービスを採用 • 開発スピードを優先して DBが共通利用されている部分がある • 特定のマイクロサービスへの依存が多い Service A Service E Service D Common Database Service B Service C Gateway
16. 課題 DBやサービスの共通利用によりキャパシティの計算が難しい 一部のサービスが落ちると連鎖的に落ちうる レイテンシが劣化してもリクエストが詰まりOOMで落ちる 整合性を重視して冗長化されていないサービスがある
17. 共通利用による障害パターン Service A Service B Service C LB Database
18. 共通利用による障害パターン Service A Service B Service C LB Database
19. 共通利用による障害パターン Service A Service B Service C LB Database
20. 共通利用による障害パターン Service A Service B Service C LB Database
21. 大規模トラフィックでよくある障害パターン Pod A Pod B Pod C Service Cloud Load Balancing 100rps 100rps 100rps
22. 大規模トラフィックでよくある障害パターン 1. キャパシティを超えたリクエストが来ると 徐々に レイテンシが悪化する
23. 大規模トラフィックでよくある障害パターン 1. キャパシティを超えたリクエストが来ると徐々に レイテンシが悪化する 2. 捌ききれず滞留するリクエストが増えると OOM が発生する Pod A Pod B Pod C Service Cloud Load Balancing 100rps 100rps 100rps
24. 大規模トラフィックでよくある障害パターン 1. キャパシティを超えたリクエストが来ると徐々に レイテンシが悪化する 2. 捌ききれず滞留するリクエストが増えると OOM が発生する
25. 大規模トラフィックでよくある障害パターン 1. キャパシティを超えたリクエストが来ると徐々に レイテンシが悪化する 2. 捌ききれず滞留するリクエストが増えると OOM が発生する 3. OOMが発生すると水平分散させていた 残りの Podに負荷が集中 Pod A Pod B Pod C Service Cloud Load Balancing 150rps 150rps
26. 大規模トラフィックでよくある障害パターン 1. キャパシティを超えたリクエストが来ると徐々に レイテンシが悪化する 2. 捌ききれず滞留するリクエストが増えると OOM が発生する 3. OOMが発生すると水平分散させていた 残りの Podに負荷が集中 4. 1に戻る Pod A Pod B Pod C Service Cloud Load Balancing 300rps
27. Blast Radius of Failureの最小化 ＝小さく壊れることが重要
28. 小さく壊れるために行ったこと 1. サービスの分割 3. Circuit Breaker 2. DBの分割 4. timeoutの短縮 6. Sidecar exclusion 5. フォールバック etc…
29. サービスの分割 • トラフィック分析を元にドメイン分割できるサービ スを分離 ◦ a. 普段リクエストが少ないが重い ◦ b. リクエストが多いが軽い • aで詰まった時にbで一気にOOMになる問題を 回避 Service Cloud Load Balancing API-a 10rps API-b 1000rps Before
30. サービスの分割 • トラフィック分析を元にドメイン分割できるサービ スを分離 ◦ a. 普段リクエストが少ないが重い ◦ b. リクエストが多いが軽い • aで詰まった時にbで一気にOOMになる問題を 回避 Service A Cloud Load Balancing API-a 10rps Service B API-b 1000rps After
31. DBの分割 • MongoDBをGCE上にセルフホスティング • 複数のマイクロサービスで共通利用 Before Compute Engine Service A Service B Service C ︙
32. DBの分割 • マイクロサービス毎の利用コレクションやトラフィック、データ量の洗い出し Microservice Collections Max ops Data size user users devices 10000 100GB coin wallets 100 1GB channel groups channels 1000 100MB ︙ ･･･
33. DBの分割 • コレクションを共通利用しないようアプリケーション実装の改修 ◦ DBに直接アクセスせずオーナーとなるマイクロサービス経由に Service A Admin Tool Admin User
34. DBの分割 • コレクションを共通利用しないようアプリケーション実装の改修 ◦ DBに直接アクセスせずオーナーとなるマイクロサービス経由に Service A Admin Tool Admin User
35. DBの分割 • マイクロサービス毎に MongoDBを 16クラスタに分割 • 運用コストが上がるため マネージド サービス（MongoDB Atlas）へ移行 • ライブマイグレーションを行い ゼロダウンタイムで移行 After Service A Service B Service C ︙
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プロジェクトを個別で作成
37. Circuit Breaker • 特定のPodが落ちた時のトラフィックが他の Pod に影響しないように、閾値を超えたら即座にエ ラーを返す • マイクロサービス毎・ gRPC毎に設定 ◦ 閾値は負荷試験から算出 • 不確実性の高い外部 APIに対しても流量を制御 Container A Service Container A 100rps 100rps 100rps 100rps Pod A Pod B
38. Circuit Breaker • 特定のPodが落ちた時のトラフィックが他の Pod に影響しないように、 閾値を超えたら 即座にエラーを返す • マイクロサービス毎・ gRPC毎に設定 ◦ 閾値は負荷試験から算出 • 不確実性の高い外部 APIに対しても 流量を制御 Container A Service Container A 200rps 100rps Pod A Pod B 503 error
39. timeoutを短く • SLOは基本的にAvailabilityとLatency • Availabilityを上げるなら自動リトライや timeoutを 長めに • 大規模トラフィックの場合 少しでも詰まるとOOM でシステムが落ちる ため Latencyを短くすることを優先
40. フォールバック • 外部APIコール、レコメンドなどでパーソナライズ 処理が重いケース • キャッシュ ◦ Cache-Asideパターン ◦ workerがコールドスタート用データを キャッシュ Cache External Service Service A
41. フォールバック • 外部APIコール、レコメンドなどでパーソナライズ 処理が重いケース • キャッシュ ◦ Cache-Asideパターン ◦ workerがコールドスタート用データを キャッシュ • 5xxエラー、timeout時にキャッシュした値を返却 する Cache External Service Service A
42. DBアクセスはSidecarを経由させない • 高負荷時においてIstio SidecarがDBアクセスでのボトルネックになるケースに遭遇 ◦ DB側のメトリクスは低レイテンシだが、分散トレースでは非常に遅い • Sidecarを経由させないことで改善 Before (600~800ms) After (46ms)
43. ピーキースパイク対策
44. 背景 • イベントでは開始時刻やCM明けにユーザが急速に流入する • 平時の10~100倍になることもざらにある
45. 課題 スパイクにはオートスケールが間に合わない 常設するとシステムコストが高騰する Twitterやニュースアプリなど外部でバズって想定外のスパイクが来る 可能性があり、正確に予測することは困難
46. API Throttlingの導入 • ユーザーシーケンスに CDNレイヤでスロットリン グをかける • 閾値を超えるとバックエンドシステムにリクエスト が到達しないため防御できる • AkamaiとCloudFrontのActive/Standbyで 冗長化 Service A Service B ① ② CDN Backend Akamai API Gateway
47. セキュリティ対策
48. 課題 大規模イベントは攻撃者にも認知されやすく攻撃影響からしても標的に なりやすい 攻撃手法は多々あり網羅することが難しい。また対策してもイタチごっこになりや すい 誤検知（偽陽性）の区別に時間がかかる
49. DDoS対策 攻撃と言っても手法によって対策も異なる 攻撃手法 説明 例 ボリューム攻撃 L3, L4, L7が攻撃対象のフ ラッドベース攻撃 SYN Flood, UDP Flood 演算処理を消費する攻撃 ↑のように帯域を枯渇させる のではなくCPUやメモリを消 費させる攻撃 HTTP GET/POST Flood 非対称攻撃 クライアントとサーバが必要と する帯域・リソースの非対称 性を悪用する攻撃 DNS amp, NTP amp 脆弱性を突く攻撃 ソフトウェアの脆弱性を悪用 する攻撃 log4j, SSL再ネゴシエーショ ン
50. DDoS対策 Google Cloudが標準的にカバーしている領域 攻撃手法 説明 例 ボリューム攻撃 L3, L4, L7が攻撃対象のフ ラッドベース攻撃 SYN Flood, UDP Flood 演算処理を消費する攻撃 ↑のように帯域を枯渇させる のではなくCPUやメモリを消 費させる攻撃 HTTP GET/POST Flood 非対称攻撃 クライアントとサーバが必要と するリソースの非対称性を悪 用する攻撃 DNS amp, NTP amp 脆弱性を突く攻撃 ソフトウェアの脆弱性を悪用 する攻撃 log4j, SSL再ネゴシエーショ ン
51. DDoS対策 サービス側でWAFを使って対応する部分 攻撃手法 説明 例 ボリューム攻撃 L3, L4, L7が攻撃対象のフ ラッドベース攻撃 SYN Flood, UDP Flood 演算処理を消費する攻撃 ↑のように帯域を枯渇させる のではなくCPUやメモリを消 費させる攻撃 HTTP GET/POST Flood 非対称攻撃 クライアントとサーバが必要と するリソースの非対称性を悪 用する攻撃 DNS amp, NTP amp 脆弱性を突く攻撃 ソフトウェアの脆弱性を悪用 する攻撃 log4j, SSL再ネゴシエーショ ン
52. Cloud Armor Adaptive Protection • 機械学習を用いて通常のリクエストか攻撃か判 断 • 攻撃と判断したリクエストを通知し、 ブロックルールの自動生成 • サービス側は数クリックでルールを 適用できる ref: https://cloud.google.com/armor/docs/adaptive-protection-use-cases
53. 事前構成されたWAFルール • オープンソースの業界標準から集められた 脆弱性対策のためのルール • 感度レベルを調節することで偽陽性を 減らせる 攻撃 WAFルール XSS xss-v33-canary リモートコード実行 rce-v33-canary Log4j の脆弱性 cve-canary ︙
54. 今後どのようなことに取り組んでいきたいか
55. 今後の取り組み 負荷試験をCIに組み込み、システムキャパシティの継続的な可視化 Blast Radius of Failureの最小化を保証するためのカオスエンジニアリング チーム毎の生産性を最大化するための適切なサービス分割 チーム毎にコストが可視化されコスト効率が高いシステム設計（FinOps）
56. まとめ
57. まとめ FIFA ワールドカップ カタール 2022を乗り切るためにアーキテクチャを大幅刷新 した Blast Radius of Failureの最小化をとにかく徹底 スパイク対策・セキュリティ対策も強化しより堅牢に