Performans ve Güvenlik Orantısı: Kaynak Limitleri, Rate Limit ve Throttling Stratejisi

Resource exhaustion; sistemi “hacklemekten” çok, kaynaklarını tüketerek erişilemez hale getirmeyi hedefler. Bazen saldırı değildir; kötü yazılmış bir sorgu, rapor/export gibi ağır işlem veya yanlış konfigürasyon da aynı etkiyi doğurur. Ortak payda: CPU/RAM/connection/worker gibi kaynakların kontrolsüz tüketilmesi.

Bu modeli web ve yazılım altyapısında kaynak limitleme güvenliği olarak okumak; endpoint korumasını kapasite, kullanıcı deneyimi ve güvenlik gereksinimleriyle birlikte tasarlamayı sağlar.

Kaynak sömürme saldırıları (resource exhaustion) nedir, nasıl önlenir?

Resource exhaustion; çok sayıda istek veya ağır işlemlerle CPU/RAM/connection gibi kaynakları tüketip hizmeti yavaşlatma/çökertme durumudur. Önleme; katmanlı limit koymak (OS/web/app), kritik endpoint’lerde rate limit ve throttling uygulamak, ağır işleri kuyruklamak ve limit aşımlarında kontrollü “graceful degradation” ile yanıt vermektir.

Neden “limit” güvenlik kontrolüdür?

Limitler; saldırganın “sonsuz deneme” ve “sonsuz kaynak tüketimi” imkânını kısar. Aynı zamanda gerçek kullanıcıların trafik dalgalanmasında tamamen kaybolmasını engeller. Sheet’teki veri noktasıyla uyumlu olarak; limit stratejisi oturan projelerde ani artışlar kesintiye dönüşmeden kontrollü yavaşlama ile yönetilebilir.

Özellikle resource exhaustion saldırısı nedir sorusu WAF, bot filtreleri ve edge korumayla birlikte ele alındığında; hangi isteğin bloklanacağı ve hangi akışın korunacağı daha net tanımlanır.

☑ Mini Check: Resource exhaustion sinyalleri

• •CPU/RAM spike aniden mi yükseliyor?
• •Connection sayısı tavan yapıyor mu?
• •Belirli endpoint’ler (login/search/export) yoğunlaşıyor mu?
• •5xx artışı p95 latency ile birlikte mi yükseliyor?
• •429/limit tetikleri hiç yok mu (yani limit yok mu)?

Burada amaç; sistemi “sonsuz kaynak” gibi davranmaktan çıkarıp kontrollü bir kapasite modeline sokmaktır. Limit yoksa bir kullanıcı veya bir endpoint tüm kaynakları tüketebilir. Limit varsa sistem “öncelik” belirleyebilir.

CPU/RAM ve connection limitlerini nasıl ayarlamalıyım?

Önce kritik iş akışları için (login/booking/search, rapor/export) normal kullanım desenini ölçün; p95/p99 ve peak değerleri çıkarın. Sonra OS ve uygulama seviyesinde makul sınırlar koyup, aşımlarda 429/503 gibi kontrollü yanıt ve backoff stratejisi uygulayın. Hedef; “tam çöküş” yerine “kısa süreli kontrollü yavaşlama”dır.

Bu kapasite fotoğrafı çıkarılmadan açık endpoint ve zafiyet kontrolü yapılmazsa, güncel olmayan servisler veya verimsiz uçlar kaynak baskısını gereksiz büyütebilir.

Connection limitleri (TCP ve web server)

• •Aynı anda kabul edilecek bağlantı sayısı
• •Keep-alive dengesi (çok yüksekse kaynak tüketir)
• •Slow client ve benzeri durumlarda zaman aşımı politikaları

Worker/thread/queue limitleri (uygulama tarafı)

• •Worker sayısı ve iş kuyruğu sınırı
• •Ağır işlerin ayrı işçi havuzuna alınması (export/rapor)
• •DB bağlantı havuzu (pool) ve maksimum eşzamanlı sorgu

“Kritik akışlar” için önceliklendirme

Otel: booking/search akışını korumak; rapor/analytics işleri gerektiğinde yavaşlatmak.

B2B: portal login ve kritik işlemler öncelik; büyük export işleri kuyrukta.

☑ Mini Check: Kaynak limit seti

• •Web server connection/timeouts tanımlı
• •Worker/thread sayısı ve queue kapasitesi tanımlı
• •DB connection pool limitleri var
• •Ağır işler ayrı kuyruk/pool’da
• •Peak anında kritik akışlar korunuyor

Rate limit “kaç istek?” sorusunu sınırlar; throttling ise “yük altında nasıl yavaşlatırım?” sorusunu yönetir. İkisi farklıdır: rate limit genelde 429 ile keser; throttling daha kontrollü bir QoS uygular (kuyruğa alma, geciktirme, degrade).

Rate limit ve throttling stratejisi nasıl kurgulanır?

Önce endpoint’leri sınıflandırın: kritik (login/booking/search), ağır (rapor/export), düşük risk (statik içerik). Sonra kimlik bazlarını seçin: IP, kullanıcı, token, tenant. Kritik endpoint’lerde daha sıkı rate limit; ağır endpoint’lerde kuyruk + throttling; aşımda ise net mesaj ve backoff ile kullanıcı deneyimini yönetin. Tüm kuralları log/izleme ile iteratif ayarlayın.

Endpoint bazlı strateji (otel + B2B örnekleri)

• •/login: brute-force ve abuse’a karşı sıkı limit
• •/booking: kritik gelir akışı; limit var ama “kibar” davranış (graceful)
• •/search: bot taramasına açık; hız sınırı + cache + davranış kontrolü
• •/report/export: en ağır; kuyruk + job id + asenkron çıktı (mümkünse)

Graceful degradation (kullanıcı deneyimi)

Limit aşımlarında iki hatalı uç var:

• •Sert kesmek (her şeyi 429/500) → iş kaybı
• •Hiç kesmemek → sistem çöker

Aradaki doğru yaklaşım:

• •Kritik akışı koru (booking/login)
• •Ağır işleri geciktir/kuyruğa al (export)
• •Net hata mesajı + retry-after/backoff

☑ Mini Check: Rate limit tasarımı

• •Endpoint’ler kritik/ağır/normal sınıflandı
• •Kimlik bazları seçildi (IP/kullanıcı/token)
• •Login için sıkı limit + lockout stratejisi var
• •Export işleri kuyruklanıyor (asenkron)
• •429/503 mesajları kullanıcıya yön gösteriyor

Bu bölüm “örnek değer” bekleyen ekipler için çerçeve verir; ancak değerler altyapıya göre değişir. Burada amaç sayı ezberi değil; profil mantığıdır: kritik akış = koru, ağır iş = kuyrukla, riskli uç = sıkı sınırla.

Otel — booking/search akışları

• •Search: cache + kısa süreli limit (botları kes)
• •Booking: daha tolerant limit + WAF/CDN ile koruma
• •Login: sıkı limit + anomali alarmı

B2B — rapor/export istekleri

• •Export: asenkron job, kişi/token bazlı limit, queue kapasitesi
• •Rapor: sayfalama, maksimum aralık, “bir seferde çok veri” engeli
• •API: tenant bazlı QoS (enterprise müşteriye farklı profil olabilir)

Otel/B2B için login/booking/search ve rapor/export istekleri için örnek limitler neler?

Örnek yaklaşım; login’de sıkı IP/kullanıcı limitleri, search’te kısa pencereli hız sınırı ve cache, booking’de daha toleranslı ama abuse’ı yakalayan kurallar, export’ta ise asenkron kuyruk + token bazlı limit ve maksimum eşzamanlı job sınırıdır. Değerler, gerçek kullanım loglarından türetilip iteratif ayarlanmalıdır.

Turizm projelerinde otel rezervasyon arama endpoint limitleri özellikle müsaitlik, fiyat sorgusu ve rezervasyon akışında kritiktir; yanlış eşikler gerçek talebi de bot trafiği gibi bastırabilir.

☑ Mini Check: Profil bazlı limit

• •Her endpoint için profil belirlendi
• •Booking/login korunuyor, export kontrol altında
• •Queue kapasitesi ve worker limiti tanımlı
• •Tenant/kullanıcı bazlı QoS var
• •Limit ihlali kullanıcı deneyimi tasarlandı (graceful)

Limit koymak tek başına yetmez; yanlış limit “gizli kesinti” üretir. Bu yüzden izleme; performans+güvenlik stratejisinin son halkasıdır.

Hangi metrikler izlenmeli?

• •429/403/503 oranı (limit ve koruma etkisi)
• •p95/p99 latency, 5xx oranı
• •CPU/RAM, connection, queue depth
• •Endpoint bazlı istek yoğunluğu (login/search/export)

Bu alarm seti, kaynak tüketimi alarmı ve incident yönetimi ile birleştiğinde kapasite sorunu, saldırı dalgası ve yanlış eşik kaynaklı olaylar daha hızlı ayrıştırılabilir.

Alarm stratejisi (az ama etkili)

• •429 patlaması: abuse veya yanlış eşik
• •Queue depth tavan: export/worker kapasite sorunu
• •p95↑ + 5xx↑: overload/kaynak tükenmesi

Bu sinyaller, raporlama panellerine bağlanmalı. Özellikle limitlerin satış ve dönüşüm akışına etkisi rezervasyon, ödeme ve form uçlarında yanlış eşiklerin gelir kaybı üretip üretmediğini gösterir; throttle edilen isteklerin raporlanması ise endpoint yükü, 429/503 trendleri ve queue davranışını operasyon dashboard’una taşır.

☑ Mini Check: İzleme doğrulaması

• •429/503 trendleri dashboard’da
• •Queue depth ve worker tüketimi izleniyor
• •Endpoint bazlı metrikler var
• •Alarm eşikleri runbook’a bağlı
• •Limitler periyodik gözden geçiriliyor (180 gün)

Bu modeli canlı altyapınıza uyarlamak için Sunucu ve Güvenlik hizmetiyle kaynak limitleme güvenliği kurun; uygulama öncesi temel sorular için de Sunucu ve Güvenlik hakkında sık sorulan sorular sayfasına göz atabilirsiniz.