NikeやeBayが陥った「OpenTelemetry」の穴 監視インフラ運用の“泥臭い実態”：運用本番段階で露呈する弱点

システム監視を効率化する「OpenTelemetry」において、データを集めるための設定を開発チームに委ねると、想定外の作業負担が発生し得る。NikeやeBayは、手作業が招く社内展開の壁をどう打ち破ったのか。

[TechTargetジャパン]

　システムの稼働状況を監視するためのデータを一元的に収集するための標準仕様群「OpenTelemetry」の採用が進んでいる。しかし、概念実証（PoC）を終えて全社規模の運用フェーズ（Day 2）に移行した途端、企業は想定外の壁に直面している。

　クラウドネイティブ技術の標準化団体Cloud Native Computing Foundation（CNCF）が2025年11月に開催したイベント「CNCF-hosted Co-located Events North America 2025」では、大規模なシステム構成で可観測性（オブザーバビリティ）システムを運用する専門家が登壇。その苦労と具体的な回避策を共有した。

　登壇者が共通して指摘したのは、データ量に比例して爆発的に増加するTCO（総所有コスト）と、社内の開発チームに計装（データを出力させるためのソースコード追加）を浸透させる際の手間だ。

　スポーツブランドのNikeでは、クラウドネイティブなシステム構成への移行に伴い、データの多様性が急増。コンピューティングリソースの消費に伴う費用が大幅に膨れ上がった。EC（電子商取引）大手のeBayでは、数千件に及ぶマイクロサービス群からのデータ収集方法をいかに標準化するかが喫緊の課題だった。

　これらの課題を、各社はどう解消したのか。イベントに登壇した各社のパイプライン構成と、社内普及における泥臭い実態を詳説する。

開発チームに根付かせるための「自動化」と「統制」

併せて読みたいお薦め記事

オブザーバビリティの重要性

• インフラ監視から「事業目標達成」のための手段へ　オブザーバビリティツールの進化
• AI安定稼働の鍵は「可観測性」（オブザーバビリティ）　主要ツールを紹介

　イベント内のセッション「Surviving and Thriving With OpenTelemetry: A Day 2 Operations」では、数千件のマイクロサービスから毎秒数億件のデータを収集する極限状態において、費用の爆発を防ぎながら安定運用を続ける具体的な手法が議論された。

　可観測性の恩恵を最大限に受けるには、まず各アプリケーションからデータを適切に出力させる必要がある。しかし、開発チームにその作業を委ねるだけでは、足並みはそろわない。セッションの進行役を務めた、ログ集約ツール「Grafana」の開発元であるGrafana Labsのマール・クランツ氏は、本番運用フェーズでの継続的な成功には「技術以上の工夫」が必要だと説いた。

　大手金融機関Capital Oneでシニアリードソフトウェアエンジニアを務めるジョセフ・ナイト氏は、プロセスを徹底的に自動化することでこの課題を解決している。同社はオープンソースのコレクターやSDK（ソフトウェア開発キット）を社内の標準的な開発・デプロイシステムにパッケージ化。個々の開発者が可観測性を意識することなく、容易に自動計装を組み込める仕組みを実現した。

　一方で、eBayのプリンシパルアーキテクトであるビジャイ・サミュエル氏は、「特定のライブラリ使用を全社に義務付ける」という強力な統制を敷いている。当初は自動計装を活用していたが、最終的には特定の計装ライブラリの利用に適合することを強制した。これによって、全マイクロサービスでメトリクスや属性の形式が完全に統一され、機械学習による自動での根本原因分析（RCA）が実用レベルで実現したという。

　Nikeのプラットフォームエンジニアリングディレクター、パノス・ツィロプロス氏はさらに踏み込んだアプローチを提示した。同社は、開発チームへの啓発活動には限界があると判断。代わりに、データ収集・送信用エージェントソフトウェアの設定を遠隔管理するためのプロトコル「OpAMP」（Open Agent Management Protocol）を利用した管理システムを内製し、可観測性チームがエージェントソフトウェアの設定を一元管理できるようにした。これによって、開発チームに再デプロイの手間をかけさせることなく、パイプラインの動的な制御を可能にしている。

パイプラインの階層化とメッセージキューによる負荷分散の仕組み

　収集するデータ量がP（ペタ）B規模に達すると、エージェントソフトウェア自体の負荷やストレージ費用が経営を圧迫する。この問題に対し、登壇した各社はアーキテクチャの工夫で対抗している。

　Capital Oneは、費用を制御するためにサンプリング専用の中継サーバ層を追加した。パイプラインを多段層化し、サーバを増設して負荷を分散できる構成にすることで、単一のインフラに依存せず、処理の重いタスクを分離。コンピューティングリソースの効率的な利用を可能にした。

　可観測性技術に特化したソフトウェアベンダーOllyGardenのジュラシ・パイシャオン・クレーリング氏は、データの多様性による処理遅延を防ぐ設計を提唱した。トレースやメトリクスなど、形状の異なるデータを直接処理（ホットパス）するのではなく、一度メッセージキューに格納する。後からそれぞれのデータの特性に合わせた速度で処理する手法を取り入れている。この設計は、突発的なトラフィック増への適応力があるだけではなく、バックエンドシステムがダウンした際のデータ消失リスクも軽減する。

　Nikeのツィロプロス氏は「最小限のデータセット」によるガバナンスを強調した。エンドユーザーの購買行動などのビジネスに直結する重要なプロセスに絞り、収集するデータとそれに対するラベリングを全システムで統一している。これによって、無駄なデータの増殖を防ぎつつ、複数のシステムをまたがって「特定のエンドユーザーがどこでエラーに遭遇したか」などを一括で検索、分析できる状態を実現した。

費用削減の先にある「ビジネスへの貢献」

　高額なインフラ費用を経営層に納得させるためには、単なるシステムの安定稼働だけではなく、ビジネスへの直接的な貢献を示す必要がある。

　Nikeは、スニーカーの限定販売時などのタイミングに可観測性システムをフル活用している。トラフィックの動向から需要の多寡をリアルタイムで分析し、「在庫を増やすべきだったかどうか」といったビジネス上の意思決定に直結するデータを抽出する。これによって、システム投資の価値を技術指標以外の文脈で証明している。これは、可観測性を単なる「監視」から「ビジネスインテリジェンス」に昇華させた好例だ。

　システムが成熟するにつれて、現場からの要望も高度化しており、オープンソースコミュニティーには開発効率向上のための次なる手段が期待されている。eBayのサミュエル氏は、多様なシグナルから自由にデータを引き出すため、時系列データベースのクエリ言語である「PromQL」にとどまらない、標準化されたクエリ言語の必要性を訴えた。Capital Oneからは、データ収集機能の組み込みにおいて、ソースコード改修の作業が発生しやすいプログラミング言語「Go」のさらなる充実を求める声が上がった。

　今後の展望として、各社はOpenTelemetryを単なるデータ収集の手段ではなく、AI（人工知能）技術による自律的なシステム運用や、ビジネスの意思決定を支えるインフラに進化させるロードマップを描いている。技術的なDay 2を乗り越えた先にあるのは、データが直接的な利益を生む「可観測性の黄金時代」だと言えそうだ。