1. Anasayfa
  2. Sunucu Teknolojileri

Load Balancer ile Trafik Dağıtımı – 5 Temel Kural

Load Balancer ile Trafik Dağıtımı – 5 Temel Kural
0

Öne Çıkanlar

  • Load balancer gelen trafiği birden fazla sunucuya dağıtarak erişilebilirlik ve performansı artırır; sağlık kontrolleriyle bozuk sunucuları otomatik olarak devre dışı bırakır.
  • Yatay ölçekleme (birden fazla orta seviye sunucu) genelde tek büyük sunucudan daha dayanıklı ve esnektir; izleme ve doğru yapılandırma kritik.
  • Doğru health check, port ve firewall ayarları ile SSL yapılandırması uptime ve güvenlik için önemli; backend sunucular mümkünse sadece özel ağ üzerinden erişilebilir olmalı.
  • Veritabanı optimizasyonu (okuma/yazma ayrımı, replikasyon, slow_query_log) ve PHP/uygulama uyumluluğu olmadan load balancer tek başına çözüm değildir.
  • Kurulum sırasında kademeli geçiş, test ve log izleme temel adımlardır; sık karşılaşılan problemler için pratik çözümler uygulanabilir.

Load Balancer Nedir? Trafiği Nasıl Dağıtır? Hakkında Bilmeniz Gerekenler

Load Balancer Nedir? Trafiği Nasıl Dağıtır? Sorunun kalbi burada: Tek bir sunucunun taşıyabileceği yük sınırlı. Ama kullanıcıların beklentisi sınırsız. Bir kampanya açıyorsun, reklam veriyorsun, trafik uçuyor ve sonra klasik sahne: “Sitem açılmıyor, panel girmiyor, CPU %100.” İşte load balancer tam bu noktada devreye giriyor. Gelen trafiği tek bir makineye yığmak yerine, birden fazla sunucuya akıllıca bölüyor. Böylece ne sunucu boğuluyor ne de kullanıcı beyaz ekrana bakmak zorunda kalıyor.

İşin güzeli şu: Load balancer sadece trafiği bölmekle kalmıyor, bozulan sunucuyu oyundan alan, sağlıklıları öne süren bir “trafik polisi” gibi davranıyor. Hem ilk kez sunucu yöneten biri için hem de yıllardır root ile yatıp kalkanlar için kritik bir katman. Çünkü dürüst olalım, tek sunucuya güvenmek üretimde artık kumar oynamak gibi.

Hizmet Türü Cloud / VDS / Yük Dengeleme Katmanı
Hedef Kitle Geliştirici, Orta-Büyük Trafikli Projeler, Kurumsal
Zorluk Seviyesi Orta / İleri
Öne Çıkan Özellik Yüksek Erişilebilirlik ve Performans

Şöyle düşünün: Elinizde tek kasiyeri olan bir market var. Kapıya 100 kişi birden dayandığında ne oluyor? Kuyruk, stres, kaçan müşteriler. Load balancer, markete ikinci, üçüncü, dördüncü kasayı eklemek ve kapıdaki trafiği bu kasalara paylaştırmak gibi. Kullanıcılar web sitenize geldiğinde önce load balancer’a uğruyor, o da bu istekleri arka plandaki sunuculara (backend node’lara) dağıtıyor.

Bu dağıtım “rastgele” yapılmıyor. Round-robin, least-connections, IP hash gibi algoritmalar devrede. Örneğin round-robin, istekleri sırasıyla sunuculara gönderiyor. Least-connections, o anda en az aktif bağlantısı olan sunucuyu seçiyor. Böylece hem yük dengeleniyor hem de kaynaklar daha verimli kullanılıyor.

En yaygın efsanelerden biri şu: “Sunucuyu 16 çekirdek yapayım, sorun kalmaz.” Aslında durum tam olarak şöyle: Tek bir sunucuyu şişirmek yerine, birden fazla orta seviye sunucuyu load balancer ile ölçeklemek çoğu zaman çok daha stabil ve esnek. Yani her zaman “daha çok çekirdek” değil, “daha iyi dağıtılmış yük” kazandırıyor.

Load balancer ayrıca health check yapar. Yani düzenli olarak arka uç sunuculara “iyi misin?” diye sorar. Cevap alamadığı sunucuyu listeden çıkarır, kullanıcıyı bozuk dükkana yönlendirmez. Bu da uptime tarafında ciddi fark yaratır. Tıpkı bir araba motoru gibi, yüksek devirde (trafikte) doğru soğutmaya (kaynak dağılımına) ihtiyaç var; load balancer da işte o soğutma sistemi.

Yapılandırma ve Yönetim: Adım Adım

Kaynak Yönetimi – Limitleri Zorlamayın

Load balancer kurdunuz diye iş bitmiyor. Arkadaki sunucuların CPU, RAM ve disk I/O değerleri hâlâ oyunun kaderini belirliyor. Dürüst olmak gerekirse, çoğu projede sorun “sunucu zayıf” olduğundan değil, yanlış yapılandırma ve izleme eksikliğinden çıkıyor.

İlk kural: ölçmeden yönetmeye kalkmayın. top, htop, iostat, vmstat, sar gibi araçlar ya da panel tarafında sunucu istatistikleri mutlaka aktif olsun. CPU sürekli %80+ ise, RAM doluysa ve swap kullanımı artıyorsa load balancer ne kadar akıllı olursa olsun darboğaz kaçınılmaz.

Genelde kullanıcılarımızdan duyduğumuz en büyük şikayet şu oluyor: “Aşırı kaynak kullanımı uyarısı aldım, ama site normal görünüyor.” Böyle bir durumda panik yapmadan önce bakılacak ilk yer log dosyalarıdır. Apache/Nginx için:

  • /var/log/nginx/access.log, /var/log/nginx/error.log
  • /var/log/apache2/access.log, /var/log/apache2/error.log

Bu loglarda anormal istek patlamaları, yoğun bir IP bloğu, saldırı girişimleri veya hatalı bir bot trafiği var mı, önce onu görün. Çoğu zaman “sunucu çöktü” dediğimiz şey aslında yük dengesizliğiyle birleşmiş bir log/istek fırtınası oluyor.

Eğer projeniz büyüyorsa, klasik paylaşımlı hosting yerine VDS veya Cloud sunucu ile load balancer kombinasyonu çok daha sağlıklı bir yol haritası sunar.

Güvenlik Duvarı ve Port Ayarları

İşin püf noktası şurada: Dış dünyaya açık her port, açık bir penceredir. Load balancer’ı konumlandırırken hangi portların dış dünyaya, hangilerinin sadece iç ağa açık olacağını net belirlemek gerekiyor.

  • HTTP için genelde 80, HTTPS için 443 kullanılır. Load balancer bu portlarda dış dünyaya açık olabilir.
  • Backend sunucular (uygulama sunucuları) çoğu zaman sadece özel ağ üzerinden erişilebilir olmalı. Örneğin Nginx load balancer 80/443’ten istek alır, arka uçta 8080 portuna yönlendirir; ama 8080 dış dünyaya kapalıdır.
  • SSH portunu (varsayılan 22) değiştirmek hâlâ geçerli ve basit bir koruma katmanı. Fail2ban gibi araçlarla birleştirildiğinde brute-force saldırıları ciddi şekilde hafifler.
  • FTP’ye açıkçası mecbur değilseniz SFTP/SSH üzerinden dosya aktarımını tercih edin. Klasik FTP hem karmaşık firewall ayarlarına hem de ekstra risklere sebep olur.

Güvenlik duvarı tarafında ufw, firewalld veya panel tabanlı çözüm kullanıyorsanız temel mantık aynı: Yalnızca ihtiyacınız olan portları açın, kalanını kapatın. Ve SSL konusunu da atlamayın. Özellikle HTTPS trafiğini doğrudan load balancer üzerinde sonlandıracaksanız, SSL sertifikası yapılandırmanız doğru olmalı; yoksa kullanıcıların tarayıcıları farklı hata mesajlarıyla dolmaya başlar.

Yazılım Uyumluluğu ve PHP/Veritabanı Seçimi

“En güncel sürüm en iyisidir” sözü, üretim ortamında her zaman çalışmıyor. Örneğin en yeni PHP sürümüne geçip load balancer arkasında onlarca uygulama koşturduğunuzu düşünün. Framework’ünüz, eklentileriniz veya bazı kütüphaneler henüz bu sürümü tam desteklemiyorsa, yük arttığında saçma sapan hatalar görebilirsiniz. Özellikle major versiyon geçişlerinde staging/test ortamı olmadan doğrudan canlıya geçmek büyük risk.

Veritabanı tarafında ise altın kural şu: Okuma ve yazma yükünü karıştırmayın. Tek bir MySQL/MariaDB sunucusuna hem yoğun yazma (insert/update) hem de raporlama/sorgu yükü bindirirseniz, load balancer uygulama katmanını kurtarsa bile veritabanı tek başına boğulur. Replikasyon ile okuma sunucuları ayırmak, indeksleri doğru tasarlamak ve yavaş sorgu logunu (slow_query_log) aktif ederek hangi sorguların sistemi kilitlediğini izlemek uzun vadede en çok kazandıran optimizasyonlar.

Bu arada, performansınızı artırmak için Sunucu Teknolojileri sayfamızdaki diğer çözümlere de bakabilirsiniz. Load balancer tek başına mucize yaratmaz; doğru PHP versiyonu, optimize veritabanı ve önbellekleme kombinasyonuyla birlikte asıl gücünü gösterir.

Uygulama: Kurulum ve Yayına Alma

Terminali açın, şu komutu girin demiyorum ama mantık şu şekilde işliyor:

  1. Altyapıyı planla: Kaç adet backend sunucu olacak? Web ve veritabanı ayrılacak mı? Trafik tahmini ne?
  2. Load balancer yazılımını seç: Nginx, HAProxy, Envoy, haproxy temelli managed çözümler veya cloud load balancer servisleri. Her birinin artısı eksisi var. Örneğin Nginx basit HTTP yük dengeleme için yeterli ve hafif, HAProxy ise daha ayrıntılı TCP/HTTP kontrolü sunuyor.
  3. Health check yapılandır: Her backend için basit bir /health endpoint’i oluşturarak, load balancer’ın bu URL’yi düzenli kontrol etmesini sağla. 200 dönmeyen sunucu, listeden otomatik çıkarılmalı.
  4. Config dosyasını düzenle: Nginx için upstream blokları, HAProxy için backend/frontend blokları belirlenir. Örneğin:
    upstream app_backend {
        server 10.0.0.2:80;
        server 10.0.0.3:80;
    }

    gibi.

  5. SSL ve yönlendirme kuralları: HTTPS’yi load balancer üzerinde bitirip backend’e HTTP ile devam edebilir veya uçtan uca şifreleme (end-to-end SSL) de kullanabilirsiniz. Burada proje gereksinimleri önemli.
  6. Test et ve kademeli geçiş yap: Canlı trafiğin tamamını bir anda taşımak yerine, önce trafiğin küçük bir yüzdesini load balancer’a alıp hata loglarını takip etmek daha güvenli.

Genelde temel bir HTTP load balancer yapılandırması için 5–10 dakika yetiyor. Tabii asıl zaman alan kısım, konfigürasyon sonrası izleme, log analizi ve ince ayar. Orada da deneyim devreye giriyor.

Sık Karşılaşılan Sorunlar ve Pratik Çözümler

Sorun Muhtemel Neden Çözüm
Site Yavaş Açılıyor Zayıf önbellekleme veya yüksek sorgu sayısı Redis/Litespeed Cache kurulumu yapın
Bağlantı Zaman Aşımı Firewall engeli veya hatalı DNS Port izinlerini kontrol edin
Bazı Kullanıcılar Sürekli Logout Oluyor Session verisi sunucular arasında paylaşılmıyor, sticky session yok Session’ları Redis/Memcached’e taşıyın veya load balancer’da “sticky session” (IP hash) aktif edin
Bir Sunucu Çöktüğünde Site Kısa Süre Tamamen Gitmiş Gibi Görünüyor Health check aralığı uzun veya hata toleransı yanlış ayarlanmış Health check süresini kısaltın, maksimum hata sayısını azaltın, logları inceleyin
SSL Hata Veriyor / Tarayıcı Güvenmiyor Yanlış domain için sertifika, eksik ara sertifikalar Doğru alan adı için geçerli bir SSL sertifikası yükleyin, chain dosyalarını kontrol edin

Sıkça Sorulan Sorular

Load balancer kullanmak güvenli mi?

Load balancer kullanmak güvenli mi?
Evet, doğru yapılandırıldığında load balancer güvenliği zayıflatmaz, aksine merkezi bir kontrol noktası sunduğu için güvenlik politikalarını yönetmeyi kolaylaştırır. HTTPS’yi burada sonlandırıp WAF (Web Application Firewall) veya rate limiting gibi ek katmanlar ekleyebilirsiniz. Önemli olan; gereksiz portları kapatmak, düzenli güncelleme yapmak ve logları takip etmek.

Fiyat/Performans dengesini nasıl kurarım?

Fiyat/Performans dengesini nasıl kurarım?
Aslında işin mantığı basit: Tek devasa bir sunucuya yüklü para vermek yerine, orta ölçekli birkaç sunucu ve araya konumlandırılmış bir load balancer genelde daha mantıklı. Trafiğiniz artarsa yeni node ekleyerek yatayda ölçeklersiniz. Küçük ve orta çaplı projeler için iyi optimize edilmiş bir web hosting veya WordPress hosting ile başlamak, trafik belli bir seviyeyi geçince VDS + load balancer’a geçmek iyi bir strateji.

Taşıma (Migration) işlemi zor mu?

Taşıma (Migration) işlemi zor mu?
Load balancer mimarisine geçerken en çok korkulan kısım “Taşıma sırasında site gider mi?” sorusu oluyor. Doğru planlama ile hayır. Yeni sunucularınızı ve load balancer’ınızı paralel olarak kurup test ettikten sonra DNS kayıtlarını yeni IP’ye yönlendirmek genelde yeterli. Dilerseniz bu aşamada Bilhost ekibi taşıma sürecinde yanınızda olabilir, VDS veya Cloud sunucu yapınız için kurulum ve geçiş adımlarını birlikte planlayabiliriz.

Sonuç

İşin özü şu: “Load Balancer Nedir? Trafiği Nasıl Dağıtır?” sorusunun cevabı, sitenizin kaderini tek bir makineye emanet etmemeniz gerektiğini anlatıyor. Trafiği akıllıca dağıtan, çöken sunucuyu devre dışı bırakan ve altyapınızı ölçeklenebilir hale getiren bir katman bu. Teknoloji ne kadar karmaşık görünürse görünsün, doğru yapılandırma hayat kurtarır. Eğer bir yerde takılırsanız biz buradayız, yorumlarda sorularınızı bekliyorum. Ayrıca projeyi büyütmeyi düşünüyorsanız, ölçeklenebilir altyapı için Cloud sunucu ve VDS seçeneklerine de göz atabilirsiniz.

İlginizi Çekebilir

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir