API Gateway ve Load Balancer Arasında TCP Port Exhaustion Çözümleri

Giriş

Yüksek ölçekli mikroservis mimarilerinde, API Gateway ile Load Balancer (LB) arasındaki trafik yoğunlaştığında sıkça karşılaşılan ancak teşhisi bazen zor olan bir sorun ortaya çıkar: TCP Port Exhaustion. Bu makalede, port tükenmesinin nedenlerini, TIME_WAIT durumunun rolünü ve üretim ortamlarında bu sorunu nasıl aşacağınızı teknik detaylarıyla inceleyeceğiz.

İçindekiler

• TCP Port Exhaustion Nedir?
• TIME_WAIT Durumunun Mekaniği ve Önemi
• Linux Kernel Parametreleri ile Optimizasyon
• Load Balancer ve Connection Pooling Stratejileri
• Sıkça Sorulan Sorular (SSS)
• Sonuç

TCP Port Exhaustion Nedir?

Bir istemci (örneğin API Gateway), bir sunucuya (Load Balancer) TCP üzerinden bağlandığında, işletim sistemi bu bağlantı için geçici bir kaynak portu (ephemeral port) atar. Linux tabanlı sistemlerde varsayılan port aralığı sınırlıdır. Saniyede binlerce kısa süreli bağlantı açılıp kapatıldığında, tüm kullanılabilir portlar rezerve edilir ve sistem yeni bağlantı taleplerine "Cannot assign requested address" hatasıyla yanıt vermeye başlar.

TIME_WAIT Durumunun Mekaniği

TCP protokolü gereği, bir bağlantı kapatıldıktan sonra soket hemen serbest bırakılmaz. Bağlantı, ağda gecikmiş olabilecek paketlerin doğru bir şekilde sonlandırılması için TIME_WAIT durumunda bir süre bekler (genellikle 60 saniye). Yüksek trafikli bir API Gateway üzerinde binlerce soketin aynı anda TIME_WAIT durumunda olması, yeni bağlantılar için port kalmamasına neden olan temel faktördür.

Linux Kernel Parametreleri ile Optimizasyon

Üretim ortamında bu sorunu yönetmek için Linux kernel parametreleri (sysctl) üzerinden şu düzenlemeler yapılmalıdır:

1. net.ipv4.tcp_tw_reuse

Bu parametre 1 olarak ayarlandığında, işletim sisteminin TIME_WAIT durumundaki soketleri yeni bağlantılar için güvenli bir şekilde yeniden kullanmasına olanak tanır. Modern mikroservis trafiği için en etkili çözümlerden biridir.

2. net.ipv4.ip_local_port_range

Varsayılan port aralığını genişleterek sistemin kapasitesini artırabilirsiniz. Örneğin:
net.ipv4.ip_local_port_range = 1024 65535 ayarı, kullanılabilir port sayısını maksimuma çıkarır.

3. net.core.somaxconn

Dinleme kuyruğunun limitini artırarak, yoğun trafik anlarında gelen bağlantı isteklerinin reddedilmesini önler.

Load Balancer ve Connection Pooling Stratejileri

Sadece kernel ayarları yeterli olmayabilir. Uygulama seviyesinde şu stratejiler uygulanmalıdır:

• HTTP Keep-Alive: Bağlantıların her istekten sonra kapatılmasını engeller. Mevcut bir TCP bağlantısı üzerinden birden fazla HTTP isteği gönderilmesini sağlayarak port ihtiyacını azaltır.
• Connection Pooling: API Gateway üzerinde, Load Balancer’a giden bağlantıları yöneten bir havuz oluşturulmalıdır. Bu sayede sürekli yeni soket açmak yerine mevcutlar verimli kullanılır.

Not: tcp_tw_recycle parametresi, NAT (Network Address Translation) kullanan istemcilerde bağlantı sorunlarına yol açtığı için modern sistemlerde (Kernel 4.12+) kaldırılmıştır ve kullanılmamalıdır.

Sıkça Sorulan Sorular (SSS)

Soket durumlarını nasıl izleyebilirim?

Terminal üzerinden ss -tan | awk '{print $1}' | sort | uniq -c komutunu kullanarak hangi durumda kaç adet soket bulunduğunu hızlıca görebilirsiniz.

TIME_WAIT süresini kısaltmak güvenli midir?

Genellikle önerilmez. Bunun yerine tcp_tw_reuse kullanmak protokol standartlarına daha uygundur ve veri bütünlüğünü bozmadan port tükenmesini önler.

Bu sorun sadece Load Balancer’da mı oluşur?

Hayır, port tükenmesi genellikle istemci tarafında (bağlantıyı başlatan API Gateway gibi) oluşur. Çünkü kaynak portunu tüketen taraf bağlantıyı başlatan taraftır.

Sonuç

API Gateway ve Load Balancer arasındaki TCP port exhaustion sorunu, doğru sistem parametreleri ve bağlantı yönetimiyle çözülebilir. tcp_tw_reuse ayarını etkinleştirmek, port aralığını genişletmek ve Keep-Alive mekanizmasını doğru yapılandırmak, yüksek performanslı ve kesintisiz bir üretim ortamı için kritik öneme sahiptir.