Kami Membatasi Laju Layanan Kami Sendiri

API Mythex mengizinkan 300 permintaan per menit dari satu alamat jaringan. Batas itu ada untuk melindungi kami dari satu orang atau skrip yang memukul API tanpa henti. Di produksi, batas itu mulai menolak layanan kami sendiri, yaitu bagian edge kami yang menyajikan aplikasi yang dipublikasikan dan layanan yang menjalankan agen AI, karena masing-masing hanya menghubungi API dari beberapa alamat saja. Permintaan yang membawa kredensial internal kami sekarang dibebaskan, dan semua yang lain tetap dibatasi persis seperti sebelumnya.

Gejalanya

API mulai menjawab sebagian panggilan internal kami dengan 429 Too Many Requests. Tiga jenis panggilan terkena, dan masing-masing penting bagi seseorang yang memakai Mythex:

• Mencari aplikasi mana yang berada di domain kustom. Saat seorang pengunjung membuka aplikasi yang dipublikasikan di domainnya sendiri, edge kami bertanya ke API di mana situs itu berada. 429 di sana berarti pengunjung tidak bisa mencapai situs.
• Menyimpan giliran agen yang sedang berjalan. Selama agen bekerja, progresnya disimpan saat berjalan, sehingga balasan bertahan saat halaman disegarkan atau koneksi terputus. 429 di sana berarti progres tidak tersimpan.
• Memeriksa akses ke pratinjau. Pratinjau aplikasi yang sedang Anda bangun dibatasi aksesnya, dan gerbang itu bertanya ke API. 429 di sana berarti pratinjau tidak bisa dibuka.

Tidak satu pun dari ini adalah orang yang memanggil API. Semuanya adalah kami sendiri.

Mengapa ini terjadi

Batas laju per alamat membuat satu asumsi: satu alamat kira-kira sama dengan satu pemanggil. Untuk manusia, itu cukup dekat. Untuk infrastruktur kami sendiri, itu sangat keliru.

• Layanan edge yang menyajikan aplikasi yang dipublikasikan dan pratinjau menghubungi API dari beberapa alamat keluar bersama. Setiap pengunjung ke setiap aplikasi yang dipublikasikan, dan setiap pemeriksaan pratinjau, datang seolah-olah berasal dari salah satu dari sedikit alamat itu.
• Orkestrator, yaitu layanan yang menjalankan giliran agen, menghubungi API dari satu alamat container. Setiap giliran yang berjalan, untuk setiap pengguna, memakai alamat yang sama.

Jadi anggaran yang dimaksudkan untuk satu orang terbagi di seluruh lalu lintas sebuah layanan utuh. Layanan-layanan itu menghabiskannya bersama-sama, dan pembatas laju melakukan apa yang seharusnya: ia menolak mereka.

Perbaikannya

Layanan internal kami sudah membuktikan siapa mereka. Setiap panggilan internal membawa token internal, dan setiap rute di bawah bagian internal API memeriksa token itu sebelum melakukan apa pun.

Pembatas laju sekarang memakai pemeriksaan yang sama. Permintaan yang tokennya cocok dengan token internal masuk daftar izin dan tidak dihitung terhadap anggaran per alamat. Semua yang lain dihitung persis seperti sebelumnya: 300 permintaan per menit per alamat.

Dua detail membuat ini tidak menjadi celah:

1. Token yang salah tidak mendapat pengecualian. Daftar izin hanya cocok dengan token internal yang sebenarnya. Permintaan dengan token palsu dihitung dan dibatasi seperti yang lain, dan rute internal tetap menolaknya dengan 401 Unauthorized.
2. Batasnya sendiri tidak berubah. Kami tidak menaikkan angkanya untuk memberi ruang. Menaikkannya akan menyembunyikan masalah sampai lalu lintas bertambah lagi, dan akan melemahkan perlindungan untuk kasus yang justru menjadi alasan batas itu ada.

Kami memindahkan pengaturan pembatas laju ke satu fungsi kecil dan menulis tes terhadapnya. Satu tes mengirim 20 permintaan dengan token internal ke pembatas yang diatur untuk mengizinkan 5, dan mengharapkan semua 20 berhasil. Tes lain mengirim permintaan biasa dari satu alamat dan mengharapkan lima yang pertama berhasil dan yang setelahnya ditolak. Tes ketiga mengirim permintaan dengan token palsu dan mengharapkan permintaan itu ditolak dengan cara yang sama.

Yang kami ambil dari ini

• Batas membawa asumsi. “Satu alamat, satu pemanggil” tertanam di dalam batas per alamat. Asumsi itu berhenti benar begitu layanan Anda sendiri berada di belakang alamat bersama, dan banyak yang demikian: load balancer, jaringan edge, container, jaringan kantor.
• Bedakan lalu lintas Anda sendiri berdasarkan identitas, bukan alamat. Alamat adalah cara lalu lintas tiba, bukan siapa yang mengirimnya. Kami sudah punya kredensial yang membuktikan bahwa sebuah panggilan milik kami; pembatas laju hanya belum memeriksanya.
• Jangan memperbaikinya dengan menaikkan angka. Batas yang lebih besar akan membuat 429 hilang untuk sementara, melindungi lebih sedikit, dan gagal lagi nanti.
• Perhatikan siapa yang dibatasi. 429 yang mengenai layanan Anda sendiri adalah laporan bug tentang batas Anda, bukan tanda bahwa pembatas bekerja.

Apa artinya jika Anda membangun di Mythex

Tidak ada yang perlu Anda ubah. Aplikasi yang dipublikasikan di domain kustom, giliran agen, dan pratinjau tidak lagi bergantung pada seberapa sibuk bagian lain Mythex. Lalu lintas aplikasi Anda sendiri adalah urusan aplikasi Anda: batas yang dijelaskan di sini ada di API kami, bukan pada aplikasi yang Anda publikasikan.

Jika Anda menjalankan backend sendiri, jebakan yang sama berlaku untuk batas laju apa pun yang Anda tambahkan. Panduan kami tentang apa itu API dan daftar periksa keamanan untuk aplikasi buatan AI adalah tempat yang baik untuk memulai. Dan untuk contoh lain tentang infrastruktur kami sendiri yang menghalangi dirinya sendiri, lihat bagaimana kami membuat deploy turun ke nol error 502.