Deploy Python free-threaded ke produksi tidak boleh diperlakukan seperti upgrade runtime biasa. Perubahan model konkurensi dapat mengubah profil performa, memunculkan race condition yang sebelumnya tersembunyi, dan memperbesar risiko inkompatibilitas pada C-extension atau dependency yang belum siap.

Untuk tim DevOps, pendekatan yang aman adalah deployment bertahap dengan rollback terukur: tetapkan baseline sebelum rilis, isolasi eksperimen dari jalur trafik utama, gunakan canary atau shadow traffic, pantau metrik yang relevan, dan siapkan ambang rollback yang jelas sebelum eksperimen dimulai. Dengan cara ini, Anda bisa menguji manfaat runtime baru tanpa menjadikan layanan utama sebagai arena coba-coba.

Mengapa Python free-threaded perlu strategi deploy khusus

Perubahan ke runtime Python free-threaded berpotensi mengubah karakteristik aplikasi pada beberapa lapisan sekaligus:

  • Perilaku threading berubah, sehingga bottleneck yang dulu tersembunyi bisa muncul sebagai contention, lock convoy, atau lonjakan CPU.
  • C-extension dan native dependency mungkin belum sepenuhnya aman pada model eksekusi baru.
  • Asumsi library tingkat aplikasi tentang thread safety bisa tidak lagi valid di beban nyata.
  • Profil resource dapat bergeser: throughput naik pada satu beban, tetapi latensi tail, memory footprint, atau context switching justru memburuk.

Karena itu, pertanyaan utamanya bukan hanya "apakah aplikasi jalan?", tetapi "apakah aplikasi tetap stabil, dapat dipulihkan cepat, dan aman untuk trafik produksi?"

Risiko utama yang harus dinilai sebelum deploy

1. Kompatibilitas C-extension dan library

Risiko terbesar biasanya bukan pada kode Python murni, melainkan pada dependency yang melibatkan native code. Contoh umum: driver database, serializer berperforma tinggi, package kriptografi, scientific stack, image processing, atau observability agent yang menyuntikkan hook native.

Yang perlu diverifikasi:

  • Apakah dependency penting Anda secara eksplisit mendukung runtime free-threaded?
  • Apakah ada catatan issue tentang crash, deadlock, memory corruption, atau race condition?
  • Apakah build pipeline Anda menghasilkan artefak terpisah untuk runtime eksperimen ini?
  • Apakah ada fallback ke implementasi pure Python jika extension native bermasalah?

Catatan: Jangan berasumsi bahwa library yang lolos unit test otomatis aman di produksi. Banyak bug konkurensi baru muncul pada beban paralel, durasi panjang, atau kombinasi dependency tertentu.

2. Regresi performa yang tidak terlihat dari throughput rata-rata

Throughput yang tampak lebih baik tidak otomatis berarti deploy aman. Tim sering hanya membandingkan request per second, lalu melewatkan gejala yang lebih penting:

  • Latensi p95/p99 memburuk.
  • Error intermiten meningkat saat concurrency naik.
  • CPU idle hilang karena spin, locking, atau contention.
  • Memory bertambah karena lifecycle object, allocator behavior, atau jumlah thread aktif.

3. Perubahan failure mode

Pada runtime baru, gejala kegagalan juga bisa berubah. Aplikasi mungkin tidak crash, tetapi mulai menunjukkan:

  • Timeout lebih sering.
  • Worker hang atau stagnan.
  • Antrian internal menumpuk.
  • Utilisasi CPU tinggi tanpa kenaikan throughput yang sebanding.

Ini sebabnya rollback trigger harus berbasis indikator layanan, bukan hanya crash total.

Checklist pra-deploy Python free-threaded

Sebelum eksperimen dimulai, siapkan checklist yang bisa diaudit. Minimal mencakup hal berikut:

Inventaris dependency

  • Daftar library kritikal dan tandai mana yang memakai C-extension/native code.
  • Kelompokkan dependency berdasarkan risiko: rendah, sedang, tinggi.
  • Tentukan komponen yang must-pass sebelum canary, misalnya driver database, client cache, auth, logging, tracing, dan serializer.

Baseline performa dan reliabilitas

  • Ambil baseline dari runtime saat ini pada beban produksi normal.
  • Simpan metrik minimal: throughput, p50/p95/p99 latency, error rate, CPU, memory, thread count, queue depth, restart count.
  • Jalankan load test yang mendekati pola trafik nyata, bukan hanya benchmark sintetis sederhana.

Keamanan rollout

  • Runtime baru harus dipasang sebagai deployment terpisah, bukan mengganti seluruh pool sekaligus.
  • Siapkan feature flag atau route flag untuk mengontrol trafik ke pool eksperimen.
  • Pastikan rollback dapat dilakukan tanpa rebuild besar atau migrasi yang memblokir.

Observability

  • Semua instance eksperimen wajib memiliki label versi runtime yang jelas.
  • Dashboard terpisah untuk membandingkan pool stabil dan pool free-threaded.
  • Alert khusus untuk canary agar anomali kecil tidak tenggelam dalam agregasi seluruh cluster.

Uji konkurensi dan soak test

  • Jalankan stress test multi-thread untuk endpoint paling sibuk.
  • Lakukan soak test beberapa jam atau lebih lama untuk mendeteksi leak, degradasi gradual, dan deadlock langka.
  • Uji skenario shutdown, restart, dan autoscaling agar perilaku worker dapat diamati saat lifecycle berubah.

Strategi deployment bertahap yang aman

1. Mulai dari environment non-kritis

Gunakan staging atau pre-production yang semirip mungkin dengan produksi. Fokus bukan hanya pada lulusnya test suite, tetapi juga pada:

  • Konsistensi startup.
  • Perilaku saat concurrency tinggi.
  • Interaksi dengan dependency eksternal seperti database, cache, broker, dan observability agent.

Jika staging terlalu bersih dan tidak mewakili produksi, hasilnya mudah menyesatkan. Prioritaskan replay trafik atau synthetic workload yang menyerupai endpoint paling mahal.

2. Gunakan shadow traffic sebelum canary aktif

Shadow traffic cocok sebagai langkah awal ketika risiko kompatibilitas masih tinggi. Permintaan produksi disalin ke pool free-threaded, tetapi responsnya tidak dikembalikan ke pengguna. Keuntungannya:

  • Tidak memengaruhi layanan utama.
  • Dapat mengungkap crash, timeout, memory leak, atau lock contention lebih awal.
  • Bisa dipakai untuk membandingkan waktu respons dan error terhadap pool stabil.

Keterbatasannya: shadow traffic tidak selalu menangkap efek penuh dari state mutation, ordering, atau side effect. Karena itu, idealnya endpoint yang berpotensi menulis data diberi guard tambahan atau diarahkan ke dependency non-produksi jika memungkinkan.

3. Canary dengan persentase trafik kecil

Setelah shadow traffic cukup stabil, lanjutkan ke canary dengan porsi kecil trafik nyata. Tujuannya adalah mengukur perilaku end-to-end di bawah beban produksi dengan risiko yang terkendali.

Prinsip canary yang baik:

  • Mulai kecil, misalnya subset instance atau rute tertentu, bukan seluruh layanan.
  • Pilih endpoint representatif, terutama yang CPU-bound, I/O-heavy, dan concurrency-sensitive.
  • Tahan tiap tahap cukup lama untuk melihat efek delayed, bukan hanya 5-10 menit.
  • Naikkan trafik hanya bila metrik dan error budget tetap sehat.

Jangan menaikkan persentase trafik hanya karena aplikasi terlihat "baik-baik saja" pada metrik rata-rata. Latensi tail, memory growth, dan contention sering baru terlihat setelah durasi lebih panjang.

4. Isolasi eksperimen dari jalur utama

Jika memungkinkan, pisahkan pool free-threaded pada:

  • Node pool atau autoscaling group tersendiri.
  • Queue worker tersendiri untuk job asinkron.
  • Rute ingress atau upstream terpisah.
  • Dashboard dan alert terpisah.

Tujuannya sederhana: kegagalan eksperimen tidak boleh menyeret pool stabil. Isolasi ini juga memudahkan rollback cepat hanya dengan mengalihkan trafik.

Metrik observability yang wajib dipantau

Untuk deploy Python free-threaded, observability tidak cukup berhenti di HTTP status dan CPU umum. Pantau minimal metrik berikut, dan bandingkan langsung dengan pool stabil.

1. Latensi

  • p50 untuk melihat respons umum.
  • p95/p99 untuk mendeteksi tail latency dan lock contention.
  • Durasi per endpoint agar regresi tidak tertutup oleh agregasi seluruh service.

2. Error rate

  • 5xx rate.
  • Timeout rate.
  • Connection reset atau upstream failure.
  • Exception rate per jenis error.

Khusus runtime eksperimen, pecah exception berdasarkan signature. Kenaikan error acak kecil bisa menjadi tanda race condition.

3. CPU dan utilisasi worker

  • Total CPU per pod/instance.
  • CPU per proses jika model worker lebih dari satu.
  • Load average dan tanda oversubscription thread.

CPU yang naik tajam tanpa throughput tambahan adalah sinyal buruk. Itu sering menunjukkan contention, spin, atau overhead sinkronisasi.

4. Memory

  • RSS atau working set per instance.
  • Laju pertumbuhan memory dari waktu ke waktu.
  • Frekuensi restart karena OOM.

Leak ringan bisa luput pada tes pendek. Karena itu, grafik memory terhadap waktu lebih penting daripada snapshot tunggal.

5. Thread contention dan indikator konkurensi

Tidak semua stack memiliki metrik contention yang siap pakai, tetapi setidaknya upayakan visibilitas terhadap:

  • Jumlah thread aktif.
  • Durasi antrean kerja internal.
  • Waktu tunggu lock jika aplikasi atau library mengeksposnya.
  • Context switch tinggi yang tidak sejalan dengan throughput.

Jika Anda memiliki profiler sampling di produksi, gunakan secara hati-hati untuk melihat apakah waktu CPU habis pada lock, scheduler, atau section kritis tertentu.

6. Metrik dependency eksternal

  • Latency database dan pool saturation.
  • Connection pool exhaustion.
  • Latency cache atau broker.
  • Error dari sidecar, proxy, atau tracing agent.

Runtime baru kadang memperlihatkan bottleneck lama yang sebelumnya tertutup oleh serialisasi eksekusi. Hasilnya tampak seperti bug Python, padahal sumbernya ada di dependency eksternal.

Contoh pendekatan canary dan rollback

Berikut contoh skema sederhana yang bisa dipakai di level operasional:

  1. Deploy pool stable dan pool free-threaded secara terpisah.
  2. Arahkan shadow traffic ke pool eksperimen selama periode observasi awal.
  3. Jika sehat, aktifkan canary untuk sebagian kecil trafik nyata.
  4. Bandingkan metrik canary versus stable pada endpoint yang sama.
  5. Rollback otomatis atau manual jika ambang tertentu terlewati.

Contoh konfigurasi rollout tidak harus bergantung pada tool tertentu. Yang penting adalah ada mekanisme pengalihan trafik yang bisa dibalik cepat.

# Pseudocode kebijakan rollout internal / service mesh / ingress controller
rollout:
  stable_pool: app-python-stable
  canary_pool: app-python-free-threaded
  stages:
    - traffic_percent: 0
      mode: shadow
      hold: 2h
    - traffic_percent: 1
      mode: canary
      hold: 1h
    - traffic_percent: 5
      mode: canary
      hold: 4h
    - traffic_percent: 10
      mode: canary
      hold: 24h
  rollback_if:
    - p99_latency_increase > threshold
    - error_rate_increase > threshold
    - cpu_per_request_increase > threshold
    - memory_growth_sustained == true
    - crash_loop_detected == true

Angka persentase dan durasi di atas hanyalah contoh pola, bukan rekomendasi pasti. Sesuaikan dengan toleransi risiko layanan Anda.

Trigger rollback yang jelas dan dapat dijalankan

Rollback yang baik harus ditetapkan sebelum deploy, bukan dinegosiasikan saat insiden sedang berlangsung. Gunakan kombinasi metrik layanan dan indikator stabilitas proses.

Contoh trigger rollback

  • Latensi p95 atau p99 meningkat signifikan dibanding baseline dalam jendela waktu yang konsisten.
  • Error rate naik melewati error budget canary.
  • CPU per request memburuk tanpa kenaikan throughput.
  • Memory terus tumbuh selama periode observasi.
  • Crash loop, deadlock, atau worker hang mulai muncul.
  • Anomali hanya terjadi pada pool free-threaded, bukan pada pool stabil.

Trigger yang terlalu longgar membuat eksperimen terlalu lama dibiarkan merusak kualitas layanan. Sebaliknya, trigger yang terlalu sensitif akan menghasilkan rollback palsu. Karena itu, bandingkan dengan baseline historis pada jam dan pola trafik yang mirip.

Praktik yang disarankan: rollback harus bisa dilakukan hanya dengan mengalihkan trafik ke pool stabil, tanpa perlu menunggu rebuild image, perubahan skema, atau restart massal yang lama.

Tindakan pencegahan agar eksperimen runtime baru tidak mengganggu layanan utama

  • Jangan gabungkan eksperimen runtime dengan perubahan besar lain seperti migrasi ORM, tuning worker, atau update dependency mayor.
  • Bekukan konfigurasi penting selama fase evaluasi agar sinyal regresi tidak tercampur faktor lain.
  • Pisahkan antrian background job jika worker asinkron juga diuji dengan runtime baru.
  • Gunakan deployment immutabel sehingga stable dan eksperimen dapat dibedakan jelas pada artefak, label, dan observability.
  • Lindungi operasi tulis sensitif dengan scope eksperimen yang sempit atau dependency terisolasi jika perlu.
  • Siapkan kill switch di layer traffic management untuk mematikan canary seketika.

Kesalahan umum adalah menguji runtime baru bersamaan dengan perubahan konfigurasi autoscaling atau jumlah worker. Jika hasilnya buruk, Anda tidak tahu penyebab dominannya.

Contoh runbook insiden singkat

Runbook berikut cukup ringkas untuk dipakai on-call saat canary menunjukkan regresi:

Gejala

  • Latensi p99 canary naik tajam.
  • Error timeout meningkat hanya pada pool free-threaded.
  • CPU instance eksperimen tinggi, throughput tidak naik.

Langkah respons

  1. Verifikasi bahwa anomali terbatas pada pool free-threaded melalui label versi runtime.
  2. Hentikan kenaikan trafik canary.
  3. Jika ambang rollback terpenuhi, alihkan seluruh trafik dari canary ke pool stabil.
  4. Pastikan error rate dan latensi pulih pada jalur stabil.
  5. Bekukan deploy lanjutan sampai bukti awal dikumpulkan.

Pengumpulan bukti minimum

  • Snapshot dashboard latensi, error, CPU, memory, dan thread count.
  • Log exception dominan dan stack trace yang relevan.
  • Durasi kejadian, persentase trafik canary, serta endpoint yang terdampak.
  • Daftar dependency native yang aktif pada jalur request tersebut.

Keputusan lanjutan

  • Jika gejala mengarah ke incompatibility library, hentikan eksperimen sampai dependency tervalidasi.
  • Jika gejala mengarah ke contention aplikasi sendiri, lanjutkan investigasi lewat profiling dan audit thread safety.
  • Jika penyebab belum jelas, ulangi di shadow traffic atau environment isolasi sebelum mencoba canary lagi.

Postmortem ringan bila muncul regresi

Tidak semua regresi perlu postmortem panjang, tetapi tetap perlu dokumentasi singkat yang bisa ditindaklanjuti. Format ringan biasanya cukup:

  • Apa yang berubah: pool free-threaded diaktifkan untuk persentase trafik tertentu.
  • Dampak: latensi, error, atau konsumsi resource yang memburuk.
  • Deteksi: alert atau dashboard mana yang pertama kali menunjukkan anomali.
  • Pemulihan: rollback trafik ke pool stabil, durasi sampai pulih.
  • Akar dugaan: contention internal, extension native, driver tertentu, atau konfigurasi thread/worker.
  • Tindak lanjut: tambah test konkurensi, perketat observability, validasi dependency, atau batasi scope eksperimen berikutnya.

Tujuan postmortem ringan bukan mencari siapa yang salah, tetapi memastikan eksperimen selanjutnya lebih aman dan lebih cepat dievaluasi.

Pola keputusan: kapan lanjut, kapan tunda

Lanjutkan rollout jika

  • Canary stabil dalam durasi observasi yang cukup.
  • Tidak ada kenaikan signifikan pada latensi tail dan error rate.
  • CPU dan memory masih dalam batas operasional yang dapat diterima.
  • Tidak ada tanda incompatibility pada dependency penting.

Tunda atau hentikan jika

  • Hasil hanya bagus pada benchmark sintetis, tetapi buruk pada trafik nyata.
  • Ada exception acak yang sulit direproduksi dan hanya muncul pada pool eksperimen.
  • Profiler atau log menunjukkan lock contention atau deadlock yang meningkat.
  • Tim belum memiliki observability yang cukup untuk membedakan bug aplikasi dari bug dependency.

Penutup

Strategi terbaik untuk deploy Python free-threaded di produksi adalah memperlakukannya sebagai eksperimen runtime berisiko terukur, bukan upgrade minor. Fokus utamanya bukan sekadar mengejar throughput, melainkan menjaga keselamatan layanan melalui baseline yang kuat, rollout bertahap, observability yang tajam, dan rollback yang sudah didefinisikan sejak awal.

Jika tim Anda disiplin pada checklist pra-deploy, canary atau shadow traffic, dan trigger rollback yang jelas, maka evaluasi runtime baru bisa dilakukan dengan aman. Bahkan ketika hasilnya negatif, Anda tetap memperoleh data yang berguna tanpa mengorbankan stabilitas layanan utama.