Web siteniz büyüdükçe sorun yalnızca “hangi web sunucusunu kuralım?” sorusu olmaktan çıkar. Trafiğin güvenli biçimde karşılanması, birden fazla uygulama sunucusuna dengeli dağıtılması, arızalı backend’in otomatik olarak devre dışı bırakılması ve yeni sürümün kesintisiz yayınlanması gerekir. Bu sayfa, web sunucusu, reverse proxy ve yük dengeleyici (load balancer) kararını tek bir üretim mimarisi içinde değerlendirir.
Web sunucusu ve load balancer ne işe yarar?
Bir web sunucusu istemciden gelen HTTP/HTTPS isteğini karşılar. Statik dosyaları sunabilir, TLS sonlandırabilir, sıkıştırma ve önbellekleme uygulayabilir veya isteği uygulama sunucusuna iletebilir. Bu son görev, reverse proxy rolüdür.
Yük dengeleyici ise aynı servisin birden fazla instance’ı arasında trafik dağıtır. İyi tasarlanmış bir katman:
- backend’leri gerçek bir HTTP veya TCP health check ile izler,
- hatalı instance’a yeni istek göndermeyi durdurur,
- TLS terminasyonu, yönlendirme ve rate limiting gibi edge politikalarını uygular,
- gözlemlenebilirlik için erişim logları ve metrikler üretir,
- gerektiğinde aktif-pasif veya aktif-aktif yüksek erişilebilirlik sağlar.
Bu nedenle “yük dengeleyici kuruldu” demek tek başına yeterli değildir. Oturumların nasıl yönetileceği, sertifikaların nasıl yenileneceği, konfigürasyonun nasıl dağıtılacağı ve arıza sonrasında trafiğin nasıl geri döneceği de tasarımın parçasıdır.
Hangi teknoloji hangi ihtiyaca uyar?
| Teknoloji | Güçlü olduğu alan | Dikkat edilmesi gereken nokta |
|---|---|---|
| Nginx | Reverse proxy, statik içerik, TLS ve HTTP yönlendirme | Karmaşık kurallarda konfigürasyon standardı gerekir |
| HAProxy | L4/L7 yük dengeleme, ACL, gelişmiş sağlık kontrolü | Web sunucusu ve uygulama sunumu için ek katman gerekebilir |
| Caddy | Otomatik HTTPS, sade konfigürasyon ve hızlı başlangıç | Özel modül/ekosistem ihtiyacı baştan doğrulanmalıdır |
| Traefik | Container ve Kubernetes servis keşfi, dinamik routing | Büyük ortamlarda erişim politikaları ve config governance şarttır |
| Kong | API gateway, kimlik doğrulama ve API politikaları | Basit reverse proxy ihtiyacında gereksiz karmaşıklık oluşturabilir |
| Apache HTTPd | Olgun modül ekosistemi ve mevcut legacy uygulamalar | Yeni kurulumlarda işletim modeli alternatiflerle kıyaslanmalıdır |
Mono’da ürün seçimini marka alışkanlığıyla değil; trafik profili, protokol, backend sayısı, SLA, ekip yetkinliği ve değişiklik sıklığıyla yapıyoruz. Reverse proxy için çoğu kurulumda Caddy’yi varsayılan seçenek olarak kullanıyoruz: otomatik HTTPS, sade konfigürasyon ve kontrollü işletim modeli, yeni servisleri güvenli biçimde yayına almayı kolaylaştırıyor. Nginx statik içerik ve HTTP reverse proxy için, HAProxy ise özel yük dengeleme ve yüksek erişilebilirlik katmanı için konumlanabilir. Kubernetes ortamında Traefik; API politikaları ağır basan yapılarda Kong değerlendirilebilir.
Üretim ortamı için tasarım kontrol listesi
1. Trafik akışını netleştirin
DNS veya CDN’den gelen isteğin hangi edge node’a ulaştığı, TLS’in nerede sonlandığı, uygulama ve veri katmanlarına hangi portlardan geçildiği dokümante edilmelidir. Gereksiz doğrudan backend erişimi firewall ile kapatılmalıdır.
2. Health check’i uygulamanın gerçeğine bağlayın
Port kontrolü, process’in çalıştığını gösterir; servisin istek kabul edebildiğini garanti etmez. Readiness endpoint’i, beklenen HTTP durum kodu, timeout, retry ve başarısızlık eşiği birlikte belirlenmelidir. Veritabanı gibi bağımlılıkları kontrol eden endpoint’ler ise zincirleme arızaya yol açmayacak şekilde tasarlanmalıdır.
3. TLS ve sertifika yenilemeyi otomatikleştirin
TLS terminasyon noktası, sertifika deposu, yenileme yöntemi ve reload davranışı yazılı olmalıdır. İki edge node’un aynı alan adı için ayrı ve kontrolsüz sertifika talep etmesi yerine ortak veya güvenli biçimde senkronize edilen bir sertifika yönetimi kullanılmalıdır.
4. Oturum ve bağlantı davranışını seçin
Stateless uygulamalarda istekler backend’ler arasında serbestçe dağıtılabilir. Stateful uygulamalarda cookie tabanlı stickiness geçici bir çözüm olabilir; kalıcı çözüm genellikle oturum verisini ortak bir store’a taşımaktır. WebSocket, uzun bağlantı, HTTP/2 ve gRPC gibi protokoller ayrıca test edilmelidir.
5. Arızayı ve geri dönüşü prova edin
Bir backend’i, edge node’u ve sertifika yenileme yolunu kontrollü biçimde devre dışı bırakarak failover denenmelidir. Alarmın üretilmesi, trafiğin sağlıklı node’a geçmesi, logların kaybolmaması ve failback’in güvenli yapılması birlikte gözlemlenmelidir.
Mono bu katmanı nasıl kurar ve işletir?
Mono, yalnızca bir config dosyası teslim etmek yerine web sunucusu ve yük dengeleyici katmanını uygulamanın yaşam döngüsüyle birlikte ele alır:
- Mevcut trafik, bağımlılıklar, darboğazlar ve tekil arıza noktaları çıkarılır.
- Nginx, HAProxy, Caddy, Traefik veya Kong için gerekçeli bir kısa liste hazırlanır.
- TLS, firewall, health check, log/metric, rate limit ve erişim politikaları standartlaştırılır.
- Staging veya tek uygulama üzerinde kontrollü geçiş yapılır; rollback planı korunur.
- Yüksek erişilebilirlik, yedekleme, yükseltme ve 7/24 izleme operasyonuna devredilir.
Bu yaklaşım, “çalışıyor” ile “arıza anında öngörülebilir biçimde çalışan” arasındaki farkı kapatır. Yeni bir proje başlatıyor, mevcut Nginx/HAProxy kurulumunuzu iyileştiriyor veya Kubernetes ingress katmanınızı sadeleştiriyorsanız, önce hedef SLA ve trafik akışınızı birlikte netleştirebiliriz.
Sık sorulan sorular
Web sunucusu ve load balancer seçimi; trafik, uygulama protokolleri ve operasyon hedefleriyle birlikte yapılmalıdır. Yukarıdaki soruların yanıtı, en sık karşılaşılan mimari kararları özetler.
Altyapınızı birlikte değerlendirelim: Mevcut topolojinizi, beklenen trafiği ve kesinti toleransınızı paylaşın; Mono ekibi size uygun web sunucusu, reverse proxy ve yük dengeleme planını çıkarsın. Görüşme planlayın veya Mono’nun DevOps hizmetlerini inceleyin.
