WebSocket Bağlantılarında Performans ve Yük Dengeleme

Gerçek zamanlı bir uygulama ilk birkaç yüz kullanıcıda kusursuz çalışıp trafik büyüdüğünde neden bir anda bağlantı kopmaları, geciken mesajlar ve dengesiz sunucu yükleri üretir? On yıllık backend ve dağıtık sistem tecrübemde WebSocket problemlerinin çoğunun protokolün kendisinden değil, bağlantıların nasıl dağıtıldığı, durum bilgisinin nerede tutulduğu ve istemcilerin hata anında nasıl yeniden bağlandığı gibi mimari kararlardan çıktığını gördüm. WebSocket Bağlantılarında Performans ve Yük Dengeleme konusu bu yüzden yalnızca bir reverse proxy ayarından ibaret değildir. İşletim sistemi limitlerinden connection draining yaklaşımına, Redis Pub/Sub kullanımından Kubernetes autoscaling metriklerine kadar bütün zinciri birlikte düşünmek gerekir. Bu rehberde WebSocket bağlantılarında performans optimizasyonu nasıl yapılır, WebSocket için load balancing nasıl yapılandırılır ve production ortamında hangi metriklerin gerçekten önemli olduğu sorularına uygulanabilir cevaplar bulacaksınız.

Özellikle yüksek eş zamanlı bağlantı sayılarında klasik HTTP ölçekleme alışkanlıkları yetersiz kalabilir. Bir WebSocket bağlantısı saniyeler yerine saatler boyunca aynı backend üzerinde kalabildiği için sadece CPU yüzdesine veya request sayısına bakarak kapasite kararı vermek çoğu zaman yanıltıcıdır. WebSocket yük dengelemede sticky session ve Redis pub sub nasıl kullanılır sorusu da bu noktada önem kazanır, çünkü bağlantı ile kullanıcı durumu farklı katmanlarda yönetilebilir. Nginx Kubernetes WebSocket load balancing ve autoscaling yapılandırması yapılırken active connections, event-loop lag, message rate ve connection skew gibi ölçümler birlikte değerlendirilmelidir. Rehberin sonunda kurumsal WebSocket performans ve yük dengeleme optimizasyon hizmeti veya WebSocket ve sunucu performans danışmanlığı yakınımda gibi ihtiyaçlarda hangi teknik başlıkların mutlaka incelenmesi gerektiğini de netleştirmiş olacağız.

WebSocket Nedir?

WebSocket, istemci ile sunucu arasında uzun süre açık kalabilen ve iki yönlü veri aktarımına izin veren bir iletişim protokolüdür. Klasik HTTP modelindeki her işlem için yeni request oluşturma yaklaşımının yerine, bir kez kurulan bağlantı üzerinden çok sayıda mesaj taşınabilir. Bu özellik chat, canlı veri, oyun ve ortak çalışma uygulamalarında düşük gecikme elde etmeyi kolaylaştırır. WebSocket kullanmak tek başına sistemi hızlı yapmaz, çünkü açık bağlantıların memory, file descriptor, network ve backend kapasitesi üzerinde sürekli maliyeti vardır. Bu yüzden protokolü anlamak kadar bağlantının yaşam döngüsünü ve failure davranışını tasarlamak da önemlidir.

WebSocket Hangi Problemi Çözer?

WebSocket, istemcinin sürekli olarak yeni HTTP isteği göndererek sunucuda yeni veri olup olmadığını kontrol etme ihtiyacını azaltır. Sunucu yeni bir olay olduğunda veriyi açık bağlantı üzerinden doğrudan istemciye gönderebilir. Bu sayede gerçek zamanlı bildirim, fiyat güncellemesi veya kullanıcı mesajı gibi olaylarda polling gecikmesi ortadan kalkar. Ayrıca her mesaj için tekrar eden HTTP header maliyeti azalır ve bağlantı kurulumu sürekli tekrarlanmaz. Ancak açık bağlantıların düzgün yönetilmediği sistemlerde polling maliyetinin yerini connection management ve fan-out maliyeti alabilir.

HTTP ile WebSocket Arasındaki Fark

HTTP çoğunlukla istemcinin request gönderdiği ve sunucunun response döndürdüğü kısa ömürlü işlem modeline dayanır. WebSocket ise handshake sonrasında uzun süre açık kalan iki yönlü bir kanal oluşturur. HTTP load balancing çoğu zaman her request için backend seçebilirken WebSocket'te bağlantı kurulduktan sonra trafik aynı backend üzerinden devam eder. Bu fark kapasite planlamasında connection sayısını önemli bir kaynak metriği haline getirir. Bu nedenle normal API sunucusu için iyi çalışan load balancing ayarı WebSocket gateway için aynı sonucu vermeyebilir.

WebSocket'in Full-Duplex Yapısı

Full-duplex iletişim, istemci ve sunucunun aynı bağlantı üzerinden birbirinden bağımsız biçimde veri gönderebilmesi anlamına gelir. Kullanıcının yeni request başlatmasını beklemeden sunucu anlık mesaj gönderebilir. İstemci de aynı bağlantı üzerinde komut, event veya acknowledgement mesajı iletebilir. Bu yapı özellikle chat ve oyun gibi iki yönlü etkileşimlerde önemli bir gecikme avantajı sağlar. Buna karşılık mesaj sıralaması, backpressure ve slow consumer kontrolü uygulama protokolünün açık parçası olmalıdır.

Uzun Ömürlü Bağlantı Nedir?

Uzun ömürlü bağlantı birkaç saniye yerine dakikalar veya saatler boyunca açık tutulabilen network bağlantısıdır. WebSocket sunucusu bu süre boyunca bağlantıya ait socket, buffer ve uygulama state'i gibi kaynakları yönetir. Bağlantı aktif mesaj üretmese bile load balancer, firewall veya NAT timeout değerleri nedeniyle kopabilir. Bu yüzden heartbeat ve idle timeout ayarları bağlantı yaşam döngüsünde önemli rol oynar. Production tasarımında ortalama bağlantı süresinin yanı sıra maksimum connection lifetime da kapasite ve deployment planına dahil edilmelidir.

WebSocket Hangi Uygulamalarda Kullanılır?

WebSocket en çok düşük gecikmeli ve sürekli veri akışına ihtiyaç duyan uygulamalarda kullanılır. Her gerçek zamanlı özellik için WebSocket zorunlu değildir, çünkü bazı server-to-client senaryolarında SSE daha basit olabilir. İki yönlü etkileşimin yoğun olduğu uygulamalarda ise WebSocket doğal bir seçimdir. Kullanım alanını değerlendirirken mesaj sıklığı, payload büyüklüğü, connection süresi ve kullanıcı eş zamanlılığı birlikte düşünülmelidir. Mimari karar sadece protokol desteğine değil, operasyonel gereksinimlere de dayanmalıdır.

Chat

Chat uygulamalarında kullanıcıların mesajları düşük gecikmeyle karşı tarafa iletilmelidir. WebSocket bu iletişimi tek açık bağlantı üzerinden gerçekleştirebilir. Birden fazla backend kullanıldığında mesajın alıcı bağlantısının hangi node üzerinde bulunduğu bilinmelidir. Bu noktada connection registry ve Pub/Sub katmanı devreye girer. Chat mimarisinde delivery acknowledgement, reconnect ve kaçırılan mesajların replay edilmesi de protokol kadar önemlidir.

Oyun

Çevrim içi oyunlarda konum, skor ve oturum olayları sık güncellenebilir. WebSocket özellikle orta frekanslı gerçek zamanlı oyun iletişiminde kullanışlı bir taşıma katmanı sunar. Çok yüksek frekanslı bazı oyunlarda farklı transport tercihleri gerekebilir, fakat lobby ve oyun içi event akışında WebSocket pratik olabilir. Oyun sunucularında jitter ve tail latency ortalama latency kadar önemlidir. Bu yüzden connection distribution ve region affinity dikkatle yönetilmelidir.

Finansal Veri

Finansal veri akışlarında fiyat, emir defteri veya piyasa olayı sürekli güncellenebilir. WebSocket istemcilerin değişiklikleri polling yapmadan almasını sağlar. Çok büyük subscriber sayılarında aynı mesajın binlerce bağlantıya fan-out edilmesi ciddi network maliyeti oluşturabilir. Bu nedenle topic bazlı subscription ve binary payload gibi yöntemler değerlendirilebilir. Message ordering ve sequence number kullanımı da veri tutarlılığı açısından önemlidir.

Bildirim Sistemleri

Bildirim sistemlerinde WebSocket kullanıcıya yeni olayları hızlı biçimde ulaştırabilir. E-posta veya mobil push gibi diğer kanallarla birlikte kullanılabilir. Kullanıcı birden fazla cihazdan bağlıysa connection registry her cihazı ayrı takip etmelidir. Kullanıcı offline olduğunda mesajın kalıcı bir queue veya database üzerinde tutulması gerekebilir. Bu nedenle WebSocket transport katmanı ile durable notification sistemi birbirinden ayrılmalıdır.

Collaborative Applications

Ortak çalışma uygulamalarında bir kullanıcının yaptığı değişikliğin diğer kullanıcı ekranlarına kısa sürede ulaşması gerekir. WebSocket belge düzenleme, cursor bilgisi veya presence event'leri için kullanılabilir. Aynı dokümana bağlı yüzlerce kullanıcı olduğunda room bazlı fan-out önemli hale gelir. Conflict resolution ve versioning gibi konular transport katmanından ayrı çözülmelidir. WebSocket yalnızca değişikliklerin hızlı taşınmasını sağlar, ortak state modelini kendiliğinden çözmez.

WebSocket Bağlantısı Nasıl Kurulur?

WebSocket bağlantısı genellikle normal bir HTTP isteğiyle başlar ve daha sonra protokol yükseltmesi yapılır. Bu yaklaşım mevcut reverse proxy ve TLS altyapılarından yararlanmayı kolaylaştırır. İstemci ve sunucu gerekli header değerlerinde anlaşırsa bağlantı HTTP request-response modelinden WebSocket frame modeline geçer. Load balancer'ın bu upgrade işlemini doğru iletmesi gerekir. Handshake başarılı olduktan sonra bağlantı kapanana kadar aynı TCP akışı üzerinde mesaj alışverişi devam eder.

HTTP Handshake

İstemci WebSocket bağlantısı başlatırken sunucuya özel header'lar içeren bir HTTP isteği gönderir. Bu istek bağlantının WebSocket protokolüne yükseltilmesini talep eder. Sunucu gerekli koşullar sağlanıyorsa başarılı bir switching protocols yanıtı döndürür. Authentication ve origin kontrolü çoğu mimaride bu aşamada uygulanabilir. Handshake latency ayrı ölçülmelidir, çünkü yoğun bağlantı açılışlarında TLS ve authentication maliyeti önemli hale gelebilir.

Protocol Upgrade

Protocol upgrade, mevcut HTTP bağlantısının WebSocket iletişimine geçirilmesini ifade eder. Reverse proxy bu geçiş sırasında ilgili header'ları backend'e doğru biçimde aktarmalıdır. Yanlış proxy yapılandırması bağlantının normal HTTP request gibi sonlandırılmasına yol açabilir. Production ortamında upgrade başarısızlık oranı metric olarak izlenebilir. Özellikle yeni load balancer veya ingress değişikliklerinde handshake testleri deployment kontrolünün parçası olmalıdır.

Upgrade Header

Upgrade header istemcinin bağlantıyı farklı bir protokole geçirmek istediğini belirtir. WebSocket proxy yapılandırmalarında bu header'ın upstream'e iletilmesi gerekir. Bazı reverse proxy çözümleri bunu otomatik yapmaz ve açık yapılandırma ister. Header eksik olduğunda backend normal HTTP request gördüğünü düşünebilir. Sorun yaşandığında ilk kontrol noktalarından biri handshake request ve response header'ları olmalıdır.

Connection Header

Connection header bağlantıya özgü upgrade davranışının kullanılacağını belirtir. Reverse proxy katmanında doğru değerin backend'e aktarılması önemlidir. Header yönetimi proxy ürününe ve HTTP sürümüne göre farklı olabilir. Geliştirme ortamında doğrudan backend'e bağlanırken çalışan WebSocket'in proxy arkasında bozulmasının nedenlerinden biri bu fark olabilir. Production debugging sırasında proxy access log ve backend handshake log birlikte incelenmelidir.

HTTP Bağlantısından WebSocket'e Geçiş

Handshake tamamlandığında aynı TCP bağlantısı artık WebSocket frame'lerini taşımaya başlar. Bundan sonra klasik HTTP response döngüsü yerine mesaj tabanlı iletişim devam eder. Load balancer bağlantıyı seçilen backend'e tunnel olarak iletir. Yeni mesajlar için yeni backend seçimi yapılmaz. Bu davranış connection distribution problemini request distribution probleminden farklı hale getirir.

ws:// ve wss:// Arasındaki Fark

ws:// şifrelenmemiş WebSocket iletişimini, wss:// ise TLS üzerinden şifrelenmiş bağlantıyı ifade eder. İnternet üzerinden kullanılan production sistemlerinde wss:// tercih edilmelidir. TLS termination edge load balancer veya uygulama sunucusunda yapılabilir. TLS handshake yoğun reconnect dönemlerinde CPU ve latency maliyeti oluşturabilir. Bu nedenle connection reuse, reconnect backoff ve edge termination stratejisi birlikte değerlendirilmelidir.

Handshake Tamamlandıktan Sonra Trafik Nasıl İlerler?

Handshake sonrasında istemci ve sunucu WebSocket frame'leri gönderir. Reverse proxy veya load balancer bağlantıyı aynı backend'e iletmeye devam eder. Trafik miktarı bağlantı başına çok farklı olabilir, çünkü bazı kullanıcılar sessizken bazıları saniyede birçok mesaj gönderebilir. Bu nedenle yalnızca connection sayısı backend yükünü tam anlatmaz. Messages per second ve bytes per second metrikleri connection count ile birlikte izlenmelidir.

WebSocket ile Normal HTTP Yük Dengeleme Arasındaki Fark

HTTP ve WebSocket yük dengeleme arasındaki temel fark backend seçiminin sıklığıdır. HTTP'de her request yeni seçim fırsatı yaratabilirken WebSocket'te seçim çoğunlukla bağlantı kurulurken yapılır. Bir backend üzerine fazla uzun bağlantı düştüğünde yeni pod eklemek mevcut bağlantıları otomatik taşımaz. Bu nedenle zaman içinde connection skew oluşabilir. WebSocket için load balancing nasıl yapılandırılır sorusunun cevabı connection yaşam süresi ve trafik yoğunluğu hesaba katılmadan verilemez.

Request-Based HTTP

Request-based HTTP trafiğinde load balancer her gelen isteği uygun bir backend'e yönlendirebilir. Kullanıcı arka arkaya yaptığı iki istekte farklı sunuculara gidebilir. Bu yapı kısa işlemlerde yükün zaman içinde doğal biçimde dağılmasını kolaylaştırır. Backend kapasitesi CPU, request rate ve latency üzerinden ölçülebilir. Stateful session kullanılıyorsa ayrıca affinity ihtiyacı doğabilir.

Connection-Based WebSocket

WebSocket'te load balancer bağlantı başlangıcında backend seçer. Bağlantı açık olduğu sürece aynı backend üzerinde kalır. Bu nedenle kısa süreli trafik dalgaları uzun süreli connection dağılımı yaratabilir. Yeni sunucu eklenmesi sadece yeni bağlantıları etkiler. Capacity planning bu kalıcılık etkisini hesaba katmalıdır.

Uzun Süre Aynı Backend'e Bağlı Kalma

Bir WebSocket kullanıcısı saatler boyunca aynı backend'e bağlı kalabilir. Bu süre içinde cluster'a yeni node eklenmiş olsa bile bağlantı kendiliğinden taşınmaz. Eski node'lar yüksek connection sayısı taşırken yeni node'lar boş kalabilir. Controlled reconnect veya maximum connection lifetime bu dengesizliği zaman içinde azaltabilir. Bu mekanizmalar kullanıcı deneyimini bozmayacak şekilde uygulanmalıdır.

Backend Kapasitesinin Connection Bazında Tüketilmesi

Her açık connection socket ve belirli miktarda memory tüketir. Uygulamanın tuttuğu subscription, authentication ve send queue bilgisi maliyeti daha da artırabilir. CPU düşük olsa bile backend file descriptor veya memory sınırına yaklaşabilir. Bu nedenle autoscaling sadece CPU metriğine dayanmamalıdır. Active connections ve memory per connection temel capacity metriklerindendir.

Connection Distribution Neden Kritik?

Connection distribution node'lar arasında çok dengesizse bazı sunucular kaynak sınırına ulaşırken diğerleri boş kalabilir. Ortalama connection count bu problemi gizleyebilir. Backend başına connection sayısı ve standard deviation benzeri dağılım metrikleri faydalıdır. Connection başına trafik de farklı olabileceği için hot backend detection yalnızca adet üzerinden yapılmamalıdır. Gerçek yük connection sayısı ile message ve byte hacminin birleşimidir.

WebSocket Load Balancer Nasıl Çalışır?

WebSocket load balancer istemciden gelen handshake bağlantısını karşılar ve uygun backend'i seçer. Backend WebSocket upgrade yanıtını kabul ettiğinde load balancer iki uç arasında uzun ömürlü bir tunnel sürdürür. Bağlantı kapanana kadar mesajlar aynı backend'e gider. Bu yüzden load balancer'ın idle timeout ve connection limit ayarları uygulama kadar önemlidir. Load balancer performans sorunu kullanıcı tarafında kopma, reconnect veya yüksek handshake latency olarak görülebilir.

Client Connection

İstemci ilk olarak load balancer'ın public endpoint'ine TCP ve gerekiyorsa TLS bağlantısı açar. Ardından WebSocket handshake isteğini gönderir. Client IP, cookie veya başka routing bilgileri backend seçimini etkileyebilir. Bağlantı açılış hızı çok yüksekse edge katmanı connection rate sınırına yaklaşabilir. Bu nedenle connection rate ayrı bir kapasite metriği olarak izlenmelidir.

Load Balancer

Load balancer client bağlantılarını backend grubuna dağıtan ara katmandır. TLS termination, health check, timeout ve routing görevlerini üstlenebilir. WebSocket desteği yalnızca upgrade yapabilmek değil, uzun süreli bağlantıları verimli biçimde koruyabilmek anlamına gelir. File descriptor ve connection table kapasitesi load balancer için de önemlidir. High availability tasarımında load balancer'ın kendisi tek hata noktası olmamalıdır.

Backend Selection

Backend selection algoritması yeni bağlantının hangi sunucuya gideceğini belirler. Round robin basit dağılım sağlarken least connections mevcut bağlantı yükünü dikkate alabilir. Weighted algoritmalar farklı kapasitedeki node'lar için kullanılabilir. Seçim sırasında active connection dışında CPU veya queue depth gibi sinyaller de değerlendirilebilir. Özellikle heterojen cluster yapılarında capacity-aware routing daha dengeli sonuç verebilir.

WebSocket Upgrade

Seçilen backend handshake isteğini alır ve upgrade işlemini tamamlar. Load balancer gerekli header ve bağlantı durumunu korur. Upgrade başarısız olursa client reconnect mekanizması devreye girebilir. Çok sık retry uygulamak failure anında ek yük oluşturur. Bu nedenle handshake error rate ile reconnect rate birlikte gözlemlenmelidir.

Persistent Tunnel

Upgrade sonrasında load balancer iki uç arasında kalıcı bir bağlantı tüneli oluşturur. Mesajlar bu tunnel üzerinden iki yönde iletilir. Connection uzun süre açık olduğu için timeout ayarlarının WebSocket kullanımına uygun olması gerekir. Proxy buffering davranışı da latency üzerinde etkili olabilir. Tunnel sayısı arttıkça load balancer connection kapasitesi dikkatle izlenmelidir.

Connection Kapanana Kadar Backend Affinity

Aktif WebSocket bağlantısı teknik olarak seçildiği backend'e bağlı kalır. Bu durum bağlantı yaşam süresi boyunca doğal bir affinity oluşturur. Sticky session kavramı daha çok reconnect sonrasında aynı backend'e dönmenin gerekip gerekmediğiyle ilgilidir. State harici sistemde tutuluyorsa reconnect sonrası farklı backend'e gitmek sorun olmayabilir. Stateless gateway tasarımı bu yüzden yatay ölçeklemeyi kolaylaştırır.

WebSocket İçin Load Balancing Algoritmaları

WebSocket için load balancing algoritması seçerken uzun bağlantıların cluster üzerinde nasıl biriktiğini düşünmek gerekir. Round robin bağlantı açılışlarında eşit dağılım sağlayabilir, fakat connection lifetime farkları zamanla dengesizlik oluşturabilir. Least connections güncel bağlantı sayısını dikkate aldığı için WebSocket sistemlerinde sık tercih edilen bir yaklaşımdır. Yine de connection sayısı tek başına trafik yoğunluğunu göstermediğinden daha gelişmiş kapasite sinyalleri gerekebilir. İyi seçim uygulamanın connection süresi, message rate ve backend kapasitesine göre yapılmalıdır.

Round Robin

Round robin yeni bağlantıları sırayla backend'lere dağıtır. Kurulumu basittir ve benzer kapasitedeki sunucularda başlangıçta dengeli sonuç verir. Bağlantı süreleri birbirine yakınsa zaman içinde de makul dağılım korunabilir. Ancak bazı bağlantılar dakikalar, bazıları saatler sürüyorsa node'lar arasında skew oluşabilir. Bu nedenle uzun ömürlü ve değişken connection sürelerinde metriklerle doğrulanmalıdır.

Avantajları

Round robin kolay anlaşılır ve düşük yönetim maliyetine sahiptir. Backend durumunu sürekli hesaplamadan deterministik bir dağılım yapabilir. Benzer donanımlı node'larda bağlantı açılışı için iyi bir başlangıç noktasıdır. Trafik düzenliyse ek routing mekanizmasına ihtiyaç duyulmaz. Basitlik operasyon sırasında davranışı yorumlamayı da kolaylaştırır.

Uzun Bağlantılardaki Dezavantajları

Bağlantıların yaşam süresi farklı olduğunda round robin aktif yükü bilmeden seçim yapar. Önceki bağlantılar bir backend üzerinde uzun süre kalabilir. Yeni bağlantıların sırayla dağıtılması mevcut dengesizliği hemen düzeltemez. Backend'lerden biri diğerine göre daha fazla message traffic taşıyabilir. Bu durumda least connections veya capacity-aware yaklaşım daha iyi olabilir.

Least Connections

Least connections algoritması yeni bağlantıyı o anda en az aktif bağlantıya sahip backend'e yönlendirmeyi amaçlar. Uzun ömürlü connection'larda mevcut dağılımı hesaba kattığı için round robin'e göre daha dengeli olabilir. Bununla birlikte tüm bağlantıların eşit kaynak tükettiği varsayımı taşır. Birkaç yoğun connection binlerce sessiz connection'dan daha fazla CPU kullanabilir. Bu nedenle message rate ile desteklenen gelişmiş metric kullanımı bazı sistemlerde daha doğru sonuç verir.

WebSocket İçin Neden Uygundur?

WebSocket bağlantıları uzun süre aynı backend üzerinde kaldığı için mevcut connection sayısı önemli bir kapasite sinyalidir. Least connections yeni bağlantıları daha boş node'lara yönlendirerek skew'u azaltabilir. Scale-out sonrasında yeni pod'ların daha hızlı dolmasına da yardımcı olabilir. Ancak mevcut bağlantılar yine taşınmaz. Bu nedenle algoritma natural rebalancing sürecini hızlandırır, tamamen çözmez.

Weighted Least Connections

Weighted least connections backend'lerin farklı kapasitelere sahip olduğu cluster'larda kullanışlıdır. Daha güçlü node daha fazla bağlantı kabul edecek şekilde ağırlıklandırılabilir. Ağırlık değerleri CPU çekirdeği, memory veya ölçülmüş connection kapasitesine göre belirlenebilir. Statik ağırlıklar workload değiştiğinde yetersiz kalabilir. Capacity test sonuçlarıyla periyodik olarak güncellenmesi daha sağlıklı olur.

IP Hash

IP hash istemci IP'sinden backend seçimi yapar. Reconnect sonrasında aynı client'ın aynı backend'e gitme olasılığını artırabilir. NAT arkasındaki çok sayıda kullanıcı aynı IP ile göründüğünde ciddi dengesizlik oluşabilir. Mobil ağlarda IP sık değişebildiği için affinity güvenilir olmayabilir. Bu nedenle IP hash genellikle state yönetimi problemi için kalıcı çözüm olarak görülmemelidir.

Consistent Hashing

Consistent hashing client veya tenant gibi bir anahtarı backend dağılımına eşleyebilir. Backend eklendiğinde veya çıkarıldığında anahtarların yalnızca bir bölümü farklı node'a taşınır. Belirli tenant veya room state'ini aynı node üzerinde tutmak isteyen sistemlerde kullanılabilir. Ancak node kaybında yine state recovery mekanizması gerekir. Shared state kullanan stateless mimaride consistent hashing zorunlu değildir.

Capacity-Aware Routing

Capacity-aware routing sadece connection sayısını değil backend'in gerçek kapasite sinyallerini de dikkate alır. Event-loop lag, send queue, CPU, memory ve network throughput gibi ölçümler kullanılabilir. Bu yaklaşım farklı trafik profiline sahip bağlantılarda daha doğru seçim yapabilir. Routing algoritmasının fazla sık değişmesi kararsız davranış oluşturabilir. Bu nedenle sinyaller smoothing ve güvenli eşiklerle kullanılmalıdır.

Hangi Algoritma Hangi Senaryoda Seçilmeli?

Benzer connection süreleri ve homojen sunucular için round robin yeterli olabilir. Uzun ve değişken bağlantı sürelerinde least connections genellikle daha iyi başlangıç noktasıdır. Farklı backend kapasiteleri varsa weighted yaklaşım değerlendirilebilir. Tenant veya belirli anahtar bazlı affinity gerekiyorsa consistent hashing kullanılabilir. Çok yüksek ölçekli sistemlerde active connection, message traffic ve queue durumunu birlikte değerlendiren capacity-aware routing daha doğru sonuç verir.

Sticky Session WebSocket İçin Gerekli midir?

Sticky session çoğu zaman WebSocket tasarımında yanlış anlaşılan konulardan biridir. Aktif WebSocket bağlantısı zaten bağlantı kapanana kadar aynı backend üzerinde kalır. Asıl soru reconnect olduğunda istemcinin yeniden aynı backend'e gitmesinin gerekip gerekmediğidir. Uygulama state'i yalnızca sunucu memory'sinde tutuluyorsa affinity gerekebilir, fakat bu mimari yatay ölçekleme ve failover işlemlerini zorlaştırır. Shared state ve distributed messaging kullanıldığında sticky session ihtiyacı büyük ölçüde azalabilir.

Session Affinity Nedir?

Session affinity aynı kullanıcı veya istemcinin ardışık bağlantılarında aynı backend'e yönlendirilmesini amaçlar. Cookie, IP veya hash tabanlı yöntemlerle uygulanabilir. Klasik HTTP session state modellerinde sık kullanılır. WebSocket'te aktif bağlantı zaten tek backend'de kaldığı için affinity daha çok reconnect davranışında önemlidir. Session state harici bir sistemde tutuluyorsa aynı backend'e dönmek gerekmeyebilir.

WebSocket Bağlantısı Zaten Sticky midir?

Evet, aktif WebSocket bağlantısı teknik olarak seçilmiş backend'e bağlıdır. Load balancer her frame için yeni backend seçmez. Bu nedenle bağlantı süresince ayrıca sticky session mekanizmasına ihtiyaç duyulmaz. Bağlantı kopup yeniden kurulduğunda backend seçimi yeniden yapılır. Tasarımın önemli kısmı bu reconnect sonrasında state'in korunup korunmayacağıdır.

Reconnect Sonrasında Affinity

Reconnect sonrasında aynı backend'e gitme ihtiyacı uygulama state modeline bağlıdır. Eğer subscription veya user session yalnızca node memory'sindeyse farklı backend ek işlem gerektirebilir. Shared connection metadata ve authentication sistemi kullanılırsa yeni node session'ı yeniden oluşturabilir. Bu yaklaşım failure recovery sürecini kolaylaştırır. Reconnect protokolünde son sequence ID veya room listesi gibi bilgiler istemciden yeniden gönderilebilir.

IP Hash

IP hash reconnect sırasında benzer backend seçimi sağlayabilir. Ancak mobil kullanıcıların IP adresi değişebilir. Büyük NAT sistemlerinde binlerce kullanıcı aynı IP üzerinden geldiği için yük tek backend üzerinde toplanabilir. Bu nedenle WebSocket load balancing için güvenilir affinity mekanizması sayılmaz. Kullanılacaksa connection skew metric'i mutlaka izlenmelidir.

Cookie-Based Affinity

Cookie-based affinity backend seçimini load balancer tarafından verilen veya uygulama tarafından üretilen cookie ile yapabilir. Tarayıcı tabanlı WebSocket istemcilerinde uygun olabilir. Reconnect sonrasında aynı backend'e dönüşü daha öngörülebilir hale getirir. Backend kaybolduğunda cookie mapping'in failover davranışı kontrol edilmelidir. Shared state kullanan sistemlerde bu bağımlılık çoğu zaman gereksiz olabilir.

Sticky Session'ın Dezavantajları

Sticky session backend'ler arasında yük dengesizliği oluşturabilir. Popüler tenant veya yoğun kullanıcı grubu aynı node üzerinde birikebilir. Node failure sonrasında affinity zaten bozulacağı için state recovery yine gereklidir. Scale-out sırasında yeni node'ların dolması yavaşlayabilir. Bu nedenlerle sticky session mimari state problemini gizlemek için kullanılmamalıdır.

Sticky Session Kullanmadan WebSocket Ölçeklendirme

Sticky session olmadan ölçeklendirme için application state mümkün olduğunca backend dışına taşınmalıdır. Authentication token üzerinden yeniden kurulabilir, presence veya registry bilgisi distributed store üzerinde tutulabilir. Node'lar arası mesaj iletimi Redis Pub/Sub, NATS, Kafka veya benzeri bir katmanla sağlanabilir. Client reconnect olduğunda herhangi sağlıklı backend'e bağlanabilir. Bu yapı horizontal scaling ve failure recovery süreçlerini daha esnek hale getirir.

Stateful ve Stateless WebSocket Mimarisi

WebSocket sunucusu bağlantının kendisi nedeniyle tamamen stateless olamaz, çünkü her socket fiziksel olarak belirli bir node üzerinde bulunur. Ancak kullanıcı session state'i ve business state'in node memory'sine bağımlı olması zorunlu değildir. Stateless gateway yaklaşımı bağlantı state'ini minimumda tutup paylaşılması gereken bilgileri harici sistemlere taşır. Bu sayede reconnect sonrası farklı backend kullanıcıyı devam ettirebilir. Dağıtık mimaride state sınırlarını açık tanımlamak load balancing ve failover kalitesini doğrudan etkiler.

Connection State Nedir?

Connection state socket'in açık olup olmadığı, connection ID, subscription listesi ve send queue gibi bağlantıya özgü bilgileri kapsar. Bu state fiziksel bağlantının bulunduğu node üzerinde tutulur. Node çökerse connection zaten kaybolur ve client reconnect etmek zorundadır. Connection state'in bir kısmı distributed registry üzerinde metadata olarak kopyalanabilir. Ancak gerçek socket başka node'a taşınamaz.

Session State Nedir?

Session state kullanıcı kimliği, yetkiler, tenant ve uygulama bağlamı gibi bağlantıdan daha uzun yaşayabilen bilgileri içerir. Bu state yalnızca server memory'sinde tutulursa reconnect sonrası affinity gerekir. Token veya distributed cache üzerinden tekrar oluşturulabilirse backend bağımlılığı azalır. Session state ile connection state birbirinden ayrılmalıdır. Bu ayrım horizontal scaling tasarımını ciddi biçimde kolaylaştırır.

State'i Application Server'da Tutmak

State'i application server memory'sinde tutmak düşük latency ve basitlik sağlayabilir. Tek node veya küçük sistemlerde bu yaklaşım yeterli olabilir. Cluster büyüdüğünde aynı kullanıcıya ait event'in doğru node'a yönlendirilmesi zorlaşır. Node failure state kaybına neden olabilir. Bu nedenle kritik state için replication veya external store düşünülmelidir.

State'i Harici Sisteme Taşımak

Harici state store backend node'ların daha bağımsız çalışmasını sağlar. Session, presence veya connection metadata gibi bilgiler node dışına taşınabilir. Bu yaklaşım reconnect sonrası başka backend'in kullanıcı bağlamını yeniden oluşturmasını kolaylaştırır. Bunun karşılığında ek network latency ve external dependency ortaya çıkar. State'in hangi bölümünün gerçekten paylaşılması gerektiği dikkatle seçilmelidir.

Redis

Redis düşük gecikmeli key-value erişimi ve Pub/Sub özellikleri nedeniyle WebSocket sistemlerinde sık kullanılır. User-to-server mapping, presence ve kısa ömürlü session bilgisi burada tutulabilir. TTL kullanımı stale kayıtların temizlenmesine yardımcı olur. Redis'in kendisi failure planına dahil edilmelidir. Yüksek availability ve memory kapasitesi production tasarımında ayrı değerlendirilmelidir.

Database

Database kalıcı session veya business state için uygun olabilir. Her WebSocket mesajında database erişmek ise gereksiz latency ve load oluşturabilir. Daha çok durable kullanıcı tercihleri, subscription kayıtları veya geçmiş event'ler için kullanılmalıdır. Connection presence gibi hızlı değişen ephemeral bilgiler farklı store üzerinde tutulabilir. Veri katmanlarını kullanım sıklığı ve kalıcılık ihtiyacına göre ayırmak daha verimli olur.

Distributed Cache

Distributed cache birden fazla backend'in ortak session ve metadata bilgisine erişmesini sağlayabilir. Node failover sonrasında yeni sunucu state'i tekrar okuyabilir. Cache hit düşükse ek network maliyeti beklenen faydayı azaltabilir. TTL ve invalidation politikası açık biçimde belirlenmelidir. Multi-region sistemlerde cache consistency ve cross-region latency ayrıca düşünülmelidir.

Stateless Gateway Yaklaşımı

Stateless gateway yaklaşımında WebSocket node yalnızca aktif socket için gerekli minimum state'i taşır. User profile, authorization ve durable subscription bilgileri dış sistemlerden alınabilir. Cross-node mesajlar broker üzerinden ilgili gateway'e gönderilir. Böylece herhangi yeni client herhangi sağlıklı node'a bağlanabilir. Bu model deployment ve autoscaling sırasında affinity bağımlılığını azaltır.

WebSocket Connection Registry Nasıl Tasarlanır?

Connection registry hangi kullanıcının hangi connection ve hangi node üzerinde bulunduğunu takip eden yapıdır. Çok node'lu sistemlerde doğrudan kullanıcıya mesaj göndermek için bu bilgi kritik hale gelir. Registry'nin stale connection sorununu çözmesi ve multi-device kullanımını desteklemesi gerekir. Her event'te central registry sorgulamak performans maliyeti yaratabileceği için local cache ve batch yaklaşımı düşünülebilir. Tasarım online presence ile gerçek socket location bilgisini birbirinden ayırmalıdır.

User ID → Connection ID

Bir kullanıcının bir veya daha fazla aktif connection ID'si olabilir. Registry user ID üzerinden bu connection listesine ulaşabilmelidir. Tek cihaz varsayımı mobil, web ve tablet kullanımında yanlış sonuç verir. Her connection ayrı yaşam döngüsüne sahiptir. Kullanıcı logout olduğunda yalnızca ilgili connection veya bütün session'lar business kuralına göre kapatılabilir.

Connection ID → Server ID

Connection ID'nin hangi server üzerinde bulunduğunu bilmek cross-node mesaj yönlendirmeyi kolaylaştırır. Broker mesajı server-specific topic'e yönlendirebilir. Node kapanırken kendi registry kayıtlarını temizlemelidir. Crash durumunda bu temizlik gerçekleşmeyebileceği için TTL veya heartbeat mekanizması gerekir. Registry verisinin mutlak doğruluk yerine kısa süreli eventual consistency ile çalışıp çalışamayacağı belirlenmelidir.

Bir Kullanıcının Birden Fazla Cihazı

Kullanıcı aynı anda telefon, web ve masaüstü istemcisinden bağlı olabilir. Mesajın bütün cihazlara mı yoksa tek aktif cihaza mı gönderileceği ürün kuralıdır. Registry her connection için device metadata saklayabilir. Presence hesaplamasında bir connection kapanması kullanıcıyı hemen offline yapmamalıdır. Tüm aktif bağlantılar kapandığında offline durumu oluşmalıdır.

Connection Metadata

Connection metadata user ID, tenant, device type, protocol version ve subscription gibi bilgileri içerebilir. Her bilgiyi registry'ye koymak memory ve update maliyetini artırır. Routing için gerçekten gereken alanlar seçilmelidir. Hassas token veya kişisel veri gereksiz yere tutulmamalıdır. Metadata schema'sı protocol versioning ile uyumlu biçimde geliştirilebilir.

Distributed Connection Registry

Distributed registry bütün WebSocket node'larının ortak connection location bilgisine erişmesini sağlar. Redis gibi düşük latency'li store kullanılabilir. Yüksek connection churn altında write rate ciddi seviyeye çıkabilir. Her connect ve disconnect işlemi registry güncellemesi üretir. Bu nedenle kapasite planı yalnızca aktif connection sayısını değil connection rate'i de içermelidir.

Stale Connection Temizliği

Node crash olduğunda disconnect callback çalışmayabilir ve registry'de eski kayıt kalabilir. TTL, node heartbeat veya periodic reconciliation bu kayıtları temizlemek için kullanılabilir. Çok kısa TTL aktif connection'ların gereksiz yenilenmesine neden olur. Çok uzun TTL ghost user ve yanlış routing riskini artırır. Uygun değer failure detection hedefiyle birlikte seçilmelidir.

Birden Fazla WebSocket Server Arasında Mesajlaşma

Bir kullanıcı A sunucusuna, diğer kullanıcı B sunucusuna bağlı olduğunda uygulama node'lar arası mesaj taşıma ihtiyacı duyar. Tek process memory'sinde event yayınlamak artık yeterli değildir. Bu nedenle Redis Pub/Sub, NATS, Kafka veya RabbitMQ gibi messaging katmanları kullanılabilir. Broker seçimi delivery semantics, ordering, throughput ve durability ihtiyacına göre yapılmalıdır. WebSocket yük dengelemede sticky session ve Redis pub sub nasıl kullanılır sorusunun önemli bölümü tam olarak bu cross-node iletişim modelidir.

Cross-Node Messaging Problemi

Gönderici ve alıcı farklı WebSocket server'larda olabilir. Mesajı alan node alıcının socket'ine doğrudan erişemez. Bu nedenle event ilgili node'a network üzerinden iletilmelidir. Distributed connection registry hedef server bilgisini sağlayabilir. Alternatif olarak room veya topic bazlı Pub/Sub ile ilgili node'lar mesajı dinleyebilir.

Redis Pub/Sub

Redis Pub/Sub düşük gecikmeli ephemeral mesajlaşma için kullanışlıdır. Publisher mesajı channel'a gönderir ve aktif subscriber node'lar anında alır. Subscriber offline ise mesaj kalıcı olarak saklanmaz. Bu yüzden missed message replay gereken sistemlerde tek başına yeterli değildir. Presence ve canlı fan-out gibi toleranslı event'lerde oldukça pratiktir.

Redis Streams

Redis Streams mesajları log benzeri yapıda saklayabilir. Consumer group ve replay gibi özellikler Pub/Sub'a göre daha güçlü delivery kontrolü sunar. Kısa süreli event history gereken sistemlerde tercih edilebilir. Stream retention ve consumer lag izlenmelidir. WebSocket fan-out için latency ile durability ihtiyacı arasında denge kurulmalıdır.

Kafka

Kafka yüksek throughput ve durable event log gereken sistemlerde güçlü bir seçenektir. Partition ordering ve replay yetenekleri büyük event platformlarında faydalıdır. Çok düşük latency'li tekil presence event'leri için her zaman en basit çözüm olmayabilir. WebSocket gateway ile event backbone arasında ayrım yapılabilir. Kafka daha çok durable business event'lerin dağıtımında değer sağlar.

NATS

NATS düşük latency ve hafif messaging ihtiyacı olan realtime sistemlerde kullanılabilir. Pub/Sub modeli node'lar arasında event dağıtımını kolaylaştırır. JetStream gibi ek özelliklerle durability seçenekleri sağlanabilir. Topic tasarımı fan-out maliyetini doğrudan etkiler. Çok yüksek subscription sayılarında broker kapasitesi ayrı load test ile doğrulanmalıdır.

RabbitMQ

RabbitMQ queue, routing ve acknowledgement özellikleriyle güvenilir messaging senaryolarında kullanılabilir. Routing key ve exchange yapısı farklı WebSocket node gruplarına mesaj taşımayı kolaylaştırabilir. Queue backlog oluştuğunda delivery latency artabilir. Real-time event ile durable job trafiği aynı broker üzerinde çalışıyorsa kaynak izolasyonu düşünülmelidir. Consumer concurrency ve prefetch ayarları workload'a göre yapılmalıdır.

Hangi Message Broker Ne Zaman Kullanılmalı?

Ephemeral ve düşük latency fan-out için Redis Pub/Sub veya NATS uygun olabilir. Replay ve durable stream gerekiyorsa Redis Streams veya Kafka değerlendirilebilir. Complex routing ve acknowledgement ihtiyacı varsa RabbitMQ güçlü seçenek olabilir. Tek bir broker'ı bütün messaging problemlerine zorlamak yerine event türlerini sınıflandırmak daha doğru olur. Seçim gerçek throughput, latency ve failure benchmark'larıyla doğrulanmalıdır.

Pub/Sub WebSocket Ölçeklemesini Nasıl Kolaylaştırır?

Pub/Sub backend node'ların birbirine doğrudan bağlı olma ihtiyacını azaltır. Bir node event yayınlar, ilgili topic'i dinleyen diğer node'lar mesajı alır. Bu sayede kullanıcıların hangi backend üzerinde bulunduğu değişse bile mesaj akışı merkezi broker üzerinden ilerleyebilir. Room ve topic tasarımı doğru yapılmazsa her mesaj bütün cluster'a broadcast edilerek gereksiz yük oluşturabilir. Pub/Sub mimarisinde subscription cardinality ve fan-out oranı temel kapasite metrikleridir.

Publisher

Publisher event'i messaging sistemine gönderen bileşendir. WebSocket node, business service veya başka bir backend publisher olabilir. Event payload mümkün olduğunca küçük ve açık schema'lı olmalıdır. Publisher başarısızlığı durumunda retry davranışı delivery semantics ile uyumlu olmalıdır. Duplicate event ihtimali varsa consumer tarafında idempotency gerekebilir.

Subscriber

Subscriber belirli channel veya topic üzerindeki mesajları dinler. WebSocket gateway ilgili kullanıcı veya room event'lerini alıp local connection'lara dağıtabilir. Subscriber lag gerçek zamanlı deneyimi doğrudan etkiler. Broker backlog ve consumer processing time izlenmelidir. Node sayısı arttığında toplam subscription sayısının broker kapasitesine etkisi ölçülmelidir.

Channel

Channel mesajların mantıksal olarak gruplandığı isimlendirilmiş akıştır. User-specific, room-specific veya server-specific channel tasarlanabilir. Çok ince channel yapısı yüksek subscription metadata maliyeti oluşturabilir. Çok geniş channel ise gereksiz mesajların her node'a ulaşmasına yol açabilir. Channel granularity gerçek fan-out pattern'e göre seçilmelidir.

Topic

Topic kavramı farklı broker sistemlerinde benzer publish-subscribe gruplamasını ifade eder. Tenant, room veya event type bazlı topic kullanılabilir. Topic sayısı çok büyüdüğünde broker metadata yönetimi etkilenebilir. Topic naming standardı operasyonda troubleshooting süresini azaltır. Multi-region sistemlerde topic replication maliyeti ayrıca değerlendirilmelidir.

Room

Room bir grup connection'ın aynı mesajları aldığı uygulama seviyesindeki kavramdır. Chat kanalı, oyun lobby'si veya ortak belge oturumu room olarak modellenebilir. Room üyeliği local memory ve distributed registry kombinasyonuyla tutulabilir. Çok büyük room'larda tek event binlerce connection'a fan-out edilir. Bu nedenle room size distribution kapasite planında önemli bir girdidir.

Multi-Node Fan-Out

Bir room üyeleri farklı WebSocket node'larına dağılmış olabilir. Publisher event'i broker'a gönderir ve ilgili node'lar kendi local connection'larına mesajı dağıtır. Böylece her kullanıcı için ayrı cross-node request gerekmez. Node başına local fan-out throughput ölçülmelidir. Büyük broadcast event'lerinde network bandwidth bottleneck olabilir.

WebSocket Fan-Out Nedir?

Fan-out tek bir event'in bir veya çok sayıda connection'a dağıtılmasıdır. One-to-one mesajlarda maliyet sınırlıyken büyük broadcast işlemlerinde tek event binlerce socket write oluşturabilir. Bu nedenle connection count kadar fan-out amplification da WebSocket kapasitesini belirler. Slow consumer'lar send queue büyümesine yol açabilir. Fan-out tasarımında batching, backpressure ve room partitioning gibi teknikler birlikte düşünülmelidir.

One-to-One

One-to-one iletişim tek kullanıcı veya connection'a mesaj gönderilmesidir. Connection registry hedef socket'in hangi node üzerinde olduğunu belirlemek için kullanılabilir. Kullanıcı birden fazla cihazdaysa delivery policy açık olmalıdır. Mesaj durable ise offline queue gerekebilir. Tekil mesajlar genellikle fan-out açısından düşük maliyetlidir.

One-to-Many

One-to-many modelinde tek event belirli bir kullanıcı grubuna gönderilir. Room veya subscription listesi hedefleri tanımlar. Alıcı sayısı arttıkça serialization ve socket write maliyeti artar. Aynı payload her kullanıcı için tekrar serialize edilmemelidir. Immutable shared buffer kullanımı bazı runtime'larda CPU ve memory kazanımı sağlayabilir.

Broadcast

Broadcast mesaj bütün aktif bağlantılara gönderilir. Cluster büyüdükçe tek event büyük network ve CPU yükü oluşturabilir. Her broadcast'in gerçekten bütün kullanıcıları ilgilendirip ilgilendirmediği sorgulanmalıdır. Topic segmentation gereksiz fan-out'u azaltır. Broadcast rate limit ve backpressure korumasıyla sınırlandırılmalıdır.

Room-Based Messaging

Room-based messaging kullanıcıları mantıksal gruplara ayırır. Mesaj yalnızca ilgili room üyelerine gönderilir. Bu yaklaşım global broadcast'a göre daha verimli olabilir. Room membership update hızı yüksekse registry ve broker üzerinde ek yük oluşur. Büyük room'lar için partition veya hierarchical fan-out düşünülebilir.

Fan-Out Amplification

Fan-out amplification tek bir incoming event'in kaç outgoing message ürettiğini gösterir. Bir event yüz bin connection'a gidiyorsa amplification değeri çok yüksektir. Incoming messages per second düşük olsa bile outgoing bandwidth devasa olabilir. Capacity planning bu çarpanı hesaba katmalıdır. Message broker throughput ile WebSocket egress throughput ayrı ölçülmelidir.

Büyük Kanallarda Performans Sorunları

Büyük channel veya room'larda tek event binlerce socket write işlemi tetikleyebilir. Slow client'lar send queue memory'sini büyütebilir. CPU serialization ve encryption maliyeti artabilir. Batching ve binary format network verimliliğini iyileştirebilir. Çok büyük gruplar için fan-out tree veya edge distribution mimarisi değerlendirilebilir.

WebSocket Sunucularında Connection Limitleri

Bir sunucunun kaldırabileceği WebSocket connection sayısı tek bir sabit rakam değildir. File descriptor limiti, memory per connection, runtime modeli, TLS, message traffic ve işletim sistemi ayarları birlikte kapasiteyi belirler. Sessiz yüz bin bağlantı ile yoğun mesajlaşan yüz bin bağlantı aynı yük değildir. Bu yüzden “bir sunucu kaç connection kaldırır” sorusunun cevabı load test sonucuyla verilmelidir. Gerçek kapasite failure headroom bırakılarak belirlenmelidir.

Operating System File Descriptors

Her TCP socket işletim sistemi seviyesinde file descriptor tüketir. Varsayılan limitler yüksek connection hedeflerinde yetersiz kalabilir. Uygulama process'i ve system-wide limitler ayrı kontrol edilmelidir. Sadece limiti artırmak memory veya network kapasitesini artırmaz. Load test sırasında açık descriptor sayısı izlenmelidir.

ulimit

ulimit process'in açabileceği dosya ve socket sayısını sınırlayabilir. Yüksek WebSocket connection hedefinde nofile ayarı kontrol edilmelidir. Container ve host ayarlarının birlikte değerlendirilmesi gerekir. Bir katmanda yüksek değer vermek diğer katmandaki sınırı otomatik kaldırmaz. Production rollout öncesinde startup validation ile limitler doğrulanabilir.

TCP Socket Limitleri

TCP connection sayısı kernel socket table ve network memory kullanır. Client ve server rollerinde ephemeral port davranışı farklı etkiler oluşturabilir. Sunucu listener tarafında file descriptor ve memory daha belirleyici olabilir. Load generator tarafında ise client port limitleri teste engel olabilir. Bu yüzden yüksek connection testlerinde hem server hem generator işletim sistemi ayarları incelenmelidir.

Memory per Connection

Her connection runtime nesnesi, socket buffer, authentication state ve queue gibi memory tüketir. Connection başına yalnızca birkaç kilobyte fark bile yüz bin bağlantıda yüzlerce megabyte oluşturabilir. TLS ve compression state bu maliyeti artırabilir. Heap profiler ile gerçek memory per connection ölçülmelidir. Kapasite hesabında slow consumer queue için ek headroom bırakılmalıdır.

Connection Table

Uygulama aktif connection'ları map veya registry içinde takip eder. Bu veri yapısının overhead'i connection sayısıyla büyür. User, room ve subscription index'leri memory maliyetini katlayabilir. Lookup complexity düşük tutulmalıdır. Large-scale sistemlerde registry yapısı profiler ve benchmark ile doğrulanmalıdır.

Kaç WebSocket Connection Bir Sunucuda Tutulabilir?

Net sayı runtime, donanım ve trafik modeline bağlıdır. Sessiz bağlantılarda yüz binlerce connection mümkün olabilirken yüksek mesaj hacminde çok daha düşük sayı güvenli olabilir. CPU, memory, network ve event-loop lag birlikte izlenmelidir. Load test gerçek message pattern'i temsil etmelidir. Production limiti testte ulaşılan maksimum değerin altında ve failure headroom içerecek biçimde seçilmelidir.

Linux TCP Ayarlarının WebSocket Performansına Etkisi

Linux varsayılan network ayarları çoğu uygulama için yeterli olabilir, ancak çok yüksek connection sayılarında bazı limitler görünür hale gelir. File descriptor, backlog, keepalive ve buffer ayarları özellikle bağlantı açılış dalgalarında önem kazanabilir. Kernel tuning ölçüm yapılmadan uygulanan sihirli değerler listesi olmamalıdır. Yanlış buffer ayarı connection başına memory tüketimini gereksiz artırabilir. Önce darboğaz belirlenmeli, sonra ilgili kernel parametresi değiştirilmelidir.

File Descriptor Limits

Yüksek connection hedefinde process descriptor limiti temel kontrollerden biridir. Uygulama açık socket sayısı limite yaklaşınca yeni connection kabul edemez. Container runtime ve systemd gibi katmanlar ayrı limit uygulayabilir. Monitoring limitle aktif kullanım arasındaki oranı göstermelidir. Kapasite planında yönetim bağlantıları ve log dosyaları için de pay bırakılmalıdır.

Socket Backlog

Socket backlog henüz application tarafından accept edilmemiş connection isteklerinin bekleyebileceği kuyruğu etkiler. Reconnect storm sırasında bu kuyruk hızla dolabilir. Çok düşük backlog connection failure oranını artırabilir. Çok yüksek değer kök kapasite sorununu çözmez. Connection ramp testleri uygun değeri belirlemeye yardımcı olur.

Accept Queue

Accept queue uygulamanın henüz işlemediği bağlantıları kısa süreli tutar. Event loop yoğun olduğunda accept hızı düşebilir. Queue saturation handshake latency ve connection error üretir. Metrics veya kernel network istatistikleri bu durumu gösterebilir. Uygulama accept loop performansı ile backlog ayarı birlikte incelenmelidir.

TCP Keepalive

TCP keepalive uzun süre sessiz bağlantıların ölü olup olmadığını kernel seviyesinde anlamaya yardımcı olabilir. WebSocket application heartbeat'in yerini tamamen almaz. NAT ve proxy timeout davranışı farklı olabilir. Keepalive interval çok uzun olursa failure detection gecikir. Çok kısa ayar gereksiz network trafiği oluşturur.

Buffer Sizes

TCP send ve receive buffer boyutları throughput ile memory kullanımı arasında denge kurar. Büyük buffer tek connection için faydalı görünürken yüz bin connection'da toplam memory maliyetini artırabilir. Uygulama mesajları küçükse aşırı buffer gereksiz olabilir. Kernel autotuning davranışı dikkate alınmalıdır. Değişiklik bandwidth ve memory benchmark ile doğrulanmalıdır.

Kernel Tuning Ne Zaman Gereklidir?

Kernel tuning ancak ölçülen limit işletim sistemi katmanındaysa yapılmalıdır. File descriptor exhaustion, accept queue saturation veya network buffer problemi açık sinyal üretir. Uygulama event loop yavaşsa kernel parametresi değiştirmek çözüm olmayacaktır. Değişiklikler staging load test'inde denenmelidir. Her ayar altyapı kodunda belgelenerek tekrarlanabilir hale getirilmelidir.

Event-Driven WebSocket Server Mimarisi

Çok sayıda uzun bağlantı için event-driven ve non-blocking I/O modelleri genellikle daha verimlidir. Her connection için ayrı işletim sistemi thread'i açmak yüksek memory ve context switch maliyeti oluşturabilir. Event loop veya hafif concurrency runtime'ları çok sayıda socket'i daha az thread ile yönetebilir. Yine de CPU yoğun iş event loop üzerinde çalıştırılırsa bütün bağlantılar gecikebilir. Bu yüzden I/O ve ağır hesaplama görevlerinin sınırı açık tasarlanmalıdır.

Thread-per-Connection Problemi

Her bağlantıya ayrı thread vermek az connection'da basit bir programlama modeli sunar. Connection sayısı on binlere çıktığında thread stack memory ve scheduler overhead büyür. Context switch CPU tüketimini artırabilir. Modern runtime'lar lightweight thread veya async abstraction sunabilir. Gerçek sınır kullanılan platform üzerinde benchmark edilmelidir.

Event Loop

Event loop hazır I/O olaylarını sırayla işleyen concurrency modelidir. Binlerce socket tek veya birkaç thread tarafından yönetilebilir. Handler'ların kısa ve non-blocking olması gerekir. Uzun CPU işlemi event-loop lag oluşturur. Event-loop lag metriği realtime latency için doğrudan izlenmelidir.

Non-Blocking I/O

Non-blocking I/O network işlemi tamamlanana kadar thread'in beklemesini engeller. Runtime hazır olduğunda callback, future veya coroutine devam eder. Bu model yüksek eş zamanlı connection sayısında thread kullanımını azaltır. Blocking database veya filesystem çağrıları yanlış kullanılırsa avantaj kaybolur. Dependency'lerin gerçekten async olup olmadığı kontrol edilmelidir.

epoll

epoll Linux üzerinde çok sayıda file descriptor olayını verimli biçimde takip etmek için kullanılan mekanizmadır. Modern network runtime'ları bunu genellikle doğrudan uygulama koduna göstermeden kullanır. On binlerce socket için klasik polling yöntemlerinden daha verimlidir. Application developer çoğu zaman runtime seçimiyle bu avantajdan yararlanır. Yine de event-loop ve handler tasarımı performans üzerinde belirleyici olmaya devam eder.

kqueue

kqueue BSD tabanlı sistemlerde benzer event notification yetenekleri sunar. Yüksek connection concurrency için runtime tarafından kullanılabilir. Platform farkları production benchmark'larında dikkate alınmalıdır. Linux production ile macOS development sonuçlarının birebir aynı olacağı varsayılmamalıdır. Container ve deployment hedefi gerçek performans testinde kullanılmalıdır.

Async Runtime

Async runtime coroutine, event loop ve I/O scheduling görevlerini yönetir. Runtime'ın connection başına overhead'i ve scheduler davranışı kapasiteyi etkiler. Event-loop lag, task queue ve garbage collection birlikte izlenebilir. CPU heavy işlemler worker pool veya ayrı service'e taşınabilir. Doğru runtime seçimi yalnızca dil tercihi değil, workload tercihi olarak görülmelidir.

WebSocket İçin Hangi Programlama Dili Daha Uygundur?

WebSocket için tek bir en iyi programlama dili yoktur. Önemli olan runtime'ın yüksek connection concurrency, non-blocking I/O ve memory yönetiminde uygulamanın hedeflerini karşılamasıdır. Ekip deneyimi, observability ve deployment araçları da kararın önemli parçalarıdır. Düşük seviyeli benchmark'ta hızlı görünen dil kötü application architecture ile kolayca yavaşlayabilir. Bu yüzden dil seçimi connection hedefi ve gerçek mesaj workload'u üzerinde test edilmelidir.

Node.js

Node.js event-driven yapısı sayesinde çok sayıda I/O ağırlıklı connection için doğal bir programlama modeli sunar. Tek event loop üzerinde blocking işlem yapmak bütün connection latency'sini etkileyebilir. CPU ağır görevler worker thread veya ayrı servisle ele alınmalıdır. Memory per connection kullanılan WebSocket library'ye göre ölçülmelidir. JavaScript ve TypeScript ekosistemi hızlı geliştirme avantajı sağlayabilir.

Event Loop

Node.js event loop socket event'lerini az sayıda thread ile yönetir. Handler fonksiyonlarının kısa tutulması önemlidir. Sync filesystem veya ağır JSON işleme event loop'u geciktirebilir. Event-loop lag production metric olarak izlenmelidir. Yük testinde latency artışı ile lag arasındaki ilişki kolayca görülebilir.

Go

Go hafif goroutine modeli ve güçlü network standard library'si nedeniyle realtime server geliştirmede sık tercih edilir. Her connection için goroutine kullanmak işletim sistemi thread-per-connection modelinden çok daha hafif olabilir. Yine de her goroutine ve buffer memory tüketir. Garbage collector davranışı yüksek connection sayısında ölçülmelidir. Basit deployment ve static binary operasyon açısından avantaj sağlayabilir.

Goroutines

Goroutine Go runtime tarafından yönetilen hafif concurrent execution birimidir. Binlerce goroutine az sayıda OS thread üzerinde çalışabilir. Blocking network işlemleri runtime scheduler tarafından verimli yönetilebilir. Gereksiz goroutine veya unbounded channel kullanımı memory problemine yol açabilir. Connection lifecycle ile goroutine lifecycle birlikte yönetilmelidir.

Java

Java güçlü runtime, profiling ve network framework ekosistemiyle yüksek ölçekli WebSocket sistemlerinde kullanılabilir. Modern JVM memory ve garbage collection seçenekleri yüksek throughput sunabilir. Reactive veya event-driven framework seçimi connection başına thread maliyetini azaltır. Startup ve heap tuning operasyonel gereksinime göre yapılmalıdır. Uzun süre çalışan servislerde observability araçları oldukça güçlüdür.

Netty

Netty event-driven network uygulamaları için düşük seviyeli güçlü bir framework sunar. Event loop ve channel pipeline modeli yüksek connection sayısını verimli yönetebilir. Handler içinde blocking işlem yapılmamalıdır. Buffer management doğru kullanılmazsa memory leak riski oluşabilir. Netty tabanlı sistemlerde event loop ve direct memory metrikleri ayrıca izlenmelidir.

Rust

Rust düşük memory overhead ve güçlü performans kontrolü isteyen sistemlerde tercih edilebilir. Ownership modeli memory güvenliği sağlarken öğrenme maliyeti daha yüksek olabilir. Async ecosystem yüksek connection concurrency için uygundur. Runtime ve library seçimi uygulama performansını doğrudan etkiler. Kritik gateway bileşenlerinde düşük kaynak tüketimi avantaj sağlayabilir.

Tokio

Tokio Rust için yaygın async runtime seçeneklerinden biridir. Event-driven network I/O ve task scheduling sağlar. Blocking işleri async worker üzerinde çalıştırmamak gerekir. Task sayısı ve buffer memory'si yüksek connection testlerinde ölçülmelidir. Runtime configuration uygulamanın CPU ve network profilinə göre ayarlanabilir.

Python

Python asyncio tabanlı WebSocket servisleri küçük ve orta ölçekli realtime uygulamalarda verimli olabilir. CPU yoğun işlerde interpreter ve runtime sınırları daha erken görünür hale gelebilir. I/O ağırlıklı workload'ta async model iyi sonuç verebilir. Worker process sayısı ve connection distribution dikkatle yönetilmelidir. Gerçek kapasite kullanılan framework ve message rate ile benchmark edilmelidir.

asyncio

asyncio coroutine tabanlı network uygulamaları için event loop sağlar. Çok sayıda socket az sayıda thread ile yönetilebilir. Blocking fonksiyonlar loop üzerinde çalıştırılırsa bütün bağlantılar etkilenir. Database client ve broker library'lerinin async uyumluluğu önemlidir. Event-loop lag ve process memory birlikte izlenmelidir.

“En İyi Programlama Dili” Yerine Doğru Runtime Nasıl Seçilir?

Runtime seçerken hedef concurrent connection sayısı ve messages per second belirlenmelidir. Memory per connection, p99 latency ve CPU profili gerçek benchmark ile ölçülmelidir. Ekibin debugging ve observability yetkinliği de uzun vadeli performansı etkiler. Gereksiz teknoloji değişimi üretkenlik kaybı oluşturabilir. Çoğu sistemde iyi tasarlanmış mevcut stack, kötü tasarlanmış daha hızlı bir dilden daha başarılı olur.

NGINX ile WebSocket Reverse Proxy Yapılandırması

NGINX WebSocket bağlantılarını reverse proxy olarak backend'e iletebilir. Yapılandırmada HTTP version, upgrade header ve timeout ayarları önemlidir. Normal HTTP için uygun kısa timeout değerleri WebSocket bağlantılarını beklenmedik biçimde kesebilir. Production ortamında config değişikliğinden sonra uzun süreli connection testi yapılmalıdır. Access log ve upstream error metric'leri handshake ve disconnect problemlerini anlamaya yardımcı olur.

HTTP Version

WebSocket proxy akışında backend iletişiminde uygun HTTP sürümünün kullanılması gerekir. Gelen client connection ile upstream connection davranışı proxy yapılandırmasına bağlıdır. Yanlış sürüm upgrade header davranışını bozabilir. Config template environment'lar arasında aynı tutulmalıdır. Integration test gerçek proxy üzerinden handshake yapmalıdır.

Upgrade Header

NGINX upstream request'e WebSocket upgrade bilgisini iletmelidir. Header kaybolursa backend normal HTTP request alabilir. Config değişikliği sonrası curl veya WebSocket client ile handshake doğrulanabilir. Access log status code sorunun ilk sinyalini verir. Reverse proxy katmanında header değerlerini gereksiz loglamak yerine gerekli metadata yeterlidir.

Connection Header

Connection header upgrade akışının backend'e doğru iletilmesinde kullanılır. Dynamic map yaklaşımı farklı request türleri için uygun değer seçebilir. Normal HTTP request'leri yanlışlıkla WebSocket gibi işaretlememek gerekir. Config review sırasında upgrade ve connection satırları birlikte kontrol edilmelidir. Handshake testleri deployment pipeline'ına eklenebilir.

Proxy Timeout

Proxy timeout çok düşükse sessiz ama sağlıklı WebSocket bağlantıları kapatılabilir. Çok yüksek değer dead connection'ların uzun süre kaynak tutmasına neden olabilir. Heartbeat interval timeout değerinden anlamlı biçimde daha kısa seçilebilir. Load balancer ve NGINX timeout'ları birbirleriyle uyumlu olmalıdır. Disconnect reason metric'leri timeout hatalarını görünür hale getirir.

Buffering

WebSocket mesajlarında düşük latency hedeflenirken gereksiz proxy buffering istenmeyebilir. Streaming trafiğin gecikmeden iletilmesi beklenir. Buffer ayarları reverse proxy davranışına göre kontrol edilmelidir. Büyük payload uygulamaları memory etkisini ayrıca ölçmelidir. Proxy config sadece handshake değil mesaj akışı üzerinde de benchmark edilmelidir.

Upstream Tanımlama

Upstream grubu WebSocket backend server'larını tanımlar. Round robin, least connections veya weighted dağılım burada seçilebilir. Health check davranışı node'ların yeni connection kabul edip etmeyeceğini etkiler. Backend DNS veya service discovery yapısı deployment mimarisiyle uyumlu olmalıdır. Rolling deployment sırasında terminating node'un upstream'den doğru zamanda çıkarılması gerekir.

NGINX ile WebSocket Load Balancing

NGINX WebSocket load balancing için birden fazla upstream backend arasında connection dağıtabilir. Algoritma seçimi connection duration ve backend kapasitesine göre yapılmalıdır. Least connections uzun ömürlü bağlantılarda çoğu zaman iyi bir başlangıç yaklaşımıdır. Health ve timeout ayarları bağlantı stabilitesini doğrudan etkiler. Nginx Kubernetes WebSocket load balancing ve autoscaling yapılandırması yapılırken ingress ile pod lifecycle davranışını birlikte test etmek gerekir.

Round Robin

NGINX varsayılan dağılım modeli round robin olabilir. Yeni connection'lar sırayla backend'lere gönderilir. Homojen node ve benzer connection lifetime durumunda yeterli olabilir. Uzun bağlantılarda skew metric'i izlenmelidir. Scale-out sonrası yeni node'ların dolma hızı ayrıca gözlemlenmelidir.

Least Connections

Least connections aktif bağlantı sayısı düşük backend'e yeni connection yönlendirir. WebSocket için doğal olarak daha uygun bir sinyal sağlar. Backend başına connection sayısı yakın tutulabilir. Trafik yoğunluğu connection başına çok değişiyorsa tek metric yetersiz kalabilir. Message rate ve queue depth monitoring ile desteklenmelidir.

IP Hash

IP hash aynı client IP'sini benzer backend'e yönlendirebilir. Reconnect affinity gereken eski stateful uygulamalarda kullanılabilir. NAT kullanıcıları dağılımı bozabilir. Mobil network IP değişimi affinity'yi kırabilir. Bu nedenle yeni mimarilerde shared state yaklaşımı çoğu zaman daha esnektir.

Weighted Backend

Weighted backend farklı server kapasitelerini load balancing kararına yansıtır. Daha yüksek CPU veya memory kapasitesi olan node daha fazla bağlantı kabul edebilir. Ağırlıklar performans testlerinden türetilmelidir. Node tipi değiştiğinde config güncellenmelidir. Dynamic autoscaling ortamında statik weight yönetimi zorlaşabilir.

Backend Health

Health check backend'in yeni bağlantı kabul etmeye uygun olup olmadığını belirler. Sadece process'in ayakta olması yeterli olmayabilir. Event-loop lag veya internal dependency sorunları node'u işlevsel olarak sağlıksız hale getirebilir. Readiness endpoint kapasite durumunu yansıtabilir. Mevcut WebSocket bağlantıları health failure anında nasıl ele alınacak ayrıca belirlenmelidir.

Connection Timeout'ları

Connect timeout, read timeout ve idle davranışları WebSocket kullanımına uygun ayarlanmalıdır. Çok kısa timeout kullanıcıların düzenli olarak reconnect etmesine neden olabilir. Çok uzun timeout dead socket tespitini geciktirebilir. Heartbeat tasarımı proxy timeout'larıyla uyumlu olmalıdır. Timeout kaynaklı disconnect rate dashboard'da ayrı izlenmelidir.

HAProxy ile WebSocket Load Balancing

HAProxy uzun ömürlü TCP ve HTTP bağlantılarını yönetebilen güçlü bir load balancing yaklaşımı sunar. WebSocket trafiği HTTP upgrade sonrasında tunnel olarak devam edebilir. Frontend ve backend timeout'larının doğru ayarlanması gerekir. Least connections WebSocket için kullanılabilir. Production testleri özellikle timeout tunnel ve health check davranışını doğrulamalıdır.

Frontend

Frontend client bağlantılarının kabul edildiği katmandır. TLS termination ve routing burada yapılabilir. Connection rate ve concurrent connection limitleri frontend kapasitesini etkiler. Log ve metric'ler handshake sorunlarını görünür hale getirebilir. DDoS koruması edge veya frontend öncesinde ayrıca uygulanabilir.

Backend

Backend WebSocket server havuzunu tanımlar. Algoritma ve health check davranışı burada yapılandırılır. Node draining sırasında yeni connection'ın terminating backend'e gitmesi engellenmelidir. Existing tunnel'lar grace period boyunca korunabilir. Backend connection count load balancing sonucunu izlemek için önemlidir.

HTTP Mode

HTTP mode handshake header ve routing bilgilerini değerlendirmeye izin verir. Path veya host bazlı WebSocket routing yapılabilir. Upgrade tamamlandıktan sonra bağlantı tunnel davranışına geçer. HTTP logları handshake debugging için faydalıdır. Application-level routing ihtiyacı varsa bu mod uygun olabilir.

TCP Mode

TCP mode daha düşük seviyede byte stream yönlendirmesi yapar. TLS passthrough veya protocol-agnostic routing için kullanılabilir. HTTP header bazlı kararlar daha sınırlı hale gelir. Observability bilgisi application layer kadar detaylı olmayabilir. Kullanım senaryosu TLS ve routing gereksinimine göre seçilmelidir.

Least Connections

Least connections HAProxy ile WebSocket backend dağılımında etkili olabilir. Yeni bağlantı daha az aktif connection olan node'a gönderilir. Uzun connection sürelerinde round robin dengesizliğini azaltabilir. Backend yoğunluğunu yalnız connection sayısı ile ölçmek yeterli olmayabilir. Custom health ve application metric'leri ayrıca izlenmelidir.

timeout tunnel

timeout tunnel uzun süreli tunnel bağlantılarının idle davranışını kontrol eder. Çok kısa değer sessiz WebSocket client'ları koparabilir. Heartbeat interval ile uyumlu seçilmelidir. Çok uzun timeout dead connection cleanup süresini artırabilir. Gerçek client network koşullarıyla test yapılmalıdır.

Health Checks

Health checks yeni connection için uygun backend'leri belirler. Liveness ile readiness kavramları birbirinden ayrılmalıdır. Node overload durumunda process canlı olsa bile yeni connection kabul etmemesi gerekebilir. Custom health endpoint active connection ve queue durumunu değerlendirebilir. Yanlış health logic flapping oluşturarak reconnect storm yaratabilir.

NGINX mi HAProxy mi?

NGINX ve HAProxy WebSocket load balancing için kullanılabilir, fakat seçim tek bir performans skoruna göre yapılmamalıdır. Mevcut altyapı, ekip deneyimi, TLS yönetimi, observability ve routing gereksinimi önemlidir. Her iki yaklaşım da doğru yapılandırıldığında yüksek connection sayısını destekleyebilir. Gerçek fark workload ve operasyon modelinde ortaya çıkar. Karar production benzeri concurrent connection ve failure testleriyle doğrulanmalıdır.

Configuration

NGINX web ve reverse proxy yapılandırmasına alışık ekipler için doğal seçim olabilir. HAProxy yük dengeleme ve network odaklı yapılandırmada güçlü kontrol sunar. Config karmaşıklığı feature sayısı arttıkça değişir. Infrastructure as code ile configuration versionlanmalıdır. Test environment'ta config syntax ve behavior otomatik doğrulanmalıdır.

Connection Management

Her iki sistem de uzun ömürlü bağlantıları yönetebilir. Timeout ve backend selection ayarları gerçek WebSocket workload'una göre yapılmalıdır. Connection draining yaklaşımı deployment sürecine entegre edilmelidir. Peak connection sayısı için file descriptor ve memory kapasitesi ölçülmelidir. Kullanılan ürün ne olursa olsun connection lifecycle görünür olmalıdır.

Observability

Backend connection sayısı, error rate ve latency metric'leri operasyon için önemlidir. Log formatı handshake ve disconnect analizine yardımcı olmalıdır. Prometheus veya mevcut monitoring stack ile entegrasyon seçim üzerinde etkili olabilir. Dashboard connection skew'u gösterebilmelidir. Ortalama değerlerin yanında percentile ve rate metrikleri izlenmelidir.

TLS

TLS termination load balancer üzerinde yapılabilir. Certificate rotation ve cipher policy operasyon süreçlerinin parçasıdır. Yüksek reconnect rate TLS handshake CPU maliyetini artırabilir. Session resumption destekleri yardımcı olabilir. Security ile performance birlikte benchmark edilmelidir.

Load Balancing

Round robin, least connections ve weighted routing her iki yaklaşımda da değerlendirilebilir. Hangi algoritmanın daha iyi olduğu connection lifetime dağılımına bağlıdır. IP hash kullanımı affinity ihtiyacına göre seçilmelidir. Scale-out sırasında connection skew monitoring önemlidir. Load balancing kararını gerçek backend kapasite verileri desteklemelidir.

Performance

Ham benchmark sonucu tek başına gerçek uygulama performansını belirlemez. TLS, log, health check ve routing feature'ları devreye girdiğinde profil değişir. Kendi connection ve message pattern'inizle test yapmak gerekir. CPU, memory ve p99 latency birlikte ölçülmelidir. Operational simplicity de uzun vadeli performansın bir parçasıdır.

Kullanım Senaryoları

Mevcut NGINX altyapısı bulunan web platformunda aynı reverse proxy katmanını kullanmak pratik olabilir. Network load balancing odaklı ayrı gateway katmanında HAProxy tercih edilebilir. Her iki çözüm Kubernetes dışında veya önünde çalışabilir. Managed cloud load balancer da operasyon yükünü azaltabilir. Karar altyapı standardı ve gerçek ölçek hedefiyle uyumlu olmalıdır.

Cloud Load Balancer'larla WebSocket

Managed cloud load balancer hizmetleri WebSocket trafiğini ölçekli biçimde yönlendirmeyi kolaylaştırabilir. TLS, health check ve autoscaling entegrasyonu operasyon yükünü azaltır. Buna karşılık idle timeout, connection limit ve pricing modeli dikkatle incelenmelidir. Çok uzun bağlantılar load balancer maliyet hesabını klasik HTTP'den farklı hale getirebilir. Region ve failover davranışı production öncesinde test edilmelidir.

AWS Application Load Balancer

AWS Application Load Balancer HTTP tabanlı WebSocket upgrade trafiğini yönlendirebilir. Target group health ve autoscaling entegrasyonu kullanılabilir. Idle timeout uzun connection'lara göre ayarlanmalıdır. Connection ve LCU benzeri maliyet bileşenleri kapasite hesabına dahil edilmelidir. Multi-AZ davranışı failure testleriyle doğrulanmalıdır.

Google Cloud Load Balancing

Google Cloud load balancing WebSocket destekli application trafiğini managed altyapıyla dağıtabilir. Global veya regional mimari ihtiyaca göre seçilebilir. Backend health ve autoscaling integration kullanılabilir. Timeout ve connection behavior servis türüne göre kontrol edilmelidir. Cross-region latency gerçek kullanıcı dağılımı üzerinde ölçülmelidir.

Azure Load Balancer / Application Gateway

Azure tarafında kullanılacak load balancing katmanı uygulama ve protocol gereksinimine göre seçilebilir. Application layer routing gereken WebSocket senaryolarında uygun gateway özellikleri değerlendirilebilir. Idle timeout ve health probe davranışı kritik ayarlardır. Managed TLS operasyon kolaylığı sağlayabilir. Deployment sırasında existing connection davranışı ayrıca test edilmelidir.

Managed TLS

Managed TLS certificate yenileme ve termination operasyonunu kolaylaştırır. Edge üzerinde TLS çözülmesi backend CPU yükünü azaltabilir. Güven sınırı ve backend encryption ihtiyacı güvenlik politikasına göre belirlenmelidir. High reconnect dönemlerinde handshake metric'leri izlenmelidir. Certificate rotation'ın açık bağlantılara etkisi önceden test edilmelidir.

Idle Timeout

Managed load balancer'larda idle timeout varsayılan değeri WebSocket için yetersiz olabilir. Sessiz connection heartbeat olmadan kapatılabilir. Timeout artırmak veya heartbeat göndermek gerekebilir. Değer platform limitleri içinde seçilmelidir. Çok sık heartbeat network ve battery maliyeti oluşturur.

Health Checks

Health check yeni connection routing kararını etkiler. Backend process alive olsa bile connection capacity dolmuş olabilir. Readiness endpoint bu durumu yansıtabilir. Health interval çok agresif olursa transient problem backend'in sık çıkarılıp eklenmesine neden olabilir. Bu davranış reconnect yükünü artırabilir.

Autoscaling Entegrasyonu

Cloud load balancer yeni backend instance'ları autoscaling grubu üzerinden keşfedebilir. WebSocket'te scale-out sonrası existing connection'lar yeni instance'a taşınmaz. Yeni connection'lar yeni kapasiteyi doldurmaya başlar. Bu yüzden scaling sinyali kapasite tamamen dolmadan önce tetiklenmelidir. Connection rate ve active connection metric'leri CPU ile birlikte kullanılabilir.

Kubernetes'te WebSocket Nasıl Çalıştırılır?

Kubernetes WebSocket server'larını pod olarak çalıştırıp Service ve Ingress veya Gateway üzerinden erişilebilir hale getirebilir. WebSocket upgrade desteklenmelidir ve timeout ayarları uzun bağlantılara uygun olmalıdır. Pod lifecycle normal kısa HTTP request'lerinden farklı ele alınmalıdır. Rolling deployment sırasında pod hemen kapatılırsa binlerce connection aynı anda kopabilir. Readiness, preStop ve termination grace ayarları connection draining stratejisiyle birlikte tasarlanmalıdır.

Deployment

Deployment WebSocket server pod'larının desired replica sayısını ve rollout stratejisini yönetir. Replica artışı yeni connection kapasitesi sağlar. Existing connection'lar yeni pod'lara otomatik taşınmaz. Rolling update parametreleri aynı anda kaç pod'un değişeceğini belirler. MaxUnavailable değeri connection capacity headroom ile uyumlu olmalıdır.

Pod

Her pod belirli sayıda WebSocket connection taşır. Pod memory ve file descriptor limitleri container konfigürasyonuyla uyumlu olmalıdır. CPU throttling event-loop latency'yi artırabilir. Resource request ve limit değerleri load test sonuçlarından türetilmelidir. Pod başına connection metric autoscaling ve skew izleme için expose edilmelidir.

Service

Kubernetes Service pod'lara stable network endpoint sağlar. Connection kurulurken belirli backend pod seçilir. Uzun TCP connection aynı pod üzerinde devam eder. Pod sonlandırıldığında connection kopar ve client reconnect eder. Service tek başına uygulama state paylaşımını çözmez.

Ingress / Gateway

Ingress veya Gateway dış trafiği cluster içindeki WebSocket service'e yönlendirir. Controller'ın upgrade ve long connection desteği doğrulanmalıdır. Timeout değerleri default HTTP kullanımına göre kısa olabilir. TLS termination burada yapılabilir. Controller replica ve load balancer kapasitesi backend kadar önemlidir.

WebSocket Upgrade

Ingress katmanı WebSocket handshake header'larını backend'e doğru iletmelidir. Controller'a göre ek annotation veya config gerekebilir. Upgrade başarısızlığı deployment sonrası hemen test edilmelidir. Synthetic WebSocket probe uzun connection açarak temel davranışı doğrulayabilir. Sadece HTTP health check WebSocket akışını tam test etmez.

Timeout Ayarları

Ingress read ve send timeout değerleri uzun connection'ları desteklemelidir. Heartbeat interval proxy timeout'tan kısa tutulabilir. Çok uzun timeout dead connection cleanup süresini artırabilir. Client, ingress ve backend timeout'ları uyumlu olmalıdır. Disconnect reason dağılımı yanlış timeout ayarını görünür hale getirir.

Kubernetes Service WebSocket Bağlantılarını Nasıl Dağıtır?

Kubernetes Service yeni connection açıldığında trafiği bir backend pod'a yönlendirir. Connection açık kaldığı sürece paketler aynı TCP akışının parçasıdır ve aynı pod'a gider. Yeni pod eklendiğinde eski connection'lar oraya taşınmaz. Bu davranış hızlı scale-out sonrasında connection skew yaratabilir. WebSocket cluster yönetiminde autoscaling kadar rebalancing davranışı da bu yüzden önemlidir.

Connection Kurulurken Backend Seçimi

Yeni client connection Service veya üst load balancing katmanı üzerinden bir pod'a yönlendirilir. Seçim kullanılan network implementation ve ingress katmanına göre değişebilir. Backend belirlendikten sonra connection uzun süre orada kalır. New connection distribution metric'i scale-out davranışını anlamaya yardımcı olur. Sticky session ek ayar olmadan da aktif TCP connection için backend sabittir.

Uzun Süreli Connection

WebSocket connection dakikalar veya saatler sürebilir. Pod bu süre boyunca socket kaynaklarını taşır. CPU düşük görünse bile connection capacity dolabilir. Long-lived connection scale-in işlemlerini yavaşlatabilir. Maximum lifetime veya drain deadline operasyon planına dahil edilebilir.

Yeni Pod Eklendiğinde Ne Olur?

Yeni pod readiness durumuna geçtiğinde yeni bağlantılar bu pod'a yönlendirilebilir. Existing bağlantılar eski pod'larda kalır. Bu yüzden yeni pod başlangıçta çok düşük connection sayısına sahip olur. Least connections kullanılıyorsa daha hızlı dolabilir. Natural rebalancing client reconnect'leriyle zaman içinde gerçekleşir.

Eski Connection'ların Yeni Pod'a Taşınmaması

Aktif TCP connection canlı biçimde başka pod'a taşınmaz. Socket state operating system ve application process'e bağlıdır. Rebalancing için bağlantının kapanması ve yeniden kurulması gerekir. Bu yüzden scale-out anında cluster load hemen eşitlenmez. Tasarım kapasite alarmını tamamen dolmadan önce tetiklemelidir.

Connection Skew

Connection skew pod'lar arasındaki aktif bağlantı sayısının dengesiz olmasıdır. Average metric bu farkı gizleyebilir. Max, min ve standard deviation birlikte izlenebilir. Trafik yoğunluğu farklıysa messages per connection metriği eklenmelidir. Çok yüksek skew deployment ve scale-out stratejisinin gözden geçirilmesini gerektirir.

WebSocket Autoscaling Nasıl Yapılmalıdır?

WebSocket autoscaling yalnızca CPU yüzdesine göre yapılmamalıdır. Active connections, connection rate, message throughput, queue depth ve event-loop lag gibi ölçümler workload hakkında daha doğru bilgi verir. Bazı uygulamalarda memory per connection CPU'dan önce kapasite sınırına ulaşır. Bazılarında ise birkaç yoğun room CPU'yu yükseltir. Composite scaling metric birden fazla sinyali değerlendirerek daha güvenli kapasite yönetimi sağlayabilir.

CPU-Based Scaling

CPU utilization basit ve yaygın autoscaling metriğidir. Yoğun serialization veya fan-out workload'larında faydalı olabilir. Sessiz ama yüz bin connection taşıyan pod düşük CPU ile kapasite sınırına yaklaşabilir. Bu nedenle CPU tek metric olmamalıdır. Scale-out threshold gerçek load test sonuçlarıyla belirlenmelidir.

Memory-Based Scaling

Connection başına state ve queue memory tükettiği için memory önemli scaling sinyalidir. Slow consumer durumunda buffer growth hızlı artabilir. Memory limitine yaklaşmak OOM riskini yükseltir. Average memory yerine working set ve connection başına memory oranı izlenebilir. Scale-out memory pressure başlamadan önce tetiklenmelidir.

Active Connections

Active connections WebSocket capacity için doğrudan metriktir. Pod başına güvenli connection limiti load test ile belirlenebilir. Autoscaler hedef connection sayısına göre replica artırabilir. Ancak bütün connection'ların aynı yükü üretmediği unutulmamalıdır. Message throughput ile birlikte değerlendirilmesi daha doğrudur.

Connection Rate

Connection rate saniyede kaç yeni bağlantı açıldığını gösterir. Ani yükseliş reconnect storm veya trafik kampanyası sinyali olabilir. TLS handshake ve authentication CPU'su bu sırada artar. Active connection henüz düşük olsa bile yüksek rate kısa süre içinde kapasiteyi tüketebilir. Predictive veya rate-based scaling bu nedenle yararlı olabilir.

Messages per Second

Messages per second application workload'unun gerçek işlem hacmini gösterir. Aynı connection sayısında farklı kullanıcı davranışı çok farklı message rate üretebilir. CPU ve broker yükü bu metric ile korelasyon gösterebilir. Incoming ve outgoing mesaj sayısı ayrı ölçülmelidir. Fan-out yoğun sistemlerde outgoing rate çok daha yüksek olabilir.

Bytes per Second

Bytes per second network throughput ve serialization yükünü gösterir. Büyük payload uygulamalarında connection sayısından daha önemli olabilir. Egress bandwidth node kapasitesini sınırlayabilir. Compression açıldığında byte miktarı düşerken CPU artabilir. Bu trade-off load test ile ölçülmelidir.

Queue Depth

Send queue veya broker queue depth sistemin tüketim hızının producer hızına yetişip yetişmediğini gösterir. Queue büyümesi backpressure sinyalidir. Autoscaling daha fazla consumer veya gateway kapasitesi ekleyebilir. Slow client kaynaklı per-connection queue sorunu ise yalnız replica artırarak çözülmez. Queue type ve owner metric içinde açık tanımlanmalıdır.

Event-Loop Lag

Event-loop lag runtime'ın I/O event'lerini zamanında işleyip işleyemediğini gösterir. CPU veya blocking code nedeniyle yükselirse bütün WebSocket latency'si bozulabilir. Node.js, Python veya diğer event-driven runtime'larda güçlü bir scaling sinyalidir. p95 ve p99 lag değerleri izlenebilir. Lag yükselmeden önce autoscaling tetiklemek kullanıcı deneyimini korur.

Composite Scaling Metric

Composite metric birden fazla kapasite sinyalini bir araya getirir. Örneğin active connection oranı, CPU ve event-loop lag birlikte değerlendirilebilir. Böylece sessiz connection ile yoğun message workload'u aynı modelde görülebilir. Karmaşık formül operasyonel olarak anlaşılır tutulmalıdır. Scaling kararının neden tetiklendiği dashboard üzerinden görülebilmelidir.

Kubernetes HPA WebSocket İçin Yeterli midir?

Kubernetes HPA varsayılan CPU ve memory metrikleriyle temel ölçekleme sağlayabilir. WebSocket workload'unda connection count ve message rate çoğu zaman daha anlamlı sinyal olabilir. Custom metrics entegrasyonu bu eksikliği kapatır. KEDA veya Prometheus Adapter gibi mekanizmalar external metric'leri scaling kararına taşıyabilir. Scale-to-zero yaklaşımı sürekli açık connection gerektiren servislerde genellikle uygun değildir.

CPU'nun Yanıltıcı Olduğu Senaryolar

Binlerce idle WebSocket connection çok düşük CPU kullanabilir. Buna rağmen pod memory ve file descriptor kapasitesine yaklaşabilir. HPA CPU düşük gördüğü için scale-out yapmaz. Ani message burst geldiğinde node hemen doygun hale gelebilir. Active connection hedefi bu senaryoda daha doğru koruma sağlar.

Custom Metrics

Custom metrics active_connections veya websocket_messages_rate gibi uygulama ölçümlerini HPA'ya sunabilir. Metric stable ve doğru export edilmelidir. Pod termination sırasında değerlerin yanlış düşmesi scaling davranışını etkileyebilir. Smoothing window kısa trafik dalgalarının gereksiz scale-out üretmesini azaltır. Threshold değerleri load test sonucuna dayanmalıdır.

Prometheus Adapter

Prometheus Adapter uygulama metric'lerini Kubernetes custom metric API üzerinden HPA'ya sunabilir. WebSocket server Prometheus formatında active connection ve event-loop lag expose edebilir. Query performansı ve metric cardinality kontrol edilmelidir. Çok yüksek label cardinality monitoring altyapısını zorlayabilir. Kullanıcı ID gibi değerler metric label olarak kullanılmamalıdır.

KEDA

KEDA event-driven scaling için farklı external source ve metric'leri kullanabilir. Broker queue veya Prometheus metric üzerinden replica sayısı yönetilebilir. WebSocket gateway için scale-to-zero yerine minimum replica belirlemek gerekir. Scaling cooldown uzun connection davranışına göre seçilmelidir. Queue-based backend worker ile connection gateway scaling politikaları ayrı olabilir.

Connection-Based Autoscaling

Connection-based autoscaling pod başına aktif connection hedefi belirler. Güvenli limit load test ile bulunmalıdır. Replica sayısı connection dağılımı ve headroom ihtiyacına göre hesaplanabilir. Scale-in sırasında pod draining yapılmadan replica azaltmak reconnect storm yaratabilir. Bu nedenle autoscaler ile lifecycle controller uyumlu çalışmalıdır.

Scale-to-Zero Problemi

Aktif WebSocket connection varken service'i sıfır replica'ya düşürmek bağlantıları koparır. Yeni connection gelene kadar pod başlatmak handshake latency oluşturabilir. Presence veya always-on realtime uygulamalarda minimum replica gereklidir. Scale-to-zero daha çok event worker gibi connection taşımayan bileşenlerde düşünülebilir. Gateway ve processing katmanını ayırmak bu esnekliği artırır.

Yeni WebSocket Pod'ları Eklendiğinde Bağlantılar Nasıl Dengelenir?

Yeni pod eklendiğinde load balancer yalnız yeni bağlantıları bu pod'a yönlendirebilir. Mevcut socket'ler eski pod üzerinde kalır. Bu nedenle ani scale-out sonrasında cluster dağılımı hemen eşitlenmez. Natural reconnect zaman içinde denge sağlayabilir, fakat connection lifetime çok uzunsa süreç saatler sürebilir. Controlled reconnect ve maximum connection lifetime bu durumda yardımcı olabilir.

Yeni Bağlantıların Yeni Pod'lara Gitmesi

Least connections gibi algoritmalar yeni boş pod'lara daha fazla connection yönlendirebilir. Round robin ise eşit sırayla dağıtım yapar ve yeni pod daha yavaş dolabilir. Service discovery yeni pod'u hazır olmadan trafiğe açmamalıdır. Readiness probe initialization tamamlanmasını beklemelidir. New connection distribution metric'i bu davranışı doğrular.

Mevcut Bağlantıların Yerinde Kalması

Existing TCP connection fiziksel olarak mevcut pod'a bağlıdır. Yeni pod eklenmesi socket migration oluşturmaz. Bu davranış bağlantı kararlılığı açısından iyidir. Ancak old pod'lar yüksek connection yükü taşımaya devam eder. Scaling sistemi bu geçici dengesizliği kapasite hesabına dahil etmelidir.

Natural Rebalancing

Kullanıcılar normal olarak bağlantıyı kapatıp tekrar açtıkça yeni connection'lar boş pod'lara gidebilir. Bu süreç natural rebalancing olarak düşünülebilir. Ortalama connection lifetime kısa ise oldukça yeterli olabilir. Saatlerce açık bağlantılarda süreç yavaş kalır. Connection distribution trend'i gerçek rebalancing hızını gösterir.

Controlled Reconnect

Controlled reconnect sunucunun belirli bağlantılara yeniden bağlanma sinyali göndermesidir. Bütün client'ları aynı anda reconnect ettirmek yerine batch ve jitter kullanılmalıdır. Aksi halde reconnect storm oluşabilir. Client session resume desteği kullanıcı deneyimini korur. Bu yöntem yalnız ciddi skew veya maintenance ihtiyacında uygulanmalıdır.

Maximum Connection Lifetime

Maximum connection lifetime çok uzun yaşayan bağlantıların belirli süreden sonra kontrollü biçimde yenilenmesini sağlar. Bu yaklaşım cluster'ın zaman içinde yeniden dengelenmesine yardımcı olabilir. Lifetime bütün client'larda aynıysa toplu reconnect dalgası oluşur. Random jitter eklenerek dağılım yumuşatılmalıdır. Reconnect maliyeti ve user experience birlikte ölçülmelidir.

Rebalancing'in Kullanıcı Deneyimine Etkisi

Rebalancing bağlantının kısa süreli kopmasına neden olabilir. Client resume ve mesaj replay desteği varsa kullanıcı bunu fark etmeyebilir. Realtime oyun veya görüşme uygulamasında bağlantı yenileme daha hassas olabilir. Bu yüzden forced reconnect sıklığı ürün gereksinimine göre sınırlanmalıdır. Operasyonel denge kullanıcı deneyiminden bağımsız düşünülmemelidir.

Connection Draining Nedir?

Connection draining bir backend'i kapatmadan önce yeni bağlantı kabulünü durdurup mevcut bağlantılara belirli süre devam etme fırsatı vermektir. WebSocket deployment'larında ani pod termination'ın oluşturduğu toplu disconnect riskini azaltır. Draining sırasında pod readiness false yapılabilir. Client'lara kontrollü reconnect sinyali gönderilebilir. Drain deadline sonunda kalan bağlantılar zorunlu biçimde kapatılabilir.

Yeni Connection Kabulünü Durdurmak

Draining başlayan pod yeni client connection almamalıdır. Kubernetes'te readiness false yapılarak Service endpoint listesinden çıkarılabilir. Load balancer propagation gecikmesi hesaba katılmalıdır. Kısa süre daha yeni connection gelme ihtimali olabilir. Application bu dönemde yeni handshake'leri reddetmek için ayrıca state tutabilir.

Mevcut Connection'ları Korumak

Existing connection'lar bir süre çalışmaya devam eder. Kullanıcı işlemlerini tamamlayabilir veya doğal biçimde disconnect olabilir. Bu süre deployment hızını yavaşlatabilir. Drain deadline operational hedefe göre belirlenmelidir. Çok uzun bağlantılar için sonsuz beklemek mümkün değildir.

Drain Deadline

Drain deadline pod'un connection'ların kapanmasını bekleyeceği maksimum süredir. Süre kullanıcı deneyimi ve deployment hızına göre seçilir. Deadline yaklaşırken client'lara reconnect mesajı gönderilebilir. Remaining connection count monitoring ile izlenmelidir. Deadline sonunda zorunlu termination için sistem hazır olmalıdır.

Graceful Disconnect

Graceful disconnect client'a bağlantının planlı biçimde kapanacağını bildirir. Uygun close code veya application mesajı kullanılabilir. Client kısa bir jitter sonrasında yeniden bağlanabilir. Session resume bilgisi korunmalıdır. Böylece kullanıcı beklenmedik network hatasına göre daha kontrollü davranış görür.

Client'a Reconnect Sinyali Göndermek

Server özel bir maintenance veya reconnect event'i gönderebilir. Event minimum delay ve random range içerebilir. Bütün client'ların aynı anda hareket etmemesi önemlidir. Client eski server'a sürekli dönmemelidir. Load balancer readiness durumu yeni bağlantıyı sağlıklı node'a yönlendirmelidir.

Deployment ve Scale-In Sırasında Kullanımı

Rolling deployment ve scale-in connection draining'in temel kullanım alanlarıdır. Scale-in sırasında dolu pod'u aniden kapatmak binlerce reconnect oluşturabilir. Autoscaler termination kararı lifecycle mekanizmasına zaman tanımalıdır. PDB ve terminationGracePeriodSeconds bu süreçle uyumlu olmalıdır. Draining metric'leri deployment dashboard'unda görünmelidir.

Graceful Shutdown Nasıl Yapılır?

Graceful shutdown WebSocket server'ın kapanırken connection'ları kontrollü biçimde sonlandırmasını sağlar. İlk adım shutdown sinyalini alıp yeni connection kabulünü durdurmaktır. Ardından mevcut connection'lara belirli süre kapanma fırsatı verilir. Timeout sonunda kalan socket'ler zorunlu olarak kapatılır. Bu akış rolling deployment sırasında reconnect storm riskini önemli ölçüde azaltır.

Shutdown Sinyali

Container veya işletim sistemi process'e termination sinyali gönderir. Uygulama bu sinyali yakalayıp draining state'e geçmelidir. Yeni background iş veya room join kabul edilmemesi gerekebilir. Shutdown handler kısa ve güvenilir olmalıdır. Crash durumunda bu akış çalışmayacağı için client reconnect stratejisi yine gereklidir.

Readiness'i Kapatmak

Readiness false olduğunda orchestrator pod'u yeni traffic için endpoint listesinden çıkarır. Propagation anlık olmayabilir. Uygulama kısa süre yeni handshake almaya devam edebilir. Bu nedenle internal draining flag ek koruma sağlar. Readiness ile liveness aynı amaç için kullanılmamalıdır.

Yeni Connection Kabul Etmemek

Draining pod yeni WebSocket handshake'lerini reddetmelidir. Client başka backend'e reconnect edebilir. Uygun error veya retry hint gönderilebilir. Yeni bağlantı reddetme oranı rollout sırasında izlenebilir. Normal trafik döneminde bu metric'in yükselmesi health problemi gösterebilir.

Mevcut Connection'ları Tamamlamak

Mevcut connection'lar doğal kapanış veya reconnect için süre kazanır. Ongoing message delivery mümkün olduğunca tamamlanır. Durable mesajlar broker veya event log üzerinde korunmalıdır. In-memory queue kapanırken kaybolabilecek mesajlar için delivery semantics açık olmalıdır. Shutdown testleri bu uç durumları kapsamalıdır.

Maksimum Bekleme Süresi

Graceful shutdown sonsuza kadar bekleyemez. Maksimum süre deployment ve infrastructure timeout limitleriyle uyumlu olmalıdır. Çok kısa süre kullanıcıları sık koparır. Çok uzun süre rollout'u geciktirir. Connection lifetime dağılımı uygun grace period seçimine yardımcı olur.

Zorunlu Disconnect

Grace süresi dolduğunda kalan connection'lar kapatılır. Client exponential backoff ve jitter ile yeniden bağlanmalıdır. Server mümkünse close code ile planlı kapanışı bildirebilir. Kaç connection'ın force disconnect edildiği metric olarak kaydedilmelidir. Yüksek oran drain süresinin veya reconnect politikasının gözden geçirilmesi gerektiğini gösterir.

Kubernetes Rolling Deployment ve WebSocket

Rolling deployment WebSocket servislerinde klasik stateless HTTP servisinden daha dikkatli yönetilmelidir. Pod termination doğrudan aktif client connection'larını etkiler. preStop hook, readiness ve termination grace birlikte connection draining akışını oluşturabilir. PodDisruptionBudget aynı anda çok fazla pod'un kaybolmasını önleyebilir. Zero-downtime hedefi client reconnect yeteneği ve protocol compatibility ile birlikte ele alınmalıdır.

Pod Termination

Pod termination başladığında process'e shutdown sinyali gönderilir. Endpoint removal ve actual traffic stop arasında kısa gecikme olabilir. Uygulama yeni connection kabulünü kendi tarafında da durdurmalıdır. Existing connection count sıfıra yaklaşana kadar beklenebilir. Deadline sonunda pod sonlandırılır.

PreStop Hook

PreStop hook termination öncesinde application veya shell tabanlı hazırlık adımı çalıştırabilir. Readiness propagation için kısa bekleme uygulanabilir. Hook süresi termination grace süresinin parçasıdır. Gereksiz uzun sleep deployment hızını düşürür. En doğru yaklaşım gerçek endpoint propagation davranışını ölçmektir.

terminationGracePeriodSeconds

Bu değer pod'un zorla kapatılmadan önce sahip olduğu maksimum süreyi belirler. WebSocket connection lifetime çok uzun olduğu için default değer yetersiz olabilir. Ancak saatlerce beklemek de rollout'u pratik olmaktan çıkarır. Client reconnect protokolü daha kısa grace süresini mümkün kılar. Değer drain testleriyle doğrulanmalıdır.

Readiness Probe

Readiness probe pod'un yeni trafik kabul edip edemeyeceğini gösterir. Draining state başladığında false dönmelidir. Overloaded pod yeni connection kabulünü geçici olarak durdurmak için de readiness kullanabilir, ancak flapping riski yönetilmelidir. Probe çok sık ve pahalı işlem yapmamalıdır. Connection capacity bilgisi lightweight biçimde değerlendirilebilir.

PodDisruptionBudget

PodDisruptionBudget planlı disruption sırasında minimum kullanılabilir replica sayısını korumaya yardımcı olur. WebSocket gateway'de aynı anda çok fazla pod'un drain edilmesini engelleyebilir. Capacity headroom olmadan yalnız replica sayısı korumak yeterli değildir. Remaining pod'ların connection kapasitesi ölçülmelidir. Cluster maintenance senaryoları load test ile denenebilir.

Zero-Downtime Deployment

WebSocket için zero-downtime her connection'ın hiç kopmaması anlamına gelmeyebilir. Daha gerçekçi hedef kontrollü reconnect ve mesaj kaybı olmamasıdır. Protocol versioning yeni ve eski server sürümlerinin aynı anda çalışmasına izin vermelidir. Draining ve resume desteği kullanıcı kesintisini azaltır. Deployment başarısı disconnect spike ve reconnect latency üzerinden ölçülmelidir.

WebSocket Reconnect Stratejisi Nasıl Tasarlanır?

WebSocket bağlantıları network, pod restart veya load balancer problemi nedeniyle zaman zaman kopacaktır. İyi client tasarımı reconnect'i beklenen bir durum olarak ele alır. Immediate retry bütün client'ların aynı anda yeniden bağlanmasına yol açabilir. Exponential backoff ve random jitter bu yükü zamana yayar. Connection resume mekanizması kullanıcı deneyimini ve mesaj bütünlüğünü korur.

Immediate Retry Problemi

Client bağlantı kapanır kapanmaz sürekli retry yaparsa failure anında server üzerinde ek yük oluşturur. Binlerce client aynı davranışı gösterdiğinde handshake flood oluşabilir. Sorun devam ettiği sürece retry trafiği normal trafiği geçebilir. Bu durum recovery süresini uzatır. Client SDK varsayılan retry davranışı production gereksinimine göre kontrol edilmelidir.

Exponential Backoff

Exponential backoff her başarısız denemeden sonra bekleme süresini artırır. İlk retry hızlı olabilir, sonraki denemeler daha seyrek yapılır. Bu yaklaşım geçici failure sırasında backend üzerindeki baskıyı azaltır. Maximum backoff kullanıcı deneyimini sınırlı tutar. Başarılı bağlantı sonrası backoff state sıfırlanabilir.

Random Jitter

Jitter bekleme süresine rastgelelik ekler. Bütün client'ların aynı saniyede retry yapmasını engeller. Özellikle deployment veya region outage sonrasında büyük fark yaratır. Jitter aralığı toplam backoff süresine göre seçilebilir. Client implementasyonu testte deterministic seed kullanarak doğrulanabilir.

Maximum Backoff

Maximum backoff retry süresinin sonsuza kadar büyümesini engeller. Kullanıcı bağlantının geri geldiğini makul sürede fark edebilmelidir. Çok düşük maksimum değer uzun outage sırasında gereksiz load üretir. Çok yüksek değer recovery sonrasında kullanıcıyı uzun süre offline bırakabilir. Ürün SLA ve connection rate kapasitesi birlikte değerlendirilmelidir.

Retry Budget

Retry budget belirli zaman aralığında yapılabilecek maksimum retry sayısını sınırlar. Client sonsuz hızlı retry döngüsüne giremez. Server da 429 veya custom signal ile backoff önerisi gönderebilir. Retry budget failure senaryolarında capacity koruması sağlar. Monitoring reconnect attempts per client dağılımını izleyebilir.

Connection Resume

Connection resume client'ın yeniden bağlandığında önceki session veya event stream'e devam etmesini sağlar. Last sequence ID veya resume token kullanılabilir. Server kaçırılan mesajları replay buffer'dan gönderebilir. Buffer retention sınırlıysa çok eski session full resync yapabilir. Bu mekanizma deployment kaynaklı kısa disconnect'leri kullanıcı açısından görünmez hale getirebilir.

Reconnect Storm Nedir?

Reconnect storm çok sayıda client'ın kısa sürede yeniden bağlantı kurmaya çalışmasıdır. Load balancer failure, pod kaybı veya region problemi bunu tetikleyebilir. Normalde stabil olan sistem bir anda yüksek TCP, TLS ve authentication yükü görür. Reconnect storm kapasitesi normal steady-state connection rate'ten çok daha yüksek olabilir. Bu nedenle load test senaryoları özellikle toplu reconnect davranışını içermelidir.

Load Balancer Failure

Load balancer instance kaybı birçok active connection'ı aynı anda kesebilir. Client'lar failover endpoint'e reconnect etmeye başlar. Yeni load balancer hem normal trafik hem handshake burst taşır. Multi-instance veya managed HA yapı tek hata noktasını azaltır. Reconnect jitter yine gereklidir.

Pod Failure

Tek pod crash olduğunda o pod üzerindeki bütün connection'lar aynı anda kopar. Pod başına çok yüksek connection yoğunluğu failure blast radius'u büyütür. Client'lar diğer pod'lara yeniden bağlanır. Remaining capacity bu ani yükü kaldırabilmelidir. Failure capacity planı en az bir node kaybını hesaba katmalıdır.

Region Failure

Region failure çok daha büyük connection kitlesini etkileyebilir. Global load balancer kullanıcıları başka region'a yönlendirebilir. Failover region normalde taşıdığından çok daha fazla connection kabul etmek zorunda kalır. Warm capacity ve shared state replication gerekir. Cross-region reconnect load testi kritik bir disaster recovery senaryosudur.

Binlerce Client'ın Aynı Anda Bağlanması

Binlerce client aynı saniyede connect olduğunda TLS ve authentication CPU yükü yükselir. Backend accept queue ve load balancer connection rate limiti zorlanabilir. Normal messages per second düşük olsa bile handshake path bottleneck olabilir. Connection ramp-up testleri bu kapasiteyi ölçer. Jitter client başlangıç trafiğinde de kullanılabilir.

Thundering Herd

Thundering herd çok sayıda client veya worker'ın aynı olaya eş zamanlı tepki vermesidir. Reconnect storm bunun network tarafındaki tipik örneğidir. Shared backoff değeri bütün client'ları yine aynı anda uyandırabilir. Random jitter bu senkronizasyonu bozar. Server-side rate limiting ek koruma sağlayabilir.

Reconnect Storm Nasıl Önlenir?

Exponential backoff, jitter ve retry budget ilk savunma katmanıdır. Server tarafında connection rate limit ve overload response kullanılabilir. Deployment sırasında connection draining ani disconnect sayısını azaltır. Region ve node failure için spare capacity bırakılmalıdır. Load test gerçek client reconnect algoritmasını kullanarak yapılmalıdır.

WebSocket Heartbeat Nasıl Tasarlanır?

Heartbeat bağlantının canlı olup olmadığını anlamak ve idle timeout'ları önlemek için düzenli sinyal gönderme yöntemidir. WebSocket protocol ping/pong frame'leri kullanılabilir. Bazı uygulamalar ayrıca application-level heartbeat gönderir. Interval çok kısa olursa milyonlarca gereksiz mesaj oluşabilir. Timeout ise dead connection'ların ne kadar hızlı temizleneceğini belirler.

Ping/Pong Frame

WebSocket protocol ping ve pong control frame desteği sunar. Server ping gönderip client pong yanıtını izleyebilir. Bazı client library'leri bunu otomatik yönetir. Ping delivery application message queue'dan ayrı ele alınabilir. Failure detection süresi interval ve timeout kombinasyonuna bağlıdır.

Application-Level Heartbeat

Application heartbeat transport bağlantısının yanında uygulama session'ının da aktif olduğunu gösterebilir. Timestamp, sequence veya minimal metadata içerebilir. Protocol ping destekleri platformlar arasında farklı davranıyorsa kullanılabilir. Gereksiz büyük payload gönderilmemelidir. Heartbeat authentication yenileme gibi ağır işlemler tetiklememelidir.

Heartbeat Interval

Interval iki heartbeat arasındaki süreyi belirler. Load balancer idle timeout'tan daha kısa olmalıdır. Çok kısa değer battery ve bandwidth tüketimini artırır. Çok uzun değer dead connection detection süresini uzatır. Mobil ve desktop client için farklı profil değerlendirilebilir.

Heartbeat Timeout

Timeout heartbeat yanıtı gelmediğinde connection'ın ne zaman ölü kabul edileceğini belirler. Tek kayıp paket nedeniyle bağlantıyı hemen kapatmak agresif olabilir. Birkaç interval toleransı eklenebilir. Çok uzun timeout stale socket'in memory ve registry'de kalmasına neden olur. Network koşullarıyla gerçek test yapılmalıdır.

Dead Connection Detection

Client internet bağlantısını kaybettiğinde server her zaman anında disconnect event'i alamaz. Heartbeat bu half-open durumu belirli süre içinde tespit eder. Connection registry temizliği bu sinyale bağlanabilir. Presence sistemi kullanıcıyı offline yapmadan önce kısa grace period kullanabilir. Böylece kısa network geçişlerinde kullanıcı durumu gereksiz dalgalanmaz.

Half-Open Connection

Half-open connection taraflardan birinin bağlantıyı canlı sanarken diğer tarafın artık erişilemez olduğu durumdur. Mobil network değişimleri bunu oluşturabilir. TCP keepalive tek başına yeterince hızlı olmayabilir. Application heartbeat daha kontrollü failure detection sağlar. Detected connection kapatılmalı ve registry kaydı temizlenmelidir.

Idle Timeout Problemi

WebSocket bağlantısı mesaj taşımadığında farklı network katmanları onu idle kabul edip kapatabilir. Load balancer, reverse proxy, NAT ve firewall farklı timeout değerlerine sahip olabilir. Kullanıcı tarafında kopma belirli aralıklarla tekrar ediyorsa timeout zinciri incelenmelidir. Heartbeat bağlantıyı aktif tutabilir. Fakat çok kısa heartbeat yüksek connection sayısında ciddi trafik ve battery maliyeti oluşturur.

Load Balancer Idle Timeout

Load balancer belirli süre trafik görmeyen connection'ı kapatabilir. Managed platformların varsayılanları farklıdır. WebSocket uygulaması bu değeri bilmelidir. Heartbeat interval güvenli payla daha kısa seçilebilir. Timeout kaynaklı disconnect pattern'i sabit zaman aralıklarında görülebilir.

Reverse Proxy Timeout

NGINX veya başka proxy kendi read timeout değerini uygulayabilir. Load balancer uzun timeout'a sahip olsa bile iç proxy bağlantıyı erken kapatabilir. Bütün hop'lar birlikte incelenmelidir. Config standardı environment'lar arasında eşit tutulmalıdır. Synthetic connection testi uzun süre açık kalmayı doğrulamalıdır.

NAT Timeout

NAT cihazları uzun süre trafik taşımayan connection mapping'lerini temizleyebilir. Mobil operatör ağlarında davranış değişken olabilir. Server tek bir timeout değeriyle bütün client koşullarını kontrol edemez. Heartbeat yeterli sıklıkta network trafiği oluşturarak mapping'i koruyabilir. Çok agresif heartbeat mobil veri ve enerji tüketimini artırır.

Firewall Timeout

Kurumsal firewall'lar idle TCP session için ayrı limit uygulayabilir. Kullanıcıların sadece belirli network'te bağlantı kaybetmesi bu duruma işaret edebilir. WSS kullanımı proxy uyumluluğunu artırabilir ancak timeout sorununu tamamen çözmez. Client telemetry network type bilgisini anonim biçimde sınıflandırabilir. Support sorunlarında disconnect interval önemli ipucudur.

Heartbeat ile Bağlantıyı Canlı Tutmak

Heartbeat düzenli küçük mesaj göndererek connection'ın idle görünmesini engeller. Interval en kısa timeout'tan daha düşük olmalıdır. Bütün client'ların heartbeat'ini aynı saniyeye sabitlemek trafik dalgası oluşturabilir. Küçük jitter uygulanabilir. Heartbeat delivery rate monitoring ile izlenebilir.

Çok Kısa Heartbeat'in Maliyeti

Bir milyon connection her on saniyede heartbeat gönderirse saniyede yüz bin ek mesaj oluşabilir. Network, CPU ve broker kapasitesi gereksiz tüketilir. Mobil client battery kullanımı artar. Heartbeat sadece gerekli failure detection ve timeout hedefini karşılayacak sıklıkta olmalıdır. Kapasite hesabında heartbeat trafiği normal message rate'e eklenmelidir.

Backpressure Nedir?

Backpressure producer'ın veri üretme hızının consumer'ın işleme hızını aşması durumunda sistemi koruyan kontrol mekanizmasıdır. WebSocket'te server hızlı mesaj üretirken client'ın network bağlantısı yavaş olabilir. Mesajlar send queue içinde birikirse memory tüketimi sınırsız büyüyebilir. Queue limit, drop policy veya disconnect gibi kurallar gerekir. Backpressure olmadan birkaç slow consumer bütün node'un memory'sini tüketebilir.

Producer Consumer'dan Hızlıysa Ne Olur?

Server saniyede yüz mesaj üretirken client yalnızca yirmi mesaj okuyabiliyorsa backlog oluşur. İlk başta buffer farkı gizleyebilir. Zamanla queue sürekli büyür. Latency saniyelere çıkar ve client artık gerçek zamanlı veri görmez. Sistem bu durumda mesajları birleştirmeli, düşürmeli veya connection'ı kapatmalıdır.

Send Queue

Send queue henüz socket'e yazılamayan mesajları tutar. Her connection için sınırsız queue tehlikelidir. Queue length ve queue bytes limitleri tanımlanabilir. Kritik ve önemsiz mesajlar farklı priority ile yönetilebilir. Queue depth metric slow consumer detection için temel sinyaldir.

Buffer Growth

Buffer growth consumer'ın uzun süre geride kaldığını gösterir. Memory allocation connection sayısıyla çarpıldığında hızla büyüyebilir. Garbage collection veya OOM riski oluşur. Queue limit aşımında uygulanacak politika önceden belirlenmelidir. Runtime buffer behavior load test sırasında gözlemlenmelidir.

Memory Exhaustion

Unbounded queue node memory'sini tamamen tüketebilir. Container OOM nedeniyle kapanırsa o node üzerindeki bütün client'lar reconnect eder. Bu olay reconnect storm'u tetikleyebilir. Bir slow consumer'ın cluster failure'a dönüşmemesi gerekir. Per-connection memory limit koruma sağlar.

Slow Consumer

Slow consumer mesajları server'ın gönderdiği hızda işleyemeyen client'tır. Zayıf mobil network, arka planda kalan uygulama veya yavaş cihaz buna neden olabilir. Slow consumer count production metriği olmalıdır. Uygulama türüne göre son durum mesajı eski mesajların yerini alabilir. Gerekiyorsa client kontrollü biçimde disconnect edilir.

Message Drop

Bazı realtime verilerde eski mesajın değeri kalmaz. Örneğin her ara fiyat güncellemesini teslim etmek yerine en güncel fiyat yeterli olabilir. Bu durumda queue dolunca eski mesajlar drop edilebilir. Chat veya finansal emir gibi durable event'lerde aynı politika kullanılamaz. Message class bazlı delivery semantics tanımlanmalıdır.

Connection Termination

Client sürekli geride kalıyorsa connection'ı kapatmak node'u koruyabilir. Server uygun close reason gönderir. Client reconnect sonrası daha düşük subscription veya snapshot modeli kullanabilir. Disconnect son seçenek olarak görülmelidir. Slow client'ın tekrar aynı yükü oluşturmasını önleyen rate limit gerekebilir.

Slow Consumer Problemi Nasıl Çözülür?

Slow consumer çözümünde temel hedef unbounded memory growth'u engellemektir. Queue limit belirlemek ilk adımdır. Message türüne göre coalescing, drop veya priority policy uygulanabilir. State update uygulamalarında yalnız en güncel değeri göndermek çoğu zaman yeterlidir. Kritik event'lerde ise durable queue ve acknowledgement modeli gerekebilir.

Queue Limit

Her connection için maksimum queue message veya byte sayısı belirlenebilir. Limit uygulama memory budget'ına göre hesaplanmalıdır. Queue dolduğunda ne yapılacağı açık olmalıdır. Sessizce sınırsız büyümeye izin verilmemelidir. Limit hit rate monitoring ile izlenmelidir.

Message Coalescing

Coalescing aynı konuya ait birden fazla bekleyen update'i tek mesaja birleştirir. Position veya fiyat gibi state tabanlı event'lerde etkilidir. Client bütün ara durumları almak zorunda değildir. Queue küçülür ve network trafiği azalır. Event türünün semantiği coalescing'e uygun olmalıdır.

Drop Policy

Drop policy hangi mesajın queue dolduğunda silineceğini belirler. Oldest, newest veya priority bazlı yaklaşım kullanılabilir. Kritik message asla sessizce drop edilmemelidir. Metric dropped_messages_total olarak tutulabilir. User experience bu davranışa göre tasarlanmalıdır.

Latest-State-Only Model

Latest-state-only yaklaşımında client yalnızca en güncel durumu alır. Ara update'ler queue'da birikmez. Dashboard, fiyat veya presence gibi state stream'lerinde kullanışlıdır. Client reconnect olduğunda full snapshot alabilir. Bu model event history gereken sistemler için uygun değildir.

Priority Messaging

Priority messaging kritik kontrol mesajlarını normal data mesajlarından ayırır. Heartbeat, auth refresh veya disconnect sinyali yoğun data queue arkasında kalmamalıdır. Farklı queue veya priority level kullanılabilir. Starvation oluşmaması için düşük öncelikli trafiğe de kapasite ayrılmalıdır. Scheduling davranışı load test ile doğrulanmalıdır.

Slow Client'ı Disconnect Etmek

Client belirlenen süre boyunca queue limitini aşarsa connection kapatılabilir. Bu işlem server'ın memory'sini korur. Client yeniden bağlandığında snapshot veya resume akışı kullanabilir. Sürekli slow kalan client için düşük rate subscription uygulanabilir. Disconnect metric'i client platform ve network türüyle anonim biçimde analiz edilebilir.

WebSocket Mesaj Performansı Nasıl Artırılır?

Mesaj performansı sadece socket throughput ile ilgili değildir. Payload boyutu, serialization formatı, batching ve compression CPU ile network maliyetini belirler. Çok küçük ve sık mesajlar header ve syscall overhead'i oluşturabilir. Çok büyük mesajlar ise latency ve memory kullanımını artırır. En iyi format uygulamanın message rate ve client platformlarına göre benchmark edilmelidir.

Küçük Mesajlar

Küçük payload düşük network transferi sağlar. Ancak saniyede çok fazla küçük mesaj gönderildiğinde per-message overhead büyüyebilir. Header, scheduling ve syscall maliyetleri toplama dönüşür. Batching uygun event türlerinde verim sağlayabilir. Realtime latency hedefi batching window'u sınırlar.

Batching

Batching birden fazla küçük event'i tek mesaj içinde gönderir. Network frame ve serialization overhead'i azalabilir. Çok uzun batch interval kullanıcı latency'sini artırır. 5 veya 10 milisaniyelik kısa window bazı yüksek throughput sistemlerinde faydalı olabilir. Benchmark gerçek client parse süresini de ölçmelidir.

Binary Payload

Binary payload text tabanlı formata göre daha küçük olabilir. Client ve server parsing maliyeti kullanılan schema'ya bağlıdır. Browser ve mobil platform desteği genellikle yeterlidir. Debugging JSON kadar kolay olmayabilir. Protocol versioning ve schema yönetimi daha önemli hale gelir.

JSON

JSON okunabilir ve geniş platform desteğine sahiptir. Küçük ve orta ölçekli realtime sistemlerde geliştirme hızını artırır. Büyük message rate'te serialization CPU ve payload boyutu sorun olabilir. Gereksiz field isimleri network maliyetini artırır. Optimize etmeden önce profiler ile JSON'un gerçekten darboğaz olduğu doğrulanmalıdır.

Protocol Buffers

Protocol Buffers schema tabanlı binary serialization sağlar. Payload boyutu JSON'dan küçük olabilir ve parsing verimli olabilir. Client generation ve schema versioning süreçleri gerekir. Browser entegrasyonu ek toolchain isteyebilir. Yüksek throughput ve bandwidth-sensitive sistemlerde benchmark edilmeye değerdir.

MessagePack

MessagePack JSON benzeri veri modelini binary formatta taşır. Payload küçültme ve hızlı parse avantajı sağlayabilir. Ek schema zorunluluğu Protocol Buffers kadar güçlü değildir. Library compatibility bütün client platformlarında doğrulanmalıdır. Gerçek kazanç payload yapısına göre ölçülmelidir.

Serialization Maliyeti

Serialization her outgoing message için CPU kullanır. Aynı broadcast payload binlerce client'a gidecekse her client için tekrar serialize etmek gereksiz olabilir. Pre-serialized immutable buffer kullanılabilir. Personalized message'larda bu optimizasyon sınırlı kalır. CPU profiler serialization'ın toplam maliyetteki payını göstermelidir.

WebSocket Compression Kullanılmalı mı?

Compression network bandwidth'i azaltabilir, fakat CPU ve memory maliyeti oluşturur. Küçük mesajlarda sıkıştırma overhead'i payload kazancından daha büyük olabilir. Büyük text mesajlarda fayda daha belirgin hale gelir. permessage-deflate gibi yöntemler client desteğine göre kullanılabilir. Compression kararı mutlaka CPU, p99 latency ve egress byte benchmark'ı ile verilmelidir.

permessage-deflate

permessage-deflate WebSocket mesajlarını sıkıştırmak için yaygın extension'lardan biridir. Handshake sırasında client ve server destek üzerinde anlaşır. Context takeover seçenekleri compression ratio ile memory arasında trade-off oluşturabilir. Yüksek connection sayısında per-connection state memory maliyeti önemlidir. Güvenlik ve CPU etkisi production testlerinde izlenmelidir.

Bandwidth Tasarrufu

Text ağırlıklı büyük payload'larda compression egress bandwidth'i ciddi azaltabilir. Cloud data transfer maliyeti de düşebilir. Zaten küçük veya binary compressed veri üzerinde kazanç düşük olabilir. Compression ratio message type bazında ölçülmelidir. Tek bir global ayar yerine belirli endpoint veya client sınıflarında farklı politika düşünülebilir.

CPU Maliyeti

Sıkıştırma ve açma CPU tüketir. High fan-out sisteminde aynı mesajın tekrar tekrar compress edilmesi pahalı olabilir. Pre-compressed shared payload bazı durumlarda kullanılabilir. CPU saturation event-loop latency'yi artırabilir. Compression seviyesi daha düşük seçilerek denge kurulabilir.

Küçük Mesajlarda Compression

Çok küçük mesajlarda compression header ve işlem maliyeti avantajı ortadan kaldırabilir. Mesaj sıkıştırıldıktan sonra daha büyük bile olabilir. Minimum payload threshold uygulanabilir. Heartbeat gibi küçük control mesajları sıkıştırılmamalıdır. Benchmark message size dağılımına göre yapılmalıdır.

Büyük Mesajlarda Compression

Büyük JSON veya text mesajları compression için daha uygun adaydır. Bandwidth ve transfer süresi düşebilir. CPU maliyeti server ve client cihazında ayrı değerlendirilmelidir. Mobil cihazlarda battery etkisi önemlidir. Çok büyük mesajların kendisi de protocol design açısından sorgulanmalıdır.

Compression Benchmark

Benchmark compression açık ve kapalı senaryoda aynı traffic pattern ile yapılmalıdır. CPU, network bytes, p95 latency ve memory ölçülmelidir. Farklı compression seviyeleri karşılaştırılabilir. Real message corpus kullanılmalıdır. Sentetik tekrar eden metin gerçek compression ratio'yu olduğundan iyi gösterebilir.

WebSocket Mesaj Boyutu Nasıl Sınırlandırılır?

Message size limiti performans ve güvenlik açısından önemlidir. Client tek mesajla çok büyük memory allocation yaptırabilir. Maximum frame ve total message boyutu ayrı sınırlandırılabilir. Fragmentation desteği limit kontrolünü atlamamalıdır. Payload validation authentication sonrasında da uygulanmalıdır.

Maximum Frame Size

WebSocket message birden fazla frame'e bölünebilir. Frame size limiti tek parçanın memory etkisini sınırlar. Ancak toplam fragmented message yine çok büyük olabilir. Runtime library'nin default değeri kontrol edilmelidir. Aşım durumunda connection güvenli biçimde kapatılabilir.

Maximum Message Size

Maximum message size bütün fragment'ler birleştirildikten sonraki toplam payload sınırıdır. Uygulama protokolünün gerçek ihtiyaçlarına göre seçilmelidir. Chat mesajı ile dosya transferi aynı limite sahip olmak zorunda değildir. Büyük dosya için WebSocket yerine object storage upload daha uygun olabilir. Limit aşım metric'i abuse veya client bug sinyali olabilir.

Fragmentation

Fragmentation büyük message'ın birden fazla frame halinde taşınmasını sağlar. Receiver parçaları birleştirirken memory kullanır. Attack client sonsuz fragment göndermeye çalışabilir. Total message ve timeout limiti uygulanmalıdır. Parser incomplete message state'ini sınırlı tutmalıdır.

Memory DoS Riski

Saldırgan çok büyük message veya çok sayıda yarım fragment göndererek memory tüketmeye çalışabilir. Connection başına buffer limiti bunu azaltır. Authentication öncesi limitler daha sıkı olabilir. Global memory pressure halinde yeni connection rate düşürülebilir. Security testleri slow upload ve oversized payload senaryolarını kapsamalıdır.

Payload Validation

Payload schema ve field limitleri server'da doğrulanmalıdır. JSON içindeki nested structure veya array uzunluğu kontrol edilebilir. Binary protocol version ve message type doğrulanmalıdır. Invalid payload hızlı ve düşük maliyetle reddedilmelidir. Validation işlemi CPU DoS yaratacak kadar pahalı olmamalıdır.

WebSocket Güvenliği

WebSocket uzun ömürlü bağlantı sağladığı için authentication ve authorization yalnız handshake anına bırakılmamalıdır. WSS ile trafik şifrelenmelidir. Origin validation browser tabanlı kötüye kullanımı azaltır. Her message türünde kullanıcı yetkisi kontrol edilmelidir. Rate limiting ve payload sınırları performans güvenliğinin önemli parçalarıdır.

WSS / TLS

WSS client ile server arasındaki WebSocket trafiğini TLS ile şifreler. İnternet üzerinden taşınan token ve mesaj içeriğini korur. TLS termination load balancer üzerinde yapılabilir. Backend bağlantısının ayrıca şifrelenmesi güvenlik modeline bağlıdır. Certificate ve protocol ayarları düzenli güncellenmelidir.

Origin Validation

Browser WebSocket handshake'inde Origin header gönderir. Server izin verilen origin listesini kontrol edebilir. Bu kontrol cross-site saldırı riskini azaltır. Origin tek authentication mekanizması değildir. Native client davranışı farklı olabileceği için client türüne göre security policy uygulanmalıdır.

Authentication

Authentication bağlantıyı açan kullanıcının kimliğini doğrular. Cookie, JWT veya kısa ömürlü token kullanılabilir. Token query string içinde taşınırsa log sızıntısı riski oluşabilir. Handshake sonrası session context minimum bilgiyle tutulmalıdır. Token expiry uzun bağlantılarda ayrıca ele alınmalıdır.

Authorization

Kullanıcının authenticated olması her room veya event'e erişebileceği anlamına gelmez. Join, publish ve subscribe işlemlerinde authorization yapılmalıdır. Yetki değişiklikleri uzun bağlantıda güncellenebilir. Server sadece client'ın gönderdiği room ID'ye güvenmemelidir. Tenant isolation kuralları merkezi policy ile uygulanmalıdır.

Cross-Site WebSocket Hijacking

Browser cookie authentication kullanıldığında kötü niyetli site kullanıcının cookie'siyle WebSocket açmaya çalışabilir. Origin validation ve CSRF benzeri handshake koruması önemlidir. Sensitive action için message-level authorization yine uygulanmalıdır. Cookie SameSite davranışı WebSocket akışıyla birlikte test edilmelidir. Güvenlik yalnız client JavaScript kontrolüne bırakılamaz.

Payload Validation

Her incoming message schema ve size açısından doğrulanmalıdır. Invalid field veya beklenmeyen type iş mantığına ulaşmadan reddedilmelidir. JSON parser limitleri kullanılabilir. Binary decoder malformed payload'a dayanıklı olmalıdır. Error response saldırgana gereksiz internal bilgi vermemelidir.

Rate Limiting

Connection ve message rate limit abuse'u sınırlar. User ve IP bazlı quota birlikte kullanılabilir. NAT ortamında yalnız IP limiti meşru kullanıcıları etkileyebilir. Authentication öncesi global veya IP rate limit daha sıkı olabilir. Limit hit metric'i operasyon ve security ekibi tarafından izlenmelidir.

WebSocket Authentication Nasıl Yapılır?

Authentication handshake sırasında veya bağlantı kurulduktan hemen sonra application message ile yapılabilir. Tarayıcı API'sinin custom header sınırlamaları token taşıma yöntemini etkileyebilir. Cookie veya short-lived ticket yaygın çözümlerdir. Uzun connection boyunca token süresi dolabilir. Yetki yenileme ve session revocation davranışı protokol içinde tanımlanmalıdır.

Handshake Sırasında Authentication

Handshake request mevcut HTTP authentication mekanizmalarını kullanabilir. Cookie veya reverse proxy tarafından doğrulanmış identity backend'e aktarılabilir. Başarısız authentication upgrade yapılmadan reddedilir. Bu yaklaşım unauthenticated connection resource kullanımını azaltır. Auth service latency handshake kapasitesini etkileyebilir.

Cookie

Browser cookie'leri WebSocket handshake ile otomatik gönderilebilir. Session-based web uygulamalarında entegrasyon kolaydır. Origin validation kritik hale gelir. Multi-domain deployment cookie scope açısından dikkat ister. Server cookie session'ını connection açıldıktan sonra sürekli geçerli varsaymamalıdır.

JWT

JWT stateless authentication için kullanılabilir. Token signature server tarafından doğrulanır ve user claim'leri connection context'e alınabilir. Çok uzun expiry güvenlik riskini artırır. Token revocation ihtiyacı varsa ek store gerekebilir. Message authorization yalnız token claim'lerinin eski kalmadığı varsayımına dayanmamalıdır.

Short-Lived Token

WebSocket bağlantısı için özel kısa ömürlü ticket üretilebilir. Normal API token'ı query string içinde taşımak yerine tek kullanımlık token kullanılabilir. Handshake tamamlandıktan sonra ticket geçersiz hale getirilebilir. Replay riski azalır. Token üretim servisi connection burst kapasitesini desteklemelidir.

Token Expiry

Connection açıkken authentication token süresi dolabilir. Server bağlantıyı hemen kapatabilir veya refresh protokolü uygulayabilir. Uzun süreli uygulamalarda saatlerce eski yetkiyle bağlantı sürdürmek risklidir. Expiry yakınken client'a refresh sinyali gönderilebilir. Refresh başarısızsa controlled disconnect yapılmalıdır.

Uzun Bağlantıda Yetki Yenileme

Kullanıcının rolü veya tenant yetkisi connection sırasında değişebilir. Server periyodik veya event-driven authorization refresh yapabilir. Her mesajda database sorgulamak gereksiz maliyet oluşturur. Versioned auth state veya cache kullanılabilir. Kritik yetki iptali hızlı propagation mekanizmasına sahip olmalıdır.

WebSocket Rate Limiting

WebSocket rate limiting yalnız handshake sayısını değil connection ve message davranışını birlikte kontrol etmelidir. Bir kullanıcı tek connection üzerinden saniyede binlerce mesaj gönderebilir. Bir başka kullanıcı yüzlerce idle connection açabilir. Bu iki abuse modeli farklı limiter gerektirir. Quota sistemi user, tenant ve IP seviyesinde birlikte uygulanabilir.

Connection Rate Limit

Connection rate limit belirli sürede açılabilecek yeni bağlantı sayısını sınırlar. Reconnect loop ve handshake flood'a karşı koruma sağlar. IP ve user bazlı değerler ayrı olabilir. Legitimate mobile network geçişleri tolerans ister. Limit aşımında client'a backoff bilgisi verilebilir.

Concurrent Connection Limit

Concurrent limit tek user veya tenant'ın aynı anda kaç açık connection tutabileceğini sınırlar. Bot veya bug kaynaklı connection leak'i engeller. Multi-device kullanım için makul pay bırakılmalıdır. Eski stale connection'lar doğru temizlenmezse kullanıcı yanlışlıkla limite takılabilir. Registry doğruluğu bu nedenle önemlidir.

Message Rate Limit

Message rate limit client'ın saniyede kaç mesaj gönderebileceğini kontrol eder. Event type'a göre farklı limit uygulanabilir. Chat mesajı ile cursor update aynı quota'ya sahip olmak zorunda değildir. Burst allowance kısa kullanıcı hareketlerini tolere eder. Sürekli aşım connection termination'a yol açabilir.

Bytes-per-Second Limit

Mesaj sayısı düşük olsa bile client çok büyük payload gönderebilir. Bytes-per-second limiti bandwidth ve parsing maliyetini sınırlar. Upload benzeri yoğun iş WebSocket'ten ayrılabilir. Limit application protocol'e göre seçilmelidir. Inbound ve outbound quota farklı olabilir.

User-Based Quota

User quota authenticated kullanıcının toplam bağlantı ve mesaj tüketimini sınırlar. Kullanıcı farklı IP'lerden bağlansa bile aynı limit uygulanabilir. Premium veya farklı ürün planlarında farklı quota tanımlanabilir. Quota merkezi state store üzerinde tutulabilir. Her message için remote counter çağrısı yapmadan local token bucket ve periyodik sync kullanılabilir.

IP-Based Quota

IP quota authentication öncesi abuse kontrolünde faydalıdır. NAT arkasındaki çok sayıda gerçek kullanıcı aynı IP'yi paylaşabilir. Bu nedenle threshold çok agresif olmamalıdır. Known proxy header'larına güven yalnız trusted edge üzerinden yapılmalıdır. IPv6 adres gruplaması ayrıca düşünülmelidir.

WebSocket DDoS Koruması

WebSocket DDoS yalnız yüksek bandwidth saldırısı değildir. Çok sayıda handshake, idle connection veya message flood server kaynaklarını tüketebilir. Edge rate limit ve connection quota ilk savunma katmanıdır. Authentication öncesi yapılan pahalı işlemler minimumda tutulmalıdır. WAF ve network protection application-level limiter'larla birlikte kullanılmalıdır.

Handshake Flood

Saldırgan saniyede çok sayıda WebSocket handshake başlatabilir. TLS ve authentication CPU'su tüketilir. Connection rate limit ve edge protection bu trafiği azaltır. Incomplete handshake timeout kısa tutulabilir. Handshake failure ve rate metric'leri security dashboard'da görünmelidir.

Connection Exhaustion

Saldırgan çok sayıda connection açıp açık tutarak file descriptor ve memory tüketebilir. Concurrent IP ve user limitleri yardımcı olur. Authentication olmayan connection için daha kısa idle timeout uygulanabilir. Global capacity threshold yeni bağlantıları kontrollü reddedebilir. Meşru kullanıcılar için reserve capacity düşünülebilir.

Idle Connection Abuse

Idle connection çok az trafik üretirken kaynak tutar. Milyonlarca sahte connection node kapasitesini tüketebilir. Authentication sonrası user quota uygulanmalıdır. Heartbeat'e cevap vermeyen bağlantı hızlı temizlenmelidir. Anonymous realtime erişim gerekiyorsa daha sıkı connection limitleri gerekir.

Message Flood

Tek veya az sayıda connection üzerinden çok yüksek message rate gönderilebilir. Parsing ve business logic CPU tüketir. Message rate ve byte limit ilk katmanda uygulanmalıdır. Ağır iş message doğrulanmadan başlatılmamalıdır. Invalid message flood ayrı metric ve ban sinyali olabilir.

Authentication Öncesi Rate Limit

Unauthenticated kullanıcı hakkında user ID bilgisi bulunmadığı için IP veya edge identity kullanılır. Handshake ve token verification rate sınırlandırılabilir. Çok pahalı database auth sorgusundan kaçınılmalıdır. Short-lived signed ticket hızlı doğrulama sağlayabilir. Limit meşru login burst senaryolarında test edilmelidir.

WAF ve Edge Protection

Edge protection saldırı trafiğini origin'e ulaşmadan azaltabilir. Connection ve request rate kontrolü sağlayabilir. WebSocket upgrade davranışının kullanılan edge ürünü tarafından desteklendiği doğrulanmalıdır. Uygulama-level message flood edge tarafından her zaman anlaşılmayabilir. Bu nedenle origin rate limiting yine gereklidir.

Multi-Tenant WebSocket Mimarisi

Multi-tenant WebSocket sisteminde bir müşterinin yüksek bağlantı veya message trafiği diğer tenant'ları etkilememelidir. Tenant-based quota ve fair scheduling bu nedenle önemlidir. Shared broker topic'leri tenant izolasyonunu koruyacak biçimde tasarlanmalıdır. Connection registry her kayıtta tenant context taşıyabilir. Çok büyük müşteriler için dedicated pool veya partition gerekebilir.

Tenant-Based Connection Quota

Her tenant için maksimum concurrent connection sayısı tanımlanabilir. Limit plan veya sözleşmeye göre değişebilir. Tek tenant bütün cluster socket kapasitesini tüketemez. Quota distributed counter ile izlenebilir. Failover sırasında kısa süreli double connection toleransı gerekebilir.

Message Quota

Tenant message rate quota shared CPU ve broker kapasitesini korur. Incoming ve outgoing rate ayrı hesaplanabilir. Broadcast yapan tenant çok yüksek fan-out oluşturabilir. Quota fan-out amplification'ı da dikkate alabilir. Aşım davranışı throttling veya event drop policy ile belirlenmelidir.

Tenant Isolation

Room ve topic isimleri tenant scope ile ayrılmalıdır. Client başka tenant'ın channel'ına kendi isteğiyle bağlanamamalıdır. Authorization server tarafında yapılmalıdır. Registry lookup tenant ID ile birlikte çalışmalıdır. Cross-tenant mesaj sızıntısı güvenlik testlerinin temel senaryolarından biri olmalıdır.

Noisy Neighbor

Noisy neighbor tek tenant'ın aşırı trafik üreterek shared resource'ları tüketmesidir. CPU, broker ve bandwidth üzerinde etkisi olabilir. Tenant metric'leri bu durumu görünür hale getirir. Fair queue ve quota uygulanabilir. Çok büyük tenant dedicated deployment'a taşınabilir.

Fair Scheduling

Fair scheduling farklı tenant queue'larının dengeli işlenmesini sağlar. Tek yoğun tenant bütün worker kapasitesini tüketmez. Weighted fairness plan seviyelerine göre uygulanabilir. Queue starvation izlenmelidir. Scheduler overhead'i yüksek message rate altında benchmark edilmelidir.

Dedicated Connection Pools

Büyük veya kritik tenant'lar ayrı WebSocket node grubuna yönlendirilebilir. Bu blast radius ve capacity planning'i kolaylaştırır. Routing tenant ID veya hostname üzerinden yapılabilir. Dedicated pool maliyet ve operasyon yükünü artırır. Sadece gerçekten farklı SLA gerektiren müşteriler için kullanılmalıdır.

WebSocket Observability Nasıl Kurulur?

WebSocket observability kısa HTTP request monitoring'inden daha geniş metric seti gerektirir. Active connection, disconnect reason, message rate, queue depth ve reconnect davranışı birlikte izlenmelidir. Loglar connection ID ve trace context ile ilişkilendirilebilir. Distributed tracing uzun connection boyunca sampling stratejisi gerektirir. Prometheus, Grafana ve OpenTelemetry gibi araçlar ortak bir gözlem yapısı kurmaya yardımcı olabilir.

Metrics

Metrics sistem davranışını zaman serisi olarak gösterir. Active connections, messages per second ve latency temel ölçümlerdir. User ID gibi yüksek cardinality değerler label yapılmamalıdır. Pod, region ve protocol version gibi kontrollü label'lar kullanılabilir. SLO dashboard metric'leri doğrudan kullanıcı deneyimiyle ilişkilendirmelidir.

Logs

Connection open, close ve error olayları structured log olarak tutulabilir. Her message'ı loglamak yüksek hacim ve gizlilik riski oluşturur. Connection ID debugging için yeterli correlation sağlayabilir. Token ve payload içeriği loglanmamalıdır. Sampling yoğun normal event'lerde log maliyetini azaltabilir.

Distributed Tracing

Tek WebSocket connection saatler sürdüğü için klasik tek span modeli uygun olmayabilir. Handshake ayrı trace, message handling ayrı span olarak ele alınabilir. Correlation ID connection context'inden taşınabilir. Çok yüksek message rate sampling gerektirir. Broker publish ve consume span'leri cross-node latency analizini kolaylaştırır.

Prometheus

Prometheus numeric WebSocket metric'lerini toplamak için kullanılabilir. Counter, gauge ve histogram tipleri doğru seçilmelidir. Active connections gauge, message total counter, latency histogram olabilir. Label cardinality kontrol altında tutulmalıdır. Scrape interval kısa süreli reconnect spike'ları kaçırmayacak şekilde seçilebilir.

Grafana

Grafana connection, latency ve broker metric'lerini ortak dashboard üzerinde gösterebilir. Node distribution paneli skew'u görünür hale getirir. Deployment annotation reconnect artışını release ile ilişkilendirmeye yardımcı olur. P95 ve p99 latency ayrı gösterilmelidir. Alert paneli yalnız aksiyon alınabilir durumlara odaklanmalıdır.

OpenTelemetry

OpenTelemetry metric, log ve trace correlation için ortak standart sağlar. WebSocket handshake ve message processing instrumentation oluşturulabilir. Broker ile cross-service context taşınabilir. Sampling ve attribute cardinality dikkatle yönetilmelidir. Standardized telemetry farklı runtime'ların aynı operasyon modelinde izlenmesini kolaylaştırır.

WebSocket Sistemlerinde Takip Edilmesi Gereken Metrikler

WebSocket performansını anlamak için connection ve message yaşam döngüsünü temsil eden metric'ler gerekir. Sadece aktif bağlantı sayısı node'un gerçekten ne kadar iş yaptığını göstermez. Message rate, bytes, queue depth ve slow consumer değerleri kapasiteyi tamamlar. Reconnect ve disconnect rate altyapı stabilitesini doğrudan gösterir. Bu metric'ler pod, region ve client version bazında kontrollü biçimde ayrıştırılabilir.

Active Connections

Active connections o anda açık WebSocket socket sayısını gösterir. Pod ve cluster toplamı ayrı izlenmelidir. Capacity threshold bu değere göre hesaplanabilir. Ani düşüş büyük failure veya deployment sinyali olabilir. Ani artış traffic burst veya reconnect dalgasını gösterebilir.

Connections per Node

Node başına connection sayısı load balancing kalitesini gösterir. Min, max ve average değerler karşılaştırılabilir. Yeni pod eklendiğinde dağılım trend'i izlenmelidir. Büyük fark connection skew sinyalidir. Message traffic ile birlikte hot node analizi yapılmalıdır.

Connection Rate

Connection rate saniyede açılan yeni bağlantı sayısını gösterir. Normal gün içi pattern baseline oluşturur. Deployment veya outage sonrası spike hemen görünür. TLS ve authentication kapasitesi bu metric'e duyarlıdır. Autoscaling predictive sinyal olarak kullanabilir.

Disconnect Rate

Disconnect rate belirli sürede kapanan connection sayısını gösterir. Normal mobile churn ile altyapı problemi birbirinden reason code üzerinden ayrılabilir. Deployment sırasında kontrollü artış beklenebilir. Ani beklenmeyen artış network veya backend failure işareti olabilir. Region ve client version kırılımı teşhisi hızlandırır.

Reconnect Rate

Reconnect rate client'ların yeniden bağlantı kurma yoğunluğunu gösterir. Disconnect rate ile birlikte değerlendirilmelidir. Çok yüksek retry sayısı client backoff problemi gösterebilir. Failure sonrası rate'in ne kadar sürede normale döndüğü recovery kalitesini anlatır. Reconnect latency de ayrı histogram olarak tutulabilir.

Messages per Second

Incoming ve outgoing message rate ayrı izlenmelidir. Fan-out sistemi outgoing rate'i incoming rate'in katlarına çıkarabilir. Peak message rate CPU ve broker kapasitesini belirler. Message type bazlı sınırlı metric faydalı olabilir. User bazlı label kullanılmamalıdır.

Bytes per Second

Byte throughput network kapasitesini gösterir. Compression değişikliği sonrası etkisi net biçimde görülebilir. Ingress ve egress ayrı izlenmelidir. Cloud transfer maliyet hesabında temel girdidir. Büyük payload regression'ları bu metric üzerinden fark edilebilir.

Queue Depth

Queue depth broker veya per-connection send buffer için takip edilebilir. Sürekli artış tüketim kapasitesinin yetersiz olduğunu gösterir. Burst sonrası hızlı düşmesi normal olabilir. Queue age bazen length değerinden daha açıklayıcıdır. Slow consumer ve backpressure alarmı için kullanılabilir.

Slow Consumer Count

Slow consumer count queue threshold'u aşan client sayısını gösterir. Network sorunu veya client bug dağılımı anlaşılabilir. Belirli app version'da artış release regression işareti olabilir. Çok yüksek sayı node memory'sini tehdit eder. Disconnect veya drop policy metric ile birlikte izlenmelidir.

Dropped Messages

Dropped messages backpressure politikasının ne kadar devreye girdiğini gösterir. Message type bazında ayrım önemlidir. Best-effort state update drop'u kabul edilebilir olabilir. Kritik event drop değeri sıfıra yakın olmalıdır. Ani artış capacity veya client network problemi gösterebilir.

WebSocket Latency Metrikleri

Realtime sistemde sadece average latency kullanıcı deneyimini anlatmaz. Handshake, message delivery ve reconnect için ayrı latency metric'leri gerekir. P50 tipik davranışı gösterirken p95 ve p99 yavaş kullanıcıları görünür hale getirir. Region ve network türü farkları tail latency üzerinde büyük etki oluşturabilir. WebSocket Bağlantılarında Performans ve Yük Dengeleme çalışmasında en değerli sinyallerden biri p99 latency ile connection skew arasındaki ilişkidir.

Handshake Latency

Handshake latency TCP, TLS, authentication ve backend upgrade süresinin birleşimidir. Reconnect storm sırasında bu değer hızla artabilir. Client-side ve server-side ölçüm fark gösterebilir. Region ve load balancer hop sayısı etkili olur. p95 handshake latency kapasite planında kullanılabilir.

Message Delivery Latency

Message delivery latency event'in üretildiği andan client'a ulaştığı ana kadar geçen süredir. Broker, gateway queue ve network gecikmesi bu değere dahildir. End-to-end timestamp ölçümü daha anlamlıdır. Clock synchronization dikkat gerektirir. Tek node ve cross-node mesajlar ayrı karşılaştırılabilir.

Round-Trip Time

Round-trip time client'tan gönderilen ping veya application message'ın cevabının geri gelme süresidir. Network ve server processing toplamını gösterir. Heartbeat RTT network kalitesi hakkında fikir verebilir. Çok sık ölçüm gereksiz trafik oluşturur. P95 ve region dağılımı faydalıdır.

Reconnect Latency

Reconnect latency bağlantı koptuktan sonra sağlıklı session'ın yeniden kurulmasına kadar geçen süredir. Backoff bilinçli olarak bu süreyi artırabilir. Resume mekanizması user-visible recovery süresini azaltır. Authentication ve state reload maliyeti ölçülmelidir. Failure drill sırasında bu metric ana başarı kriterlerinden biridir.

P50

P50 kullanıcıların yarısının bu değerden daha hızlı deneyim yaşadığını gösterir. Tipik sistem davranışını anlamak için faydalıdır. Ancak tail problemi gizler. P50 iyi görünürken küçük kullanıcı grubu saniyelik gecikmeler yaşayabilir. Realtime SLA yalnız p50 üzerinden tanımlanmamalıdır.

P95

P95 yavaş kullanıcıların önemli bölümünü görünür hale getirir. Load increase ile tail latency'nin nasıl değiştiği gözlemlenebilir. Scaling threshold için p95 event-loop lag veya message latency kullanılabilir. Deployment regression'ları average değerden önce p95'te ortaya çıkabilir. Alert threshold geçmiş baseline'a göre belirlenmelidir.

P99

P99 en yavaş yüzde birlik kullanıcı deneyimini temsil eder. Connection skew, queue ve GC pause gibi sorunlar burada belirginleşir. Very low traffic endpoint'te sample sayısı yeterli olmayabilir. High-scale WebSocket sisteminde p99 özellikle önemlidir. Capacity headroom tail latency bozulmadan önce korunmalıdır.

Connection Distribution Nasıl İzlenir?

Connection distribution load balancing algoritmasının production ortamında gerçekten dengeli çalışıp çalışmadığını gösterir. Pod başına sadece aktif connection sayısını görmek başlangıçtır. Standard deviation ve max-to-min oranı skew'u nicel hale getirir. Trafik per connection farklıysa message ve byte hacmi de node bazında karşılaştırılmalıdır. Hot backend detection otomatik alarm üretebilir.

Connections per Backend

Her backend'in active connection sayısı aynı panelde gösterilmelidir. Scale-out sonrası yeni pod'ların ne kadar sürede dolduğu görülebilir. Bir node sürekli yüksekse routing problemi olabilir. Ortalama ile maksimum değer arasındaki fark önemlidir. Draining node ayrı renk veya state ile işaretlenebilir.

Connection Skew

Skew backend'ler arasındaki dengesizlik seviyesini anlatır. Basit olarak max connection ile average arasındaki fark ölçülebilir. Daha doğru analiz standard deviation kullanabilir. Uzun connection lifetime skew'u doğal olarak artırabilir. Kabul edilebilir aralık kapasite headroom'a göre belirlenmelidir.

Standard Deviation

Standard deviation connection dağılımındaki varyasyonu sayısallaştırır. Replica sayısı arttığında yalnız gözle değerlendirme zorlaşır. Normalize edilmiş variation metric daha anlaşılır olabilir. Scale-out ve rollout öncesi ile sonrası karşılaştırma yapılabilir. Tek başına karar vermek yerine node capacity ile birlikte yorumlanmalıdır.

Traffic per Connection

Bütün connection'lar aynı yükü üretmez. Node başına messages per connection ve bytes per connection hesaplanabilir. Az connection taşıyan bir backend yüksek traffic nedeniyle yine hot olabilir. Bu metric capacity-aware routing için de sinyal sağlayabilir. Fan-out room distribution node yükünü etkileyebilir.

Hot Backend Detection

Hot backend diğer node'lara göre belirgin yüksek CPU, queue veya traffic taşıyan server'dır. Connection sayısı normal görünse bile birkaç yoğun room nedeniyle hot olabilir. Multi-metric alarm daha güvenilir sonuç verir. Hot node yeni connection kabulünü geçici olarak azaltabilir. Root cause room distribution veya client davranışı üzerinden araştırılmalıdır.

WebSocket Load Test Nasıl Yapılır?

WebSocket load test yalnız bağlantı açıp açık tutmaktan ibaret olmamalıdır. Connection ramp-up, message throughput, spike, soak, reconnect ve failure senaryoları ayrı test edilmelidir. Gerçek client protocol ve heartbeat davranışı kullanılmalıdır. Load generator kapasitesi server sonucu kadar dikkatle izlenmelidir. Test hedefi maksimum rakam bulmak değil, güvenli operating limit ve failure davranışını belirlemektir.

Connection Ramp-Up

Connection ramp-up belirli sürede connection sayısının kademeli artırılmasıdır. Server accept, TLS ve authentication kapasitesi gözlemlenir. Çok hızlı ramp gerçek kullanıcı davranışını temsil etmeyebilir. Ayrıca intentionally high ramp reconnect storm kapasitesini ölçmek için ayrı çalıştırılabilir. Handshake error ve p95 latency ana metric'lerdir.

Concurrent Connection Test

Concurrent test hedef sayıda bağlantıyı aynı anda açık tutar. Memory, file descriptor ve idle CPU ölçülür. Connection başına heartbeat trafiği gerçekçi olmalıdır. Sadece idle connection sonucu mesaj workload kapasitesini göstermez. İkinci aşamada message traffic eklenmelidir.

Message Throughput Test

Bu test active connection'lar üzerinden belirli messages per second üretir. Incoming, outgoing ve fan-out pattern production'a benzemelidir. CPU, network, queue ve p99 latency ölçülür. Payload boyutu gerçek dağılıma yakın olmalıdır. Compression veya serialization seçenekleri karşılaştırılabilir.

Spike Test

Spike test kısa sürede büyük trafik artışı oluşturur. Autoscaling'in ne kadar hızlı tepki verdiği görülür. Connection ve message burst ayrı test edilebilir. Queue veya error rate spike sırasında sınırı gösterebilir. Recovery sonrasında metric'lerin normale dönme süresi ölçülmelidir.

Soak Test

Soak test sistemi saatler veya günler boyunca sürekli yük altında çalıştırır. Memory leak, connection leak ve registry stale record sorunları ortaya çıkabilir. Short benchmark'ta görünmeyen GC ve fragmentation etkileri gözlenir. Broker ve database bağlantıları da uzun süre test edilir. Deployment kadar uzun connection lifetime davranışı doğrulanır.

Reconnect Test

Reconnect test belirli oran veya bütün connection'ları kontrollü biçimde koparır. Client backoff ve jitter gerçek implementation ile çalışmalıdır. Handshake capacity ve connection rate gözlemlenir. Session resume doğrulanır. Duplicate message veya missed message oranı ölçülebilir.

Failure Test

Failure test pod, broker, load balancer veya region kaybını simüle eder. System yalnız steady-state performance ile değerlendirilmemelidir. Kalan kapasitenin yükü taşıyıp taşımadığı görülür. Recovery ve reconnect latency ölçülür. Failure test düzenli chaos veya resilience programına dönüştürülebilir.

100 Bin ve 1 Milyon WebSocket Bağlantısı Nasıl Test Edilir?

Yüz bin veya bir milyon connection testinde load generator tarafı ciddi altyapı gerektirir. Tek makine file descriptor, port, memory veya bandwidth sınırına ulaşabilir. Distributed load generation birden fazla generator kullanarak gerçek client sayısını yayar. Test network maliyeti ve cloud limitleri önceden hesaplanmalıdır. Sonuçların server bottleneck mi generator bottleneck mi olduğu mutlaka ayrıştırılmalıdır.

Tek Load Generator'ın Sınırları

Tek generator çok sayıda outbound socket açarken local file descriptor ve ephemeral port kaynaklarını tüketebilir. CPU veya network kartı test sonucunu sınırlar. Server boş olduğu halde generator message göndermekte zorlanabilir. Generator metric'leri server metric'leriyle birlikte izlenmelidir. Büyük testte birden fazla host kullanmak daha güvenilir olur.

Distributed Load Generation

Distributed load generation connection'ları çok sayıda test worker'a böler. Region bazlı generator gerçek coğrafi latency oluşturabilir. Coordinator yalnız test kontrolü yapmalı, data path bottleneck olmamalıdır. Worker clock synchronization latency ölçümü için önemlidir. Sonuçlar merkezi metric sisteminde toplanabilir.

Client Resource Limits

Her test client connection için memory ve socket kullanır. Generator runtime'ın connection overhead'i ölçülmelidir. TLS state CPU tüketebilir. Heartbeat ve message parsing generator'ı server kadar zorlayabilir. Test client'ı üretim client davranışını yeterince temsil etmelidir.

Network Bandwidth

Bir milyon connection küçük heartbeat bile önemli network trafiği üretir. Message throughput testi egress ve ingress bandwidth limitine ulaşabilir. Cloud provider network quota önceden kontrol edilmelidir. Generator ve server farklı region'daysa transfer maliyeti yüksek olabilir. Bandwidth bottleneck latency ve packet loss ile kendini gösterebilir.

Connection Ramp Rate

Bir milyon connection'ı birkaç saniyede açmak çoğu gerçek senaryoyu temsil etmez. Normal startup ve failure reconnect için farklı ramp rate testleri yapılmalıdır. Server accept ve authentication capacity bu sayede ayrı ölçülür. Ramp süresi test planında açık belirtilmelidir. Başarılı connection oranı hedef metric olmalıdır.

Test Sonuçlarının Yorumlanması

Sadece “bir milyon bağlantı açıldı” sonucu anlamlı değildir. Message latency, memory, CPU, error rate ve recovery davranışı birlikte raporlanmalıdır. Test sırasında load generator saturation olup olmadığı doğrulanmalıdır. Hedef production payload ve message rate kullanılmalıdır. Güvenli kapasite maksimum başarılı test değerinden daha düşük belirlenmelidir.

WebSocket Capacity Planning

Capacity planning connection sayısı ile birlikte connection başına memory, CPU, message rate ve bandwidth hesabını içerir. Headroom özellikle node veya zone kaybı sonrasında kritik hale gelir. Ortalama workload kadar peak ve failure workload hesaplanmalıdır. Autoscaling gecikmesi sırasında mevcut node'ların yeni yükü taşıyabilmesi gerekir. Capacity plan düzenli load test sonuçlarıyla güncellenmelidir.

Connection Başına Memory

Memory per connection idle ve active durumda ayrı ölçülebilir. Authentication, subscription ve queue state maliyeti dahil edilmelidir. TLS ve compression memory'si unutulmamalıdır. 20 KB fark yüz bin connection'da yaklaşık gigabyte seviyesinde etki yaratabilir. Bu nedenle profiler ile gerçek heap ölçümü yapılmalıdır.

Connection Başına CPU

Idle connection'ın CPU maliyeti çok düşük olabilir. Heartbeat ve message rate arttığında connection başına CPU yükselir. Encryption ve serialization da ek yük oluşturur. Ortalama yerine workload class bazlı model kurulabilir. CPU capacity messages per second ile daha anlamlı ilişkilenebilir.

Ortalama Messages/sec

Kullanıcı başına ortalama message rate toplam workload hesabının temel girdisidir. Peak kullanıcı davranışı ortalamanın birkaç katı olabilir. Incoming ve outgoing rate fan-out nedeniyle farklıdır. Room broadcast amplification hesaba katılmalıdır. Gerçek production telemetry en güvenilir kaynaktır.

Ortalama Payload Size

Payload size bandwidth ve serialization maliyetini belirler. Ortalama yanında p95 message size da faydalıdır. Birkaç çok büyük message tail latency oluşturabilir. Compression açıkken wire size ayrı ölçülmelidir. Protocol değişiklikleri payload regression testine dahil edilebilir.

Bandwidth

Toplam bandwidth message rate ile payload size çarpımından daha karmaşıktır. Protocol, TLS ve TCP overhead de vardır. Fan-out outgoing traffic'i büyütür. Network interface ve cloud egress quota sınırı olabilir. Capacity planında güvenli pay bırakılmalıdır.

Headroom

Headroom mevcut kapasite ile normal peak yük arasındaki güvenlik payıdır. Autoscaling anlık olmadığı için bu pay gereklidir. Küçük headroom failure anında cluster'ı hemen doygun hale getirir. Fazla headroom maliyeti artırır. SLA ve scale-up süresine göre uygun oran seçilmelidir.

Failure Capacity

Failure capacity bir veya daha fazla node kaybolduğunda kalan sistemin trafiği taşıyabilmesidir. Normalde yüzde yetmiş dolu cluster tek node kaybında yüzde yüzü aşabilir. Capacity plan N+1 veya zone failure hedefini açık tanımlamalıdır. Reconnect burst ek yük oluşturacağı için sadece steady-state connection sayısı hesaplanmamalıdır. Disaster recovery testi bu varsayımı doğrular.

WebSocket High Availability

High availability WebSocket sisteminde load balancer, backend, broker ve state store için tek hata noktalarını azaltmayı amaçlar. Server kaybında client reconnect temel recovery mekanizmasıdır. Shared state yeni node'un session'ı yeniden kurmasını kolaylaştırır. Failure detection çok agresif veya çok yavaş olmamalıdır. HA tasarımı düzenli failure testleriyle doğrulanmalıdır.

Birden Fazla Load Balancer

Tek load balancer arızası bütün connection'ları etkileyebilir. Managed HA veya birden fazla active instance kullanılabilir. DNS veya anycast failover davranışı test edilmelidir. Existing connection load balancer kaybında genellikle kopar. Client reconnect jitter yükü yeni instance'lara dağıtır.

Birden Fazla Backend

Birden fazla WebSocket backend yatay kapasite ve redundancy sağlar. Shared state veya stateless gateway node bağımlılığını azaltır. Load balancer health check yeni connection'ları sağlıklı node'lara gönderir. Bir backend kaybında sadece o node üzerindeki connection'lar reconnect etmelidir. Failure blast radius pod başına connection sayısıyla ilişkilidir.

Failure Detection

Health check ve heartbeat failure detection sağlar. Çok kısa interval transient problemde gereksiz failover oluşturabilir. Çok uzun interval kullanıcıların bozuk backend'de beklemesine neden olur. Application readiness internal dependency durumunu yansıtabilir. False positive ve detection latency birlikte optimize edilmelidir.

Backend Removal

Sağlıksız backend yeni connection routing listesinden çıkarılır. Existing connections tamamen bozuksa client disconnect olur. Planned maintenance'ta draining kullanılmalıdır. Backend tekrar sağlıklı olduğunda yavaş biçimde traffic'e alınabilir. Ani full load cache ve runtime warm-up sorunları yaratabilir.

Client Reconnect

Client reconnect HA mimarisinin önemli parçasıdır. Server failover tek başına açık socket'i koruyamaz. Backoff ve jitter bütün kullanıcıların aynı anda bağlanmasını engeller. Resume token session continuity sağlar. Client SDK davranışı platformlar arasında aynı prensibi izlemelidir.

Shared State

Shared state reconnect sonrasında farklı backend'in kullanıcı context'ini yeniden oluşturmasını sağlar. Presence, session ve subscription metadata uygun sistemlerde tutulabilir. Shared store failure yeni single point oluşturmamalıdır. Cache ve broker HA ayrı planlanmalıdır. State data'nın ne kadarının gerçekten shared olması gerektiği minimize edilmelidir.

WebSocket Sistemlerinde Failure Senaryoları

Production tasarımı yalnız normal durumda iyi çalışan architecture'a göre yapılmamalıdır. Server crash, broker failure, network partition ve region outage gibi senaryolar ayrı düşünülmelidir. Her failure için kullanıcı etkisi, veri kaybı ve recovery süresi tanımlanmalıdır. Reconnect storm ve duplicate delivery gibi ikincil etkiler test edilmelidir. Failure drill sonucunda runbook ve metric'ler güncellenmelidir.

WebSocket Server Crash

Server crash o node üzerindeki bütün socket'leri aniden kapatır. Graceful shutdown çalışmaz. Client'lar diğer node'lara reconnect eder. In-memory unsent message kaybolabilir. Durable delivery gerekiyorsa event broker veya log üzerinde korunmalıdır.

Load Balancer Failure

Load balancer failure çok sayıda connection'ı aynı anda etkileyebilir. HA edge tasarımı blast radius'u azaltır. Existing TCP connection başka load balancer'a canlı taşınmaz. Client failover endpoint'e bağlanır. Reconnect capacity normal connection rate'in çok üzerinde planlanmalıdır.

Message Broker Failure

Broker failure cross-node messaging'i durdurabilir. Local connection'lar açık kalsa bile kullanıcılar mesaj alamayabilir. Application degraded mode tanımlamalıdır. Durable broker varsa backlog recovery sonrasında replay edilir. Ephemeral Pub/Sub kaybında resync gerekebilir.

Redis Failure

Redis connection registry veya Pub/Sub için kullanılıyorsa failure etkisi iki farklı katmanda görülebilir. Registry lookup çalışmazsa user routing zorlaşır. Pub/Sub mesajları kaybolabilir. Redis HA ve failover latency ölçülmelidir. Application Redis yokken hangi özelliklerin çalışmaya devam edeceğini bilmelidir.

Network Partition

Network partition node'ların broker veya state store'a erişimini kesebilir. Client connection'ları açık kalabilir fakat cross-node messaging bozulur. Split-brain presence bilgisi oluşabilir. Timeout ve circuit breaker davranışı önemlidir. Recovery sonrası stale state reconciliation yapılmalıdır.

Database Failure

Database failure authentication refresh veya durable message işlemlerini etkileyebilir. Her WebSocket message'ın database'e bağımlı olması failure blast radius'u büyütür. Cache veya event queue geçici dayanıklılık sağlayabilir. Write işlemleri retry yapılırken duplicate etkisi düşünülmelidir. Database recovery sonrasında backlog kontrollü tüketilmelidir.

Region Failure

Region outage global kullanıcı kitlesinin büyük bölümünü yeniden yönlendirebilir. Failover region yeterli warm capacity'ye sahip olmalıdır. Cross-region state replication gecikmesi user session continuity'yi etkiler. DNS veya global load balancer failover süresi ölçülmelidir. Düzenli disaster recovery tatbikatı varsayımları doğrular.

Multi-Region WebSocket Mimarisi

Multi-region WebSocket mimarisi kullanıcıları yakın region'a bağlayarak network latency'yi azaltabilir. Bunun karşılığında cross-region messaging, presence ve state consistency daha zor hale gelir. Global load balancer region seçimi yapabilir. Region affinity connection'ın sürekli uzak bölgelere sıçramasını engeller. Failover sırasında kullanıcı deneyimi ve messaging semantics açık biçimde tanımlanmalıdır.

Geo DNS

Geo DNS kullanıcıya coğrafi konumuna göre region endpoint döndürebilir. DNS cache failover hızını sınırlar. Existing WebSocket connection DNS değişiminden etkilenmez. Connection koptuğunda client yeni çözümleme yapabilir. TTL değeri stability ile failover hızı arasında denge kurar.

Global Load Balancer

Global load balancer kullanıcıyı network veya health bilgisine göre uygun region'a yönlendirebilir. Managed anycast çözümleri latency avantajı sağlayabilir. Region outage otomatik detection ile failover tetikleyebilir. Capacity target region'da yeterli olmalıdır. Global edge connection metric'leri region bazında izlenmelidir.

Region Affinity

Region affinity kullanıcıyı normal koşullarda aynı region'da tutmayı amaçlar. Presence ve session locality daha öngörülebilir olur. Kullanıcı seyahat ettiğinde yeni region daha düşük latency sunabilir. Stateful data migration gerekebilir. Affinity failure durumunda katı olmamalı ve sağlıklı region'a geçişe izin vermelidir.

En Yakın Region'a Bağlantı

En yakın region seçimi RTT veya coğrafi bilgi üzerinden yapılabilir. Coğrafi olarak yakın datacenter her zaman network olarak en düşük latency'li olmayabilir. Global load balancer gerçek network performansını kullanabilir. Client telemetry region selection kalitesini doğrulayabilir. Data residency gereksinimleri routing kararını sınırlayabilir.

Cross-Region Messaging

Farklı region'lardaki kullanıcılar aynı room'da olabilir. Event'in region'lar arasında taşınması gerekir. Global broker veya region bridge kullanılabilir. Cross-region latency message delivery p99 değerini yükseltir. Local fan-out ve remote replication ayrı katmanlar olarak tasarlanabilir.

Region Failover

Region failover kullanıcıları sağlıklı bölgeye yönlendirir. Client connection doğal olarak kopar ve yeniden kurulur. State ve missed message recovery mekanizması gerekir. Failover region'ın quota ve broker kapasitesi normalden büyük olmalıdır. Disaster testleri gerçek client reconnect davranışıyla yapılmalıdır.

Multi-Region Pub/Sub Problemleri

Multi-region Pub/Sub mesajların farklı network gecikmeleriyle taşınması nedeniyle ordering ve consistency sorunları oluşturabilir. Aynı event tekrar teslim edilebilir veya farklı sırada gelebilir. Presence gibi hızlı değişen state eventual consistency ile çalışabilir. Kritik business event'ler için sequence ve deduplication gerekir. Cross-region bandwidth maliyeti topic tasarımında önemli bir faktördür.

Message Ordering

Global sistemde bütün mesajlar için tek total order sağlamak pahalı olabilir. Room veya user bazında ordering yeterli olabilir. Partition key bu sınırı belirler. Client sequence number ile sıra kontrolü yapabilir. Geç gelen eski state update atılabilir.

Cross-Region Latency

Region'lar arası network RTT message delivery süresine doğrudan eklenir. Local kullanıcılar düşük latency görürken remote room event'i daha geç gelebilir. P95 ve p99 region pair bazında izlenebilir. Gereksiz global broadcast azaltılmalıdır. Data locality performansı iyileştirebilir.

Duplicate Messages

Retry ve at-least-once broker davranışı duplicate event üretebilir. Message ID ve deduplication cache kullanılabilir. Client da son sequence bilgisiyle tekrarları ayıklayabilir. Exactly-once beklentisi yerine idempotent processing tasarlanmalıdır. Deduplication retention event replay süresine göre seçilir.

Eventual Consistency

Her region state değişikliğini aynı anda görmeyebilir. Presence ve typing indicator gibi veriler bu gecikmeyi tolere edebilir. Kritik authorization state daha güçlü consistency isteyebilir. Data class'ları ayrı SLA ile yönetmek doğru olur. Eventual consistency user experience içinde açık davranışa dönüştürülmelidir.

Presence Consistency

Kullanıcı region değiştirirken kısa süre iki yerde online görünebilir. Eski heartbeat timeout ile kapanmadan yeni connection açılmış olabilir. Connection session ID ve timestamp en yeni state'i belirlemeye yardımcı olur. Global presence store eventual model kullanabilir. Ghost user cleanup kısa TTL ile desteklenmelidir.

WebSocket Presence Sistemi Nasıl Tasarlanır?

Presence sistemi kullanıcının online, offline veya son görülme durumunu takip eder. Tek connection varsayımı multi-device kullanımında hatalıdır. Heartbeat connection canlılığını güncelleyebilir. Distributed store node failure sonrasında state paylaşımı sağlar. Ghost user problemi TTL ve reconciliation ile çözülmelidir.

Online / Offline

Kullanıcının en az bir aktif connection'ı varsa online kabul edilebilir. Son connection kapandığında hemen offline yapmak kısa network kopmalarında flapping oluşturur. Küçük grace period kullanılabilir. Logout event'i daha hızlı offline işareti verebilir. Presence semantics ürün beklentisine göre tanımlanmalıdır.

Last Seen

Last seen kullanıcının son aktif olduğu zamanı gösterir. Her heartbeat'te durable database update yapmak gereksiz write load oluşturur. Memory veya Redis üzerinde güncel tutulup belirli aralıklarla persist edilebilir. Privacy ayarları dikkate alınmalıdır. Timestamp precision ürün ihtiyacından daha yüksek olmamalıdır.

Multi-Device Presence

Kullanıcı birden fazla cihazdan bağlı olabilir. Bir cihaz disconnect olduğunda diğer connection'lar kontrol edilmelidir. Presence registry connection set tutabilir. Device-specific presence gerekiyorsa metadata genişletilebilir. Mobile background bağlantısı ürün kuralına göre online sayılabilir veya sayılmayabilir.

Heartbeat-Based Presence

Heartbeat son görülen connection timestamp'ini günceller. Belirli timeout aşılırsa connection stale kabul edilir. Her heartbeat'i distributed store'a yazmak yüksek write rate oluşturabilir. Local aggregation veya daha uzun refresh interval kullanılabilir. Failure detection hedefi ile store load arasında denge kurulmalıdır.

Distributed Presence Store

Distributed store farklı WebSocket node'larının ortak presence state'e erişmesini sağlar. Redis TTL bu kullanımda pratiktir. Region bazlı presence ayrı tutulup global görünüm sonradan birleştirilebilir. High availability olmadan store failure bütün presence özelliğini etkiler. Presence uygulamanın kritik business işlemlerinden ayrılmalıdır.

Ghost User Problemi

Ghost user aslında bağlantısı kopmuş kullanıcıyı online göstermeye devam eden stale kayıttır. Crash veya network partition disconnect event'ini engelleyebilir. TTL ve heartbeat bu problemi azaltır. Reconciliation node heartbeat'i kaybolan bütün connection kayıtlarını temizleyebilir. Ghost count tahmini monitoring kalitesini gösterir.

WebSocket Deployment Stratejileri

WebSocket deployment stratejisi uzun bağlantıların sürüm değişikliklerinden nasıl etkileneceğini belirler. Rolling deployment en yaygın yöntemdir, fakat connection draining gerekir. Blue-green hızlı rollback sağlayabilir ancak bir anda büyük reconnect oluşturabilir. Canary yeni sürümü az connection üzerinde test etmeye yardımcı olur. Protocol version compatibility bütün stratejilerin temel şartıdır.

Rolling Deployment

Rolling deployment pod'ları kademeli değiştirir. Her pod draining ile connection'larını azaltabilir. Yeni sürüm ile eski sürüm bir süre aynı anda çalışır. Shared broker message schema iki sürümle uyumlu olmalıdır. Rollout metric'leri disconnect ve error rate'i takip etmelidir.

Blue-Green Deployment

Blue-green iki ayrı deployment ortamı kullanır. Traffic yeni ortama geçirildiğinde existing WebSocket connection'lar eski ortamda kalabilir. Zorunlu switch büyük reconnect dalgası yaratabilir. DNS veya load balancer geçişi new connection'ları green'e yönlendirebilir. Eski ortam drain tamamlanana kadar tutulabilir.

Canary Deployment

Canary yeni sürüme sınırlı kullanıcı veya connection yönlendirir. Error, latency ve disconnect metric'leri karşılaştırılabilir. Long-lived connection nedeniyle canary sample'ın oluşması zaman alabilir. Protocol version routing kullanılabilir. Problem görülürse yeni connection routing eski sürüme döndürülebilir.

Connection Draining

Draining deployment sırasında ani disconnect sayısını azaltır. Terminating node yeni connection kabul etmez. Existing client'lar doğal kapanış veya controlled reconnect ile taşınır. Drain süresi connection lifetime'a göre belirlenir. Force disconnect sayısı rollout kalite metriği olabilir.

Version Compatibility

Eski ve yeni server bir süre aynı broker ve client'larla çalışır. Message schema geriye uyumlu olmalıdır. Yeni field optional eklenebilir. Eski server'ın anlayamayacağı breaking event hemen yayınlanmamalıdır. Feature flag staged rollout için kullanılabilir.

Client Protocol Versioning

Client uygulamalarının upgrade hızı server'dan daha yavaştır. Mobil kullanıcı aylarca eski sürüm kullanabilir. Server birden fazla protocol version desteklemek zorunda kalabilir. Handshake client version bilgisi taşıyabilir. Unsupported version için açık upgrade mesajı gönderilmelidir.

WebSocket Protocol Versioning

WebSocket transport uzun süre stabil kalabilir, fakat application message schema zaman içinde değişir. Protocol versioning eski client'ların yeni server ile çalışmasını sağlar. Message type ve field değişiklikleri geriye uyumlu tasarlanmalıdır. Breaking değişikliklerde version negotiation kullanılabilir. Version kullanım oranı monitoring ile takip edilerek eski sürüm desteği kontrollü kaldırılabilir.

Message Schema Versioning

Her message type açık schema'ya sahip olmalıdır. Yeni field eklenirken eski client'ın bunu yok sayabilmesi gerekir. Required field değişiklikleri breaking olabilir. Binary protocol'de field numbering kurallarına uyulmalıdır. Schema contract testleri client ve server build sürecine eklenebilir.

Eski Client Desteği

Mobil client'lar kullanıcı tarafından hemen güncellenmeyebilir. Server eski protocol version'ı belirli süre desteklemelidir. Feature capability negotiation yapılabilir. Güvenlik açığı bulunan çok eski client zorunlu upgrade isteyebilir. Active connection version dağılımı karar vermeye yardımcı olur.

Backward Compatibility

Backward compatibility yeni server'ın eski client mesajlarını anlayabilmesini sağlar. Yeni field'lar optional olabilir. Enum genişletme sırasında unknown value davranışı tanımlanmalıdır. Broker event schema da eski server sürümleriyle uyumlu olmalıdır. Rolling deployment testleri mixed-version cluster kullanmalıdır.

Server Rollout

Server rollout sırasında iki veya daha fazla version aynı anda aktif olabilir. Cross-node messaging schema ortak paydada kalmalıdır. Feature yeni server oranı yeterli seviyeye gelmeden aktive edilmemelidir. Canary metric'leri version label ile ayrılabilir. Rollback eski server'ın yeni state'i okuyabildiğini garanti etmelidir.

Client Upgrade Süresi

Client upgrade süresi platform ve kullanıcı davranışına bağlıdır. Web client hızlı güncellenirken mobil client gecikebilir. Protocol deprecation birkaç release boyunca duyurulabilir. Server support maliyeti version sayısıyla artar. Usage threshold altına düşen sürüm kontrollü biçimde kapatılabilir.

WebSocket Mesajlarında Delivery Semantics

WebSocket TCP üzerinde güvenilir byte stream kullansa da application-level message delivery semantics ayrıca tasarlanmalıdır. Connection koparsa server'ın gönderdiği son mesajın client tarafından işlendiği garanti olmayabilir. At-most-once ve at-least-once modelleri farklı trade-off taşır. Acknowledgement, sequence number ve deduplication güvenilirlik sağlar. Exactly-once ifadesi dağıtık sistemlerde dikkatli kullanılmalıdır.

At-Most-Once

At-most-once modelinde mesaj ya bir kez teslim edilir ya da kaybolabilir. Retry yapılmaz. Typing indicator veya geçici state update gibi event'lerde uygun olabilir. Sistem basittir ve duplicate işleme yoktur. Kritik business event'ler için yetersiz olabilir.

At-Least-Once

At-least-once modelinde mesaj kaybolmaması için retry yapılabilir. Bunun karşılığında duplicate delivery mümkündür. Message ID ile idempotent processing gerekir. Broker ve client acknowledgement birlikte kullanılabilir. Finansal veya durable event'lerde daha uygun olabilir.

Exactly-Once Yanılgısı

Dağıtık sistemde network failure sırasında gönderici acknowledgement'ın ulaşıp ulaşmadığını bilemeyebilir. Retry duplicate üretebilir. Exactly-once davranış çoğu zaman deduplication ve idempotency kombinasyonuyla application seviyesinde taklit edilir. Her katmanda mutlak garanti varsayılmamalıdır. Business işlem unique key ile korunabilir.

Acknowledgement

Client mesajı aldığını veya işlediğini acknowledgement ile bildirebilir. Server ack gelmezse belirli sürede retry yapabilir. Timeout network RTT'ye göre seçilmelidir. Her küçük state update için ack gereksiz overhead olabilir. Message class'a göre farklı delivery policy uygulanabilir.

Sequence Number

Sequence number mesajların sırasını ve eksik event'leri anlamayı sağlar. Room, user veya stream bazında tutulabilir. Client son sequence ID'yi reconnect sırasında gönderebilir. Gap görülürse replay veya snapshot istenir. Counter rollover ve persistence davranışı tanımlanmalıdır.

Deduplication

Deduplication aynı message ID'nin tekrar işlenmesini engeller. Client veya server kısa süreli ID cache tutabilir. Retention retry window'dan uzun olmalıdır. Çok büyük cache memory tüketir. Durable business işlem database unique constraint ile de korunabilir.

Connection Resume ve Kaçırılan Mesajların Tamamlanması

Connection resume kısa network kopmalarında kullanıcıyı kaldığı event stream'e geri döndürür. Client son aldığı sequence ID'yi server'a bildirir. Server replay buffer veya durable event log üzerinden eksik mesajları gönderir. Buffer süresi aşılmışsa full snapshot gerekebilir. Bu yaklaşım deployment ve transient network failure etkisini ciddi biçimde azaltır.

Last Sequence ID

Client işlediği son message sequence değerini saklar. Reconnect handshake veya ilk application message ile server'a gönderir. Server bundan sonraki event'leri bulabilir. Sequence scope açık olmalıdır. Global counter yerine room veya stream counter daha ölçeklenebilir olabilir.

Replay Buffer

Replay buffer son belirli sayı veya süre içindeki mesajları tutar. Memory veya Redis Streams gibi sistemlerde uygulanabilir. Çok büyük buffer maliyeti artırır. Retention normal reconnect süresini kapsamalıdır. Buffer miss durumunda snapshot fallback gerekir.

Event Log

Durable event log uzun süreli replay imkânı sunar. Kafka veya database event table kullanılabilir. Her transient UI event'i durable log'a yazmak gerekli değildir. Business-critical event'ler için daha uygundur. Consumer offset ve retention capacity planına dahil edilmelidir.

Reconnect Sonrası Replay

Client reconnect olduktan sonra live stream'e geçmeden önce eksik event'leri alabilir. Replay sırasında yeni event'ler buffer edilmeli veya sequence üzerinden birleştirilmelidir. Duplicate delivery deduplication ile yönetilir. Çok büyük gap full state sync gerektirebilir. Reconnect latency bu süreci kapsayacak şekilde ölçülmelidir.

Buffer Retention

Retention süresi tipik network kesinti süresine göre seçilir. Çok kısa retention resume başarısını düşürür. Çok uzun retention memory veya storage maliyetini artırır. User base ve event rate hesabı yapılmalıdır. Metric replay_hit_rate uygun retention kararını destekler.

WebSocket ve Server-Sent Events Arasındaki Fark

WebSocket ve SSE gerçek zamanlı veri için farklı iletişim modelleri sunar. WebSocket iki yönlü full-duplex iletişim sağlarken SSE ağırlıklı olarak server'dan client'a event akışıdır. Basit bildirim veya feed uygulamalarında SSE daha az protocol yönetimi gerektirebilir. Yoğun client-to-server mesajlaşmasında WebSocket daha doğal seçimdir. Ölçeklenebilirlik kararı uygulamanın gerçek yön ve message rate ihtiyacına göre verilmelidir.

Full-Duplex vs Server-to-Client

WebSocket client ve server'ın aynı bağlantıda bağımsız mesaj göndermesine izin verir. SSE server-to-client stream sağlar ve client komutları normal HTTP ile gönderebilir. Chat gibi çift yönlü yoğun akışta WebSocket avantajlıdır. Canlı haber feed'i gibi tek yönlü kullanımda SSE yeterli olabilir. Daha basit çözüm operasyon maliyetini azaltabilir.

Reconnect Davranışı

SSE tarayıcı tarafında doğal reconnect mekanizması sunabilir. Last-Event-ID ile replay desteklenebilir. WebSocket reconnect uygulama tarafından tasarlanmalıdır. Bu ek kontrol daha esnek davranış sağlar. Her iki protokolde de reconnect storm ve backoff düşünülmelidir.

Proxy Uyumluluğu

SSE normal HTTP streaming kullandığı için bazı proxy ortamlarında daha kolay çalışabilir. WebSocket upgrade desteği her ara katmanda doğrulanmalıdır. Modern altyapılarda WebSocket desteği yaygındır. Kurumsal network ve firewall davranışı gerçek client ortamında test edilmelidir. WSS genellikle proxy geçişini kolaylaştırır.

Ölçeklenebilirlik

Her iki protokol de uzun bağlantı tuttuğu için connection capacity gerektirir. SSE tek yönlü olduğundan application protocol daha basit olabilir. WebSocket daha geniş kullanım alanı sunar. Load balancing ve connection draining iki modelde de önemlidir. Seçim yalnız teorik benchmark'a göre yapılmamalıdır.

Hangi Senaryoda SSE Daha İyi?

Client'ın server'a sürekli realtime mesaj göndermesi gerekmiyorsa SSE daha basit olabilir. Notification, server log stream veya dashboard update örnek verilebilir. Automatic reconnect geliştirme maliyetini azaltır. Binary data veya full-duplex ihtiyaç varsa WebSocket daha uygundur. Ürün gereksinimi transport kararından önce gelmelidir.

WebSocket ve Long Polling Arasındaki Fark

Long polling client'ın server'da yeni veri oluşana kadar HTTP request'i açık tutması ve response sonrası yeniden request göndermesi yaklaşımıdır. WebSocket tek connection üzerinde sürekli çift yönlü iletişim sağlar. Long polling bazı proxy ortamlarında kolay uyumluluk sunabilir. Buna karşılık request overhead ve reconnect sıklığı daha yüksektir. Modern realtime uygulamalarda WebSocket çoğu yoğun etkileşim senaryosunda daha verimli olabilir.

Connection Overhead

Long polling her response sonrasında yeni HTTP request gerektirir. Header ve request processing maliyeti tekrarlanır. WebSocket tek handshake sonrası daha küçük frame'ler kullanır. Çok düşük message rate'te fark daha az önemli olabilir. High frequency sistemde WebSocket avantajı artar.

Latency

Long polling doğru uygulandığında yeni event hızlı dönebilir. Ancak request yeniden kurulurken küçük boşluklar oluşabilir. WebSocket server event'i açık socket üzerinden hemen gönderebilir. Tail latency network ve load balancer koşullarına bağlıdır. Gerçek client ortamında karşılaştırma yapılmalıdır.

Proxy Davranışı

Long polling normal HTTP olduğu için eski proxy sistemlerinde daha kolay geçebilir. Timeout değerleri request'in yeterince uzun açık kalmasına izin vermelidir. WebSocket protocol upgrade gerektirir. Modern managed proxy'lerde bu fark giderek azalmıştır. Legacy enterprise network kullanımında fallback planı değerlendirilebilir.

Server Resource Kullanımı

Her iki yaklaşım uzun süreli bekleme kaynağı kullanabilir. Long polling request lifecycle ve header işlemlerini daha sık tekrarlar. WebSocket connection state uzun süre tutulur. Runtime architecture gerçek resource farkını belirler. Load test olmadan kesin genelleme yapılmamalıdır.

Fallback Stratejileri

Bazı realtime client library'leri WebSocket başarısız olduğunda long polling fallback sunar. Bu uyumluluğu artırır. Fallback workload'u server capacity planında unutulmamalıdır. Long polling request rate normal WebSocket modelinden çok daha yüksek olabilir. Monitoring transport type bazında trafik dağılımını göstermelidir.

WebSocket Performansının Maliyeti Nasıl Ölçülür?

WebSocket altyapı maliyeti sadece sunucu instance fiyatından oluşmaz. Load balancer connection kullanımı, data transfer, broker ve cross-region trafik önemli kalemlerdir. Connection başına maliyet farklı workload sınıfları için hesaplanabilir. 10K ve 100K connection maliyet modelleri capacity planlamasını kolaylaştırır. Optimizasyon yalnız latency değil birim kullanıcı maliyeti üzerinden de değerlendirilebilir.

Cost per 10K Connections

On bin connection için gereken backend replica, memory ve load balancer kapasitesi hesaplanabilir. Ortalama message rate ve payload eklenmelidir. Idle connection testi gerçek maliyeti düşük gösterebilir. Broker ve monitoring giderleri paylaştırılabilir. Bu metric architecture değişikliklerini karşılaştırmak için faydalıdır.

Cost per 100K Connections

Yüz bin connection ölçeğinde network ve memory verimliliği daha belirgin hale gelir. Küçük per-connection overhead farkları toplam maliyeti ciddi etkiler. Failure headroom nedeniyle yalnız teorik maksimum kapasite üzerinden hesap yapılmamalıdır. Multi-AZ veya replica gereksinimi dahil edilmelidir. Gerçek production utilization oranı kullanılmalıdır.

Data Transfer Cost

Outgoing WebSocket trafik cloud ortamında önemli maliyet oluşturabilir. Fan-out amplification egress byte miktarını büyütür. Compression bandwidth'i azaltabilir fakat CPU maliyeti ekler. Cross-region egress ayrıca fiyatlanabilir. Message size optimizasyonu doğrudan altyapı maliyetine yansıyabilir.

Load Balancer Cost

Managed load balancer connection, rule veya data processing bazlı fiyatlama uygulayabilir. Uzun ömürlü connection modeli maliyet hesaplamasını etkiler. Peak concurrent connection ve new connection rate ayrı parametre olabilir. Reconnect storm kısa sürede ekstra consumption yaratabilir. Pricing model capacity planla birlikte incelenmelidir.

Message Broker Cost

Broker maliyeti throughput, storage, partition ve replication ihtiyacına bağlıdır. Ephemeral Pub/Sub durable log'a göre daha düşük storage maliyetine sahip olabilir. Multi-AZ replication yüksek availability için ek kaynak kullanır. Consumer lag büyük instance ihtiyacını gösterebilir. Broker metriği WebSocket gateway cost'undan ayrı raporlanmalıdır.

Cross-Region Traffic Cost

Multi-region messaging region'lar arası veri transferi üretir. Global broadcast bu maliyeti hızla büyütebilir. Region-local room tasarımı gereksiz replikasyonu azaltır. Sadece gereken event cross-region taşınmalıdır. Latency ve maliyet aynı mimari kararın iki sonucudur.

Open Source WebSocket Ekosistemi

WebSocket altyapısı güçlü bir açık kaynak ekosistemi üzerine kurulabilir. Reverse proxy, broker, runtime library ve load-test araçları bu ekosistemin farklı parçalarıdır. Araç seçerken community büyüklüğü kadar production davranışı ve observability desteği önemlidir. Version upgrade'leri changelog ve performance test ile doğrulanmalıdır. Açık kaynak kullanmak operasyon sorumluluğunu ortadan kaldırmaz.

NGINX

NGINX reverse proxy ve load balancing katmanında WebSocket upgrade destekleyebilir. Mevcut web altyapısıyla entegrasyonu kolaydır. Timeout ve upstream ayarları uzun connection'lara göre yapılmalıdır. Connection ve error metric'leri izlenmelidir. Config değişiklikleri load test ile doğrulanmalıdır.

HAProxy

HAProxy yüksek bağlantı sayısı ve load balancing konusunda güçlü bir açık kaynak seçeneğidir. HTTP ve TCP mode farklı ihtiyaçlara hizmet eder. Least connections ve timeout tunnel WebSocket kullanımında önemlidir. Health ve draining davranışı production deployment ile birlikte tasarlanmalıdır. Ekip operasyon deneyimi seçimde önemli rol oynar.

Envoy

Envoy modern proxy ve service networking ihtiyaçlarında kullanılabilir. HTTP routing, observability ve dynamic configuration özellikleri sunar. WebSocket upgrade ve long connection davranışı deployment modelinde doğrulanmalıdır. Service mesh içinde ek hop latency'si ölçülmelidir. Metric zenginliği debugging süresini azaltabilir.

Redis

Redis connection registry, presence ve düşük latency Pub/Sub için kullanılabilir. Memory-based yapısı hızlıdır. Persistence ve HA gereksinimi kullanım alanına göre yapılandırılmalıdır. Pub/Sub mesajları subscriber offline olduğunda saklamaz. Durable replay gerekiyorsa Streams veya başka log sistemi değerlendirilmelidir.

NATS

NATS hafif ve düşük latency messaging için uygundur. WebSocket node'ları arasında event dağıtımı yapılabilir. Topic design fan-out verimliliğini etkiler. JetStream durability gerektiğinde farklı özellikler sunar. Broker topology load test ile doğrulanmalıdır.

Kafka

Kafka durable event streaming ve yüksek throughput için kullanılabilir. WebSocket gateway'e doğrudan transient presence taşıması her zaman gerekli değildir. Business event ve replay gereksiniminde güçlüdür. Partition key ordering sınırını belirler. Consumer lag monitoring realtime delivery için önemlidir.

Socket.IO

Socket.IO realtime application geliştirme için event ve room abstraction sunar. Reconnect ve fallback gibi client özellikleri geliştirme hızını artırabilir. Native WebSocket protokolüyle birebir aynı wire protocol değildir. Cluster kullanımında adapter ve shared messaging gerekir. Production kapasitesi gerçek room ve message pattern'iyle test edilmelidir.

uWebSockets

uWebSockets yüksek performanslı WebSocket server geliştirmede kullanılan seçeneklerden biridir. Connection overhead ve throughput açısından güçlü benchmark sonuçları sunabilir. Library API ve ecosystem fit ekip yetkinliğiyle değerlendirilmelidir. Yüksek benchmark sonucu tek başına production architecture garantisi değildir. Observability ve failure management yine uygulama sorumluluğundadır.

Open Source ve İşbirliğinin WebSocket Ekosistemindeki Rolü

Açık kaynak toplulukları realtime sistem performansı konusunda ölçülebilir deneyim paylaşımını kolaylaştırır. Proxy, runtime ve broker projelerinde gerçek workload bug'ları community katkılarıyla çözülebilir. Benchmark çalışmalarının metodolojisi açık olduğunda sonuçlar daha güvenilir hale gelir. Ortak load-test laboratuvarları farklı teknolojilerin aynı koşulda değerlendirilmesini sağlar. Bu işbirliği özellikle yerel yazılım topluluklarında networking ve dağıtık sistem bilgisinin hızla yayılmasına yardımcı olur.

Load Balancer Projelerine Katkı

Load balancer projelerine bug report, documentation veya benchmark katkısı yapılabilir. Reproducible connection test gerçek problemin çözümünü hızlandırır. Timeout veya protocol edge case küçük test projesiyle gösterilebilir. Upstream katkı aynı problemi yaşayan birçok ekibe fayda sağlar. Contribution süreci network protokollerini öğrenmek için de değerlidir.

Realtime Framework'leri

Realtime framework'ler connection, room ve reconnect yönetimini kolaylaştırabilir. Açık kaynak kod runtime davranışını inceleme fırsatı sunar. Performance issue varsa profiler sonucu community ile paylaşılabilir. Framework abstraction'ın altındaki WebSocket protokolü öğrenilmelidir. Bu bilgi problem çıktığında daha hızlı debugging sağlar.

Benchmark Çalışmaları

Benchmark yalnız maksimum connection sayısını ölçmemelidir. Message throughput, p99 latency, memory ve recovery davranışı raporlanmalıdır. Test script açık paylaşılırsa sonuçlar tekrar üretilebilir. Hardware ve network koşulları belirtilmelidir. Community benchmark'ı kendi production workload'unuzda tekrar doğrulanmalıdır.

Açık Kaynak Load-Test Araçları

Load-test araçları çok sayıda WebSocket client simüle edebilir. Script gerçek handshake, heartbeat ve message davranışını uygulamalıdır. Distributed generation desteği yüksek connection hedefinde önemlidir. Tool'un kendi CPU ve socket limitleri izlenmelidir. Sonuçların server değil generator bottleneck'i olmadığı doğrulanmalıdır.

Community Best Practices

Community deneyimleri reconnect, heartbeat ve timeout gibi konularda güçlü başlangıç bilgisi sunar. Her öneri kendi workload'unuz için otomatik doğru değildir. Özellikle kernel tuning değerleri ölçüm olmadan kopyalanmamalıdır. Paylaşılan yöntem production-like test ile doğrulanmalıdır. En iyi pratik gerçek sistem verisiyle yaşayan bir dokümana dönüşmelidir.

Ortak Performans Laboratuvarları

Ortak laboratuvar geliştiricilerin NGINX, Kubernetes, Redis ve farklı runtime'ları aynı workload altında test etmesini sağlar. Katılımcılar connection limit ve failure davranışını doğrudan gözlemleyebilir. Sonuçlar açık benchmark raporu olarak paylaşılabilir. Böyle çalışmalar teori ile production davranışı arasındaki farkı öğretir. Diyarbakır Yazılım Topluluğu benzeri yerel organizasyonlar bu tür uygulamalı teknik işbirliği için güçlü ortam oluşturabilir.

Diyarbakır Yazılım Topluluğu İçin WebSocket Proje Fikirleri

WebSocket konusunu öğrenmenin en etkili yollarından biri ölçülebilir küçük sistemler geliştirmektir. Chat uygulaması yalnız UI projesi olarak değil, load balancing ve observability laboratuvarı olarak tasarlanabilir. Redis Pub/Sub, Kubernetes ve reconnect stratejileri ayrı modüller halinde denenebilir. Sonuçların açık source code ve benchmark raporuyla paylaşılması topluluk bilgisini büyütür. Mevcut proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects adresinde inceleyerek benzer teknik üretimlerin nasıl ele alındığını görebilirsiniz.

Açık Kaynak Realtime Chat Sistemi

Basit chat sistemi room, presence ve message delivery gibi temel WebSocket kavramlarını öğretir. İlk sürüm tek node çalışabilir. Sonra Redis Pub/Sub eklenerek multi-node hale getirilebilir. Query ve broker metric'leri dashboard'a taşınabilir. Project roadmap her aşamada load test hedefi içerebilir.

WebSocket Load-Test Aracı

Topluluk odaklı load-test aracı connection ramp ve message rate senaryolarını destekleyebilir. Distributed worker mimarisi eklenebilir. CSV veya Prometheus output üretilebilir. Generator resource metric'leri de sonuçla birlikte raporlanmalıdır. Böyle bir proje networking ve concurrency bilgisini birlikte geliştirir.

Redis Pub/Sub Tabanlı Cluster

Birden fazla WebSocket server Redis Pub/Sub üzerinden room event'leri paylaşabilir. Connection registry Redis üzerinde tutulabilir. Node crash ve stale registry testi yapılabilir. Pub/Sub kaybında uygulamanın davranışı gözlemlenebilir. Sonraki aşamada Redis Streams ile replay karşılaştırması yapılabilir.

Kubernetes WebSocket Laboratuvarı

Kubernetes laboratuvarı Deployment, Service, Ingress ve HPA davranışını gerçek WebSocket connection'larla gösterebilir. Rolling update sırasında connection loss ölçülebilir. preStop ve draining eklenerek fark karşılaştırılır. Custom connection metric ile autoscaling uygulanabilir. Sonuçlar adım adım teknik içerik haline getirilebilir.

Realtime Monitoring Dashboard'u

Dashboard active connection, message rate ve p99 latency gösterebilir. Pod başına connection skew paneli eklenebilir. Reconnect storm sırasında metric değişimi gözlemlenir. Prometheus ve Grafana entegrasyonu pratik observability deneyimi sağlar. Alert kuralları gerçek failure testleri üzerinden ayarlanabilir.

Open Source Performans Benchmark Projesi

Farklı runtime veya load balancing algoritmaları aynı test koşulunda karşılaştırılabilir. Amaç tek kazanan bulmak yerine trade-off'ları göstermek olmalıdır. Memory, CPU, p99 latency ve recovery time birlikte raporlanabilir. Test dataset ve script açık paylaşılmalıdır. Böyle proje yerel topluluğun ölçüm odaklı mühendislik kültürünü güçlendirir.

Yazılımcılar WebSocket ve Realtime Sistemlerde Nasıl Uzmanlaşabilir?

WebSocket uzmanlığı yalnız bir kütüphanenin API'sini bilmekten daha geniştir. HTTP, TCP, Linux networking ve async programming temelleri doğrudan production problemlerine yansır. Redis, broker, reverse proxy ve Kubernetes bilgisi sistemin dağıtık tarafını anlamayı sağlar. Observability olmadan performans debugging eksik kalır. Açık kaynak projelere katkı gerçek edge case'lerle çalışmanın en iyi yollarından biridir.

HTTP ve TCP Temelleri

Handshake, TCP connection ve TLS davranışını anlamak debugging süresini ciddi azaltır. Packet loss ve RTT kavramları realtime latency'yi açıklar. HTTP upgrade akışı proxy sorunlarını anlamayı kolaylaştırır. TCP bağlantısının backend değiştiremeyeceği gerçeği load balancing tasarımını belirler. Teoriyi packet capture ve küçük deneylerle pekiştirmek faydalıdır.

Linux Networking

File descriptor, socket backlog ve keepalive yüksek connection sistemlerinde önem kazanır. Kernel metric'lerini okumak uygulama ile OS bottleneck'ini ayırmayı sağlar. Tuning değerleri ezberlenmemelidir. Load test ile limit ortaya çıkarılmalıdır. Container ve host network katmanları birlikte öğrenilmelidir.

Async Programming

Async programming çok sayıda I/O işlemini az thread ile yönetmeyi sağlar. Event loop üzerinde blocking işlem yapmanın etkisi anlaşılmalıdır. Backpressure ve cancellation temel konulardır. Runtime profiler kullanmak teoriyi gerçek davranışla birleştirir. Async kod otomatik olarak hızlı değildir.

Redis ve Message Brokers

Pub/Sub, queue ve event log farklarını anlamak doğru broker seçimini sağlar. Delivery semantics ve consumer lag realtime sistemin temel kavramlarıdır. Redis hızlı ephemeral messaging için pratik olabilir. Kafka veya başka durable broker farklı ihtiyaçlara cevap verir. Küçük demo cluster kurmak güçlü öğrenme yöntemidir.

NGINX / HAProxy

Reverse proxy ve load balancer config'i WebSocket connection lifecycle'ını doğrudan etkiler. Upgrade, timeout ve least connections gibi ayarlar uygulamalı öğrenilmelidir. Draining ve health check failure testleri yapılabilir. Access log ile application log korele edilmelidir. Production sorununun önemli bir bölümü bu ara katmanlarda oluşabilir.

Docker

Container resource limitleri WebSocket capacity üzerinde doğrudan etkilidir. File descriptor ve memory davranışı container içinde kontrol edilmelidir. Graceful shutdown signal handling doğru yapılmalıdır. Image ve runtime minimal tutulabilir. Local multi-container broker ve gateway lab öğrenmeyi kolaylaştırır.

Kubernetes

Kubernetes lifecycle WebSocket deployment'larında kritik konudur. Readiness, preStop ve terminationGracePeriodSeconds uygulamalı öğrenilmelidir. HPA custom metric ile connection scaling yapılabilir. Service ve Ingress connection behavior test edilmelidir. Rolling update sırasında real client kullanmak teoriyi görünür hale getirir.

Observability

Metric, log ve trace olmadan performans optimizasyonu tahmine dönüşür. Prometheus histogram ve counter tipleri öğrenilmelidir. p95 ve p99 yorumlama pratiği yapılmalıdır. High cardinality metric hatalarından kaçınılmalıdır. Failure drill sırasında dashboard üzerinden root cause bulunmaya çalışılabilir.

Distributed Systems

Cross-node messaging, eventual consistency ve failure handling dağıtık sistem bilgisidir. WebSocket yalnız transport sağladığı için bu konular ayrıca çözülür. Message ordering ve duplicate delivery pratiğe dökülmelidir. Region failure ve network partition düşünülmelidir. Veri tutarlılığı ile realtime delivery aynı problem olarak görülmemelidir.

Açık Kaynak Projelere Katkı

Açık kaynak contribution gerçek kod ve issue üzerinden öğrenmeyi hızlandırır. Dokümantasyon, test veya benchmark katkısıyla başlanabilir. Minimal reproduction hazırlamak debugging becerisini geliştirir. Performance issue için profiler sonucu paylaşmak değerlidir. Topluluk geri bildirimi farklı production deneyimlerini görmeyi sağlar.

Örnek Bir Ölçeklenebilir WebSocket Mimarisi Nasıl Kurulur?

Ölçeklenebilir WebSocket mimarisi tek seferde teknoloji listesi seçerek kurulmaz. Önce trafik modeli, connection hedefi ve delivery semantics netleştirilmelidir. Sonra runtime, gateway, shared state ve Pub/Sub katmanı seçilir. Heartbeat, reconnect, backpressure ve autoscaling failure davranışıyla birlikte tasarlanır. En son load ve failure testleriyle kapasite varsayımları doğrulanır.

Adım 1 — Trafik Modelini Belirleme

İlk olarak kaç aktif kullanıcı, connection süresi ve message rate tahmin edilir. Incoming ve outgoing traffic ayrı hesaplanmalıdır. Fan-out ratio room yapısına göre belirlenir. Payload size dağılımı ölçülür. Bu veriler sonraki bütün capacity kararlarının temelidir.

Adım 2 — Concurrent Connection Hedefini Belirleme

Normal ve peak concurrent connection sayısı ayrı tanımlanır. Growth hedefi en az birkaç dönem ileri düşünülür. Failure headroom eklenir. Tek pod hedefi load test ile belirlenir. Replica hesabı teorik maksimum yerine güvenli kapasiteye göre yapılır.

Adım 3 — WebSocket Runtime Seçimi

Runtime ekip yetkinliği ve workload temelinde seçilir. Memory per connection ve p99 latency benchmark edilir. Blocking dependency olup olmadığı kontrol edilir. Observability desteği değerlendirilir. Dil değişikliği yalnız ölçülebilir ihtiyaç varsa yapılır.

Adım 4 — Connection Gateway Oluşturma

Gateway authentication, connection lifecycle ve message validation sorumluluğunu üstlenebilir. Business logic'in tamamı gateway içinde tutulmamalıdır. Connection registry local ve distributed katmana ayrılabilir. Rate limit ve backpressure burada uygulanabilir. Gateway mümkün olduğunca stateless tasarlanır.

Adım 5 — Load Balancer Seçimi

Load balancer WebSocket upgrade ve uzun connection'ı desteklemelidir. Least connections başlangıç algoritması olabilir. Idle timeout heartbeat ile uyumlu ayarlanır. Health ve draining behavior test edilir. Edge capacity connection rate ve concurrent connection için ölçülür.

Adım 6 — Shared State Tasarımı

Session ve connection metadata'nın hangi kısmının paylaşılacağı belirlenir. Redis veya başka distributed store kullanılabilir. Durable business state database'de kalabilir. TTL stale connection cleanup için uygulanabilir. Shared store failure senaryosu ayrıca tasarlanır.

Adım 7 — Pub/Sub Katmanı

Cross-node message delivery için broker seçilir. Ephemeral ve durable event türleri ayrılır. Topic ve room granularity fan-out ihtiyacına göre tasarlanır. Broker throughput load test ile ölçülür. Consumer lag dashboard'a eklenir.

Adım 8 — Heartbeat

Heartbeat interval network timeout değerlerine göre seçilir. Protocol ping veya application heartbeat kullanılabilir. Jitter heartbeat trafiğini yayabilir. Dead connection timeout registry cleanup ile bağlanır. Maliyet connection count ile çarpılarak hesaplanır.

Adım 9 — Reconnect ve Backoff

Client exponential backoff ve random jitter uygular. Maximum backoff user experience'e göre sınırlanır. Retry budget ek koruma sağlar. Resume token ile missed event recovery yapılır. Reconnect storm load testi mutlaka çalıştırılır.

Adım 10 — Backpressure

Per-connection queue limit tanımlanır. Message class'a göre drop veya coalescing policy seçilir. Slow consumer metric oluşturulur. Queue memory budget hesaplanır. Gerekirse client disconnect edilir.

Adım 11 — Autoscaling

CPU yanında active connection ve message rate kullanılır. Custom metric HPA veya KEDA ile entegre edilebilir. Scale-out threshold headroom bırakır. Scale-in draining ile yapılır. Scaling event'leri p99 latency ile korele edilir.

Adım 12 — Connection Draining

Deployment ve scale-in öncesi pod yeni connection kabulünü durdurur. Existing client'lara reconnect zamanı verilir. Drain deadline belirlenir. Force disconnect sayısı izlenir. Lifecycle Kubernetes termination ayarlarıyla uyumlu hale getirilir.

Adım 13 — Monitoring

Connection, message, latency ve queue metric'leri dashboard'a eklenir. Pod başına skew görünür hale getirilir. Broker ve load balancer metric'leri aynı ekranda ilişkilendirilir. Disconnect reason kodları analiz edilir. Alert yalnız kullanıcı etkisi oluşturan durumlara odaklanır.

Adım 14 — Load Testing

Connection ramp, throughput, soak ve spike testleri çalıştırılır. Real payload ve heartbeat kullanılır. Generator capacity ayrıca izlenir. p95, p99 ve error rate raporlanır. Güvenli operating limit test sonucundan çıkarılır.

Adım 15 — Failure Testing

Pod, broker ve region failure senaryoları test edilir. Reconnect storm kapasitesi ölçülür. Message loss ve duplicate behavior doğrulanır. Recovery time SLO ile karşılaştırılır. Runbook gerçek test sonucuna göre güncellenir.

WebSocket Yük Dengelemede Yapılan Yaygın Hatalar

WebSocket altyapısındaki yaygın hatalar çoğunlukla kısa HTTP request alışkanlıklarının uzun connection modeline taşınmasından kaynaklanır. Round robin veya sticky session varsayılanları ölçülmeden kullanılabilir. Autoscaling yalnız CPU'ya bağlanabilir. Heartbeat ve draining eksikliği küçük failure'ları büyük reconnect dalgasına dönüştürür. Bu hataları önlemenin en güçlü yolu connection lifecycle ve failure davranışını production benzeri test etmektir.

WebSocket'ı Normal HTTP Trafiği Gibi Düşünmek

HTTP request kısa süreli olduğu için load doğal olarak sık yeniden dağıtılır. WebSocket connection saatler boyunca tek backend üzerinde kalabilir. Bu fark scale-out ve deployment davranışını değiştirir. Request count yerine connection ve message metric'leri gerekir. Kapasite planı uzun connection modeline göre yapılmalıdır.

Körlemesine Round Robin Kullanmak

Round robin kötü bir algoritma değildir, fakat connection duration çok değişkense skew oluşturabilir. Backend active load dikkate alınmaz. Least connections daha dengeli olabilir. Trafik per connection farklıysa daha gelişmiş metric gerekir. Algoritma production distribution metric'iyle doğrulanmalıdır.

Her Durumda Sticky Session Kullanmak

Sticky session reconnect sonrası state problemini gizleyebilir. Node failure olduğunda affinity zaten bozulur. Shared state olmadan recovery zorlaşır. Load distribution da dengesizleşebilir. Mümkün olduğunda backend bağımlılığı azaltılmalıdır.

Uygulama State'ini Tek Sunucuda Tutmak

User session veya room state sadece local memory'deyse cross-node messaging zorlaşır. Reconnect farklı node'a gittiğinde state kaybolur. Critical shared state distributed store'a taşınabilir. Local cache yine performans için kullanılabilir. State boundary açık tasarlanmalıdır.

Sadece CPU ile Autoscaling Yapmak

Idle connection çok düşük CPU kullanabilir. Pod file descriptor ve memory limitine yaklaşırken HPA scale-out yapmayabilir. Active connection ve event-loop lag daha anlamlı olabilir. Composite metric daha güvenli sonuç verir. Threshold load test ile bulunmalıdır.

Heartbeat Kullanmamak

Dead veya half-open connection registry'de uzun süre kalabilir. Proxy idle timeout bağlantıyı beklenmedik biçimde kapatabilir. Presence yanlış görünebilir. Heartbeat failure detection sağlar. Interval gereksiz trafik üretmeyecek şekilde seçilmelidir.

Reconnect Backoff Uygulamamak

Immediate retry failure sırasında handshake yükünü artırır. Binlerce client aynı anda server'a dönebilir. Exponential backoff ve jitter yükü zamana yayar. Retry budget ek koruma sağlar. Client SDK davranışı test edilmelidir.

Connection Draining Yapmadan Pod Kapatmak

Pod aniden kapanırsa bütün connection'lar aynı anda düşer. Reconnect storm oluşabilir. Draining yeni bağlantıları durdurur ve mevcut client'lara zaman verir. Grace period rollout'u daha güvenli hale getirir. Force disconnect sayısı deployment kalitesini gösterir.

Slow Consumer'ları Kontrol Etmemek

Slow client send queue'nun sınırsız büyümesine neden olabilir. Memory exhaustion bütün node'u düşürebilir. Queue limit ve drop policy gerekir. Slow consumer metric izlenmelidir. Gerekirse connection kapatılmalıdır.

Connection Sayısını İzleyip Trafik Yoğunluğunu İzlememek

On bin idle connection ile on bin yoğun connection aynı kapasiteyi tüketmez. Messages per second ve bytes per second izlenmelidir. Fan-out amplification CPU ve network yükünü büyütür. Node başına traffic skew hot backend oluşturabilir. Connection count tek başına yeterli değildir.

Idle Timeout'ları Kontrol Etmemek

Load balancer ve proxy default timeout değerleri WebSocket için uygun olmayabilir. Bağlantılar belirli aralıklarla kopar. Kullanıcı bunu uygulama hatası gibi görebilir. Heartbeat ve timeout değerleri birlikte ayarlanmalıdır. Synthetic long connection testi config değişikliklerinden sonra çalıştırılmalıdır.

Sadece Ortalama Latency Ölçmek

Average latency tail problemlerini gizler. Kullanıcıların küçük bölümü saniyelik gecikme yaşayabilir. P95 ve p99 metric'leri izlenmelidir. Connection skew ve queue sorunları genellikle tail değerlerinde görünür. SLO percentile üzerinden tanımlanmalıdır.

Reconnect Storm Testi Yapmamak

Normal steady-state test server'ın gerçek failure kapasitesini göstermez. Pod veya load balancer kaybında connection rate yüzlerce kat artabilir. TLS ve authentication path doygun hale gelir. Reconnect test client backoff implementation'ını doğrular. Failure capacity production öncesinde bilinmelidir.

WebSocket Sistemlerinin Geleceği

Realtime sistemlerin geleceğinde connection-aware routing, edge gateway ve global messaging katmanlarının daha önemli hale gelmesi beklenebilir. Autoscaling yalnız CPU yerine connection ve traffic pattern'lerine daha fazla odaklanacaktır. QUIC tabanlı yeni transport yaklaşımları farklı bağlantı yönetimi seçenekleri sunabilir. Traffic prediction kapasite hazırlığını iyileştirebilir, ancak sistem kararları yine ölçülebilir sınırlar içinde tutulmalıdır. Otonom altyapı fikri bile güvenli failure budget ve insan tarafından anlaşılabilir observability gerektirir.

Daha Akıllı Connection-Aware Load Balancing

Gelecekte routing yalnız connection sayısına değil message rate ve queue pressure'a daha fazla bakabilir. Backend real-time capacity score yayınlayabilir. Load balancer yeni connection'ı en uygun node'a gönderebilir. Hızlı metric değişimi oscillation oluşturmamalıdır. Stabilizasyon algoritmaları önemli hale gelecektir.

Edge WebSocket Gateways

Edge gateway kullanıcıya yakın noktada connection terminate ederek RTT'yi azaltabilir. Backend'e optimize edilmiş internal protocol kullanılabilir. Global connection state yönetimi daha dağıtık hale gelir. Region outage sırasında edge başka origin'e bağlanabilir. Cost ve operational visibility yeni trade-off'lar oluşturur.

Serverless Realtime Platforms

Serverless realtime platformlar connection management operasyonunu managed hizmete taşıyabilir. Ekip uygulama message logic'ine odaklanır. Pricing yüksek connection veya message hacminde dikkatle hesaplanmalıdır. Vendor limitleri protocol tasarımını etkileyebilir. Custom backpressure veya routing ihtiyacı daha sınırlı olabilir.

Global Pub/Sub

Global Pub/Sub region'lar arasında event dağıtımını kolaylaştırabilir. Ordering ve consistency sınırları yine uygulama tarafından anlaşılmalıdır. Cross-region latency tamamen ortadan kalkmaz. Topic locality maliyeti azaltabilir. Durable ve ephemeral event'ler farklı katmanlarda tutulabilir.

Adaptive Autoscaling

Adaptive autoscaling traffic pattern ve connection trend'lerini birlikte değerlendirebilir. Scale-out connection rate yükselirken CPU artmadan önce başlayabilir. Historical pattern predictive capacity sağlayabilir. Yanlış tahmin aşırı maliyet veya düşük kapasite oluşturabilir. Manuel safety threshold her zaman korunmalıdır.

QUIC ve Yeni Transport Yaklaşımları

QUIC UDP üzerinde multiplexing ve farklı connection özellikleri sunar. WebTransport gibi yeni API'ler bazı realtime kullanım alanlarında değerlendirilebilir. WebSocket yaygın uyumluluğu nedeniyle uzun süre önemli kalacaktır. Yeni transport'a geçiş yalnız benchmark değil client support ile belirlenir. Protocol abstraction application logic'i taşıma katmanından ayırmalıdır.

AI Tabanlı Traffic Prediction

Trafik tahmin modelleri geçmiş connection ve message verisinden kapasite ihtiyacını öngörebilir. Kampanya veya günlük kullanım pattern'i önceden scale-out için kullanılabilir. Tahmin tek başına autoscaling kontrolü olmamalıdır. Gerçek zamanlı safety metric'leri yanlış tahmini düzeltmelidir. Modelin sağladığı fayda maliyet ve hata oranıyla ölçülmelidir.

Otonom Realtime Infrastructure

Daha fazla altyapı kararı otomatik hale gelebilir. Routing, scaling ve draining metric'lere göre dinamik yönetilebilir. Otomasyonun neden karar verdiği gözlemlenebilir olmalıdır. Failure durumunda güvenli fallback gerekir. İnsan operatörün sistemi anlayabildiği basit sınırlar korunmalıdır.

Sıkça Sorulan Sorular

WebSocket sistemleri hakkında sık sorulan sorular çoğunlukla load balancing, sticky session, autoscaling ve connection kapasitesi çevresinde toplanır. Bu soruların çoğunda tek bir doğru cevap yerine workload'a bağlı seçim vardır. Connection süresi, message rate, fan-out ve failure hedefleri sonuçları değiştirir. Aşağıdaki yanıtlar production kararlarında hangi sinyallere bakılması gerektiğini özetler. Her öneri gerçek load ve failure testleriyle doğrulanmalıdır.

WebSocket nedir?

WebSocket istemci ve sunucu arasında uzun süre açık kalabilen çift yönlü iletişim protokolüdür. Handshake HTTP ile başlar ve protocol upgrade sonrasında frame tabanlı iletişime geçilir. Chat, oyun ve realtime bildirim sistemlerinde sık kullanılır. Her connection server üzerinde sürekli resource tüketir. Bu nedenle connection lifecycle performans tasarımının temelidir.

WebSocket bağlantıları nasıl load balance edilir?

Yeni WebSocket connection load balancer tarafından bir backend'e yönlendirilir. Bağlantı açık kaldığı sürece aynı backend üzerinden devam eder. Round robin veya least connections kullanılabilir. Stateful session yerine shared state yatay ölçeklemeyi kolaylaştırır. Connection skew production metric'i olarak izlenmelidir.

WebSocket için sticky session gerekli midir?

Aktif WebSocket connection zaten aynı backend üzerinde kalır. Sticky session daha çok reconnect sonrası aynı backend'e dönüş ihtiyacını ifade eder. Shared state ve Pub/Sub kullanılıyorsa çoğu sistemde zorunlu değildir. Local-only session state affinity ihtiyacı yaratabilir. Uzun vadede stateless gateway daha esnek olur.

WebSocket için round robin mı least connections mı kullanılmalı?

Benzer connection lifetime durumunda round robin yeterli olabilir. Uzun ve değişken bağlantılarda least connections mevcut yükü daha iyi yansıtabilir. Connection başına traffic çok değişiyorsa iki yöntem de eksik kalabilir. Messages per second ve queue depth eklenebilir. Karar production-like benchmark ile verilmelidir.

NGINX WebSocket load balancing nasıl yapılır?

NGINX upstream backend grubuna WebSocket connection yönlendirebilir. Upgrade ve Connection header'ları doğru iletilmelidir. Proxy timeout uzun connection kullanımına göre ayarlanmalıdır. Least connections WebSocket için değerlendirilebilir. Health ve draining davranışı deployment ile birlikte test edilmelidir.

HAProxy WebSocket destekler mi?

HAProxy WebSocket handshake ve uzun tunnel bağlantılarını destekleyebilir. HTTP veya TCP mode kullanım senaryosuna göre seçilebilir. Least connections ve timeout tunnel ayarları önemlidir. Health check yeni connection routing'ini etkiler. Gerçek concurrent connection testiyle kapasite doğrulanmalıdır.

Kubernetes'te WebSocket nasıl ölçeklendirilir?

WebSocket server pod'ları Deployment ile yatay çoğaltılabilir. Service ve Ingress yeni connection'ları pod'lara yönlendirir. Existing connection'lar yeni pod'a taşınmaz. HPA custom connection metric kullanabilir. Scale-in sırasında connection draining uygulanmalıdır.

WebSocket autoscaling hangi metriğe göre yapılmalıdır?

Tek bir metric her sistem için yeterli değildir. Active connection, CPU, memory, message rate ve event-loop lag birlikte değerlendirilebilir. Sessiz connection yoğun sistemde CPU yanıltıcı olabilir. Fan-out yoğun sistemde message rate daha belirleyicidir. Composite metric güvenli scaling sağlayabilir.

Bir sunucu kaç WebSocket bağlantısı kaldırabilir?

Bu sayı donanım, runtime ve message workload'a bağlıdır. File descriptor ve memory per connection temel sınırlar arasındadır. Idle connection benchmark gerçek trafik kapasitesini göstermez. Message rate ve fan-out eklenmelidir. Güvenli limit failure headroom ile load test sonucundan belirlenir.

WebSocket heartbeat nedir?

Heartbeat connection'ın canlı olduğunu belirlemek için düzenli ping veya application mesajı göndermektir. Dead socket cleanup ve idle timeout önleme sağlar. Interval çok kısa seçilmemelidir. Timeout failure detection hedefini belirler. Heartbeat trafiği toplam kapasite hesabına eklenmelidir.

WebSocket reconnect storm nedir?

Reconnect storm çok sayıda client'ın aynı anda yeniden bağlantı kurmaya çalışmasıdır. Pod, load balancer veya region failure tetikleyebilir. TLS ve authentication path aşırı yüklenebilir. Exponential backoff ve random jitter riski azaltır. Failure load test bu davranışı mutlaka ölçmelidir.

Backpressure nedir?

Backpressure producer consumer'dan hızlı olduğunda queue büyümesini kontrol eden mekanizmadır. WebSocket send buffer sınırsız bırakılmamalıdır. Queue limit, coalescing veya drop policy uygulanabilir. Slow consumer gerekirse disconnect edilir. Amaç bir client'ın bütün node memory'sini tüketmesini engellemektir.

Redis WebSocket sistemlerinde neden kullanılır?

Redis session metadata, presence ve connection registry için kullanılabilir. Pub/Sub node'lar arası düşük latency event dağıtımı sağlar. Subscriber offline olduğunda Pub/Sub mesajı saklanmaz. Replay gerekiyorsa Streams veya durable broker gerekebilir. Redis HA production mimarisinin parçası olmalıdır.

WebSocket bağlantıları pod değiştirince ne olur?

Aktif socket başka pod'a canlı taşınmaz. Pod kapanırsa connection kesilir. Client yeni backend'e reconnect eder. Shared state session'ın yeni pod üzerinde kurulmasını kolaylaştırır. Resume mekanizması kaçırılan mesajları tamamlayabilir.

Connection draining nedir?

Connection draining backend'in kapatılmadan önce yeni connection kabulünü durdurmasıdır. Existing socket'ler belirli süre korunur. Client'lara kontrollü reconnect fırsatı verilir. Drain deadline sonunda kalan connection'lar kapatılabilir. Rolling deployment ve scale-in sırasında kullanılır.

WebSocket için hangi programlama dili kullanılmalıdır?

Tek bir zorunlu dil yoktur. Event-driven veya hafif concurrency runtime yüksek connection sayısında avantaj sağlar. Node.js, Go, Java, Rust ve Python farklı ihtiyaçlara uygundur. Ekip deneyimi ve observability kararı etkiler. Gerçek workload benchmark'ı en güvenilir seçim yöntemidir.

WebSocket mi SSE mi daha performanslıdır?

Bu seçim kullanım yönüne bağlıdır. Sadece server-to-client event gerekiyorsa SSE daha basit olabilir. Yoğun çift yönlü iletişimde WebSocket daha doğal çalışır. Her iki model de uzun connection yönetimi gerektirir. Performans gerçek message pattern ve altyapı üzerinde ölçülmelidir.

100 bin WebSocket bağlantısı nasıl test edilir?

Yük generator'ın file descriptor ve network kapasitesi önce doğrulanmalıdır. Gerekirse distributed load generation kullanılmalıdır. Connection ramp ve message throughput ayrı test edilmelidir. Server ile generator metric'leri birlikte izlenmelidir. Sonuç p99 latency ve resource kullanımıyla yorumlanmalıdır.

WebSocket performansı nasıl ölçülür?

Active connections, connection rate, messages per second ve bytes per second temel metric'lerdir. Queue depth ve slow consumer count backpressure durumunu gösterir. Handshake ve message delivery için p95 ve p99 latency izlenmelidir. Node başına connection skew load balancing kalitesini gösterir. Failure test sonucundaki reconnect latency de performansın önemli parçasıdır.

WebSocket Performansı Hakkında Ek Sık Sorulan Sorular

Production ortamında WebSocket konusunda danışmanlık arayan ekiplerin soruları genellikle aynı teknik başlıklarda birleşir. Sorun yalnızca daha fazla pod eklemekle çözülmez, çünkü load balancing, state, Pub/Sub ve reconnect davranışı birbirini doğrudan etkiler. Bu nedenle performans değerlendirmesi uçtan uca yapılmalıdır. Özellikle connection başına maliyet ve failure kapasitesi bilinmeden yalnız steady-state sonuçlara güvenmek risklidir. Aşağıdaki cevaplar bu karar alanlarını daha kısa bir çerçevede toplar.

WebSocket bağlantılarında performans ve yük dengeleme nasıl optimize edilir?

Önce connection ve mesaj trafiğini ölçmek gerekir. Active connection, connection rate, p95 ve p99 latency, event-loop lag, queue depth ve bytes per second birlikte izlenmelidir. Load balancer tarafında connection lifetime değişkense least connections yaklaşımı denenebilir, ancak trafik yoğunluğu node'lar arasında farklıysa capacity-aware metric'ler daha doğru sonuç verebilir. Uygulama state'ini backend memory'sine bağımlı tutmamak, Redis veya başka shared store kullanmak yatay ölçeklemeyi kolaylaştırır. WebSocket Bağlantılarında Performans ve Yük Dengeleme optimizasyonunda son adım her değişikliği production benzeri load, reconnect ve failure testleriyle doğrulamaktır.

WebSocket yük dengelemede Sticky Session gerekli midir ve hangi durumlarda kullanılmalıdır?

Aktif WebSocket bağlantısı zaten bağlantı süresince aynı backend'e bağlıdır. Sticky session daha çok reconnect sonrasında aynı backend'e dönmek gerektiğinde anlam kazanır. Session ve subscription state yalnız local memory'de tutuluyorsa affinity kısa vadede kolaylık sağlayabilir. Ancak node failure durumunda bu state yine kaybolabileceği için shared state ve distributed messaging daha dayanıklı mimari oluşturur. Uzun vadeli ölçeklenebilir sistemlerde sticky session zorunluluk değil, belirli stateful tasarımlarda bilinçli kullanılan bir tercih olmalıdır.

Nginx HAProxy veya bulut tabanlı Load Balancer ile WebSocket trafiği nasıl dağıtılır?

Bu katmanların temel görevi client handshake'ini sağlıklı backend'e yönlendirmek ve bağlantı kapanana kadar tüneli korumaktır. WebSocket upgrade header'ları ve uzun connection timeout değerleri doğru yapılandırılmalıdır. Round robin basit sistemlerde yeterli olabilirken least connections değişken connection lifetime için daha dengeli sonuç verebilir. Managed cloud çözümlerinde idle timeout, connection limit ve maliyet modeli ayrıca kontrol edilmelidir. Hangi teknoloji seçilirse seçilsin backend connection distribution, handshake latency ve disconnect rate production dashboard üzerinden takip edilmelidir.

Çok sayıda eş zamanlı WebSocket bağlantısında yatay ölçekleme Redis Pub/Sub ve bağlantı durumu yönetimi nasıl yapılır?

Her WebSocket node yalnız kendi fiziksel socket'lerini doğrudan yönetebilir. Kullanıcının hangi node üzerinde bulunduğunu belirleyen distributed connection registry Redis gibi bir store üzerinde tutulabilir. Node'lar arası mesajlar Redis Pub/Sub veya ihtiyaca göre başka broker üzerinden taşınabilir. Pub/Sub transient event'ler için uygundur, fakat replay veya durable delivery gerekiyorsa Redis Streams ya da event log yaklaşımı gerekebilir. Connection state, session state ve durable business data ayrı katmanlarda tutulduğunda horizontal scaling çok daha yönetilebilir hale gelir.

WebSocket performans optimizasyonu ve yük dengeleme konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

WebSocket ve sunucu performans danışmanlığı yakınımda araması yapan ekipler için teknik çalışmanın yalnız proxy ayarlarına odaklanmaması önemlidir. Connection capacity, Redis Pub/Sub, Kubernetes lifecycle, backpressure, observability ve failure testing aynı değerlendirme içinde ele alınmalıdır. Diyarbakır Yazılım Topluluğu hakkında bilgi almak ve topluluğun çalışma yaklaşımını incelemek için https://www.diyarbakiryazilim.com.tr/about adresi kullanılabilir. Veri entegrasyonu ve sistemler arası akış tarafındaki teknik içeriklere örnek olarak https://www.diyarbakiryazilim.com.tr/posts/veri-ambari-data-warehouse-sistemlerine-entegrasyon içeriği de incelenebilir. Kurumsal WebSocket performans ve yük dengeleme optimizasyon hizmeti planlanırken önce mevcut sistemin metric ve load-test verilerinin çıkarılması en verimli başlangıç noktasıdır.

Sonuç

WebSocket sistemini ölçeklendirmek yalnız daha fazla sunucu eklemek değildir. Bağlantıların uzun süre backend üzerinde kalması load balancing, autoscaling ve deployment davranışını klasik HTTP servislerinden farklı hale getirir. Connection registry, Redis Pub/Sub, heartbeat, backpressure, draining ve reconnect stratejileri birlikte tasarlandığında sistem failure anlarında daha öngörülebilir çalışır. WebSocket Bağlantılarında Performans ve Yük Dengeleme konusunda başarılı bir production mimarisi, ortalama değerlerden çok connection dağılımı, p95 ve p99 latency, reconnect rate ve failure kapasitesini ölçen bir yaklaşım gerektirir. En önemli adım ise her mimari varsayımı gerçek connection sayısı, gerçek payload ve gerçek failure senaryolarıyla doğrulamaktır.

Uygulamanızda sürekli bağlantı kopmaları, dengesiz pod yükleri, yüksek reconnect oranı veya WebSocket autoscaling problemi yaşıyorsanız önce active connection, message throughput ve connection skew metric'lerini görünür hale getirin. Sonra load balancer algoritmasını, timeout'ları, shared state modelini ve connection draining akışını tek tek test edin. Kubernetes ve Redis tabanlı cluster kullanıyorsanız node failure ile reconnect storm senaryosunu özellikle ölçün. Teknik topluluk çalışmaları, projeler ve yazılım geliştirme içerikleri için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz. Ölçüm odaklı bir çalışma modeli kurduğunuzda WebSocket altyapısı yalnız daha hızlı değil, aynı zamanda daha öngörülebilir ve yönetilebilir hale gelir.