Apa Itu Rolling Deployment? Panduan Lengkap dan Cara Kerjanya

Dalam pengembangan aplikasi modern, pembaruan software perlu dilakukan secara berkala untuk memperbaiki bug, meningkatkan performa, menambahkan fitur, atau memperkuat keamanan. Namun, proses pembaruan dapat menjadi tantangan ketika aplikasi harus tetap tersedia dan melayani pengguna selama proses deployment berlangsung.

Salah satu strategi yang digunakan untuk mengurangi gangguan tersebut adalah rolling deployment. Strategi ini memungkinkan versi lama aplikasi digantikan secara bertahap oleh versi baru, sehingga tidak semua instance aplikasi diperbarui pada waktu yang sama.

Rolling deployment banyak digunakan dalam lingkungan cloud, container, orchestration platform, dan sistem yang membutuhkan ketersediaan aplikasi secara berkelanjutan. Kubernetes, misalnya, menggunakan strategi RollingUpdate sebagai strategi default untuk Deployment dan mengganti Pod lama secara bertahap dengan Pod baru.

Apa Itu Rolling Deployment?

Rolling deployment adalah strategi deployment yang memperbarui aplikasi secara bertahap dengan mengganti instance atau server yang menjalankan versi lama menjadi versi baru secara berurutan atau dalam beberapa kelompok.

Dalam proses ini, versi lama dan versi baru aplikasi dapat berjalan secara bersamaan untuk sementara waktu. Instance baru terlebih dahulu dijalankan dan dipastikan siap menerima trafik sebelum sebagian instance lama dihentikan.

Dengan mekanisme tersebut, aplikasi tidak perlu menghentikan seluruh instance sekaligus hanya untuk memasang versi terbaru. AWS menjelaskan bahwa rolling deployment secara perlahan mengganti versi aplikasi sebelumnya dengan versi baru, misalnya dengan mengganti container lama satu per satu pada lingkungan Amazon ECS.

Sebagai gambaran sederhana, sebuah aplikasi memiliki 4 instance:

Versi lama: Instance 1 — Instance 2 — Instance 3 — Instance 4

Ketika versi baru dirilis, proses rolling deployment dapat berjalan seperti berikut:

Tahap 1:
Instance 1 → versi baru
Instance 2 → versi lama
Instance 3 → versi lama
Instance 4 → versi lama

Tahap 2:
Instance 1 → versi baru
Instance 2 → versi baru
Instance 3 → versi lama
Instance 4 → versi lama

Tahap 3:
Instance 1 → versi baru
Instance 2 → versi baru
Instance 3 → versi baru
Instance 4 → versi lama

Tahap 4:
Semua instance → versi baru

Dengan pendekatan tersebut, kapasitas aplikasi dapat tetap tersedia selama proses pembaruan, selama jumlah instance dan konfigurasi deployment dirancang dengan tepat.

Bagaimana Cara Kerja Rolling Deployment?

Rolling deployment bekerja dengan mengganti komponen aplikasi secara bertahap. Mekanisme detailnya dapat berbeda tergantung platform yang digunakan, tetapi konsep dasarnya relatif sama.

1. Menentukan Versi Baru

Deployment dimulai ketika tim ingin merilis versi aplikasi yang baru. Perubahan dapat berupa update kode, container image, konfigurasi tertentu, atau komponen aplikasi lainnya. Dalam Kubernetes, perubahan pada Pod template seperti container image dapat memicu rollout baru pada Deployment.

2. Menjalankan Instance Versi Baru

Sistem kemudian membuat atau mengaktifkan instance yang menggunakan versi baru. Instance tersebut perlu memenuhi kondisi yang ditentukan sebelum dianggap siap. Dalam Kubernetes, misalnya, Pod baru akan dijalankan dan sistem secara bertahap mengganti Pod lama setelah Pod baru tersedia.

3. Memastikan Instance Baru Siap

Sistem perlu memastikan versi baru dapat berjalan dengan baik sebelum instance lama dikurangi. Pemeriksaan dapat melibatkan health check, readiness check, status aplikasi, atau mekanisme monitoring lainnya. Tahap ini penting karena deployment tidak seharusnya hanya melihat apakah proses aplikasi berhasil dijalankan, tetapi juga apakah aplikasi benar-benar siap melayani trafik.

4. Mengurangi Instance Lama

Setelah instance baru siap, sebagian instance lama dapat dihentikan atau dikeluarkan dari layanan. Jumlah instance yang diganti pada setiap tahap bergantung pada konfigurasi deployment.

5. Mengulangi Proses

Langkah tersebut dilakukan secara berulang sampai seluruh instance menggunakan versi baru. Jika selama proses ditemukan masalah, rollout dapat dihentikan atau dikembalikan ke versi sebelumnya, tergantung kemampuan platform dan konfigurasi deployment.

Contoh Rolling Deployment Sederhana

Misalnya sebuah website memiliki 5 instance aplikasi dan ingin diperbarui dari versi 1.0 ke versi 2.0. Tanpa rolling deployment, seluruh instance dapat dihentikan terlebih dahulu kemudian diganti dengan versi baru. Cara tersebut berpotensi menyebabkan downtime. Dengan rolling deployment, proses dapat dilakukan secara bertahap:

Dalam praktik, jumlah instance yang tersedia dapat berubah selama proses jika konfigurasi deployment mengizinkan penambahan instance sementara. Pada Kubernetes, hal ini dikendalikan antara lain melalui parameter maxUnavailable dan maxSurge.

Parameter Penting dalam Rolling Deployment

Dalam implementasi rolling deployment, terdapat beberapa konfigurasi yang menentukan bagaimana proses penggantian dilakukan.

Max Unavailable

Max unavailable menentukan jumlah maksimum instance yang boleh berada dalam kondisi tidak tersedia selama proses deployment. Pada Kubernetes, maxUnavailable dapat ditentukan menggunakan angka absolut atau persentase. Nilai default untuk RollingUpdate Kubernetes adalah 25%.

Misalnya terdapat 10 Pod dan maxUnavailable ditetapkan sebesar 20%. Secara sederhana, maksimal sekitar 2 Pod dapat tidak tersedia selama proses update, sesuai aturan perhitungan platform. Semakin kecil nilai ini, semakin banyak kapasitas yang dipertahankan selama deployment, tetapi proses pembaruan dapat menjadi lebih lambat.

Max Surge

Max surge menentukan jumlah maksimum instance tambahan yang boleh dibuat melebihi jumlah instance yang diinginkan selama proses rolling update. Pada Kubernetes, maxSurge juga dapat dinyatakan dalam angka atau persentase dan memiliki nilai default 25%.

Sebagai contoh, jika aplikasi memiliki 10 Pod dan maxSurge ditetapkan 20%, sistem dapat membuat Pod tambahan selama proses update hingga batas yang ditentukan. Pengaturan ini memungkinkan instance baru tersedia terlebih dahulu sebelum instance lama dihentikan.

Rolling Deployment di Kubernetes

Rolling deployment sangat erat kaitannya dengan Kubernetes karena RollingUpdate merupakan strategi default untuk objek Deployment. Kubernetes secara bertahap melakukan scale down pada ReplicaSet lama dan scale up pada ReplicaSet baru. Contoh konfigurasi sederhana:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: aplikasi-web
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: aplikasi-web
  template:
    metadata:
      labels:
        app: aplikasi-web
    spec:
      containers:
        - name: aplikasi-web
          image: aplikasi-web:v2

Pada konfigurasi tersebut, aplikasi menjalankan empat replica. maxUnavailable: 1 membatasi jumlah Pod yang dapat tidak tersedia selama update, sedangkan maxSurge: 1 memungkinkan satu Pod tambahan dibuat di atas jumlah replica yang diinginkan selama proses pembaruan.

Setelah konfigurasi atau image diperbarui, Kubernetes akan melakukan rollout secara bertahap. Status proses dapat dipantau menggunakan perintah kubectl rollout status.

Rolling Deployment dan Zero Downtime

Salah satu alasan utama menggunakan rolling deployment adalah untuk mengurangi atau menghindari downtime selama proses deployment. Namun, penting untuk memahami bahwa rolling deployment tidak otomatis menjamin zero downtime dalam semua kondisi.

Agar aplikasi tetap tersedia, sistem harus memiliki beberapa instance yang dapat melayani trafik, konfigurasi deployment harus tepat, dan aplikasi harus mampu berjalan dengan baik selama periode ketika versi lama dan versi baru mungkin hidup bersamaan.

Dokumentasi Kubernetes menjelaskan bahwa rolling update dapat melakukan update secara bertahap sehingga aplikasi tetap tersedia, tetapi menjalankan beberapa instance aplikasi merupakan bagian penting untuk melakukan update tanpa memengaruhi availability. Karena itu, rolling deployment sebaiknya dipadukan dengan:

• health check;
• readiness check;
• load balancing;
• monitoring;
• logging;
• automated testing;
• rollback;
• observability.

Kelebihan Rolling Deployment

Rolling deployment memiliki sejumlah kelebihan yang membuatnya populer dalam lingkungan aplikasi modern.

• Mengurangi Downtime
  Karena instance tidak diganti sekaligus, aplikasi tetap memiliki instance yang dapat melayani permintaan selama proses deployment.

• Deployment Lebih Bertahap
  Tim dapat memperkenalkan versi baru secara perlahan sehingga perubahan tidak langsung diterapkan ke seluruh instance.

• Penggunaan Infrastruktur Lebih Efisien
  Dibandingkan blue-green deployment yang membutuhkan dua environment terpisah secara penuh, rolling deployment dapat menggunakan infrastruktur yang sama dan mengganti instance secara bertahap. AWS mencatat bahwa rolling deployment umumnya lebih cepat dibandingkan blue-green, tetapi tidak memberikan isolasi environment seperti blue-green.

• Cocok untuk Aplikasi yang Memiliki Banyak Replica
  Rolling deployment sangat sesuai untuk aplikasi yang memiliki beberapa instance atau replica yang berjalan secara paralel.

• Mendukung Continuous Delivery
  Karena deployment dapat dilakukan secara bertahap dan otomatis, rolling deployment dapat menjadi bagian dari pipeline CI/CD.

Kekurangan Rolling Deployment

Meskipun memiliki banyak manfaat, rolling deployment juga mempunyai keterbatasan.

• Versi Lama dan Baru Dapat Berjalan Bersamaan
  Selama proses deployment, pengguna dapat dilayani oleh versi lama maupun versi baru. Hal ini berarti aplikasi harus dirancang agar kedua versi dapat bekerja secara kompatibel selama masa transisi.

• Rollback Bisa Lebih Kompleks
  AWS mencatat bahwa rolling deployment tidak memiliki environment isolation seperti blue-green deployment sehingga rollback ketika deployment bermasalah dapat menjadi lebih kompleks.

• Membutuhkan Monitoring yang Baik
  Masalah pada versi baru tidak selalu langsung terlihat. Tanpa monitoring dan health check yang baik, deployment dapat terus berjalan meskipun versi baru sebenarnya mengalami masalah.

• Tidak Cocok untuk Semua Jenis Perubahan
  Perubahan database yang tidak kompatibel, perubahan API yang memutus kompatibilitas, atau perubahan arsitektur tertentu dapat membutuhkan strategi migrasi tambahan agar versi lama dan baru dapat berjalan bersamaan.

Perbedaan Rolling Deployment dan Recreate

Rolling deployment dapat dibandingkan dengan strategi Recreate.

Dalam Kubernetes, Recreate akan menghentikan Pod yang ada sebelum membuat Pod baru, sedangkan RollingUpdate mengganti Pod lama dengan Pod baru secara bertahap.

Perbedaan Rolling Deployment dan Blue-Green Deployment

Rolling deployment dan blue-green deployment sama-sama dapat digunakan untuk mengurangi risiko deployment, tetapi mekanismenya berbeda.

AWS menjelaskan bahwa rolling deployment umumnya lebih cepat dibandingkan blue-green, tetapi rolling deployment tidak memiliki isolasi environment antara versi lama dan versi baru seperti yang dimiliki blue-green.

Perbedaan Rolling Deployment dan Canary Deployment

Rolling deployment juga sering dibandingkan dengan canary deployment.

Keduanya dapat digunakan bersama. Kubernetes, misalnya, mendokumentasikan penggunaan partisi pada StatefulSet RollingUpdate untuk mendukung skenario seperti canary update.

Kapan Rolling Deployment Sebaiknya Digunakan?

Rolling deployment cocok digunakan ketika aplikasi memiliki beberapa instance yang dapat berjalan secara paralel dan perusahaan ingin memperbarui aplikasi tanpa menghentikan seluruh layanan. Strategi ini sangat berguna untuk:

• aplikasi web dengan trafik tinggi;
• microservices;
• aplikasi berbasis container;
• sistem cloud;
• layanan API;
• aplikasi yang menggunakan load balancing;
• deployment melalui Kubernetes atau container orchestration;
• sistem yang membutuhkan availability tinggi.

Namun, keputusan menggunakan rolling deployment tetap harus mempertimbangkan arsitektur aplikasi, kebutuhan availability, kompatibilitas versi, database, dan kemampuan rollback.

Praktik Terbaik Rolling Deployment

Agar rolling deployment berjalan lebih aman, beberapa praktik berikut dapat diterapkan.

Gunakan Health Check

Pastikan sistem dapat membedakan instance yang benar-benar siap melayani trafik dengan instance yang hanya berhasil menjalankan proses aplikasinya.

Atur Max Unavailable dan Max Surge

Jangan menggunakan konfigurasi secara sembarangan. Sesuaikan jumlah instance yang boleh dihentikan dan instance tambahan yang boleh dibuat dengan kapasitas infrastruktur.

Gunakan Monitoring

Pantau error rate, latency, CPU, memory, request rate, serta metrik aplikasi selama rollout.

Siapkan Rollback

Deployment harus memiliki mekanisme untuk kembali ke versi sebelumnya apabila versi baru mengalami masalah. Kubernetes menyediakan revision history dan mekanisme rollback untuk Deployment, sehingga versi sebelumnya dapat digunakan kembali ketika diperlukan.

Pastikan Kompatibilitas Antarversi

Karena versi lama dan baru dapat berjalan bersamaan, API, database schema, konfigurasi, dan format data harus dirancang agar tetap kompatibel selama masa transisi.

Lakukan Pengujian Sebelum Deployment

Automated testing, integration testing, dan pemeriksaan konfigurasi dapat membantu mengurangi kemungkinan versi bermasalah masuk ke production.

Gunakan Observability

Logging, metrics, tracing, dan alerting membantu tim mengetahui kondisi aplikasi selama rollout dan menemukan masalah lebih cepat.

Apakah Rolling Deployment Selalu Berarti Tanpa Downtime?

Tidak selalu. Rolling deployment dirancang untuk melakukan pembaruan aplikasi secara bertahap sehingga gangguan layanan dapat diminimalkan, tetapi strategi ini tidak secara otomatis menjamin zero downtime. Keberhasilannya bergantung pada arsitektur aplikasi, jumlah instance, konfigurasi deployment, kesiapan sistem, serta kemampuan aplikasi dalam menangani proses pergantian versi.

Sebagai contoh, jika aplikasi hanya memiliki satu instance, tidak ada instance lain yang dapat melayani trafik ketika instance tersebut sedang diperbarui. Gangguan juga dapat terjadi apabila versi baru mengalami kegagalan saat dijalankan, health check tidak dikonfigurasi dengan baik, atau terdapat perubahan database yang tidak kompatibel antara versi lama dan versi baru. Oleh karena itu, rolling deployment sebaiknya dipahami sebagai strategi untuk melakukan pembaruan secara bertahap dan mengurangi risiko downtime, bukan sebagai jaminan bahwa layanan akan selalu tersedia tanpa gangguan.

Kesimpulan

Rolling deployment adalah strategi deployment yang mengganti versi lama aplikasi dengan versi baru secara bertahap, sehingga tidak seluruh instance diperbarui secara bersamaan. Pendekatan ini dapat membantu menjaga availability, mengurangi risiko deployment, dan mendukung proses rilis aplikasi yang lebih terkontrol.

Dalam penerapannya, rolling deployment perlu memperhatikan jumlah instance, health check, monitoring, kompatibilitas antara versi lama dan baru, serta mekanisme rollback. Pada Kubernetes, strategi RollingUpdate menjadi strategi default untuk Deployment dan dapat dikontrol menggunakan parameter seperti maxUnavailable dan maxSurge.

Rolling deployment juga memiliki karakteristik berbeda dibandingkan Recreate, Blue-Green Deployment, dan Canary Deployment. Oleh karena itu, pemilihan strategi perlu disesuaikan dengan arsitektur aplikasi, kebutuhan availability, kapasitas infrastruktur, dan tingkat risiko perubahan.

Dengan perencanaan dan monitoring yang tepat, rolling deployment dapat menjadi salah satu pendekatan penting dalam CI/CD, cloud computing, container orchestration, dan pengembangan aplikasi modern. Untuk memperdalam wawasan mengenai hosting, server, cloud computing, DevOps, dan teknologi website, Anda dapat menemukan berbagai panduan informatif di Blog Hosteko. Sementara itu, Hosteko Hosting Indonesia dapat menjadi pilihan bagi Anda yang membutuhkan layanan hosting untuk mendukung website dan kebutuhan digital bisnis.