Skip to main content

> websocket_durumlu_bağlantı_ölçekleme_ve_pub/sub_omurgası

WebSocket Durumlu Bağlantı Ölçekleme ve Pub/Sub Omurgası

Milyonlarca kalıcı ve durumlu WebSocket TCP bağlantısı, durumsuz sunucu kümelerinde yayın (broadcast) mesajlarını kaybetmeden veya yeniden bağlanma fırtınaları yaratmadan yatayda nasıl ölçeklenir?

Stack: SOFTWARE ARCHITECTURE STACK →Staff (L6-L7)pattern

ÖZET VE TEKNİK CEVAP

Kalıcı WebSocket bağlantılarını hafif ağ geçidi podlarında sonlandırıp, mesaj dağıtımını dağıtık bir Pub/Sub omurgası (Redis / NATS) üzerinden yürüterek, işletim sistemi soket belleğini optimize edip istemci yeniden bağlanmalarını rastgele gecikmeli (jitter) üstel geri çekilmeyle kademelendirerek.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Milisaniyeler içinde tamamlanan durumsuz HTTP'nin aksine, WebSocket bağlantıları durumlu TCP soketleri olarak süresiz açık kalır. Kullanıcı A Pod 1'e, Kullanıcı B ise Pod 2'ye bağlıysa, Pod 1 doğrudan B'ye mesaj iletemez. Yatay ölçekleme dağıtık bir Pub/Sub omurgası (Redis Pub/Sub, NATS veya Kafka) gerektirir. Pod 1 bir mesaj aldığında bunu omurga kanalına yayımlar; o kanalı dinleyen tüm podlar olayı alıp kendi yerel aktif WebSocket istemcilerine iletir. İşletim sistemi çekirdek optimizasyonu (`sysctl fs.file-max`, `net.ipv4.tcp_rmem`) boşta duran soket başına RAM tüketimini 50KB'tan 4KB'ın altına indirerek tek bir 16GB sunucuda 500.000 eşzamanlı soket tutmayı mümkün kılar.

2. Doğru Kullanım Senaryosu

Gerçek zamanlı ortak çalışma araçları (Figma benzeri), çok oyunculu oyunlar, borsa canlı emir defterleri, canlı yayın sohbetleri ve anlık bildirim ağ geçitleri.

3. Prodüksiyon Arıza Modları

1) EMFILE Limit Çöküşü: Linux varsayılan `1024` dosya tanıtıcısı sınırına takılıp tüm yeni bağlantıların anında reddedilmesi; 2) Yeniden Bağlanma Fırtınası (Thundering Herd): Yeni sürüm dağıtımında 500.000 istemcinin aynı anda kopup 1 saniye içinde tekrar bağlanarak kimlik doğrulama veritabanını çökertmesi; 3) Redis Bellek Taşması: Yavaş podların Redis çıktı tamponlarını şişirip merkezi Redis'i OOM ile öldürmesi.

4. Teşhis ve Telemetri Sinyalleri

Düğüm başına açık TCP soket sayısı (`ss -s`), çekirdek soket bellek kullanımı (`netstat -m`), Redis pub/sub mesaj iletim gecikmesi ve dağıtım anındaki istemci yeniden bağlanma sıçramaları.

5. Önleme ve Mimari Bariyerler

Linux sistem limitlerini yükseltin (`ulimit -n 1048576`); tüm istemci SDK'larında rastgele gecikmeli (full jitter) üstel geri çekilmeyi zorunlu kılın; aşamalı bağlantı tahliyesi (dakikada %5 koparma) yapan kademeli dağıtımlar uygulayın ve 30 saniyelik kalp atışı (ping/pong) ile ölü soketleri temizleyin.

6. Mimari Ödünleşimler (Trade-offs)

Mikrosaniyeler seviyesinde gerçek zamanlı çift yönlü iletişim sağlar; buna karşılık durumlu sunucu filoları yönetme, zorlu kademeli güncelleme tahliyeleri ve pub/sub omurga altyapı maliyeti getirir.

Vaka İncelemesi (TinyCTO Örneği)

TinyCTO Vaka 094: Canlı sohbet servisine atılan bir yama, 800.000 WebSocket kullanıcısını aynı anda kopardı. 800.000 istemci aynı saniyede `/auth` ucuna yüklenerek PostgreSQL kullanıcı veritabanını 40 dakika kilitledi. İstemci koduna 0-60 saniyelik rastgele jitter eklenmesi ve Envoy aşamalı bağlantı tahliyesi kurulması sonraki tüm kesintileri tamamen engelledi.

İnteraktif Konsept Alıştırmaları

3 Alıştırma
Q1

WebSocket bağlantılarını yatayda ölçeklemek için neden Redis veya NATS gibi bir Pub/Sub omurgası gerekir?

Çünkü kullanıcılar farklı fiziksel sunucu podlarına dağılmıştır. Bir odaya mesaj atıldığında, omurga mesajı tüm podlara yayımlar ve her pod mesajı kendi üzerindeki yerel soketlere iletir.
Q2

WebSocket mimarilerinde 'Yeniden Bağlanma Fırtınası' (Thundering Herd) nedir ve nasıl önlenir?

Sunucu yeniden başladığında kopan binlerce kullanıcının aynı anda bağlanıp kimlik doğrulamaya çalışmasıdır; istemci SDK'larına rastgele gecikmeli (full jitter) üstel geri çekilme konularak önlenir.
Q3

Varsayılan Linux `ulimit -n` 1024 sınırı WebSocket sunucuları için neden ölümcüldür?

Açık olan her TCP soketi bir dosya tanıtıcısı (file descriptor) tüketir. 1.024 eşzamanlı bağlantıda sunucu `EMFILE: Too many open files` hatası vererek tüm yeni bağlantıları reddeder.

WebSocket Durumlu Bağlantı Ölçekleme ve Pub/Sub Omurgası — Sıkça Sorulan Sorular

Server-Sent Events (SSE) ile WebSocket nasıl karşılaştırılır?

SSE standart HTTP/2 üzerinde tek yönlüdür (yalnızca sunucudan istemciye); bu da onu daha basit, kolay dengelenir ve önbellek dostu yapar. WebSocket ise çift yönlüdür ve istemciden sunucuya anlık veri iletimi için gereklidir.

WebSocket sunucularında kullanıcı sohbetlerini kesmeden kademeli dağıtım (rolling update) nasıl yapılır?

Bağlantı tahliyesi (connection draining) kullanın: eski podun yeni bağlantı almasını durdurun, dakikada %5 istemciye 'yakında_tekrar_bağlan' sinyali gönderin ve podu kapatmadan önce yeni podlara geçmelerini bekleyin.

WebSocket sağlığı için Kalp Atışı (Ping/Pong) sinyalleri neden kritiktir?

Ağ değiştiren veya tünelden geçen mobil cihazlar 'yarı açık' yetim soketler bırakır. Periyodik ping/pong sinyalleri bu sessiz kopmaları yakalar ve 30-60 saniye içinde işletim sistemi belleğini geri kazanır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸WebSocket protokolü (RFC 6455), standart bir HTTP/1.1 bağlantısını `Upgrade: websocket` başlığıyla tam çift yönlü bir TCP soketine yükseltir.
  • ▸WebSocket sunucu filolarını ölçeklerken birincil fiziksel darboğaz neredeyse her zaman CPU değil, bellek (RAM) kapasitesidir.

Yaygın Yanılgılar

  • ✗Her şey için WebSocket kullanılması gerektiğini düşünmek; tek yönlü veri akışlarında (borsa fiyatları veya yapay zeka metin akışı) HTTP/2 Server-Sent Events (SSE) çok daha basit ve dayanıklıdır.

Karar Kılavuzu & Önceliklendirme

Gerçek çift yönlü 50 ms altı etkileşim gerektiğinde (oyun, ortak çizim tahtası) WebSocket kullanın; tek yönlü veri akışlarında Server-Sent Events (SSE) tercih edin.

Doğrulanmış Kaynaklar & Referanslar