背景と移行の動機
Delivery Hero は食品配送業界で活躍する企業であり、13の子會社を統合する過程で、それぞれが異なるプラットフォームと観測ツールを使用していた。この狀況により、分散トレースの統合が困難となり、データが異なるバックエンドに蓄積されていた。CTO は年間600萬ドルのコスト削減を目標に、プラットフォームと観測ツールの統合を推進した。この移行の目的は、ベンダー中立（vendor agnostic）の実現、語義的約束（semantic conventions）の標準化、そしてトレースを核としたすべてのテレメトリデータの統合である。
移行戦略とアーキテクチャ設計
理想的なアーキテクチャ
中央管理の OpenTelemetry Collector Agent を中心に、すべてのアプリケーションが OpenTelemetry SDK を使用し、データを Agent を経由して単一のベンダーにイングレスする構成が想定されていた。
実際のアーキテクチャ
- 中央 Datadog Collector：Datadog フォーマットのデータを新ベンダーに統合。
- 中央 OTP Collector：OTP フォーマットのデータを処理。
- フェデレーテッドコレクター：OTLP、Prometheus、JSON などの複數フォーマットをサポートし、新ベンダーに統合。
- 子會社獨自のコレクター：Glovo、Logistics などの事業部は獨立したコレクターを維持。
移行ステップ
まずインフラの移行を完了し、その後アプリケーションの再インストルメンテーション（reinstrumentation）に著手した。
遇う課題と問題
1. カスタムコンポーネントと上流への貢獻
- フォークされたコンポーネント：DataDog Collector の受信機をフォークし、トレース、メトリクス、ログのすべてのテレメトリタイプをサポートする必要があった。既存のカスタムロジックは OpenTelemetry 上流バージョンと互換性がなく、戻すことができなかった。
- その他のカスタムコンポーネント：Span Metrics Connector、Prometheus Exporter、Delta to Cumulative Processor、Load Balancing Exporter など。
- 上流への貢獻の困難さ：上流コンポーネントの更新サイクルが遅く、要望を迅速に統合できなかった。カスタムコンポーネントにより、OpenTelemetry Collector のバージョンアップに補丁を追加する必要があり、メンテナンスコストが増加した。
2. データシリアライズ/デシリアライズのオーバーヘッド
- 問題の概要：コレクター內部でデータを変換する際、複數回のシリアライズとデシリアライズ（マーシャリング/アンマーシャリング）が行われた。これは引っ越しの例に比喩されるように、すべてのアイテム（フォーク、スプーンなど）を異なるボックスに分解するプロセスであり、効率が低下した。
- パフォーマンスへの影響：CPU 使用率が高くなり、ガベージコレクション（GC）のオーバーヘッドが増加した。メモリ消費も高くなり、フライムグラフでは大部分の CPU サイクルがデータ変換に費やされていた。
3. 狀態を持つコンポーネントの追加ニーズ
- Span Metrics Connector：同じトレースの spans が同じコレクターPodに到達するようにするため、Load Balancing Exporter を導入した。
- Delta to Cumulative Processor：DataDog ホストヘッダーに基づいてデータをルーティングする必要があり、獨自のプロキシアプリケーションとルーティングロジックを構築した。
- メンテナンスコスト：獨自コンポーネントの監視とデバッグを継続し、運用負擔が増加した。あるプロキシアプリケーションは重大な事故を引き起こした。
結論と振り返り
継続的な課題
- カスタムコンポーネントと上流への貢獻のバランス。
- 狀態を持つコンポーネントの追加インフラストラクチャニーズ。
- データ変換のパフォーマンスオーバーヘッド。
長期的な価値
- OpenTelemetry はベンダー中立とベンダーロックインの迴避を実現する唯一の手段である。
- 一時的なコストを払っても、長期戦略目標に合致する。
総括
移行プロセスは困難だったが、OpenTelemetry の柔軟性と標準化の価値は大きい。カスタムコンポーネントと上流への貢獻プロセスを継続的に最適化し、メンテナンスコストを削減する必要がある。