Kami telah menyelesaikan masalah kesalahan pada promosi besar 429 dengan menggunakan gateway Kubernetes, dan juga menghemat 30% dari biaya server.

Bulan lalu, saat Black Friday, tim kami hampir saja gagal:13% dari permintaan penyelesaian alamat pengguna ditolak dengan kode kesalahan 429.Setelah dilakukan pemeriksaan di backend, baru diketahui bahwa aturan pembatasan lalu lintas (throttling) yang sebelumnya diberikan secara terpisah untuk masing-masing mikroservis terlalu ketat. Akibatnya, lalu lintas di modul pencarian logistik meningkat tiga kali lipat, dan sumber daya lain yang tersedia tidak dapat digunakan karena tidak ada jalur untuk mengalirkannya.

Sebelumnya, kami selalu berpikir bahwa Kubernetes Gateway adalah komponen yang kompleks yang hanya digunakan oleh perusahaan besar. Baru setelah kami mengalami masalah dan terpaksa mengimplementasikannya, kami menyadari bahwa prosesnya tidak memakan waktu lebih dari seminggu, dan hasilnya jauh lebih baik dari yang kami perkirakan.

Apa sebenarnya itu Kubernetes Gateway?

Singkatnya, ini merupakan pintu masuk utama untuk semua lalu lintas di seluruh kluster Kubernetes Anda. Semua permintaan dari luar akan pertama-tama dikirim ke sini, kemudian dialihkan ke layanan backend yang sesuai. Versi open-source yang kami gunakan mampu menangani hingga 12.000 permintaan per detik dengan hanya satu instance, sehingga tim kecil tidak perlu khawatir tentang masalah kinerja.

Tiga keuntungan nyata yang kami dapatkan:

Yang paling langsung terlihat: Aturan pembatasan lalu lintas (throttling) tidak perlu lagi diatur secara terpisah untuk setiap layanan. Sebelumnya, saat ada promosi besar, kami harus mengubah nilai ambang pembatasan lalu lintas untuk tujuh atau delapan layanan mikro, dan jika ada satu yang tidak diatur dengan benar, akan terjadi masalah. Sekarang, pembatasan lalu lintas dilakukan secara dinamis di tingkat gateway, sehingga sumber daya server yang tersedia dapat secara otomatis dialokasikan ke modul-modul yang memiliki lalu lintas yang tinggi. Akibatnya, jumlah laporan kesalahan tipe 429 selama promosi Natal ini langsung turun menjadi nol.

Yang kedua adalah penghematan biaya. Sebelumnya, untuk menanggung beban puncak, kami menambahkan 2 server cadangan untuk masing-masing dari 3 layanan inti, sehingga tingkat penggunaan sumber daya hanya sekitar 20% sebagian besar waktu. Sekarang, gateway dapat melakukan distribusi beban secara otomatis, sehingga kami dapat mengurangi jumlah server menjadi 6 unit. Setelah dihitung, biaya penggunaan cloud bulanan kami berkurang sebesar 30%.

Yang ketiga adalah tidak perlu lagi meminta bagian backend untuk terus-menerus mengubah logika umum seperti penanganan cross-domain dan autentikasi. Sebelumnya, setiap kali layanan baru diluncurkan, bagian backend harus menulis kode verifikasi JWT secara manual. Sekarang, dengan menetapkan aturan di lapisan gateway saja, masalah tersebut dapat diatasi. Dengan demikian, kami yang hanya ada 3 orang di bagian backend dapat menghemat waktu setidaknya setengah hari per minggu untuk menulis kode bisnis.

Jangan hanya mendengarkan kelebihannya saja, kami sudah benar-benar mengalami 2 masalah serius akibatnya.

Pertama-tama, masalah yang muncul adalah pengaturan waktu tunggu (timeout) default yang sangat tidak memadai. Pada hari pertama layanan kami diluncurkan, kami menemukan bahwa 5% dari permintaan pemecahan alamat (address resolution) mengalami timeout. Setelah melakukan pemeriksaan yang cukup lama, kami menyadari bahwa waktu tunggu default dari gateway adalah 30 detik, sementara proses pemecahan alamat kami sendiri membutuhkan waktu hingga 40 detik. Setelah mengubah pengaturan waktu tunggu tersebut, masalah tersebut segera teratasi. Sebelum meluncurkan layanan, sangat penting untuk memeriksa nilai batas waktu tunggu untuk setiap interface bisnis (business interface) secara individu.

Kesalahan kedua adalah jangan langsung memasukkan semua fitur sekaligus. Awalnya kami ingin mengaktifkan semua fitur seperti log, throttling, WAF, dan pengelolaan versi beta (grayscale release) sekaligus, tetapi karena kesalahan dalam konfigurasi, seluruh akses ke kluster terputus selama 20 menit. Setelah itu, kami hanya mengaktifkan fitur routing dan throttling terlebih dahulu, dan setelah berjalan selama 3 hari tanpa masalah, barulah kami perlahan-lahan menambahkan fitur lainnya. Sejak saat itu, tidak pernah ada lagi masalah yang terjadi.

Haruskah kita menggunakannya? Kriteria penilaian yang kami berikan sangat sederhana.

Kondisi yang cocok untuk digunakan:

• Jumlah mikroservis Anda sudah melebihi 5, dan setiap kali Anda mengubah konfigurasi umum, Anda perlu mengubah beberapa bagian secara bersamaan.
• Seringkali mengalami puncak permintaan (traffic peaks), dan sumber daya tidak dapat dialokasikan secara fleksibel di antara berbagai layanan.
• Tim backend hanya terdiri dari kurang dari 5 orang, dan kami tidak ingin membuang-buang waktu untuk menulis logika umum yang sama berulang kali.

Situasi yang tidak perlu diperbaiki:

• Kamu hanya memiliki 2 mikroservis, dan lalu lintas pengguna selalu stabil sepanjang tahun. Saat ini, penggunaan NGINX untuk melakukan proses forwarding tidak menimbulkan masalah sama sekali.
• Tidak ada seorang pun di seluruh tim yang memahami dasar-dasar Kubernetes; jangan memaksakan diri untuk mengikuti teknologi baru hanya karena ingin mengikutinya.

2 saran praktis untuk tim kecil yang baru memulai

Tidak perlu repot memilih produk, untuk tim kecil cukup menggunakan APIX atau Kong yang bersifat open source saja. Dokumentasinya lengkap, dan jika menghadapi masalah, biasanya ada solusinya jika dicari di internet. Tidak perlu membeli versi komersial; fitur-fitur versi gratis sudah cukup untuk kebutuhan.

Sebelum diluncurkan, alihkan terlebih dahulu 10% dari lalu lintas data selama 24 jam untuk memeriksa apakah ada masalah seperti waktu tunggu yang terlalu lama atau permintaan yang salah ditangkap oleh sistem. Jika semuanya berjalan dengan baik, barulah alihkan seluruh lalu lintas data. Jangan langsung mengalihkan semua lalu lintas data sejak awal.

Terakhir, ada pertanyaan yang sering diajukan: Sebelumnya, tidak ada yang khusus meneliti tentang gateway untuk ketiga backend kami, dan kami berhasil membangunnya dalam waktu 2 hari hanya dengan membaca dokumen resmi. Sebenarnya, tidak sesulit yang Anda kira.