Aylık fatura geldi ve trafik rakamı önceki aya göre iki katına çıkmış, ama siz hiçbir yeni servis devreye almadınız. Ya da daha kötüsü: bulut sunucudaki site aniden yavaşladı ve panelde çıkış trafiği limite dayanmış. Bu iki durumun neredeyse her zaman tek bir kök nedeni vardır: kimse "bulut sunucu trafiğinin" tam olarak nereden sayıldığını ve hangi byte'ların hesaba katıldığını bilmiyor.
Her şeyden önce şunu bilmelisiniz ki bulut altyapısında trafik tek bir sayı değildir. Her biri faturada ve ağ davranışında kendi yerine sahip en az dört ayrı sayı vardır.
Giriş ve çıkış trafiği; hangisi sayılır
Neredeyse her yerde sabit olan kural: giriş trafiği (ingress) ücretsizdir ve çıkış trafiği (egress) sayılır. Yani internetten sunucunuza gelen her byte mali açıdan değersizdir; sunucunuzdan internete giden her byte ise maliyetlidir.
Bu tanım basittir, ancak en çok kafa karışıklığına yol açan iki istisnası vardır:
- Aynı özel ağdaki sunucular arasındaki trafik genellikle sayılmaz. Veritabanı ve web sunucusu bir özel ağ üzerinden konuşursa, o gigabaytlar hesabınızdan düşülmez. Aynı iletişim genel IP üzerinden geçerse tamamen sayılır. Bu ikisinin arasındaki fark pratikte ayda birkaç yüz gigabayt olabilir.
- Veri merkezleri arasındaki veya bölgeler (regions) arasındaki trafik neredeyse her zaman sayılır, her iki sunucu da sizin olsa bile.
O halde yapmanız gereken ilk şey, mimarinizde hangi yolun genel IP üzerinden geçtiğini anlamaktır. Basit bir traceroute bunu ortaya çıkarır:
traceroute -n db.internal.example.com
# İlk hop 10.x.x.x ise yol özeldir
# Genel IP üzerinden geçtiyse o trafik sayılırBulut sunucu trafiği nasıl ölçülür
Panelde gördüğünüz trafik rakamı, uygulamanızın loglarından değil, hipervizördeki ağ kartı sayaçlarından gelir. Bu şu anlama gelir: birkaç şeyi asla görmezsiniz: loopback trafiği, aynı makine içindeki trafik ve ağ kartına ulaşmadan önce drop edilen paketler.
Daha da önemlisi, sayım katman 3'te yapılır, katman 7'de değil. 800 byte'lık header'lar ve 200 byte'lık gövde ile bir HTTP isteği gönderirseniz, sayılan rakam yaklaşık 1000 byte'tır, 200 byte değil. Büyük header'larla küçük yanıtlar veren API'ler için bu fark üç katına kadar çıkabilir.
Gerçek rakamı sunucunun içinden görmek için, vnstat ek agent olmadan çalışan en kesin seçenektir:
vnstat -m # arayüze göre aylık tüketim
vnstat -i eth0 -h # son 24 saatin saatlik raporu
cat /proc/net/dev # ham kernel sayacı, sıfırlanmazvnstat rakamı panel rakamıyla çok farklıysa, muhtemelen trafik başka bir arayüzden geçiyordur veya trafiğin bir kısmı makinenize ulaşmadan ağ katmanında filtrelenmiştir. Tam resmi görmek için bu sayaçları bulut izleme ve otomatik uyarılarla birleştirmek gerekir; uyarı olmadan trafik artışını fark ettiğiniz ilk an fatura günüdür.
Limit aşıldıktan sonra ne olur
İşte burada sağlayıcıların davranışı gerçekten farklılaşır ve seçim yapmadan önce hangi modeli satın aldığınızı bilmelisiniz. Üç yaygın model vardır:
| Model | Limit aşıldıktan sonraki davranış | Gördüğünüz işaret |
|---|---|---|
| Katı | Bant genişliği bir sonraki ayın başına kadar birkaç megabite sınırlanır | Site açılır ama TTFB 200ms'den 3 saniyeye çıkar |
| Kullandıkça öde | Servis normal çalışır, faturaya ek tutar yansır | Hiçbir yavaşlama hissetmezsiniz, sadece fatura ağırlaşır |
| Karma | İlk limite kadar ücretsiz, sonrasında kademeli azalan oran | Maliyet artar ama doğrusal değil |
İlk model göründüğünden daha tehlikelidir, çünkü throttle genellikle tüm arayüze uygulanır, sadece web trafiğine değil. Yani SSH'ınız da yavaşlar ve gece yedeklemesi aynı arayüzden geçerse yarıda kalabilir. Trafiği öngörülemez olan bir sunucuda çalışıyorsanız, kullandıkça öde modelini seçin; daha pahalı görünür ama servis kesintisini satın almazsınız.
İşinize yarayacak gerçek bir rakam: ayda 50 bin görüntüleme ve 1,5 megabaytlık sayfalara sahip sıradan bir web sunucusu, yaklaşık 75 gigabayt çıkış üretir. Aynı site görselleri sıkıştırmadan sunarsa, bu rakam 300 gigabayta ulaşır. Fark, sadece bir ayardır.
Ek IP; gerçekten ne zaman gerekli
Her bulut sunucu bir genel IP ile gelir. Ek IP üç senaryoda anlamlıdır ve geri kalan durumlarda sadece maliyet ve karmaşıklıktır:
- Servisleri 443 portunda ayırmak. İki ayrı SSL sertifikasına sahip iki siteniz varsa ve SNI'ı devreye sokmak istemiyorsanız, ikinci IP eski ve güvenilir çözümdür. Elbette bugün SNI tüm gerçek tarayıcılarda çalışır ve bu gerekçe zayıflamıştır.
- Dış servisler için sabit çıkış. Banka API'niz veya ödeme geçidiniz kaynak IP'yi whitelist'e alıyorsa, sabit çıkış IP'si zorunludur. Bu, gerçekten ek IP'den başka çareniz olmayan tek durumdur.
- Yönetim trafiğini servis trafiğinden ayırmak. SSH ve panel bir IP'de, kullanıcı trafiği başka bir IP'de. Bu hem güvenliği iyileştirir hem de trafik analizini kolaylaştırır.
Az görülen bir nokta: ek IP aynı arayüze bind edilir, dolayısıyla bant genişliği limitini yükseltmez. Sorununuz bant genişliği yetersizliğiyse, ikinci IP hiçbir yardım sağlamaz. Bunun için dağıtık mimariye yönelmelisiniz.
Burada hata yapıyorlar
Ticket'larda gördüğüm en yaygın hata şudur: biri trafik tüketimini azaltmak için CDN'i ana alan adında etkinleştirir ama DNS kaydını A'dan CNAME'e değiştirmez. Sonuç şudur: CDN hiçbir trafik almaz, tüm istekler doğrudan sunucuya gelir ve tüketim tam olarak aynı kalır. İşareti de şudur: CDN panelinde hit ratio neredeyse sıfırdır ama sunucu trafiği değişmemiştir.
İkinci ve daha pahalı hata: biri trafiği Nginx loglarından sayar ve panel rakamına güvenmez. Nginx logu yalnızca yanıt gövdesini sayar; header'ları, TLS handshake'ini ve retransmit paketlerini görmez. Bu iki rakam arasındaki %15 ila %25 fark normaldir, hesaplamada hata olduğunun işareti değildir.
Üçüncü hata yedeklemeyle ilgilidir. Yedekleri aynı ağdaki başka bir sunucuya ama genel yoldan gönderiyorsanız, her gece birkaç on gigabayt çıkış trafiği yakıyorsunuz. Yedekleri sunucular arası özel ağ üzerinden aktarmak bu maliyeti tamamen ortadan kaldırır ve genellikle daha hızlıdır da.
Mimariye dokunmadan tüketimi azaltmak
Büyük bir değişiklikten önce şu üç şeyi yapın. Birincisi, Nginx'te sıkıştırmayı açın; metin ve JSON için genellikle %70 azalma sağlar:
gzip on;
gzip_types application/json text/css application/javascript;
gzip_min_length 1024;İkincisi, görselleri WebP'ye dönüştürün. Üçüncüsü, statik dosyalar için tarayıcı önbelleğini uzun bir aralığa ayarlayın ki her ziyaretçi bunları yeniden çekmesin. Bu üç madde pratikte çıkış trafiğini %40 ila %60 azaltır ve uygulama kodunda hiçbir değişiklik gerektirmez.
Bunlardan sonra tüketim hâlâ yüksekse, sorun ayarlarda değil mimaridedir. O durumda statik dosyaların uçtan sunulması için içerik dağıtım ağına yönelin ve video veya yedek gibi büyük dosyalar için nesne depolama sunucu diskinden daha doğru seçimdir; çünkü onun çıkış trafiği ayrı hesaplanır ve hangi dosyanın ne kadar tükettiğini tam olarak görebilirsiniz.
ServerNet bulut altyapısında çalışıyorsanız, trafik sayaçları aynı panelde ve arayüze göre ayrılmış olarak görünür ve herhangi bir değişiklikten önce bir haftalık baseline alabilirsiniz. Temel rakama sahip olun; o olmadan her optimizasyon bir tahmindir.
Sık sorulan sorular
Bulut sunucu giriş trafiği de hesaplanır mı?
Neredeyse tüm bulut sağlayıcılarında giriş trafiği ücretsizdir ve yalnızca çıkış sayılır. İstisna, trafiğin bölgeler veya veri merkezleri arasında geçtiği durumdur; o da genellikle her iki yönde hesaplanır.
Panel trafik rakamı neden vnstat'tan farklı?
Çünkü panel hipervizör sayacından, vnstat ise makinenin kendi kernelinden okur. %5 ila %15 fark normaldir ve genellikle yönetim paketleri, ARP ve arayüzünüze ulaşmadan önceki trafikten kaynaklanır. %30'dan fazla fark, bir arayüzü veya bir yolu görmediğiniz anlamına gelir.
Bant genişliği limiti bittikten sonra ne olur?
Faturalandırma modeline bağlıdır. Katı modelde bant genişliği sınırlanır ve SSH dahil tüm servisler yavaşlar. Kullandıkça öde modelinde servis normal kalır ve faturaya maliyet eklenir. Satın almadan önce hangi modeli aldığınızı bilmelisiniz.
Ek IP'nin bant genişliği limitine etkisi var mı?
Hayır. Ek IP yalnızca aynı arayüz üzerinde bir adrestir ve bant genişliği limitini değiştirmez. Gerçek kullanımı servisleri ayırmak, whitelist için sabit çıkış sağlamak ve yönetim trafiğini kullanıcı trafiğinden ayırmaktır.