ZipkinはGoogleが2010年に公開した分散トレーシング論文「Dapper」を参考に、Twitter（現X）の社内エンジニアが2012年に開発・OSS化したトレーシング基盤です。Apache License 2.0で公開された最初期のオープンソース実装として、後発のJaegerやTempoの設計にも大きな影響を与えました。シンプルなアーキテクチャと豊富な言語クライアント、ScalaやJavaを中心としたJVMエコシステムでの導入実績が魅力で、現在もspring-cloud-sleuthなどフレームワーク連携の標準として現役利用されています。
この記事の目次
- Collector・Storage・APIの三層
- Twitterで生まれApache配下へ
- JVM中心のサービスで使う場面
- JaegerやSaaSとの棲み分け
- まとめ
Collector・Storage・APIの三層
Zipkinのアーキテクチャは極めてシンプルで、トレースデータの受信窓口（Collector）、保存層（Storage）、検索／表示用のAPIとUIという三層構造です。Collectorは HTTP / Kafka / RabbitMQ など複数のトランスポートでSpanを受け取り、StorageはインメモリのほかMySQL、Cassandra、Elasticsearch等が選べます。「とりあえず1台のJVMで全部動かす」モードと、本番向けに各コンポーネントを別ノードへ分離するモードの両方をサポートしており、初期検証から本番運用まで段階的にスケールアップできるのが、長年支持されている理由のひとつです。
クライアント側のライブラリは「Brave」というJavaライブラリが中核で、サーブレットフィルタやRestTemplateインターセプタを差し込むだけで自動計装できます。Pythonの py_zipkin、Rubyの zipkin-ruby、Go の zipkin-go、Node.js の zipkin-js など多言語クライアントが揃っており、B3伝播ヘッダ（X-B3-TraceId など）はOpenTelemetryでも互換オプションとして残るほどデファクト化しました。spring-cloud-sleuthが既定でZipkin形式を扱うため、SpringBoot系のJavaアプリでは導入が特に容易です。
Twitterで生まれApache配下へ
Twitterは2010年代初頭、モノリシックなRuby on Railsアプリ（俗称Monorail）から多言語マイクロサービスへ大規模移行する真っ最中で、サービス間呼び出しの遅延原因を突き止める手段に困っていました。Googleが2010年に公開したDapper論文をベースに、クリス・アニジュック、フランクリン・フシーらが2012年6月にZipkinをオープンソース公開しました。GitHubで世界に開かれた最初の本格的分散トレーシング実装として、多くの企業が自社運用を開始するきっかけになりました。
その後Twitter社からの直接的な貢献は減り、コミュニティ主導の「OpenZipkin」組織にGitHubリポジトリが移管されました。現在はAdrian Coleら独立コミッターが中心となって開発を続けています。2016年以降に登場したJaegerやOpenTelemetryと比べると派手な新機能は少ないものの、シンプルさと低リソース消費を武器に、レガシーJVMサービス群の監視基盤として根強く生き残っています。
JVM中心のサービスで使う場面
Zipkinが最も力を発揮するのは、Spring Bootベースのマイクロサービスを多数抱えるJVM中心の組織です。spring-cloud-sleuthを依存に追加するだけで、HTTPコントローラ、Feignクライアント、JDBC、Kafkaリスナーの呼び出しが自動でSpan化され、アプリ側のコードに手を加えずにフレームグラフが取得できます。Kafka越しのメッセージ送受信もB3ヘッダで連結できるため、非同期処理が絡む決済バッチや在庫連動のフローでも、リクエストの始まりから終わりまで途切れずに追えます。
UIにはサービスマップ表示があり、自動収集された呼び出し関係を有向グラフで可視化できます。「このサービスは想定外のサービスから呼ばれている」「依存が深すぎて単一障害点になっている」といったアーキテクチャ上の課題に、Excelやホワイトボードに頼らず気付けるのが利点です。OpenTelemetry Collectorは出力先（exporter）としてZipkinをサポートしているため、新規実装をOpenTelemetryで進めつつ既存のZipkin UIへ送るというハイブリッド構成も現実的な移行戦略となっています。
JaegerやSaaSとの棲み分け
後発のJaegerはCNCF Graduatedの肩書きとKubernetesとの親和性で勢力を伸ばし、新規導入では選ばれる比率が高くなっています。Grafana LabsのTempoはS3互換オブジェクトストレージにトレースを安価に長期保存できるOSSで、Loki／Prometheusと組み合わせた「LGTMスタック」の一員として支持を集めています。
Zipkinは新規案件で第一候補に挙がる頻度こそ減ったものの、Spring Boot文化圏での既存基盤としてはなお強力で、「無理にJaegerへ乗り換えるよりOpenTelemetry経由でデータを両側に送る」という延命策が現実的に選ばれます。SaaS型では、Datadog APMやHoneycomb、New Relicが運用負担を肩代わりしてくれる選択肢として併存しており、「自社運用のシンプルさを取るならZipkin、機能性を取るならJaeger、運用代行を取るならSaaS」というのが今の住み分けです。
まとめ
ZipkinはTwitter発・Dapper論文を最初に実装した由緒あるOSSトレーシング基盤で、現在もJVM中心のサービス群で根強く使われています。JaegerやTempoに新規導入の主役は譲りつつも、Spring Cloud Sleuthとの相性とB3伝播のデファクト性により、OpenTelemetry時代の出力先として現役のポジションを保ち続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント