Kami menghemat 38% biaya pemrosesan lalu lintas dengan menggunakan gateway berbasis cloud-native, tetapi hampir saja merusak rantai distribusi produk segar di Eropa selama promo Black Friday.

Rapat tinjauan promosi besar-besaran pada Black Friday minggu lalu baru saja selesai, dan tim kami yang terdiri dari 3 orang yang bertanggung jawab atas layanan pengiriman produk segar di Eropa masih merasa khawatir: pada hari pre-order, 17% dari permintaan reservasi rantai dingin langsung ditolak (dengan kode 429), jumlah keluhan dari pengguna meningkat tiga kali lipat, dan hampir saja merusak promosi tahunan yang telah kami persiapkan selama tiga bulan.

Masalahnya terletak pada penggunaan gateway API tradisional yang telah digunakan selama dua tahun: kami menetapkan batas limitasi yang sama untuk dua interface inti, yaitu pemrosesan alamat (address resolution) dan pemesanan rantai dingin (cold chain reservation). Pada hari Black Friday, permintaan pemrosesan alamat melonjak tajam dan langsung menghabiskan kuota yang tersedia di gateway, sehingga permintaan pemesanan yang datang setelahnya tidak dapat diproses. Sebelumnya, kami selalu berpikir bahwa mengganti gateway adalah hal yang hanya perlu dilakukan oleh tim besar. Setelah mengalami masalah ini, kami menyadari bahwa gateway berbasis cloud native mungkin merupakan pilihan yang lebih menguntungkan dari segi biaya dan efisiensi bagi tim kecil.

Apa sebenarnya itu gateway berbasis cloud native?

Dengan satu kalimat saja: Ini adalah pintu masuk lalu lintas yang berjalan di dalam kluster K8s, sehingga Anda tidak perlu menyewa server secara terpisah untuk mengimplementasikannya.Anda hanya perlu fokus pada aturan routing dan strategi pengendalian lalu lintas data (traffic control), sementara hal-hal lain seperti fleksibilitas sumber daya dan peningkatan operasional serta pemeliharaan (ops dan maintenance) semuanya ditangani oleh penyedia layanan cloud.Kita sekarang menggunakan versi yang mampu menangani 20.000 permintaan per detik untuk setiap instance tunggal, sehingga tidak perlu melakukan perencanaan kapasitas terlebih dahulu.

Setelah proses penggantian, kami mendapatkan tiga pendapatan aktual.

Setelah terjadi masalah pada hari pra-penjualan, kami menghabiskan 3 hari untuk beralih ke gateway berbasis cloud-native. Pada hari pertandingan Black Friday, tidak ada lagi masalah pembatasan bandwidth (throttling) yang menyebabkan kesalahan penanganan data. Selain itu, ada tiga keuntungan lain yang melebihi ekspektasi kami:

• Biayanya langsung turun: Sebelumnya, kami menyewa dua server dengan prosesor 4 core (8G) secara terpisah untuk menjalankan gateway tradisional, ditambah dengan biaya operasional dan pemeliharaan sebesar 8 jam per bulan untuk melakukan pembaruan versi, yang totalnya mencapai 1200 euro per bulan. Sekarang, dengan menggunakan gateway berbasis cloud native yang dibayar berdasarkan jumlah pemanggilan (usage-based pricing), biayanya hanya 740 euro per bulan.Dengan langsung menghemat 38% dari biaya pemrosesan lalu lintas data
• Akhirnya saya mengerti strategi pembatasan lalu lintas (throttling) ini: sebelumnya, gateway hanya bisa menetapkan batas pembatasan lalu lintas untuk semua interface secara global. Sekarang, kita bisa menetapkan aturan yang berbeda untuk berbagai skenario bisnis—misalnya, interface pemrosesan alamat (address resolution) hanya diizinkan menerima maksimal 5000 permintaan per detik. Jadi, bahkan jika interface tersebut terkena serangan yang menyebabkan beban berlebih, hal tersebut tidak akan mempengaruhi proses pembayaran atau pemesanan yang berikutnya.
• Waktu yang dibutuhkan untuk proses handshake HTTPS telah berkurang hingga setengahnya: Sebelumnya, sertifikat SSL kami tersimpan di server gateway kami sendiri, sehingga penundaan proses handshake untuk pengguna di berbagai wilayah Eropa bisa mencapai 200ms. Sekarang, penyedia layanan cloud telah menyimpan sertifikat tersebut di node-edge (node terdekat dengan pengguna), sehingga penundaan handshake untuk sebagian besar permintaan dapat dikurangi hingga di bawah 80ms.

Jangan terburu-buru naik mobil, kami sudah pernah mengalami kedua masalah tersebut sebelumnya.

Bukan berarti bahwa semua aspek dari gateway berbasis cloud native (cloud-native gateway) hanya memiliki keuntungan saja; selama proses pengimplementasian kami juga menemukan dua masalah kecil yang hampir membuat kami harus melakukan pekerjaan ulang:

Pertama adalah masalah keterlambatan pada proses cold start (memulai sistem dari keadaan tidak aktif). Setelah kami melakukan pengujian beban (stress testing) pada hari pertama, kami menemukan bahwa setelah tidak ada permintaan selama 10 menit berturut-turut, waktu respons untuk permintaan pertama tiba-tiba meningkat menjadi lebih dari 300 milidetik. Kemudian kami menyadari bahwa instance elastis dari penyedia layanan cloud diaktifkan sesuai dengan kebutuhan, dan kami perlu menetapkan jumlah minimum instance yang harus disediakan untuk interface inti. Jika tidak, ketika tiba-tiba ada lalu lintas yang tinggi saat instance tidak aktif, hal tersebut dapat menyebabkan timeout.

Yang kedua adalah batasan dari plugin kustom. Sebelumnya, kami membuat plugin untuk verifikasi tanda tangan permintaan sendiri dan menjalankannya di gateway tradisional. Baru ketika kami beralih ke gateway berbasis cloud native, kami menyadari bahwa gateway tersebut hanya mendukung plugin dalam format WebAssembly. Kami menghabiskan dua hari untuk mengubah kode agar plugin tersebut dapat berfungsi dengan baik. Jika Anda memiliki banyak logika kustom, sebaiknya Anda terlebih dahulu memeriksa dengan jelas apa saja yang didukung oleh plugin dari pihak vendor.

Apakah benar-benar perlu menggantinya? Cukup lihat kedua kriteria penilaian ini saja.

Situasi yang seharusnya Anda ganti:

• Tim kami terdiri dari kurang dari 5 orang yang bekerja di bidang backend, dan tidak memiliki staf operasional khusus. Kami tidak ingin menghabiskan waktu untuk pemeliharaan dan peningkatan server gateway.
• Fluktuasi lalu lintas sangat besar, misalnya saat promosi besar-besaran, lalu lintas bisa mencapai 3 hingga 10 kali lipat dari biasanya. Kami tidak ingin menyewa sejumlah server terlebih dahulu karena akan menyebabkan pemborosan uang saat server tersebut tidak digunakan.

Situasi di mana Anda tidak seharusnya melakukan penggantian:

• Persyaratan kompatibilitasnya sangat ketat; semua lalu lintas data harus melewati server yang Anda kendalikan sendiri, dan tidak boleh melalui node publik penyedia layanan cloud.
• Gateway Anda memiliki banyak logika khusus yang disesuaikan, yang tidak didukung oleh gateway berbasis cloud native yang ada di pasaran. Biaya untuk mengubahnya sendiri lebih tinggi daripada biaya untuk memelihara gateway tersebut.

Tiga saran kecil untuk orang yang pertama kali mencobanya

• Tidak perlu melakukan migrasi secara penuh; lebih baik mulai dengan mengalihkan 10% dari lalu lintas ke gateway berbasis cloud untuk diuji selama seminggu. Setelah tidak ditemukan masalah, barulah lalu lintas dapat dipindahkan secara bertahap. Awalnya, kami hanya memindahkan interface penyelesaian alamat (address resolution interface) terlebih dahulu, dan setelah tidak ada masalah, barulah kami memindahkan seluruh lalu lintas.
• Interfis inti harus diatur dengan jumlah instance minimum; jangan menghemat uang itu. Saat ini, kami telah menyisakan 2 instance permanen untuk masing-masing dari dua interfis inti, yaitu reservasi rantai dingin (cold chain reservation) dan pembayaran (payment), dan tidak pernah lagi terjadi masalah dengan waktu tunggu saat sistem dihidupkan kembali (cold start timeout).
• Tidak perlu membeli versi dengan spesifikasi tertinggi; untuk sebagian besar perusahaan kecil dan menengah, fitur-fitur yang tersedia di versi dasar sudah lebih dari cukup. Versi dasar yang kita gunakan saat ini sudah cukup untuk menangani volume lalu lintas hingga 20.000 QPS tanpa perlu membayar biaya tambahan.

Jawaban terakhir untuk pertanyaan yang paling sering diajukan di dalam tim: Apakah akan terikat pada penyedia layanan cloud (cloud vendor)?

Penilaian kami adalah: untuk tim backend dengan jumlah anggota kurang dari 10 orang,Peningkatan efisiensi yang dihasilkan dari terikat dengan penyedia layanan cloud jauh lebih besar daripada biaya untuk membangun semua komponen dari awal.Jika suatu hari nanti memang diperlukan untuk beralih ke penyedia layanan cloud yang berbeda, kamu pasti sudah memiliki cukup energi untuk melakukan proses migrasi tersebut. Jadi, sekarang jangan terlalu memikirkannya.