OpenTelemetryのGo対応：コンテキスト伝搬なしでもトレース親子関係を維持する「GLS」機構の仕組みを深掘り
本記事は、Go言語におけるOpenTelemetry（OTel）のコンパイル時計装ツール（otelc）が採用している、高度なトレース親子関係維持の仕組み「GLS（Goroutine-Local Storage）」について詳細に解説しています。Goの標準的なAPI規約では、トレースの親子関係は`context.Context`を通じて伝搬されることが前提となっています。しかし、`database/sql`のようなライブラリのメソッド（例：`db.QueryRow`）など、呼び出し元から明示的に`context.Context`を受け取らないレガシーコードやライブラリコードが存在する場合、親となるSpanが失われ、トレースが途切れてしまうという問題があります。GLSは、この「コンテキストを渡さない呼び出し境界」におけるギャップを埋めるための互換レイヤーです。
GLSの仕組みは、単なるライブラリの修正に留まらず、Goのランタイム自体を改造することにあります。具体的には、Goのゴルーチン（goroutine）の実体である`runtime/g`構造体に、トレースコンテキストを保持するための専用フィールド（`otel_trace_context`など）をコンパイル時に注入します。これにより、各ゴルーチンが自身のローカルなスタックにアクティブなSpanを積むことが可能になります。Spanが開始される際にはスタックにプッシュされ、終了時にはポップされます。
最も重要なのは、`trace.SpanFromContext`というAPIへのフックです。通常、空の`context.Background()`を渡した場合、このAPIは無効なSpanを返しますが、otelcはここに介入し、コンテキスト内にSpanがない場合、代わりにGLSスタックの最上位にある「現在アクティブなSpan」を返します。実験例として、`db.QueryRow`のような`ctx`なしのDBクエリを実行した場合でも、このGLSのフックが働き、HTTPリクエストのSpanを親として認識させることで、SQLのSpanが元のHTTPリクエストのトレースに正しく紐づけられることを実証しています。この実装は、コンパイル時にランタイムレベルでコードを書き換えるという、otelcならではの高度な技術的アプローチに基づいています。
背景
マイクロサービス化が進む現代のシステムでは、分散トレーシングによる可観測性（Observability）の確保が必須です。Go言語では、トレースの親子関係を`context.Context`で管理するのが標準規約ですが、多くの既存ライブラリやレガシーコードは、このコンテキストを呼び出し境界で適切に引き渡さない場合があります。この「コンテキスト伝搬の欠如」が、トレースの断片化を引き起こす主要な課題でした。
重要用語解説
- OpenTelemetry (OTel): 分散システムにおける可観測性（Observability）を標準化するためのオープンな仕様群。トレース、メトリクス、ログを統一的に収集・分析することを可能にします。
- otelc: OpenTelemetryのコンパイル時計装ツール。Goのビルドプロセスに介入し、ソースコードを書き換えることで、アプリケーションコードに手を加えずにトレース機能（Spanの生成など）を組み込みます。
- GLS (Goroutine-Local Storage): Goのゴルーチン（軽量スレッド）ごとに、特定のデータをローカルに保持するための仕組み。本記事では、このGLSを利用して、コンテキストが渡されない状況でもアクティブなSpanを保持・参照しています。
今後の影響
GLSの実装は、Go言語におけるOTelの採用障壁を大幅に下げます。これにより、開発者はライブラリの内部実装を気にする必要がなくなり、既存の複雑なコードベースに対しても高い精度でトレースを適用できるようになります。結果として、本番環境でのボトルネック特定や障害原因究明の効率が飛躍的に向上します。