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

大規模イベントを成功させるための負荷・障害・セキュリティ対策 / Load, failure,...

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

April 19, 2023
Tweet

More Decks by CyberAgent

Other Decks in Technology

Transcript

  1. Index 1. イベント対策を行う上で 重要なことは何か 3. 小さく壊れるための アーキテクチャ改変 2. シーケンスとクリティカルAPI 4.

    ピーキースパイク対策 6. 今後どのようなことに 取り組んでいきたいか 5. セキュリティ対策
  2. サービスの分割 • トラフィック分析を元にドメイン分割できるサービ スを分離 ◦ a. 普段リクエストが少ないが重い ◦ b. リクエストが多いが軽い

    • aで詰まった時にbで一気にOOMになる問題を 回避 Service A Cloud Load Balancing API-a 10rps Service B API-b 1000rps After
  3. DBの分割 • マイクロサービス毎に MongoDBを 16クラスタに分割 • 運用コストが上がるため マネージド サービス(MongoDB Atlas)へ移行

    • ライブマイグレーションを行い ゼロダウンタイムで移行 After Service A Service B Service C ︙
  4. 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プロジェクトを個別で作成
  5. Circuit Breaker • 特定のPodが落ちた時のトラフィックが他の Pod に影響しないように、閾値を超えたら即座にエ ラーを返す • マイクロサービス毎・ gRPC毎に設定

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

    gRPC毎に設定 ◦ 閾値は負荷試験から算出 • 不確実性の高い外部 APIに対しても 流量を制御 Container A Service Container A 200rps 100rps Pod A Pod B 503 error
  7. DDoS対策 攻撃と言っても手法によって対策も異なる 攻撃手法 説明 例 ボリューム攻撃 L3, L4, L7が攻撃対象のフ ラッドベース攻撃

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

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

    SYN Flood, UDP Flood 演算処理を消費する攻撃 ↑のように帯域を枯渇させる のではなくCPUやメモリを消 費させる攻撃 HTTP GET/POST Flood 非対称攻撃 クライアントとサーバが必要と するリソースの非対称性を悪 用する攻撃 DNS amp, NTP amp 脆弱性を突く攻撃 ソフトウェアの脆弱性を悪用 する攻撃 log4j, SSL再ネゴシエーショ ン
  10. Cloud Armor Adaptive Protection • 機械学習を用いて通常のリクエストか攻撃か判 断 • 攻撃と判断したリクエストを通知し、 ブロックルールの自動生成

    • サービス側は数クリックでルールを 適用できる ref: https://cloud.google.com/armor/docs/adaptive-protection-use-cases