イベント内のセッション「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を乗り越えた先にあるのは、データが直接的な利益を生む「可観測性の黄金時代」だと言えそうだ。

本稿は、Cloud Native Computing Foundation（CNCF）が2025年11月25日に公開した動画「Panel: Surviving and Thriving With OpenTelemetry... Juraci K, Myrle K, Joseph K, Vijay S & Panos T」を基に作成しました。