Ketika Lima Persen Lalu Lintas Memberi Tahu Lebih Banyak daripada Lingkungan Staging

Beberapa minggu lalu, sebuah tim yang saya kenal melakukan deployment alur autentikasi baru. Lingkungan staging menunjukkan semua tes hijau, waktu respons yang dapat diterima, dan tidak ada error. Mereka mempromosikan build ke produksi, mengarahkan semua pengguna ke versi baru dalam hitungan menit. Tiga puluh menit kemudian, tiket dukungan mulai menumpuk. Pengguna di wilayah tertentu tidak bisa login. Lingkungan staging tidak pernah menangkapnya karena tidak memiliki pola lalu lintas yang realistis, latensi regional, atau campuran perangkat yang dimiliki produksi.

Tim tersebut melakukan rollback, tetapi kerusakan sudah terjadi. Pengguna kehilangan kepercayaan, dan tim menghabiskan dua hari berikutnya untuk melakukan debug pada masalah yang hanya muncul dalam kondisi produksi nyata.

Inilah celah yang coba ditutup oleh strategi progressive delivery. Alih-alih menyalakan saklar untuk semua orang, Anda mengekspos sebagian kecil pengguna atau lalu lintas ke versi baru terlebih dahulu. Anda mengamati apa yang terjadi. Kemudian Anda memutuskan apakah akan melanjutkan, menjeda, atau melakukan rollback.

Dua strategi umum untuk ini adalah canary release dan staged rollout. Keduanya terdengar mirip, tetapi memecahkan masalah yang berbeda. Memahami perbedaannya membantu Anda memilih pendekatan yang tepat untuk setiap perubahan yang Anda kirim.

Canary Release: Biarkan Lalu Lintas yang Memutuskan

Canary release dimulai dengan mengarahkan persentase kecil lalu lintas ke versi baru. Bayangkan aplikasi Anda menerima seratus permintaan per detik. Anda mengonfigurasi load balancer atau service mesh untuk mengirim lima permintaan tersebut ke server yang menjalankan versi baru. Sembilan puluh lima permintaan sisanya masih mengenai versi lama.

Anda kemudian memonitor sinyal-sinyal kunci: tingkat error, latensi, penggunaan CPU, performa kueri basis data. Jika versi baru terlihat sehat setelah beberapa menit, Anda meningkatkan porsi lalu lintas menjadi sepuluh persen, lalu dua puluh, lalu lima puluh, dan akhirnya seratus persen.

Ide kunci di sini adalah bahwa pembagiannya bersifat probabilistik. Pengguna mana pun mungkin berakhir di versi baru jika kebetulan menjadi permintaan kelima dari seratus. Pengguna tidak tahu versi mana yang mereka akses, dan mereka seharusnya tidak peduli selama aplikasi berfungsi.

Canary release berguna ketika Anda ingin memvalidasi bahwa suatu perubahan stabil di bawah beban produksi nyata. Lingkungan staging bagus untuk menangkap kesalahan logika, tetapi tidak dapat mereplikasi kekacauan produksi: lonjakan lalu lintas yang tidak merata, koneksi basis data yang lambat dari wilayah tertentu, atau batas tarif API pihak ketiga yang hanya muncul di bawah beban.

Strategi ini sangat cocok untuk perubahan berisiko tinggi. Penulisan ulang logika bisnis besar, migrasi skema basis data, upgrade pustaka yang menyentuh jaringan atau konkurensi, atau perubahan pada perilaku caching adalah kandidat yang baik untuk canary release. Jika ada yang salah, hanya sebagian kecil pengguna yang terpengaruh, dan Anda dapat mengalihkan lalu lintas dari versi baru dengan cepat.

Staged Rollout: Pilih Siapa yang Mendapatkannya Terlebih Dahulu

Staged rollout mengambil pendekatan yang berbeda. Alih-alih membagi lalu lintas secara acak, Anda memutuskan kelompok pengguna mana yang menerima versi baru terlebih dahulu. Kelompok-kelompok ini sering disebut ring.

Ring satu mungkin berisi tim internal Anda dan segelintir penguji beta. Ring dua bisa berupa persentase pengguna di wilayah tertentu atau dengan tipe perangkat tertentu. Ring tiga mungkin semua pengguna tingkat gratis. Ring empat bisa berupa pelanggan perusahaan dengan SLA ketat.

Progres rollout melalui ring-ring ini hanya jika ring sebelumnya tidak menunjukkan masalah kritis. Jika ring satu melaporkan masalah, Anda menjeda sebelum memperluas. Jika ring dua menunjukkan tingkat error yang meningkat, Anda melakukan rollback sebelum mencapai ring tiga.

Perbedaan utama dari canary release adalah intensionalitas. Anda memilih siapa yang mendapatkan versi baru, bukan hanya seberapa banyak lalu lintas. Ini penting ketika kelompok pengguna yang berbeda memiliki ekspektasi yang berbeda, pola penggunaan yang berbeda, atau kewajiban kontraktual yang berbeda.

Misalnya, jika aplikasi Anda melayani pengguna individu dan klien perusahaan besar dengan SLA yang ditandatangani, Anda mungkin tidak ingin secara tidak sengaja mengarahkan permintaan perusahaan ke versi baru yang bermasalah. Staged rollout memungkinkan Anda menguji perubahan pada pengguna yang kurang kritis terlebih dahulu, kemudian memperluas ke pelanggan bernilai tinggi hanya setelah Anda yakin.

Staged rollout juga berfungsi baik untuk rilis aplikasi seluler. Anda tidak dapat dengan mudah mengontrol lalu lintas di tingkat jaringan untuk aplikasi seluler. Sebagai gantinya, Anda merilis pembaruan ke sebagian kecil pengguna melalui fitur staged rollout toko aplikasi, memonitor laporan crash dan peringkat, kemudian memperluas ke lebih banyak pengguna.

Menggabungkan Kedua Strategi

Dalam praktiknya, canary release dan staged rollout tidak saling eksklusif. Banyak tim menggabungkannya ke dalam satu pipeline progressive delivery.

Diagram di bawah menunjukkan kedua strategi secara berdampingan dan bagaimana keduanya dapat dirangkai bersama.

flowchart TD A[Versi Baru Siap] --> B{Pilih Strategi} B --> C[Canary Release] B --> D[Staged Rollout] C --> C1[Arahkan 5% lalu lintas] C1 --> C2{Sehat?} C2 -->|Ya| C3[Tingkatkan ke 20%] C2 -->|Tidak| C4[Rollback] C3 --> C5[Lanjutkan ke 100%] D --> D1[Ring 1: Internal] D1 --> D2{Ada Masalah?} D2 -->|Tidak| D3[Ring 2: Beta] D2 -->|Ya| D4[Rollback] D3 --> D5[Ring 3: Semua Pengguna] C5 --> E[Pipeline Gabungan] D5 --> E E --> F[Canary 5% → Ring Bertahap → Rilis Penuh]

Pipeline mungkin dimulai dengan canary release pada lima persen lalu lintas untuk memvalidasi stabilitas teknis. Jika canary lolos, pipeline beralih ke staged rollout: pertama ke pengguna internal, lalu ke pengguna beta, kemudian ke persentase pengguna produksi, dan akhirnya ke semua orang.

Pendekatan gabungan ini memberi Anda dua lapisan keamanan. Canary menangkap masalah tingkat infrastruktur seperti kebocoran memori atau kueri basis data yang lambat. Staged rollout menangkap masalah yang dihadapi pengguna seperti alur kerja yang rusak untuk jenis akun atau wilayah tertentu.

Pipeline progressive delivery yang dirancang dengan baik dapat mengotomatiskan keputusan-keputusan ini. Pipeline memonitor metrik yang Anda tentukan, membandingkannya dengan ambang batas, dan melanjutkan ke langkah berikutnya, menahan rollout untuk peninjauan manual, atau memicu rollback otomatis.

Yang Anda Butuhkan Sebelum Memulai

Strategi progressive delivery hanya berguna jika data yang Anda gunakan untuk membuat keputusan berkualitas. Tanpa observabilitas yang baik, canary release hanyalah cara yang lebih lambat untuk merusak produksi.

Anda membutuhkan:

  • Pemantauan tingkat error waktu nyata, yang dipecah berdasarkan versi
  • Persentil latensi untuk versi baru dibandingkan dengan versi lama
  • Metrik bisnis yang penting bagi produk Anda, seperti tingkat konversi atau penyelesaian pendaftaran
  • Cara untuk menghubungkan laporan pengguna dengan versi yang mereka jalankan

Anda juga membutuhkan kemampuan untuk melakukan rollback dengan cepat. Jika canary menunjukkan masalah, Anda harus dapat mengalihkan lalu lintas dari versi baru dalam hitungan detik, bukan jam. Ini membutuhkan infrastruktur yang mendukung perpindahan lalu lintas, seperti load balancer, service mesh, atau sistem feature flag.

Daftar Periksa Praktis Singkat

Jika Anda menyiapkan progressive delivery untuk pertama kalinya, berikut adalah daftar singkat untuk memandu implementasi Anda:

  • Mulailah dengan satu strategi. Pilih canary release jika Anda peduli dengan stabilitas teknis di bawah beban produksi. Pilih staged rollout jika Anda perlu mengontrol pengguna mana yang melihat perubahan terlebih dahulu.
  • Tentukan kriteria go/no-go yang jelas sebelum Anda memulai. Tingkat error apa yang dapat diterima? Peningkatan latensi berapa yang terlalu besar? Tulis ambang batas ini dan konfigurasikan di pipeline Anda.
  • Pastikan pemantauan Anda mencakup metrik teknis dan metrik bisnis. Canary mungkin menunjukkan nol error tetapi tetap merusak alur checkout Anda jika pengguna tidak dapat menyelesaikan pembelian.
  • Latih rollback. Jangan menunggu sampai sesuatu rusak untuk mengetahui bahwa perpindahan lalu lintas Anda memakan waktu sepuluh menit.
  • Gabungkan strategi hanya setelah Anda nyaman dengan masing-masing strategi secara individual. Pipeline gabungan menambah kompleksitas, dan Anda ingin memahami setiap lapisan sebelum menumpuknya.

Intisari Konkret

Canary release dan staged rollout bukan tentang berhati-hati demi berhati-hati. Mereka tentang mempelajari apa yang sebenarnya dilakukan produksi terhadap kode Anda sebelum mencapai semua orang. Lingkungan staging memberi Anda kepercayaan pada pengujian Anda. Canary atau staged rollout memberi Anda kepercayaan pada kenyataan.

Mulailah dengan satu strategi, instrumentasi metrik Anda, dan biarkan data memberi tahu Anda kapan harus melanjutkan. Tujuannya bukan untuk menghilangkan risiko sepenuhnya. Tujuannya adalah untuk membatasi risiko pada sekelompok kecil pengguna, belajar darinya, dan memperluas hanya ketika Anda yakin.