OpenFreeMap Berbagi Pengalaman Menangani 100.000 Permintaan per Detik

• OpenFreeMap berhasil menangani 100.000 permintaan per detik dan 300 juta permintaan lalu lintas harian
• Popularitas mendadak Wplace.live dan permintaan massal yang otomatis menjadi penyebab lonjakan lalu lintas
• Cloudflare mencapai tingkat cache CDN 99,4%, sementara server dengan mudah menyerap sisa 1.000 rps
• Akibatnya hanya terjadi gangguan kecil seperti tile hilang, dan layanan sebagian besar tetap beroperasi normal
• Untuk ke depan direncanakan peningkatan pengelolaan lalu lintas otomatis, termasuk pembatasan bandwidth berbasis referer

---

Pengalaman 10 Bulan Terakhir OpenFreeMap dan Penanganan Lalu Lintas Berukuran Besar

OpenFreeMap telah melewati pengalaman operasi yang sangat stabil selama 10 bulan terakhir. Dukungan bandwidth dari Cloudflare, stabilitas server Hetzner, layanan tile pada Btrfs, dan efisiensi nginx menunjukkan bahwa keandalan sistem sudah terbukti. Namun, suatu saat mendapat laporan bahwa beberapa tile tidak termuat. Umumnya ini biasanya disebabkan bug algoritma, tetapi pada kesempatan ini ditemukan error open() "Too many open files" di log nginx.

Dengan memeriksa melalui alat pemantau lalu lintas, terdeteksi bahwa dalam kurun waktu 24 jam terjadi 3 miliar permintaan, dan untuk file tile berukuran kecil saja tercatat 215 TB trafik. Dalam 5 menit terakhir sempat terjadi 30 juta permintaan, mencapai lonjakan 100.000 permintaan per detik. Lalu lintas seperti ini diperkirakan memerlukan biaya lebih dari 6 juta dolar AS per bulan untuk layanan peta komersial.

Di dashboard Cloudflare, 96% merespons 200 OK, dan hanya 3,6% yang abnormal (206 Partial Content). Mayoritas permintaan dilayani secara normal, dan di luar beberapa tile yang hilang, keseluruhan sistem tetap berjalan dengan baik.

Penyebab Lonjakan Lalu Lintas: Wplace.live

Penyebab lonjakan kali ini adalah situs gambar kolaboratif baru bernama Wplace.live. Setelah diluncurkan, banyak pengguna berdatangan dan situs ini dirancang agar menggunakan peta berbasis OpenFreeMap. Untuk menghindari batas 1 piksel/30 detik, pengguna membangkitkan permintaan massal menggunakan alat otomatisasi (misalnya Puppeteer/Chromium, rotasi IP, dan sebagainya).

Pengelola menekankan pentingnya komunikasi awal sebelum trafik meningkat, mengacu pada pengalaman sebelumnya saat bekerja sama dengan Neal.fun. Karena kali ini mengganggu operasi layanan, aturan Cloudflare diterapkan untuk pertama kalinya guna memblokir trafik tersebut. Ke depan, sedang dicari solusi kontrol lalu lintas otomatis berbasis referer atau custom header, termasuk pemanfaatan Cloudflare API.

Dukungan Cloudflare dan Kinerja Arsitektur OpenFreeMap

Cloudflare menyetujui dukungan bandwidth dalam prosedur yang sangat cepat (dalam 48 jam termasuk akhir pekan) dan juga berdiskusi hingga tingkat arsitektur bersama tim engineer. Hal ini menunjukkan responsivitas yang fleksibel meski merupakan perusahaan berskala besar.

Operator bangga berhasil mencapai tingkat cache CDN 99.4% dan bahwa server mampu menahan beban 1.000 rps. Untuk layanan yang menyediakan pembaruan data mingguan, ini adalah kinerja yang cukup tinggi.

Komunikasi dengan Pengembang Wplace.live, dan Rekomendasi Solusi

Setelah terjalin kontak dengan pengembang Wplace.live, dipahami bahwa peningkatan hingga 2 juta pengguna secara mendadak menyebabkan keterbatasan kesiapan mereka. Mereka diusulkan untuk mendukung instance self-hosting OpenFreeMap, dan didiskusikan agar konsentrasi lalu lintas dapat ditekan sekaligus meningkatkan efisiensi.

Selain itu, meski jumlah pengguna hanya 2 juta, munculnya 3 miliar permintaan menunjukkan dominasi permintaan massal berbasis skrip. Karena pengguna biasa hanya melakukan 10 hingga 20 permintaan, disarankan mengubah kebijakan layanan untuk mencegah permintaan otomatis yang tidak perlu.

Rencana Peningkatan dan Pembelajaran ke Depan

Operator mengumumkan dua perbaikan yang akan dilakukan.

1. Pembatasan bandwidth berbasis Referer

   • Rencana memasukkan batas per referer di Cloudflare, misalnya 100–200 juta permintaan per 24 jam
   • Aplikasi native akan diarahkan agar menggunakan custom header

2. Penanganan tile hilang dan perbaikan konfigurasi server

   • Akan dilakukan tindakan agar tile kosong yang dihasilkan karena pengaturan server yang salah tidak terjadi lagi

OpenFreeMap saat ini dioperasikan dengan donasi $500 per bulan. Biaya infrastruktur sudah terpenuhi, tetapi pengembangan baru masih bergantung pada waktu pribadi yang terbatas. Dukungan lebih lanjut dapat memungkinkan peningkatan kecepatan pengembangan dan perluasan stabilitas layanan.

Anda dapat berpartisipasi dalam mendukung proyek melalui GitHub Sponsors: https://github.com/sponsors/hyperknot

[GN⁺]

Pendapat Hacker News

• Beberapa gambar diduga digambar oleh script kiddie. Situs ini hanya mengizinkan satu piksel setiap 30 detik per pengguna, jadi saya menduga mereka mengotomatisasi dengan membuka browser baru lewat Puppeteer atau Chromium, lalu klik satu piksel dan menutup browser tersebut. Mungkin juga dilakukan rotasi alamat IP, meskipun mungkin itu tidak terlalu dibutuhkan. Jangan dianggap remeh bahwa ini membesar secara massif dalam semalam. Saat saya menyebutkan gambar di sekitar rumah saya ke beberapa orang, tanpa menyebut situsnya, mereka langsung mengerti apa maksudnya. Orang-orang memang suka proyek tipe /r/place beberapa kali dalam beberapa tahun, dan sepertinya antusiasme besar datang karena kali ini mereka bisa menggambar di sekitar lokasi rumah masing-masing di peta dunia.

• Saya penasaran seperti apa kalau MapLibre langsung membaca file pmtiles statis. Saat mengambil pmtiles dari Bunnycdn dengan range request, saya merasakan kecepatan respons hampir sama seperti saat mengambilnya langsung dari tile server nyata.

  • Saya pikir wplace bisa memenuhi seluruh kebutuhan hanya dengan satu static pmtile kustom. Ini bukan kasus yang perlu memproses data 150GB OSM sama sekali.

  • Tautan terkait dibagikan

• Saya berterima kasih atas penjelasan yang sangat detail dan transparan ini. Saya sedang mempertimbangkan memakai OpenFreeMap untuk peta insiden StatusGator menggantikan MapTiler.

  • Bisa pindah kapan pun. Kalau khawatir soal ketersediaan tinggi, bisa langsung self-hosting. Kami terus berusaha membuat instans publik ini semaksimal mungkin stabil.

• Dari screenshot saja terlihat cukup dengan satu VPS dan desainnya tampak terlalu kompleks. Namun saya menyadari bahwa piksel-piksel itu ditempel di peta seluruh dunia. Saya penasaran berapa throughput puncak yang bisa dicapai. Mungkin ini bisa ditangani oleh server web yang mudah untuk di-benchmark. Tentu, karakter aplikasinya mungkin membuat penurunan performa yang signifikan. Dengan 64 piksel per 1km, untuk menutupi seluruh dunia dalam warna tanpa kompresi butuh 8TB (ini isu jangka panjang). Di Hetzner paket box 10TB seharga 20 euro per bulan, jadi caching terlihat wajib. wplace memakai layer gambar PNG 1000x1000 dan gambarnya langsung tampil, tapi peta aslinya sangat lambat dan ada area yang bahkan tidak muncul sama sekali.

  • Di Hetzner 20 euro per bulan memang kelihatan menarik, tapi apakah benar-benar akan tetap berjalan baik di saat paling dibutuhkan itu cerita lain.

• Sepertinya masalahnya memang batas jumlah file terbuka, saya penasaran kalau batas itu saja yang dinaikkan apakah cukup ditanggung. Wajar jika trafik spam diblokir, tapi secara teori apakah tidak seharusnya lebih banyak trafik bisa ditangani hanya dengan menaikkan limitnya.

  • Setelah debugging lama dengan beberapa LLM, saya sempat bertanya di forum komunitas nginx. Saat ini saya menduga kombinasi multi_accept, open_file_cache, dan worker_rlimit_nofile yang menjadi penyebab. Detailnya ada di sini. Server diperkirakan menggunakan 200 Mbps, jadi meskipun limit dinaikkan kemungkinan tetap tidak bisa bertahan lama.

• Apakah situs yang tidak menerapkan caching berarti semata-mata karena "terlalu repot"? Kalau begitu, kenapa wplace.live mengirim begitu banyak trafik ke openfreemap, padahal saya rasa kalau pasang satu server cache di depan server sendiri, bisa jadi layanannya lebih cepat atau setidaknya sebanding dengan openfreemap.

  • openfreemap ada di belakang CDN, dan di beranda tertulis seperti ini: "Instans publik gratis, tanpa batasan lihat halaman/jumlah request, tanpa perlu signup/cookie/API key. Biaya ditanggung dari donasi. Penggunaan komersial diizinkan." Kalau dibaca begitu, rasanya memang langsung bisa dipakai. Jadi sepertinya tidak perlu menaruh cache server di depan CDN. Memang perlu cek bandwidth lalu dipertimbangkan, tapi di saat viral yang tak terduga kita bisa sibuk urusan lain.

  • Untuk pertanyaan ini saya bisa jawab tegas: ini soal prioritas. Saya menjalankan situs lelang yang cukup populer dan tile peta saya ambil dari stadia maps. Saya bayar 80 dolar per bulan, dan tahu kalau bisa menyajikan tile via proxy dengan caching agar lebih hemat biaya, tapi karena selalu ada prioritas yang lebih mendesak jadi saya belum sempat kerjakan caching.

  • Data yang ditangani di sini sangat besar. Pernah kena lonjakan 56Gbps (56 server mengonsumsi traffic 100%!) jadi tidak bisa ditangani oleh satu server caching saja. Ini butuh jaringan setara CDN seperti Cloudflare.

  • Situs ini keliatan menarik dan sepertinya bukan proyek komersial. Fokus situs semacam ini umumnya membuat semuanya "berjalan", bukan menjadikan penanganan trafik masif sebagai prioritas pertama. Jumlah pengguna pun meningkat berlipat ganda dalam semalam, dan pemeliharanya tampaknya satu orang atau tim kecil.

• Saya sendiri belum pernah pakai Cloudflare secara langsung, dan juga tidak terlalu familiar dengan teknis web map. Kalau situs ini mayoritas hanya menyajikan file statis, saya penasaran kenapa harus pakai Hetzner terus. Apakah tidak mungkin dipindahkan penuh ke Cloudflare Pages?

  • Tile perlu rendering. Tile yang sering dipakai sudah ter-cache, dan peran cache itu dilakukan oleh Cloudflare. Secara teoritis tileserver bisa dipindah ke Cloudflare Pages, tetapi tetap perlu pekerjaan porting dan kemungkinan biayanya tidak jadi lebih murah.

• Batasan berbasis referrer terasa pilihan aneh. Kalau pengguna normal melakukan 10–20 request per menit, tidak cukupkah menetapkan batas 100 permintaan per menit per IP (rata-rata 5x lebih) untuk memblokir kebanyakan? Atau kalau ada sedikit pengguna jahat, kenapa tidak diblokir lewat pola JA4/JA3?

  • Bisa saja satu orang ingin benar-benar menjelajahi seluruh bagian bumi. Dulu saya punya pengalaman setengah hari main-main sama Google Earth. Saya pikir pembatasan berbasis referrer itu lebih baik—pengguna yang memakan trafik tinggi bisa diarahkan untuk self-hosting daripada memakai instans publik.

  • Batasan lewat referrer itu langkah awal yang bagus (pesan panduan di beranda juga sepertinya perlu diubah). Lebih efektif melacak kuota berdasarkan situs. Dari sisi situs bisa meminta perubahan pola penggunaan mereka, tapi ke perorangan tidak mudah. Pembatasan per-IP juga akan membantu, meski kalau disetel terlalu rendah biasanya tidak efektif untuk kasus ini.

• Saya pikir pemblokiran ini hebat. Ini adalah serangan ddos. Beruntung tidak ada biaya terpisah untuk bandwidth, kalau tidak ini bisa jadi serangan yang bikin dompet meledak.

• Tingkat cache hit sangat tinggi. Saya penasaran apakah ada teknologi khusus yang diimplementasikan.

  • Arsitektur jalur penuh dan location block sudah didesain sejak awal dengan mempertimbangkan caching. Kalau penasaran, silakan lihat contoh nginx.conf.