Scraping API mi Datacenter Proxy mi? Karar Rehberi

İki ürün aynı rafta durmaz: ne satın alıyorsunuz?

Datacenter proxy ağ katmanında durur. Panelden aldığınız adres, port ve kimlik bilgisini kendi istemcinize yazarsınız; istek sizin sunucunuzdan çıkar, proxy üzerinden hedefe gider, yanıt aynı yoldan size döner. Hangi hedefe kaç eşzamanlı bağlantı açılacağı, hangi hatada kaç kez yeniden deneneceği, sayfanın tarayıcıyla mı düz istemciyle mi alınacağı ve yanıtın nasıl ayrıştırılacağı sizin kodunuzdadır. DatacenterProxy kataloğunda bu katmanın dört ürünü var: static IPv4 (adet bazlı, 30 günlük dönem), rotating IPv4 (GB bazlı), static IPv6 ve rotating IPv6 (port bazlı).

Scraping API uygulama katmanında durur. Bir uç noktaya hedef adresi ve birkaç parametre gönderirsiniz: ülke, JavaScript çalıştırılsın mı, hangi alanlar istenir. Satıcı isteği kendi altyapısından geçirir, gerekirse tarayıcı açar, başarısız olursa kendi yöntemleriyle yeniden dener ve size tek bir yanıt döndürür. Proxy, kuyruk ve tarayıcı artık sizin değildir; bunların maliyeti de görünürlüğü de tek bir istek fiyatının içine gömülüdür.

Aradaki fark kontrol ile sorumluluğun yer değiştirmesidir. Proxy ile her bileşeni siz ayarlarsınız ve her bileşenin bakımı sizdedir; API ile çoğu şey hazır gelir, karşılığında satıcının sınırları, kuyruğu, bölge seçenekleri ve fiyat tablosu sizin sınırınız olur. İkisi de meşru seçenektir; hedef sitelerin kurallarına uymak ve toplanan veriyi hukuka uygun işlemek iki yolda da sizin sorumluluğunuzdadır, hangi katmanı satın aldığınız bunu değiştirmez.

Birim fiyat: GB ve adet karşısında başarılı istek

Proxy tarafında birim bellidir. Rotating IPv4 datacenter GB ile satılır: kataloğa göre 10 GB 6 USD, 20 GB 12 USD, 50 GB 30 USD, 100 GB 60 USD; süre sınırı yoktur, kota bitene kadar kullanılır. Static IPv4 datacenter adet ile satılır: 100 adres 15 USD, 250 adres 25 USD, 500 adres 45 USD, 1.000 adres 80 USD, dönem 30 gün. IPv6 ürünleri port bazlıdır ve kota saymaz. Bu birimlerin hiçbiri “sayfa” değildir; GB’yi sayfaya çevirmek için ortalama yanıt boyutunu, adedi sayfaya çevirmek için adres başına günlük istek düzeninizi bilmeniz gerekir.

API tarafında birim genellikle istek ya da kredidir ve aynı istek farklı katsayılarla sayılabilir: JavaScript çalıştırılan istek, belirli ülkeden gelen istek ya da ayrıştırılmış çıktı isteyen istek daha fazla kredi yakar. Satıcıya göre değişen bu katsayılar yüzünden iki API’yi bile birbiriyle doğrudan karşılaştırmak zordur; proxy ile karşılaştırmak için ortak bir birime inmek gerekir.

Ortak birim kullanılabilir sonuç başına maliyettir: bir ayda ödediğiniz toplam tutarı, o ay doğrulamadan geçmiş kayıt sayısına bölün. Proxy tarafında pay, GB ya da adet paketinin bedeli artı kendi sunucu ve geliştirme saatinizdir; payda, başarısız ve boş yanıtlar düşüldükten sonra kalan kayıtlardır. API tarafında pay, kredi harcaması artı entegrasyon saatidir; payda yine doğrulanmış kayıttır. Bu birim, “API pahalı” ya da “proxy ucuz” gibi genel yargıları kendi hedefinizde ölçülmüş tek bir sayıya çevirir. Maliyet hesaplama rehberindeki altı satır proxy tarafının payını çıkarmak için yeterlidir.

Dört karar ekseni: hacim, hedef türü, ekip, kontrol

Hacim. Aylık birkaç bin sayfalık bir işte proxy için yazılacak kuyruk, havuz ve yeniden deneme kodu, işin kendisinden pahalıya gelir; API’nin istek başına fiyatı bu ölçekte önemsizdir. Hacim yüz binlere çıktığında denklem döner: bir kez yazılan kod ve sunucu maliyeti sayfa başına küçülür, proxy birim fiyatı sabit kalır ya da düşer (rotating IPv4 datacenter’da GB fiyatı kademeler arasında sabittir, 10 GB ve 100 GB için 0,60 USD/GB; static IPv4’te adres fiyatı kademe yükseldikçe düşer, 100 adreste 0,15 USD, 1.000 adreste 0,08 USD/adres), API’nin istek başına fiyatı ise çoğu zaman doğrusal kalır. Kırılma noktası satıcıya ve hedefe göre değişir, bu yüzden yazılmaz; kendi iki pilotunuzun sonucudur.

Hedef türü. Sayfa düz HTML ile geliyorsa ya da verisini herkese açık bir JSON uç noktasından alıyorsa proxy ile düz istemci yeter, maliyet yalnız GB’dir. Sayfa JavaScript ile dolan bir iskeletse tarayıcı gerekir; tarayıcıyı proxy ile siz çalıştırırsınız (CPU, RAM ve sayfa başına birkaç MB trafik sizin), API’de ise satıcı çalıştırır ve bunu kredi katsayısına yansıtır. JavaScript ağırlıklı hedeflerin payı yükseldikçe API’nin görece avantajı artar; düz HTML ağırlıklı listelerde proxy belirgin biçimde ucuzdur.

Ekip. Proxy yolunda bir geliştiricinin istemciyi, havuzu, zaman aşımı ve yeniden deneme düzenini kurması, sonra bakımını yapması gerekir; thread sayısı ve zaman aşımı rehberleri bu işin iki parçasıdır. API yolunda entegrasyon bir uç noktaya istek atmaktan ibarettir, ama hedef değiştiğinde ya da satıcı parametre değiştirdiğinde bağımlılık sizin dışınızdadır. Ekipte bu işi sahiplenecek kimse yoksa API, varsa proxy daha öngörülebilir sonuç verir.

Kontrol. Proxy ile istek başlıkları, çerezler, hız, bölge ve istemci kimliği tamamen sizdedir; sorun çıktığında her bileşene bakabilirsiniz. API ile hedef adresleriniz ve isteğin içeriği satıcıya görünür, bu da iş gizliliği ve veri işleme sözleşmesi açısından ayrı bir soru doğurur; satıcının bölge listesi ve eşzamanlılık sınırı planınıza bağlıdır. Hangi hedeflerin izlendiğinin rakibe ya da üçüncü tarafa görünmemesi gereken işlerde kontrol ekseni tek başına kararı belirleyebilir.

Gecikme ve sınır: tek istek nereden geçer?

Proxy ile istek iki bacaktan geçer: istemciniz ile proxy arası ve proxy ile hedef arası. Gecikme rehberinde anlatıldığı gibi iki bacağın toplamı ve hedefin yanıt süresi p95’inizi belirler; eşzamanlılığı siz seçtiğiniz için kuyruk gecikmesi de sizin kontrolünüzdedir. API ile araya üçüncü bir bacak girer: istemciniz ile API arası, API ile kendi proxy’si arası, oradan hedefe. Tarayıcı çalıştırılan isteklerde buna sayfanın yüklenme süresi eklenir; tek isteğin süresi saniyelerle ölçülür ve bu süre sizin ayarınız değildir.

Sınırlar da farklı yerdedir. Proxy tarafında sınırı hedefin hız kuralı ve sizin sunucunuzun kapasitesi koyar; GB kotası bitince istek geçmez, adet paketinde adres sayısı sabittir. API tarafında plan başına eşzamanlı istek sınırı ve aylık kredi tavanı vardır; kampanya döneminde hacmi ikiye katlamak plan değişikliği gerektirebilir. Zaman duyarlı işlerde, örneğin fiyatın belirli saatte ölçülmesi gereken takiplerde, bu sınırların nerede durduğu maliyetten önce gelir.

Karma düzen: üç kurgu

Birinci kurgu, hedefe göre bölmek: düz HTML ile gelen hedefler proxy üzerinden kendi istemcinizle, JavaScript ile dolan birkaç hedef API üzerinden. Hedef listesindeki her satıra “yol” sütunu eklenir ve kuyruk isteği ona göre yönlendirir. Bu kurgu toplam maliyeti düşürürken tarayıcı altyapısı kurmaktan kurtarır.

İkinci kurgu, proxy ana yol, API yedek: istek önce proxy ile gider, doğrulamadan geçemeyen sayfalar ikinci bir kuyruğa düşer ve oradan API ile yeniden denenir. API harcaması yalnız sorunlu sayfalara gider; sorunlu sayfa oranı yükselirse bu, hedefin değiştiğinin erken işaretidir ve önce kendi istemcinizi gözden geçirirsiniz.

Üçüncü kurgu, zamanla geçiş: proje API ile başlar, hedefler ve hacim netleşince ağır hedefler proxy tarafına taşınır. Bu kurgunun şartı, kodun en başta bir “getir” arayüzü etrafında yazılmasıdır: hedef adresi alan, ham gövde döndüren tek bir fonksiyon. Arayüz sabit kaldığında arkasındaki yolu API’den proxy’ye ya da tersine çevirmek kuyruğu ve ayrıştırıcıyı etkilemez. Kendi proxy sunucunuzu kurma seçeneği de aynı arayüzün arkasına girer; o kararın hesabı ayrı rehberde yapılır.

Örnek hesap: ayda 300.000 ürün sayfası

Varsayımlar açıkça yazılsın: ayda 300.000 ürün sayfası, sayfa başına ortalama 120 KB düz HTML, hedeflerin yüzde 85’i düz istemciyle alınabiliyor, yüzde 15’i tarayıcı istiyor. Proxy yolunda düz kısım 255.000 × 120 KB, yaklaşık 30,6 GB; kataloğa göre 50 GB rotating IPv4 datacenter paketi 30 USD bu trafiği karşılar ve artan kota sonraki aya kalır. Tarayıcı isteyen 45.000 sayfa için ya kendi headless altyapınızı kurarsınız (sayfa başına birkaç MB trafik ve kendi sunucu maliyeti; hesap maliyet rehberindeki yöntemle çıkarılır) ya da bu dilimi API’ye verirsiniz.

API yolunda hesap satıcının kredi tablosuna bağlıdır: 300.000 isteğin yüzde 15’i tarayıcı katsayısıyla sayılır, kalan düz katsayıyla; bu rakamı kendi aldığınız teklife göre doldurun ve yanına entegrasyon saatini yazın. Sonra her iki yolun toplamını aynı ayda doğrulamadan geçen kayıt sayısına bölün. Bu örnekte düz dilim için proxy daha düşük maliyetlidir; tarayıcı dilimi için karar, kendi headless maliyetinizle API katsayısının karşılaştırmasına kalır. Çoğu ekipte sonuç birinci karma kurgu olur.

Static alternatifi de hesaba girer. Aynı hedeflerde sabit adres gerekiyorsa, örneğin izin listesine yazılacak ya da uzun oturum gerektiren bir düzen varsa, 100 adres 15 USD paketi 30 gün boyunca kullanılır ve trafik sayılmaz; adres başına günlük istek düzeni hedefin toleransına göre kurulur. Bu durumda pay GB yerine adet bedelidir ve kullanılabilir sonuç başına maliyet formülü aynen çalışır.

Beş soruluk karar listesi

Birinci soru: aylık hacim kaç sayfa ve önümüzdeki altı ayda ne yöne gidiyor? Birkaç bin ve sabitse API, yüz binler ve artıyorsa proxy ağır basar. İkinci soru: hedeflerin yüzde kaçı tarayıcı istiyor? Yüzde onun altındaysa proxy ile düz istemci, yarıdan fazlaysa API ya da kendi headless altyapınız. Üçüncü soru: ekipte istemci, havuz ve yeniden deneme düzenini kurup bakacak biri var mı? Yoksa API ile başlayıp üçüncü kurguyu uygulayın.

Dördüncü soru: hedef listesi ve istek içeriği üçüncü tarafa görünebilir mi? Görünemiyorsa proxy. Beşinci soru: iki pilot yaptınız mı? Aynı bin sayfayı bir hafta boyunca iki yoldan da çekip aynı doğrulama kuralıyla kullanılabilir kayıt başına maliyeti ölçmeden verilen karar, satıcı broşürüne verilen karardır. Pilot için 10 GB rotating paketi ve API’nin deneme planı yeterlidir; iki sayıyı yan yana koyduğunuzda karar çoğu zaman kendiliğinden görünür.