多角的なエンターテインメントサービスを展開するDMM.comは、2022年にサブスクリプション型動画配信サービス「DMM TV」を立ち上げた。同社はこれに伴い、動画配信インフラをオンプレミスからGoogle Cloud上の「Google Kubernetes Engine」（GKE）へ移行した。短いライフサイクルでコンテナが生成・破棄されるクラウドネイティブ環境では、従来のインフラ監視だけでは不十分で、アプリケーションやユーザー体験を含めたフルスタックな可観測性が求められる。こうした要件に対応するため、同社は統合モニタリング基盤として「Datadog」を採用した。4人のSRE（Site Reliability Engineering、本番環境の信頼性を担保する取り組みを網羅的に担う）チームでCPU約820コア規模のインフラ運用を支える体制や、開発チームとの共通言語としての可観測性をどのように定着させたのか。その実装と運用のポイント、さらに今後のAI活用に向けた取り組みを取材した。
DMM TV立ち上げに伴いインフラ基盤をコンテナネイティブに刷新
DMM.comは2022年12月、アニメやバラエティ、舞台作品などを扱う総合動画配信サービスDMM TVを開始し、あわせて会員基盤となる「DMMプレミアム」を立ち上げた。従来の売り切り型の動画配信から月額定額制へとビジネスモデルを転換し、複数のエンタメサービスを横断的に利用するためのハブとしてDMM TVを位置づけている。
この新サービスの立ち上げにあたり、同社はインフラ基盤をオンプレミスからクラウドへ移行した。従来の動画配信基盤は長年オンプレミスで運用されてきたが、新たにプラットフォームを設計し直し、社内で検証を進めていたGoogle CloudとGKEを中核とするコンテナネイティブなアーキテクチャを採用している。
このインフラ環境の変化は、運用監視の前提にも影響を与えた。オンプレミス時代の監視は、オープンソースの統合監視ソフトウェア「Zabbix」を核とした仕組みで、主にCPUやメモリー、ディスク使用率といったインフラリソースの把握に取り組んでいた。仮想マシン上にアプリケーションを配置する構成では、こうしたリソースを静的に監視することで全体の状態を把握できたためである。
一方、GKEを前提としたクラウドネイティブ環境では、寿命の短いコンテナが自動的に生成・破棄される。リソースやワークロードの配置が継続的に変化するため、サーバー単位の静的な監視ではシステム全体の挙動を十分に捉えることが難しい。その結果、コンテナ環境に適した、より動的かつアプリケーションレイヤーまで含めた監視アプローチが求められるようになった。
ユーザー体験を守るフルスタック監視に向けDatadogを選択
インフラがコンテナネイティブへと移行したことに加え、新サービスの開発に携わるフロントエンドとバックエンドの開発チームからも、これまでにないモニタリング要求が寄せられていた。サブスクリプション型動画配信では、解約を防ぎ、ユーザーに継続して利用してもらうために、動画の再生安定性や画面表示速度といったユーザー体験の維持・向上が重要な指標となる。
開発現場からは、エンドユーザーが体感するパフォーマンスを正確に把握したいとの要望があり、フロントエンドからバックエンドまでを横断して確認できるフルスタックな監視環境が求められた。具体的には、特定APIの応答遅延や、アプリケーション層におけるガベージコレクションの挙動などの詳細なパフォーマンス指標を可視化し、その変化がユーザー体験に与える影響まで追跡できることが必要とされた。
その背景には、同社が過去の運用で経験してきた課題もある。大型キャンペーン時にトラフィックが急増し、サーバーがダウンする事象が発生しており、生配信イベントや人気作品の無料配信ではアクセスが集中しやすかった。当時のレガシー基盤では十分な性能チューニングが難しく、スパイクアクセスに対応するには、配信用に別システムを都度構築してしのぐ必要があり、運用負荷も大きかった。
これらの課題を踏まえ、インフラとアプリケーションの両面にまたがるシステム全体を一元的にモニタリングできる仕組みが求められていた。この要件を満たすツールとしてDatadogを採用した。DMM.comでは、同製品を提供する米Datadogの日本法人が設立された2019年以降、ゲーム事業や全社共通のアカウント、決済を担うプラットフォーム基盤などでDatadogを活用してきた実績があり、運用チームにも一定の知見が蓄積されていた。加えて、インフラ監視にとどまらず、アプリケーションパフォーマンスモニタリング（APM）やリアルユーザーモニタリング（RUM）といったデジタルエクスペリエンスの可視化に必要な機能がそろっていたことも評価ポイントとなった。
レガシー環境では導入が難しかったフロントエンドからバックエンドまでのフルスタック監視は、クラウド移行によってアーキテクチャ的にも運用的にも現実的な選択肢となり、その要件を満たすSaaS型の監視プラットフォームとしてDatadogが最適と判断されたことも、選定理由の一つである。さらに、Datadogは必要な範囲から小さく始めやすい料金体系と、リアルタイムに更新されるダッシュボードを簡単に作成できる操作性を備えている。DMM TVのように開発スピードが重視される環境では、こうした導入・運用のしやすさも評価され、Datadogは開発チームとSREチーム双方の要求に対応できる選択肢となった。
Datadog Notebookを核とした開発・運用チーム間の連携
DMM TVでのDatadogの運用は、SRE、アプリケーション、フロントエンド、バックエンドの4チームを中心に、リードオンリーのアカウントを含めて約160人が利用している。各チームは役割に応じてDatadogを使い分けており、監視対象が異なるため、それぞれ専用にカスタマイズしたダッシュボードを運用している。
たとえばフロントエンドチームはRUMを中心に、ページの表示速度などのコアウェブバイタルを確認し、ユーザー体験の低下を防いでいる。一方、バックエンドチームはAPMを用いて、レイテンシー悪化につながるエラーの早期検知や原因分析を行っている。
その一方で、部門をまたいで共通のデータを整理し、部門間の会話の土台をつくる役割を担っているのがDatadog Notebookだ。Notebookは、ダッシュボード上のメトリクスやトレース、ログなどを文章とあわせて一つのドキュメントとしてまとめ、チーム間で共有できるコラボレーション機能である。障害発生時には、SREチームが関連するメトリクスやトレースをノートブック上に整理し、時系列や原因仮説をコメントとして付けたうえで開発チームへ共有する。たとえば、異なるコンポーネントで同時に不可解な挙動が発生した際、双方のメトリクスを一つのNotebookに並べて共有することで、開発側が「共通の原因があるのではないか」と直感的に気づきやすくするアプローチが取られている。
DMM.com 動画配信開発部 配信インフラグループ SREチームの片岡步夢氏は「Datadogを使ってみて理解したのは、インフラだけでなくアプリケーションの課題もSRE側から確認できることです。Datadog Notebookを使えば、他チームとダッシュボード情報を手軽に連携でき、わかりやすく伝えられる点もユニークです」と語る。
この運用が定着したことで、障害対応の初動やチーム間のやり取りは大きく変わった。日常の会話でもDatadogのダッシュボードやNotebookのURLが頻繁に共有され、システム全体の品質を支える共通言語として機能している。なお、ユーザー数や解約率といったビジネスKPIは、別の事業部がBigQueryやLookerで管理しているが、SREチームもデータ連携の面で協力し、システム品質の側面からその維持を支えている。
アプリケーション層まで踏み込んだ監視について、片岡氏は次のように話す。「主要コンポーネントのAPMをチェックする中で、特定のAPIエンドポイントの遅延や、ガベージコレクションによるメモリ使用率の急増といったアプリケーション側の詳細なメトリクスを、インフラ側（SRE）でも高い精度で把握できるようになりました。これにより、トラブル発生時に『もしかしたらアプリケーション側のこの処理に問題があるのではないか』というところまで、SRE側から原因を絞り込んで開発チームに共有できるようになり、大きな効果を感じています」
4人のSRE体制で大規模インフラの安定運用を支える
現在、DMM TVの配信インフラはCPU約820コア規模で運用されており、サービスの成長に伴ってコンテナのPod数やコンポーネント数も増え続けている。こうした大規模かつ動的な環境を、4人のSREチームがDatadogを活用しながら支えている。少人数で安定運用を実現するうえで欠かせないのが、監視の標準化と運用の自動化だ。
実際の運用の負担感について片岡氏は、「監視を担うSREチームがわずか4人でオンコールを回すとなると、月に1回は夜間や休日の当番が回ってくる計算になります。それにもかかわらず、大きなトラブルもなく安定して回せているのは、Datadogに必要なメトリクスが一元化され、日常的なチェックにかける時間を最小限に抑えられているからです」と明かす。
SREチームの日常監視は、サービス全体の健全性を迅速に評価するために設計したオーバービューダッシュボードを確認するだけで済む。日次では2〜3日の短い時間軸を見ながら、APMやRUMのエラー推移、Podの異常、エラーログの急増などを確認し、突発的な変化を早めに捉えるようにしている。日次の確認時間は15分程度だが、ダッシュボードがなければ2倍以上の時間を要していたと片岡氏は話す。
さらに、インメモリキャッシュとして利用している「Redis」（インメモリ型のNoSQLキーバリューデータストア）のメモリエラーを素早く検知するための専用ダッシュボードも作成しており、問題発生時の原因究明を迅速化している。加えて、ノードリソースの利用効率を確認するコスト管理用ダッシュボードも常時運用し、負荷状況を踏まえながらGKEのノード数を適切に調整している。
日常監視でイレギュラーな状態やしきい値を超える異常を検知した場合は、Datadogのモニター機能からSlackやオンコールシステムを通じて担当者へ自動通知する仕組みを整えている。これらのモニター設定はIaC（Infrastructure as Code）ツール「Terraform」でコードとして一元管理しており、設定の棚卸しやしきい値の調整も柔軟に行える。
また、大型キャンペーンや人気コンテンツのライブ配信のように、急激なアクセス増加が想定される場面では、特別監視を実施する。過去のイベントで取得したアクセス数やPod数の推移、実施した対応などはDatadogのNotebookに記録し、次回以降のキャパシティプランニングやリソース試算に活用している。
負荷試験でもDatadogを試験環境に導入し、数値ベースで挙動を確認している。SREチームが常時張り付かなくても、バックエンドチームが試験を実施し、その結果をDatadog上で共有するだけで必要なキャパシティを算出できるため、運用効率の向上とインフラコストの最適化につながっている。
多機能化に伴う運用の負荷増大、AIが課題解決の切り札になるか
Datadogの導入により、DMM TVは運用効率とサービスの安定性を向上させてきた。一方で、可観測性の運用は一度構築すれば終わりではない。サービスの進化に伴って新しい技術スタックが次々と追加されており、直近では検索基盤としてElasticsearchを導入し、インメモリキャッシュもRedis互換の「Valkey」へ移行を進めている。コンポーネントの増加や変化に応じて監視の仕組みを継続的に作り込む必要がある。
Datadogは多機能である反面、使いこなすには一定のノウハウが必要で、課金体系も複雑だ。そのため、自分たちに必要な機能を見極めながら、コストと機能のバランスを取り続ける運用負荷も発生している。
現在、4人という限られた要員でローテーションを回しているSREチームにとって、夜間や休日の緊急対応の負担軽減と属人化の解消は重要な課題だ。システムが堅牢になったことで大きな障害は減ったが、その一方で、障害対応の経験やナレッジがメンバー間で偏りやすくなるという新たな問題も生まれている。こうしたギャップを埋める手段として、同社はDatadogのAIアシスタントの「Bits AI」をはじめとするAI機能に注目している。Bits AIは、Datadog上のメトリクスやログ、トレースを横断的に調査・要約するDevOps向けのAIアシスタントだ。
同社が期待するのは、異常検知後の原因究明や解決策の提示に加え、業務時間外の自動調査や自動復旧まで見据えた運用の高度化だ。片岡氏によれば、現在のDatadogには、追加設定なしでメトリクスやログの異常を自動検知するWatchdogと、詳細な調査を担うBits AIがあるが、Watchdogは文脈や因果関係の把握に限界があり、Bits AIは有用である一方、明確なトリガーがなければ動きにくいという課題がある。
そこで両者の間を埋めるような、たとえば一定間隔でシステム全体を軽く監視し、文脈を踏まえて異常の兆候を教えてくれる、軽量で安価なAI機能を求めている。AIが原因特定やノイズ除去といった定型業務を担えるようになれば、SREチームはより価値の高いクラウドネイティブ化やアーキテクチャ刷新に集中できる。同社は今後もDatadogの活用範囲を広げながら、少数精鋭の体制で動画配信プラットフォームの高度化と安定運用に挑み続ける構えだ。