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

大規模イベントに向けた ABEMA アーキテクチャの遍歴 ~ Platform Strat...

大規模イベントに向けた ABEMA アーキテクチャの遍歴 ~ Platform Strategy 詳細解説 ~

ハッカーズチャンプルー 2025 の登壇資料です。

Avatar for Katsutoshi Nagaoka

Katsutoshi Nagaoka

August 02, 2025
Tweet

More Decks by Katsutoshi Nagaoka

Other Decks in Technology

Transcript

  1. AbemaTV, Inc. All Rights Reserved
 1 大規模イベントに向けた ABEMA アーキテクチャの遍歴 ~

    Platform Strategy 詳細解説 ~ Aug 2, Hackers Champloo 2025 / #hcmpl25 永岡 克利 Platform Div, Development Headquarters, AbemaTV, Inc.
  2. 大規模イベントに向けた ABEMA アーキテクチャの遍歴        ~ Platform Strategy 詳細解説 ~ 1

    ABEMA について Index 2 Platform Strategy クラウド活用戦略 キャパシティ戦略の変遷 可観測性戦略の変遷
  3. 永岡 克利 Principal Platform Engineer Head of Platform Div, Development

    Headquarters, AbemaTV Inc. CyberAgent Developer Experts Cloud Architect スピーカー紹介 9 2011 年 - 株式会社 サイバーエージェント入社 2017 年 - 株式会社 AbemaTV に参画 ABEMA ではプロダクト開発のテックリードを経て、 2019 年より Cloud Platform Team のマネージャーとして ABEMA のクラウド ソリューション全般を担当。 2024 年より Platform Div の責任者として、プラット フォーム全般 (Cloud Platform, Developer Productivity, Platform Backend, SRE, Security) を担当。 @na_ga
  4. Elemental MediaPackage High Level Cloud Architecture 12 Cloudflare Amazon CloudFront

    Google 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  
  5. マルチ CDN システム要件に応じた CDN (Content Delivery Network) サービス選定 目的: コンテンツデータをユーザーに高速かつ効率的に伝送すること

    • 配信システム ◦ 高品質な伝送、定常時の帯域確保と大型イベント時の帯域拡張 ◦ Akamai CDN + Amazon CloudFront • ユーザーシステム ◦ 汎用 API のキャッシュ、画像変換、Server-side Rendering / Push など機能性 ◦ Google Cloud CDN + Cloudflare (Workers, Images) + Fastly (Edge Compute / Fanout) 13
  6. マネージド サービスの発展性が高いものを用いてハイブリッドで利用する • AWS ◦ 配信システム (AWS Elemental MediaConnect, MediaLive,

    MediaPackage, MediaTailor) ◦ Media Asset Management (Amazon S3, Amazon Bedrock) • Google Cloud ◦ ユーザーシステム (Google Kubernetes Engine, Cloud Service Mesh) ◦ 行動ログ分析、レコメンド基盤システム (BigQuery, Vertex AI, AlloyDB AI) • Cloudflare ◦ 画像変換 (Workers, Images) ◦ 仮想待機室 (Waiting Room) マルチ クラウド 14
  7. マルチ リージョン 配信システムとユーザー システムで、マルチ リージョンの用途が異なる • AWS : 配信システム ◦

    東京 + 大阪 + ソウル ◦ 信頼性を最重視し、主要経路はリージョン内で完結する ◦ 特定リージョンで問題が起きても配信を続けられる • Google Cloud : ユーザー システム ◦ 東京 + 大阪 + 台湾 ◦ 拡張性を最重視し、一部経路はリージョン間通信が生じる ◦ 日本国内のキャパシティ不足時は、台湾リージョンに拡張する 15
  8. 透過的活用 クラウドの差分を意識することなく利用できるプラット フォーム • Kubernetes を中心としたマイクロ サービス アーキテクチャ ◦ EKS

    (Elastic Kubernetes Service) & GKE (Google Kubernetes Engine) ◦ Add-on を駆使し、同じように利用できる環境を整備 ◦ Prometheus + Victoria Metrics + Grafana による統合監視基盤 • Kubernetes + Service Mesh によるサービス間通信の信頼性向上 ◦ App Mesh & Cloud Service Mesh ◦ Circuit Breaker, Outlier Detection (Destination Rule) による影響範囲の最小化 ◦ 応答時間/コードに応じた Auto Retry (Virtual Service) による回復性を担保 ◦ Traffic Mirroring (Virtual Service) による本番環境での負荷試験と障害注入試験 16
  9. Elemental MediaPackage High Level Cloud Architecture 再載 18 Cloudflare Amazon

    CloudFront Google 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  
  10. Elemental MediaPackage 配信システムの負荷係数 19 Cloudflare Amazon CloudFront Google 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 ※ 主要シーケンス・サービスのみを記載、ターゲティング広告は CCU に比例する Load Balancer 配信システムへの負荷は CCU (同時視聴者数) に比例しない • 主に CDN Origin としての活用 • CDN 側の負荷を制御するため、マルチ CDN の活用 • CDN 負荷分散、流入制限、画質制御が重要
  11. ユーザー システムへの負荷は CCU (同時視聴者数) に比例する • リニア放送の CM や、サッカーのハーフタイム •

    大規模な視聴ユーザーが一斉に回遊する • GKE スケールアウトが重要、流入制限、仮想待機室 ユーザー システムの負荷係数 20 Cloudflare Amazon CloudFront Google 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  
  12. Kubernetes の HPA (Horizontal Pod Autoscaler) を用いて スパイク アクセス に対応

    • Resource Metrics ◦ CPU 使用量 • External Metrics ◦ CCU (同時視聴者数) や HTTP/gRPC リクエスト数 ユーザー行動に基づいたオートスケール 21 スパイク アクセス CCU API RPS 大規模なユーザーが視聴中 CDN に負荷が集中する期間 CDN に負荷が集中する期間 大規模なユーザーが視聴中 後半戦 45min 前半戦 45min CCU ★ ハーフタイム 15min ★
  13. HPA で External Metrics を扱う場合、高い信頼性が求められる Cloud Monitoring に External Metrics

    を格納し、Stackdriver Adapter 経由で参照 External Metrics の信頼性担保 22  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 Auto Scaling Fetching Metrics
  14. 人気番組によるピーキーな流入 • 毎週月曜 21 時に「今日、好きになりました。」の放送開始 • 放送開始に合わせて同時視聴者数が、約 5 倍に跳ね上がる •

    負荷係数に応じたオートスケールでは、Pod も Node も間に合わない • 担当者が手動でスケールアウト・インを行っていた 従来の HPA 構成における課題 23 人気番組 月曜日の CCU ( 同時視聴者数 ) 変化 5x
  15. KEDA の Cron Scaler と Prometheus Scaler によるオートスケールを実現 • KEDA

    ◦ Kubernetes Event-driven Autoscaling ◦ 様々な Scaler によって柔軟なオートスケールを実現 • Cron Scaler ◦ External Metrics ( 時間帯 ) に対応 ◦ 人気番組に向けた手動スケール対応を自動化 • Prometheus Scaler ◦ External Metrics ( CCU や HTTP/gRPC RPS ) に対応 ◦ 従来構成の Stackdriver Adapter の代替として採用 課題解消に向けて 24
  16. Cron Scaler を用いて時間帯に応じた制御 Prometheus Scaler を用いて Cloud Monitoring または Victoria

    Metrics を参照 現在の HPA 構成 25 ※ 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 Auto Scaling
  17. 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 使用率などは省略、各閾値は実際と異なる
  18. 従来の構成 28 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 2022 年の統合監視基盤 • Grafana • Victoria Metrics Cluster • Prometheus Agent Mode
  19. 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 活用強化 30
  20. Grafana / Grafana Loki / Grafana Pyroscope / Grafana Tempo

    / Grafana Alloy 31 vm insert Victria Metrics vm insert Grafana Pyroscope vm insert Grafana Loki Grafana vm insert Grafana Tempo vm insert Promtail vm insert OTel Gateway vm insert Promethes Agent Mode vm insert Grafana Alloy vm insert OTel Collector vm insert Micro Services Scraping Profiles Logs Metrics gRPC / HTTP Grafana 活用強化 Send Trace by ABEMA OTel SDK
  21. 4 Signals (Metrisc, Traces, Logs, Profiles) が繋がっていない • 4 Signals

    を計測しているが、個別に動作し、相関性がない • システム複雑化に向けて、これらのシームレスな探索体験が重要 Grafana 活用強化による課題 32 ※ 引用元: Grafana Labs Traces and telemetry ※ 引用元: CNCF Observability Whitepaper
  22. Grafana 活用強化による課題 33 4 Signals (Metrisc, Traces, Logs, Profiles) が繋がっていない

    • 4 Signals を計測しているが、個別に動作し、相関性がない • システム複雑化に向けて、これらのシームレスな探索体験が重要 更なる大規模イベントに向けて、潜在的な未知の異常を検知したい • 生成 AI 機能は Grafana Cloud (有償) に限られている • システム複雑化に向けて、Anomaly Monitor など異常値検知が重要
  23. Grafana 活用強化による課題 34 4 Signals (Metrisc, Traces, Logs, Profiles) が繋がっていない

    • 4 Signals を計測しているが、個別に動作し、相関性がない • システム複雑化に向けて、これらのシームレスな探索体験が重要 更なる大規模イベントに向けて、潜在的な未知の異常を検知したい • 生成 AI 機能は Grafana Cloud (有償) に限られている • システム複雑化に向けて、Anomaly Monitor など異常値検知が重要 更なる大規模イベントに向けて、大規模なテレメトリー データを効率的に解析したい • 高度な分析体験や、トラブルシュートの支援機能が求められる • システム複雑化に向けて、経験知見が浅い領域でも根本原因を調査できる能力が重要
  24. 2024 年から OpenTelemetry をベースとした SaaS 連携の強化 • OpenTelemetry ◦ OTel

    に準拠した 内製トレース SDK を刷新 ◦ Micro Services への導入を進め、計測データの実装を強化 ◦ 特定ベンダーに依存した実装ではなく、OTel 準拠で汎用性を高めている SaaS 連携強化 35 ※ 引用元: opentelemetry.io ※ 引用元: ABEMA Trace SDK ( Internal )
  25. 2024 年から OpenTelemetry をベースとした SaaS 連携の強化 • OpenTelemetry ◦ OTel

    に準拠した 内製トレース SDK を刷新 ◦ Micro Services への導入を進め、計測データの実装を強化 ◦ 特定ベンダーに依存した実装ではなく、OTel 準拠で汎用性を高めている • SaaS 活用の加速化 ◦ Honeycomb による大規模なトレースの効果的な分析手法を整備 ◦ Datadog による 4 Signals のシームレスな探索体験と異常検知を整備 ◦ OTel 準拠 SaaS は、既存実装を変えることなく導入可能な構成を実現 SaaS 連携強化 36
  26. Grafana + SaaS 構成 本番環境での実用性評価 37 vm insert Victria Metrics

    vm insert Grafana Pyroscope vm insert Grafana Loki Grafana vm insert Grafana Tempo vm insert Promtail vm insert OTel Gateway vm insert Promethes Agent Mode vm insert Grafana Alloy vm insert OTel Collector vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent vm insert OTel Collector Datadog Honeycomb   Spans    Metrics / Logs    Events  Scraping Profiles Logs Metrics gRPC / HTTP SaaS 連携強化 Send Trace by ABEMA OTel SDK Scraping Metrics / Logs 
  27. 従来の Grafana Tempo、Loki、Pyroscope は退役 全体を通して OTel に準拠した Monitoring & Observability

    基盤 38 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 年分のメトリクスを格納
  28. 従来の Grafana Tempo、Loki、Pyroscope は退役 全体を通して OTel に準拠した Monitoring & Observability

    基盤 Tail-based Sampling による分析精度を落とさずに SaaS コスト制御を実現 39 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 
  29. インフラコストの約 7% を Monitoring & Observability に投資する合意形成 • SaaS 活用の方針

    ◦ 統合監視基盤に不足している Observability を補う ◦ 4 Signals のシームレスな探索体験や AI による異常検知などの洞察 • 統合監視基盤の方針 ◦ SaaS 優位性に意味を持たないデータの汎用的な監視基盤 ◦ プラット フォーム (例: Kubernetes Capacity、HTTP/gRPC RPS) や運用業務 (例: CCU、WAF、SLI/SLO) Monitoring & Observability 戦略 41
  30. インフラコストの約 7% を Monitoring & Observability に投資する合意形成 • SaaS 活用の方針

    ◦ 統合監視基盤に不足している Observability を補う ◦ 4 Signals のシームレスな探索体験や AI による異常検知などの洞察 • 統合監視基盤の方針 ◦ SaaS 優位性に意味を持たないデータの汎用的な監視基盤 ◦ プラット フォーム (例: Kubernetes Capacity、HTTP/gRPC RPS) や運用業務 (例: CCU、WAF、SLI/SLO) • 統合監視基盤の最適化によって、全体の投資額を変えない ◦ 経過時間に応じてメトリクス保管方法を最適化 ▪ 直近 6 ヶ月は応答速度を重視 ▪ 以後は、いくつかの制約を加えた低コストを重視 Monitoring & Observability 戦略 42
  31. アプリケーション領域は SaaS 活用 プラットフォーム領域は直近6ヶ月未満は Victria Metrics、以後は Thanos を参照 43 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 
  32. Platform Strategy について主要な取り組みについて紹介しました • クラウド活用戦略 ◦ 従来の基本戦略を継続 ◦ Multi CDN

    / Cloud / Region を適材適所に組み合わせ、透過的活用を実現 • キャパシティ戦略の変遷 ◦ 従来のオートスケール戦略を強化 ◦ KEDA の Cron Scaler と Prometheus Scaler による柔軟なスケーリングを実現 まとめ 46
  33. Platform Strategy について主要な取り組みについて紹介しました • クラウド活用戦略 ◦ 従来の基本戦略を継続 ◦ Multi CDN

    / Cloud / Region を適材適所に組み合わせ、透過的活用を実現 • キャパシティ戦略の変遷 ◦ 従来のオートスケール戦略を強化 ◦ KEDA の Cron Scaler と Prometheus Scaler による柔軟なスケーリングを実現 • Monitoring & Observability 戦略の変遷 ◦ 更なる大規模イベントに向けて統合監視基盤は縮退し SaaS 活用を加速 ◦ OpenTelemetry をベースに、複数 SaaS へ柔軟に拡張可能な構成を実現 まとめ 47