Yük Dengeleyiciler Neden Hâlâ Çalışmayan Sunuculara Trafik Gönderiyor?

Bir hizmetin sağlıklı olduğu rapor edilse de, yük dengeleyicinin bu bilgiye güvenerek çalışmayan bir arka uç sunucusuna istek göndermesi, kullanıcılar için zaman aşımı ve kötü bir deneyimle sonuçlanabilir. Bu durum, sistemin arızayı tespit etme ve tepki verme hızını doğrudan etkiler. Sağlık kontrolü basit gibi görünse de, bu kontrolün mekanizması ve kim tarafından yapıldığı, sistemin hata tespitindeki doğruluğunu ve hızını belirler.

Yük dengeleme temelde iki ana modelde incelenir: sunucu tarafı (server-side) ve istemci tarafı (client-side). Sunucu tarafı yük dengelemede, istemciler ile arka uç sunucuları arasında HAProxy, NGINX veya AWS ALB gibi özel bir proxy bulunur. İstemciler sadece bu yük dengeleyicinin adresini bilirken, yük dengeleyici arka uç havuzunun sağlığını takip eder ve trafiği yönlendirir. Sağlık kontrolleri tamamen yük dengeleyici tarafından yönetilir; belirli aralıklarla (örn. 5 saniyede bir) TCP bağlantısı veya /health uç noktasına HTTP isteği gibi periyodik yoklamalar yapılır. Bu kontroller, bir sunucunun sağlıklı kabul edilmesi için ardışık başarı (rise threshold) ve sağlıksız kabul edilmesi için ardışık hata (fall threshold) eşikleri gibi parametrelerle yapılandırılır. Bu eşikler, sunucuların sürekli olarak rotasyona girip çıkmasını (flapping) önlemek içindir.

İstemci tarafı yük dengelemede ise yönlendirme zekası doğrudan istemciye taşınır. Her istemci, bir hizmet kaydından (service registry) alınan mevcut arka uç örneklerinin yerel bir görünümünü tutar ve her istek için kendi yönlendirme kararını verir. gRPC'nin yerleşik yük dengelemesi, Netflix Ribbon ve LinkedIn'in D2'si bu şekilde çalışır. Bu modelde istek yolunda bir proxy bulunmaz, ancak hizmet kaydı güncellemeleri veya DNS yayılımı nedeniyle gecikmeler yaşanabilir. Her iki modelin de sağlık kontrolü yaklaşımları, sistemin arızalara ne kadar hızlı ve doğru tepki vereceğini belirleyen kritik faktörlerdir.