OpenTelemetry、vendor lock-inを避けるobservability標準をCNCFで育てた設計

冒頭

Ben SigelmanはOpenTelemetryの前身となる標準化活動について、vendor lock-inを避けるための共通基盤を目指したと説明している。出典

OpenTelemetryは、observability vendorを選ぶ前に計測の共通言語を置くプロジェクトとして成長した。出典

統合から始まった標準化

2019年、OpenTracingとOpenCensusを統合する取り組みとして発表された。

Ben SigelmanらOpenTracing側の活動と既存コミュニティを、単一の仕様へ束ねる出発点だった。出典

転機と難しさ

OpenTelemetryはbackendを一つに決めず、API・SDK・Collectorの境界を先に整えた。

そのため利用者は既存のbackendを残したままinstrumentationを共通化できる一方、各実装の成熟度を見極める必要があった。出典

成長と現在

CNCFのgraduated projectとなり、複数言語のSDK、Collector、demo、ecosystemを持つ標準へ広がった。出典

Ben Sigelmanが関わったOpenTracingの問題意識は、vendor lock-inを避けたい開発者の課題として、より広い標準化へ引き継がれた。出典

結び

OpenTelemetryの示唆は、observabilityを画面ではなくデータ契約として設計したことにある。

計測の共通化とbackend選択を分離する発想は、複数クラウドを扱う日本企業にも応用できる。

observabilityの利用企業は、vendorごとに異なるagentやSDKを運用する負担を抱えていた。

OpenTelemetryはtraces・metrics・logsを共通のAPIとSDK、Collectorで扱い、計測とbackend選択を分離する。出典

OSS標準として複数vendorとCNCFのエコシステムを横断できる点が、単一製品ではなく計測基盤を探すチームに刺さる。

仕様と実装を公開し、CNCF・vendor・ユーザーが参加する互換性のネットワークを形成している点が障壁になる。

単一企業の機能ではなく、標準採用の蓄積が効く。出典

強い。

instrumentation library、Collector、backend vendorが同じsemantic conventionを採用するほど、ユーザーの移行コストが下がる。

一方、規格の複雑さは参加障壁にもなる。

複数サービスを運用し、observabilityの計測方式を統一したいplatform teamやSRE向け。

単一アプリの可視化だけを急ぐ小規模チームには導入設計が重い場合がある。

第一に、OpenTracingとOpenCensusの統合で既存の標準化資産を束ねた。出典

第二に、仕様・SDK・Collectorを分離し、多言語で段階的に導入できる構造を取った。出典

OSS標準はbackendそのものではないため、保存・可視化・アラートは別途選定が必要になる。

また仕様や各言語実装の成熟度が揃わない局面では、チームが互換性を確認するコストも残る。出典

特定vendorの営業ではなく、GitHub、docs、CNCF、各言語のSDKを入口に開発者へ浸透する戦略。

zero-code instrumentationやdemoで導入を早め、backend vendorとの連携で利用先を増やす。出典

主要チャネル: developerCommunity, CNCF, GitHub, documentation

標準化プロダクトでは、全機能を自社で囲うより、計測・転送・保存の境界を明確にする方が採用を広げやすい。

OSSでは仕様の読みやすさと移行導線がプロダクト体験になる。

日本では複数クラウドやSIer運用をまたぐ案件で、vendor-neutralなtelemetry schemaが効く。

導入時はCollectorの運用責任、個人情報のredaction、リージョン要件を先に決めるべきだ。