Penerapan canary deployment membatasi dampak rilis baru dengan mengalirkan sebagian kecil traffic (misalnya 5% hingga 10%) ke versi kandidat sebelum peluncuran penuh. Namun, jika versi canary membawa regresi performa atau bug kritis, sistem harus mendeteksi anomali secara instan dan mengeksekusi rollback terukur sebelum insiden meluas ke seluruh infrastruktur produksi.

1. Skenario Kegagalan: Lonjakan Latensi p99 dan HTTP 5xx

Regresi pada rilis aplikasi backend sering kali tidak terdeteksi pada unit test atau staging environment berbeban rendah. Skenario umum pasca-deploy canary meliputi:

  • Connection Pool Exhaustion: Adanya kebocoran koneksi database atau kueri N+1 baru yang menyebabkan antrean HikariCP penuh, memicu lonjakan latensi p99 secara drastis dari 120ms ke lebih dari 2.000ms.
  • Thread Pool Starvation: Operasi I/O blocking yang dijalankan tanpa offloading asinkron, menghabiskan thread kerja Tomcat.
  • HTTP 5xx Spikes: Kesalahan serialisasi JSON atau unhandled runtime exceptions pada kode baru yang menghasilkan respon HTTP 500 Internal Server Error seketika traffic masuk.

2. Konfigurasi Observability: Spring Boot Actuator dan Micrometer

Untuk mendeteksi anomali pada tingkat pod canary secara terisolasi, aplikasi harus mengekspos metrik HTTP dengan rincian status code, URI, dan histogram percentile. Tambahkan dependensi spring-boot-starter-actuator dan micrometer-registry-prometheus ke dalam build pipeline.

Gunakan konfigurasi application.yml berikut untuk mengaktifkan export metrik percentile latency pada http.server.requests dan menyuntikkan tag versi aplikasi:

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus
  endpoint:
    health:
      probes:
        enabled: true
      show-details: when_authorized
  metrics:
    distribution:
      percentiles-histogram:
        http.server.requests: true
      slo:
        http.server.requests: 100ms, 300ms, 500ms, 1s, 2s
    tags:
      application: ${spring.application.name:backend-service}
      version: ${APP_VERSION:v1.0.0}

Label version memungkinkan Prometheus membedakan metrik antara deployment stable (baseline) dan canary (canary release).

3. Kueri PromQL Operasional untuk Alerting Otomatis

Observabilitas yang efektif memerlukan PromQL queries presisi yang memantau tingkat kegagalan dan latensi versi canary. Gunakan kueri berikut untuk mendeteksi degradasi SLO.

A. HTTP 5xx Error Rate Canary (> 2% dalam rentang 2 menit)

sum(rate(http_server_requests_seconds_count{application="backend-service", version="v1.2.0", status=~"5.."}[2m]))
/
sum(rate(http_server_requests_seconds_count{application="backend-service", version="v1.2.0"}[2m])) * 100 > 2

B. Latensi p99 Canary (> 1000ms dalam rentang 2 menit)

histogram_quantile(
  0.99,
  sum(rate(http_server_requests_seconds_bucket{application="backend-service", version="v1.2.0"}[2m])) by (le)
) > 1.0

Jika kondisi PromQL ini terpenuhi selama 1 hingga 2 siklus evaluasi Prometheus Alertmanager, sistem harus memicu notifikasi kritis dan otomatisasi rollback.

4. Prosedur Rollback Cepat dan Isolasi Traffic

Saat alert terpicu, tindakan prioritas pertama adalah mitigasi dampak dengan memotong rute traffic canary, bukan melakukan debugging langsung di pod produksi.

  1. Isolasi Traffic via Ingress/Service Mesh: Ubah bobot routing traffic ke target 0% untuk versi canary melalui ingress controller (misal: NGINX Ingress canary annotation) atau Istio VirtualService.
  2. Scale Down Deployment Canary: Turunkan replika canary untuk melepaskan resource infrastruktur dan koneksi database.
    # Potong traffic seketika dengan menurunkan replika canary ke 0
kubectl scale deployment/backend-service-canary --replicas=0 -n production
  3. Verifikasi Pemulihan Metrik: Pantau dashboard baseline untuk memastikan latensi p99 global dan error rate kembali ke ambang batas normal.

5. Pencegahan: Tuning Readiness Probe dan Automated Analysis Gate

Pencegahan regresi membutuhkan konfigurasi deployment yang ketat sebelum traffic pengguna dialihkan.

  • Tuning Readiness Probe: Pastikan probe tidak mematikan pod secara keliru namun cukup cepat menandai pod unready saat koneksi database jenuh. Pisahkan endpoint readiness dan liveness actuator: /actuator/health/readiness dan /actuator/health/liveness.
  • Automated Canary Analysis (ACA): Integrasikan tools seperti Argo Rollouts atau Flagger. Alat ini mengeksekusi kueri PromQL di atas secara berkala. Jika canary gagal melewati metrik uji selama fase kenaikan traffic bertahap (misal: 5% -> 10%), controller akan membatalkan rollout otomatis tanpa menunggu intervensi teknisi.

6. Format Postmortem Insiden Ringkas

Setelah mitigasi tuntas, dokumentasikan kegagalan tanpa mencari kambing hitam (blameless postmortem). Format ringkas berikut memastikan akar masalah tertangani:

Incident ID: INC-2026-0312-CANARY
Severity: Sev-2 (Canary Degradation)
Blast Radius: ~8% total user requests terdampak selama 4 menit; 412 request menghasilkan HTTP 500.

Timeline

  • 14:02 UTC: Canary deployment v1.2.0 dimulai dengan alokasi 10% traffic.
  • 14:04 UTC: Alert PromQL CanaryHighErrorRate terpicu (HTTP 5xx mencapai 6.4%). Latensi p99 naik ke 2.8s.
  • 14:05 UTC: On-call SRE mengeksekusi scale down backend-service-canary ke 0 replika.
  • 14:06 UTC: Traffic canary dialihkan penuh ke versi stable v1.1.9. Latensi p99 global kembali ke 115ms. Insiden termitigasi.

Root Cause Analysis (RCA)

Versi v1.2.0 menambahkan eager fetching pada entitas JPA tanpa pagination batas pada endpoint /api/v1/orders, menyebabkan buffer memori melonjak dan thread database pool HikariCP terkuras seketika saat menerima request concurrent.

Action Items

  • Tambahkan default query pagination pada query order repository (Owner: Backend Team, Deadline: T+2 hari).
  • Terapkan Automated Canary Analysis via Argo Rollouts menggunakan metrik histogram latency PromQL untuk auto-abort (Owner: Platform Team, Deadline: T+5 hari).
  • Tambahkan performance testing skenario DB connection exhaustion pada pipeline CI (Owner: QA/Dev, Deadline: T+7 hari).