Rate Limiter Redis Çökmesi
Rate limiter'ımız durumunu Redis'te saklıyordu. Redis düştü. Rate limiting durdu. Sessizce emdiği kötü niyetli trafik ise durmadı.
Zaman çizelgesi:
- 14:00 - Redis master bakım için kapatıldı; failover beklendiği gibi devreye girmedi
- 14:01 - Rate limiter durumu okuyup yazamadı; fail-open: tüm isteklere izin verildi
- 14:02 - Limiter'ın elediği scraper ve bot trafiği — meşru yükümüzün birkaç katı — API'ye kısıtlamasız vurdu
- 14:03 - API sunucuları doydu
- 14:05 - Tam kesinti
Tasarım kusuru:
Bunu ikili bir seçim olarak çerçeveledik: “fail-open” (her şeye izin ver) ya da “fail-closed” (her şeyi engelle). Fail-open'ı seçtik ve orta seçeneği — daha kaba yerel durumla da olsa limitlemeye devam etmeyi — hiç tasarlamadık.
Bu seçimi neden yaptık:
“Redis sorunlarının meşru kullanıcıları engellemesini istemiyoruz.” Makul — tam fail-closed her Redis takılmasını kendi elimizle yarattığımız topyekûn bir kesintiye çevirirdi. Ama tamamen açık kalmak diğer uçtu.
Ne yapmalıydık:
- Instance başına bellek içi yedek rate limiter
- Paylaşımlı depo erişilemezken muhafazakâr limitler — hiç uygulamamak değil, düşük modda uygulamak
- Otomatik failover'lı Redis replikasyonu, ihtiyaç duyulmadan önce test edilmiş
- Birden fazla katmanda rate limiting (CDN, API Gateway, uygulama), böylece hiçbir depo tek başına yük taşımaz
Her kontrolün bağımlılıkları öldüğünde nasıl davrandığını adım adım incelemek SecOps incelemelerimizin temel bir parçasıdır — çoğu ekip bu soruyu bir olay yanıtlayana kadar hiç sormamıştır.
Ders: Tamamen açık düşen bir rate limiter kontrol değildir; tamamen kapalı düşen ise kesinti üreticisidir. Düşük modu tasarlayın: yerel durum, muhafazakâr limitler, birden fazla katman.
Bu tür olaylar önlenebilir. AWS Yönetilen Hizmetler ekibimiz müşteri ortamlarını yapay zekâ destekli izleme ve nöbetteki kıdemli mühendislerle 7/24 gözetir — böylece bu tür hikâyeler arşivde kalır.