Proxy Havuzu Yönetimi: Round-Robin, Cooldown ve Sağlık

Proxy havuzu yönetimi, elinizde birden fazla proxy adresi varken hangi isteğin hangi adresten çıkacağına, bozulan adresin ne zaman devre dışı kalacağına ve ne zaman geri döneceğine istemci tarafında karar vermektir. Tek bir rotating gateway kullanıyorsanız bu kararların çoğunu gateway verir; adres seçimi, bozuk çıkışın ayıklanması ve dağılım sizin kodunuza hiç uğramaz. Havuz yönetimi, birden fazla uç noktanız olduğunda gündeme gelir.

RotatingProxy kataloğunda bu durum en çok IPv6 ürünlerinde yaşanır: paketler port bazlıdır (1, 5 ya da 10 port) ve her port kendi rotasyon ayarıyla ayrı bir uç noktadır. Beş portluk bir pakette beş kanalınız vardır ve işleri bu kanallara dağıtmak sizin kodunuzun işidir. İkinci durum, aynı GB bazlı gateway’e farklı oturum kimlikleriyle açılmış sticky kanallardır; her kanal kendi çıkış adresini korur ve istemci açısından ayrı bir proxy gibi davranır. Üçüncü durum, farklı ürünlerin (datacenter ve residential) tek bir işte birlikte kullanılmasıdır; burada seçim maliyeti de belirler.

Bu rehber istemci tarafındaki yapıyı anlatır: seçim algoritması, cooldown, sağlık kontrolü ve puanlama. Tek uç noktanın arkasında havuzu gateway’in nasıl yönettiği gateway rehberinde, bir isteğin ne zaman yeniden deneneceği ise retry ve backoff rehberinde anlatılıyor; ikisi de bu yazının tamamlayıcısıdır.

En küçük işe yarar havuz, her uç nokta için dört alan tutar: adres (şema, host, port, kullanıcı adı, parola), durum (aktif, cooldown’da, devre dışı), cooldown’un biteceği zaman ve son on isteğin sonuç geçmişi. Bu dört alan dışında kalan her şey (toplam istek sayısı, ortalama süre, son hata metni) ölçüm içindir, karar için gerekmez. Havuz, dışarıya iki işlem sunar: bir sonraki uç noktayı ver ve bir isteğin sonucunu bildir. Kodunuzun geri kalanı yalnız bu iki işlemi çağırır; seçim mantığı tek yerde yaşar.

Sonuç bildirimi, havuzun bütün kararlarını besleyen tek girdidir. İstek başarılıysa havuz, o uç noktanın geçmişine başarı yazar. Başarısızsa hatanın türü önemlidir: proxy katmanı hatası (bağlantı reddi, 407, tünel kurulamadı, zaman aşımı) uç noktaya yazılır; hedef katmanı hatası (404, 500, beklenen alanın gelmemesi) ise uç noktanın suçu değildir ve geçmişe yazılmaz. 403 ve 429 ortada kalır: tek bir uç noktada yoğunlaşıyorsa o çıkış tanınmıştır, bütün uç noktalarda aynı anda görülüyorsa hedef genel bir sınır koymuştur ve havuzla ilgisi yoktur. Bu ayrımı baştan koymazsanız, hedefin bir günlük bakımı bütün havuzunuzu cooldown’a sokar.

Sonuç geçmişini sabit boyutlu bir pencere (son on ya da yirmi istek) olarak tutmak, hem belleği sabit tutar hem de eski hataların uç noktayı sonsuza kadar cezalandırmasını önler. Pencerede başarısızlık oranı belirlediğiniz eşiği (örneğin on istekte beş) aştığında uç nokta cooldown’a girer. Tek bir hata hiçbir zaman cooldown sebebi olmamalıdır; rotating çıkışlarda tek bir isteğin başarısız olması olağandır.

Round-robin, uç noktaları sırayla dolaşır: birinci, ikinci, üçüncü, sonra tekrar birinci. Uç noktalar birbirine denkse ve istekler birbirine benziyorsa en iyi seçimdir, çünkü tahmin edilebilir ve ölçmesi kolaydır. Yüz istek gönderdiğinizde her uç noktaya yirmi istek düşer; bir uç noktanın payı eksikse o uç nokta cooldown’da geçirmiş demektir ve bu sayının kendisi bir teşhis aracıdır. Cooldown’daki uç noktalar sıradan atlanır; sıra dönerken aktif olanlar arasında devam eder.

Ağırlıklı seçim, uç noktalara farklı pay verir. Beş IPv6 portunun yanında bir de GB bazlı residential gateway’iniz varsa, residential kanalın her GB’si daha pahalıdır; ona yalnız IPv6 ile başarısız olan hedefleri ya da toplam isteklerin küçük bir payını vermek maliyeti kontrol altında tutar. Ağırlık, sonuç geçmişiyle de bağlanabilir: son pencerede başarı oranı yüksek olan uç noktanın ağırlığı artar, düşen azalır. Bu, cooldown’a girmeden önce bir ara kademe sağlar; uç nokta tamamen devre dışı kalmaz, yalnız daha az iş alır.

En az yüklü seçim, o anda en az açık isteği olan uç noktayı seçer. Eşzamanlı çalışan bir sistemde round-robin’in gözden kaçırdığı bir sorunu çözer: yavaş bir uç nokta, sırası geldiğinde istek almaya devam eder ve açık istek sayısı birikir. En az yüklü seçim yavaş uç noktaya doğal olarak daha az iş verir. Bedeli, her uç nokta için açık istek sayacını tutmak ve istek bitince düşürmektir; sayaç bir yerde düşürülmezse uç nokta kalıcı olarak yüklü görünür ve hiç seçilmez.

Hangisini seçeceğiniz iş tipine bağlıdır: toplu tarama ve fiyat izlemede round-robin yeterlidir; karma ürün kullanan düzenlerde ağırlıklı seçim maliyeti yönetir; tarayıcı tabanlı ya da uzun süreli istekler yürüten sistemlerde en az yüklü seçim kuyruğun bir uç noktada birikmesini önler. Üçünü aynı anda kurmak gerekmez; round-robin ile başlayıp ölçüm bir sorun gösterdiğinde diğerine geçmek yeterlidir.

Cooldown, hata eşiğini aşan uç noktayı belirli bir süre seçimden çıkarmaktır. Sürenin bir doğru değeri yoktur, ama bir yapısı vardır: ilk cooldown kısa olur (örneğin otuz saniye), aynı uç nokta cooldown’dan çıkar çıkmaz yeniden eşiği aşarsa süre katlanır (bir dakika, iki dakika, dört dakika) ve bir üst sınırda durur (örneğin on beş dakika). Bu, retry rehberindeki üstel bekleme mantığının uç nokta ölçeğine taşınmış halidir. Üst sınır gerekir, çünkü hedefin geçici bir engeli uç noktayı saatlerce kullanılmaz bırakmamalıdır.

Cooldown’dan dönüş iki biçimde olur. Süre dolunca uç nokta doğrudan aktif listeye alınır ve ilk isteklerde yeniden sınanır; basit ama geri dönen uç nokta hâlâ bozuksa birkaç gerçek isteği harcar. İkinci biçim yarı açık dönüştür: süre dolunca uç nokta tek bir deneme isteği alır, başarılıysa aktif olur, başarısızsa katlanmış süreyle cooldown’a geri döner. Üretim trafiğini korumak istiyorsanız ikincisi tercih edilir; bu da retry rehberinde anlatılan devre kesicinin uç nokta ölçeğindeki karşılığıdır.

Cooldown’un bir de bütün havuzu kapsayan hali vardır. Aktif uç nokta sayısı belirli bir tabanın altına düşerse (örneğin beş porttan üçü cooldown’daysa) sorun büyük olasılıkla hedefte ya da sizin isteklerinizdedir. Bu durumda havuz kalan iki portu da tüketmek yerine bütün işi kısa bir süre durdurmalı ve bir uyarı üretmelidir. Üç porta yüklenen trafik hem o portların oturum düzenini bozar hem de hedefte daha sık tanınmaya yol açar.

Pasif sağlık kontrolü, gerçek isteklerin sonuçlarından beslenir: yukarıdaki sonuç geçmişi tam olarak budur. Ek trafik üretmez, ek kota harcamaz ve uç noktanın gerçek hedefte nasıl davrandığını ölçer. Çoğu iş için yeterlidir. Eksik yanı, cooldown’daki bir uç noktanın iyileşip iyileşmediğini ancak gerçek bir istek verildiğinde anlamasıdır.

Aktif sağlık kontrolü, belirli aralıklarla her uç noktadan bilinen bir adrese (istemci IP’sini düz metin döndüren bir uç nokta gibi) küçük bir istek gönderir. Üç şeyi ölçer: proxy’ye bağlanılıyor mu, tünel kuruluyor mu, dönen adres beklenen türde mi. IPv6 portlarında dönen adresin IPv6 olduğunu, sticky kanallarda adresin önceki kontrolle aynı kaldığını, rotating kanallarda değiştiğini doğrulamak da bu isteğin içine sığar. Bedeli, GB bazlı ürünlerde kotadan düşmesidir: dakikada bir kontrol, beş kanal, bir kilobaytlık yanıt varsayımıyla ayda yaklaşık 200 MB eder; bu küçük bir rakamdır ama kontrol sıklığını saniyeye indirirseniz anlamlı hale gelir. Port bazlı IPv6 ürünlerde GB kotası olmadığı için bu bedel yoktur.

İki yaklaşımı birleştirmek en sağlıklı sonucu verir: pasif kontrol asıl karar vericidir, aktif kontrol yalnız cooldown’daki uç noktaların geri dönüşünü sınamak için kullanılır. Böylece aktif kontrol yalnız gerektiğinde çalışır ve üretim trafiği bozuk uç noktaya hiç gitmez. Aktif kontrolün hedefi gerçek hedef site olmamalıdır; tanıma riski taşır ve hedefin kendi sınırını boşa tüketir.

Havuz yönetimi ile gateway birbirinin alternatifi değildir; çoğu üretim düzeninde ikisi iç içedir. En yaygın kurgu, havuzun her elemanının bir gateway kanalı olmasıdır. GB bazlı rotating IPv4 ürünlerinde aynı gateway’e farklı oturum kimlikleriyle açılan on sticky kanal, on elemanlı bir havuz verir: her kanal kendi çıkış adresini oturum süresi boyunca korur, biri tanındığında yalnız o kanal cooldown’a girer ve yeni bir oturum kimliğiyle yeniden açıldığında yeni bir adres alır. Burada cooldown’dan dönüş için oturum kimliği değiştirilir; havuz elemanı aynı kalır, arkasındaki adres yenilenir.

İkinci kurgu kademeli havuzdur: ucuz ve hızlı kanallar (IPv6 portları ya da datacenter gateway) birinci kademede, residential gateway ikinci kademede durur. Her istek önce birinci kademeden çıkar; yalnız 403, captcha ya da boş yanıt gibi tanınma belirtileriyle başarısız olan istekler ikinci kademeye devredilir. Devir kuralı retry rehberindeki “hangi hata yeniden denenir” tablosuyla aynıdır; fark, yeniden denemenin aynı havuzda değil üst kademede yapılmasıdır. Bu düzen GB tüketimini düşürür, çünkü pahalı kanal yalnız gerçekten gereken isteklere harcanır.

Üçüncü kurgu, aynı işi birden fazla süreçte çalıştırmaktır. Havuz nesnesi süreç içinde yaşadığı için iki süreç aynı sticky kanalı aynı anda kullanabilir ve biri diğerinin oturumunu bozabilir. En basit çözüm, kanalları süreçlere baştan bölmektir: on kanal, iki süreç, her sürece beş kanal. Süreçler arası paylaşılan havuz (ortak bir kilit ya da kuyruk üzerinden) daha karmaşıktır ve ancak süreç sayısı sık değişiyorsa gerekir.

Havuzun çalışıp çalışmadığını beş sayı gösterir; bunlar düzenli ölçülmelidir. Birincisi uç nokta başına istek payıdır: round-robin’de paylar eşit olmalı, ağırlıklı seçimde ağırlıklara yakın olmalıdır. İkincisi cooldown’a giriş sayısı ve toplam cooldown süresidir; bir uç nokta diğerlerinden belirgin biçimde fazla cooldown yaşıyorsa o kanal ya hedefte tanınmıştır ya da ayarı yanlıştır. Üçüncüsü, aktif uç nokta sayısının zaman içindeki en düşük değeridir; tabana yaklaşıyorsa havuz dardır.

Dördüncüsü, üst kademeye devredilen isteklerin oranıdır: kademeli düzende bu oran GB maliyetinin ana belirleyicisidir ve yükselmesi birinci kademenin hedefte tanınmaya başladığını gösterir. Beşincisi, cooldown’dan dönen uç noktanın ilk on isteğindeki başarı oranıdır; düşükse cooldown süresi kısa ya da yarı açık dönüş eksiktir. Bu beş sayı tek bir günlük satırına sığar ve havuzla ilgili kararların çoğunu (süre, eşik, ağırlık) tahmin yerine ölçümle vermenizi sağlar.

Havuzun hiç ihtiyaç duyulmadığı bir durum da vardır: tek bir rotating gateway, istek başına rotasyon, tek süreç. Bu düzende havuz nesnesi tek elemanlıdır ve yukarıdaki yapı fazladan karmaşıklıktır. Havuzu, ikinci bir uç nokta eklendiği gün kurmak doğru zamandır; birinci günden kurulan havuz çoğu zaman hiç kullanılmayan kod olarak kalır.

Round-robin ile rastgele seçim arasında fark var mı? Küçük havuzlarda vardır: rastgele seçim kısa pencerede aynı uç noktayı art arda seçebilir ve bu, sticky kanallarda aynı çıkışın üst üste istek almasına yol açar. Round-robin bunu yapısal olarak önler. Havuz büyüdükçe (onlarca uç nokta) fark kaybolur.

Cooldown süresi için hangi değerle başlamalıyım? Otuz saniye ile başlayıp katlamak, çoğu hedef için makul bir başlangıçtır. Değeri doğrulamanın yolu, cooldown’dan dönen uç noktanın ilk isteklerindeki başarı oranıdır; düşükse süreyi uzatın. Hedefin sınır penceresi biliniyorsa (429 yanıtındaki Retry-After gibi) başlangıç değeri o pencereye eşitlenir.

Sağlık kontrolü hangi adrese gitmeli? Sizin kontrolünüzdeki ya da yalnız istemci IP’sini döndüren bir uç noktaya; hedef siteye gitmemeli. Kontrol isteği hedefin sınırını tüketmemeli ve hedefte tanınma riski yaratmamalıdır.

Havuz kütüphanesi mi, kendi kodum mu? Yukarıdaki yapı yüz satırın altında yazılır ve iş akışınıza tam oturur. Hazır kütüphaneler genellikle seçim ve yeniden denemeyi birlikte sunar; kullanacaksanız hata sınıflandırmasının (proxy hatası ile hedef hatası ayrımı) yapılandırılabilir olduğundan emin olun, aksi halde hedefin bir 500’ü uç noktalarınızı cooldown’a sokar.

IPv6 portlarını havuza almak için ne gerekir? Her port ayrı bir uç nokta olarak eklenir; port başına rotasyon ayarı paneldeki düzende kalır. Aktif sağlık kontrolünde dönen adresin IPv6 olduğunu doğrulamak, bir portun yanlışlıkla IPv4’e düşüp düşmediğini erken gösterir.