HAProxy, TCP ve HTTP trafiğini backend havuzlarına dağıtan L4/L7 yük dengeleyicidir. Yalnızca istekleri sırayla göndermek için değil, servis sağlığına ve erişim politikalarına göre trafik kararları almak için kullanılır. Kapasitesi; donanım, TLS, bağlantı süresi ve kuralların maliyetine bağlıdır; tek bir istek/saniye değeri bütün kurulumları temsil etmez.
ACL (Access Control List) motoru, gelişmiş health check sistemi (HTTP, TCP, MySQL, PostgreSQL, Redis), stick-table’lar (rate limiting + session persistence) ve runtime API’si HAProxy’yi kurumsal yük dengeleme için olgun ve güçlü kılar. Nginx ile karşılaştırıldığında daha sade ve yük dengelemeye odaklı bir araçtır.
Mono’nun yaklaşımı
Mono kurulumlarında HAProxy genelde trafik girişinin ilk katmanı olarak konumlanır. Standartlarımız:
- HA pattern: Keepalived + VRRP ile aktif-pasif çift; veya Anycast + ECMP ile aktif-aktif (BGP destekli ortamlarda).
- TLS: Sertifika yaşam döngüsü ve backend şifreleme politikası tanımlanır; runtime üzerinden sertifika güncelleme kullanılan sürüm ve yöntemle doğrulanır.
- Health check: Sade
option httpchkyerine expect ile gerçek 200 kontrolü; uygulama health endpoint’i (/health/readyile bağımlılık kontrolü). - Logging: Yapılandırılmış loglar merkezi sisteme aktarılır; request ID korelasyon sağlar, tek başına dağıtık tracing oluşturmaz.
- Stick-table: Rate limit, brute-force koruması, IP reputation tracking.
- Stats:
stats socketUnix soketi → Data Plane API → Mono operasyon ekibi yönetir.
Tipik kurulum
Kurumsal trafik girişi:
- Cloudflare/Akamai (CDN + DDoS koruma).
- HAProxy aktif-pasif çifti (keepalived ile VIP’i yönetir).
- HAProxy backend pool’ları → uygulama sunucuları (sticky cookie ile session affinity).
- Health check ile sağlıksız node’lar otomatik dışlanır; recovery’de yavaş yavaş trafik alır (
slowstart).
PostgreSQL/MariaDB cluster önünde HAProxy + custom healthcheck (örn. Patroni REST endpoint’i) ile otomatik primary keşfi çok yaygın bir Mono pattern’idir.
Yaygın sorunlar ve çözümler
- Bağlantı reddi: Servis erişimi, bağlantı kuyruğu ve dosya tanıtıcı kullanımı birlikte kontrol edilir.
- TIME_WAIT artışı: Önce bağlantı yeniden kullanımı ve trafik profili incelenir; kernel ayarları körlemesine değiştirilmez.
- Yavaş failover: Sağlık tespiti, ağ devri ve istemci yeniden bağlanma süreleri ayrı ölçülür.
- Oturum kaybı: Stick-table senkronizasyonunun uygulama oturum verisini çoğaltmadığı unutulmaz.
- Bütün backend’lerin sağlıksız görünmesi: Health check beklentisi, ağ, TLS ve bağımlılık durumu araştırılır; kontroller devre dışı bırakılarak sorun gizlenmez.
Round-robin, leastconn ve oturum sürekliliği
Kısa ve benzer maliyetli HTTP isteklerinde round-robin anlaşılır bir başlangıçtır. Uzun bağlantılarda leastconn, aktif bağlantı sayısını dengelemeye yardımcı olabilir. Ancak bağlantı sayısı CPU maliyetiyle aynı değildir; tek bir ağır istek ile çok sayıda hafif istek eşdeğer yük oluşturmaz. Algoritma kararı uygulama davranışıyla sınanmalıdır.
Kaynak IP’ye bağlı yönlendirme ortak NAT kullanan kullanıcıları tek backend’de toplayabilir. Cookie tabanlı affinity bu sorunu azaltabilir, fakat node arızasında oturumu kurtarmaz. Stateless uygulama veya ortak oturum deposu, kapasiteyi serbest dağıtmayı kolaylaştırır. Stick-table ise uygulama veritabanının yedeği değil, trafik kararlarına yardımcı olan durum bilgisidir.
Gerçek yüksek erişilebilirlik hangi katmanları kapsar?
| Katman | Doğrulanması gereken |
|---|---|
| Backend havuzu | Hazır olmayan node’a yeni trafik gönderilmemesi |
| HAProxy node’ları | Proxy kaybında istemcinin başka giriş noktasına ulaşması |
| Ağ | VIP/VRRP veya bulut yük dengeleyici modelinin ortamda desteklenmesi |
| Uygulama verisi | Oturum ve yazma işlemlerinin arıza sonrasında tutarlılığı |
İki HAProxy node’u kurmak tek başına bütün bu koşulları karşılamaz. VRRP her bulut ağında aynı biçimde çalışmaz; ağ platformunun desteklediği IP devri veya yönetilen yük dengeleyici mekanizması gerekebilir. DNS ile geçişte önbellek süreleri ve mevcut bağlantılar hesaba katılır. Çok agresif sağlık eşikleri geçici gecikmeleri arıza sanarak sürekli node çıkarıp eklemeye neden olabilir.
Devreye alma ve yönetim API’si
Data Plane API yalnızca ticari sürüme ait bir özellik değildir; açık kaynak olarak da kullanılabilir. Yönetim arayüzünün erişimi sınırlanmalı, API ile değişen konfigürasyonun Git’teki kaynakla nasıl uzlaştırılacağı belirlenmelidir. Runtime değişikliklerinin yeniden başlatma sonrasında korunup korunmadığı ayrıca kontrol edilir.
Mono’nun değerlendirmesinde failover testi sağlıklı trafiğin sürmesi kadar hatalı işlemin nasıl raporlandığını da kapsar. Ödeme gibi tekrar edilmesi riskli istekler, uzun bağlantılar ve bakım sonrası havuza dönüş ayrı senaryolardır. Teslimat; backend envanteri, sağlık koşulları, alarm eşikleri ve işletim ekibinin uygulayabileceği bakım prosedürünü içerir.
