Kami Mengehadkan Kadar Perkhidmatan Kami Sendiri

API Mythex membenarkan 300 permintaan seminit dari satu alamat rangkaian. Had itu wujud untuk melindungi kami daripada seorang pengguna atau skrip yang membanjiri API. Dalam pengeluaran, ia mula menolak perkhidmatan kami sendiri, iaitu bahagian edge kami yang menghidangkan aplikasi terbitan dan perkhidmatan yang menjalankan ejen AI, kerana setiap satunya menghubungi API dari hanya segelintir alamat. Permintaan yang membawa kelayakan dalaman kami kini dikecualikan, dan semua yang lain dihadkan seperti sebelumnya.

Gejala

API mula menjawab sebahagian panggilan dalaman kami dengan 429 Too Many Requests. Tiga jenis panggilan terkena, dan setiap satu penting kepada sesiapa yang menggunakan Mythex:

• Mencari aplikasi mana yang tinggal pada domain tersuai. Apabila pelawat membuka aplikasi terbitan pada domainnya sendiri, edge kami bertanya kepada API di mana laman itu. 429 di sana bermakna pelawat tidak dapat sampai ke laman.
• Menyimpan giliran ejen yang sedang berjalan. Semasa ejen bekerja, kemajuannya disimpan sepanjang jalan, supaya balasan terselamat daripada muat semula atau sambungan yang terputus. 429 di sana bermakna kemajuan tidak disimpan.
• Menyemak akses ke pratonton. Pratonton aplikasi yang sedang anda bina dikawal, dan pengawal itu bertanya kepada API. 429 di sana bermakna pratonton tidak dapat dibuka.

Tiada satu pun daripada ini panggilan oleh orang yang menggunakan API. Kesemuanya adalah kami sendiri.

Mengapa ia berlaku

Had kadar setiap alamat membuat satu andaian: satu alamat lebih kurang sama dengan satu pemanggil. Bagi orang, itu sudah cukup dekat. Bagi infrastruktur kami sendiri, itu sangat salah.

• Perkhidmatan edge yang menghidangkan aplikasi terbitan dan pratonton menghubungi API dari beberapa alamat keluar yang dikongsi. Setiap pelawat kepada setiap aplikasi terbitan, dan setiap semakan pratonton, tiba kelihatan seperti datang dari salah satu daripada beberapa alamat itu.
• Orkestra, iaitu perkhidmatan yang menjalankan giliran ejen, menghubungi API dari satu alamat kontena. Setiap giliran yang sedang berjalan, untuk setiap pengguna, berkongsi alamat itu.

Jadi bajet yang sepatutnya untuk seorang individu sedang dibahagi merentasi semua trafik seluruh perkhidmatan. Perkhidmatan-perkhidmatan itu menghabiskannya bersama-sama, dan pengehad melakukan apa yang disuruhnya: ia menolak mereka.

Pembetulan

Perkhidmatan kami sendiri sudah membuktikan siapa mereka. Setiap panggilan dalaman membawa token dalaman, dan setiap laluan di bawah bahagian dalaman API menyemak token itu sebelum ia melakukan apa-apa.

Pengehad kadar kini menggunakan semakan yang sama. Permintaan yang token-nya sepadan dengan token dalaman berada dalam senarai benar dan tidak dikira terhadap bajet setiap alamat. Yang lain dikira tepat seperti sebelumnya: 300 permintaan seminit setiap alamat.

Dua butiran menghalang ini daripada menjadi lubang keselamatan:

1. Token yang salah tidak mendapat pengecualian. Senarai benar hanya sepadan dengan token dalaman yang sebenar. Permintaan dengan token palsu dikira dan dihadkan seperti yang lain, dan laluan dalaman tetap menolaknya dengan 401 Unauthorized.
2. Had itu sendiri tidak berubah. Kami tidak menaikkan nombornya untuk memberi ruang. Menaikkannya akan menyembunyikan masalah sehingga trafik bertambah semula, dan ia akan melemahkan perlindungan untuk kes yang had itu wujud untuknya.

Kami memindahkan tetapan pengehad ke dalam satu fungsi kecil dan menulis ujian terhadapnya. Satu menghantar 20 permintaan dengan token dalaman kepada pengehad yang ditetapkan untuk membenarkan 5, dan menjangka kesemua 20 berjaya. Satu lagi menghantar permintaan biasa dari satu alamat dan menjangka lima yang pertama berjaya dan yang selepas itu ditolak. Yang ketiga menghantar permintaan dengan token palsu dan menjangka ia ditolak dengan cara yang sama.

Apa yang kami pelajari daripadanya

• Had membawa andaian. "Satu alamat, satu pemanggil" dibina dalam had kadar setiap alamat. Ia berhenti benar sebaik sahaja perkhidmatan anda sendiri berada di belakang alamat yang dikongsi, dan banyak yang berada di situ: pengimbang beban, rangkaian edge, kontena, rangkaian pejabat.
• Bezakan trafik anda sendiri mengikut identiti, bukan alamat. Alamat ialah cara trafik tiba, bukan siapa yang menghantarnya. Kami sudah mempunyai kelayakan yang membuktikan panggilan itu milik kami; pengehad hanya tidak memeriksanya.
• Jangan membetulkannya dengan menaikkan nombor. Had yang lebih besar akan menghilangkan 429 buat sementara, melindungi kurang, dan gagal semula kemudian.
• Lihat siapa yang dihadkan. 429 yang jatuh ke atas perkhidmatan anda sendiri ialah laporan pepijat tentang had anda, bukan tanda pengehad berfungsi.

Apa maksudnya jika anda membina di Mythex

Tiada apa yang perlu anda ubah. Aplikasi terbitan pada domain tersuai, giliran ejen dan pratonton tidak lagi bergantung kepada betapa sibuknya bahagian lain Mythex. Trafik aplikasi anda sendiri ialah urusan aplikasi anda: had yang diterangkan di sini ialah pada API kami, bukan pada aplikasi yang anda terbitkan.

Jika anda menjalankan bahagian belakang sendiri, perangkap yang sama terpakai kepada mana-mana had kadar yang anda tambahkan. Panduan kami tentang apakah API dan senarai semak keselamatan untuk aplikasi yang dibina dengan AI ialah tempat yang baik untuk bermula. Dan untuk satu lagi contoh infrastruktur kami sendiri yang menghalang dirinya sendiri, lihat bagaimana kami mencapai penerbitan dengan sifar ralat 502.