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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

1 ABEMA について Index 2 Platform 戦略 Cloud Architecture Observability 戦略の変遷 3 Observability 実践現在の基盤紹介基盤の事前準備・構築・運用不確実性に備える ABEMA の信頼性設計とオブザーバビリティ基盤

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Cloud Architecture 10 10

Slide 11

Slide 11 text

Elemental MediaPackage High Level Cloud Architecture 11 Cloudﬂare 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 　

Slide 12

Slide 12 text

マネージドサービスの発展性が高いものを用いてハイブリッドで利用する ● 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) ● Cloudﬂare ○ 画像変換 (Workers, Images) ○ 仮想待機室 (Waiting Room) マルチクラウド 12

Slide 13

Slide 13 text

マルチリージョン配信システムとユーザーシステムで、マルチリージョンの用途が異なる ● AWS : 配信システム ○ 東京 + 大阪 + ソウル ○ 信頼性を最重視し、主要経路はリージョン内で完結する ○ 特定リージョンで問題が起きても配信を続けられる ● Google Cloud : ユーザーシステム ○ 東京 + 大阪 + 台湾 ○ 拡張性を最重視し、一部経路はリージョン間通信が生じる ○ 日本国内のキャパシティ不足時は、台湾リージョンに拡張する 13

Slide 14

Slide 14 text

透過的活用クラウドの差分を意識することなく利用できるプラットフォーム ● 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) による回復性を担保 ○ Traﬃc Mirroring (Virtual Service) による本番環境での負荷試験と障害注入試験 14

Slide 15

Slide 15 text

Observability 戦略の変遷 15 15

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

システムの複雑化 ● 年々増加かつ、開発速度向上の副作用により加速傾向 ● 経験や知見が浅い領域において根本原因に辿り着くまでに時間がかかる統合監視基盤の課題 17 2018 年 2020 年 2023 年 ( 2 年経過 ) ( 3 年経過 ) ※ Promviz によるサービス間通信の可視化

Slide 18

Slide 18 text

分散トレーシングの課題 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 で「本当に欲しいトレース」が欠如

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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 Proﬁles Logs Metrics gRPC / HTTP Grafana 活用強化 Send Trace by ABEMA OTel SDK

Slide 21

Slide 21 text

4 Signals (Metrics, Traces, Logs, Proﬁles) が繋がっていない ● 4 Signals を計測しているが、これらをつなげる開発工数が高い ● システム複雑化に向けて、これらのシームレスな探索体験が重要 Grafana 活用強化による課題 21 ※ 引用元: Grafana Labs Traces and telemetry ※ 引用元: CNCF Observability Whitepaper

Slide 22

Slide 22 text

Grafana 活用強化による課題 22 4 Signals (Metrics, Traces, Logs, Proﬁles) が繋がっていない ● 4 Signals を計測しているが、これらをつなげる開発工数が高い ● システム複雑化に向けて、これらのシームレスな探索体験が重要更なる大規模イベントに向けて、潜在的な未知の異常を検知したい ● 生成 AI 機能は Grafana Cloud (有償) に限られている ● システム複雑化に向けて、Anomaly Monitor など異常値検知が重要

Slide 23

Slide 23 text

Grafana 活用強化による課題 23 4 Signals (Metrics, Traces, Logs, Proﬁles) が繋がっていない ● 4 Signals を計測しているが、これらをつなげる開発工数が高い ● システム複雑化に向けて、これらのシームレスな探索体験が重要更なる大規模イベントに向けて、潜在的な未知の異常を検知したい ● 生成 AI 機能は Grafana Cloud (有償) に限られている ● システム複雑化に向けて、Anomaly Monitor など異常値検知が重要更なる大規模イベントに向けて、大規模なテレメトリーデータを効率的に解析したい ● 高度な分析体験や、トラブルシュートの支援機能が求められる ● システム複雑化に向けて、経験知見が浅い領域でも根本原因を調査できる能力が重要

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

2024 年から OpenTelemetry をベースとした SaaS 連携の強化 ● OpenTelemetry ○ OTel に準拠した内製トレース SDK を刷新 ○ Micro Services への導入を進め、計測データの実装を強化 ○ 特定ベンダーに依存した実装ではなく、OTel 準拠で汎用性を高めている ● SaaS 活用の加速化 ○ Honeycomb による大規模なトレースの効果的な分析手法を整備 ○ Datadog による 4 Signals のシームレスな探索体験と異常検知を整備 ○ OTel 準拠 SaaS は、既存実装を変えることなく導入可能な構成を実現 SaaS 連携強化 25

Slide 26

Slide 26 text

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　

Slide 27

Slide 27 text

従来の 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

Slide 28

Slide 28 text

従来の 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　

Slide 29

Slide 29 text

SaaS 連携によってコストは増加します！　　　… っと言っても、そんなに簡単に許されるわけ、、ないですよねコスト 29

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

アプリケーション領域は 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

Slide 32

Slide 32 text

前半まとめ 32 32

Slide 33

Slide 33 text

Platform 戦略について主要な取り組みについて紹介しました ● Cloud Architecture ○ 従来の基本戦略を継続 ○ Multi CDN / Cloud / Region を適材適所に組み合わせ、透過的活用を実現 ● Monitoring & Observability 戦略の変遷 ○ 更なる大規模イベントに向けて統合監視基盤は縮退し SaaS 活用を加速 ○ OpenTelemetry をベースに、複数 SaaS へ柔軟に拡張可能な構成を実現前半のまとめ 33

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

( 再掲 ) 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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Observability 基盤のインフラ構成 Datadog Agent Microservice OTel Gateway

Slide 41

Slide 41 text

Observability 基盤のインフラ構成 Datadog Agent OTel Collector Microservice OTel Gateway Honeycomb Reﬁnery

Slide 42

Slide 42 text

Observability 基盤のインフラ構成 Datadog Agent OTel Collector Datadog Microservice OTel Gateway Honeycomb Reﬁnery Honeycomb

Slide 43

Slide 43 text

ABEMA が Observability 基盤を手に入れるまでの道のり ★ ノードプール再設計 ★ Istio の技術的制約の克服 ★ マルチクラウド対応 1 インフラ基盤の整備 ★ コスト削減 3 基盤構築 ★ ポータビリティの確保 ★ プロトコルの統一 ★ 複数 SaaS のサポート 2 SDK の整備

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Observability 導入への課題 - コストと技術的制約解決しないといけない課題 k8s ノードの配置戦略 Cloud Service Mesh の技術的制約マルチクラウド環境

Slide 46

Slide 46 text

Observability 導入への課題 - コストと技術的制約解決しないといけない課題 k8s ノードの配置戦略 Cloud Service Mesh の技術的制約マルチクラウド環境

Slide 47

Slide 47 text

サービス要件やコスト最適化 ( Bin Packing ) に対応するための構成となっていた ● コストを最適化する ● 固定 IP などのサービス要件を満たす ● オートスケールでキャパシティを確保する 47 2024 年までの k8s ノード配置戦略 300以上のマイクロサービスを支えるマルチクラウドアーキテクチャ戦略 | ABEMA Developer Conference 2021

Slide 48

Slide 48 text

必要なもののみを監視出来る構成へユーザーシステムなどの Observability 基盤を利用したいワークロード Observability 用ノードプール監視が必要なコンポーネントを絞ることでデータ量を削減する開発者はどちらかのノードプールを選択してワークロードをデプロイする既存のノードプール

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Observability 導入への課題 - インフラ基盤の整備解決しないといけない課題 k8s ノードの配置戦略 Cloud Service Mesh の技術的制約マルチクラウド環境

Slide 51

Slide 51 text

Cloud Service Mesh における技術的制約 Cloud Service Mesh では以下の制約がある 1. Traﬃc Director ( TD ) 実装の Cloud Service Mesh では Cloud Trace しか利用できない 2. Tail-based Sampling が利用できない

Slide 52

Slide 52 text

Cloud Trace しか利用できない ABEMA が利用している TD 実装の Cloud Service Mesh では Cloud Trace しか利用できない Istio API を使用する場合のサポートされている機能（マネージドコントロールプレーン） | Cloud Service Mesh

Slide 53

Slide 53 text

Istio で Tail-based Sampling が利用できない Istio による大量のスパンが生成される Microservice Microservice Istio なし Cloud Trace Microservice Istio あり Microservice Istio Istio

Slide 54

Slide 54 text

Observability 導入への課題 - インフラ基盤の整備 Istio のトレースを全て捨てることで合意 ● Cloud Trace しか利用できない ○ ベンダーロックインやコストの観点から許容できないデメリットもある ● Istio レイヤーのトレースが取得できない ○ 実際に ABEMA では Istio レイヤーがボトルネックになることもあった

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Observability 導入への課題 - コストと技術的制約解決しないといけない課題 k8s ノードの配置戦略 Cloud Service Mesh の技術的制約マルチクラウド環境

Slide 57

Slide 57 text

AWS と Google Cloud へのマルチクラウド対応の要件当時は AWS X-Ray 、 Google Cloud Trace をそれぞれ利用 Microservice AWS X-Ray Microservice Cloud Trace

Slide 58

Slide 58 text

AWS と Google Cloud へのマルチクラウド対応の要件当時は AWS X-Ray 、 Google Cloud Trace をそれぞれ利用 Microservice AWS X-Ray Microservice Cloud Trace トレースは繋がらない

Slide 59

Slide 59 text

AWS と Google Cloud へのマルチクラウド対応の要件ユーザーシステム・配信システムの境界を超えた Observability 基盤を目指す Microservice OpenTelemetry Microservice OpenTelemetry Datadog Honeycomb

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

開発者による計装のハードルを取り除くどう計装する？バージョンは？出力先は？設定は？共通 SDK があるよライブラリは？

Slide 63

Slide 63 text

ABEMA における共通 SDK による計装方針の統一 OpenCensus や Cloud Trace や OpenTelemetry の実装が各所にばらけていた計装のポータビリティ確保を目的に、全てを OpenTelemetry ベースの実装に統合 ※ 引用元: opentelemetry.io ※ 引用元: ABEMA Trace SDK ( Internal )

Slide 64

Slide 64 text

Slide 65

Slide 65 text

コンテキスト伝播プロトコルの統一 B3 ( Multiple Headers ) から W3C に移行コンテキスト伝播のプロトコルとは？ → W3C / B3 / Google Cloud Trace / X-Ray など何をしている？ → トレース情報を伝播するための形式 traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01

Slide 66

Slide 66 text

コンテキスト伝播プロトコルの統一 B3 ( Multiple Headers ) から W3C に移行何故 B3 を利用していた？ → 2021 年導入頃は B3 にしか対応していないツールが多かった何故移行した？ → B3 が対応していない SaaS やツールなどが出てきていた Trace Context

Slide 67

Slide 67 text

ABEMA における共通 SDK の機能要件これらの背景から、共通 SDK の機能要件を確定 W3C プロトコルを用いた OpenTelemetry 形式で実装し、データを任意の Observability ツールに送信できること

Slide 68

Slide 68 text

共通 SDK の特徴利用者は各種設定をコード上で変更する必要はない ● 変更したい項目は全て環境変数で制御できるようになっている ○ 例 : 有効化・無効化 / サンプリングレート / オブザーバビリティツール / etc. 初期化実装例環境変数例

Slide 69

Slide 69 text

Slide 70

Slide 70 text

70 ABEMA と、 Honeycomb と Datadog ABEMA では 2 つの Observability ツールを併用していますイベントデータに対して柔軟にクエリベースで分析できる Honeycomb シグナルを連携させ統合的な Observability を担保できる Datadog

Slide 71

Slide 71 text

71 Observability 基盤の構築 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Reﬁnery vm insert DDOT Datadog Agent Datadog Honeycomb 　 Spans　　 Events　 Send Trace by ABEMA OTel SDK 　 Tail-based　　 Sampling　 vm insert OTel Collector 複数箇所にエクスポートする必要がある

Slide 72

Slide 72 text

共通 SDK から OTel Gateway と DDOT へとダブルライト OTel SDK の内部処理における Exporter を複数設定する 72 Observability 基盤の構築 Span Span Processor Exporter Exporter https://opentelemetry.io/docs/specs/otel/trace/sdk

Slide 73

Slide 73 text

Span Span Processor Exporter Exporter 共通 SDK から OTel Gateway と DDOT へとダブルライト OTel SDK の内部処理における Exporter を複数設定する 73 Observability 基盤の構築

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

( 再掲 ) Observability 基盤 76 Observability 基盤の構築 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Reﬁnery vm insert DDOT Datadog Agent Datadog Honeycomb 　 Spans　　 Events　 Send Trace by ABEMA OTel SDK 　 Tail-based　　 Sampling　 vm insert OTel Collector

Slide 77

Slide 77 text

2 つのツールを利用しつつもコストを予算 ( インフラコストの 7% ) 以内に収める 77 Observability 基盤に対する非機能要件

Slide 78

Slide 78 text

2 つのツールを利用しつつもコストを予算 ( インフラコストの 7% ) 以内に収める 78 Observability 基盤に対する非機能要件 💸 💸 💸 ABEMA のデータ量を全て取得することはできないサンプリングする必要がある

Slide 79

Slide 79 text

サンプリングの手法 Head-based Sampling 確率サンプリング ● X% のサンプリングレート Tail-based Sampling 条件付きサンプリング ● エラーを含む ● レイテンシーの高い比較的簡単に利用できる自由度は高いが運用工数も高い

Slide 80

Slide 80 text

Head-based Sampling の課題 Cloud Trace 利用時は、 Head-based Sampling を実施負荷試験統計的な情報で対応できる欲しい情報が見れない障害対応

Slide 81

Slide 81 text

サンプリングの手法 Head-based Sampling 確率サンプリング ● x% のサンプリングレート Tail-based Sampling 条件付きサンプリング ● エラーを含む ● レイテンシーの高い比較的簡単に利用できる自由度は高いが運用工数も高い

Slide 82

Slide 82 text

Tail-based Sampling 82 Head-based Sampling から Tail-based Sampling へ vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Reﬁnery vm insert DDOT Datadog Agent Datadog Honeycomb 　 Spans　　 Events　 Send Trace by ABEMA OTel SDK 　 Tail-based　　 Sampling　 vm insert OTel Collector

Slide 83

Slide 83 text

Tail-based Sampling とは異常系正常系レイテンシー時刻トレース全体に含まれるスパンの情報を考慮してサンプリングする手法 Head-based Sampling とは異なり欲しい情報だけを残すことができる

Slide 84

Slide 84 text

Tail-based Sampling とは Head-based Sampling だと欲しいデータを拾えるかは分からない異常系正常系レイテンシー時刻

Slide 85

Slide 85 text

Tail-based Sampling とは Tail-based Sampling だと欲しいデータを意図的にサンプリングすることができる異常系のトレースレイテンシーが高いトレース異常系正常系レイテンシー時刻

Slide 86

Slide 86 text

Tail-based Sampling とは実際に ABEMA でどのように Tail-based Sampling を行っているかピーク時165万スパン/秒に立ち向かえ！オブザーバビリティコストを効率化する ABEMA におけるトレースサンプリングの実践的事例

Slide 87

Slide 87 text

その結果トレースデータ量を 1/10 以下まで削減 Tail-based Sampling を活用したコストの削減 2024 年から本格的に Tail-based Sampling の検証を開始 2024 年上半期、 OpenTelemetry Collector / Reﬁnery を用いた Tail-based Sampling の本番運用を確立 Honeycomb Refinery 日次スパン数月間累積スパン数

Slide 88

Slide 88 text

Slide 89

Slide 89 text

( 再掲 ) 89 Observability 基盤の構築 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Reﬁnery vm insert DDOT Datadog Agent Datadog Honeycomb 　 Spans　　 Events　 Send Trace by ABEMA OTel SDK vm insert OTel Collector 　 Tail-based　　 Sampling　

Slide 90

Slide 90 text

共通 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

Slide 91

Slide 91 text

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　

Slide 92

Slide 92 text

92 Reﬁnery とは Honeycomb が開発しているトレースの Tail-based Sampling に特化したツール様々なサンプリング手法をサポート https://docs.honeycomb.io/manage-data-volume/sample/honeycomb-reﬁnery/

Slide 93

Slide 93 text

93 Reﬁnery とは Honeycomb が開発しているトレースの Tail-based Sampling に特化したツール様々なサンプリング手法をサポート https://docs.honeycomb.io/manage-data-volume/sample/honeycomb-reﬁnery/ Dynamic sampling 自動で閾値などを判断する Tail-based Sampling

Slide 94

Slide 94 text

94 Reﬁnery とは Honeycomb が開発しているトレースの Tail-based Sampling に特化したツール様々なサンプリング手法をサポート https://docs.honeycomb.io/manage-data-volume/sample/honeycomb-reﬁnery/ Dynamic sampling 自動で閾値などを判断する Tail-based Sampling Rules-based sampling 一般的なルールベースの Tail-based Sampling

Slide 95

Slide 95 text

95 Reﬁnery とは Honeycomb が開発しているトレースの Tail-based Sampling に特化したツール様々なサンプリング手法をサポート https://docs.honeycomb.io/manage-data-volume/sample/honeycomb-reﬁnery/ Dynamic sampling 自動で閾値などを判断する Tail-based Sampling Throughput-based sampling 秒間の上限を設定してサンプリング Rules-based sampling 一般的なルールベースの Tail-based Sampling

Slide 96

Slide 96 text

96 Reﬁnery とは Honeycomb が開発しているトレースの Tail-based Sampling に特化したツール様々なサンプリング手法をサポート https://docs.honeycomb.io/manage-data-volume/sample/honeycomb-reﬁnery/ Dynamic sampling 自動で閾値などを判断する Tail-based Sampling Throughput-based sampling 秒間の上限を設定してサンプリング Deterministic probability sampling 一般的なトレース ID による Head-based Sampling Rules-based sampling 一般的なルールベースの Tail-based Sampling

Slide 97

Slide 97 text

97 Honeycomb へのデータ送信 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Reﬁnery Honeycomb 　 Events　 Send Trace by ABEMA OTel SDK 　 Tail-based　　 Sampling　 vm insert DDOT Datadog Agent Reﬁnery で Tail-based Sampling した結果を Honeycomb へと送信

Slide 98

Slide 98 text

DDOT から全てのトレースを一度 Otel Collector に送信し、 Otel Collector で Tail-based Sampling を実行 98 Datadog へのデータ送信 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Reﬁnery vm insert DDOT Datadog Agent Honeycomb 　 Events　 Send Trace by ABEMA OTel SDK 　 Tail-based　　 Sampling　 vm insert OTel Collector

Slide 99

Slide 99 text

99 Datadog へのデータ送信 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Reﬁnery 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 へと送信

Slide 100

Slide 100 text

Slide 101

Slide 101 text

Observability 基盤の利用率 ABEMA のユーザシステムのほぼ全てのマイクロサービスがこの基盤を利用している ● ほぼ全ての GKE ノードへの展開 ● 100+ のマイクロサービスへの導入毎秒 165 万スパンという大量のデータを問題なく処理し、 ABEMA の Observability を支えている

Slide 102

Slide 102 text

負荷試験環境での利用実績負荷試験ではコスパ良く、統計情報を元にボトルネックを把握したい → Reﬁnery + Honeycomb のみ利用 vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Reﬁnery Honeycomb 　 Events　 Send Trace by ABEMA OTel SDK ABEMAの本番環境負荷試験への挑戦 - Speaker Deck

Slide 103

Slide 103 text

負荷試験環境での利用実績 Throughput-based sampling を利用することで、どんな流量でも上限を設けたままトレースを取得することができる vm insert OTel Gateway vm insert Micro Services vm insert Honeycomb Reﬁnery Honeycomb 　 Events　 Send Trace by ABEMA OTel SDK Throughput-based sampling

Slide 104

Slide 104 text

104 後半のまとめ Observability 実践 ● ABEMA としての Platform & Observability 戦略を支える基盤について ○ Observability 基盤の整備に先駆けて、インフラ基盤から刷新 ○ Observability 基盤に対する機能要件・非機能要件の整理 ○ ABEMA 規模で数年間問題なく稼働させるための技術的検証

Slide 105

Slide 105 text

No content