ABEMAの信頼性設計とオブザーバビリティ基盤¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
ABEMA の信頼性設計と Observability 基盤を、「不確実性への備え」として紹介するアーキテクチャ Conference 2025 の登壇資料。 AWS、Google Cloud、Cloudflare を用途別に使い分け、EKS / GKE、service mesh、Prometheus / VictoriaMetrics / Grafana、OpenTelemetry、Honeycomb、Datadog を組み合わせている。 Head-based sampling の限界、4 Signals の分断、大規模イベント時の未知の異常検知などが課題として整理されている。 最終的には OTel 準拠の共通 SDK と gateway、tail-based sampling、SaaS 連携によって、大量 telemetry を扱う構成へ進化している。
解説¶
この資料の価値は、単にツール一覧を並べるのではなく、事業特性から信頼性設計を逆算している点にある。 ABEMA はリアルタイム性、同時性、大規模イベント、予測困難な負荷があるサービスなので、単一クラウドや単一監視ツールだけではなく、配信系とユーザー系でアーキテクチャを分けている。
Observability も「メトリクスを集める」段階から、「未知の異常を早く見つける」「経験の浅い領域でも根本原因に近づける」「大量データをコスト内で扱う」段階へ進化している。 大規模サービスでは、監視基盤そのものもプロダクトとして要件定義、非機能要件、負荷検証、運用設計が必要になる。
本文¶
本文は Speaker Deck の transcript から取得できた内容をもとに、日本語で再構成したもの。
ABEMA の事業特性¶
ABEMA は、生中継、ニュース、イベント性の高い番組、同時視聴などを扱う。 多様な視聴スタイルと予測困難な負荷があるため、常に障害と急激なトラフィック変動に備える必要がある。
資料では Observability を、単なる可視化ではなく不確実性への備えとして位置づけている。
Platform 戦略と Cloud Architecture¶
ABEMA は用途に応じて複数クラウドを使い分けている。
- AWS: 配信システム、Elemental MediaConnect / MediaLive / MediaPackage / MediaTailor、S3、Bedrock など
- Google Cloud: ユーザーシステム、GKE、Cloud Service Mesh、BigQuery、Vertex AI、AlloyDB AI など
- Cloudflare: 画像変換、Workers、Images、Waiting Room など
配信システムとユーザーシステムでは、マルチリージョンの目的も異なる。 AWS 側の配信システムは東京、大阪、ソウルを使い、リージョン内完結と継続配信を重視する。 Google Cloud 側のユーザーシステムは東京、大阪、台湾を使い、拡張性とキャパシティ確保を重視する。
Kubernetes と Service Mesh¶
クラウド差分を意識せず使えるプラットフォームとして Kubernetes を中心に据えている。 EKS と GKE を併用し、Add-on を整備して同じように利用できる環境を作る。
Service Mesh では、App Mesh と Cloud Service Mesh を活用している。 資料では、circuit breaker、outlier detection、auto retry、traffic mirroring によって、障害時の影響範囲を小さくし、回復性や本番相当の検証を支えている。
Observability 戦略の変遷¶
2022 年時点では、Grafana、VictoriaMetrics Cluster、Prometheus Agent Mode、Cloud Trace などによる統合監視基盤があった。 しかしシステムが複雑化し、サービス間通信の可視化や根本原因調査が難しくなっていった。
分散トレーシングでは、Head-based sampling によって本当に欲しいトレースが欠落するという課題があった。 コストと情報量のトレードオフが強く、単純に全量保存することも難しい。
2023 年からは Grafana 活用を強化し、Loki、Tempo、Pyroscope、OpenTelemetry を組み合わせて metrics、traces、logs、profiles を扱う構成へ進めた。 しかし 4 Signals がつながっておらず、開発工数が高いことが新たな課題になった。
OpenTelemetry と SaaS 連携¶
2024 年から OpenTelemetry をベースにした SaaS 連携を強化している。 内製の trace SDK を OTel 準拠で刷新し、特定 vendor に依存しない計測実装へ寄せている。
SaaS としては、Honeycomb による大規模 trace 分析、Datadog による 4 Signals の探索体験と異常検知を整備している。 OTel 準拠にしておくことで、既存実装を変えずに連携先を追加しやすくしている。
Tail-based Sampling と Refinery¶
Honeycomb 連携では、OTel Gateway から Refinery へ trace を送り、Refinery で tail-based sampling を実行する。 Refinery は Honeycomb が開発する sampling tool で、dynamic sampling、rules-based sampling、throughput-based sampling、deterministic probability sampling などをサポートする。
Datadog 連携では、DDOT から OTel Collector へ trace を送り、Collector 側で tail-based sampling した結果を Datadog へ送る構成が紹介されている。
利用実績¶
資料では、ABEMA のユーザーシステムのほぼすべてのマイクロサービスがこの Observability 基盤を利用していると説明されている。 100 以上のマイクロサービスへ導入され、毎秒 165 万 span という大量データを処理している。
負荷試験環境では、Refinery と Honeycomb を使い、throughput-based sampling によって流量が大きくても上限を設けたまま trace を取得する。 これにより、コストを抑えながら統計情報をもとにボトルネックを把握できる。
要点¶
- Observability は、既知の監視だけでなく未知の異常に備えるための信頼性設計である。
- 配信系とユーザー系でクラウド、リージョン、設計優先度を分けている。
- Head-based sampling だけでは、大規模障害調査に必要な trace を落とす可能性がある。
- OTel 準拠の SDK と gateway は、vendor lock-in を避けつつ SaaS 連携を強化できる。
- 大規模 telemetry では、tail-based sampling と throughput 制御がコストと調査性の両立に効く。