不確実性に備える ABEMA の信頼性設計とオブザーバビリティ基盤

2025/11/21 アーキテクチャConference 2025 の登壇資料です。

多様な視聴スタイルとイベント性の高い番組が混在する ABEMA では、予測困難な負荷や障害に常に備える必要があります。本セッションでは、オブザーバビリティを「不確実性への備え」と位置づけ、どのように信頼性設計と統合してきたかを紹介します。リアルタイム性やスケーラビリティを支える技術選定や刷新の経緯、設計における意思決定の裏側、そして今後の挑戦についても具体的にお伝えします。

Transcript

1. AbemaTV, Inc. All Rights Reserved
 1 不確実性に備える ABEMA の信頼性設計と Observability 基盤 Nov 21, アーキテクチャ Conference 2025 永岡 克利 / 山本 哲也 Product Div, Development Headquarters, AbemaTV, Inc.
2. 1 ABEMA について Index 2 Platform 戦略 Cloud Architecture Observability 戦略の変遷 3 Observability 実践 現在の基盤紹介 基盤の事前準備・構築・運用 不確実性に備える ABEMA の 信頼性設計とオブザーバビリティ基盤
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
 7
8. AbemaTV, Inc. All Rights Reserved
 8 Platform 戦略 2
9. 2011 年 - 株式会社 サイバーエージェント入社 2017 年 - 株式会社 AbemaTV に参画 ABEMA では Platform Backend Team のテックリードを 経て、2019 年より Cloud Platform Team のマネー ジャーとしてクラウド ソリューションを、2024 年より セキュリティを担当。 2025 年 10 月より Product Backend & Platform 領域の 責任者を務める。 永岡 克利 Principal Platform Engineer Head of Product Backend & Platform, Development Headquarters, AbemaTV Inc. CyberAgent Developer Experts Cloud Architect スピーカー紹介 9 @na_ga
10. Cloud Architecture 10 10
11. Elemental MediaPackage High Level Cloud Architecture 11 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 　
12. マネージド サービスの発展性が高いものを用いてハイブリッドで利用する • 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) マルチ クラウド 12
13. マルチ リージョン 配信システムとユーザー システムで、マルチ リージョンの用途が異なる • AWS : 配信システム ◦ 東京 + 大阪 + ソウル ◦ 信頼性を最重視し、主要経路はリージョン内で完結する ◦ 特定リージョンで問題が起きても配信を続けられる • Google Cloud : ユーザー システム ◦ 東京 + 大阪 + 台湾 ◦ 拡張性を最重視し、一部経路はリージョン間通信が生じる ◦ 日本国内のキャパシティ不足時は、台湾リージョンに拡張する 13
14. 透過的活用 クラウドの差分を意識することなく利用できるプラット フォーム • Kubernetes を中心としたマイクロ サービス アーキテクチャ ◦ EKS (Elastic Kubernetes Service) & GKE (Google Kubernetes Engine) ◦ Add-on を駆使し、同じように利用できる環境を整備 ◦ Prometheus + VictoriaMetrics + Grafana による統合監視基盤 • Kubernetes + Service Mesh によるサービス間通信の信頼性向上 ◦ App Mesh & Cloud Service Mesh ◦ Circuit Breaker, Outlier Detection (Destination Rule) による影響範囲の最小化 ◦ 応答時間/コードに応じた Auto Retry (Virtual Service) による回復性を担保 ◦ Traffic Mirroring (Virtual Service) による本番環境での負荷試験と障害注入試験 14
15. Observability 戦略の変遷 15 15
16. 2022 年の統合監視基盤 • Grafana • VictoriaMetrics Cluster • Prometheus Agent Mode • Cloud Trace 従来の構成 16 vm insert Victria Metrics vm insert Prometheus Agent Mode vm insert Micro Services Scraping Metrics vmstorage gRPC / HTTP vminsert vmselect 過去 3 年分のメトリクスを格納 Grafana Grafana Cloud Trace Send Trace by Cloud Service Mesh
17. システムの複雑化 • 年々増加かつ、開発速度向上の副作用により加速傾向 • 経験や知見が浅い領域において根本原因に辿り着くまでに時間がかかる 統合監視基盤の課題 17 2018 年 2020 年 2023 年 ( 2 年経過 ) ( 3 年経過 ) ※ Promviz によるサービス間通信の可視化
18. 分散トレーシングの課題 18 vm insert Pod video-clip vm insert Pod api vm insert Pod comment Cloud Trace Send Trace by Cloud Service Mesh apiVersion: v1 kind: ConfigMap metadata: name: istio-asm-managed namespace: istio-system data: mesh: | defaultConfig: tracing: stackdriver: {} sampling: 0 CSM Global Setting annotations: proxy.istio.io/config: | tracing: stackdriver: {} sampling: 0.05 　Override Sampling Rate　 Sampling 0.00% Sampling 0.00% Sampling 0.05% Sidecar Injection by Admission Webhook 　GKE　 NS: istio-system　 NS: chat　 コストと情報量のトレードオフ • Head-based Sampling で「本当に欲しいトレース」が欠如
19. 2022 年の統合監視基盤 • Grafana • VictoriaMetrics 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 活用強化 19
20. Grafana / Grafana Loki / Grafana Pyroscope / Grafana Tempo / Grafana Alloy 20 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 Prometheus 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 (Metrics, Traces, Logs, Profiles) が繋がっていない • 4 Signals を計測しているが、これらをつなげる開発工数が高い • システム複雑化に向けて、これらのシームレスな探索体験が重要 Grafana 活用強化による課題 21 ※ 引用元: Grafana Labs Traces and telemetry ※ 引用元: CNCF Observability Whitepaper
22. Grafana 活用強化による課題 22 4 Signals (Metrics, Traces, Logs, Profiles) が繋がっていない • 4 Signals を計測しているが、これらをつなげる開発工数が高い • システム複雑化に向けて、これらのシームレスな探索体験が重要 更なる大規模イベントに向けて、潜在的な未知の異常を検知したい • 生成 AI 機能は Grafana Cloud (有償) に限られている • システム複雑化に向けて、Anomaly Monitor など異常値検知が重要
23. Grafana 活用強化による課題 23 4 Signals (Metrics, Traces, Logs, Profiles) が繋がっていない • 4 Signals を計測しているが、これらをつなげる開発工数が高い • システム複雑化に向けて、これらのシームレスな探索体験が重要 更なる大規模イベントに向けて、潜在的な未知の異常を検知したい • 生成 AI 機能は Grafana Cloud (有償) に限られている • システム複雑化に向けて、Anomaly Monitor など異常値検知が重要 更なる大規模イベントに向けて、大規模なテレメトリー データを効率的に解析したい • 高度な分析体験や、トラブルシュートの支援機能が求められる • システム複雑化に向けて、経験知見が浅い領域でも根本原因を調査できる能力が重要
24. 2024 年から OpenTelemetry をベースとした SaaS 連携の強化 • OpenTelemetry ◦ OTel に準拠した 内製トレース SDK を刷新 ◦ Micro Services への導入を進め、計測データの実装を強化 ◦ 特定ベンダーに依存した実装ではなく、OTel 準拠で汎用性を高めている SaaS 連携強化 24 ※ 引用元: opentelemetry.io ※ 引用元: ABEMA Trace SDK ( Internal )
25. 2024 年から OpenTelemetry をベースとした SaaS 連携の強化 • OpenTelemetry ◦ OTel に準拠した 内製トレース SDK を刷新 ◦ Micro Services への導入を進め、計測データの実装を強化 ◦ 特定ベンダーに依存した実装ではなく、OTel 準拠で汎用性を高めている • SaaS 活用の加速化 ◦ Honeycomb による大規模なトレースの効果的な分析手法を整備 ◦ Datadog による 4 Signals のシームレスな探索体験と異常検知を整備 ◦ OTel 準拠 SaaS は、既存実装を変えることなく導入可能な構成を実現 SaaS 連携強化 25
26. Grafana + SaaS 構成 本番環境で実用性評価 26 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 Prometheus 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 / Profiles 　 Events　 Scraping Profiles Logs Metrics gRPC / HTTP SaaS 連携強化 Send Trace by ABEMA OTel SDK Scraping Metrics / Logs / Profiles　
27. 従来の Grafana Tempo、Loki、Pyroscope は退役 全体を通して OTel に準拠した Monitoring & Observability 基盤 27 vm insert Victria Metrics Grafana vm insert OTel Gateway vm insert Prometheus Agent Mode vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent vm insert OTel Collector Datadog Honeycomb 　 Spans　 　 Events　 Scraping Metrics gRPC / HTTP SaaS 連携強化 Send Trace by ABEMA OTel SDK 過去 3 年分のメトリクスを格納 Scraping Metrics / Logs / Profiles　 　 Metrics / Logs / Profiles
28. 従来の Grafana Tempo、Loki、Pyroscope は退役 全体を通して OTel に準拠した Monitoring & Observability 基盤 Tail-based Sampling による分析精度を落とさずに SaaS コスト制御を実現 28 vm insert Victria Metrics Grafana vm insert OTel Gateway vm insert Prometheus Agent Mode vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent vm insert OTel Collector Datadog Honeycomb 　 Spans　 　 Events　 Scraping Metrics gRPC / HTTP SaaS 連携強化 Send Trace by ABEMA OTel SDK 過去 3 年分のメトリクスを格納 　 Tail-based　 　 Sampling　 　 Metrics / Logs / Profiles Scraping Metrics / Logs / Profiles　
29. SaaS 連携によってコストは増加します！ 　　　… っと言っても、そんなに簡単に許されるわけ、、ないですよね コスト 29
30. インフラコストの約 7% を Monitoring & Observability に投資する合意形成 • SaaS 活用の方針 ◦ 統合監視基盤に不足している Observability を補う ◦ 4 Signals のシームレスな探索体験や AI による異常検知などの洞察 • 統合監視基盤の方針 ◦ SaaS 優位性に意味を持たないデータの汎用的な監視基盤 ◦ プラット フォーム (例: Kubernetes Capacity、HTTP/gRPC RPS) や運用業務 (例: CCU、WAF、SLI/SLO) Monitoring & Observability 戦略 30
31. アプリケーション領域は SaaS 活用 プラットフォーム領域は直近６ヶ月未満は VictriaMetrics、以後は Thanos を参照 31 vm insert Victria Metrics Grafana vm insert OTel Gateway vm insert Prometheus Agent Mode vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent vm insert OTel Collector Datadog Honeycomb 　 Spans　 　 Events　 Scraping gRPC / HTTP 現在の構成 vm insert Thanos GCS 6 ヶ月未満 6 ヶ月以降 Metrics Send Trace by ABEMA OTel SDK 　 Tail-based　 　 Sampling　 Scraping Metrics / Logs / Profiles　 　 Metrics / Logs / Profiles
32. 前半 まとめ 32 32
33. Platform 戦略について主要な取り組みについて紹介しました • Cloud Architecture ◦ 従来の基本戦略を継続 ◦ Multi CDN / Cloud / Region を適材適所に組み合わせ、透過的活用を実現 • Monitoring & Observability 戦略の変遷 ◦ 更なる大規模イベントに向けて統合監視基盤は縮退し SaaS 活用を加速 ◦ OpenTelemetry をベースに、複数 SaaS へ柔軟に拡張可能な構成を実現 前半のまとめ 33
34. AbemaTV, Inc. All Rights Reserved
 34 Observability 実践 3
35. 2021 年 - 株式会社 サイバーエージェント入社 2021 年 - 株式会社 AbemaTV に参画 クラウド基盤や監視基盤や CI/CD など基盤周り全般を担当。 大規模イベントの負荷試験やリージョン移設、新しいクラウ ドソリューションの導入などを担当。 2024 年からは Developer Productivity チームの立ち上げや Engineering Manager を兼任しながら、 Observability 基盤 の刷新・構築にコミット。 2025 年 10 月からは SRE チームとして ABEMA 全体の信頼 性の向上をサポートしています。 山本 哲也 Software Engineer SRE, Product Div, Development Headquarters, AbemaTV Inc. スピーカー紹介 35
36. AbemaTV, Inc. All Rights Reserved
 36 1. 現在の Observability 基盤のアーキテクチャ 2. Observability 基盤の構築に向けた準備 2.1. インフラ構成 2.2. 共通 SDK 3. Observability 基盤の構築 4. Observability 基盤の運用 目次
37. AbemaTV, Inc. All Rights Reserved
 37 1. 現在の Observability 基盤のアーキテクチャ 2. Observability 基盤の構築に向けた準備 2.1. インフラ構成 2.2. 共通 SDK 3. Observability 基盤の構築 4. Observability 基盤の運用 目次
38. ( 再掲 ) 2025 年 11 月の ABEMA の Monitoring & Observability 基盤 38 vm insert Victria Metrics Grafana vm insert OTel Gateway vm insert Prometheus Agent Mode vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent vm insert OTel Collector Datadog Honeycomb 　 Spans　 　 Events　 Scraping gRPC / HTTP Monitoring & Observability 基盤 vm insert Thanos GCS 6 ヶ月未満 6 ヶ月以降 Metrics Send Trace by ABEMA OTel SDK 　 Tail-based　 　 Sampling　 Scraping Metrics / Logs / Profiles　 　 Metrics / Logs / Profiles
39. 2025 年頭から Datadog と Honeycomb を用いた Observability 基盤を整備 39 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent vm insert OTel Collector Datadog Honeycomb 　 Spans　 　 Events　 gRPC / HTTP 本日紹介する Observability 基盤の概念図 Send Trace by ABEMA OTel SDK 　 Tail-based　 　 Sampling　 Scraping Metrics / Logs / Profiles　 　 Metrics / Logs / Profiles
40. Observability 基盤のインフラ構成 Datadog Agent Microservice OTel Gateway
41. Observability 基盤のインフラ構成 Datadog Agent OTel Collector Microservice OTel Gateway Honeycomb Refinery
42. Observability 基盤のインフラ構成 Datadog Agent OTel Collector Datadog Microservice OTel Gateway Honeycomb Refinery Honeycomb
43. ABEMA が Observability 基盤を手に入れるまでの道のり ★ ノードプール再設計 ★ Istio の技術的制約の克服 ★ マルチクラウド対応 1 インフラ基盤の整備 ★ コスト削減 3 基盤構築 ★ ポータビリティの確保 ★ プロトコルの統一 ★ 複数 SaaS のサポート 2 SDK の整備
44. AbemaTV, Inc. All Rights Reserved
 44 1. 現在の Observability 基盤のアーキテクチャ 2. Observability 基盤の構築に向けた準備 2.1. インフラ構成 2.2. 共通 SDK 3. Observability 基盤の構築 4. Observability 基盤の運用 目次
45. Observability 導入への課題 - コストと技術的制約 解決しないといけない課題 k8s ノードの 配置戦略 Cloud Service Mesh の 技術的制約 マルチ クラウド環境
46. Observability 導入への課題 - コストと技術的制約 解決しないといけない課題 k8s ノードの 配置戦略 Cloud Service Mesh の 技術的制約 マルチ クラウド環境
47. サービス要件やコスト最適化 ( Bin Packing ) に対応するための構成となっていた • コストを最適化する • 固定 IP などのサービス要件を満たす • オートスケールでキャパシティを確保する 47 2024 年までの k8s ノード配置戦略 300以上のマイクロサービスを支えるマルチクラウドアーキテクチャ戦略 | ABEMA Developer Conference 2021
48. 必要なもののみを監視出来る構成へ ユーザー システムなどの Observability 基盤を利用したいワークロード Observability 用ノードプール 監視が必要なコンポーネントを絞ることでデータ量を削減する 開発者はどちらかのノードプールを選択してワークロードをデプロイする 既存のノードプール
49. ABEMA が Observability 基盤を手に入れるまでの道のり ★ ノードプール再設計 ★ Istio の技術的制約の克服 ★ マルチクラウド対応 1 インフラ基盤の整備 ★ コスト削減 3 基盤構築 ★ ポータビリティの確保 ★ プロトコルの統一 ★ 複数 SaaS のサポート 2 SDK の整備
50. Observability 導入への課題 - インフラ基盤の整備 解決しないといけない課題 k8s ノードの 配置戦略 Cloud Service Mesh の 技術的制約 マルチ クラウド環境
51. Cloud Service Mesh における技術的制約 Cloud Service Mesh では以下の制約がある 1. Traffic Director ( TD ) 実装の Cloud Service Mesh では Cloud Trace しか 利用できない 2. Tail-based Sampling が利用できない
52. Cloud Trace しか利用できない ABEMA が利用している TD 実装の Cloud Service Mesh では Cloud Trace しか利用 できない Istio API を使用する場合のサポートされている機能（マネージド コントロール プレーン） | Cloud Service Mesh
53. Istio で Tail-based Sampling が利用できない Istio による大量のスパンが生成される Microservice Microservice Istio なし Cloud Trace Microservice Istio あり Microservice Istio Istio
54. Observability 導入への課題 - インフラ基盤の整備 Istio のトレースを全て捨てることで合意 • Cloud Trace しか利用できない ◦ ベンダーロックインやコストの観点から許容できない デメリットもある • Istio レイヤーのトレースが取得できない ◦ 実際に ABEMA では Istio レイヤーがボトルネックになることもあった
55. ABEMA が Observability 基盤を手に入れるまでの道のり ★ ノードプール再設計 ★ Istio の技術的制約の克服 ★ マルチクラウド対応 1 インフラ基盤の整備 ★ コスト削減 3 基盤構築 ★ ポータビリティの確保 ★ プロトコルの統一 ★ 複数 SaaS のサポート 2 SDK の整備
56. Observability 導入への課題 - コストと技術的制約 解決しないといけない課題 k8s ノードの 配置戦略 Cloud Service Mesh の 技術的制約 マルチ クラウド環境
57. AWS と Google Cloud へのマルチクラウド対応の要件 当時は AWS X-Ray 、 Google Cloud Trace をそれぞれ利用 Microservice AWS X-Ray Microservice Cloud Trace
58. AWS と Google Cloud へのマルチクラウド対応の要件 当時は AWS X-Ray 、 Google Cloud Trace をそれぞれ利用 Microservice AWS X-Ray Microservice Cloud Trace トレースは 繋がらない
59. AWS と Google Cloud へのマルチクラウド対応の要件 ユーザーシステム・配信システムの境界を超えた Observability 基盤を目指す Microservice OpenTelemetry Microservice OpenTelemetry Datadog Honeycomb
60. ABEMA が Observability 基盤を手に入れるまでの道のり ★ ノードプール再設計 ★ Istio の技術的制約の克服 ★ マルチクラウド対応 1 インフラ基盤の整備 ★ コスト削減 3 基盤構築 ★ ポータビリティの確保 ★ プロトコルの統一 ★ 複数 SaaS のサポート 2 SDK の整備
61. AbemaTV, Inc. All Rights Reserved
 61 1. 現在の Observability 基盤のアーキテクチャ 2. Observability 基盤の構築に向けた準備 2.1. インフラ構成 2.2. 共通 SDK 3. Observability 基盤の構築 4. Observability 基盤の運用 目次
62. 開発者による計装のハードルを取り除く どう計装する？ バージョンは？ 出力先は？ 設定は？ 共通 SDK が あるよ ライブラリは？
63. ABEMA における共通 SDK による計装方針の統一 OpenCensus や Cloud Trace や OpenTelemetry の実装が各所にばらけていた 計装のポータビリティ確保を目的に、全てを OpenTelemetry ベースの実装に統合 ※ 引用元: opentelemetry.io ※ 引用元: ABEMA Trace SDK ( Internal )
64. ABEMA が Observability 基盤を手に入れるまでの道のり ★ ノードプール再設計 ★ Istio の技術的制約の克服 ★ マルチクラウド対応 1 インフラ基盤の整備 ★ コスト削減 3 基盤構築 ★ ポータビリティの確保 ★ プロトコルの統一 ★ 複数 SaaS のサポート 2 SDK の整備
65. コンテキスト伝播プロトコルの統一 B3 ( Multiple Headers ) から W3C に移行 コンテキスト伝播のプロトコルとは？ → W3C / B3 / Google Cloud Trace / X-Ray など 何をしている？ → トレース情報を伝播するための形式 traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
66. コンテキスト伝播プロトコルの統一 B3 ( Multiple Headers ) から W3C に移行 何故 B3 を利用していた？ → 2021 年導入頃は B3 にしか対応していないツールが多かった 何故移行した？ → B3 が対応していない SaaS やツールなどが出てきていた Trace Context
67. ABEMA における共通 SDK の機能要件 これらの背景から、共通 SDK の機能要件を確定 W3C プロトコルを用いた OpenTelemetry 形式で実装し、 データを任意の Observability ツールに送信できること
68. 共通 SDK の特徴 利用者は各種設定をコード上で変更する必要はない • 変更したい項目は全て環境変数で制御できるようになっている ◦ 例 : 有効化・無効化 / サンプリング レート / オブザーバビリティツール / etc. 初期化実装例 環境変数例
69. ABEMA が Observability 基盤を手に入れるまでの道のり ★ ノードプール再設計 ★ Istio の技術的制約の克服 ★ マルチクラウド対応 1 インフラ基盤の整備 ★ コスト削減 3 基盤構築 ★ ポータビリティの確保 ★ プロトコルの統一 ★ 複数 SaaS のサポート 2 SDK の整備
70. 70 ABEMA と、 Honeycomb と Datadog ABEMA では 2 つの Observability ツールを併用しています イベントデータに対して柔軟に クエリベースで分析できる Honeycomb シグナルを連携させ統合的な Observability を担保できる Datadog
71. 71 Observability 基盤の構築 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent Datadog Honeycomb 　 Spans　 　 Events　 Send Trace by ABEMA OTel SDK 　 Tail-based　 　 Sampling　 vm insert OTel Collector 複数箇所にエクスポートする必要がある
72. 共通 SDK から OTel Gateway と DDOT へとダブルライト OTel SDK の内部処理における Exporter を複数設定する 72 Observability 基盤の構築 Span Span Processor Exporter Exporter https://opentelemetry.io/docs/specs/otel/trace/sdk
73. Span Span Processor Exporter Exporter 共通 SDK から OTel Gateway と DDOT へとダブルライト OTel SDK の内部処理における Exporter を複数設定する 73 Observability 基盤の構築
74. ABEMA が Observability 基盤を手に入れるまでの道のり ★ ノードプール再設計 ★ Istio の技術的制約の克服 ★ マルチクラウド対応 1 インフラ基盤の整備 ★ コスト削減 3 基盤構築 ★ ポータビリティの確保 ★ プロトコルの統一 ★ 複数 SaaS のサポート 2 SDK の整備
75. AbemaTV, Inc. All Rights Reserved
 75 1. 現在の Observability 基盤のアーキテクチャ 2. Observability 基盤の構築に向けた準備 2.1. インフラ構成 2.2. 共通 SDK 3. Observability 基盤の構築 4. Observability 基盤の運用 目次
76. ( 再掲 ) Observability 基盤 76 Observability 基盤の構築 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent Datadog Honeycomb 　 Spans　 　 Events　 Send Trace by ABEMA OTel SDK 　 Tail-based　 　 Sampling　 vm insert OTel Collector
77. 2 つのツールを利用しつつも コストを予算 ( インフラコストの 7% ) 以内に収める 77 Observability 基盤に対する非機能要件
78. 2 つのツールを利用しつつも コストを予算 ( インフラコストの 7% ) 以内に収める 78 Observability 基盤に対する非機能要件 💸 💸 💸 ABEMA のデータ量を全て取得することはできない サンプリングする必要がある
79. サンプリングの手法 Head-based Sampling 確率サンプリング • X% のサンプリングレート Tail-based Sampling 条件付きサンプリング • エラーを含む • レイテンシーの高い 比較的簡単に利用できる 自由度は高いが運用工数も高い
80. Head-based Sampling の課題 Cloud Trace 利用時は、 Head-based Sampling を実施 負荷試験 統計的な情報で対応できる 欲しい情報が見れない 障害対応
81. サンプリングの手法 Head-based Sampling 確率サンプリング • x% のサンプリングレート Tail-based Sampling 条件付きサンプリング • エラーを含む • レイテンシーの高い 比較的簡単に利用できる 自由度は高いが運用工数も高い
82. Tail-based Sampling 82 Head-based Sampling から Tail-based Sampling へ vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent Datadog Honeycomb 　 Spans　 　 Events　 Send Trace by ABEMA OTel SDK 　 Tail-based　 　 Sampling　 vm insert OTel Collector
83. Tail-based Sampling とは 異常系 正常系 レイテンシー 時刻 トレース全体に含まれるスパンの情報を考慮してサンプリングする手法 Head-based Sampling とは異なり欲しい情報だけを残すことができる
84. Tail-based Sampling とは Head-based Sampling だと欲しいデータを拾えるかは分からない 異常系 正常系 レイテンシー 時刻
85. Tail-based Sampling とは Tail-based Sampling だと欲しいデータを意図的にサンプリングすることができる 異常系のトレース レイテンシーが高いトレース 異常系 正常系 レイテンシー 時刻
86. Tail-based Sampling とは 実際に ABEMA でどのように Tail-based Sampling を行っているか ピーク時165万スパン/秒に立ち向かえ！オブザーバビリティコストを効率化する ABEMA におけるトレースサンプリングの実践的事例
87. その結果 トレースデータ量を 1/10 以下まで削減 Tail-based Sampling を活用したコストの削減 2024 年から本格的に Tail-based Sampling の検証を開始 2024 年上半期、 OpenTelemetry Collector / Refinery を用いた Tail-based Sampling の本番運用を確立 Honeycomb Refinery 日次スパン数 月間累積スパン数
88. ABEMA が Observability 基盤を手に入れるまでの道のり ★ ノードプール再設計 ★ Istio の技術的制約の克服 ★ マルチクラウド対応 1 インフラ基盤の整備 ★ コスト削減 3 基盤構築 ★ ポータビリティの確保 ★ プロトコルの統一 ★ 複数 SaaS のサポート 2 SDK の整備
89. ( 再掲 ) 89 Observability 基盤の構築 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent Datadog Honeycomb 　 Spans　 　 Events　 Send Trace by ABEMA OTel SDK vm insert OTel Collector 　 Tail-based　 　 Sampling　
90. 共通 SDK から OTel Gateway と DDOT へとダブルライト OTel Gateway = Honeycomb 用の OpenTelemetry Collector DDOT = Datadog Distribution of OpenTelemetry Collector 90 Observability 基盤の構築 vm insert OTel Gateway vm insert Micro Services vm insert DDOT Datadog Agent Send Trace by ABEMA OTel SDK datadog-distribution-of-opentelemetry-collector-intro - Speaker Deck
91. OTel Gateway → Refinery へとトレースを送信、 Refinery で Tail-based Sampling を実行 91 Honeycomb へのデータ送信 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent Send Trace by ABEMA OTel SDK 　 Tail-based　 　 Sampling　
92. 92 Refinery とは Honeycomb が開発しているトレースの Tail-based Sampling に特化したツール 様々なサンプリング手法をサポート https://docs.honeycomb.io/manage-data-volume/sample/honeycomb-refinery/
93. 93 Refinery とは Honeycomb が開発しているトレースの Tail-based Sampling に特化したツール 様々なサンプリング手法をサポート https://docs.honeycomb.io/manage-data-volume/sample/honeycomb-refinery/ Dynamic sampling 自動で閾値などを判断する Tail-based Sampling
94. 94 Refinery とは Honeycomb が開発しているトレースの Tail-based Sampling に特化したツール 様々なサンプリング手法をサポート https://docs.honeycomb.io/manage-data-volume/sample/honeycomb-refinery/ Dynamic sampling 自動で閾値などを判断する Tail-based Sampling Rules-based sampling 一般的なルールベースの Tail-based Sampling
95. 95 Refinery とは Honeycomb が開発しているトレースの Tail-based Sampling に特化したツール 様々なサンプリング手法をサポート https://docs.honeycomb.io/manage-data-volume/sample/honeycomb-refinery/ Dynamic sampling 自動で閾値などを判断する Tail-based Sampling Throughput-based sampling 秒間の上限を設定してサンプリング Rules-based sampling 一般的なルールベースの Tail-based Sampling
96. 96 Refinery とは Honeycomb が開発しているトレースの Tail-based Sampling に特化したツール 様々なサンプリング手法をサポート https://docs.honeycomb.io/manage-data-volume/sample/honeycomb-refinery/ Dynamic sampling 自動で閾値などを判断する Tail-based Sampling Throughput-based sampling 秒間の上限を設定してサンプリング Deterministic probability sampling 一般的なトレース ID による Head-based Sampling Rules-based sampling 一般的なルールベースの Tail-based Sampling
97. 97 Honeycomb へのデータ送信 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Refinery Honeycomb 　 Events　 Send Trace by ABEMA OTel SDK 　 Tail-based　 　 Sampling　 vm insert DDOT Datadog Agent Refinery で Tail-based Sampling した結果を Honeycomb へと送信
98. DDOT から全てのトレースを一度 Otel Collector に送信し、 Otel Collector で Tail-based Sampling を実行 98 Datadog へのデータ送信 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent Honeycomb 　 Events　 Send Trace by ABEMA OTel SDK 　 Tail-based　 　 Sampling　 vm insert OTel Collector
99. 99 Datadog へのデータ送信 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Refinery vm insert DDOT Datadog Agent Datadog Honeycomb 　 Spans　 　 Events　 Send Trace by ABEMA OTel SDK 　 Tail-based　 　 Sampling　 vm insert OTel Collector Otel Collector で Tail-based Sapling した結果を Datadog へと送信
100. AbemaTV, Inc. All Rights Reserved
 100 1. 現在の Observability 基盤のアーキテクチャ 2. Observability 基盤の構築に向けた準備 2.1. インフラ構成 2.2. 共通 SDK 3. Observability 基盤の構築 4. Observability 基盤の運用 目次
101. Observability 基盤の利用率 ABEMA のユーザシステムのほぼ全てのマイクロサービスがこの基盤を利用している • ほぼ全ての GKE ノードへの展開 • 100+ のマイクロサービスへの導入 毎秒 165 万スパンという大量のデータを問題なく処理し、 ABEMA の Observability を支えている
102. 負荷試験環境での利用実績 負荷試験ではコスパ良く、統計情報を元にボトルネックを把握したい → Refinery + Honeycomb のみ利用 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Refinery Honeycomb 　 Events　 Send Trace by ABEMA OTel SDK ABEMAの本番環境負荷試験への挑戦 - Speaker Deck
103. 負荷試験環境での利用実績 Throughput-based sampling を利用することで、どんな流量でも上限を設けたまま トレースを取得することができる vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Refinery Honeycomb 　 Events　 Send Trace by ABEMA OTel SDK Throughput-based sampling
104. 104 後半のまとめ Observability 実践 • ABEMA としての Platform & Observability 戦略を支える基盤について ◦ Observability 基盤の整備に先駆けて、インフラ基盤から刷新 ◦ Observability 基盤に対する機能要件・非機能要件の整理 ◦ ABEMA 規模で数年間問題なく稼働させるための技術的検証