Memilih Cara Men-deploy Versi Baru Tanpa Merusak Layanan

Kamu baru saja selesai membangun fitur baru. Kode sudah lolos semua pemeriksaan, pengujian hijau, dan artefak siap. Sekarang pertanyaan sebenarnya: bagaimana cara menempatkan versi baru ini ke server tanpa membuat pengguna marah?

Jawaban paling sederhana adalah menghentikan server, mengganti file, lalu menjalankannya lagi. Itu berfungsi baik jika aplikasi digunakan oleh segelintir orang yang tahu akan ada downtime. Namun, untuk aplikasi yang melayani pengguna sungguhan, pendekatan itu langsung bermasalah. Orang melihat halaman error. Permintaan gagal. Kepercayaan terkikis.

Masalah intinya adalah kamu perlu menempatkan kode baru ke produksi sementara kode lama masih melayani traffic. Kamu tidak bisa begitu saja menukar semuanya sekaligus. Kamu memerlukan strategi yang memungkinkan transisi dari satu versi ke versi lain tanpa mengganggu layanan.

Ada tiga strategi umum untuk ini: rolling update, blue/green deployment, dan canary deployment. Masing-masing memecahkan masalah yang sama dengan cara berbeda, dan masing-masing cocok untuk situasi yang berbeda.

Rolling Update: Ganti Satu Server dalam Satu Waktu

Rolling update adalah strategi yang paling banyak digunakan. Idenya sederhana: alih-alih mengganti semua server sekaligus, kamu menggantinya satu per satu atau dalam kelompok kecil.

Bayangkan kamu memiliki sepuluh server yang menjalankan aplikasi. Dengan rolling update, kamu mengambil dua server offline, menginstal versi baru di server tersebut, dan mengaktifkannya kembali. Setelah kedua server itu menjalankan versi baru, kamu beralih ke dua server berikutnya. Kamu ulangi ini sampai semua sepuluh server menjalankan versi baru.

Keuntungan besarnya di sini adalah kamu tidak memerlukan server tambahan. Kamu menggunakan kembali infrastruktur yang sama. Biayanya minimal karena kamu tidak menyediakan lingkungan duplikat.

Berikut adalah tampilan rolling update dalam manifes Deployment Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: my-app:2.0.0

Konfigurasi ini memastikan bahwa hanya satu Pod baru yang dibuat dalam satu waktu (maxSurge: 1) dan tidak ada Pod lama yang dimatikan sampai Pod baru siap (maxUnavailable: 0). Pembaruan berlangsung pod demi pod, menjaga layanan tetap tersedia selama proses.

Namun, ada satu kelemahan. Selama pembaruan, dua versi aplikasi berjalan bersamaan. Beberapa pengguna mengenai versi lama, yang lain mengenai versi baru. Jika kontrak API berubah di antara versi, permintaan bisa gagal. Seorang pengguna mungkin mengirim permintaan yang diproses oleh server lama, tetapi format responsnya telah berubah. Atau server baru mengharapkan field yang tidak dikirim oleh klien lama.

Rolling update berfungsi baik ketika perubahannya kompatibel ke belakang. Jika kamu menambahkan field, bukan menghapusnya. Jika kamu memperluas API, bukan mengubah bentuknya. Jika perubahan skema database bersifat aditif, bukan destruktif. Untuk perubahan kecil yang aman, rolling update efisien dan sederhana.

Blue/Green Deployment: Dua Lingkungan Lengkap

Blue/green deployment mengambil pendekatan berbeda. Kamu memelihara dua lingkungan yang identik. Sebut saja biru dan hijau. Pada waktu tertentu, hanya satu yang melayani traffic langsung. Yang lainnya diam atau menjalankan versi sebelumnya.

Begini cara kerjanya. Pengguna kamu saat ini mengenai lingkungan biru. Kamu men-deploy versi baru ke lingkungan hijau. Setelah lingkungan hijau sepenuhnya siap dan kamu telah memverifikasi bahwa itu berfungsi, kamu mengalihkan traffic. Semua pengguna sekarang mengenai lingkungan hijau. Jika ada yang salah, kamu kembali ke biru. Rollback-nya instan.

Strategi ini lebih aman karena tidak pernah ada campuran versi. Pengguna beralih dari satu versi lengkap ke versi lainnya. Tidak ada periode di mana setengah server menjalankan kode lama dan setengahnya menjalankan kode baru. Transisinya bersih.

Konsekuensinya adalah biaya. Kamu membutuhkan dua kali lipat sumber daya. Dua lingkungan penuh, masing-masing dengan kapasitas yang sama, berjalan bersamaan. Untuk aplikasi kecil, ini mungkin terjangkau. Untuk yang besar, biayanya bisa signifikan.

Blue/green ideal untuk aplikasi kritis di mana downtime tidak dapat diterima dan rollback harus cepat. Jika kamu men-deploy perubahan besar, migrasi database, atau sesuatu yang menyentuh banyak bagian sistem, blue/green memberimu jaring pengaman.

Canary Deployment: Uji pada Kelompok Kecil Terlebih Dahulu

Canary deployment seperti rolling update tetapi lebih hati-hati. Alih-alih mengganti server dalam kelompok, kamu mulai dengan persentase yang sangat kecil. Mungkin 5 persen server mendapatkan versi baru. Sisanya tetap pada versi lama.

Kamu mengamati kelompok kecil itu untuk sementara waktu. Jika tingkat error tetap normal, waktu respons baik, dan tidak ada yang melaporkan masalah, kamu meningkatkan persentasenya. Mungkin menjadi 20 persen. Lalu 50 persen. Lalu 100 persen.

Idenya adalah membatasi radius ledakan. Jika versi baru memiliki bug, hanya sebagian kecil pengguna yang mengalaminya. Kamu menangkap masalah sebelum menjadi pemadaman total.

Canary deployment membutuhkan monitoring yang baik. Kamu perlu tahu seperti apa kondisi normal. Kamu memerlukan dashboard yang menunjukkan tingkat error, latensi, dan throughput secara real-time. Tanpa visibilitas itu, kamu terbang buta. Kamu tidak akan tahu apakah canary sehat atau tidak.

Strategi ini berfungsi baik ketika kamu ingin memvalidasi perubahan di produksi sebelum berkomitmen penuh. Ini sangat berguna untuk perubahan performa, algoritma baru, atau apa pun yang perilakunya di bawah traffic nyata tidak pasti.

Memilih Strategi yang Tepat

Tidak ada satu strategi terbaik. Masing-masing cocok untuk situasi yang berbeda.

Diagram alir berikut dapat membantu kamu memutuskan strategi mana yang cocok untuk situasi kamu.

flowchart TD A[Strategi deployment mana?] --> B{Bisa menyediakan infrastruktur ganda?} B -->|Ya| C{Butuh rollback instan?} B -->|Tidak| D{Apakah perubahan kompatibel ke belakang?} C -->|Ya| E[Blue/Green Deployment] C -->|Tidak| F{Punya monitoring real-time?} F -->|Ya| G[Canary Deployment] F -->|Tidak| E D -->|Ya| H[Rolling Update] D -->|Tidak| I{Punya monitoring real-time?} I -->|Ya| G I -->|Tidak| E

Rolling update adalah default untuk sebagian besar tim. Ini efisien sumber daya dan berfungsi baik untuk perubahan rutin. Gunakan ketika perubahanmu kompatibel ke belakang dan kamu tidak membutuhkan rollback instan.

Blue/green adalah pilihan teraman. Gunakan untuk deployment kritis, perubahan versi besar, atau ketika kamu perlu rollback segera. Bersiaplah untuk membayar infrastruktur tambahan.

Canary adalah yang paling hati-hati. Gunakan ketika kamu ingin mengamati dampak perubahan sebelum berkomitmen. Ini membutuhkan monitoring yang baik dan proses untuk memutuskan kapan meningkatkan persentase.

Banyak tim memulai dengan rolling update dan beralih ke blue/green atau canary seiring aplikasi menjadi lebih kritis dan basis pengguna bertambah. Strategi yang kamu pilih hari ini tidak harus menjadi yang kamu gunakan selamanya.

Daftar Periksa Praktis Sebelum Memilih

  • Apakah perubahan kompatibel ke belakang? Jika ya, rolling update sudah cukup.
  • Apakah kamu butuh rollback instan? Jika ya, blue/green lebih aman.
  • Apakah kamu memiliki monitoring real-time? Jika tidak, canary berisiko.
  • Bisakah kamu menyediakan infrastruktur ganda? Jika tidak, hindari blue/green.
  • Apakah kamu ingin menguji di bawah traffic nyata? Jika ya, canary memberimu itu.

Yang Paling Penting

Strategi bukanlah bagian tersulit. Bagian tersulit adalah memahami perilaku aplikasi selama transisi. Apakah aplikasi menangani dua versi yang berjalan bersamaan? Bisakah aplikasi mentolerir periode singkat kontrak API campuran? Apakah kamu memiliki observabilitas untuk mendeteksi masalah sebelum pengguna melaporkannya?

Pilih strategi yang sesuai dengan toleransi risiko dan anggaran infrastrukturmu. Lalu uji. Tidak hanya di staging, tetapi di produksi dengan pola traffic nyata. Pertama kali kamu melakukan blue/green switch atau canary rollout, lakukan saat traffic rendah. Amati metriknya. Pelajari seperti apa kondisi normal.

Deployment bukan tentang memindahkan bit dari satu tempat ke tempat lain. Ini tentang menjaga pengguna tetap senang sambil kamu meningkatkan produk. Strategi yang tepat memungkinkan itu. Strategi yang salah membuatnya menyakitkan.