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

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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プロジェクトを個別で作成

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

ピーキースパイク対策

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

セキュリティ対策

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

まとめ

Slide 57

Slide 57 text

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