Kısaca özet
- Yük dengeleme, gelen istekleri aynı uygulamayı çalıştıran birden çok sunucuya dağıtan ve sunuculardan biri yanıt vermediğinde trafiği sağlam olanlara yönlendiren ara katmandır.
- Yaygın üç algoritma round robin (sırayla), least connections (en az aktif bağlantıya) ve IP hash’tir (aynı ziyaretçi hep aynı sunucuya); istek süreleri farklıysa least connections daha dengeli dağıtır.
- L4 dengeleyici bağlantıyı IP ve port bilgisiyle yönlendirir, L7 dengeleyici HTTP isteğini okuyup adrese, başlığa ya da çereze göre karar verir.
- Kurumsal sitelerin ve orta ölçekli mağazaların çoğunda tek güçlü sunucu, sayfa önbelleği ve CDN yeterlidir; birden çok sunucu bu adımlar tükendiğinde gündeme gelir.
- Asıl zorluk dengeleyici değil paylaşılan durumdur: oturumlar, yüklenen dosyalar ve veritabanı ortak bir yere taşınmadan ikinci sunucu işe yaramaz.
- Tek dengeleyici de tek arıza noktasıdır; kesintisiz hizmet hedefleniyorsa ikinci bir dengeleyici ve devralma planı gerekir.
Kampanya saatinde sipariş sayfası yavaşlıyor, izleme ekranında işlemci yüzde yüze dayanmış duruyor ve ekipten biri “yük dengeleyici kuralım” diyor. Öneri kulağa doğru gelir ama çoğu zaman erken bir adımdır. Yük dengeleme trafiği birden çok sunucuya bölerek hem kapasite hem dayanıklılık kazandırır; karşılığında altyapıyı belirgin biçimde karmaşıklaştırır. Neyi çözüp neyi çözmediğini bilmek, gereksiz sunucu faturasından korur.
Yük dengeleme nedir, istekler nasıl dağıtılır
Bu mimaride ziyaretçi doğrudan uygulama sunucusuna değil, önde duran dengeleyiciye bağlanır. Dengeleyici arka taraftaki sunucu havuzundan birini seçer, isteği ona iletir ve yanıtı ziyaretçiye geri gönderir. Alan adının DNS kaydı yalnız dengeleyicinin IP adresini gösterir.
Dengeleyicinin ikinci görevi sağlık kontrolüdür. Havuzdaki bir sunucu hata döndürmeye ya da zaman aşımına düşmeye başlarsa dengeleyici onu bir süre devreden çıkarır ve yeni istekleri kalan sunuculara verir. Nginx’in HTTP yük dengeleme dokümanı bu pasif kontrolü, art arda kaç başarısız denemeden sonra sunucunun arızalı sayılacağını ve ne kadar süre dışarıda tutulacağını belirleyen ayarlarla anlatır. Böylece tek bir uygulama sunucusunun çökmesi sitenin kapanması anlamına gelmez.
Bilgi
Dengeleyici çoğunlukla bir ters vekil sunucudur (reverse proxy). Nginx ve HAProxy bu iş için yaygın kullanılan iki açık kaynak yazılımdır ve ayrı bir sunucuda çalıştırılmaları önerilir.
Yük dengeleme algoritmaları karşılaştırması
Sıradaki isteğin hangi sunucuya gideceğini algoritma belirler. Doğru seçim, isteklerinizin ne kadar benzer süreli olduğuna ve uygulamanın oturum bilgisini nerede tuttuğuna bağlıdır.
| Algoritma | Nasıl seçer | Güçlü yanı | Zayıf yanı | Uygun iş yükü |
|---|---|---|---|---|
| Round robin | Sunucuları sırayla dolaşır | Basit, ek hesap gerektirmez | Uzun süren istekleri hesaba katmaz | Kısa ve benzer süreli istekler |
| Ağırlıklı round robin | Güçlü sunucuya ağırlığı oranında daha çok istek verir | Farklı boyuttaki sunucuları birlikte kullanır | Ağırlıklar elle ayarlanır | Karışık donanımlı havuz |
| Least connections | En az aktif bağlantısı olan sunucuyu seçer | Yavaş istekler tek sunucuda birikmez | Bağlantı sayısı her zaman gerçek yükü göstermez | API, rapor üreten paneller, süresi değişken istekler |
| IP hash | Ziyaretçi IP’sinden hesaplanan değerle sunucu seçer | Aynı ziyaretçi aynı sunucuya düşer | Aynı IP arkasındaki kalabalık tek sunucuya yığılır | Oturumu yerel diskte tutan eski uygulamalar |
Nginx’te varsayılan yöntem round robin’dir; least connections ve IP hash tek satırlık bir yönergeyle açılır. Hangi yöntemi seçerseniz seçin, havuzdaki sunucuların aynı uygulama sürümünü çalıştırması gerekir. Aksi hâlde aynı sayfa bir istekte eski, bir sonrakinde yeni sürümle yanıtlanır.
L4 ile L7 yük dengeleme arasındaki fark
L4 (taşıma katmanı) dengeleyici TCP ya da UDP bağlantısına bakar: kaynak ve hedef IP, port. Paketin içeriğini okumaz, bu yüzden hafiftir ve HTTP dışındaki protokollerde de çalışır. Veritabanı bağlantılarını, oyun sunucusu trafiğini ya da SMTP’yi dağıtmak için bu katman kullanılır.
L7 (uygulama katmanı) dengeleyici HTTP isteğini açar. Adrese göre yönlendirme yapabilir; örneğin /api ile başlayan istekleri bir havuza, görselleri başka bir havuza gönderir. SSL’i önde sonlandırıp arka sunucuları şifre çözme yükünden kurtarabilir, çereze bakarak ziyaretçiyi aynı sunucuda tutabilir. Karşılığında her isteği ayrıştırdığı için biraz daha fazla işlemci harcar. Web siteleri için pratik tercih neredeyse her zaman L7’dir.
Oturum yapışkanlığı ve paylaşılan durum sorunu
Çok sunuculu mimarinin en çok atlanan tarafı uygulamanın durum bilgisidir. PHP varsayılan olarak oturum dosyalarını sunucunun kendi diskine yazar. Ziyaretçi ilk isteğinde A sunucusunda oturum açıp ikinci isteğinde B’ye düşerse sistem onu tanımaz: sepet boşalır, yönetim paneli yeniden giriş ister.
Oturum yapışkanlığı (sticky session) bu sorunun hızlı çözümüdür; dengeleyici aynı ziyaretçiyi IP ya da çerez üzerinden hep aynı sunucuya gönderir. O sunucu çöktüğünde ise oturumlar da gider ve mobil operatörlerin çok sayıda kullanıcıyı tek IP arkasında toplaması IP tabanlı yapışkanlığı dengesizleştirir. Kalıcı çözüm oturumu tüm sunucuların eriştiği ortak bir depoya, örneğin Redis’e ya da veritabanına taşımaktır. Aynı kural yüklenen dosyalar için de geçerlidir: bir görsel yalnız bir sunucunun diskine inerse diğer sunucudan açılan sayfada kırık görünür.
Örnek senaryo
Çevrim içi sınav yapan bir eğitim platformu, sınav saatlerinde aynı anda 2.500 öğrenciyi karşılıyor. Önce sunucusunu bir üst pakete taşıdı ve statik sayfalar için önbellek açtı; sınav ekranı kişiye özel olduğu için önbellekten yararlanamadı ve işlemci yine doydu. Sonraki adımda bir Nginx dengeleyici, üç uygulama sunucusu ve ayrı bir veritabanı sunucusu kurdu, PHP oturumlarını Redis’e taşıdı. Artık sunuculardan biri güncelleme için yeniden başlatılırken sınav kesilmiyor ve yük üç makineye bölünüyor.
Dikkat
Yavaşlığın kaynağı veritabanıysa ikinci web sunucusu işe yaramaz, hatta durumu kötüleştirir: iki sunucu aynı veritabanına iki kat sorgu gönderir. Karar vermeden önce darboğazın PHP tarafında mı, veritabanında mı, diskte mi olduğunu ölçün.
Tek sunucu ne zaman yetmez
Birden çok sunucuya geçişi haklı çıkaran durumlar üç başlıkta toplanır. Birincisi dikey ölçek tavanıdır: sunucunuzu erişebildiğiniz en büyük pakete taşıdınız, önbelleği ve sorguları iyileştirdiniz, işlemci yoğun saatlerde hâlâ doygun. Bir makineye eklenebilecek çekirdek sayısının bir sınırı vardır; ondan sonrası yatay ölçeklemedir.
İkincisi kesintisiz bakım ihtiyacıdır. Tek sunucuda çekirdek güncellemesi ya da yeniden başlatma birkaç dakikalık kesinti demektir. İki uygulama sunucusu varsa birini havuzdan çıkarıp güncellersiniz, ziyaretçi farkı görmez. Üçüncüsü yüksek erişilebilirliktir: bir saatlik kesintinin maliyeti ek sunucuların aylık maliyetini aşıyorsa, arızaya karşı ikinci bir kopyanın çalışır hâlde beklemesi mantıklıdır.
Bunların hiçbiri yoksa, yani trafik tek sunucuya sığıyor ve birkaç dakikalık planlı bakım kabul edilebiliyorsa, yük dengeleme maliyet ve yönetim yükü ekler ama karşılığında hissedilir bir kazanç vermez.
Önce dikey ölçekleme ve önbellekle ne kadar gidilir
Çoğu site için doğru sıra bellidir. Önce ölçün: hangi saatte, hangi süreç işlemciyi dolduruyor; bunun için işlemci yükü takibi rehberi yeterlidir. Sonra sayfa önbelleği açın; önbellekten dönen bir sayfa PHP’yi ve veritabanını hiç çalıştırmaz, aynı sunucu çok daha fazla ziyaretçi taşır. Statik dosyalar ve uzak ziyaretçiler için CDN gerekir mi sorusunu ayrıca değerlendirin.
Ardından dikey ölçekleme gelir: daha çok çekirdek ve bellek. Doğru boyutu kestirmek için VPS’e ne kadar RAM ve CPU gerekir yazısındaki ölçütler kullanılabilir. Paket yükseltmek uygulamanızda tek satır değişiklik gerektirmez. Yük dengeleme ise uygulamayı birden çok sunucuda çalışacak şekilde yeniden düzenlemeyi ister. Dikey ölçek ucuz ve hızlı kaldığı sürece önce o kullanılır.
Birden çok sunucuyla yük dengeleme kurmak
En küçük anlamlı kurulum dört parçadan oluşur: bir dengeleyici, iki uygulama sunucusu ve ayrı bir veritabanı sunucusu. Dengeleyici küçük bir sunucu olabilir; asıl kaynak uygulama ve veritabanı tarafına gider. Sunucular arasındaki veritabanı ve oturum trafiğini güvenlik duvarında yalnız birbirlerinin IP adreslerine açın.
Narhost’ta bu yapı birden çok bulut sunucu ya da VPS alınarak ve dengeleyici görevini üstlenecek sunucuya Nginx veya HAProxy kurularak oluşturulur. Sunucular yönetimsizdir: root erişimi sizdedir, dengeleyici yapılandırması, güncellemeler ve izleme sizin sorumluluğunuzdadır. Nginx’in adım adım kurulumu Nginx kurulum rehberinde yer alır. Hangi sunucu tipinin hangi katmana uyduğunu VPS mi VDS mi bulut sunucu mu karşılaştırmasından seçebilirsiniz.
Sonuç
Yük dengeleme ölçeklemenin son basamağıdır, ilk basamağı değil. Önce ölçüm, sonra önbellek, sonra daha büyük sunucu gelir. Bu adımlar tükendiğinde ya da kesintisiz bakım bir iş gereği hâline geldiğinde birden çok sunucu ve önde bir dengeleyici gerçek fark yaratır.
Birden çok sunucuya geçmeden önce kontrol listesi
- Darboğazı ölçün: işlemci mi, bellek mi, disk mi, veritabanı mı.
- Sayfa önbelleğini ve statik dosyalar için CDN’i devreye alın.
- Sunucuyu bir üst pakete taşıyıp yükün düşüp düşmediğini görün.
- PHP oturumlarının nerede tutulduğunu belirleyin, gerekirse ortak bir depoya taşıyın.
- Yüklenen dosyaların tüm sunuculardan erişilebilir bir yerde durmasını sağlayın.
- Veritabanını uygulama sunucularından ayırın ve tek kaynaktan yönetin.
- Dengeleyicinin kendisi için ikinci bir dengeleyici ya da hızlı yeniden kurulum planı hazırlayın.
- Havuzdaki bir sunucuyu bilerek kapatıp sitenin açık kaldığını test edin.
Sıkça sorulan sorular
Yük dengeleme her site için gerekli mi?
Hayır. Trafiği tek sunucuya sığan ve birkaç dakikalık planlı bakımı kabul edebilen sitelerde yük dengeleme maliyeti ve yönetim yükünü artırır, karşılığında belirgin bir kazanç vermez. Önce önbellek, CDN ve daha büyük bir sunucu denenir; bunlar yetmediğinde ya da kesintisiz hizmet bir iş gereği olduğunda birden çok sunucuya geçilir.
Round robin mi least connections mı seçmeliyim?
İstekleriniz kısa ve birbirine benziyorsa round robin yeterlidir ve en az ayar ister. Bazı istekler saniyeler sürüyorsa, örneğin rapor üreten bir panel ya da dışa aktarma işlemi varsa, least connections yavaş işlerin tek sunucuda birikmesini önler. İkisi arasındaki geçiş dengeleyicide tek satırlık bir ayardır; trafiği izleyerek değiştirebilirsiniz.
Dengeleyici saldırı trafiğini durdurur mu?
Durdurmaz. Dengeleyici gelen trafiği dağıtır ama hacimli bir saldırıda önce kendisi dolar. Saldırı trafiğini ağ tarafında süzmek ayrı bir katmandır; Narhost altyapısındaki saldırı koruması ağ ve taşıma katmanını (Layer 3/4) kapsar. Uygulama katmanındaki istek selleri için web uygulama güvenlik duvarı ve istek hızı sınırlaması ayrıca yapılandırılır.
SSL sertifikası dengeleyiciye mi kurulur, sunuculara mı?
L7 kurulumlarda sertifika genellikle dengeleyiciye kurulur ve şifreli bağlantı orada açılır. Arka sunuculara giden trafik düz HTTP olarak ya da yeniden şifrelenerek iletilir. Bu yöntem sertifikayı tek yerde yenilemenizi sağlar. Uygulamaya ziyaretçinin HTTPS ile geldiğini bildiren başlığı iletmeyi unutmayın, yoksa sonsuz yönlendirme döngüsü oluşur.
WordPress birden çok sunucuda çalışır mı?
Çalışır ama hazırlık ister. Veritabanı tek ve ortak olmalı, yüklenen medya dosyaları tüm sunucuların gördüğü bir depoda durmalı, eklenti ve tema güncellemeleri her sunucuya aynı anda dağıtılmalıdır. Yönetim paneli isteklerini tek bir sunucuya sabitlemek dosya yazma çakışmalarını azaltır.
İlgili bir karar için Kubernetes nedir, küçük projede gerekir mi yazısını da okuyun.
Aynı kümede sık sorulan bir başka soru veritabanı sunucusunu ne zaman ayırmak gerektiği; ayrıntıları ayrı yazıda ele aldık.
Narhost’ta
Bulut sunucularda NVMe disk, 50 Gbps port ve tarayıcı terminali standarttır; paket yükseltmeyi müşteri panelinden yaparsınız. Birden çok sunucuyla kendi dengeleyicinizi kurduğunuzda root erişimi ve yapılandırma sizdedir.