公開日 2024/12/25更新日 2024/12/25

ABEMA のオブザーバビリティアーキテクチャ変遷

「ABEMA」は、テレビのイノベーションを目指し「新しい未来のテレビ」として展開する動画配信事業です。開局 8 年目に入り、ニュース、アニメ、恋愛、格闘、バラエティなど、多彩なジャンルの約 25 チャンネルを 24 時間 365 日放送しています。
2024 年 9 月には月間アクティブユーザー数が 3,000万を突破し、多くのユーザーに利用いただいています。

ABEMA | 無料動画・話題の作品が楽しめる新しい未来のテレビ
 ABEMA | 新しい未来のテレビ「ABEMA」、週間視聴者数が3,000万を突破

この成長を支える鍵となっているのが、モニタリングとオブザーバビリティです。本記事では、ABEMAにおけるオブザーバビリティの進化とこれまでの取り組みについてご紹介します。

ABEMAのインフラ構成と2022年以前の監視環境

ABEMAでは、Google CloudとAmazon Web Services ( 以下、AWS ) を活用したマルチクラウド構成を採用し、300 以上のマイクロサービスがそれぞれのクラウドサービス上の Kubernetes 環境で稼働しています。

abema1

サービスの横断的な監視を実現するため、Grafanaを利用し、単一のプラットフォームでモニタリングを統合しています。

abema2

しかし、サービスの成長に伴い、複雑化したシステムにおける問題調査が時間を要するようになり、特に複数のマイクロサービスやミドルウェアが絡むトラブルの原因特定に課題を抱えるようになりました。

こうした背景から、オブザーバビリティ向上への取り組みが始まりました。

オブザーバビリティ導入〜活用へ取り組み

ABEMAでのオブザーバビリティ向上への取り組みは、2022年に開催された大規模イベントの負荷対策から始まりました。

オブザーバビリティ導入期 - OpenTelemetryを利用して分散トレーシングを実現

2022 年の大規模イベントでは、各マイクロサービスごとの単体負荷試験だけではなく、サービス全体に対する複合的な負荷試験を行いました。
負荷試験を開始した当初はサービス全体に対して分散トレーシングが導入されておらず、ボトルネックの調査に時間がかかっていました。そこで、 OpenTelemetry を利用して各ゲートウェイ、マイクロサービス、ミドルウェアを横断した分散トレーシングを実現することにしました。

abema3

時間的な制約もあったため、重要なコンポーネントにのみ計装し、トレースデータの可視化にはいくつかのコンポーネントで採用していたGoogle Cloud の Cloud Trace を利用しました。その結果、複雑なシステムの負荷試験を効率化し、調査時間を大幅に短縮することができました。
具体的な導入手順や技術については CA.go というイベントで紹介しているのでご覧ください。
https://youtu.be/yEeqSxwNI1E?si=W4FCLCPqeDuSyb5Q

オブザーバビリティ成長期 - すべての環境を横断的に観測できる基盤を構築

2023年には、Google Cloud上のマイクロサービスでのみ導入していた分散トレーシングの仕組みを拡張し、AWS上で動作するコンポーネントも含め、すべての環境を横断的に観測できる基盤を構築しました。この過程で OpenTelemetry Collector、Grafana Tempo、Grafana Loki を導入しました。
OpenTelemetry Collectorを採用した理由は、マイクロサービスから直接データを送信する場合、Head-based Samplingしか行えないという制約を解消し、将来的にTail-based Samplingなど柔軟なサンプリングを実現するためです。
また、Google Cloud Trace とは別で Grafana Tempoを導入したことで、AWS環境を含むトレースデータを一元的に管理できるようになりました。また、複数クラウド間を跨いだトレースも確認できるようになり、既存のGrafanaと連携することで統一感のある運用が可能になりました。

トレースデータの一元管理を導入後に見えてきた新たな課題と対策

コスト増懸念でサンプリングレートを抑えて運用した結果、確認したいデータが見れない事態に

Grafana Tempo の導入初期は、Grafana Tempo の環境で問題が発生した際でもトレースデータを確実に確認できるよう、OpenTelemetery Collector で Cloud Trace と Grafana Tempo の両方にトレースデータを書き込む構成を取っていました。
サンプリング戦略を考えるために、この構成で OpenTelemetry Collector の負荷試験を行ったところすべてのトレースデータを取得すると、OpenTelemetry Collector 自体のリソースのコストが許容できないことが発覚し、サンプリングレートを数 % に抑えて運用を行っていました。

しかし、特定の問題発生時に必要なトレースデータがサンプリングされていない場合があり、確認したいデータが見れないという課題が出てきました。

この課題に対して、 OpenTelemetry Collector の負荷試験とチューニングを行い、ある程度のスパン数まで捌ける構成を構築してサンプリングレートを上げられるようにしました。また、重要度の高い API のサンプリングレートだけを上げることで、確認したいデータが見られないといった事態がないように対応しました。

OOM など瞬間的に落とされたデータの原因調査が難しい

OOM (Out Of Memory) など、意図しない事象により、Pod の強制終了が発生すると、メトリクスやプロファイルデータを回収することが困難になるという課題がありました。元々 Google Cloud の Cloud Profiler を利用していましたが、プロファイルデータの送信間隔を変更できないため、問題のあるタイミングのプロファイルデータの確認ができませんでした。

そこで、Grafana Pyroscope の導入を進めました。Pyroscope では、SDK でプロファイルデータの送信を行う際にデータの送信間隔を短くすることができるため、落とされる直前のプロファイルデータが回収できる可能性を上げることができます。問題が発生しはじめた際のデータを回収できる割合が上がったことで、原因の仮説を立てやすくなり調査が行いやすくなりました。

ABEMA ではデプロイツールとして PipeCD という CD ツールを利用しています。しかし、そのツールで複数のマイクロサービスのリリースが同時に実行されると、デプロイが詰まってしまうというパフォーマンスの課題が発生していました。Pyroscope を利用してプロファイルデータを回収し、PipeCD の開発チームと問題の調査を行い、最大 3.5 倍デプロイが早くなるケースが出てくるほどの大きなパフォーマンス改善に貢献することができました。

https://pipecd.dev/blog/2024/09/11/performance-improvement-in-git-operations-on-pipecd-v0.48.9/

改善後の最終的なオブザーバビリティアーキテクチャ

2024 年 12 月現在、モニタリングとオブザーバビリティ両方を含めた全体構成としては以下のようになりました。

abema4

OpenTelemetry と Grafana Ecosystem を活用することで、特定のクラウドサービスに縛られること無く横断的に観測することのできるモニタリング・オブザーバビリティ基盤を構築することができました。

abema5

トレーシング環境の構成は OpenTelemetery Collector を 2 つのレイヤーで配置した多段構成になっています。このような構成を取ったことで、スケーラビリティを保ちながら Tail-based Sampling といった柔軟なサンプリング戦略を取れるようになりました。

分散トレーシング・サンプリング戦略におけるコストシミュレーションと経営陣への説明

まず前提として、オブザーバビリティ基盤の導入に伴うコストは、アプリケーションの規模やサービスの成長に応じて変動すると考えています。そのため、以下の手順で費用対効果を検証しました。

負荷試験の実施: トレースなどについてコンポーネントごとに負荷試験を行い、ABEMA の構成下におけるパフォーマンスの計測を実施
本番環境での検証: 負荷試験の結果と実際のサービスで生成されるトレースデータでのパフォーマンス差分を検証するために、一部コンポーネントにオブザーバビリティ基盤を導入して実際のデータでのコストの理論値の把握
コスト試算の作成: どれくだいのリソースを導入することでどこまでサンプリングレートを上げていけるかの情報の整理
優先順位付け: バックエンド開発者と議論してどのマイクロサービスを優先的にトレースしていくかの情報を整理

これらの結果をもとに、経営層には「特定のコンポーネントで必要な観測を行うために、この程度のコストが発生する」といった具体的な判断材料を提示しました。
現場のエンジニア側では、番組や時期ごとにサンプリングレートやリソースの調整を設定できるようにしておくことでコストを抑えながら必要なデータを集められるように心がけています。
また、将来的にはより高パフォーマンス・低コストでデータを集められるようにするための改善を継続的に考えています。

今後の展望

ここまでの構成を構築することで、ログ・トレース・メトリクス・プロファイルのオブザーバビリティの 4 本柱すべてのデータを取得し、それぞれ柔軟にカスタマイズできるような構成になりました。
次のステップとしては、4 本柱すべてのデータを繋げることで誰もがどこからでも問題対応を行える世界を作りたいと考えています。データを繋げていくのは、実装に修正を入れたり泥臭い対応をやっていく必要がありますが、そこをやりきり真のオブザーバビリティの民主化を実現したいです。

執筆

宇地原さん

株式会社 AbemaTV Development Headquarters
Platform Division, Developer Productivity Team

宇地原大智
X: https://x.com/u_chi_ha_ra_
GitHub: https://github.com/ucpr