OpenFreeMap แบ่งปันประสบการณ์ที่รับคำขอได้ 100,000 รายการต่อวินาที

 (blog.hyperknot.com)
5 คะแนน โดย GN⁺ 2025-08-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • OpenFreeMap จัดการคำขอได้ถึง 100,000 ต่อวินาทีและทราฟฟิกรายวัน 300 ล้านรายการได้สำเร็จ
  • ความนิยมที่เกิดขึ้นอย่างกะทันหันของ Wplace.live และคำขอจำนวนมากแบบอัตโนมัติเป็นสาเหตุของการพุ่งสูง
  • อัตรา CDN cache 99.4% ของ Cloudflare พร้อมเซิร์ฟเวอร์ที่รองรับโหลดที่เหลืออีก 1,000 rps ได้อย่างราบรื่น
  • ทำให้เกิดปัญหาเล็กน้อยเช่น tile หายไปเป็นครั้งคราว ขณะที่ระบบให้บริการได้ตามปกติมากกว่าเดิม
  • วางแผนปรับปรุงการจัดการทราฟฟิกอัตโนมัติในอนาคต เช่นการจำกัดแบนด์วิดธ์ตาม Referer

10 เดือนที่ผ่านมาและประสบการณ์รับมือทราฟฟิกขนาดใหญ่ของ OpenFreeMap

OpenFreeMap มีประสบการณ์การให้บริการที่ค่อนข้างเสถียรมาเป็นเวลา 10 เดือน ด้วยความช่วยเหลือด้านแบนด์วิดท์จาก Cloudflare ความเสถียรของเซิร์ฟเวอร์จาก Hetzner บริการ tile บน Btrfs และประสิทธิภาพของ nginx ซึ่งยืนยันความเชื่อถือได้ของระบบได้แล้ว.**

แต่แล้ววันหนึ่งมีรายงานว่ามีบาง tile ที่โหลดไม่ขึ้น ซึ่งปกติแล้วมักเกิดจากบั๊กอัลกอริทึม แต่ในครั้งนี้พบข้อผิดพลาด open() Too many open files ในบันทึกของ nginx

จากเครื่องมือมอนิเตอร์ทราฟฟิกพบว่ามีคำขอเกิดขึ้น 3 พันล้านครั้งใน 24 ชั่วโมง และแม้แต่ไฟล์ tile ขนาดเล็กก็ทำให้เกิดทราฟฟิกถึง 215TB สังเกตได้ว่าช่วงล่าสุด 5 นาทีมีคำขอสูงถึง 30 ล้านครั้ง หรือเทียบได้กับ 100,000 คำขอต่อนาที การรับส่งทราฟฟิกนี้ หากเป็นบริการแผนที่เชิงพาณิชย์คาดว่าค่าใช้จ่ายมากกว่า 6 ล้านดอลลาร์ต่อเดือน

ในแดชบอร์ด Cloudflare, 96% ตอบกลับด้วย 200 OK และมีเพียง 3.6% เท่านั้นที่ผิดปกติ (206 Partial Content). สรุปได้ว่าคำขอส่วนใหญ่ได้รับบริการอย่างปกติ และนอกเหนือจาก tile บางส่วนที่หายไป ระบบโดยรวมก็ทำงานได้ดี

สาเหตุของการพุ่งสูง: Wplace.live

สาเหตุของการพุ่งสูงครั้งนี้คือเว็บไซต์วาดภาพร่วมกันใหม่ที่ชื่อ Wplace.live. หลังเปิดตัวมีผู้ใช้จำนวนมากหลั่งไหลเข้ามา และระบบถูกออกแบบให้ใช้แผนที่บน OpenFreeMap โดยตรง ชุมชนผู้ใช้งานมีการใช้เครื่องมืออัตโนมัติเพื่อละเว้นข้อจำกัด 1 พิกเซล/30 วินาที เช่น Puppeteer/Chromium, การหมุน IP และเทคนิคอื่น ๆ เพื่อสร้างคำขอจำนวนมาก

ผู้ดูแลระบบเน้นย้ำว่าจากประสบการณ์ที่เคยทำงานร่วมกับ Neal.fun มาก่อน การสื่อสารล่วงหน้าเป็นเรื่องสำคัญ ก่อนเกิดพีคทราฟฟิก ครั้งนี้ได้อธิบายว่าการให้บริการถูกกระทบ จึงได้เริ่มใช้กฎของ Cloudflare เพื่อบล็อกครั้งแรก ส่วนอนาคตกำลังสำรวจแนวทางควบคุมทราฟฟิกอัตโนมัติบนฐาน Referer หรือ custom header (รวมถึงการใช้ Cloudflare API)

การสนับสนุนจาก Cloudflare และผลงานของสถาปัตยกรรม OpenFreeMap

Cloudflare อนุมัติการสนับสนุนแบนด์วิดท์ได้อย่างรวดเร็วมาก (อนุมัติภายใน 48 ชั่วโมง รวมวันหยุดสุดสัปดาห์) และยังร่วมคุยกับวิศวกรเรื่องความเหมาะสมด้านสถาปัตยกรรม แสดงให้เห็นถึงความคล่องตัวที่ดีมากแม้จะเป็นองค์กรขนาดใหญ่

ผู้ดำเนินการรู้สึกภูมิใจที่สามารถทำอัตรา CDN cache 99.4% ได้ และเซิร์ฟเวอร์รับโหลด 1,000 rps ได้อย่างดีเยี่ยม ซึ่งเป็นผลลัพธ์ที่ดีมากสำหรับบริการที่มีการอัปเดตข้อมูลรายสัปดาห์

การสื่อสารกับนักพัฒนา Wplace.live และข้อเสนอการแก้ไข

ต่อมาก็สามารถติดต่อกับนักพัฒนา Wplace.live ได้ และเข้าใจได้ว่าการเพิ่มขึ้นอย่างฉับพลันของผู้ใช้ 2 ล้านคนทำให้การเตรียมการไม่พร้อมพอ จึงเสนอให้ใช้การสนับสนุน OpenFreeMap self-hosted instance เพื่อป้องกันการรวมตัวแบบฮอตสปอตของทราฟฟิกและเพิ่มประสิทธิภาพการใช้ทรัพยากรอย่างเหมาะสมได้

นอกจากนี้ จำนวนคำขอ 3 พันล้านครั้งเมื่อเทียบกับผู้ใช้จริง 2 ล้านคน สะท้อนว่าคำขอจำนวนมากนั้นมาจากสคริปต์เป็นหลัก ผู้ใช้ทั่วไปแทบจะทำเพียง 10-20 คำขอเท่านั้น จึงแนะนำให้ปรับนโยบายบริการเพื่อป้องกันคำขออัตโนมัติที่ไม่จำเป็น

แผนปรับปรุงในอนาคตและสิ่งที่ได้เรียนรู้

ผู้ดูแลระบบแจ้งว่าเตรียมปรับปรุงสองประเด็นดังนี้

  1. การจำกัดแบนด์วิดท์ตาม Referer

    • วางแผนนำระบบจำกัดคำขอต่อ Referer ในช่วง 24 ชั่วโมงลงไปที่ 100-200 ล้านครั้งใน Cloudflare
    • ชี้แนะให้แอปเนทีฟใช้ custom header ในการเชื่อมต่อ

  2. การจัดการ tile ที่หายไปและปรับปรุงการตั้งค่าเซิร์ฟเวอร์

    • วางมาตรการป้องกันการสร้าง tile ว่างที่เกิดจากการตั้งค่าเซิร์ฟเวอร์ที่ไม่ถูกต้อง

OpenFreeMap ใช้การสนับสนุนรายเดือน 500 ดอลลาร์ในการดำเนินการในปัจจุบัน แม้โครงสร้างพื้นฐานจะได้รับการครอบคลุมค่าใช้จ่ายแล้ว แต่การพัฒนาส่วนใหม่ยังคงพึ่งพาเวลาส่วนตัวจำกัด การได้รับการสนับสนุนเพิ่มเติมจะช่วยขยายความเร็วในการพัฒนาและเสริมความเสถียรของระบบได้มากขึ้น

คุณสามารถมีส่วนร่วมสนับสนุนโปรเจกต์ผ่านทาง GitHub Sponsors ได้ที่: https://github.com/sponsors/hyperknot

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-08-10
ความคิดเห็นจาก Hacker News

  • ผมคาดเดาว่าแถวไหนของภาพบางส่วนถูกวาดโดยสคริปต์คิทตี้ พฤติกรรมนี้เกิดได้เพราะไซต์กำหนดให้ทุกผู้ใช้วาดได้เพียง 1 พิกเซลต่อ 30 วินาที จึงน่าจะเป็นแบบที่เปิดเบราว์เซอร์ใหม่ด้วย Puppeteer หรือ Chromium คลิกพิกเซล แล้วปิดเบราว์เซอร์ทันทีเพื่อรัน automation โดยอาจมีการหมุน IP ด้วยก็เป็นไปได้ แต่บางทีอาจไม่ต้องใช้วิธีซับซ้อนมากขนาดนั้น ขออย่าเพิ่งประเมินต่ำเกินไปว่าเหตุการณ์แบบนี้มันขยายตัวมากขึ้นอย่างกะทันหันมากในเพียงหนึ่งคืน พอผมพูดเรื่องรูปวาดที่อยู่แถวบ้านให้คนไม่กี่คนฟัง โดยไม่ถึงกับเอ่ยชื่อเว็บ คนเหล่านั้นก็จับประเด็นได้ทันทีทันใด คนมักชอบโปรเจกต์แนว /r/place แบบนี้ทุกไม่กี่ปี และครั้งนี้มันน่าจะนิยมเพราะวาดบนแผนที่โลกได้เลย จึงทำให้ใครหลายคนวาดใกล้บ้านตัวเองได้

  • ผมสงสัยว่าถ้าดูผ่าน maplibre แล้วอ่านไฟล์ pmtiles แบบ static โดยตรง จะต่างกันยังไง ตอนดึง pmtiles จาก Bunnycdn ด้วย range request ผมได้ประสบการณ์ความเร็วตอบสนองเกือบเท่ากับการรับจาก tile server ตัวจริง

    • ผมคิดว่า wplace ทำได้ด้วยไฟล์ pmtile static แบบ custom เพียงไฟล์เดียวก็อาจแก้ความต้องการทั้งหมดได้ ไม่มีความจำเป็นต้องประมวลผลข้อมูล OSM 150GB ในกรณีนี้

    • ลิงก์ที่เกี่ยวข้อง เอามาแชร์

  • ชื่นชมคำอธิบายที่ละเอียดและความโปร่งใสระดับนี้มาก พิจารณาเปลี่ยนแผนที่เหตุขัดข้องของ StatusGator จาก MapTiler มาใช้ OpenFreeMap

    • ย้ายมาได้ตลอด หากกังวลเรื่องความพร้อมใช้งานสูงก็สามารถโฮสต์เองได้ เราพยายามทำให้ public instance เสถียรที่สุดเท่าที่จะทำได้

  • ดูจาก screenshot อย่างเดียว ผมก็คิดว่ารันบน VPS เครื่องเดียวก็พอ และอาจดูซับซ้อนเกินจำเป็น แต่เมื่อตระหนักว่าพิกเซลถูกวางบนแผนที่โลกทั้งใบแล้วก็เริ่มคิดว่าควรรับคำขอสูงสุดได้เท่าไร คิดว่าอาจอยู่ในระดับที่เว็บเซิร์ฟเวอร์ที่เทสต์ benchmark ได้สบายๆ ก็คุ้ม แล้วก็อย่างว่าระบบอาจเกิดการตกประสิทธิภาพอย่างรุนแรงได้ง่ายๆ ในที่มี 64 พิกเซลต่อ 1 กม. แล้วหากปกคลุมทั่วโลกแบบไม่บีบอัดสี จะต้องใช้ 8TB (เป็นโจทย์ระยะยาวแน่นอน) ในขณะที่ Hetzner ให้ box 10TB ได้เดือนละ 20 ยูโร จึงดูว่าจะต้องมี caching แน่นอน wplace ใช้ png 1000x1000 พิกเซลที่เลเยอร์วาด และรูปขึ้นเร็วมาก แต่แผนที่ตัวเองค่อนข้างช้า บางช่วงยังไม่ขึ้นเลย

    • Hetzner เดือนละ 20 ยูโรอาจดูดี แต่ความสามารถในการให้บริการได้เสถียรในช่วงเวลาที่ต้องการจริงๆ นี่คือตัวแปรอีกอย่าง

  • ดูเหมือนว่าเรื่องมันคือการจำกัดจำนวนไฟล์ที่เปิดอยู่ ถ้ายกเพดานนี้ขึ้นมาอีกหน่อยคงรับไหวได้? ผมเข้าใจเหตุผลในการป้องกันสแปมเทรฟฟิก แต่ในทางทฤษฎีก็ควรเป็นไปได้ที่จะรองรับได้มากขึ้นหากเพิ่มเพดานนั้นอย่างเดียว

    • หลังจากเจาะกับ LLM หลายตัวและดีบักนาน ผมก็ถามในฟอรัมชุมชน nginx แล้ว ตอนนี้ยังเชื่อว่าเป็นผลจากการจับคู่ของ multi_accept, open_file_cache และ worker_rlimit_nofile รายละเอียดเพิ่มเติมดูได้ที่ ที่นี่ เซิร์ฟเวอร์กำลังใช้ทรัพยากรถึง 200 Mbps อยู่แล้ว จึงน่าจะไม่ทนได้นานหากเพียงเพิ่มเพดานเฉยๆ

  • สงสัยว่าเว็บที่ไม่ implement caching มักทำแบบนั้นเพราะเกรงว่าจะยุ่งเหยิง เหตุใด wplace.live ถึงส่งทราฟฟิกจำนวนมากให้ openfreemap ทั้งที่ดูเหมือนเพียงเพิ่มเซิร์ฟเวอร์ caching เดียวที่ตัวเองก็อาจให้บริการได้เร็วไม่แพ้ openfreemap

    • openfreemap อยู่หลัง CDN และบนหน้าเว็บยังมีข้อความแบบนี้ว่า: "อินสแตนซ์สาธารณะฟรี, ไม่มีข้อจำกัดจำนวนวิว/คำขอ, ไม่ต้องสมัคร/คุกกี้/API key. ค่าใช้จ่ายรองรับโดยการบริจาค และอนุญาตให้ใช้เพื่อการค้าได้" อ่านดูแล้วรู้สึกว่าใช้งานได้เลยทันที จึงไม่เห็นว่าจำเป็นต้องมี caching server แทรกก่อนหน้า CDN เลย ดึง bandwidth มาเทียบก็ต้องคิดนะ แต่ถ้าเกิดไวรัลไม่คาดคิดอาจต้องไปยุ่งกับอย่างอื่นแทน

    • ผมเชื่อว่าคำตอบนี้ตรงมากคือเรื่องลำดับความสำคัญ ผมรันเว็บไซต์ประมูลที่ค่อนข้างนิยม และรับ tile มาจาก stadia maps ผมจ่ายเดือนละ 80 ดอลลาร์ แต่ทราบว่า ถ้าคิวเออร์ไทล์ผ่าน proxy แล้วทำ caching จะถูกกว่าได้ แต่ยังไม่รีบทำเพราะงานเร่งด่วนอื่นๆ ติดๆ อยู่ตลอด

    • ปริมาณข้อมูลที่มีที่นี่มันมหาศาล ระดับสูงสุดอยู่ที่ 56Gbps (เซิร์ฟเวอร์ 56 ตัวกินทราฟฟิก 100%) ซึ่งเกินกว่าที่ caching server เดียวจะรับได้ ขนาดนี้ต้องใช้ระดับเครือข่าย CDN แบบ Cloudflare เป็นต้นจึงจะรับไหว

    • ดูเหมือนเป็นไซต์แนวความบันเทิงที่ไม่มุ่งหวังผลกำไร จุดเน้นของไซต์ลักษณะนี้คือ "ให้ระบบทำงานได้" มากกว่าการรับมือทราฟฟิกจำนวนมากเป็นเรื่องแรก ผู้ใช้โตขึ้นเป็น 2 เท่าในคืนเดียว และผู้ดูแลก็เหมือนคนเดียวหรือทีมเล็กๆ

  • ผมไม่เคยใช้ Cloudflare โดยตรง และไม่ค่อยคุ้นกับเทคโนโลยีเว็บแมป หากเว็บนี้เป็นไฟล์ static เป็นหลัก ทำไมจึงยังต้องอยู่กับ Hetzner อยากรู้ว่าควรย้ายไป Cloudflare Pages ได้ทั้งหมดหรือไม่

    • แผ่น tile ต้องมีขั้นตอน render ก่อน ตรงที่มีการใช้ซ้ำบ่อยก็ถูก cache แล้ว และงาน cache นี้น่าจะตกกับ Cloudflare ในทางปฏิบัติทฤษฎีอาจ port tileserver ไป Cloudflare Pages ได้ แต่สุดท้ายต้องทำการ porting เอง และอาจไม่ประหยัดต้นทุนมากขึ้นด้วย

  • การจำกัดตาม Referrer ดูเป็นตัวเลือกที่ประหลาด ถ้าผู้ใช้ปกติขอข้อมูล 10~20 ครั้งต่อนาที ตั้งลิมิต 100 คำขอต่อนาทีต่อ IP (สูงกว่าเฉลี่ย 5 เท่า) ควรจะป้องกันได้ส่วนใหญ่แล้วใช่ไหม? หากเป็นผู้ใช้ที่มีเจตนาไม่ดีไม่มากก็อาจยั้งด้วยการ match รูปแบบ JA4/JA3 ได้ใช่ไหม

    • ก็มีคนที่อยากสำรวจโลกทั้งลูกโลกได้จริงๆ มันมีได้เหมือนกัน ผมเคยใช้ Google Earth ตั้งครึ่งวันที่แล้ว เลยคิดว่าการปิดกั้นตาม referrer ดีกว่า (แล้วแนะนำให้ผู้ใช้ที่ใช้ทราฟฟิกสูงมาทำ self-host แทนการใช้ public instance)

    • การจำกัดผ่าน referrer เป็นขั้นแรกที่ดี (อาจต้องแก้ข้อความแจ้งบนหน้าแรก) การติดตามปริมาณการใช้ตามระดับเว็บไซต์น่าจะมีผลมากกว่า สามารถขอให้ไซต์ปรับพฤติกรรมการใช้งานได้ แต่ระดับผู้ใช้รายบุคคลทำได้ลำบาก เพิ่มการจำกัดตาม IP ก็เป็นเรื่องดี แต่หากตั้งต่ำเกินไป ก็ไม่ค่อยได้ผลในบางกรณีนี้

  • คิดว่าปิดกั้นได้ค่อนข้างดีมาก นี่คือการโจมตีแบบ DDoS ดีที่ไม่ได้มีค่าแบนด์วิดท์เพิ่มเฉพาะทาง ถ้าไม่อย่างนั้นคงเป็นการโจมตีแบบทำให้กระเป๋าเปลืองอย่างแท้จริง

  • อัตรา cache hit สูงมาก อยากรู้ว่ามีเทคนิคเฉพาะตัวอะไรถูกใส่เพิ่มไหม

    • ผมออกแบบทั้งโครงสร้าง path และ location block โดยคำนึงถึง caching โดยตรง ถ้าสนใจลองดู ตัวอย่าง nginx.conf ได้