Yüksek Trafikli Web Siteleri İçin Sunucu Gereksinimleri

“Yüksek trafik” belirsiz bir ifade. Biri için günde 50.000 ziyaretçi, bir başkası için saniyede 2.000 istek demek. Sunucu gereksinimlerini konuşmadan önce bu belirsizliği gidermek gerekiyor, çünkü yanlış birimle yapılan kapasite hesabı, doğru donanımla bile çöken siteler üretiyor.

Bu rehber bir donanım listesinden çok bir hesap yöntemi sunuyor: trafiği ölçülebilir bir yüke nasıl çevireceğinizi, CPU, RAM, disk ve ağın hangi koşulda darboğaza dönüştüğünü, mimariyi ne zaman katmanlara bölmeniz gerektiğini ve kapasitenizi nasıl sınayacağınızı ele alıyoruz.

Yüksek Trafikli Bir Site Hangi Sunucu Özelliklerini Gerektirir?

Tek bir ideal konfigürasyon yok. Ama yüksek trafikli her sitede aynı altı bileşen incelenir. Aşağıdaki hedefler genel mühendislik pratiğinden gelen başlangıç çıtalarıdır; her sitenin yük profili farklı olduğundan kendi ölçümlerinizle doğrulanmalıdır.

Bu kalemlerden hiçbiri tek başına çözüm değil. En sık yapılan hata, kolay satın alınan kalemi büyütmek: sorun veritabanındayken RAM eklemek, sorun önbellek yokluğundayken çekirdek sayısını artırmak.

Trafiği Doğru Birime Çevirmek: Ziyaretçiden İstek Hızına

Ziyaretçi sayısı pazarlama birimidir; sunucu saniyedeki istekle (RPS) çalışır. Dönüşüm üç adımda yapılır. Önce günlük sayfa görüntülemeyi bulun. Sonra tepe saatin payını belirleyin; çoğu sitede günlük trafiğin %8–12’si tek saate sıkışır. Son olarak saniyelik yığılmayı hesaba katın; tepe saatin içinde anlık dalgalanma 3–4 katı bulabilir.

Örnek bir hesap: günde 300.000 sayfa görüntüleme olsun. Tepe saat %10’u taşırsa saatte 30.000, yani saniyede yaklaşık 8 sayfa eder. 3–4 katlık anlık yığılmada bu 25–35 sayfa/sn’ye çıkar. Sayfa başına 2 dinamik istek (HTML ve bir API çağrısı) varsayarsanız kaynak sunucudan 50–70 dinamik istek/sn beklenir. Rakamlar varsayımdır; amaç yöntemi göstermek.

Bu hesabın ürünü, önbelleğe takılmayan istek sayısıdır. CDN ve tam sayfa önbelleği doğru çalışıyorsa isteklerin büyük kısmı kaynak sunucuya hiç gelmez. Bu yüzden iki sayıyı ayrı takip edin: kullanıcıların toplam istek hızı ve kaynak sunucuya (origin) düşen istek hızı.

Little Yasası: Siteler Neden Bir Anda Çöker?

Kuyruk teorisinden gelen Little Yasası şunu söyler: sistemdeki eş zamanlı iş sayısı, istek hızı ile ortalama yanıt süresinin çarpımına eşittir. Tepe saatte saniyede 50 dinamik isteğiniz varsa:

Yanıt süresi otuz katına çıktığında aynı trafik sunucudan otuz kat fazla eş zamanlılık ister. Çöküşün mekaniği de budur: bir sorgu yavaşlar, istekler yığılır, yığılan istekler bellek ve bağlantı tüketir, bu da diğer istekleri yavaşlatır ve döngü kendini besler. Trafik artışı tetikleyici olabilir ama çoğunlukla asıl neden yanıt süresindeki küçük bir bozulmadır.

Kullanım oranı da benzer bir eğri çizer. Tek kuyruklu basit bir modelde yanıt süresi, boştaki işlem süresinin 1/(1−kullanım) katıdır: %50 kullanımda 2 kat, %80’de 5 kat, %90’da 10 kat. Çok çekirdekli sistemler eğriyi bir miktar yatıklaştırır ama şekil aynı kalır. Tepe saatte CPU’yu %60–70 civarında tutacak şekilde boyutlandırmak israf değildir; gecikmeyi kontrol altında tutmanın bedelidir.

CPU Çekirdek Sayısından Önce Çekirdek Kalitesi

PHP, Python ve Node.js gibi çalışma zamanlarında tek bir isteğin süresi çoğunlukla tek çekirdeğin hızına bağlıdır. Bu yüzden 16 yavaş çekirdek, aynı iş için 8 hızlı çekirdekten daha kötü sonuç verebilir. Çekirdek sayısı eş zamanlılığı, saat hızı ise yanıt süresini belirler; ikisi birlikte okunmalıdır.

Sanal sunucularda ayrıca “steal” süresine bakın. top veya vmstat çıktısındaki st değeri sürekli birkaç yüzdeyi aşıyorsa hipervizör çekirdeğinizi başka bir müşteriye veriyordur. Yüksek trafikli bir site için bu, garantili kaynak (dedicated vCPU) ya da fiziksel sunucu gerektiğinin en net işaretlerinden biridir.

RAM Çalışma Kümesini Bellekte Tutmak

RAM ihtiyacı üç kalemden oluşur: uygulama işçileri (PHP-FPM, Node, Gunicorn), veritabanı tamponu ve önbellek servisleri. Veritabanında sık okunan veri ve indekslerden oluşan çalışma kümesi belleğe sığıyorsa disk okuması azalır ve yanıt süresi düşer. İşçi sayısı hesabını e-ticaret örneğiyle ayrıca anlattığımız RAM yazısında adım adım bulabilirsiniz; aynı formül burada da geçerli.

Yüksek trafikte eklenen tek yeni kural şudur: yanıt süresi uzadığında aynı anda açık işçi sayısı artar. Bu yüzden belleği ortalama yüke göre değil, yavaşlama anındaki işçi sayısına göre hesaplayın. Swap’i bir emniyet kemeri olarak düşünün; tepe saatte sürekli kullanılıyorsa sistem zaten sınırdadır.

Disk Bant Genişliği Değil, Gecikme ve IOPS

Web ve veritabanı iş yükleri küçük, rastgele okuma ve yazmalardan oluşur. Bu yüzden ardışık okuma hızından çok rastgele IOPS ve gecikme önemlidir. Büyüklük mertebesi olarak klasik diskler yüzlerce, SATA SSD’ler on binlerce, NVMe diskler ise yüz binlerce IOPS düzeyine çıkabilir. Yüksek trafikli bir veritabanı için NVMe fiilen standarttır.

Pratik kurallar: veritabanı verisini işletim sistemi ve log diskinden ayırın, yedekleme işlerini tepe saatlerin dışına alın (yedekleme okuma yükü canlı sorguları yavaşlatır), kullanıcı yüklemelerini ve statik dosyaları sunucu diskinde değil nesne depolamada tutun. Disk dolması da bir kapasite sorunudur; log rotasyonu olmayan bir sunucu en beklenmedik anda çöker.

Ağ Port Hızı, Çıkış Trafiği ve Konum

Bant genişliği hesabı çoğu zaman atlanır. Saniyede 20 sayfa görüntüleme ve 2 MB’lık sayfa ağırlığı 40 MB/sn, yani yaklaşık 320 Mbit/sn çıkış trafiği eder. Bu, 1 Gbit/sn’lik bir portun üçte birinden fazlasıdır ve henüz yalnızca 20 sayfa/sn’dir. Statik dosyaları CDN’e devrettiğinizde kaynak sunucudan çıkan trafik bunun çok küçük bir kısmına düşer; bu, CDN’in yalnızca hız değil kapasite aracı olduğunu da gösterir.

“Sınırsız trafik” ifadesini sözleşmede doğrulayın. Birçok paketin makul kullanım sınırı ya da aşıldığında port hızının düşürülmesi şartı vardır. Konum konusunda da kullanıcılarınızın çoğunluğu Türkiye’deyse İstanbul’daki ya da Frankfurt gibi yakın bir noktadaki veri merkezi, gecikmeyi ve TLS el sıkışma süresini belirgin biçimde etkiler. Kişisel veri işliyorsanız verinin barındırıldığı ülke ve KVKK yükümlülükleri için hukuki destek alın.

Önbellek Katmanları Yükün Çoğu Kaynağa Hiç Ulaşmamalı

Yüksek trafikli bir sitenin en etkili “donanımı” önbellektir. Katmanlar dıştan içe şöyle sıralanır:

1. Tarayıcı önbelleği. Uzun ömürlü Cache-Control başlıkları ve dosya adına sürüm ekleme (fingerprinting) ile statik dosyalar tekrar indirilmez.
2. CDN. Statik dosyalar ve mümkünse anonim kullanıcıya giden HTML kenarda sunulur.
3. Ters vekil. Nginx veya Varnish, uygulamaya gitmeden yanıtı bellekten verir.
4. Uygulama önbelleği. Redis veya Memcached, pahalı sorgu sonuçlarını ve oturum verisini tutar.
5. Veritabanı tamponu. Son durak; buraya düşen isteği azaltmak asıl hedeftir.

Haber, blog ve katalog gibi her kullanıcıya aynı içeriği sunan sitelerde mikro önbellekleme çok etkilidir: dinamik sayfayı yalnızca birkaç saniye saklamak bile saniyede yüzlerce isteği tek bir uygulama çağrısına indirir.

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mikro:50m max_size=1g inactive=10m;

location / {
    proxy_pass http://uygulama;
    proxy_cache mikro;
    proxy_cache_valid 200 2s;
    proxy_cache_lock on;
    proxy_cache_use_stale updating error timeout;
    add_header X-Cache $upstream_cache_status;
}

Buradaki kritik satır proxy_cache_lock: önbellek süresi dolduğu anda yüzlerce isteğin aynı anda uygulamaya yönelmesini (cache stampede) engeller. Kişiselleştirilmiş sayfalarda, oturum çerezi taşıyan isteklerde ve sepet, hesap gibi alanlarda bu önbelleği uygulamayın.

Veritabanı: Çoğu Zaman İlk Kırılan Halka

Web katmanını yatay büyütmek kolaydır; veritabanını büyütmek değildir. Bu yüzden yük arttıkça ilk darboğaz sıklıkla veritabanında çıkar. Sırasıyla uygulanacak adımlar şöyle:

• Sorgu ve indeks sağlığı. Yavaş sorgu günlüğünü açın, N+1 sorgularını ve indekssiz taramaları temizleyin. Donanım eklemeden önceki en ucuz kazanç budur.
• Bağlantı havuzu. Her bağlantı bellek ve süreç maliyeti taşır. PostgreSQL için PgBouncer, MySQL için ProxySQL gibi araçlar yüzlerce uygulama bağlantısını az sayıda gerçek bağlantıya indirger.
• Okuma replikaları. Okuma ağırlıklı sitelerde okumalar replikalara dağıtılır. Replikasyon gecikmesi nedeniyle kullanıcının az önce yazdığı veriyi hemen okuması gereken ekranlar (ödeme sonucu, profil güncelleme) birincil sunucuya yönlendirilmelidir.
• Ayrı veritabanı sunucusu. Web ve veritabanı aynı makinede yarıştığında ikisinin de ayarı bozulur. Ayırmak hem ayar hem arıza yönetimini kolaylaştırır.
• Bölümleme ve parçalama. Tek sunucuya sığmayan yazma yükünde gündeme gelir. Karmaşıklığı yüksektir, son çare olarak düşünün.

Web Sunucusu ve İşletim Sistemi Ayarları

Event-driven yapıdaki Nginx ve LiteSpeed, bağlantı başına süreç açan Apache prefork modeline göre aynı RAM’le çok daha fazla eş zamanlı bağlantı taşır. HTTP/2 ve HTTP/3, TLS oturum yeniden kullanımı ve makul keepalive ayarları bağlantı maliyetini düşürür.

İşletim sistemi tarafında varsayılan değerler yüksek trafiğe göre ayarlı değildir. Açık dosya sınırı (ulimit -n ve worker_rlimit_nofile), bağlantı kuyruğu (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog) ve geçici port aralığı sık sorun çıkaran noktalardır. Bu ayarları internetten kopyalayıp yapıştırmayın; önce yük testiyle darboğazı görün, sonra değiştirip tekrar ölçün.

Altyapı Seçimi: VPS/VDS, Dedicated Sunucu mu Bulut mu?

Tek doğru seçim yok; melez yapılar da yaygın. Örneğin veritabanını dedicated sunucuda tutup web katmanını bulutta esnek ölçeklemek, ya da CDN ve nesne depolamayı bulutta, çekirdek uygulamayı sabit maliyetli sunucuda çalıştırmak mantıklı olabilir.

Dikey mi Yatay mı Ölçeklemek?

Dikey ölçekleme, aynı sunucuyu büyütmektir: basittir ama tavanı vardır ve tek hata noktası olarak kalır. Yatay ölçekleme, aynı işi yapan birden çok sunucuyu yük dengeleyicinin arkasına dizmektir. Bunun için uygulamanın durumsuz (stateless) olması gerekir:

• Oturumlar sunucu belleğinde değil, Redis gibi ortak bir yerde tutulmalı.
• Kullanıcı yüklemeleri sunucu diskinde değil, nesne depolamada olmalı.
• Yapılandırma ve dağıtım sunucudan sunucuya elle değil, otomatik yapılmalı.

Yük dengeleyicinin kendisi de tek hata noktası olmamalı; keepalived/VRRP ile yüzen IP ya da sağlayıcının yönetilen yük dengeleyicisi bu riski azaltır. Sağlık kontrolleri (health check) sorunlu sunucuyu havuzdan otomatik çıkarmalıdır. Veritabanı tarafında otomatik yük devretme (failover) ayrı bir mühendislik konusudur ve devretme senaryosu mutlaka test edilmelidir.

Aşırı Yükte Kontrollü Bozulma

Her sistemin bir tavanı vardır; fark, tavana ulaşıldığında ne olduğudur. Kontrollü bozulma (graceful degradation), ağır özellikleri kapatarak çekirdek işlevi ayakta tutmaktır: arama önerilerini, kişiselleştirilmiş modülleri ya da canlı sayaçları yük altında devre dışı bırakmak, ağır işleri anlık işlem yerine kuyruğa almak, hız sınırlaması koymak, en kötü durumda statik bir bakım sayfası sunmak. Bilet satışı gibi çok keskin ani yığılmalarda “sanal bekleme odası” da kullanılır.

Bu davranışlar önceden tasarlanıp özellik bayraklarıyla (feature flag) hazır tutulmazsa, kriz anında kod değiştirmek zorunda kalırsınız.

Güvenlik ve Bot Trafiği

Yüksek trafikli sitelerde isteklerin hatırı sayılır bir kısmı otomatik istemcilerden gelir: arama botları, fiyat tarayıcıları, saldırı denemeleri. Uygulama katmanı (L7) saldırıları meşru istek gibi göründüğü için yalnızca bant genişliğiyle savuşturulamaz. WAF, hız sınırlama, bot yönetimi ve DDoS koruması sunan bir ön katman, sunucu kapasitenizin bir parçası sayılmalıdır. Aksi halde satın aldığınız çekirdeklerin bir kısmını istemediğiniz trafik tüketir.

Test ve Kapasite Planı: Kırılma Noktanızı Önceden Bulun

Kapasiteyi tahmin etmek yerine ölçmenin yolu yük testidir. k6, Locust ve wrk bu iş için yaygın araçlardır. Üç senaryoyu ayırın: kademeli artışla (ramp-up) kırılma noktasını bulma, ani yığılmayla (spike) toparlanma davranışını görme ve uzun süreli (soak) testle bellek sızıntısı ve kaynak birikimini yakalama. Testi canlı sistemde değil, veri hacmi ve yapılandırma bakımından canlıya benzeyen bir ortamda yapın; önbellek soğukken ve sıcakken ayrı ayrı çalıştırın.

İzlemede ortalama yerine p95 ve p99 yanıt sürelerine bakın; kullanıcının yaşadığı yavaşlık ortalamada görünmez. Bileşenler için kullanım, doygunluk ve hata oranı (USE), servisler için istek hızı, hata ve süre (RED) metrikleri iyi bir çerçevedir. Kapasiteyi planlarken tepe yükün en az 2 katını kaldıracak şekilde ya da bir sunucu düşse de hizmetin sürdüğü (N+1) biçimde boyutlandırın.

Erişilebilirlik hedefinizi de rakama dökün. 30 günlük bir ayda:

Bu tablo, her ek “9”un maliyetini görünür kılar: %99,99 için yedekli yük dengeleyici, otomatik yük devretme ve çoğu zaman çok bölgeli mimari gerekir.

Sık Sorulan Sorular

Yüksek trafikli bir site için VPS yeterli mi?

Trafiğin büyük kısmı CDN ve önbellekle karşılanıyor, kaynak sunucuya düşen dinamik istek sayısı düşükse güçlü bir VDS uzun süre yeterli olabilir. Ancak CPU steal, disk gecikmesi ya da tavan sorunu yaşıyorsanız dedicated sunucuya veya çok sunuculu mimariye geçme zamanı gelmiştir.

Bir sunucu aynı anda kaç kullanıcıyı kaldırır?

Sabit bir cevap yoktur. Kapasite uygulamanın yanıt süresine ve önbellek isabet oranına bağlıdır. Little Yasası ile eş zamanlı iş sayısını hesaplayıp yük testiyle doğrulamak tek güvenilir yöntemdir.

CDN kullanmak yüksek trafik sorununu çözer mi?

Statik içerik ve anonim kullanıcıya sunulan sayfalar için büyük ölçüde çözer; kaynak sunucunun yükünü ve bant genişliğini ciddi azaltır. Ama kişiselleştirilmiş, veritabanına yazan ya da oturum gerektiren istekler yine kaynak sunucuya gelir. Bunlar için veritabanı ve uygulama katmanı hazır olmalıdır.

Dedicated sunucu mu, bulut mu tercih edilmeli?

Yük sabit ve öngörülebilirse dedicated sunucu çoğu zaman daha ucuz ve tutarlıdır. Trafik dalgalıysa ya da hızla büyüyorsa otomatik ölçekleme sunan bulut daha uygundur. Çıkış trafiği ücretlerini maliyet hesabına mutlaka katın.