Rolling Update: Cara Deployment Tanpa Menghentikan Semua Layanan Sekaligus

Bayangkan skenario ini: aplikasi Anda berjalan di lima server, semuanya melayani pengguna. Anda perlu mendorong versi baru dengan perbaikan bug kritis. Cara lama adalah menghentikan semua server, deploy versi baru, lalu mulai lagi semuanya. Tapi itu berarti downtime. Setiap pengguna akan melihat halaman error atau spinner loading yang tidak pernah selesai.

Pendekatan itu mungkin berfungsi untuk alat internal yang digunakan segelintir orang pada jam 3 pagi. Tapi untuk aplikasi live dengan pengguna nyata, menghentikan semuanya sekaligus bukanlah opsi. Anda membutuhkan cara untuk memperbarui perangkat lunak tanpa membuat semua orang merasakan dampaknya secara bersamaan.

Masalahnya: Deployment All-or-Nothing

Ketika Anda mengganti semua instance aplikasi yang berjalan pada saat yang sama, Anda menciptakan celah waktu di mana tidak ada yang melayani traffic. Meskipun deployment itu sendiri hanya memakan waktu detik, detik-detik itu bisa berarti hilangnya pendapatan, pengguna yang frustrasi, atau transaksi yang gagal. Untuk aplikasi yang membutuhkan ketersediaan tinggi, celah waktu ini tidak dapat diterima.

Inti masalahnya adalah Anda memperlakukan semua server sebagai satu kesatuan. Anda menghentikannya bersama-sama, memperbaruinya bersama-sama, dan memulainya bersama-sama. Masalah apa pun dengan versi baru akan memengaruhi semua pengguna pada saat yang bersamaan. Jika deployment gagal, Anda akan kebingungan mengembalikan versi lama sementara pengguna sudah melihat error.

Solusinya: Ganti Satu Instance dalam Satu Waktu

Alih-alih memperbarui semuanya sekaligus, Anda dapat memperbarui server satu per satu. Begini cara kerjanya:

Diagram urutan berikut menunjukkan bagaimana load balancer mengoordinasikan pembaruan di seluruh instance:

sequenceDiagram participant LB as Load Balancer participant I1 as Instance 1 participant I2 as Instance 2 participant I3 as Instance 3 LB->>I1: Hentikan traffic I1-->>LB: Dikonfirmasi I1->>I1: Deploy v2.0 I1->>I1: Health check /ready I1-->>LB: Siap LB->>I1: Lanjutkan traffic LB->>I2: Hentikan traffic I2-->>LB: Dikonfirmasi I2->>I2: Deploy v2.0 I2->>I2: Health check /ready I2-->>LB: Siap LB->>I2: Lanjutkan traffic LB->>I3: Hentikan traffic I3-->>LB: Dikonfirmasi I3->>I3: Deploy v2.0 I3->>I3: Health check /ready I3-->>LB: Siap LB->>I3: Lanjutkan traffic
  1. Anda memiliki lima server yang menjalankan versi 1.0 dari aplikasi Anda.
  2. Anda mengambil satu server dari layanan.
  3. Anda deploy versi 2.0 ke server tersebut.
  4. Anda verifikasi bahwa versi baru berfungsi dengan benar.
  5. Anda mengembalikan server itu ke layanan.
  6. Anda beralih ke server berikutnya dan ulangi.

Pada titik mana pun dalam proses ini, empat server masih menjalankan versi lama, dan satu server menjalankan versi baru. Pengguna yang mengenai server yang diperbarui mendapatkan versi baru. Pengguna yang mengenai server lain mendapatkan versi lama. Tidak ada yang mendapatkan error karena tidak ada server yang benar-benar dihentikan sepenuhnya.

Pendekatan ini disebut rolling update. Namanya berasal dari cara pembaruan "bergulir" melintasi instance Anda satu per satu, seperti gelombang yang bergerak melintasi lapangan. Instance adalah unit apa pun tempat aplikasi Anda berjalan: server fisik, mesin virtual, atau container.

Mengapa Health Check Itu Penting

Rolling update hanya berfungsi jika Anda dapat mengetahui apakah versi baru benar-benar berjalan dengan benar sebelum Anda memperbarui instance berikutnya. Di sinilah health check berperan.

Health check adalah mekanisme sederhana yang menguji apakah suatu instance siap menerima traffic. Biasanya, ini adalah endpoint seperti /health atau /ready yang mengembalikan respons sukses ketika aplikasi berfungsi normal. Sistem orkestrasi Anda - apakah itu Kubernetes, load balancer, atau alat deployment kustom - memeriksa endpoint ini sebelum mengirim traffic ke instance.

Jika health check gagal setelah Anda deploy versi baru, rolling update akan berhenti. Instance yang bermasalah dapat dikembalikan ke versi lama, dan server lainnya tetap tidak tersentuh. Anda telah membatasi dampak hanya pada satu instance dan sebagian kecil pengguna.

Tanpa health check, Anda terbang buta. Anda mungkin memperbarui kelima server sebelum menyadari bahwa versi baru crash saat startup. Pada saat itu, semua pengguna sudah terpengaruh.

Kapan Rolling Update Bekerja dengan Baik

Rolling update ideal untuk perubahan yang kompatibel ke belakang (backward compatible). Ini adalah perubahan di mana versi lama dan baru dapat berjalan berdampingan tanpa masalah. Contohnya termasuk:

  • Menambahkan pernyataan log baru
  • Memperbaiki bug kecil yang tidak mengubah format data
  • Mengubah warna atau teks UI
  • Menambahkan endpoint API baru yang belum digunakan siapa pun
  • Memperbarui dependensi yang tidak mengubah perilaku

Karena instance lama dan baru berjalan bersamaan selama pembaruan, kompatibilitas ke belakang sangat penting. Jika versi baru mengharapkan data dalam format yang berbeda, atau berkomunikasi dengan layanan lain menggunakan protokol yang berbeda, Anda akan mendapatkan error ketika instance lama dan baru mencoba bekerja sama.

Trade-Off

Rolling update sederhana dan tidak memerlukan infrastruktur tambahan. Anda menggunakan server yang sudah Anda miliki. Tidak perlu menyiapkan lingkungan paralel atau menyediakan kapasitas tambahan. Biaya infrastruktur Anda tetap sama selama pembaruan.

Kekurangannya adalah kecepatan. Rolling update memakan waktu karena Anda harus menunggu setiap instance diperbarui dan diverifikasi. Jika Anda memiliki lima puluh server dan masing-masing membutuhkan waktu satu menit untuk deploy dan periksa, pembaruan Anda memakan waktu hampir satu jam. Untuk patch keamanan yang mendesak, itu mungkin terlalu lambat.

Keterbatasan lainnya adalah visibilitas. Ketika rolling update memperkenalkan masalah, dampaknya menyebar secara bertahap. Beberapa pengguna melihat masalah, yang lain tidak. Ini membuatnya lebih sulit untuk mengisolasi akar penyebab dibandingkan dengan strategi di mana Anda dapat dengan jelas memisahkan pengguna yang terpengaruh dari yang tidak terpengaruh.

Checklist Praktis

Sebelum Anda menerapkan rolling update, pastikan Anda memiliki dasar-dasar ini:

  • Endpoint health check: Aplikasi Anda harus mengekspos cara yang andal untuk memverifikasi bahwa ia berfungsi.
  • Kompatibilitas ke belakang: Versi baru harus dapat bekerja bersama versi lama selama transisi.
  • Rencana rollback: Ketahui cara mengembalikan satu instance jika health check gagal.
  • Monitoring: Pantau tingkat error dan waktu respons selama pembaruan untuk menangkap masalah lebih awal.
  • Instance yang cukup: Rolling update paling baik bekerja dengan setidaknya tiga instance. Dengan hanya dua, Anda kehilangan setengah kapasitas selama pembaruan.

Kesimpulan

Rolling update adalah strategi deployment default untuk sebagian besar aplikasi modern karena mereka memecahkan masalah fundamental dalam memperbarui perangkat lunak tanpa downtime. Idenya sederhana: jangan ganti semuanya sekaligus. Ganti satu instance, verifikasi bahwa itu berfungsi, lalu lanjutkan ke instance berikutnya. Pendekatan ini menjaga aplikasi Anda tetap tersedia selama pembaruan dan membatasi radius ledakan jika terjadi kesalahan.

Untuk perubahan kecil yang kompatibel ke belakang, rolling update seringkali sudah cukup. Mereka mudah, hemat biaya, dan didukung secara luas oleh platform orkestrasi container seperti Kubernetes dan alat deployment cloud. Tapi untuk perubahan yang lebih berisiko - migrasi database, perubahan protokol, atau perombakan fitur besar - Anda mungkin membutuhkan kontrol yang lebih besar. Di situlah strategi seperti blue-green deployment atau canary release berperan. Tapi itu adalah topik untuk artikel lain.