Zipkinのシステム開発の完全ガイド - ブログ

Zipkinのシステムとは、マイクロサービス間を流れる1件のリクエストを追跡し、遅延やエラーの発生箇所を可視化するオープンソースの分散トレーシング基盤です。

モノリスでは画面の遅さを1つのアプリケーション内で調べられましたが、認証、注文、在庫、決済、通知などが分かれたシステムでは原因が下流サービスや外部APIに隠れます。本記事では、Zipkinの基本概念から本番アーキテクチャ、導入の進め方、費用相場、セキュリティ、OpenTelemetryとの関係、開発会社・ベンダーの選び方まで、導入判断に必要な情報を順番に解説します。

Zipkinのシステムとは何ですか？

Zipkinは、分散したサービスをまたぐリクエストの経路と処理時間を記録し、1つの画面で追跡するためのシステムです。販売管理やERPのように業務データを登録・更新する業務システムそのものではなく、業務システムが正常に動いているかを調べる運用基盤として位置づけると理解しやすいです。

分散トレーシングで何が分かりますか？

例えば、利用者が注文画面を開いたとき、APIゲートウェイから認証、商品、在庫、決済、通知へ処理が順番に進んだとします。Zipkinでは、各処理の開始時刻、終了時刻、サービス名、HTTPメソッド、ステータス、エラー、タグなどを同じリクエストの記録として確認できます。そのため、全体で3秒かかった処理のうち、在庫サービスが2秒を占めている、外部決済への接続でタイムアウトした、といった切り分けが可能です。

Zipkinが向いているシステムはどのようなものですか？

複数のAPIやコンテナ、非同期メッセージ、外部サービスを組み合わせるシステムに向いています。特に、サービス単位のログだけでは1件の処理を追えない、障害の再現が難しい、性能問題の調査に担当者の経験と時間がかかる、といった課題がある場合に効果を発揮します。一方、単一アプリケーションで処理が完結し、既存ログとメトリクスだけで原因を十分に把握できる場合は、最初から大規模なトレーシング基盤を構築する必要はありませんので、優先度を下げても問題ありません。

Zipkinのシステムを理解する基本概念と種類

Zipkinを導入するときは、製品名だけでなく、trace、span、ID、計装という4つの言葉を押さえることが重要です。また、ログやメトリクスとの役割を分けて考えると、Zipkinに過剰な期待をせず、必要な構成を選びやすくなります。

trace・span・trace ID・span IDの違い

traceは、利用者の1回の操作や1件のリクエスト全体をまとめた単位です。spanは、そのtraceを構成する個々の処理で、認証、DB検索、外部API呼び出しなどが該当します。trace IDは全体を識別する番号、span IDは各処理を識別する番号です。親子関係を持つspanを時系列に並べることで、ウォーターフォール形式の画面から処理の順番と待ち時間を読み取れます。

ログ・メトリクス・トレースの役割分担

ログは「何が起きたか」という詳細なイベント記録、メトリクスはCPU使用率やエラー率、応答時間などの時系列の数値、トレースは「1件の処理がどのサービスをどう通ったか」を表します。例えばメトリクスで注文APIの95パーセンタイルが悪化した時間帯を見つけ、traceで遅いリクエストを特定し、最後にログで例外内容を確認するという連携が基本です。Zipkinだけで監視・通知・監査まで完結するわけではないため、既存のログ基盤やメトリクス監視との相関を最初から設計します。

自前運用・Collector併用・SaaS利用の違い

導入方式は、Zipkinサーバーを自社環境で運用する方式、OpenTelemetry Collectorなどの中継基盤を挟んでZipkinへ送る方式、トレース機能を持つ商用サービスへ送る方式に大別できます。自前運用はデータの保管場所やカスタマイズを管理しやすい一方、可用性、バックアップ、アップデート、アクセス制御を自社で担います。Collector併用は計装と保存先を分離でき、将来のバックエンド変更に備えやすい方式です。SaaS利用は初期構築を抑えやすい一方、データ量、ホスト数、保持期間、契約条件によって月額が変わります。

Zipkinのシステム構成とデータの流れ

本番のZipkinは、Dockerコンテナを1つ起動するだけではなく、アプリケーション側の計装、送信、収集、保存、検索、閲覧を一つの流れとして設計します。公式アーキテクチャでは、トレーサーがアプリ内でspanを記録し、Reporterがcollectorへ送信し、保存先を検索APIが読み取り、Web UIが結果を表示します（出典: OpenZipkin公式アーキテクチャ、2026年確認）とされています。

▶ 詳細はこちら：Zipkinのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

アプリケーションの計装とコンテキスト伝搬

計装とは、Webサーバー、HTTPクライアント、データベースドライバ、メッセージング処理などにトレース記録の仕組みを組み込むことです。入口で作成したtrace IDを下流サービスへ伝搬できなければ、サービスごとに別のtraceが作られてしまい、全体を追跡できません。HTTPではリクエストヘッダー、非同期処理ではメッセージのメタデータなどを使い、同期・非同期の両方でコンテキストを引き継ぐ設計が必要です。

collector・storage・検索API・UIの役割

collectorはspanを受け取り、形式を検証し、必要に応じてバッチ化やサンプリングを行って保存先へ渡します。storageはトレースを一定期間保持し、検索APIはサービス名、時間、アノテーションなどを条件にデータを取得します。UIはそのAPIを利用して、サービス間の親子関係と処理時間を人が読める形にします。公式のサーバー拡張ではHTTP、Kafka、RabbitMQなどの受信経路や、インメモリ、MySQL、Cassandra、Elasticsearchなどの保存先が選択肢として示されています（出典: OpenZipkin公式サーバー拡張情報、2026年確認）とされています。

本番環境で追加すべき設計

PoCではインメモリ保存でも画面を確認できますが、本番では保存期間、容量上限、障害時の再送、バックアップ、復元、collectorの冗長化を決めます。ZipkinのWeb UIには標準で認証機能がないため、社内ネットワークに閉じる、認証プロキシを置く、アクセス元を制限するなどの防御も必要です。通信はTLSで保護し、保存先の読み取り権限を運用担当者に限定し、誰がどのtraceを閲覧したかを監査できる状態にします。

Zipkinのシステム開発・導入の進め方

導入は、Zipkinを起動して終わる作業ではなく、改善したい業務フローを定義し、少数サービスで効果を検証し、本番へ段階的に広げるプロジェクトです。最初から全サービスを計装するとデータ量と不具合の切り分けが難しくなるため、代表的な業務フローを選んで検証します。

要件定義・企画フェーズ

まず「Zipkinを入れる」ではなく、何を改善するかをKPIにします。例えば、注文APIの95パーセンタイル応答時間、障害の平均切り分け時間、重要業務フローのうちtraceを確認できる割合、リトライやタイムアウトの検知時間などです。対象サービス数、1日のリクエスト数、ピーク時の同時実行数、外部API、メッセージング、個人情報の有無、必要な保持期間を棚卸しし、アプリ担当、インフラ担当、セキュリティ担当、運用担当の責任分界を決めます。

PoCと設計・開発フェーズ

最初は2〜5サービス程度に絞り、入口から下流までtrace IDがつながるかを確認します。正常系だけでなく、DBの遅延、外部APIのタイムアウト、HTTPエラー、リトライ、非同期メッセージの遅延を再現し、UIでどこまで原因を追えるかを試します。JavaやSpring系ではBrave、Micrometer Tracing、OpenTelemetry SDKなどを候補にできますが、Node.js、Python、Goなどでは自動計装の対象範囲が異なるため、言語とフレームワークごとに対応状況を検証します。

テスト・リリース・運用引き渡し

本番前には、負荷試験でspanの増加量とアプリケーションへのオーバーヘッドを測定します。collector停止時に業務処理が止まらないか、保存先の容量が上限に達したときにどう縮退するか、ネットワーク切断後に再送できるかも確認します。最後に、ダッシュボードの見方、trace IDを使ったログ検索、サンプリング率の変更、データ削除、障害時の連絡先を手順書にまとめ、運用担当者が開発者の個人判断に頼らず調査できる状態にして引き渡します。

OpenTelemetryとZipkinはどのように使い分けますか？

結論から言うと、Zipkinは主にtraceを保存・検索・表示するバックエンドとUI、OpenTelemetryは計装・データ収集・標準化を担う基盤です。両者は競合する製品というより、OpenTelemetryでアプリを計装し、Collectorを経由してZipkinへ送る組み合わせで利用できます。新規設計では、保存先を固定しすぎないためにOpenTelemetryとOTLPを入口にする構成が現実的です。

Collectorを中継するメリット

OpenTelemetry Collectorは、テレメトリを受信し、処理し、複数の宛先へ出力する実行ファイルです。公式ドキュメントでは、パイプラインをreceiver、processor、exporterで構成し、processorで属性の削除やサンプリングを行い、複数のexporterへ分岐できる設計が説明されています（出典: OpenTelemetry Collector公式アーキテクチャ、最終更新2026年3月）。この中継層を置くと、アプリケーションを毎回改修せずに、開発・検証・本番の送信先やデータ削減ルールを切り替えやすくなります。

2026年時点の新規導入・移行方針

OpenTelemetryは2025年12月にZipkin exporterの仕様を非推奨化し、既存の安定版exporterについては少なくとも2026年12月までセキュリティ修正と重大なバグ修正を続ける方針を示しています（出典: OpenTelemetry公式ブログ、2025年12月・2026年2月更新）。新規案件で古いZipkin exporterだけを標準にするのではなく、アプリからOTLPで送ってZipkinのOTLP取り込みを使うか、Collectorで受信してZipkinへ出力する設計を優先します。

既存環境は急いで一斉移行する必要はありません。まず現在のexporter、SDKのバージョン、データ形式、保存期間、送信失敗時の挙動を棚卸しし、Collectorを並行稼働させます。次に少数サービスをOTLPへ切り替え、trace IDの連続性、span属性、件数、検索結果、障害時の復旧を比較し、問題がなければ業務影響の小さいサービスから段階的に移行します。

Zipkinのシステム開発にかかる費用相場

Zipkin単体の国内受託開発価格を示す公的な統計は確認できないため、以下は業務システム全般の相場と、分散トレーシング導入で必要になる作業範囲から算出した編集用の推定です。実際の金額は、対象サービス数、利用言語、Kubernetesの有無、既存ログ基盤、保持期間、可用性、夜間対応によって大きく変わります。したがって、金額だけでなく前提条件と成果物をそろえて比較することが大切です。

▶ 詳細はこちら：Zipkinのシステム開発の見積相場や費用/コスト/値段について

導入パターン別の初期費用と期間

学習・PoCなら50万〜200万円、期間は2〜6週間が一つの目安です。Dockerでの起動、2〜5サービスの基本計装、代表シナリオの確認までに絞った範囲です。5〜20サービスを対象にした小規模本番は300万〜800万円、期間は1〜3か月程度となり、TLS、永続ストレージ、権限、ダッシュボード、運用手順書まで含めて考えます。

20〜100サービス、Collector、コンテナ基盤、サンプリング、負荷試験、既存監視との相関まで行う中規模本番は800万〜2,000万円、3〜6か月程度が推定レンジです。複数クラスタ、複数リージョン、長期保持、SIEM連携、24時間運用まで求める大規模・高可用性案件は2,000万〜5,000万円以上、6〜12か月以上になる場合があります。これはZipkin本体の価格ではなく、計装・基盤・テスト・運用設計を含む導入プロジェクトの費用です。

ランニングコストの内訳

OSS自体のライセンス費用が無料でも、クラウドやサーバー、ストレージ、バックアップ、監視、保守、アップデート、障害対応の費用は発生します。自己運用の小規模構成では月20万〜60万円、中規模では月60万〜200万円程度を編集用の推定レンジとしますが、保守担当者の稼働を含むかどうかで見え方が変わります。初期開発費の年15〜25％を保守費の目安にする考え方もありますが、トレース量が増えた場合は別途見直します。

クラウド型の公開料金例では、2026年2月以降の新規利用について、ホスト時間が1時間あたり0.025米ドル、trace・log・profileの取り込みが1GBあたり0.50米ドルという体系が示されています（出典: Application Observability公開料金表、2026年）。別のサービスでも、100GBまで無料、超過分を1GB単位で課金、ホスト単位またはユーザー単位で課金、といった方式があります。料金を比較するときは、1日あたりのspan数をGBへ換算し、採取率、保持日数、バックアップ、検索期間を含めて月額を試算します。

Zipkinの開発会社・ベンダーの選び方

Zipkinの開発会社・ベンダーを選ぶときは、Dockerを起動できるかではなく、計装から運用引き渡しまでを設計できるかを確認します。Zipkin専用の公開実績だけに限定すると候補が狭くなるため、分散トレーシング、OpenTelemetry、APM、クラウドネイティブ基盤、ログ相関の実績を広く確認し、今回の要件に適用できるかを質問します。

計装・Collector・既存監視の技術力を確認する

見積もり前に、JavaやSpring、Node.js、Python、Goなど自社の利用言語に対応できるか、HTTPとメッセージングをまたいでコンテキストを伝搬できるか、DBや外部APIまでspanを作れるかを確認します。さらに、Collectorのreceiver・processor・exporter、サンプリング、属性のマスキング、複数宛先への分岐を誰が設計するのかを明確にします。既存ログのtrace ID検索、メトリクスからtraceへの導線、通知の条件までデモで示せる相手なら、導入後の運用をイメージしやすいです。

セキュリティ・運用・引き継ぎの範囲を確認する

本番では、TLS、認証プロキシ、RBAC、ネットワーク分離、保存期間、削除手順、アクセス監査、バックアップ復元、collector障害時の縮退を設計します。提案書に「監視導入」とだけ書かれている場合は、計装対象、採取率、1日span数、保持日数、容量上限、アラート、夜間対応、SLA、運用教育を具体化してもらいます。納品物も設定ファイルだけでなく、構成図、データ分類表、テスト結果、障害対応手順、変更手順、担当者向けの操作説明まで含めて比較します。

見積もり依頼で伝えるべき情報

依頼時には、対象サービス数、サービスごとの言語と実行基盤、1日リクエスト数、1日span数の想定、ピーク同時実行数、保持日数、開発・検証・本番の環境数、既存ログとメトリクスの有無、個人情報の扱い、必要な可用性、24時間対応の有無を伝えます。PoCのみか本番運用までか、既存Zipkinを移行するのか、新規に構築するのかも分けて記載します。要件が同じ状態で複数の提案を比べると、初期費用の安さだけでなく、運用費と将来の移行費まで含めた総額を判断できます。

▶ 詳細はこちら：Zipkinのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Zipkinのシステム開発の発注/外注/依頼/委託方法について

セキュリティと運用で失敗しないための注意点

トレースは障害調査に役立つ一方、URL、ヘッダー、タグ、baggage、ログとの相関情報に機密情報が混ざる可能性があります。業務データを詳細に記録するほど便利になるとは限らないため、収集する属性を定義し、不要な情報を最初から記録しない設計にします。

記録してはいけない情報とマスキング

アクセストークン、パスワード、暗号鍵、データベース接続文字列、決済情報、要配慮個人情報、セッション識別子は、span属性やログへ直接入れないようにします。OWASPのLogging Cheat Sheetでも、アクセストークン、認証パスワード、暗号鍵、決済カード情報、機微な個人情報などは除外・マスク・ハッシュ化・暗号化の対象として示されています（出典: OWASP Logging Cheat Sheet、2026年確認）。必要な場合は一方向の識別子や業務上意味のない分類値へ置き換え、元データを復元できない形にします。

サンプリングと保持期間を設計する

全リクエストを保存すると、データ量、検索負荷、ストレージ費用が増えます。通常系を一定割合で採取するhead sampling、処理結果を見て高レイテンシーやエラーを残すtail sampling、開発・検証・本番で異なる採取率を組み合わせます。例えば本番の正常系は低い割合、エラーやタイムアウトは高い割合で残す設計が考えられますが、採取率を下げる前に、KPIを計測できる件数が確保されるかを確認します。

よくある失敗と改善策

よくある失敗は、全サービスを一度に計装してデータ量が想定を超えること、入口と下流でtrace IDが切れること、トレースのタグ名がサービスごとにばらばらになること、UIを誰でも閲覧できる状態で公開することです。改善策は、代表フローのPoC、属性命名規約、負荷試験、アクセス制御、保持期間の上限を先に決めることです。また、collectorや保存先が停止しても業務処理を止めないため、送信を非同期にし、タイムアウトやバッファの上限を設けます。

よくある質問（FAQ）

ここでは、Zipkinのシステム導入を検討するときに寄せられやすい質問へ、判断の基準を簡潔に回答します。自社のサービス数、データ量、運用体制に当てはめて確認してください。

Zipkinは無料で使えますか？

ZipkinのOSS本体はライセンス費用を抑えて利用できますが、導入費用と運用費用がゼロになるわけではありません。サーバー、ストレージ、バックアップ、計装、保守、監視、セキュリティ対応の費用が発生するため、初期費用と月額費用を分けて見積もります。

モノリスのシステムにもZipkinは必要ですか？

単一アプリケーションで処理が完結し、ログとメトリクスで十分に原因を追えるなら、優先度は高くありません。ただし、外部API、DB、キュー、バッチ、別プロセスをまたぐ場合や、将来の分割を見据えて処理境界を把握したい場合は、一部の重要フローから導入する価値があります。

新規開発ではZipkin exporterを使い続けてもよいですか？

新規開発では、OpenTelemetryとOTLPを入口にし、必要に応じてZipkinのOTLP取り込みやCollectorを経由する設計を優先します。既存の安定版Zipkin exporterは2026年12月までの修正方針が示されていますが、SDKや言語によって提供状況が異なるため、採用するライブラリのサポート期間を確認してから決めます。

開発会社へ相談するときに何を準備すればよいですか？

システム構成図、対象サービスと利用言語、環境数、1日リクエスト数、ピーク時の負荷、障害事例、保持期間、既存ログ・監視基盤、セキュリティ制約を準備します。PoCだけか本番運用までか、運用を自社で担うか、夜間対応が必要かも明記すると、計装工数と基盤費用を含んだ比較しやすい提案を受けられます。

まとめ

Zipkinのシステムは、マイクロサービスや分散システムの1件のリクエストをtraceとして追跡し、どのサービスで遅延やエラーが生じたかを可視化する基盤です。trace、span、trace ID、span IDを理解し、ログとメトリクスを組み合わせることで、障害対応と性能改善の精度を高められます。

導入は、目的とKPIの定義、2〜5サービスのPoC、計装とコンテキスト伝搬の検証、本番アーキテクチャの設計、負荷・障害・セキュリティ試験、運用引き渡しの順に進めます。費用はPoCで50万〜200万円、小規模本番で300万〜800万円、中規模本番で800万〜2,000万円程度を推定の起点とし、span数、保持期間、可用性、運用体制で調整します。

2026年時点の新規設計では、OpenTelemetryとOTLPを軸にし、Zipkinまたは別のバックエンドへ柔軟に出力できる構成が将来性の面で有力です。開発会社・ベンダーを選ぶ際は、個別の起動実績だけでなく、計装、Collector、データ量、マスキング、認証、バックアップ、障害訓練、運用引き継ぎまで含めて比較してください。