Apa Itu Canary Deployment? Panduan Praktis untuk Developer
Summary
Canary deployment mengirim versi baru ke sebagian kecil trafik sungguhan, sering 1% sampai 5%, sebelum semua orang mendapatkannya. Kamu membandingkan error rate dan latency dengan versi stabil, memperlebar potongan jika hasilnya sehat, dan mengembalikan bobot canary ke nol jika tidak. Metode ini membatasi kerusakan dari rilis buruk, tapi butuh metrik per versi dan trafik yang cukup agar hasilnya bermakna.
Apa itu canary deployment? Ini metode rilis di mana versi baru aplikasi kamu lebih dulu mendapat sebagian kecil trafik sungguhan, misalnya 1% sampai 5%, sementara pengguna lain tetap di versi lama. Kamu memantau error rate dan latency pada potongan trafik itu. Kalau hasilnya sehat, potongannya diperlebar. Kalau buruk, trafik dikembalikan ke versi stabil dan hampir tidak ada yang sadar. Itulah intinya. Sisa artikel ini membahas cara membuatnya berjalan di dunia nyata.
Kenapa disebut canary?
Dulu para penambang membawa burung kenari ke dalam tambang karena burung itu bereaksi terhadap gas beracun sebelum manusia merasakannya. Kenari yang berhenti berkicau adalah tanda untuk segera keluar. Canary deployment bekerja dengan cara yang mirip: sekelompok kecil pengguna mencoba kode baru lebih dulu dan menjadi peringatan dini. Glosarium CNCF menggambarkannya sebagai dua lingkungan, satu melayani trafik live dan satu lagi menjalankan kode yang diperbarui, dengan trafik dipindahkan secara bertahap mulai dari porsi kecil seperti 1%.
Di praktiknya, pengguna canary adalah pengguna sungguhan, dan staging tidak bisa memberikan itu. Production punya browser yang aneh, cache yang sudah basi, dan satu pelanggan dengan file impor 40 MB. Canary adalah cara untuk bertemu mereka sebelum semua orang bertemu bug kamu.
Bagaimana canary deployment bekerja?
Ada empat bagian utama, tidak ada yang rumit.
Dua versi berjalan berdampingan. Versi lama (stable) dan versi baru (canary). Keduanya harus bisa melayani request dalam waktu yang sama.
Pembagi trafik. Load balancer, ingress controller, service mesh, atau aturan CDN yang mengirim persentase tertentu ke canary.
Metrik yang bisa kamu percaya. Error rate, latency, dan minimal satu sinyal bisnis, misalnya checkout yang berhasil atau pendaftaran baru.
Aturan untuk lanjut atau membatalkan. Ditulis sebelum deploy, bukan dibuat dadakan jam 11 malam sambil menatap grafik.
Ramp yang umum terlihat seperti 1%, 5%, 25%, 50%, lalu 100%, dengan jeda di setiap tahap. Google Cloud Deploy mendokumentasikan pola yang sama: kamu mendefinisikan serangkaian persentase dan tool-nya membagi trafik, dengan contoh tahap 25%, 50%, dan 75% sebelum versi stabil final. Dokumentasi canary Cloud Deploy juga menunjukkan bahwa tiap tahap bisa menjalankan verify job dan langkah analisis untuk memutuskan apakah tahap berikutnya dilanjutkan.
Ini bukan setup yang sempurna, tapi ini setup yang bisa dikerjakan. Kamu tidak perlu Kubernetes untuk menjalankannya. Weighted route di nginx, Worker di Cloudflare yang membagi trafik berdasarkan cookie, atau dua mesin Fly.io di belakang satu proxy, semuanya sudah termasuk.
Seperti apa pembagian trafik di konfigurasi?
Ini contoh paling sederhana yang berguna: upstream nginx dengan bobot. Sembilan dari sepuluh request masuk ke stable, dan satu ke canary.
upstream app {
server 10.0.0.10:3000 weight=9; # stable
server 10.0.0.11:3000 weight=1; # canary
}Ada satu kelemahan yang perlu kamu tahu. Pembagiannya dilakukan per request, jadi satu pengguna bisa bolak-balik antara dua versi saat mengklik dua halaman berurutan. Kalau versi baru mengubah bentuk response API atau kolom di database, pengguna itu akan mengalami masalah. Sticky routing berdasarkan cookie atau user ID memperbaikinya, dan ini hal pertama yang layak ditambahkan setelah pembagian dasarnya berjalan.
Apa yang harus dipantau selama canary berjalan?
Bandingkan canary dengan stable pada waktu yang sama, bukan dengan minggu lalu, karena minggu lalu punya trafik yang berbeda. Pertanyaannya selalu sama: apakah canary lebih buruk daripada versi yang sekarang melayani 95% pengguna lainnya?
Error rate. HTTP 5xx dan exception yang tidak tertangani, dipisah per label versi.
Latency. p95 dan p99, bukan rata-rata. Rata-rata menyembunyikan ekor lambat, tempat regresi biasanya bersembunyi.
Saturasi. CPU, memori, dan koneksi database. Memory leak terlihat sebagai kemiringan grafik, jadi beri waktu yang cukup.
Satu metrik bisnis. Kalau checkout yang berhasil turun di canary sementara error tetap datar, kamu baru saja mengirim bug diam-diam.
Kesalahan yang paling sering kami lihat di tim kecil adalah ramp berbasis timer. Lima menit di 1%, lalu naik ke 25%, tanpa peduli apa kata grafiknya. Dengan trafik rendah, lima menit di 1% mungkin hanya enam request, dan itu tidak memberi tahu apa-apa. Tunggu jumlah request minimum, bukan jumlah menit minimum.
Tool yang membuat proses ini tidak terlalu manual layak kamu lihat begitu trafik sudah nyata.
Canary atau blue-green: mana yang sebaiknya dipilih?
Blue-green menjaga dua lingkungan penuh dan memindahkan seluruh trafik sekaligus. Rollback-nya cukup membalik arah, cepat dan bersih. Harganya, untuk sesaat 100% pengguna berada di versi baru, dan kamu membayar infrastruktur dua kali lipat selama proses peralihan.
Canary hanya memaparkan sebagian kecil, jadi dampak bug lebih kecil. Harganya kompleksitas: kamu butuh pembagian trafik berbobot, metrik per versi, dan aturan keputusan. Rollback berarti mengatur bobot canary ke nol. Ini cepat, tapi tidak benar-benar instan kalau koneksi yang masih berjalan perlu dikosongkan dulu.
Ada tiga alasan memilih canary dan satu alasan untuk tidak memilihnya. Pilih canary ketika bug di production itu mahal, ketika trafik kamu cukup banyak agar potongan kecil bermakna, dan ketika kamu bisa membandingkan metrik per versi. Lewati canary kalau pengguna kamu hanya beberapa puluh orang sehari. Potongan canary akan kosong secara statistik dan kamu hanya menebak-nebak. Di skala itu, blue-green atau bahkan deploy biasa dengan script rollback yang cepat adalah jawaban yang jujur.
Rolling update berada di tengah. Mereka mengganti instance satu per satu, cara yang lembut, tapi itu bukan eksperimen terkontrol: kamu tidak memilih siapa yang melihat versi baru dan tidak membandingkan kelompok pengguna.
Di mana feature flag masuk?
Canary deployment membagi trafik antar versi kode. Feature flag membagi perilaku di dalam satu versi. Orang sering mencampuradukkan keduanya, dan kebingungan itu mahal.
Deploy kode baru ke semua orang, disembunyikan di balik flag yang masih mati. Lalu nyalakan flag untuk 1% pengguna, kemudian 10%, lalu semuanya. Ini sering disebut canary release di level fitur. Keuntungannya, rollback cukup dengan mematikan flag tanpa deploy ulang. Kekurangannya, jalur kode yang tidak aktif ikut berada di production untuk semua orang, dan flag yang terlupakan berubah menjadi utang teknis.
Urutan yang aman biasanya begini: flag dulu, canary setelahnya, lalu bersihkan flag begitu fitur sudah stabil. Untuk developer solo, flag biasanya langkah pertama yang lebih murah. Sebuah boolean di tabel konfigurasi dan hash dari user ID sudah memberi sekitar 80% manfaatnya. Kalau kamu sudah melampaui itu, layanan terkelola menangani targeting, audit log, dan rollout persentase bertahap.
Apa yang biasanya salah pada canary di proyek nyata?
Ini bukan setup yang sempurna, tapi kami tetap memakainya. Berikut kegagalan yang benar-benar menggigit.
Migrasi database. Kedua versi menyentuh database yang sama pada saat yang sama. Kalau canary menghapus atau mengganti nama kolom, stable ikut rusak. Solusinya pola expand and contract: tambahkan kolom baru dulu, rilis kode yang menangani keduanya, dan hapus kolom lama hanya di rilis berikutnya. Lewatkan ini dan canary kamu akan menjatuhkan versi stable.
Sesi stateful. Kalau sesi disimpan di memori satu instance, pengguna yang berpindah-pindah antar versi akan ter-logout. Pindahkan state sesi ke penyimpanan bersama sebelum mencoba canary.
Cache yang rusak. Versi baru yang menulis format cache berbeda bisa merusak data yang dibaca versi lama. Beri versi pada cache key kamu.
Background job. Canary juga mengonsumsi pesan dari antrean. Worker yang bermasalah bisa menghabiskan job dengan kecepatan penuh, karena persentase trafik tidak membatasi konsumsi antrean. Beri canary antrean sendiri atau bobot consumer tersendiri.
Alert yang tidak pernah dipasang. Canary bisa gagal dengan keras di dashboard yang tidak pernah dibuka siapa pun. Abort otomatis berdasarkan ambang lebih baik daripada manusia yang memantau, terutama jam 2 pagi di Jakarta atau Surabaya, saat satu-satunya orang yang bangun adalah orang yang barusan melakukan deploy.
Bagaimana memulai canary di side project?
Mulailah lebih kecil dari yang kamu kira. Kamu seorang developer, bukan tim platform.
Beri label versi di setiap metrik. Taruh git SHA di header dan di log. Tanpa ini, kamu tidak bisa membandingkan canary dan stable sama sekali.
Pilih satu aturan abort. Misalnya: error rate canary di atas 2x stable selama lima menit berarti rollback. Satu aturan, tertulis.
Tambahkan weighted route. Bobot nginx, aturan Cloudflare, atau fitur traffic splitting dari host kamu. Kebanyakan platform terkelola sekarang sudah menawarkan routing berbasis persentase tanpa tool tambahan.
Kirim sesuatu yang membosankan dulu. Perubahan copy, bukan rewrite halaman harga. Latih ramp dan rollback saat tidak ada yang dipertaruhkan.
Ukur waktu rollback. Jalankan sekali sungguhan. Kalau butuh sepuluh menit untuk meraba-raba, itu yang perlu diperbaiki, bukan ramp-nya.
Kalau proyek kamu masih di tahap mencari tahu siapa yang mau membayarnya, ini mungkin terlalu dini. Kirim saja dengan sederhana, simpan script rollback, dan kembali ke canary ketika outage akan merugikan pelanggan sungguhan. Kalau sudah sampai di tahap itu, weighted route plus satu aturan abort adalah pekerjaan satu akhir pekan, dan hasilnya langsung terasa saat rilis buruk mati di 1% alih-alih di 100%. Simpan juga catatan singkat setiap ramp: jam berapa bobot dinaikkan, metrik apa yang dilihat, dan keputusan apa yang diambil. Catatan ini berguna saat kamu harus menjelaskan rollback ke tim, atau ke diri sendiri tiga minggu kemudian.
Apakah semuanya harus di-canary?
Tidak. Perubahan konfigurasi, tweak copy, dan perbaikan typo di footer tidak perlu ramp. Pakai canary untuk perubahan yang kalau salah akan merugikan uang atau kepercayaan: pembayaran, autentikasi, model data, apa pun yang menyentuh hot path. Pipeline yang meramp setiap commit selama satu jam akan dilewati begitu seseorang sedang terburu-buru, dan proses yang selalu dilewati lebih buruk daripada tidak ada proses sama sekali.
Jadi, apa perubahan paling berisiko di rilis kamu berikutnya, dan apa yang dibutuhkan untuk mengirimnya ke 1% pengguna dulu?