zipkinを移行している話

トレーシングツールとしてzipkinを利用しているのですが、稼働時からサーバのバージョンを上げておらず、クライアント側のバージョンアップでまともに動かない状態になっていたのを更新している話。

今までの構成

構築されたころからのしがらみや人的リソースがないなどの理由から、あまり良い構成とはなっておらず、下記のような状態でした。

f:id:paihu:20191106213636p:plain
Before

データセンター側にzipkinサーバがあり、ストレージとして、AWSのElasticsearchServiceを利用しています。

トレーシング情報を送信するアプリケーションサーバAWS上にあり、わざわざデータセンターまでトレーシング情報を送信していました。

移行後の構成

流石にまずいと、構成含め、色々話をして下記のような構成に移しました。

f:id:paihu:20191106214246p:plain
After

全てがAWS上にあり、完結しています。

雑感

構築する上で特に大きく躓いた箇所はないけれど、アプリケーションには、zipkinライブラリが組み込まれており、zipkin v1のトレーシング情報を送ってくるものと、v2のトレーシング情報を送ってくるものが混じっていたこともあり、送信側を修正するのは大掛かりになりすぎるため、行わないという判断をしています。

また、今のところzipkinを引き続き利用しているけれど、AWS X-Rayや、Jaeger、その他、マネージドサービスに置き換えたいという話もあり、拡張性を見越して opentelemetry collector を アプリケーションとzipkinサーバの間に挟んでいます。これにより、将来、移行したい場合は、opentelemetry collectorの設定変更などで対応ができるようになっています。

今後、使いやすい分散トレーシングサービスが出てきても、opentelemetry に対応してさえくれれば、おそらく、構成を大きく変えることなく、使い続けられるだろうと思っているので、満足度の高い構成変更になったと思っています。