- 1 milyar web sayfasını 24 saat içinde taramaya dair gerçek deneyim ve modern bir web crawling sistemi tasarlama sürecinin paylaşımı
- Güncel donanım ve bulut altyapısıyla birkaç yüz dolar seviyesinde maliyetle büyük ölçekli tarama gerçekleştirildi; ana darboğazın parsing olduğu görüldü
- JavaScript çalıştırmadan yalnızca HTML parsing yapıldı, ancak buna rağmen hâlâ çok sayıda web sayfasına erişilebildi
- Redis tabanlı node cluster mimarisi tasarlanarak, domain bazlı sharding ve süreç yapısının optimizasyonuyla verimlilik en üst düzeye çıkarıldı
- Ağdan çok CPU·SSL·bellek başlıca darboğazlar olarak ortaya çıktı ve büyük domain frontier’larının yönetimi temel mesele oldu
Problemin tanımı
- 24 saat içinde 1 milyar web sayfası tarama hedefi belirlendi
- Bütçe birkaç yüz dolardı (nihai olarak yaklaşık 462 dolar) ve 2012’deki örnekle benzer bir seviyede tutuldu
- Yalnızca HTML toplandı; JavaScript çalıştırılmadı ve sadece
<a> bağlantıları çıkarıldı
- Politeness (nazik tarama) ön plandaydı: robots.txt’ye uyum, User Agent bilgisinin eklenmesi, talep edilirse domain hariç tutma, yalnızca en popüler 1 milyon domainin hedeflenmesi, aynı domainde 70 saniye bekleme gibi kurallar uygulandı
- Hata toleransı sağlandı: node arızalarında yeniden başlatma ve bir miktar veri kaybını kabul eden, örnekleme temelli bir yaklaşım benimsendi
Mimari ve tasarım
- Klasik sistem tasarımı mülakatı tarzındaki (işlev bazlı dağıtılmış) yapı yerine, her node’un tüm işlevleri (crawl durumu, parsing, fetch, depolama vb.) kendi içinde yürüttüğü bir yapı seçildi
- 12 node kullanıldı; her node
i7i.4xlarge (16 vCPU, 128GB RAM, 10Gbps, 3750GB depolama) instance’ıydı
- Her node, 1 Redis, 9 fetcher ve 6 parser sürecinden oluşuyordu
- Redis içinde domain bazlı frontier, fetch queue, ziyaret edilmiş URL’ler, Bloom filter, robots.txt ve parsing queue saklandı
- Fetcher: URL’leri domain bazında kuyruktan alıp fetch ediyor, asyncio ile 6000~7000 eşzamanlı işi yürütüyor; ana darboğaz CPU
- Parser: 80 async worker ile HTML parsing ve bağlantı çıkarma yapıyor; iş yükü büyük ölçüde CPU ağırlıklı
- Depolama: S3 yerine instance’ın yerel depolaması seçildi; büyük sayfaları saklama maliyeti düşürüldü
- Sharding: Domain’ler node’lara dağıtıldı (cross-communication yok); popüler domainlerdeki dengesizliği çözmek için shard sayısı ayarlandı
Başlıca alternatifler ve deneyler
- SQLite, PostgreSQL gibi çeşitli depolama çözümleri denendi; sonunda performans açısından Redis öne çıktı
- Dikey ölçekleme (tek büyük instance) da denendi ancak yazılım sınırları nedeniyle darboğaz oluştu; sonuçta yatay ölçekleme (birden çok node) tercih edildi
- Node’lar arası cross-communication kaldırıldı, paralel işleme her node içinde yapıldı
Tarama sürecinden çıkan başlıca dersler
Parsing en büyük darboğazdı
- Ortalama sayfa boyutu geçmişe göre (2012’de 51KB) çok büyümüştü (ortalama 242KB, medyan 138KB)
- lxml yerine selectolax (Lexbor tabanlı) kullanıldığında parsing hızı ciddi biçimde arttı
- En yüksek verim için sayfa üst boyutu 250KB ile truncation uygulanarak sınırlandı
- Sonuç olarak tek bir parser saniyede 160 sayfa parse etti; nihayetinde fetcher:parser oranı 9:6’ya ayarlanarak yaklaşık 950 sayfa/saniye işleme ulaşıldı
Fetching: kolaylaşan ve zorlaşan taraflar
- Ağ bant genişliği artık darboğaz değildi (node başına 25Gbps’in yalnızca yaklaşık 8Gbps’i kullanıldı)
- Yalnızca popüler domainler hedeflendiği için DNS de darboğaz olmadı
- Buna karşılık SSL handshake, toplam CPU kullanımının %25’ini oluşturarak en büyük darboğazlardan biri haline geldi
- Sayfaların büyük kısmı HTTPS’ye geçtiği için CPU maliyeti arttı
Gerçek crawl çalıştırması ve sorunlar
- İlk deneyler tek bir node (
i7i.2xlarge) üzerinde birkaç saat yürütüldü; asıl crawl ise 12 node’a ölçeklendi
- Bellek sorunu yaşandı: popüler domainlerin frontier’ları (ziyaret edilmemiş URL’ler) onlarca GB’a kadar büyüdü ve node’ların tekrar tekrar çökmesine yol açtı
- Popüler domainler (ör. yahoo.com, wikipedia.org) ya da anormal derecede fazla bağlantıya sahip siteler sorun çıkardı
- Sorunlu domainler elle hariç tutuldu; arıza olduğunda node yeniden başlatılarak ve frontier truncation uygulanarak toparlanıldı
Teori ile pratiğin karşılaştırılması
- Ders kitaplarındaki klasik tahmin olan "5 makineyle 5 günde 10 milyar sayfa" ile karşılaştırıldığında, gerçek ölçümler buna belli ölçüde yakındı
- Her node’un gerçek ağ ve CPU kullanım oranları dikkate alındığında, daha fazla optimizasyonla daha yüksek throughput’un da mümkün olduğu görüldü
Gelecek görevler ve düşünceler
- Yalnızca HTML parsing ile bile çok sayıda web sayfasına erişilebildiği yeniden doğrulandı; ancak büyük platformlarda (ör. GitHub) anlamlı içerik JS içine gömülü olduğundan parse edilemedi
- Gelecekte JS rendering tabanlı büyük ölçekli crawling için maliyet ve yöntemlerin ayrıca araştırılması gerekiyor
- Veri analizi (gerçekte toplanan sayfaların meta bilgileri, aktif/pasif oranları vb.) de sonraki konu başlıkları arasında anıldı
- Son dönemde yapay zeka ile birleşen agresif crawling giderek artıyor; Cloudflare’ın pay-per-crawl gibi yeni savunma sistemleri ortaya çıkarken web crawling ortamı yeniden değişiyor
3 yorum
Gerçekten harika..alkışlar...
İlginçmiş. Keyifle okudum, teşekkürler.
Müthiş gerçekten.. Kılıçla kalkanın savaşı mı yani haha