Modern uygulamalarda kapasite problemi yalnız istek sayısıyla ölçülmez. Büyük dosya indirme, video akışı, API export, yedekleme trafiği veya bot kaynaklı yoğun veri çekimi, düşük istek adediyle bile yüksek bant genişliği tüketebilir. Bu durumda request rate limit tek başına yeterli olmaz.
Multi-tenant ortamlarda sorun daha görünür hale gelir. Bir tenant yoğun veri aktarımı yaparken diğer tenant'ların gecikmesi artabilir. Aynı vService'i paylaşan müşteriler arasında kapasite sınırı yoksa adil kullanım politikası teknik olarak uygulanamaz.
Geleneksel trafik şekillendirme çoğu zaman ağ seviyesinde karmaşık kuyruk ve sınıf yapıları gerektirir. Bu model güçlüdür; fakat uygulama teslim katmanında path, tenant, kullanıcı, JWT claim veya kaynak IP gibi L7 sinyallerle doğrudan çalışması zordur. Operasyon ekibi için debug ve değişiklik yönetimi de ağırlaşır.
Doğru yaklaşım, ADC seviyesinde bağlantı ve anahtar bazlı bant genişliği tavanı uygulamaktır. vService, kullanıcı, tenant veya riskli trafik grubu için farklı limitler tanımlanabilmeli; upload ve download yönleri ayrı yönetilebilmelidir.
TR7 vService Bazlı Trafik Şekillendirme ve QoS, stream, per-key ve shared modlarıyla bant genişliği kullanımını uygulama teslim katmanında kontrol eder.
TR7, bant genişliği kontrolünü vService, trafik anahtarı ve yüksek erişilebilirlik paylaşımı üzerinden üç modlu bir politika olarak uygular.
Her vService için istemciden kuruma giden ve kurum servisinden istemciye dönen trafik ayrı sınırlandırılabilir. Bu, uygulama kapasitesinin servis bazında kontrol edilmesini sağlar.
Stream modunda her bağlantı kendi bant genişliği tavanıyla çalışır. Uzun süren indirme, upload veya WebSocket benzeri akışlarda tek bağlantının kaynak tüketimi sınırlandırılabilir.
Per-key modunda limit, FX ifadesiyle üretilen anahtara göre uygulanır. Kaynak IP, kullanıcı, tenant ID veya JWT claim gibi değerler bant genişliği anahtarı olabilir.
Shared modda iki düğümlü yapılarda bant genişliği bütçesi tek cihazla sınırlı kalmaz. Aynı tenant veya servis için toplam limit küme düzeyinde daha tutarlı uygulanabilir.
Trafik şekillendirme, bağlantı bazlı, anahtar bazlı ve paylaşımlı bant genişliği limitlerini vService politikası haline getirir.
Stream modu her bağlantıya ayrı sınır uygular. Per-key modu IP, kullanıcı, tenant veya başka bir FX anahtarı üzerinden ortak limit uygular. Shared mod ise yüksek erişilebilirlik yapısında aynı limitin düğümler arasında paylaşılmasına yardımcı olur. Böylece tek bir özellik altında basit bağlantı limiti, tenant kotası ve küme genelinde ortak kapasite yönetimi kurulabilir.
Bazı servislerde indirme trafiği ağırdır, bazılarında upload kritik kapasite tüketir. TR7, istemciden kuruma giden upload yönü ile kurum servisinden istemciye dönen download yönünü ayrı ayrı sınırlandırabilir. Örneğin dosya yükleme servisinde upload, video servisinde download daha sıkı kontrol edilebilir. Bu ayrım bant genişliği politikasını gerçek trafik davranışına yaklaştırır.
Per-key modunda bant genişliği anahtarı FX ifade motoruyla oluşturulur. Kaynak IP, JWT kullanıcı bilgisi, tenant ID, header değeri veya bunların birleşimi anahtar olarak kullanılabilir. Örneğin aynı tenant'a ait tüm kullanıcılar ortak kapasite tavanını paylaşabilir. Bu, multi-tenant SaaS modellerinde adil kullanım için güçlü bir mekanizmadır.
Per-key modda her anahtar ayrı kullanım durumu olarak takip edilir. Sessiz kalan anahtarlar belirli süre sonra temizlenir; aktif olanlar limit politikasına tabi tutulur. Bu model, binlerce kullanıcı veya tenant için merkezi kapasite kontrolü sağlar. Operatör tek tek bağlantı yerine mantıksal trafik sahibi üzerinden limit uygular.
Aktif-aktif veya aktif-pasif yapılarda trafik iki düğüm arasında dağılabilir. Shared mod, bant genişliği bütçesinin yalnız tek düğümde değil, ortak servis davranışı olarak uygulanmasına yardımcı olur. Böylece tenant bir düğümden diğerine geçtiğinde limit mantığı bozulmaz. Bu, özellikle kurumsal SLA ve kota senaryolarında önemlidir.
Trafik şekillendirme kuralları koşullu çalışabilir. Örneğin premium tenant limitsiz, free tenant 100 Kbps, şüpheli IP 1 Mbps sınırla çalıştırılabilir. Koşullar path, kullanıcı, header, JWT claim, kaynak IP veya farklı FX ifadeleriyle kurulabilir. Bant genişliği politikası tek global ayar olmaktan çıkar.
Aynı vService içinde farklı trafik dilimleri için farklı limit kuralları kullanılabilir. Örneğin `/download` path'i ayrı, `/api/export` ayrı, normal API çağrıları ayrı limitlenebilir. Bu, kapasite kontrolünü uygulama davranışına göre parçalara ayırır. Operatör tek kaba tavan yerine bağlama duyarlı shaping uygular.
WebSocket, büyük dosya indirme veya uzun süreli streaming bağlantıları klasik istek bazlı limitleri aşabilir. Stream modu bu tür bağlantılarda her akışa bant genişliği tavanı uygular. Tek uzun bağlantının servis kapasitesini tüketmesi engellenir. Bu model medya, dosya transferi ve gerçek zamanlı akış senaryolarında önemlidir.
Bant genişliği limitleri konfigürasyon değişikliğiyle güncellenebilir. Yeni limitler üretim trafiğine kontrollü şekilde uygulanır. Bu, kampanya, DDoS şüphesi, tenant kotası değişikliği veya geçici kapasite kısıtlaması sırasında hızlı müdahale sağlar. Operasyon ekibi ayrı ağ cihazı değişikliği beklemez.
Per-key modda her kullanıcı, IP veya tenant için kullanım durumu izlenebilir. Operatör hangi anahtarın kota tavanına dayandığını görebilir. Bu bilgi müşteri destek, güvenlik analizi ve kapasite planlama için değerlidir. Limit aşımı olayları log ve SIEM akışına bağlanabilir.
Her şüpheli trafik doğrudan bloklanmak zorunda değildir. TR7, riskli IP, ASN, path veya davranış grubuna düşük bant genişliği limiti uygulayabilir. Böylece saldırı etkisi azaltılırken false-positive durumunda gerçek kullanıcının tamamen kesilmesi önlenebilir. Bu, aşamalı savunma modeline uygundur.
Bu özellik ağ seviyesinde karmaşık kuyruk veya donanım QoS sistemi değildir. TR7, bağlantı ve akış düzeyinde bant genişliği tavanı uygular. Bu sınırlandırma vService, anahtar ve koşul seviyesinde kolay yönetilir. Operatör hangi servis veya kullanıcının ne kadar kapasite alacağını açık şekilde tanımlar.
Trafik şekillendirme; limit modu, anahtar seçimi, upload/download yönü, uzun akışlar, küme paylaşımı ve audit görünürlüğüyle birlikte planlanmalıdır.
Stream modu bağlantı bazlı, per-key modu kullanıcı veya tenant bazlı, shared mod ise küme genelinde ortak limit için uygundur. Yanlış mod seçimi beklenen kapasite davranışını bozabilir. Politika hedefi önce netleştirilmelidir.
Per-key modda kullanılan anahtar limitin gerçek sahibini belirler. Kaynak IP bazı ortamlarda yeterlidir; tenant veya kullanıcı bilgisi daha doğru kota modeli sağlayabilir. NAT arkasındaki çoklu kullanıcılar için IP tek başına adil olmayabilir.
Upload ve download yönleri farklı kaynak etkisine sahiptir. Büyük dosya yükleme kurum servisi giriş kapasitesini, indirme ise çıkış kapasitesini tüketir. Bu iki yön ayrı limitlenmelidir.
WebSocket, stream ve büyük dosya transferleri uzun süre açık kalabilir. Bu tür akışlarda bağlantı bazlı limitler kaynak kullanımını daha öngörülebilir hale getirir. Timeout ve bant genişliği limitleri birlikte değerlendirilmelidir.
Shared mod, iki düğümlü yapılarda ortak bütçe davranışı için kullanılabilir. Düğümler arası trafik dağılımı değiştiğinde limit politikasının aynı kalması hedeflenir. Kritik tenant SLA'larında bu davranış önemlidir.
Limit eşiğine ulaşan anahtarlar loglanabilir. SIEM tarafında tenant, kullanıcı veya IP bazlı kota aşımı alarmı üretilebilir. Bu bilgi hem güvenlik hem müşteri destek operasyonlarında kullanılabilir.
Çok kiracılı SaaS ortamında her tenant için ayrı kapasite tavanı tanımlanabilir. Tenant ID anahtar olarak kullanılır ve aynı tenant'a ait tüm kullanıcılar ortak limiti paylaşır.
Premium müşterilere daha yüksek, ücretsiz kullanıcılara daha düşük bant genişliği limiti verilebilir. Paket farkı uygulama koduna yazılmadan ADC politikasında yönetilir.
Video veya medya servislerinde farklı kalite seviyeleri farklı bant genişliği gerektirir. TR7, path veya kullanıcı paketine göre download tavanı uygulayabilir.
DDoS veya bot şüphesinde trafik tamamen kesilmeden düşük hız limitine alınabilir. Böylece saldırı etkisi düşer, gerçek kullanıcı false-positive durumunda tamamen kopmaz.
Internal API çağrıları limitsiz bırakılırken internetten gelen trafik sınırlandırılabilir. Kaynak IP, path veya header koşullarıyla bu ayrım merkezi olarak yapılır.
E-ticaret kampanyalarında belirli endpoint'ler ani trafik çekebilir. TR7, checkout veya kampanya API'leri için geçici bant genişliği tavanı uygulayarak servis kararlılığını korur.
Bant genişliği yönetimini ADC üzerine taşıyın; ayrı ağ cihazı veya karmaşık kuyruk yapıları olmadan stream, per-key ve shared modlarıyla kapasite politikası kurun.