Description
Sometimes we need to switch storage implementations from one type to another or due to a schema incompatibility. For example, you may switch from mysql to cassandra, or from cassandra to cassandra3, or from elasticsearch 2.x to 6.x. Data migration or maintaining multiple copies of storage code is one way out, but due to the normal aging of trace data, another one is a fan-out proxy. This discusses the fan-out proxy approach.
The proposal is to use a MIGRATING_FROM variable whose value is the query endpoint of an existing install (ex http://zipkin-v129:9411). When in a transition, you leave an old service up until your migration is complete. The master runs the new code and queries across itself and the MIGRATING_FROM until the latter is unset.
For example, given an environment which you want to upgrade, like so
.─────────.
,─' '─.
╱ ╲
╱ ╲
; :
: Applications ;
.─────────. : ;
,' `. : ;
( Zipkin UI ) `. ,'
'─. ,─' '─. ,─'
`───┬───' │───────'
│ │
│ ┌──────────┘
│ │
┌───────▼─────────────▼──────┐
│ ┌───────────┐ ┌─────────┐ │
│ │ Query Api │ │Collector│ │
│ └──────┬────┘ └──┬──────┘ │
│ │ │ │
│ ┌────▼─────────▼────┐ │
│ │ Elasticsearch 5.x │ │
│ │ Storage Component │ │
│ │ │ │
│ └───────────────────┘ │
│ Zipkin 1.29 │
└────────────────────────────┘
You'd install a new versions and point users to it, setting MIGRATING_FROM to the old version. At this point, you can immediately cut write traffic to it, or at some point in the future. The new version will query across itself and the other.
.───────.
,─' '─.
; Migrated :
┌────────────────────: Applications ; .───────.
│ ╲ ╱ ,─' '─.
│ .─────────. '─. ,─' ╱ ╲
│ ,' `. `─────' ; Applications :
│ ( Zipkin UI ) : ;
│ '─. ,─' ╲ ╱
│ `──┬────' ╲ ╱
│ │ '─. ,─'
│ │ `──┬──'
┌─────────▼───────────▼──────┐ │
│ ┌───────────┐ ┌─────────┐ │ ┌────────────────┐ │
│ │ Collector │ │Query Api├─┼─┤ Migrating From │ │
│ └──────┬────┘ └──┬──────┘ │ └────────────┬───┘ │
│ │ │ │ │ │
│ ┌────▼─────────▼────┐ │ │ │
│ │ Elasticsearch 6.x │ │ │ │
│ │ Storage Component │ │ ┌───────▼────────────▼───────┐
│ │ │ │ │ ┌───────────┐ ┌─────────┐ │
│ └───────────────────┘ │ │ │ Query Api │ │Collector│ │
│ Zipkin 1.30 │ │ └──────┬────┘ └──┬──────┘ │
└────────────────────────────┘ │ │ │ │
│ ┌────▼─────────▼────┐ │
│ │ Elasticsearch 5.x │ │
│ │ Storage Component │ │
│ │ │ │
│ └───────────────────┘ │
│ Zipkin 1.29 │
└────────────────────────────┘
This eliminates the need to keep multiple copies of storage code in the same process. Since retention is usually days, you can simply cutoff the MIGRATING_FROM when you are ready.