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

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

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. AbemaTV, Inc. All Rights Reserved
 3 ABEMA について 1
4. AbemaTV, Inc. All Rights Reserved

5. AbemaTV, Inc. All Rights Reserved

6. AbemaTV, Inc. All Rights Reserved

7. AbemaTV, Inc. All Rights Reserved

8. AbemaTV, Inc. All Rights Reserved
 8 Platform Strategy 2
9. 永岡 克利 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
10. 基本戦略は大きく変えず、2023 年から 2 年間で何を取り組んできたか 関連資料 10 2023/05/25 Google Cloud Days ‘23 東京 2023/06/09 Jagu’e’r クラウドネイティブ分科会
11. クラウド活用戦略 11 11
12. 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 　
13. マルチ 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
14. マネージド サービスの発展性が高いものを用いてハイブリッドで利用する • 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
15. マルチ リージョン 配信システムとユーザー システムで、マルチ リージョンの用途が異なる • AWS : 配信システム ◦ 東京 + 大阪 + ソウル ◦ 信頼性を最重視し、主要経路はリージョン内で完結する ◦ 特定リージョンで問題が起きても配信を続けられる • Google Cloud : ユーザー システム ◦ 東京 + 大阪 + 台湾 ◦ 拡張性を最重視し、一部経路はリージョン間通信が生じる ◦ 日本国内のキャパシティ不足時は、台湾リージョンに拡張する 15
16. 透過的活用 クラウドの差分を意識することなく利用できるプラット フォーム • 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
17. キャパシティ戦略の変遷 17 17
18. 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 　
19. 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 負荷分散、流入制限、画質制御が重要
20. ユーザー システムへの負荷は 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 　
21. Kubernetes の HPA (Horizontal Pod Autoscaler) を用いて スパイク アクセス に対応 • Resource Metrics ◦ CPU 使用量 • External Metrics ◦ CCU (同時視聴者数) や HTTP/gRPC リクエスト数 ユーザー行動に基づいたオートスケール 21 スパイク アクセス CCU API RPS 大規模なユーザーが視聴中 CDN に負荷が集中する期間 CDN に負荷が集中する期間 大規模なユーザーが視聴中 後半戦 45min 前半戦 45min CCU ★ ハーフタイム 15min ★
22. 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
23. 人気番組によるピーキーな流入 • 毎週月曜 21 時に「今日、好きになりました。」の放送開始 • 放送開始に合わせて同時視聴者数が、約 5 倍に跳ね上がる • 負荷係数に応じたオートスケールでは、Pod も Node も間に合わない • 担当者が手動でスケールアウト・インを行っていた 従来の HPA 構成における課題 23 人気番組 月曜日の CCU ( 同時視聴者数 ) 変化 5x
24. 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
25. 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
26. 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 使用率などは省略、各閾値は実際と異なる
27. Monitoring & Observability 戦略の変遷 27 27
28. 従来の構成 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
29. システムの複雑化 • 年々増加かつ、開発速度向上の副作用により加速傾向 • 経験や知見が浅い領域において根本原因に辿り着くまでに時間がかかる 統合監視基盤の課題 29 2018 年 2020 年 2023 年 ( 2 年経過 ) ( 3 年経過 ) ※ Promviz によるサービス間通信の可視化
30. 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
31. 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
32. 4 Signals (Metrisc, Traces, Logs, Profiles) が繋がっていない • 4 Signals を計測しているが、個別に動作し、相関性がない • システム複雑化に向けて、これらのシームレスな探索体験が重要 Grafana 活用強化による課題 32 ※ 引用元: Grafana Labs Traces and telemetry ※ 引用元: CNCF Observability Whitepaper
33. Grafana 活用強化による課題 33 4 Signals (Metrisc, Traces, Logs, Profiles) が繋がっていない • 4 Signals を計測しているが、個別に動作し、相関性がない • システム複雑化に向けて、これらのシームレスな探索体験が重要 更なる大規模イベントに向けて、潜在的な未知の異常を検知したい • 生成 AI 機能は Grafana Cloud (有償) に限られている • システム複雑化に向けて、Anomaly Monitor など異常値検知が重要
34. Grafana 活用強化による課題 34 4 Signals (Metrisc, Traces, Logs, Profiles) が繋がっていない • 4 Signals を計測しているが、個別に動作し、相関性がない • システム複雑化に向けて、これらのシームレスな探索体験が重要 更なる大規模イベントに向けて、潜在的な未知の異常を検知したい • 生成 AI 機能は Grafana Cloud (有償) に限られている • システム複雑化に向けて、Anomaly Monitor など異常値検知が重要 更なる大規模イベントに向けて、大規模なテレメトリー データを効率的に解析したい • 高度な分析体験や、トラブルシュートの支援機能が求められる • システム複雑化に向けて、経験知見が浅い領域でも根本原因を調査できる能力が重要
35. 2024 年から OpenTelemetry をベースとした SaaS 連携の強化 • OpenTelemetry ◦ OTel に準拠した 内製トレース SDK を刷新 ◦ Micro Services への導入を進め、計測データの実装を強化 ◦ 特定ベンダーに依存した実装ではなく、OTel 準拠で汎用性を高めている SaaS 連携強化 35 ※ 引用元: opentelemetry.io ※ 引用元: ABEMA Trace SDK ( Internal )
36. 2024 年から OpenTelemetry をベースとした SaaS 連携の強化 • OpenTelemetry ◦ OTel に準拠した 内製トレース SDK を刷新 ◦ Micro Services への導入を進め、計測データの実装を強化 ◦ 特定ベンダーに依存した実装ではなく、OTel 準拠で汎用性を高めている • SaaS 活用の加速化 ◦ Honeycomb による大規模なトレースの効果的な分析手法を整備 ◦ Datadog による 4 Signals のシームレスな探索体験と異常検知を整備 ◦ OTel 準拠 SaaS は、既存実装を変えることなく導入可能な構成を実現 SaaS 連携強化 36
37. 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　
38. 従来の 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 年分のメトリクスを格納
39. 従来の 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　
40. SaaS 連携によってコストは増加します！ 　　　… っと言っても、そんなに簡単に許されるわけ、、ないですよね コスト 40
41. インフラコストの約 7% を Monitoring & Observability に投資する合意形成 • SaaS 活用の方針 ◦ 統合監視基盤に不足している Observability を補う ◦ 4 Signals のシームレスな探索体験や AI による異常検知などの洞察 • 統合監視基盤の方針 ◦ SaaS 優位性に意味を持たないデータの汎用的な監視基盤 ◦ プラット フォーム (例: Kubernetes Capacity、HTTP/gRPC RPS) や運用業務 (例: CCU、WAF、SLI/SLO) Monitoring & Observability 戦略 41
42. インフラコストの約 7% を Monitoring & Observability に投資する合意形成 • SaaS 活用の方針 ◦ 統合監視基盤に不足している Observability を補う ◦ 4 Signals のシームレスな探索体験や AI による異常検知などの洞察 • 統合監視基盤の方針 ◦ SaaS 優位性に意味を持たないデータの汎用的な監視基盤 ◦ プラット フォーム (例: Kubernetes Capacity、HTTP/gRPC RPS) や運用業務 (例: CCU、WAF、SLI/SLO) • 統合監視基盤の最適化によって、全体の投資額を変えない ◦ 経過時間に応じてメトリクス保管方法を最適化 ▪ 直近 6 ヶ月は応答速度を重視 ▪ 以後は、いくつかの制約を加えた低コストを重視 Monitoring & Observability 戦略 42
43. アプリケーション領域は SaaS 活用 プラットフォーム領域は直近６ヶ月未満は 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　
44. まとめ 44 44
45. Platform Strategy について主要な取り組みについて紹介しました • クラウド活用戦略 ◦ 従来の基本戦略を継続 ◦ Multi CDN / Cloud / Region を適材適所に組み合わせ、透過的活用を実現 まとめ 45
46. Platform Strategy について主要な取り組みについて紹介しました • クラウド活用戦略 ◦ 従来の基本戦略を継続 ◦ Multi CDN / Cloud / Region を適材適所に組み合わせ、透過的活用を実現 • キャパシティ戦略の変遷 ◦ 従来のオートスケール戦略を強化 ◦ KEDA の Cron Scaler と Prometheus Scaler による柔軟なスケーリングを実現 まとめ 46
47. Platform Strategy について主要な取り組みについて紹介しました • クラウド活用戦略 ◦ 従来の基本戦略を継続 ◦ Multi CDN / Cloud / Region を適材適所に組み合わせ、透過的活用を実現 • キャパシティ戦略の変遷 ◦ 従来のオートスケール戦略を強化 ◦ KEDA の Cron Scaler と Prometheus Scaler による柔軟なスケーリングを実現 • Monitoring & Observability 戦略の変遷 ◦ 更なる大規模イベントに向けて統合監視基盤は縮退し SaaS 活用を加速 ◦ OpenTelemetry をベースに、複数 SaaS へ柔軟に拡張可能な構成を実現 まとめ 47
48. AbemaTV, Inc. All Rights Reserved