OpenFreeMap, Saniyede 100 Bin İsteği Dayanma Deneyimini Paylaştı

 (blog.hyperknot.com)
5 puan yazan GN⁺ 2025-08-10 | 1 yorum | WhatsApp'ta paylaş
  • OpenFreeMap, saniyede 100 bin isteği ve günde 300 milyon trafiği başarıyla işledi
  • Wplace.live'in ani popülaritesi ve otomatik toplu istekler trafik patlamasının nedeni oldu
  • Cloudflare'in CDN önbellek oranı %99,4 ile sunucu, kalan 1.000 rps yükünü de rahatça taşıdı
  • Bunun sonucu olarak yalnızca kayan tile eksikliği gibi küçük kesintiler yaşandı; hizmetin çoğu normal şekilde çalışmaya devam etti
  • İleride referer tabanlı bant genişliği sınırlaması gibi otomatik trafik yönetimi iyileştirmeleri planlanıyor

OpenFreeMap'in Son 10 Aydaki Büyük Trafik Yanıtı

OpenFreeMap son 10 aydır son derece stabil bir operasyon deneyimi yaşadı. Cloudflare bant genişliği desteği, Hetzner sunucularının stabilitesi, Btrfs üzerindeki tile servisi ve nginx verimliliği sayesinde sistem güvenilirliği kanıtlandı. Ancak bir gün bazı tile’ların yüklenmediği yönünde raporlar alınmaya başlandı. Normalde bu, algoritma hatasından kaynaklanır; bu sefer ise nginx loglarında open() "Too many open files" hatası görüldü.

Trafik izleme araçlarıyla yapılan kontrolde, 24 saat içinde 3 milyar istek oluştuğu ve yalnızca küçük tile dosyalarıyla bile 215 TB trafik üretildiği görüldü. Son 5 dakikada ise 30 milyon istek ile, yani saniyede 100 bin isteke ulaşan bir sıçrama yaşandı. Bu trafik, ticari harita servislerinde aylık 6 milyon dolardan fazla maliyet anlamına gelirdi.

Cloudflare panosunda isteklerin %96'sı 200 OK olarak yanıtlandı; yalnızca %3,6'sı anormaldi (206 Partial Content). Çoğu istek sorunsuz servis edildi ve yalnızca bazı eksik tile’lar dışında tüm sistem normal çalıştı.

Trafik Patlamasının Nedeni: Wplace.live

Bu trafiğin kaynağı, yeni bir işbirlikçi çizim sitesi olan Wplace.live idi. Açılışın ardından çok sayıda kullanıcı akın etti ve OpenFreeMap tabanlı haritayı kullanmaları tasarlanmıştı. Kullanıcılar, 1 piksel/30 saniye sınırlamasını atlatmak için otomatik araçlar (örn. Puppeteer/Chromium, IP rotasyonu vb.) ile yüksek hacimli istekler üretmişti.

Reklam

Yönetici, geçmişte Neal.fun ile iş birliği deneyiminden yola çıkarak, trafik patlamasından önce iletişim kurmanın önemini vurguladı. Bu sefer hizmetin aksamasına neden olduğu için ilk kez Cloudflare kuralları uygulanarak engelleme yapıldı. Bundan sonraki dönemde referer ya da custom header tabanlı otomatik trafik kontrolü yöntemleri (Cloudflare API kullanımı dahil) üzerinde çalışılacak.

Cloudflare Desteği ve OpenFreeMap Mimarisinin Başarısı

Cloudflare, bant genişliği desteğini çok hızlı bir şekilde (hafta sonu dahil 48 saat içinde) onayladı ve mühendisleriyle mimari uygunluk konusunu da tartıştı. Büyük ölçekli bir şirket olmasına rağmen esnek bir yanıt verdiğini gösterdi.

İşletici %99,4 CDN önbellek oranına ulaştıklarını ve sunucuların 1.000 rps yükünü de taşıyabildiğini gururla belirtti. Haftalık veri güncellemesi sunan bir servis için bu oldukça iyi bir performans.

Wplace.live Geliştiricileriyle İletişim ve Çözüm Önerileri

Daha sonra Wplace.live geliştiricileriyle temas kuruldu ve ani 2 milyonluk kullanıcı artışının hazırlıksız yakalanmalarına yol açtığı anlaşıldı. Bu ekip için OpenFreeMap self-hosting örnekleri desteği önerilerek, trafik yoğunlaşmasını engelleyip verimliliği artırma konusunda görüşüldü.

Reklam

Ayrıca gerçek 2 milyon kullanıcıya göre 3 milyar istek oluşması, baskın oranda script tabanlı toplu istek olduğunu gösteriyor. Normal kullanıcılar yalnızca 10-20 istekle sınırlı kalırken, gereksiz otomatik istekleri önleyecek şekilde servis politikalarının değiştirilmesi önerildi.

Gelecekteki İyileştirmeler ve Öğrenilenler

Yönetici iki konu başlığına yönelik iyileştirme planından bahsediyor.

  1. Referer tabanlı bant genişliği sınırlandırma

    • Cloudflare'de referer bazlı isteklerin gün bazında 100 milyon ile 200 milyon arası sınırlanması planlanıyor
    • Yerel (native) uygulamaları custom header kullanmaya yönlendirmek hedefleniyor

  2. Eksik tile işleme ve sunucu yapılandırma iyileştirmesi

    Reklam
    • Hatalı sunucu ayarlarıyla boş tile üretilmesini önleyici düzenlemeler yapılacak

OpenFreeMap şu anda aylık 500 dolar bağışla çalışıyor. Altyapı maliyeti karşılanabiliyor; ancak yeni geliştirmeler sınırlı kişisel zamana bağlı kalıyor. Daha fazla destekle geliştirme hızı ve hizmet kararlılığı artırılabilir.

GitHub sponsorluklarıyla projeye destek verebilirsiniz: https://github.com/sponsors/hyperknot

İlgili okumalar

1 yorum

 
GN⁺ 2025-08-10
Hacker News yorumu

  • Bazı görsellerin script kiddie'ler tarafından çizildiğini tahmin ediyorum. Bu site her kullanıcıya 30 saniyede yalnızca 1 piksel izni verdiği için, herkesin Puppeteer veya Chromium ile yeni bir tarayıcı açıp pikseli tıklayıp sonra tarayıcıyı kapattığı bir otomasyonu çalıştırdığını düşünüyorum. IP adresini değiştirme yapmış olmaları da mümkün; ama buna aslında hiç ihtiyaç olmamış olabilir. Bu olayın bir gecede bu ölçekte büyüdüğünü hafife almamanızı isterim. Evime yakın bir çizimi birkaç kişiye anlatınca, siteyi anmadan da herkesin ne anlama geldiğini hemen yakaladığını gördüm. İnsanlar bu /r/place benzeri projeleri birkaç yılda bir gerçekten seviyorlar; bu kez dünya haritası üzerinde çizim yapabildikleri ve evlerinin yakınını doğrudan çizebildikleri için buna çok iyi tepki verdi gibi görünüyor.

  • Bu, MapLibre'de doğrudan static pmtiles dosyası okuma yoluyla olsaydı nasıl bir fark olurdu, merak ediyorum. BunnyCDN'den pmtiles'i range request ile çekerken, gerçek tile sunucusundan almakla neredeyse aynı yanıt hızını gördüm.

    • wplace, tüm ihtiyacı tek bir özel static pmtile ile karşılayabileceğini düşünüyorum; 150GB OSM verisini işleme gereği hiç olmayacak bir durumda.

    • İlgili bağlantı paylaşıldı

  • Bu kadar detaylı açıklama ve şeffaflık için teşekkür ederim. StatusGator'un arıza haritasında MapTiler yerine OpenFreeMap kullanmayı düşünüyorum.

    • İstediğiniz zaman geçebilirsiniz. Yüksek kullanılabilirlik konusunda endişe varsa doğrudan kendiniz hostlayabilirsiniz. Public instance'ı mümkün olduğunca kararlı hale getirmek için sürekli uğraşıyoruz.

  • Sadece ekran görüntüsüne bakınca tek bir VPS'nin bile yeterli olabileceğini düşündürüyor ve mimari gereğinden karmaşık görünüyordu. Sonra pikselin tüm dünya haritasına yerleştirildiğini fark ettim. En yüksek request throughput'in ne olabileceğini merak ediyorum. Bunun, benchmark'ı kolay bir web sunucusunun sadece zor da olsa kaldırabileceği bir seviyede olması da mümkün olabilir. Tabi bu tip bir uygulamada büyük performans düşüşleri olabilir. 1 km'de 64 piksel varsa sıkıştırılmamış renklerle tam dünya kapsaması 8 TB gerektirir (uzun vadede bakılması gereken bir konu!). Hetzner'de 10 TB diski aylık 20€ olup, bu yüzden cache kesin gerekli görünüyor. wplace çizim katmanında 1000x1000 piksel PNG kullanıyor; görsel hemen açılıyor ama haritanın kendisi çok yavaş ve bazı noktalar hiç yüklenmiyor.

    • Hetzner'de aylık 20€ fena görünse de, gerçekten gerekli anlarda her zaman düzgün çalışacağı ayrı bir mesele.

  • Açık dosya sayısı sınırı bir sorundu gibi duruyor; sadece bu limiti artsaydık durumu kaldırabilir miydik diye merak ediyorum. Spam trafiğini engellemeyi anlamak mümkün ama teoride sadece limit arttırılarak daha fazla işlenemez miydi?

    • Birkaç LLM ve uzun bir debugging sonrası nginx topluluk forumunda bir soru bıraktım. Şu an bunun multi_accept, open_file_cache ve worker_rlimit_nofile kombinasyonundan kaynaklandığını düşünüyorum. Detayları burada inceleyebilirsiniz. Sunucu 200 Mbps'ye kadar kullanımdaydı, bu yüzden limit artsa bile uzun süre dayanması zor olurdu.

  • Ön belleği kurmamış bir site bunu sadece 'tembellikten' dolayı mı yapıyor diye merak ediyorum. Neden wplace.live, openfreemap'e bu kadar trafik veriyor da, kendi sunucunda bir cache sunucusu dahi koyup openfreemap'ten daha hızlı veya benzer bir servis veremeyeceğiz?

    • openfreemap bir CDN arkasında ve ana sayfada şu şekilde yazıyor: "Public instance ücretsiz, görünüm/istek sınırlaması yok, kayıt/cookie/API anahtarı yok. Maliyetleri bağışlarla karşılanıyor. Ticari kullanım serbest." Bunu okuyunca doğrudan kullanılabilen bir şey gibi geliyor. CDN önüne neden ekstra cache server koymak isteği zor görünüyor. Bant genişliğine bakıp karar verilirdi ama beklenmedik bir viral anda başka şeylere odaklanmak gerekebilir.

    • Bu soruya doğrudan cevap verebilirim: öncelik meselesi. Oldukça popüler bir açık artırma sitesi yönetiyorum ve harita tile'larını Stadia Maps'ten alıyorum. Ayda 80$ ödüyorum; tile'ları cacheleyip proxy ile sunarsam daha ucuza gelebileceğini biliyorum ama daha acil işler olduğu için hala cache işi yapamadım.

    • Buradaki veri hacmi gerçekten devasa. Anlık olarak 56Gbps (56 sunucu %100 trafiğini tüketiyor!) görüldü. Tek bir cache sunucusuyla karşılanamaz bir ölçekte. Bu boyutta ancak Cloudflare benzeri bir CDN ağı yeter.

    • Eğlenceli bir site gibi görünüyor ve kâr odaklı olmadığı hissediliyor. Böyle sitelerin odak noktası genelde "çalışıyor tutmak" olur, büyük ölçekli trafik yönetimi birinci öncelik değildir. Kullanıcılar bir gecede iki katına çıktı; bakımı yapan kişi de tek başına ya da çok az sayıda.

  • Cloudflare'ı doğrudan hiç denemedim ve web map teknolojisine de aşina değilim. Site çoğunlukla statik dosya sunuyorsa neden sürekli Hetzner kullanmak gerekiyor, merak ediyorum. Cloudflare Pages'e tamamen taşınması mümkün mü acaba?

    • Tile'ların render edilmesi gerekiyor. Sık kullanılan tile'lar zaten cacheleniyor ve o cache rolünü Cloudflare üstleniyor. Teoride tileserver'ı Cloudflare Pages'e geçirmek mümkün olsa da, sonunda port etme işini de yapmak gerekiyor ve maliyetin daha düşeceğini de sanmıyorum.

  • Referrer tabanlı kısıtlama garip bir tercih gibi. Eğer normal bir kullanıcı dakikada 10-20 istek atıyorsa IP başına dakikada 100 istek (ortalama 5 kat) limiti koymak çoğunu durdurmaya yetmez mi? Ya da çok az sayıda kötü niyetli kullanıcıyı JA4/JA3 pattern'leriyle engellemek mümkün olmaz mıydı?

    • Birinin gerçekten gezegenin birçok yerini keşfetmek istemesi de olabilir; hatırladığım kadarıyla bir keresinde yarım gün Google Earth geziyorum diye geçirmiştim. Referrer tabanlı limit daha iyi olur diye düşünüyorum; (yüksek trafik tüketen) kullanıcılara doğrudan public instance yerine self-hosting önerilebilir.

    • Referrer ile sınırlamak iyi bir ilk adım (ana sayfadaki uyarı mesajı da revize edilmeli). Site bazında kullanım takibi yapmak çok daha etkili olur. Siteye kullanım kalıbını değiştirmeleri için söylenecek şeyler söylenebilir ama bireysel kullanıcıya bunu uygulamak zordur. IP bazlı limit de eklenebilir ama çok düşük ayarlanırsa bu durumda işe yaramaz.

  • Savunmanız gerçekten iyi olmuş. Bu bir DDoS saldırısı. Bant genişliği ücretini ayrıca ödemediğiniz için şanslısınız; ödeseydiniz gerçekten cüzdanı kilitleyen bir saldırı olurdu.

  • Cache hit oranı çok yüksek. Özel bir teknik uygulanmış mı, merak ediyorum.

    • Tüm route yapısı ve location block'ları önbelleği düşünerek baştan tasarlandı. İsterseniz nginx.conf örneği'ne bakabilirsiniz