การทยอยปล่อยแบบ Canary: ส่งให้ผู้ใช้บางส่วนก่อน

A canary rollout sends your new model to a small slice of real traffic first, so any damage stays tiny while you watch. 🐤

Flipping all traffic to a fresh model at once is a big-bang deploy: if it is wrong, every single user feels it instantly.

Canaries usually begin around 5% of traffic. That is enough to gather real signal, but small enough that a bad model barely dents your users.

The stable model is the champion; the canary is the challenger. Both run live at once so you can compare them on the same real requests.

While the canary serves its slice, you monitor error rate, latency, and key business metrics, side by side against the champion.

If the canary looks healthy, you ramp its share up in stages, say 5%, 25%, 50%, then 100%, pausing to check at each level.

A router or proxy decides which model each request hits. This simple split sends one in twenty calls to the canary version.

Log which model handled each request. Without a version tag on every prediction, you cannot tell whose metrics are whose later.

Route by a stable hash of user id so the same person always lands on the same model. Random per-request splits make a fair comparison harder.

The whole point is a quick exit. If the canary misbehaves, you drop its traffic back to 0% and users never noticed a thing.

Blue-green keeps two full environments and flips between them. A canary instead leaks traffic gradually, giving you finer control and earlier warning.

Let us check the core idea behind a canary.

A canary ships your new model to a tiny slice first, compares it against the champion, ramps up only if healthy, and rolls back instantly if not. ✅