Bir toplama görevi on hedefte sorunsuz çalışıp binlerce hedefte güvenilirliğini kaybedebilir. Hata sınıflandırma ve tekilleştirme, hız sınırlama ve eşzamanlılık, kaldığı yerden devam, çıkış arızaları, tutarlılık kontrolleri ve birkaç temel izleme metriği büyük ölçekte kritik hale gelir.
Bir veri toplama betiği on hedefte sorunsuz çalışırken binlerce hedefe çıkarıldığında başarı oranı düşmeye başlayabilir. Yeniden deneme eklersiniz, proxy değiştirirsiniz, eşzamanlılığı ayarlarsınız; yine de aynı sorunlar tekrar eder. Daha derine bakıldığında darboğaz çoğu zaman ayrıştırma mantığında değil, kurulmamış birkaç mühendislik katmanındadır. Küçük ölçekte bu sorunlar hiç görünmeyebilir.
Yeniden denemenin anlamlı olması için önce hataları sınıflandırın
Veri toplamada hatalar kaçınılmazdır. Önemli olan bunları sınıflandırmaktır: ağ dalgalanmaları ve bağlantı sıfırlamaları hemen yeniden denenebilir; geçici hız sınırlamasında backoff sonrasında yeniden deneme yapılmalıdır; sayfa yapısı değiştiği için ayrıştırma sonucu boş dönüyorsa on bin kez denemek de işe yaramaz, durum kaydedilmeli ve alarm üretilmelidir; hedef zaten yoksa görev tamamlandı olarak işaretlenebilir; ortam veya ağ çıkışı başlatılamıyorsa başka birine geçilip yeniden denenmelidir.
Her şeyi ayrım yapmadan yeniden denemek en yaygın hatalardan biridir. İnsan müdahalesi gerektiren sorunları döngüler içinde gizlerken kota ve çıkış kaynaklarını da boşa harcar. Backoff da gereklidir: yeniden deneme aralıkları giderek artmalıdır; aksi halde bir görev grubu aynı zaman penceresinde topluca geri döner ve hız sınırlamasını daha da ağırlaştırır.
Yeniden denemeler doğrudan tekilleştirme ihtiyacını doğurur. Bir görev retries nedeniyle birden fazla kez çalıştırılabilir; bu yüzden her görevin, örneğin URL normalizasyonundan sonraki değer gibi, kararlı ve benzersiz bir kimliği olmalı ve veritabanı yazımları bu kimliğe göre idempotent yapılmalıdır. Aksi halde daha fazla yeniden deneme daha fazla kirli veri üretir.
Hız sınırlama ve eşzamanlılık farklı şeylerdir
Eşzamanlılığı artırmak throughput'un da artacağını garanti etmez. Aynı anda üç kısıt devrededir: hedef sitenin hız sınırlaması uygulamadan önce ne kadar yük kaldırabildiği, yerel makinenin bellek ve CPU kapasitesi ve tek bir ortamın ya da oturumun birden fazla görevi aynı anda çalıştırıp çalıştıramadığı.
Daha kararlı yöntem düşük eşzamanlılıkla başlayıp yükü kademeli olarak artırmak, başarı oranı ile yanıt süresini birlikte izleyerek belirgin bozulmanın başladığı kırılma noktasını bulmaktır. Hız sınırlama ayrı bir konudur: aynı hedefe erişim temposunu kontrol eder ve global eşzamanlılıkla aynı şey değildir. Bir görev grubu birden fazla siteye dağılıyorsa her sitenin temposu ayrı belirlenmelidir.
Kaldığı yerden devam etmek kalıcı duruma bağlıdır
Saatler süren bir görevin kesilmesi normaldir; baştan başlamak çoğu zaman kabul edilemeyecek kadar maliyetlidir. Bunun için durum kalıcı olarak saklanmalıdır: bekleyen, çalışıyor, tamamlandı; ayrıca yeniden deneme sayısı, bir sonraki çalıştırılabilir zaman ve hata türü. Süreç başladığında kuyruk bellekten yeniden oluşturulmak yerine depolamadan geri yüklenmelidir.
Kuyruğu yalnızca bellekte tutmak, çalışıyormuş gibi görünen en yaygın yaklaşımlardan biridir. Süreç çöktüğünde bekleyen bütün görevler kaybolur ve sayılar artık birbirini tutmaz.
Proxy ve ağ çıkışı arızalarını ayrı ele alın
Bir çıkışın hedef tarafından engellenmesi, proxy'nin çevrimdışı olması veya bölgesel düğümlerin kararsızlaşması büyük ölçekte sürekli yaşanır. Bunlar istisna değil, normal çalışma koşullarıdır. Çıkışları değiştirilebilir kaynaklar olarak ele alın: bir görev başarısız olduğunda önce hedefin hız sınırlaması mı uyguladığını yoksa çıkışın mı kullanılamaz olduğunu belirleyin; ilk durumda backoff uygulayın, ikinci durumda çıkışı değiştirip yeniden deneyin. Her çıkışın hata oranını da kaydedin ve belirgin biçimde kötüleşen grupları devreden çıkarın.
Tersine, tüm görevler tek bir çıkışı paylaşıyorsa bir görev bağlantıyı bozup arkasındaki her şeyi etkileyebilir. Sorunu incelemek için de loglardan geriye doğru giderek hangi görevin tetiklediğini bulmak gerekir.
Veri tutarlılığı kontrolü
Bir çalışmanın tamamlanması verinin doğru olduğu anlamına gelmez. Veritabanına yazdıktan sonra birkaç soruyu yanıtlayabilmelisiniz: tamamlanan görev sayısı kaydedilen satır sayısıyla uyuşuyor mu, ayrıştırma sonuçlarının ne kadarı boş, kritik alanların eksik olma oranında anormal artış var mı ve kaç yinelenen satır bulunuyor?
Bu kontrollerin karmaşık olması gerekmez. Parti bazında örnekleme yeterlidir, ancak sonuçları birinin incelemesi gerekir. Ölçek büyüdükçe hatalı veri, hiç veri olmamasından daha sorunlu hale gelebilir.
Hangi metrikleri izlemeli
Çok fazla metriğe gerek yoktur. Sistem sağlığını gösteren birkaç tanesi yeterlidir.
- Başarı oranı ve hata türlerinin dağılımı; hangi hata sınıfının arttığını görmek için
- Görev kuyruğu uzunluğu ve ortalama bekleme süresi; sürekli büyüyen birikme giriş ve işleme kapasitesinin uyuşmadığını gösterir
- Aktif ortam ve ilgili süreç sayısı; uzun süre tek yönde artış genellikle kaynak temizlemede sızıntıya işaret eder
- Birim zamandaki çıktı miktarı; throughput'un hız sınırlaması yüzünden bastırılıp bastırılmadığını anlamak için
- Çıkış hata oranı; bir düğüm grubunun değiştirilip değiştirilmeyeceğine karar vermek için
Bu metriklerden biri uzun süre tek yönde değişmeye devam ediyorsa önce kaynak temizleme ve yeniden deneme mantığını kontrol edin.
Ortam katmanını bağımsızlaştırın
Bütün bu noktalar birlikte düşünüldüğünde aynı sonuca varılır: ortam katmanı betiklerden bağımsız yönetilmelidir. Ortam havuzlama, ortamların farklı betiklere dağılması yerine merkezi olarak planlanabilmesini gerektirir; kaynak temizleme, betiklerin kendi kendini kurtarmasına güvenmek yerine sorgulanabilir durum gerektirir; başka bir ortam veya çıkışla yeniden deneme ancak ortamlar bağımsız planlanabiliyorsa mümkündür.
Betikler mantığı yönetir, ortam katmanı ise kaynakları ve kimliği yönetir. PurpleMark bu tür bir mimaride tam olarak bu katmanı üstlenir; toplu oluşturulabilen, bağımsız ağ çıkışlarına bağlanabilen ve durumu sorgulanabilen ortam kaynakları sunar.
Uyumluluk sınırları
Ölçekleyebilmek verilerin gelişigüzel toplanabileceği anlamına gelmez. Hedef sitenin robots kurallarına ve hizmet şartlarına uyun, kişisel bilgi toplamayın, teknik koruma önlemlerini aşmayın ve istek sıklığını karşı tarafın normal hizmetini etkilemeyecek şekilde kontrol edin. Kararlılık teknik bir konudur; veriyi toplamaya izin olup olmadığı başka bir konudur. İkisinin de şartları karşılanmalıdır.
