Go Fiber: Blue-Green Deploy dengan Health Check dan Auto Rollback

Go Fiber: Blue-Green Deploy dengan Health Check dan Auto Rollback adalah pendekatan praktis untuk merilis versi baru aplikasi tanpa menghentikan layanan, sekaligus mengurangi risiko error saat cutover trafik. Intinya, Anda menjalankan dua environment identik: blue sebagai versi aktif dan green sebagai kandidat rilis. Setelah green lolos health check dan verifikasi, trafik dipindahkan. Jika metrik memburuk, sistem melakukan rollback ke blue.

Pendekatan ini cocok untuk layanan HTTP berbasis Go Fiber karena proses start-up relatif cepat, sederhana untuk diberi endpoint health, dan mudah diintegrasikan dengan reverse proxy atau load balancer. Namun, keberhasilan blue-green deployment tidak ditentukan oleh framework saja. Faktor penentunya adalah definisi health check yang benar, cutover yang terkendali, observability yang cukup, dan rollback yang benar-benar bisa dieksekusi otomatis.

Mengapa Blue-Green Deploy untuk Go Fiber

Blue-green deployment memisahkan proses rilis dari proses aktivasi trafik. Artinya, Anda dapat men-deploy versi baru lebih dulu, memverifikasi kondisinya, lalu baru mengalihkan trafik. Ini berbeda dari strategi yang langsung menimpa instance aktif dan baru mengetahui masalah setelah user terdampak.

Manfaat utamanya:

Downtime minimal karena environment lama tetap melayani trafik sampai versi baru siap.
Rollback cepat karena kembali ke versi lama biasanya cukup dengan mengembalikan routing.
Validasi lebih aman karena kandidat rilis bisa diuji dalam kondisi mirip produksi.
Lebih mudah diaudit karena fase deploy, health verification, cutover, dan rollback terpisah jelas.

Trade-off yang perlu diperhatikan:

Membutuhkan dua environment aktif, sehingga konsumsi resource meningkat.
Jika aplikasi menyimpan state lokal, sesi, atau file di disk lokal, perpindahan trafik bisa bermasalah.
Perubahan skema database harus dirancang hati-hati agar kompatibel dengan versi lama dan baru selama masa transisi.

Arsitektur Dasar Blue-Green Deployment

Secara umum, arsitekturnya terdiri dari komponen berikut:

Blue environment: versi yang saat ini menerima trafik produksi.
Green environment: versi baru yang baru di-deploy dan belum atau baru sebagian menerima trafik.
Reverse proxy/load balancer: komponen yang menentukan trafik diarahkan ke blue atau green.
Health checker: memeriksa liveness dan readiness.
Observability: log, metrik, dan alert untuk menilai apakah rilis sehat.
Rollback controller: otomatis atau semi-otomatis mengembalikan trafik jika terjadi degradasi.

Alur idealnya seperti ini:

Deploy versi baru ke green.
Jalankan liveness check untuk memastikan proses hidup.
Jalankan readiness check untuk memastikan aplikasi benar-benar siap menerima request.
Lakukan smoke test dan verifikasi pasca-deploy pada green.
Alihkan trafik dari blue ke green.
Pantau metrik error rate, latency, dan saturation selama jendela observasi.
Jika metrik sehat, pertahankan green sebagai aktif. Jika tidak, rollback ke blue.

Health Check yang Benar: Liveness vs Readiness

Kesalahan paling umum dalam blue-green deployment adalah menyamakan proses hidup dengan siap menerima trafik. Keduanya harus dipisahkan.

Liveness Check

Liveness menjawab pertanyaan: apakah proses aplikasi masih berjalan dan tidak macet? Endpoint ini sebaiknya ringan dan tidak bergantung pada dependency eksternal yang mudah fluktuatif. Tujuannya untuk mendeteksi proses hang, deadlock, atau kondisi crash loop.

Readiness Check

Readiness menjawab pertanyaan: apakah instance ini layak menerima trafik sekarang? Endpoint ini boleh memeriksa dependency penting seperti koneksi database, cache, atau konektivitas internal minimum. Jika readiness gagal, instance seharusnya tidak menerima trafik baru.

Catatan: Jangan jadikan endpoint readiness terlalu mahal. Jika setiap health check melakukan query kompleks, health check justru bisa memperburuk beban sistem.

Contoh Struktur Endpoint Health di Go Fiber

Berikut contoh sederhana namun realistis untuk memisahkan liveness dan readiness pada aplikasi Go Fiber. Contoh ini memakai abstraksi dependency agar status siap bisa dikontrol secara eksplisit.

package main

import (
    "context"
    "log"
    "sync/atomic"
    "time"

    "github.com/gofiber/fiber/v2"
)

type DependencyChecker interface {
    Ping(ctx context.Context) error
}

type AppState struct {
    ready atomic.Bool
    db    DependencyChecker
}

func main() {
    app := fiber.New()

    state := &AppState{}
    state.ready.Store(false)

    // Inisialisasi dependency di sini
    // state.db = ...

    app.Get("/health/live", func(c *fiber.Ctx) error {
        return c.Status(fiber.StatusOK).JSON(fiber.Map{
            "status": "alive",
        })
    })

    app.Get("/health/ready", func(c *fiber.Ctx) error {
        if !state.ready.Load() {
            return c.Status(fiber.StatusServiceUnavailable).JSON(fiber.Map{
                "status": "starting",
            })
        }

        if state.db != nil {
            ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
            defer cancel()

            if err := state.db.Ping(ctx); err != nil {
                return c.Status(fiber.StatusServiceUnavailable).JSON(fiber.Map{
                    "status": "dependency_unhealthy",
                })
            }
        }

        return c.Status(fiber.StatusOK).JSON(fiber.Map{
            "status": "ready",
        })
    })

    app.Get("/", func(c *fiber.Ctx) error {
        return c.SendString("ok")
    })

    go func() {
        // Simulasi bootstrap: koneksi DB, cache warmup, config load, dsb.
        time.Sleep(3 * time.Second)
        state.ready.Store(true)
        log.Println("application is ready")
    }()

    log.Fatal(app.Listen(":3000"))
}

Mengapa pendekatan ini efektif:

/health/live selalu ringan dan fokus pada proses aplikasi.
/health/ready hanya sukses jika aplikasi sudah selesai bootstrap dan dependency inti dapat diakses.
Status ready tidak aktif otomatis saat proses baru start, sehingga trafik tidak dialihkan terlalu cepat.

Alur Deploy Aman untuk Go Fiber

1. Deploy ke Environment Green

Deploy artefak baru ke environment green tanpa menyentuh trafik produksi. Pada tahap ini, versi lama di blue tetap melayani semua request.

Prinsip penting:

Gunakan artefak yang immutable, misalnya image atau binary hasil build yang sudah diuji.
Pastikan konfigurasi green identik dengan blue kecuali versi aplikasinya.
Hindari perubahan konfigurasi tersembunyi yang hanya ada di salah satu environment.

2. Tunggu Readiness

Jangan memindahkan trafik hanya karena proses sudah mendengarkan port. Tunggu sampai endpoint /health/ready mengembalikan status sehat secara stabil dalam beberapa kali pengecekan berturut-turut.

Kesalahan umum:

Readiness dianggap sehat sebelum migrasi internal selesai.
Dependency eksternal belum siap tetapi health check tetap 200.
Timeout health check terlalu pendek sehingga memicu false negative.

3. Jalankan Smoke Test

Setelah readiness sukses, lakukan smoke test dasar terhadap green secara langsung, misalnya:

Memanggil endpoint utama aplikasi.
Verifikasi autentikasi atau middleware dasar.
Cek jalur baca/tulis yang paling kritikal.
Pastikan response code dan payload minimum sesuai ekspektasi.

Smoke test tidak perlu menggantikan test suite penuh. Tujuannya adalah memastikan fungsi terpenting benar-benar berjalan di environment target.

4. Cutover Trafik

Setelah green lulus smoke test, ubah reverse proxy atau load balancer agar trafik mengarah ke green. Cutover dapat dilakukan sekaligus atau bertahap. Jika environment dan tooling Anda mendukung pembagian trafik bertahap, pendekatan itu memberi sinyal lebih aman. Namun untuk blue-green murni, cutover biasanya berupa perpindahan target upstream aktif.

5. Verifikasi Pasca-Rilis

Setelah cutover, jangan anggap deploy selesai. Pantau metrik selama jendela observasi singkat, misalnya beberapa menit pertama. Fokus pada:

Error rate HTTP 5xx atau error aplikasi.
Latency terutama p95/p99 jika tersedia.
Resource saturation seperti CPU, memori, atau antrean koneksi.
Dependency failure seperti lonjakan timeout ke database atau service internal.

Contoh Konfigurasi Reverse Proxy atau Load Balancer Secara Umum

Setiap produk reverse proxy memiliki sintaks berbeda, tetapi prinsipnya sama: definisikan dua upstream dan sediakan mekanisme untuk mengaktifkan salah satu target. Contoh berikut adalah representasi umum, bukan konfigurasi vendor tertentu.

upstream app_blue {
    server 10.0.1.10:3000;
    server 10.0.1.11:3000;
}

upstream app_green {
    server 10.0.2.10:3000;
    server 10.0.2.11:3000;
}

route production_app {
    active_upstream app_blue;
    health_check /health/ready;
}

Saat cutover, active_upstream dipindah dari app_blue ke app_green. Beberapa load balancer dapat melakukan health probe otomatis ke endpoint readiness dan menahan trafik jika target belum sehat.

Hal yang perlu dijaga:

Probe health check harus menuju endpoint yang benar-benar mencerminkan kesiapan menerima trafik.
Durasi timeout dan jumlah retry harus seimbang; terlalu agresif memicu flapping, terlalu longgar memperlambat deteksi masalah.
Jika ada keep-alive connection lama, pahami bahwa sebagian koneksi bisa tetap hidup sesaat setelah cutover.

Auto Rollback Berdasarkan Metrik Error dan Latensi

Rollback otomatis hanya berguna jika kriterianya jelas. Jangan mendasarkan rollback pada satu request gagal. Gunakan jendela observasi dan ambang yang masuk akal untuk mendeteksi degradasi nyata.

Metrik Minimum untuk Rollback

Error rate: peningkatan signifikan pada 5xx, timeout, atau error domain yang penting.
Latency: lonjakan median atau tail latency dibanding baseline sebelum deploy.
Readiness instability: instance baru sering keluar-masuk status ready.

Alur Auto Rollback

Cutover trafik ke green.
Mulai jendela observasi.
Kumpulkan metrik dari reverse proxy, aplikasi, dan dependency utama.
Bandingkan dengan threshold atau baseline sebelum deploy.
Jika ambang pelanggaran terlewati secara konsisten, alihkan trafik kembali ke blue.
Tandai rilis sebagai gagal dan hentikan promosi otomatis berikutnya.

Pseudocode Orkestrasi Rollback

deploy green
wait until green.readiness == healthy
run smoke tests on green
switch traffic to green
start observation window

if error_rate > threshold for N checks
   or latency > threshold for N checks
   or readiness flaps repeatedly:
    switch traffic back to blue
    mark release failed
else:
    mark green as stable

Trade-off auto rollback:

Kelebihan: mengurangi waktu paparan error di produksi.
Kekurangan: threshold yang salah bisa memicu rollback palsu saat ada lonjakan trafik normal atau gangguan dependency sementara.

Karena itu, metrik rollback sebaiknya mempertimbangkan konteks, bukan sekadar satu angka mentah.

Observability Dasar: Log, Metrik, dan Alert

Blue-green deployment tanpa observability akan sulit dibedakan antara deploy gagal dan dependency bermasalah. Minimal, siapkan tiga lapisan observability berikut.

1. Log Terstruktur

Gunakan log yang konsisten dan mudah difilter. Minimal sertakan:

timestamp
service name
version atau release id
environment color: blue/green
request id atau correlation id
status code dan latency

Ini membantu menjawab: apakah error hanya muncul di green, endpoint mana yang terdampak, dan kapan mulai terjadi.

2. Metrik Aplikasi dan Trafik

Metrik minimum yang sebaiknya dikumpulkan:

Request count
Error count per status code
Request latency
Readiness status
Restart atau crash count
Koneksi ke dependency, bila tersedia

Jika memungkinkan, tampilkan metrik dengan label version atau deployment_color agar perbandingan blue vs green mudah dilakukan.

3. Alert yang Relevan

Alert sebaiknya memberi sinyal operasional yang bisa ditindak, bukan sekadar bising. Contoh kondisi alert:

Error 5xx naik tajam setelah cutover.
Latency melonjak pada endpoint kritikal.
Readiness gagal terus setelah deploy.
Rollback otomatis terjadi.

Tips debugging: Saat terjadi lonjakan error setelah cutover, bandingkan log dan metrik blue vs green pada rentang waktu yang sama. Jika hanya green yang bermasalah, kemungkinan besar isu berasal dari aplikasi baru atau konfigurasi barunya.

Checklist Deployment Blue-Green untuk Go Fiber

Build artefak yang immutable dan sudah lolos test.
Pastikan konfigurasi blue dan green identik selain versi aplikasi.
Sediakan endpoint /health/live dan /health/ready.
Definisikan readiness berdasarkan dependency inti, bukan sekadar port terbuka.
Deploy ke green tanpa mengubah trafik aktif.
Tunggu readiness stabil.
Jalankan smoke test terhadap green.
Siapkan dashboard log dan metrik untuk versi baru.
Lakukan cutover trafik.
Pantau error rate, latency, dan readiness pada jendela observasi.
Rollback otomatis atau manual jika metrik memburuk.
Dokumentasikan hasil deploy, termasuk anomali kecil sekalipun.

Kesalahan Umum yang Sering Terjadi

Health check terlalu dangkal: endpoint selalu 200 meskipun DB tidak bisa diakses.
Health check terlalu berat: endpoint readiness menjalankan query mahal yang memperlambat sistem.
Database migration tidak kompatibel: versi lama dan baru tidak bisa hidup berdampingan selama cutover.
Session state lokal: user berpindah ke environment baru tetapi state hilang.
Rollback hanya ada di dokumen: secara teori bisa rollback, tetapi prosedurnya belum pernah diuji.
Tidak ada baseline metrik: tim tidak tahu apakah latency saat ini memang memburuk atau hanya fluktuasi normal.

Skenario Insiden Singkat

Berikut contoh insiden yang cukup realistis pada blue-green deployment aplikasi Go Fiber.

Kejadian

Versi baru di-deploy ke green dan readiness sukses. Setelah cutover, error 5xx meningkat dan latency endpoint login memburuk. Sistem mendeteksi degradasi selama jendela observasi dan otomatis mengembalikan trafik ke blue.

Gejala

Lonjakan error pada endpoint autentikasi.
Timeout ke dependency session store meningkat.
Endpoint lain relatif normal.

Analisis Singkat

Akar masalah ternyata bukan pada Go Fiber itu sendiri, melainkan konfigurasi timeout client internal pada versi baru yang terlalu pendek. Di lingkungan nyata, dependency session store memiliki latensi sesaat yang masih normal, tetapi versi baru memotongnya terlalu cepat sehingga request gagal.

Postmortem Ringan

Timeline

10:00 - Deploy versi baru ke green dimulai.
10:03 - Readiness green sehat dan smoke test lolos.
10:05 - Cutover trafik dari blue ke green.
10:06 - Alert error rate dan latency endpoint login meningkat.
10:07 - Sistem auto rollback ke blue.
10:10 - Trafik stabil kembali, investigasi dimulai.

Root Cause

Konfigurasi timeout pada client internal untuk session store di versi baru terlalu agresif, sehingga request yang sebelumnya masih valid kini diperlakukan sebagai timeout.

Dampak

Sejumlah request login gagal selama jendela cutover singkat.
User pada endpoint non-login sebagian besar tidak terdampak.
Tidak ada kehilangan data, tetapi ada gangguan akses sementara.

Mitigasi

Auto rollback mengalihkan trafik kembali ke blue.
Rilis ditandai gagal dan promosi otomatis dihentikan.
Konfigurasi timeout dikembalikan ke nilai aman untuk pengujian ulang.

Tindakan Pencegahan

Tambahkan smoke test khusus untuk alur login.
Masukkan timeout dependency sebagai item review sebelum rilis.
Buat alert yang memisahkan error per endpoint kritikal.
Uji rollback secara berkala, bukan hanya saat insiden nyata.

Penutup

Blue-green deployment untuk aplikasi Go Fiber bekerja baik jika Anda memandangnya sebagai proses operasional end-to-end, bukan hanya teknik routing. Endpoint liveness dan readiness harus dirancang dengan benar, cutover trafik harus terkendali, verifikasi pasca-rilis wajib dilakukan, dan rollback harus didorong oleh metrik yang relevan.

Jika ingin mulai sederhana, fokuslah pada empat hal: health check yang benar, cutover yang mudah dibalik, metrik error/latensi yang terlihat jelas, dan prosedur rollback yang rutin diuji. Dari sana, Anda bisa meningkatkan otomatisasi tanpa kehilangan kendali saat rilis produksi.

Quick Search

shopping_cart Keranjang