大規模イベントを支える ABEMA の アーキテクチャ 変遷 2025

CEDEC 2025 登壇資料です。本セッションでは、大規模イベントの配信を支えるために私たちが実施したクラウドアーキテクチャの強化施策と、更なる大規模イベントに向けた改善や社会インフラとしての進化について共有します。

従来の技術的負債を解消しながら、大規模トラフィック時のキャパシティ管理やオートスケール戦略、サービスメッシュ導入による通信制御・可観測性向上、モニタリングシステムの最適化など多角的なアプローチを実施しました。

過去のイベントを通じて得た学びを活かし、負荷試験やログ分析からクリティカルパスを抽出するとともに、障害時も小さく壊れるための耐障害設計を徹底。さらに、ピーキーなトラフィックや DDoS などのセキュリティリスクにも多層防御で対応し、社会インフラとしての信頼性をより強固にしました。

これらの取り組みは単なるイベント対応にとどまらず、次世代の大規模配信プラットフォームや社会インフラとしての進化に寄与するものです。本セッションを通じて、大規模ライブ配信の裏側でどのようなクラウドアーキテクチャが進化してきたのかを知り、今後のシステム設計・運用に役立つ具体的なノウハウをお伝えします。

Transcript

1. AbemaTV, Inc. All Rights Reserved
 1 大規模イベントを支える ABEMA の アーキテクチャ 変遷 2025 July 22, CEDEC 2025 永岡 克利 / 辻 純平 Platform Div, Development Headquarters, AbemaTV Inc.
2. 大規模イベントを支える ABEMA の アーキテクチャ 変遷 2025 1 ABEMA について Index 2 Platform Strategy 基本戦略 キャパシティ戦略の変遷 可観測性戦略の変遷 3 Backend Strategy システム アーキテクチャの変遷 負荷試験・障害試験の変遷
3. AbemaTV, Inc. All Rights Reserved
 3 ABEMA について 1
4. AbemaTV, Inc. All Rights Reserved
 ABEMAについて 登録不要で、いつでも無料で楽しめる 24時間365日編成されているリニア配信と 見逃した作品を好きなタイミングでオンデマンドでも楽しむこともできます。 国内最大級のオリジナルエピソード数 オリジナルエピソード数は国内発の動画サービスで日本No.1(※)を誇り、 注目の新作映画、国内外の人気ドラマ、話題のアニメなど豊富なラインナップの作品や、 様々な音楽や舞台のオンラインライブも展開。 ※2024年8月時点、自社調べ 100%プロコンテンツ サイバーエージェントとテレビ朝日 それぞれの強みを活かした制作体制で高品質なコンテンツを配信しています。 多彩なラインナップ 24時間編成のニュース専門チャンネルをはじめ、 オリジナルのドラマや恋愛番組、アニメ、スポーツなど、 多彩なジャンルの約25チャンネルを24時間365日放送しています。 4
5. AbemaTV, Inc. All Rights Reserved
 ABEMA 紹介 複数デバイス対応・多彩な チャンネル ラインナップ 5
6. AbemaTV, Inc. All Rights Reserved
 2025 年 4 月 2,892 万 WAU 3,408 2,892 引用元: CyberAgent 2025 年 2Q 決算発表資料
7. AbemaTV, Inc. All Rights Reserved
 7 Platform Strategy 2
8. 永岡 克利 Principal Platform Engineer Head of Platform Div, Development Headquarters, AbemaTV Inc. CyberAgent Developer Experts Cloud Architect スピーカー紹介 8 2011 年 - 株式会社 サイバーエージェント入社 2017 年 - 株式会社 AbemaTV に参画 ABEMA ではプロダクト開発のテックリードを経て、 2019 年より Cloud Platform Team のマネージャーとし て ABEMA のクラウド ソリューション全般を担当。 2024 年より Platform Div の責任者として、プラット フォーム全般 (Cloud Platform, Developer Productivity, Platform Backend, SRE, Security) を担当。
9. 基本戦略は大きく変えず、2023 年から 2 年間で何を取り組んできたか 関連資料 9 2023/05/25 Google Cloud Days ‘23 東京 2023/06/09 Jagu’e’r クラウドネイティブ分科会
10. 基本戦略 10 10
11. Elemental MediaPackage High Level Cloud Architecture 11 Cloudflare Amazon CloudFront Cloud CDN Akamai 　 CDN 　 　 AWS : 配信システム 　 　 Google Cloud : ユーザーシステム 　 　 EKS 東京/大阪/ソウル + App Mesh 　 　 Managed Services 　 Elemental MediaLive DynamoDB Elemental MediaConnect … etc Memorystore 　 Managed Services 　 Cloud Spanner Cloud Bigtable MongoDB Atlas … etc Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service gRPC / HTTP gRPC / HTTP Fastly ※ 主要シーケンス・サービスのみを記載 Mutual TLS Load Balancer 　 GKE 東京/大阪/台湾 + Cloud Service Mesh 　
12. マルチ CDN システム要件に応じた CDN サービス選定 • 配信システム ◦ 高品質な伝送、定常時の帯域確保と大型イベント時の帯域拡張 ◦ Akamai CDN + Amazon CloudFront • ユーザーシステム ◦ 汎用 API のキャッシュ、画像変換、Server-side Rendering / Push など機能性 ◦ Cloud CDN + Cloudflare (Workers, Images) + Fastly (Edge Compute / Fanout) 12
13. マネージド サービスの発展性が高いものを用いてハイブリッドで利用する • AWS ◦ 配信システム (AWS Elemental MediaConnect, MediaLive, MediaPackage, MediaTailor) ◦ MAM (Amazon S3, Amazon Bedrock) • Google Cloud ◦ ユーザーシステム (Google Kubernetes Engine, Cloud Service Mesh) ◦ 行動ログ分析、レコメンド基盤システム (BigQuery, Vertex AI, AlloyDB AI) • Cloudflare ◦ 画像変換 (Workers, Images) ◦ 仮想待機室 (Waiting Room) マルチ クラウド 13
14. マルチ リージョン 配信システムとユーザー システムで、マルチ リージョンの用途が異なる • AWS : 配信システム ◦ 東京 + 大阪 + ソウル ◦ 信頼性を最重視し、主要経路はリージョン内で完結する ◦ 特定リージョンで問題が起きても配信を続けられる • Google Cloud : ユーザー システム ◦ 東京 + 大阪 + 台湾 ◦ 拡張性を最重視し、一部経路はリージョン間通信が生じる ◦ 日本国内のキャパシティ不足時は、台湾リージョンに拡張する 14
15. 透過的活用 クラウドの差分を意識することなく利用できるプラット フォーム • Kubernetes を中心としたマイクロ サービス アーキテクチャ ◦ EKS & GKE ◦ Add-on を駆使し、同じように利用できる環境を整備 ◦ Prometheus + Victoria Metrics + Grafana による統合監視基盤 • サービス メッシュによるサービス間通信の信頼性向上 ◦ App Mesh & Cloud Service Mesh ◦ Circuit Breaker, Outlier Detection (Destination Rule) による影響範囲の最小化 ◦ 応答時間/コードに応じた Auto Retry (Virtual Service) による回復性を担保 ◦ Traffic Mirroring (Virtual Service) による本番環境での負荷試験と障害注入試験 15 ※ サービスメッシュの活用事例は後半 Backend Strategy セクションで紹介します
16. キャパシティ戦略の変遷 16 16
17. Elemental MediaPackage High Level Cloud Architecture 再載 17 Cloudflare Amazon CloudFront Cloud CDN Akamai 　 CDN 　 　 AWS : 配信システム 　 　 Google Cloud : ユーザーシステム 　 　 EKS 東京/大阪/ソウル + App Mesh 　 　 Managed Services 　 Elemental MediaLive DynamoDB Elemental MediaConnect … etc Memorystore 　 Managed Services 　 Cloud Spanner Cloud Bigtable MongoDB Atlas … etc Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service Micro Service gRPC / HTTP gRPC / HTTP Fastly ※ 主要シーケンス・サービスのみを記載 Load Balancer 　 GKE 東京/大阪/台湾 + Cloud Service Mesh 　 Mutual TLS
18. Elemental MediaPackage 配信システムの負荷係数 18 Cloudflare Amazon CloudFront Cloud CDN Akamai 　 CDN 　 　 AWS : 配信システム 　 　 EKS 東京/大阪/ソウル + App Mesh 　 　 Managed Services 　 Elemental MediaLive DynamoDB Elemental MediaConnect … etc Micro Service Micro Service Micro Service Micro Service Micro Service gRPC / HTTP Fastly ※ 主要シーケンス・サービスのみを記載 Load Balancer 配信システムへの負荷は CCU (同時視聴者数) に比例しない • 主に CDN Origin としての活用 • CDN 側の負荷を制御するため、マルチ CDN の活用 • CDN 負荷分散、流入制限、画質制御が重要
19. ユーザー システムへの負荷は CCU (同時視聴者数) に比例する • リニア放送の CM や、サッカーのハーフタイム • 大規模な視聴ユーザーが一斉に回遊する • GKE スケールアウトが重要、流入制限、仮想待機室 ユーザー システムの負荷係数 19 Cloudflare Amazon CloudFront Cloud CDN Akamai 　 CDN 　 　 Google Cloud : ユーザーシステム 　 Memorystore 　 Managed Services 　 Cloud Spanner Cloud Bigtable MongoDB Atlas … etc Micro Service Micro Service Micro Service Micro Service Micro Service gRPC / HTTP Fastly ※ 主要シーケンス・サービスのみを記載 Load Balancer 　 GKE 東京/大阪/台湾 + Cloud Service Mesh 　
20. ユーザー システム は HPA による オートスケール • Resource Metrics ◦ CPU 使用量 • External Metrics ◦ CCU (同時視聴者数) や HTTP/gRPC リクエスト数 従来 20 スパイク アクセス CCU API RPS 大規模なユーザーが視聴中 CDN に負荷が集中する期間 CDN に負荷が集中する期間 大規模なユーザーが視聴中 後半戦 45min 前半戦 45min CCU ★ ハーフタイム 15min ★
21. HPA から Stackdriver Adapter 経由で Cloud Monitoring の External Metrics を参照する 従来の構成 21 　GKE 東京　 　GKE 台湾　 Cloud Monitoring Managed Service for Prometheus 　NS: monitoring　 Grafana HA Grafana Alert Victoria Metrics 　NS: monitoring　 Prometheus Prometheus Adapter Stackdriver Adapter 　NS: gmp-system　 Collector Rule Evalutor HPA api Deployment api 　NS: user　 Pod(s) api Pod(s) api Pod(s) api SLA 99.95% ※ kube-system/metrics-server (CPU 使用率 …etc) は省略 Fetch External Metrics Failover GMP
22. 人気番組によるピーキーな流入 • 毎週月曜 21 時に「今日、好きになりました。」の放送開始 • 放送開始に合わせて同時視聴者数が、約 5 倍に跳ね上がる • 負荷係数に応じたオートスケールでは、Pod も Node も間に合わない • 担当者が手動でスケールアウト・インを行っていた 従来の課題 22 人気番組 月曜日の CCU ( 同時視聴者数 ) 変化 5x
23. KEDA の Cron Scaler と Prometheus Scaler によるオートスケールを実現 • KEDA ◦ Kubernetes Event-driven Autoscaling ◦ 様々な Scaler によって柔軟なオートスケールを実現 • Cron Scaler ◦ External Metrics ( 時間帯 ) に対応 ◦ 人気番組に向けた手動スケール対応を自動化 • Prometheus Scaler ◦ External Metrics ( HTTP/gRPC RPS, CCU ) に対応 ◦ 普段使いしている PromQL でスケール条件を指定可能 対応 23
24. Cron Scaler を用いて時間帯に応じた制御 Prometheus Scaler を用いて Cloud Monitoring または Victoria Metrics を参照する 現在の構成 24 ※ kube-system/metrics-server (CPU Usage …etc) は省略 KEDA Cron Scaler Prometheus Scaler 　GKE 東京　 　GKE 台湾　 Cloud Monitoring Managed Service for Prometheus 　NS: monitoring　 Grafana HA Grafana Alert Victoria Metrics 　NS: monitoring　 Prometheus 　NS: gmp-system　 Collector Rule Evalutor HPA api Deployment api 　NS: user　 Pod(s) api Pod(s) api Pod(s) api SLA 99.95% Fetch External Metrics 　NS: keda　 Failover Polling Metrics GMP
25. Cron Scaler 毎週月曜 21 時の人気番組に向けて • 20:40 ~ 21:00 ◦ Replicas: 3 • 20:50 ~ 21:00 ◦ Replicas: 12 Prometheus Scaler 上記時間帯以外は CCU ベース • Pod あたり CCU 50 万を超過 ◦ Replicas: 1 ~ 20 apiVersion: keda.sh/v1alpha1 kind: ScaledObject spec: minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: cron # ① 時間帯に応じたスケールアウト metadata: start: "40 20 * * 1" end: "0 21 * * 1" desiredReplicas: '3' - type: cron # ② 時間帯に応じたスケールアウト metadata: start: "50 20 * * 1" end: "0 21 * * 1" desiredReplicas: '12' - type: prometheus # ③ CCU に応じたスケールアウト metadata: serverAddress: https://monitoring.googleapis.com/v1/… query: sum(avg_over_time(abema_ccu:delay2m[1m])) threshold: '500000' KEDA 設定例 ※ CPU 使用率などは省略、各閾値は実際と異なる
26. Monitoring & Observability 戦略の変遷 26 26
27. 2022 年の統合監視基盤 • Grafana • Victoria Metrics Cluster • Prometheus Agent Mode 従来 27 vm insert Victria Metrics vm insert Promethes Agent Mode vm insert Micro Services Scraping Metrics vm-storage gRPC / HTTP vm-insert vm-select 過去 3 年分のメトリクスを格納 Grafana Grafana
28. システムの複雑化 • 年々増加かつ、開発速度向上の副作用により加速傾向 • 経験や知見が浅い領域において根本原因に辿り着くまでに時間がかかる 統合監視基盤の課題 28 2018 年 2020 年 2023 年 ( 2 年経過 ) ( 3 年経過 ) ※ Promviz によるサービス間通信の可視化
29. 2022 年の統合監視基盤 • Grafana • Victoria Metrics Cluster • Prometheus Agent Mode 2023 年から、Grafana 活用強化 • Grafana Loki : ログ • Grafana Tempo : トレーシング • Grafana Pyroscope : プロファイリング • OpenTelemetry : テレメトリー データ伝送 2024/10/10 Grafana meetup #3 山本 哲也 Developer Productivity, Platform Div, Development Headquarters, AbemaTV Inc. Grafana 活用強化 29
30. Grafana 活用強化による課題 30 4 Signals (Metrisc, Traces, Logs, Profiles) が繋がっていない • 4 Signals を計測しているが、それぞれが繋がっていない • システム複雑化に向けて、これらのシームレスな探索体験が重要 更なる大規模イベントに向けて、潜在的な未知の異常を検知したい • 生成 AI 機能は Grafana Cloud (有償) に限られている • システム複雑化に向けて、Anomaly Monitor など異常値検知が重要 更なる大規模イベントに向けて、大規模なテレメトリー データを効率的に解析したい • 高度な分析体験や、トラブルシュートの支援機能が求められる • システム複雑化に向けて、経験知見が浅い領域でも根本原因を調査できる能力が重要
31. 2024 年から OpenTelemetry をベースとした SaaS 連携の強化 • OpenTelemetry ◦ OTel に準拠した 内製トレース SDK を刷新 ◦ Micro Services への導入を進め、計測データの実装を強化 ◦ 特定ベンダーに依存した実装ではなく、OTel 準拠で汎用性を高めている • SaaS 活用の加速化 ◦ Honeycomb による大規模なトレースの効果的な分析手法を整備 ◦ Datadog による 4 Signals のシームレスな探索体験と異常検知を整備 ◦ OTel 準拠 SaaS は、既存実装を変えることなく導入可能な構成を実現 SaaS 連携強化 31
32. Grafana + OTel + SaaS 構成 Tail-based Sampling による分析精度を落とさずに SaaS コスト制御を実現 32 vm insert Victria Metrics Grafana vm insert OTel Gateway vm insert Promethes Agent Mode vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent vm insert OTel Collector Datadog Honeycomb 　 Spans　 　 Metrics / Logs　 　 Events　 Scraping Metrics gRPC / HTTP SaaS 連携強化 Scraping Metrics / Logs　 Send Trace by ABEMA OTel SDK 過去 3 年分のメトリクスを格納 　 Tail-based　 　 Sampling　
33. SaaS 連携によってコストは増加します！ … っと言っても、そんなに簡単に許されるわけじゃない、ですよね コスト 33
34. インフラコストの約 7% を Monitoring & Observability に投資する • SaaS 活用の方針 ◦ 統合監視基盤に不足している Observability を補う • 統合監視基盤の方針 ◦ SaaS 優位性に意味を持たないデータの汎用的な監視基盤 ◦ プラット フォーム (例: Kubernetes Capacity、HTTP/gRPC RPS) や運用業務 (例: CCU、WAF、SLI/SLO) • 統合監視基盤の最適化によって、投資額を変えない ◦ 経過時間に応じてメトリクス保管方法を最適化 ▪ 直近 6 ヶ月は応答速度を重視 ▪ 以後は、いくつかの制約を加えた低コストを重視 Monitoring & Observability 戦略 34
35. アプリケーション領域は SaaS 活用 プラットフォーム領域は直近６ヶ月未満は Victria Metrics、以後は Thanos を参照 35 vm insert Victria Metrics Grafana vm insert OTel Gateway vm insert Promethes Agent Mode vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent vm insert OTel Collector Datadog Honeycomb 　 Spans　 　 Metrics / Logs　 　 Events　 Scraping gRPC / HTTP 現在の構成 vm insert Thanos GCS 6 ヶ月未満 6 ヶ月以降 Metrics Scraping Metrics / Logs　 Send Trace by ABEMA OTel SDK 　 Tail-based　 　 Sampling　
36. 前半 まとめ 36 36
37. Platform Strategy について主要な取り組みについて紹介しました • 基本戦略 ◦ 従来の基本戦略を継続 ◦ Multi CDN / Cloud / Region を適材適所に組み合わせ、透過的活用を実現 • キャパシティ戦略の変遷 ◦ 従来のオートスケール戦略を強化 ◦ KEDA の Cron Scaler と Prometheus Scaler による柔軟なスケーリングを実現 • Monitoring & Observability 戦略の変遷 ◦ 更なる大規模イベントに向けて統合監視基盤は縮退し SaaS 活用を加速 ◦ OpenTelemetry をベースに、複数 SaaS へ柔軟に拡張可能な構成を実現 前半のまとめ 37 ※ 生成 AI 活用や、セキュリティ強化も取り組んでいますが、それはまた別の機会にて
38. AbemaTV, Inc. All Rights Reserved
 38 Backend Strategy 3
39. 辻 純平 Director of Backend Engineering Platform Div, Development Headquarters, AbemaTV Inc. 2013 年 - 株式会社 サイバーエージェント入社 2019 年 - 株式会社 AbemaTV に参画 ABEMA では 2019 年からプロダクト開発のテックリード を担当し、2021 年にはデータマネジメントチームとデー タ基盤の整備。その後 SRE チームのマネージャーを担当。 2024 年よりバックエンドのディレクターとして、バック エンド全体を管理。 スピーカー紹介 39
40. システムアーキテクチャの変遷 40 40
41. • 小さく壊れるためのアーキテクチャ改変 ◦ サービス分割 ◦ DB 分割 ◦ Circuit Breaker 導入 ◦ timeout 短縮 ◦ フォールバック ◦ Sidecar exclusion • ピーキースパイク対策 ◦ API Throttling の導入 2022年 大規模イベント時の対応 41
42. 42 小さく壊れるためのアーキテクチャ改変
43. • DBやサービスの共通利用によりキャパシティの計算が難しい • 一部のサービスが落ちると連鎖的に落ちうる • レイテンシが劣化してもリクエストが詰まりOOMで落ちる • 整合性を重視して冗長化されていないサービスがある 課題 43
44. 大規模トラフィックでよくある障害パターン 44 Pod A Pod B Pod C Service Cloud Load Balancing 100rps 100rps 100rps
45. 大規模トラフィックでよくある障害パターン 45 1. キャパシティを超えたリクエストが来ると徐々に レイテンシが悪化する
46. 大規模トラフィックでよくある障害パターン 46 Pod A Pod B Pod C Service Cloud Load Balancing 100rps 100rps 100rps 1. キャパシティを超えたリクエストが来ると徐々に レイテンシが悪化する 2. 捌ききれず滞留するリクエストが増えると OOM が発生する
47. 大規模トラフィックでよくある障害パターン 47 1. キャパシティを超えたリクエストが来ると徐々に レイテンシが悪化する 2. 捌ききれず滞留するリクエストが増えると OOM が発生する
48. 大規模トラフィックでよくある障害パターン 48 Pod A Pod B Pod C Service Cloud Load Balancing 150rps 150rps 1. キャパシティを超えたリクエストが来ると徐々に レイテンシが悪化する 2. 捌ききれず滞留するリクエストが増えると OOM が発生する 3. OOM が発生すると水平分散させていた残りの Pod に負荷が集中
49. 大規模トラフィックでよくある障害パターン 49 Pod A Pod B Pod C Service Cloud Load Balancing 300rps 1. キャパシティを超えたリクエストが来ると徐々に レイテンシが悪化する 2. 捌ききれず滞留するリクエストが増えると OOM が発生する 3. OOM が発生すると水平分散させていた残りの Pod に負荷が集中 4. Pod が再起動しても足りず 1 に戻る
50. 大規模トラフィックでよくある障害パターン 50 Pod A Pod B Pod C Service Cloud Load Balancing 1. キャパシティを超えたリクエストが来ると徐々に レイテンシが悪化する 2. 捌ききれず滞留するリクエストが増えると OOM が発生する 3. OOM が発生すると水平分散させていた残りの Pod に負荷が集中 4. Pod が再起動しても足りず 1 に戻る 5. 全サービスがダウン
51. 51 Blast Radius of Failureの最小化 ＝小さく壊れることが重要
52. サービス分割 52 Service Cloud Load Balancing API-a 10rps API-b 1000rps Before Service A Cloud Load Balancing API-a 10rps Service B API-b 1000rps After • トラフィック分析を元にドメイン分割できるサービスを分離 ◦ a. 普段リクエストが少ないが重い ◦ b. リクエストが多いが軽い • a で詰まった時に b で一気に OOM になる問題を回避
53. DB分割 53 Compute Engine Service A Service B Service C ︙ Service A Service B Service C ︙ Before • MongoDB を GCE 上にセルフホスティング • 複数のマイクロサービスで共通利用 After • マイクロサービス毎に MongoDB を 16 クラスタに分割 • 運用コストが上がるためマネージドサービス（MongoDB Atlas） へ移行 • ライブマイグレーションを行いゼロダウンタイムで移行
54. 100rps 100rps 100rps Circuit Breaker導入 54 Container A Service Container A 100rps 100rps Pod A Pod B Container A Service Container A 200rps Pod A Pod B 503 error (100rps) Before After • 特定の Pod が落ちた時のトラフィックが他の Pod に影響しないように、閾値を超えたら即座にエラーを返す • マイクロサービス毎・gRPC 毎に設定 ◦ 閾値は負荷試験から算出 • 不確実性の高い外部APIに対しても流量を制御
55. timeout短縮 55 • SLO は基本的に Availability と Latency • Availability を上げるなら自動リトライや timeout を長めに • 大規模トラフィックの場合 少しでも詰まると OOM でシステムが落ちる ため Latency を短くすることを優先
56. フォールバック 56 • 外部 API コール、レコメンドなどでパーソナライズ処理が重いケース • キャッシュ ◦ Cache-Aside パターン ◦ worker がコールドスタート用データをキャッシュ • 5xx エラー、timeout 時にキャッシュした値を返却する Cache External Service Service A Cache External Service Service A 正常時 異常時
57. Sidecar exclusion（DB アクセスは Sidecar を経由させない） 57 • 高負荷時において Istio Sidecar が DB アクセスでのボトルネックになるケースに遭遇 ◦ DB 側のメトリクスは低レイテンシだが、分散トレースでは非常に遅い • Sidecar を経由させないことで改善 Before (600~800ms) After (46ms)
58. 58 ピーキースパイク対策
59. • イベントでは開始時刻や CM 明けにユーザが急速に流入する • 平時の 10 ~ 100 倍になることもざらにある 背景 59
60. • スパイクにはオートスケールが間に合わない • 常設するとシステムコストが高騰する • X (Twitter) やニュースアプリなど外部でバズって想定外のスパイクが来る可能性があ り、正確に予測することは困難 課題 60
61. API Throttlingの導入 61 • ユーザーシーケンスに CDN レイヤでスロットリ ングをかける • 閾値を超えるとバックエンドシステムにリクエスト が到達しないため防御できる • Akamai と CloudFront の Active/Standby で 冗長化 Service A Service B ① ② CDN Backend Akamai API Gateway
62. 62 2023年からの取り組み
63. • 認証・認可サーバの分離 ◦ 複数ある API gateway にお ける認証ロジックの統一 • JWT の有効期限の短縮 ◦ ログアウト機能の導入 ◦ セキュリティ向上 • サービスサイドでの session revoke 機能の実現 認証基盤刷新 63
64. • 事前に想定されるスパイクをピンポイント で保護 ◦ 大規模イベント配信 • 突発的なスパイクのセーフティネットに ◦ 「今日、好きになりました。」など 人気コンテンツによるスパイク ◦ 開発側が把握しない出稿によるスパ イク • ユーザに高解像度を提供するため同時接続 数を自動で制限可能に Virtual Waiting Room 64
65. • DDoS レベルでなくとも、多数のリクエス トによってシステムの信頼性を落とすこと が可能 ◦ メールボム攻撃 ◦ 外部 SaaS を利用するレイテンシの高 い API への攻撃 • CloudArmor では柔軟に防げないアプリ ケーション領域を網羅的に保護する rate limit を導入 アプリケーションレイヤ rate limit 65
66. 負荷試験・障害試験 66 66
67. • 過去最大規模の同接目標が発表された • サービスの成長に伴い、システムがますます複雑になっている 背景 67 再掲 2018 年 2020 年 2023 年 ( 2 年経過 ) ( 3 年経過 )
68. • クラウド、関連サービス共に内部のリソース調整が必要になるためできる限り早めに キャパシティプラニングする必要がある • 攻撃の送信側・受信側それぞれ大規模トラフィックを扱う環境がない • 配信特性や運用施策がこれまでと大きく変わる 課題 68
69. 69 精度は低くても、大枠の規模感を正しく見積もる (後続の工程で精度を上げていく)
70. キャパシティプラニング 70 1. 対象コンポーネントの洗い出し 2. 各コンポーネントの見積もり要素確認 3. 参考とする過去配信の決定と各利用量の 確認 4. 同時接続数を係数とした試算 5. 並行プロジェクトによる変更の影響確認 6. Google Cloud 側にリソース調整の依頼 L7LB (asia-northeast1) QPS IngressGbps Egress Gbps GKE Node (asia-northeast1) Core RAM Storage Bigtable (asia-northeast1) Nodes Storage IngressGbps Egress Gbps Publisher Throughput Subscriber Throughput Pub/Sub (project A) Instances Memory Memory store (asia-northeast1) xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx ・ ・ ・ Metrics Source Target Components ・ ・ ・ ・ ・ ・ ・ ・ ・
71. 負荷試験環境準備 71 Project Load Cluster A (asia-notheast1) Cluster B (asia-notheast1) Global LB Cluster C (asia-east1) DBs Microservices Prometheus Prometheus Kind: Job PipCD Victoria Metrics Internal LB Grafana Kind: k6 Operator 1. 東京リージョンに送信側・受信側2つのクラスタを準備 2. 送信側を SRE 、受信側を開発者で環境構築 3. CI、モニタリング、Quota の緩和等も Cloud Platform チームと協力し準備 Cluster B (asia-notheast1)
72. 負荷試験シナリオ準備 通常利用シナリオ ・API ごとの重要度・コール数などから対象パスの決定 ・直近の大型配信から各 API の高さを決定 大規模イベントシナリオ ・大規模イベントで想定される視聴動線を確認 ・過去の配信から想定出来る時間経過ごとのユーザー分布 を調査 ・1試合を想定したタイムラインを定義し、マッピング ワーストケースシナリオ ・施策担当者からのヒアリングや過去配信の確認 ・ネガティブチェックを繰り返す ※ イメージ図 通常利用 (既存) 通常利用 (残存) 平時 番組 開始 前半戦 ハーフ タイム 後半戦 試合 終了 平時 流入 流入 視聴 流入 視聴 視聴 流入 回遊 視聴 流入 視聴 流入 視聴 流入 回遊 タイムシフ ト視聴 視聴 流入 バースト コメント バースト
73. 障害試験 on 負荷試験環境 73 • 周辺サービス・クラウドの障害時の影響・復旧の確認 ◦ 以下の様な状態で負荷シナリオを流す ▪ 特定のマイクロサービスをシャットダウン ▪ Google Cloud の特定サービスにおける Quota を 0 に（擬似的に障害を再 現） • トラフィック分析における影響範囲・発生確率、クラウドを含めた再現難易度などから試験 対象を決定
74. 74 2023年からの取り組み
75. 本番環境での負荷試験・障害試験のためのマルチテナント化 75 • 本番環境の同じクラスター内に構築された、もう一つのアプリケーション群 ◦ Kubernetes で自作 Operator 。開発者はカスタムリソースを定義するだけで OK • Pod と Node を完全に分離し、ABEMA 利用者のリクエストを捌く Pod のリソースを食い潰さない ◦ Istio によるトラフィック制御 • データソースは共有 ◦ ABEMA は様々な種類の DB を利用していることから DB まで複製するのは厳しい
76. ローカルで透過的に負荷試験できるツールの提供 76 課題 • 簡易に gRPC/HTTP などへ負荷をかける試験環 境の不足 ◦ gRPC の負荷試験を行う際、ポートフォ ワードや強い権限などが必要になる状況 を解消したい。 ◦ 社内ネットワークへの過度な負荷やレイテ ンシーを避けるため、VPC リソースの圧迫 を考慮しなくてよい簡易な仕組みを作りた い。 解決策 • CLI ツールを提供し、負荷試験の実行インフラを 意識せずに簡単にローカルから試験できる。
77. データベースRTO 77 • 多くのマネージド DB の RPO は 0秒 ~ 1分 • 一方で RTO は計測が必要 • 大規模災害を想定して各 DB を再構築からリスト ア、アプリケーションとの接続までの RTO を検証 ◦ リカバリフローの最適化 ◦ オペレーションの最適化 クラスタ名 データサイズ テーブル数 RecoveryTime(min) Cluster A 10GB 4 17 Cluster B 15TB 3 60 Cluster C 500GB 12 24
78. 障害対応フロー 78 • Warroom の導入 ◦ 障害時のコミュニケーションを行 うための個別の Slack チャンネ ル • 生成 AI を活用して自動的な障害のリ アルタイム要約・障害報告書の生成 ※こちらは生成AIにつくってもらった仮の障害です
79. まとめ 79 79
80. Backend Strategy について主要な取り組みについて紹介しました • システムアーキテクチャの変遷 ◦ 2022年 大規模イベントにおける負荷・障害対策 ▪ 「小さく壊れる」を標語にアーキテクチャ刷新 ◦ 以降はキャパシティコントロールやセキュリティを更に改善 • 負荷試験・障害試験、障害フロー ◦ 当時は大規模イベントに特化した負荷試験・障害試験の実施 ◦ 現在は持続可能な試験・障害フローにできるように SRE チームがプラットフォー ムを整備 まとめ 80
81. AbemaTV, Inc. All Rights Reserved