Spring Boot: Canary Deploy, Rollback Aman, dan Observability Dasar berarti merilis versi baru ke sebagian kecil trafik lebih dulu, memantau dampaknya, lalu memperluas rollout hanya jika indikator tetap sehat. Untuk aplikasi backend Spring Boot, pendekatan ini membantu menurunkan risiko bug produksi, regresi performa, dan rollback yang kacau.

Artikel ini fokus pada implementasi praktis di lingkungan container, Kubernetes, atau VM tanpa bergantung pada vendor tertentu. Kita akan bahas alur rilis, health check dengan Spring Boot Actuator, metrik yang wajib dipantau, logging terstruktur, tracing dasar, deteksi error rate dan latensi, langkah rollback aman, serta postmortem ringan agar deploy berikutnya lebih stabil.

Kapan canary deploy layak dipakai

Canary deploy paling berguna saat perubahan menyentuh jalur kritis: autentikasi, pembayaran, query database utama, integrasi pihak ketiga, atau perubahan konfigurasi runtime. Jika Anda langsung mengalihkan 100% trafik ke versi baru, kesalahan kecil bisa berdampak ke semua pengguna sekaligus.

Dengan canary, versi baru hanya menerima sebagian kecil trafik, misalnya 1-10%. Jika error rate, latensi, atau konsumsi resource memburuk, Anda bisa menghentikan rollout sebelum insiden melebar.

Trade-off canary deploy

  • Keuntungan: risiko rilis lebih kecil, deteksi dini regresi, rollback lebih cepat.
  • Kekurangan: perlu observability yang cukup, routing trafik yang bisa dikendalikan, dan disiplin verifikasi pascadeploy.
  • Kesalahan umum: mengaktifkan canary tanpa baseline metrik, tanpa endpoint health yang benar, atau tanpa rencana rollback yang jelas.

Alur rilis canary yang sederhana dan realistis

Untuk backend Spring Boot, alur minimal yang aman biasanya seperti ini:

  1. Build image/artifact yang immutable.
  2. Jalankan verifikasi pra-rilis: migrasi database yang aman, smoke test, dan pengecekan konfigurasi.
  3. Deploy versi baru sebagai canary dengan replika sedikit atau trafik kecil.
  4. Pastikan readiness baru menjadi sehat setelah aplikasi benar-benar siap menerima request.
  5. Pantau metrik utama selama beberapa menit: error rate, p95/p99 latency, CPU, memory, restart, dan dependency failure.
  6. Jalankan verifikasi pascadeploy: endpoint penting, query DB utama, koneksi cache, dan alur bisnis inti.
  7. Jika sehat, naikkan trafik bertahap. Jika tidak, rollback cepat ke versi stabil.

Di Kubernetes, pembagian trafik bisa dilakukan lewat dua deployment dan service/ingress yang mendukung pembobotan atau melalui skala pod yang dikendalikan. Di VM atau load balancer sederhana, Anda bisa menambahkan node baru sebagai canary lalu mengarahkan sebagian trafik ke sana.

Tujuan canary bukan sekadar “ada versi baru yang hidup”, tetapi membuktikan bahwa versi baru tetap sehat di bawah trafik nyata.

Health check yang benar: readiness, liveness, dan startup

Banyak rollback gagal karena health check dikonfigurasi terlalu dangkal. Endpoint hanya menjawab 200 OK, tetapi koneksi database macet, thread pool habis, atau dependency eksternal gagal. Karena itu, pisahkan makna tiap health check:

  • Liveness: proses masih hidup dan tidak deadlock. Jika gagal, runtime/orchestrator boleh me-restart container.
  • Readiness: aplikasi siap menerima trafik. Jika gagal, instance sebaiknya dikeluarkan dari load balancer tanpa langsung di-restart.
  • Startup: berguna saat startup lambat agar aplikasi tidak dianggap rusak terlalu cepat.

Contoh konfigurasi Spring Boot Actuator

Konfigurasi berikut menunjukkan pola umum yang aman untuk mengekspos health, info, dan metrik dasar. Nama properti dapat sedikit berbeda tergantung versi, jadi sesuaikan dengan dokumentasi Spring Boot yang Anda gunakan.

management.endpoints.web.exposure.include=health,info,metrics,prometheus,loggers
management.endpoint.health.probes.enabled=true
management.health.livenessstate.enabled=true
management.health.readinessstate.enabled=true
management.endpoint.health.show-details=never
management.server.port=8080

Jika Anda ingin endpoint actuator berada di path terpisah, gunakan base path yang konsisten dengan konfigurasi infra Anda.

management.endpoints.web.base-path=/actuator

Apa yang sebaiknya masuk readiness

Readiness sebaiknya mencerminkan kemampuan instance melayani request secara aman. Biasanya meliputi:

  • Koneksi database utama.
  • Ketersediaan connection pool.
  • Koneksi ke cache jika cache wajib untuk jalur kritis.
  • Status konfigurasi atau secret yang dibutuhkan aplikasi.

Namun, jangan memasukkan semua dependency eksternal ke readiness secara buta. Jika satu API pihak ketiga sesekali gagal tetapi aplikasi masih bisa melayani sebagian besar endpoint, menandai seluruh instance sebagai not ready justru bisa memperburuk keadaan.

Kesalahan umum health check

  • Readiness terlalu optimistis: endpoint sehat sebelum migrasi, warm-up cache, atau koneksi database benar-benar siap.
  • Liveness terlalu agresif: dependency eksternal lambat lalu container terus direstart, padahal masalahnya bukan proses mati.
  • Health endpoint dibuka terlalu lebar: detail sensitif diekspos ke publik.

Observability dasar yang wajib ada sebelum canary

Canary tanpa observability hanya mengganti risiko besar menjadi ketidakpastian kecil. Sebelum rollout bertahap, pastikan Anda punya tiga hal: metrik, log, dan jejak request dasar.

Metrik inti yang perlu dipantau

Jangan mulai dari dashboard yang terlalu ramai. Untuk rilis, fokus pada metrik yang membantu keputusan lanjut atau rollback:

  • Request rate: memastikan canary benar-benar menerima trafik.
  • Error rate: proporsi 5xx, timeout, dan exception aplikasi.
  • Latency: minimal p50 dan p95; p99 lebih baik jika tersedia.
  • Resource: CPU, memory, garbage collection, restart count.
  • Dependency metrics: durasi query database, error koneksi, timeout ke service lain.

Jika menggunakan Micrometer dan endpoint Prometheus, Spring Boot Actuator sudah memberi fondasi yang baik untuk metrik HTTP dan JVM. Yang penting adalah bagaimana Anda membaca hasilnya saat deploy.

Deteksi error rate dan latensi saat canary

Saat canary aktif, bandingkan versi baru dengan versi stabil, bukan hanya melihat angka absolut. Misalnya:

  • Error 5xx naik hanya di pod canary.
  • p95 latency versi baru lebih tinggi pada endpoint tertentu.
  • Jumlah timeout ke database meningkat setelah perubahan query.

Ini penting karena lonjakan trafik umum atau gangguan dependency bersama bisa membuat semua versi terlihat buruk. Canary efektif jika Anda bisa membedakan gejala khusus versi baru dari gangguan sistemik.

Structured logging untuk investigasi cepat

Log teks bebas sulit difilter saat insiden. Gunakan log terstruktur, minimal dalam JSON atau format key-value konsisten. Pastikan setiap log request penting memiliki:

  • timestamp
  • level
  • service name
  • environment
  • version atau release id
  • trace id / correlation id
  • HTTP method, path, status
  • durasi request
  • error class atau root cause jika gagal

Contoh pola log yang berguna:

{
  "timestamp": "2026-06-20T10:15:30Z",
  "level": "ERROR",
  "service": "order-service",
  "env": "prod",
  "version": "2026.06.20-1",
  "traceId": "8f3c1d...",
  "path": "/api/orders",
  "status": 500,
  "durationMs": 842,
  "error": "DataIntegrityViolationException"
}

Dengan field version, Anda bisa langsung memisahkan log canary dari versi stabil saat investigasi.

Tracing dasar tanpa kompleksitas berlebihan

Anda tidak harus membangun distributed tracing penuh untuk mulai aman. Tracing dasar berarti setiap request membawa correlation ID atau trace ID yang diteruskan antar service. Manfaatnya:

  • Melihat alur request lintas service saat error.
  • Menghubungkan log aplikasi dengan request tertentu.
  • Mengidentifikasi dependency yang memperlambat response.

Jika stack Anda sudah mendukung propagasi trace context, aktifkan secara konsisten. Jika belum, minimal buat filter/interceptor yang memastikan request ID masuk ke MDC/log context dan diteruskan ke downstream service melalui header.

Contoh verifikasi pascadeploy untuk Spring Boot

Setelah canary aktif, jangan hanya menunggu dashboard. Jalankan verifikasi kecil tapi bermakna:

  1. Cek endpoint health dan pastikan instance benar-benar ready.
  2. Panggil endpoint bisnis utama dengan data aman/non-destruktif.
  3. Periksa log error pada versi canary.
  4. Bandingkan p95 latency canary versus stable.
  5. Pastikan koneksi database, cache, dan queue tidak menunjukkan lonjakan error.

Contoh pengecekan health dan metrik

curl -fsS http://app-host:8080/actuator/health
curl -fsS http://app-host:8080/actuator/metrics
curl -fsS http://app-host:8080/actuator/prometheus

Untuk Kubernetes, Anda juga perlu memastikan pod canary benar-benar masuk status Ready dan tidak restart berulang:

kubectl get pods -n production -o wide
kubectl describe pod <nama-pod> -n production
kubectl logs <nama-pod> -n production --tail=200

Jika berjalan di VM, lakukan verifikasi serupa dari sisi process supervisor, load balancer, dan log aplikasi. Prinsipnya sama: instance harus siap, menerima trafik, dan tidak menunjukkan gejala error tersembunyi.

Rollback aman: cepat, kecil, dan bisa diprediksi

Rollback yang baik bukan rollback yang heroik, tetapi rollback yang sudah disiapkan. Pada banyak kasus, rollback tercepat adalah mengalihkan trafik kembali ke versi lama, bukan memperbaiki versi baru di tempat.

Strategi rollback yang praktis

  • Jika canary menggunakan porsi trafik kecil: set trafik canary ke 0%, pertahankan versi stabil melayani 100% trafik.
  • Jika rollout dilakukan dengan mengganti replika: scale down deployment baru dan scale up deployment lama yang masih tersedia.
  • Jika di VM/load balancer: keluarkan node canary dari pool lalu drain koneksi secara aman.

Prinsip pentingnya: jangan menghapus versi lama terlalu cepat. Simpan cukup lama sampai Anda yakin rollout stabil.

Perhatian khusus pada perubahan database

Rollback aplikasi sering mudah; rollback skema database tidak selalu. Karena itu, gunakan pendekatan migrasi yang kompatibel dua arah sejauh mungkin:

  • Tambahkan kolom baru sebelum kode baru membutuhkannya.
  • Hindari langsung menghapus kolom yang masih dibaca versi lama.
  • Lakukan perubahan destruktif di tahap terpisah setelah versi baru benar-benar stabil.

Kesalahan umum adalah menganggap rollback image otomatis memulihkan sistem, padahal data yang sudah ditulis oleh versi baru mungkin tidak lagi kompatibel dengan versi lama.

Kapan harus rollback, bukan menunggu

Beberapa sinyal yang sebaiknya memicu rollback cepat:

  • Error 5xx naik jelas pada canary.
  • Latensi p95/p99 memburuk signifikan hanya di versi baru.
  • Readiness flapping: pod berganti sehat-tidak sehat berulang.
  • Lonjakan restart, OOM, atau deadlock thread.
  • Bug fungsional pada alur bisnis utama walau metrik sistem terlihat normal.

Jika Anda masih berdebat apakah rollback perlu dilakukan, sering kali itu tanda bahwa kriteria rollback belum ditentukan sebelum rilis. Tetapkan ambang keputusan lebih awal.

Checklist deploy agar rilis berikutnya lebih stabil

Sebelum deploy

  • Artifact/image immutable dan bisa ditelusuri ke commit tertentu.
  • Konfigurasi environment sudah divalidasi.
  • Migrasi database aman untuk rollback aplikasi.
  • Health endpoint, metrik, dan log versi aktif dan bisa diakses.
  • Ambang rollback sudah disepakati: error rate, latency, restart, atau bug fungsional.

Saat canary berjalan

  • Trafik canary benar-benar kecil di awal.
  • Bandingkan canary dengan stable, bukan angka mentah saja.
  • Verifikasi endpoint utama dengan request nyata yang aman.
  • Pantau log error per versi dan per endpoint.
  • Jangan memperluas rollout saat metrik masih ambigu.

Setelah rollout penuh

  • Pantau metrik beberapa waktu, jangan anggap selesai saat semua pod hijau.
  • Simpan versi lama sampai jendela observasi lewat.
  • Catat anomali kecil meski tidak sampai rollback.

Postmortem ringan setelah insiden rilis

Tidak semua insiden perlu dokumen panjang. Untuk tim kecil, postmortem ringan sudah cukup selama isinya konkret dan bisa ditindaklanjuti.

Format singkat yang efektif

  • Apa yang berubah: commit, konfigurasi, migrasi, dependency.
  • Apa gejalanya: error rate, endpoint terdampak, durasi insiden.
  • Bagaimana terdeteksi: alert, dashboard, laporan pengguna, log.
  • Mengapa lolos sebelum deploy: gap test, health check salah, observability kurang, asumsi salah.
  • Apa tindakan perbaikan: checklist baru, test tambahan, alarm baru, perubahan proses rollout.

Hindari postmortem yang hanya menyalahkan operator atau developer. Fokus pada celah sistem: sinyal yang kurang, otomatisasi yang belum ada, atau rollback yang masih manual dan lambat.

Kesalahan umum yang sering terjadi

  • Actuator aktif, tetapi tidak dimanfaatkan: endpoint ada, dashboard tidak ada, alert tidak ada.
  • Readiness hanya memeriksa proses hidup: hasilnya trafik masuk ke instance yang belum siap.
  • Canary terlalu besar: 50% trafik bukan canary kecil untuk perubahan berisiko.
  • Tidak membedakan error aplikasi dan error dependency: investigasi jadi salah arah.
  • Rollback tidak pernah dilatih: saat insiden nyata, tim bingung urutan langkahnya.

Penutup

Untuk aplikasi backend Spring Boot, canary deploy, rollback aman, dan observability dasar tidak harus rumit. Mulailah dari hal yang memberi dampak besar: health check readiness/liveness yang benar, Actuator untuk health dan metrik, logging terstruktur dengan version dan trace ID, lalu aturan rollback yang jelas.

Jika Anda hanya menerapkan satu perbaikan minggu ini, pastikan versi baru bisa menerima sedikit trafik, bisa dibedakan metriknya dari versi lama, dan bisa dikeluarkan dari trafik dalam hitungan menit. Itu sudah cukup untuk membuat proses rilis jauh lebih aman dan lebih mudah di-debug.