Use Case

Blue Green Deployment with TD #

Dengan bantuan Traffic Distributor, Kamu bisa melakukan pembaruan aplikasi secara “tidak terlihat” menggunakan metode blue-green deployment, tanpa menyebabkan downtime. Kemampuan ini sangat penting di masa sekarang, di mana perkembangan aplikasi begitu cepat dan persaingan terus meningkat. Kamu harus sering memperbarui proyek agar tetap relevan, menarik pengguna baru, dan tidak tertinggal dari pesaing. Namun, kalau proses pembaruan ini justru mengganggu jalannya aplikasi dan menurunkan ketersediaannya, hal itu bisa berdampak buruk pada citra layanan Kamu.

Jadi, mari kita bahas bagaimana cara menghindari masalah seperti ini dan menerapkan pembaruan blue-green ke proyekmu dengan bantuan solusi routing traffic yang sudah disiapkan.

1. Anggap saja kita punya dua environment, masing-masing sudah diberi alias Blue dan Green agar mudah dibedakan. Lalu, ada satu environment terpisah yang berisi Traffic Distributor, yang bertugas mengatur alur traffic di antara kedua environment tersebut.

2. Untuk memperbarui aplikasi di backend ke versi terbaru tanpa menyebabkan downtime pada seluruh proyek, pembaruannya harus dilakukan secara bergiliran. Jadi, pertama-tama, kita hentikan dulu aliran traffic ke salah satu environment (misalnya Blue) dengan mengatur ulang konfigurasi add-on di Traffic Distributor.

Untuk melakukannya, geser slider Traffic Ratio ke posisi 0 … 100, agar backend pertama (misalnya Blue) tidak lagi menerima traffic.

Setelah itu, klik Apply untuk melanjutkan.

3. Sekarang, karena semua traffic masuk hanya diarahkan ke environment kedua (Green), Kamu bisa melakukan perubahan apa pun di environment Blue tanpa terburu-buru — misalnya, melakukan deploy dan menguji versi baru dari aplikasi Kamu.

4. Sekarang, kalau Kamu ingin memperbarui proyek di host kedua (Green), cukup ulangi langkah ke-2 dan ke-3 di atas, lalu tukar peran antar environment — yaitu geser slider Traffic Ratio ke posisi sebaliknya (100 … 0). Dengan begitu, salinan proyek di Blue akan menangani semua permintaan, sementara Green bisa masuk ke mode pemeliharaan.

5. Terakhir, buka kembali tampilan konfigurasi Traffic Distributor dan atur ulang bobot (weight) server sesuai kebutuhan agar operasional kembali seperti semula, contohnya

Selesai! Hasilnya, aplikasi kamu berhasil diperbarui di kedua backend, sementara para pengguna tetap bisa mengakses layanan tanpa gangguan selama seluruh proses berlangsung.

 

Failover Protection with TD #

Traffic Distributor memudahkan penerapan perlindungan failover tingkat lanjut dengan modul health check bawaan. Modul ini secara otomatis dan rutin memeriksa apakah backend tersedia, dan akan mengeluarkan backend yang tidak tersedia dari jalur routing. Fungsi ini diaktifkan secara default, namun Kamu bisa menyesuaikan perilaku modul ini jika diperlukan. Ikuti langkah-langkah di bawah ini untuk melakukannya :

1. Masuk ke panel NGINX Config dengan mengklik tombol yang bernama sama, lalu buka file /etc/nginx/nginx-jelastic.conf yang berada di dalam direktori Root:

Klik dua kali pada file tersebut untuk membukanya di tab baru dan mulai mengedit.

2. Gulir ke sekitar baris ke-50, tempat konfigurasi add-on dideklarasikan, lalu temukan modul check yang dibutuhkan di dalam bagian upstream common. Modul ini bekerja dengan parameter berikut (dengan tanda kurung siku [ ] menunjukkan bahwa parameter tersebut bersifat opsional):

 check interval={interval} fall={fail_count} rise={rise_count} [timeout={timeout}] [default_down={true/false}] [port={port}] [type={type}] 

Berikut penjelasan dari setiap parameter yang digunakan dalam konfigurasi modul health check pada Traffic Distributor :

• {interval} – jeda antar dua pengecekan berturut-turut, dalam milidetik
• {fail_count} – jumlah kegagalan pengecekan berturut-turut sebelum server dianggap tidak tersedia
• {rise_count} – jumlah keberhasilan pengecekan berturut-turut sebelum server dianggap tersedia kembali
• {timeout} – waktu maksimal (dalam milidetik) yang ditunggu untuk respons dari backend sebelum dianggap gagal
• {true/false} – menentukan status awal backend saat startup (true = down secara default sampai lolos pengecekan)
• {port} – nomor port yang digunakan saat mengecek backend; default-nya 0 (artinya pakai port default sesuai protokol)
• {type} – jenis protokol yang digunakan untuk melakukan pengecekan apakah backend aktif, seperti:
  • tcp – koneksi socket TCP biasa
  • ssl_hello – mengirim paket SSL Client Hello dan menunggu Server Hello
  • http – mengirim permintaan HTTP dan mengevaluasi respons
  • mysql – konek ke server MySQL dan menerima respons sambutan
  • ajp – mengirim AJP Cping dan menunggu respons Cpong
  • fastcgi – mengirim permintaan FastCGI dan memproses responsnya

Berdasarkan pengaturan pada gambar di atas, kedua backend akan diperiksa setiap 3 detik untuk respons HTTP normal (yaitu kode status 200, yang berarti permintaan telah dipenuhi). Jika pemeriksaan gagal tiga kali berturut-turut, backend yang bersangkutan akan ditandai sebagai “down” dan dikecualikan dari rute, sehingga semua permintaan akan diarahkan ke environment kedua. Dan ketika server yang down kembali aktif, ia akan secara otomatis ditambahkan kembali (yaitu, setelah 3 permintaan berhasil berturut-turut) ke daftar backend.

3. Setelah Kamu menyimpan perubahan pada konfigurasi NGINX balancer, perubahan tersebut bisa diterapkan tanpa perlu me-restart seluruh server (sehingga Kamu bisa menghindari downtime pada proyek). Caranya adalah dengan melakukan graceful reload melalui opsi Reload configuration yang ada di menu add-on.

Konfirmasi tindakan kamu melalui pop-up yang muncul, dan dalam beberapa detik, pengaturan failover protection yang baru akan langsung diterapkan.

 

A/B Testing with TD #

Setiap situs web atau aplikasi komersial biasanya memiliki fitur seperti pembelian produk, pendaftaran, konversi ke versi berbayar, langganan, dan sebagainya. Jumlah aksi seperti ini yang dilakukan oleh pengguna (dan jika dihitung dalam persen disebut conversion rate) sangat dipengaruhi oleh tampilan visual aplikasi, teks iklan, dan strategi pemasaran lainnya. Perbandingan antara dua versi aplikasi untuk menentukan mana yang memberikan conversion rate lebih baik disebut A/B testing. Proses ini sangat berguna untuk menemukan kombinasi tampilan, konten, dan fitur yang paling efektif dalam menarik pengguna dan meningkatkan pendapatan.

Dengan bantuan Traffic Distributor, Kamu bisa dengan mudah menerapkan A/B testing pada proyek kamu. Berikut langkah awalnya:

1. Untuk melakukan A/B testing, kamu butuh dua versi aplikasi yang berbeda untuk dibandingkan, dan metode monitoring sesuai kebutuhan untuk melacak aksi pengguna tertentu (misalnya saat pengguna mengklik tombol tertentu).

 

 

2. Selanjutnya, instal Traffic Distributor atau cukup konfigurasikan ulang jika kamu sudah memilikinya :

Hal-hal yang wajib kamu atur dalam konfigurasi adalah:

• Routing method – pilih Sticky Sessions, agar tiap pengguna tetap diarahkan ke versi aplikasi yang sama selama sesi berlangsung
• Traffic ratio – atur ke 50:50 supaya pembagian traffic merata, sehingga analisis hasil A/B testing jadi adil dan seimbang

 

 

3. Sekarang semuanya sudah siap, request terbaru akan dibagi secara merata ke kedua versi aplikasi, dan setiap aksi pengguna akan dimonitor untuk mencatat skor konversi. Tinggal bagikan link entry point Traffic Distributor kamu (baik itu domain environment atau domain kustom) ke para pengguna, lalu tunggu selama beberapa waktu sampai mereka mencoba kedua versi aplikasi dan Kamu mendapatkan data konversinya.

4. Analisis data yang sudah terkumpul untuk menentukan versi aplikasi mana yang lebih unggul. Secara logis, environment dengan Conversion Rate lebih tinggi adalah yang paling layak digunakan di produksi. Sementara versi lainnya bisa Kamu hapus, atau Kamu ubah lagi untuk keperluan uji coba selanjutnya.