Kendi Servislerimizi Kendimiz Sınırlıyorduk

Mythex'in API'si, tek bir ağ adresinden dakikada 300 isteğe izin verir. Bu sınır, tek bir kişinin ya da betiğin API'yi zorlamasına karşı bizi korumak için vardır. Üretimde ise bu sınır bunun yerine kendi servislerimizi reddetmeye başladı: yayınlanmış uygulamaları sunan kenar katmanımızın bir parçası ve agent'ı çalıştıran servis. Her biri API'ye yalnızca birkaç adresten eriştiği için sınır onları yakalıyordu. İç kimlik bilgimizi taşıyan istekler artık muaf tutuluyor ve diğer herkes tam olarak eskisi gibi sınırlanıyor.

Belirti

API, kendi iç çağrılarımızdan bazılarına 429 Too Many Requests yanıtı vermeye başladı. Üç tür çağrı etkilendi ve her biri Mythex kullanan biri için önemliydi:

Bir özel alan adında hangi uygulamanın bulunduğunu aramak. Bir ziyaretçi yayınlanmış bir uygulamayı kendi alan adında açtığında, kenarımız sitenin nerede olduğunu API'ye sorar. Burada bir 429, siteye ulaşamayan bir ziyaretçi demektir.
Çalışan bir agent turunu kaydetmek. Agent çalışırken ilerlemesi adım adım kaydedilir; böylece bir yanıt sayfa yenilemesinden ya da kopan bir bağlantıdan sağ çıkar. Burada bir 429, kaydedilmeyen bir ilerleme demektir.
Bir önizlemeye erişimi kontrol etmek. Geliştirdiğiniz bir uygulamanın önizlemesi kapılıdır ve bu kapı API'ye sorar. Burada bir 429, açılmayan bir önizleme demektir.

Bunların hiçbiri API'yi çağıran bir kişi değildi. Hepsi bizdik.

Neden oldu?

Adres başına hız sınırı tek bir varsayım yapar: bir adres kabaca bir çağırana karşılık gelir. İnsanlar için bu yeterince yakındır. Kendi altyapımız için ise bu tamamen yanlıştır.

Yayınlanmış uygulamaları ve önizlemeleri sunan kenar servisi, API'ye birkaç paylaşılan giden adresten erişir. Her yayınlanmış uygulamanın her ziyaretçisi ve her önizleme kontrolü, bu birkaç adresten birinden geliyormuş gibi görünür.
Orkestratör (agent turlarını çalıştıran servis), API'ye tek bir konteyner adresinden erişir. Her kullanıcının her çalışan turu bu adresi paylaşır.

Yani tek bir kişi için tasarlanmış bütçe, tüm bir servisin trafiği arasında bölünüyordu. Bu servisler bütçeyi kendi aralarında tüketti ve sınırlayıcı da söyleneni yaptı: onları reddetti.

Düzeltme

Kendi servislerimiz zaten kim olduklarını kanıtlıyor. Her iç çağrı bir iç belirteç taşır ve API'nin iç bölümü altındaki her rota, bir şey yapmadan önce bu belirteci kontrol eder.

Hız sınırlayıcı artık aynı kontrolü kullanıyor. İç belirteçle eşleşen bir istek bir izin listesinde olur ve adres başına bütçeye sayılmaz. Diğer her şey, adres başına dakikada 300 istek olarak tam eskisi gibi sayılır.

İki ayrıntı bunun bir açığa dönüşmesini engelledi:

Yanlış bir belirteç geçiş hakkı kazanmaz. İzin listesi yalnızca gerçek iç belirteçle eşleşir. Uydurulmuş bir belirteçle gelen istek, diğerleri gibi sayılır ve sınırlanır; iç rotalar da onu 401 Unauthorized ile reddeder.
Sınırın kendisi değişmedi. Yer açmak için sayıyı yükseltmedik. Yükseltmek, trafik yeniden artana kadar sorunu gizlerdi ve sınırın var olma nedeni olan durumda korumayı zayıflatırdı.

Sınırlayıcının ayarlarını küçük bir işleve taşıdık ve buna karşı testler yazdık. Biri, 5'e izin verecek şekilde ayarlanmış bir sınırlayıcıya iç belirteçle 20 istek gönderir ve hepsinin başarılı olmasını bekler. Bir diğeri aynı adresten düz istekler gönderir ve ilk beşinin başarılı, sonrakilerin reddedilmesini bekler. Üçüncüsü sahte bir belirteçle istekler gönderir ve bunların aynı şekilde reddedilmesini bekler.

Bundan çıkardıklarımız

Sınırlar varsayımlar taşır. "Bir adres, bir çağırıcı" adres başına bir sınıra gömülüdür. Kendi servisleriniz paylaşılan adreslerin arkasına girdiği anda bu doğru olmaktan çıkar; ve birçok servis öyle: yük dengeleyiciler, kenar ağları, konteynerler, ofis ağları.
Kendi trafiğinizi adrese göre değil, kimliğe göre ayırın. Adresler trafiğin nasıl geldiğidir, kimin gönderdiği değil. Bir çağrının bize ait olduğunu kanıtlayan bir kimlik bilgimiz zaten vardı; sınırlayıcı sadece ona bakmıyordu.
Sayıyı yükselterek düzeltmeyin. Daha büyük bir sınır, 429'ları bir süre ortadan kaldırırdı, daha az koruma sağlardı ve sonra yeniden başarısız olurdu.
Kimin sınırlandığına bakın. Kendi servisinize düşen bir 429, sınırlarınız hakkında bir hata raporudur; sınırlayıcının çalıştığının işareti değildir.

Mythex üzerine kuruyorsanız ne anlama geliyor?

Sizin tarafınızda değiştirilecek bir şey yok. Özel alan adlarındaki yayınlanmış uygulamalar, agent turları ve önizlemeler artık Mythex'in geri kalanının ne kadar meşgul olduğuna bağlı değil. Uygulamanızın kendi trafiği uygulamanızın işidir: burada anlatılan sınır Mythex API'mizde, yayınladığınız uygulamalarda değil.

Kendi arka ucunuzu çalıştırıyorsanız, eklediğiniz her hız sınırında aynı tuzak geçerlidir. Başlamak için API nedir ve yapay zeka ile yapılmış uygulamalar için güvenlik kontrol listesi iyi yerlerdir. Altyapımızın kendi yolunda engel olduğuna dair başka bir örnek için de dağıtımları sıfır 502 hataya nasıl indirdik yazısına bakın.