Bant genişliği sınırsız bırakıldığında, tek tenant veya tek yoğun akış tüm servisi etkileyebilir.
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.
Yaklaşımımız
TR7, bant genişliği kontrolünü vService, trafik anahtarı ve yüksek erişilebilirlik paylaşımı üzerinden üç modlu bir politika olarak uygular.
vService başına upload ve download tavanı uygulanır
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 modu her bağlantıya ayrı limit verir
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 modu kullanıcı, IP veya tenant bazlı kota uygular
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 mod küme genelinde ortak kapasite bütçesi sağlar
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.
Yetenekler
Trafik şekillendirme, bağlantı bazlı, anahtar bazlı ve paylaşımlı bant genişliği limitlerini vService politikası haline getirir.
Üç limit modu farklı kapasite kontrol senaryolarını karşılar
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.
CPU ve bellek servis başına tahsis edilir, kiracı başına değil
Yayımlanan her servise kendi çekirdekleri, kendi CPU önceliği ve kendi bellek tavanı verilir. Bir uygulamadaki trafik yükselişi ya da bir diğerindeki ağır WAF politikası o uygulamanın içinde kalır; geri kalanını aç bırakamaz. Kaynak yalıtımının servis düzeyinde olması, yoğun konsolidasyonu güvenli kılan şeydir: tek cihazdaki yirmi uygulama, yirmi cihaz gibi davranır — yirmi cihaz olmadan.
Upload ve download limitleri birbirinden bağımsız tanımlanabilir
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.
FX key builder tenant ve kullanıcı bazlı limit üretir
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 tablo yüksek sayıda kullanıcı veya tenant'ı izleyebilir
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.
Shared mod yüksek erişilebilirlik çiftinde toplam limiti korur
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.
Koşullu uygulama premium ve standart trafiği ayırır
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.
vService ve pool içinde birden fazla limit kuralı tanımlanabilir
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.
Uzun süreli akışlarda bağlantı bazlı tavan uygulanır
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.
Limit değişiklikleri servis kesintisi oluşturmadan uygulanabilir
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.
Monitoring ile hangi anahtarın limiti kullandığı görülebilir
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.
DDoS azaltmada şüpheli trafiğe hız tavanı uygulanabilir
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.
Connection-level flow control olarak net ve öngörülebilir çalışır
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.
Operasyonel derinlik
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.
Limit modu seçimi
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.
Anahtar tasarımı
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 ayrımı
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.
Uzun bağlantılar
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.
Küme paylaşımı
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.
Audit ve alarm
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.
Hangi senaryolarda kullanılır
SaaS tenant'ları için bant genişliği kotası uygulama
Ç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 ve ücretsiz paketlerde farklı hız sunma
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.
Medya akışında kalite seviyesine göre hız sınırı
Video veya medya servislerinde farklı kalite seviyeleri farklı bant genişliği gerektirir. TR7, path veya kullanıcı paketine göre download tavanı uygulayabilir.
Şüpheli trafiği bloklamak yerine yavaşlatma
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.
İç trafik ve dış trafik için farklı kapasite politikası
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.
Kampanya saatlerinde belirli endpoint'leri throttle etme
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.
Sık sorulanlar
Stream, per-key ve shared modu arasında nasıl seçim yapılır?
Upload ve download limitleri ayrı ayrı tanımlanabilir mi?
Per-key modda anahtar nasıl oluşturulur ve kaç anahtar izlenebilir?
Shared mod yüksek erişilebilirlik yapısında nasıl çalışır?
Bu özellik Linux tc veya donanım QoS sistemleriyle aynı mı?
Limit aşıldığında ne olur ve bu olaylar izlenebilir mi?
Trafik kapasitesini vService ve tenant bazında kontrol edin
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.