Flickr için Proxy: Katmanlar, API Kotası ve Paylaşımlı Kullanım

Betik ortamında kapsam: ortam değişkenleri ve istisnalar

Tarayıcıda proxy bir ayar ekranından verilir; betikte kapsamı baştan siz kurarsınız. En yaygın yol ortam değişkenleridir: HTTP_PROXY ve HTTPS_PROXY giden istekleri yönlendirir, NO_PROXY ise belirli adresleri kuralın dışında bırakır. Adların büyük-küçük harf duyarlılığı araca göre değişir; bir araç yalnızca küçük harfli biçimi okurken bir diğeri ikisini de kabul eder.

Şema ayrımı ikinci ayrıntıdır ve en sık buradan hata alınır. Flickr istekleri HTTPS üzerinden gittiğinden belirleyici olan HTTPS_PROXY değeridir; yalnızca HTTP_PROXY tanımlanmış bir ortamda çağrılar proxy’yi hiç görmeden doğrudan çıkar. Süreç hata vermediği için bu durum sessizce ilerler: iş tamamlanır, ancak hiçbir istek beklediğiniz çıkıştan gitmemiştir.

Üçüncü parça istisna listesidir. İç ağ adreslerini ve yerel servis adlarını NO_PROXY kapsamına almazsanız kendi veritabanınıza ya da önbellek sunucunuza giden bağlantı da dış çıkışa yönlenir; sonuç, kaynağı kolay anlaşılmayan zaman aşımlarıdır. Ters yönde de risk vardır: fazla geniş bir örüntü yazmak, asıl yönlendirmek istediğiniz isteklerin listeye takılıp doğrudan gitmesine yol açar.

Sistem düzeyindeki karşılıklar için Ubuntu ve Linux proxy ayarları yazısı, değişkenlerin kalıcı biçimde nereye yazılacağını adım adım gösteriyor. Windows tarafında aynı işi ya sistem genelindeki ağ ayarı ya da süreç başına tanımlanan değişkenler üstlenir; tarayıcı profilleri ise bu değişkenleri hiç okumaz, kendi yapılandırmalarına bakar. Betikle tarayıcıyı aynı makinede çalıştırırken bu ayrımı unutmak, ikisinin farklı çıkışlardan gittiğini geç fark etmenize yol açar.

Arşiv yöneten ekiplerde rol ve erişim ayrımı

Kurumsal bir arşivi birden fazla kişi yönetiyorsa, herkesin aynı erişim bilgisiyle çalışması kısa vadede pratik, uzun vadede sorunludur. Bir sorun çıktığında hangi oturumun sebep olduğunu ayırt edemezsiniz ve ekipten ayrılan bir kişi için tüm erişimi yenilemek gerekir.

Rol bazlı bir ayrım daha sürdürülebilirdir. Aşağıdaki tablo yaygın rolleri ve ihtiyaç duydukları erişimi özetliyor.

Ayrımın ikinci faydası ölçüm tarafındadır. Her rol kendi giriş noktasını kullandığında, hacim ve hata sayıları da rol bazında okunabilir hâle gelir. Bir ayın faturası beklenenden yüksek çıktığında, bunun editör yüklemelerinden mi yoksa geliştirici tarafındaki bir döngüden mi geldiğini tahmin etmek zorunda kalmazsınız.

Kimlik doğrulama yöntemi seçimi bu ayrımın teknik karşılığıdır; seçenekler proxy kimlik doğrulama yöntemleri yazısında karşılaştırılıyor. Sabit oturum davranışı için rotating proxy ile statik çıkış arasındaki farkı bilmek gerekir: arşiv yönetimi rotasyon istemez, sabitlik ister.

Kurumsal ağdan erişim: izin listeleri ve süreklilik

Kurumsal ortamda proxy talebi çoğu zaman gizlilikten değil yönetimden doğar. Şirket ağından çıkan trafiğin bilinen tek bir adresten görünmesi istenir; bu hem denetim kayıtlarını okunur kılar hem de karşı tarafta referans alınabilecek sabit bir kimlik yaratır. Arşiv işlerinde bu kimlik, bir koleksiyona kimin hangi kapsamda dokunduğunu sonradan izlenebilir kılar.

İzin listeleri bu ihtiyacın en somut hâlidir. Bir iş ortağının sistemine ya da kendi iç servisinize dışarıdan erişiyorsanız, adresi değişmeyen bir çıkış karşı taraftaki kural yönetimini basitleştirir. Rotasyonlu bir havuz burada tam ters etki yapar: her yeni adres listenin dışında kalır ve erişim, öngörülemeyen anlarda kesilir.

Erişim yönteminin seçimi ekibin nerede çalıştığına bağlıdır. IP yetkilendirme ofis içinde pratiktir, çünkü tanımlanacak tek bir adres vardır; evden çalışan biri içinse abonelik adresi değiştiğinde erişim düşeceğinden kullanıcı adı-parola yöntemi daha uygundur. İki yöntemi aynı hesapta ayrı giriş noktalarına bağlamak her iki grubu da rahatlatır; giriş noktalarının mimarisi gateway mimarisi yazısında anlatılıyor.

• Kullanılan çıkış adresini ve onu hangi ekibin kullandığını tek bir yerde kayıtlı tutun.
• İzin listesi verdiğiniz her karşı tarafı, adres değişikliğinden önce haberdar edin.
• Ofis içi ve uzaktan çalışan için ayrı giriş noktası tanımlayın.

Gece boyunca çalışan bir toplama işi planlıyorsanız süreklilik taahhüdünü de baştan netleştirin: çıkış kesildiğinde işin durması mı, beklemesi mi yoksa kaldığı yerden devam etmesi mi gerektiği önceden kararlaştırılmalıdır. Sağlayıcı taahhütlerinin nasıl okunacağını uptime ve SLA yazısı açıklıyor.

Statik medya adresleri ve bant genişliği muhasebesi

Flickr fotoğrafları farklı boyutlarda türetilmiş dosyalar hâlinde saklar ve bunları ana alan adından ayrı bir statik medya adresinden servis eder. Bu ayrım performans için mantıklıdır: statik içerik önbelleğe uygun, dinamik sayfa değildir.

Proxy açısından iki sonucu vardır. Birincisi kapsam: yalnızca ana adresi kapsayan bir kural, görselleri yönlendirmez. İkincisi maliyet: hacim bazlı ücretlendirilen bir çıkışta faturayı büyüten şey sayfalar değil, indirilen fotoğraflardır. Yüksek çözünürlüklü bir arşivi tararken bu fark hızla büyür; hesaplama yöntemi için bant genişliği hesaplama yazısına bakın.

Üçüncü bir sonuç günlük tarafındadır. Statik medya istekleri sayıca kalabalıktır: tek bir galeri sayfası düzinelerce görsel isteği üretebilir. Proxy günlüklerini okurken satır sayısına bakıp “çok fazla istek yapılmış” sonucuna varmak bu yüzden yanıltıcıdır; anlamlı ölçüt satır sayısı değil, taşınan hacim ve yapılan API çağrısı sayısıdır.

Boyut türevleri burada elinizdeki en güçlü kaldıraçtır. Bir küçük resim ile tam çözünürlüklü bir dosya arasındaki hacim farkı büyüktür; önizleme veya sınıflandırma amaçlı bir iş için en büyük türevi indirmek gereksiz maliyet üretir. İş akışını “önce en küçük türev, gerekiyorsa büyüğü” biçiminde kurmak çoğu projede en belirgin tasarrufu sağlar.

Meta veri okumak ile dosya indirmek arasındaki farkı baştan planlamak da aynı ölçüde etkilidir. Çoğu iş akışında önce meta veri toplanır, yalnızca gereken kayıtların görselleri indirilir; bu sıralama hem kotayı hem hacmi korur.

Kurulum ve doğrulama sırası

Kurulumda sıra, sonucun güvenilirliğini belirler. Önce kuralın nereye yazılacağına karar verilir, sonra çıkış doğrulanır, ardından sızıntı ölçülür, en son kota ve hata davranışı izlenir.

Tarayıcı tarafında DNS leak testi ve WebRTC leak testi birlikte çalıştırılmalıdır; ikisi farklı katmanlara bakar. Çıkış adresinin ve ülkesinin beklediğiniz gibi olduğunu IP adresim aracıyla görebilirsiniz.

İstemci kitaplıkları

API çağrılarını bir betikten yapıyorsanız proxy ayarı genellikle ortam değişkeni veya kitaplığın kendi parametresiyle verilir. Çoğu kitaplık ortam değişkenlerini otomatik okumaz ya da yalnızca belirli şemalar için okur; bu yüzden ayarı açıkça vermek en güvenli yoldur. Ayarın gerçekten uygulandığını, betiğin gördüğü çıkış adresini bir kez yazdırarak doğrulayın. Örnek bağlantı bilgisi biçimi proxy.example.com, port 8080, kullanıcı adı username ve parola password şeklindedir; gerçek değerler panelinizde yer alır.

Doğrulama tek seferlik bir iş değildir. Çıkış türünü değiştirdiğinizde, yeni bir lokasyona geçtiğinizde veya kitaplığı güncellediğinizde aynı dört adımı tekrarlayın. En sık yaşanan sürpriz, aylardır sorunsuz çalışan bir kurulumun küçük bir güncellemeden sonra sessizce proxy’yi atlamaya başlamasıdır.

Ne zaman proxy gerçekten gerekli değildir?

Kendi arşivinizi kendi ülkenizden, tek bir hesapla yönetiyorsanız araya proxy koymanın kazandırdığı bir şey yoktur; yalnızca bir durak ve bir arıza noktası eklenir.

Proxy anlamlı hâle geldiği durumlar bellidir: kurumsal ağdan sabit ve kayıtlı bir adresle çıkmak, bir koleksiyonun farklı bölgelerde nasıl göründüğünü doğrulamak, ekip üyelerinin erişimini ayrıştırmak ve herkese açık meta veriyi düzenli aralıklarla toplamak. Bu senaryoların ortak yanı, proxy’nin bir hız aracı değil bir kimlik ve erişim aracı olarak kullanılmasıdır.

Bu senaryolarda karar iki başlıkta toplanır: kaç ayrı çıkış adresine gerçekten ihtiyaç duyulduğu ve hangi taşıma protokolünün işi karşıladığı. Arşiv yönetiminde cevap genellikle azdır ve sadedir: tek bir sabit çıkış ile HTTPS tüneli çoğu ekibin ihtiyacını karşılar. Kararı verirken tek soru yeterlidir: proxy olmadan yapamadığınız somut bir şey var mı? Cevap hayırsa, katmanı eklememek en iyi yapılandırmadır.