- แชร์ประสบการณ์จริงในการครอว์ล 1 พันล้านเว็บเพจ ภายใน 24 ชั่วโมง และกระบวนการออกแบบ ระบบเว็บครอว์ลิงสมัยใหม่
- ใช้ฮาร์ดแวร์และโครงสร้างพื้นฐานคลาวด์ล่าสุดเพื่อทำครอว์ลิงขนาดใหญ่ได้ด้วยงบเพียง ไม่กี่ร้อยดอลลาร์ พร้อมยืนยันว่าคอขวดหลักคือ การพาร์ส
- แม้จะไม่รัน JavaScript และทำเพียง การพาร์ส HTML แต่ก็ยังเข้าถึงเว็บเพจจำนวนมากได้
- ออกแบบสถาปัตยกรรม คลัสเตอร์โหนด บน Redis และเพิ่มประสิทธิภาพสูงสุดด้วย การชาร์ดตามโดเมน และโครงสร้างโปรเซสที่เหมาะสม
- พบว่า CPU·SSL·หน่วยความจำ เป็นคอขวดหลักมากกว่า เครือข่าย และการจัดการ frontier ของโดเมนขนาดใหญ่เป็นประเด็นสำคัญ
นิยามปัญหา
- ตั้งเป้าหมาย ครอว์ล 1 พันล้านเว็บเพจ ภายใน 24 ชั่วโมง
- งบประมาณ อยู่ที่ไม่กี่ร้อยดอลลาร์ (สุดท้ายประมาณ 462 ดอลลาร์) โดยตั้งให้ใกล้เคียงกับ กรณีศึกษาในปี 2012
- เก็บเฉพาะ HTML โดยไม่รัน JavaScript และดึงเฉพาะลิงก์จาก
<a>
- ให้ความสำคัญกับ Politeness (การครอว์ลอย่างมีมารยาท): ปฏิบัติตาม robots.txt, ระบุ User Agent, ยกเว้นโดเมนเมื่อมีการร้องขอ, จำกัดเป้าหมายไว้ที่ 1 ล้านโดเมนยอดนิยม, เว้นช่วง 70 วินาทีกับโดเมนเดียวกัน เป็นต้น
- มี ความทนทานต่อความขัดข้อง: เมื่อโหนดล้มเหลวสามารถรีสตาร์ตได้ และยอมรับการสูญหายของข้อมูลบางส่วน โดยใช้แนวทางแบบสุ่มตัวอย่าง
สถาปัตยกรรมและการออกแบบ
- ต่างจากแนว การออกแบบระบบแบบสัมภาษณ์ทั่วไป (แยกตามฟังก์ชัน) โดยเลือกโครงสร้างที่ แต่ละโหนดจัดการทุกหน้าที่เอง เช่น สถานะการครอว์ล การพาร์ส การดึงข้อมูล การจัดเก็บ เป็นต้น
- ใช้ 12 โหนด โดยแต่ละโหนดเป็นอินสแตนซ์
i7i.4xlarge (16 vCPU, RAM 128GB, 10Gbps, สตอเรจ 3750GB)
- แต่ละโหนดประกอบด้วย Redis 1 ตัว, fetcher 9 ตัว, และ parser process 6 ตัว
- ใน Redis เก็บ frontier แยกตามโดเมน, fetch queue, URL ที่เยี่ยมชมแล้ว, Bloom filter, robots.txt, คิวพาร์ส เป็นต้น
- Fetcher: ดึง URL จากคิวแยกตามโดเมนแล้ว fetch โดยใช้ asyncio ทำงานพร้อมกัน 6000~7000 งาน คอขวดหลักคือ CPU
- Parser: มี async worker 80 ตัว ทำงานพาร์ส HTML และดึงลิงก์ เป็นงานที่ใช้ CPU เป็นหลัก
- สตอเรจ: เลือกใช้สตอเรจภายในอินสแตนซ์แทน S3 เพื่อลดต้นทุนการเก็บเพจขนาดใหญ่
- การชาร์ด: กระจายโดเมนไปยังแต่ละโหนด (ไม่มีการสื่อสารข้ามกัน) และปรับจำนวนโหนดสำหรับการชาร์ดเพื่อแก้ปัญหาความไม่สมดุลของโดเมนยอดนิยม
ทางเลือกหลักและการทดลอง
- ทดลองใช้สโตร์หลายแบบ เช่น SQLite, PostgreSQL และสุดท้ายพบว่า Redis ให้ประสิทธิภาพดีที่สุด
- เคยลองขยายแนวตั้ง (อินสแตนซ์ขนาดใหญ่เครื่องเดียว) แต่เจอคอขวดจากข้อจำกัดของซอฟต์แวร์ จึงตัดสินใจใช้โครงสร้างขยายแนวนอน (หลายโหนด)
- ตัดการสื่อสารข้ามโหนดออก และทำการประมวลผลแบบขนานภายในโหนดเดียว
บทเรียนสำคัญจากกระบวนการครอว์ลิง
การพาร์สคือคอขวดที่ใหญ่ที่สุด
- ขนาดเฉลี่ยของเพจใหญ่ขึ้นมากเมื่อเทียบกับอดีต (ปี 2012 เฉลี่ย 51KB) โดยตอนนี้เฉลี่ย 242KB และค่ามัธยฐาน 138KB
- เมื่อเปลี่ยนจาก lxml เป็น selectolax (บน Lexbor) ความเร็วในการพาร์สดีขึ้นอย่างมาก
- ปรับปรุงประสิทธิภาพด้วยการตัดขนาดเพจสูงสุดไว้ที่ 250KB
- สุดท้าย parser เดี่ยวพาร์สได้ 160 เพจต่อวินาที และปรับอัตราส่วน fetcher:parser เป็น 9:6 จนประมวลผลได้ราว 950 เพจต่อวินาที
Fetching: ทั้งสิ่งที่ง่ายขึ้นและยากขึ้น
- แบนด์วิดท์เครือข่าย กลับไม่ใช่คอขวด (ใช้เพียงราว 8Gbps จาก 25Gbps ต่อโหนด)
- DNS ก็ไม่เป็นปัญหา เพราะจำกัดเป้าหมายไว้ที่โดเมนยอดนิยมเท่านั้น
- ในทางกลับกัน SSL handshake กลายเป็นหนึ่งในคอขวดใหญ่ที่สุด คิดเป็น 25% ของการใช้ CPU ทั้งหมด
- เมื่อเว็บส่วนใหญ่เปลี่ยนมาใช้ HTTPS ต้นทุนฝั่ง CPU จึงเพิ่มขึ้น
การรันครอว์ลจริงและปัญหาที่พบ
- ในการทดลองช่วงแรก ใช้โหนดเดียว (
i7i.2xlarge) รันเพียงไม่กี่ชั่วโมง ก่อนจะขยายเป็น 12 โหนดในรอบครอว์ลจริง
- เกิดปัญหา หน่วยความจำ: frontier (URL ที่ยังไม่เคยเยี่ยมชม) ของโดเมนยอดนิยมโตถึงหลายสิบ GB จนโหนดล่มซ้ำ ๆ
- โดเมนยอดนิยม (เช่น yahoo.com, wikipedia.org) หรือเว็บที่มีลิงก์จำนวนผิดปกติเป็นต้นเหตุของปัญหา
- โดเมนที่มีปัญหาถูกตัดออกด้วยมือ และเมื่อเกิดความขัดข้องก็รีสตาร์ตโหนดพร้อมตัด frontier ให้สั้นลงเพื่อกู้ระบบ
เปรียบเทียบทฤษฎีกับภาคปฏิบัติ
- เมื่อนำไปเทียบกับการประเมินแบบตำราเดิมอย่าง "1 หมื่นล้านเพจใน 5 วันด้วยเครื่อง 5 เครื่อง" พบว่าตัวเลขจริงค่อนข้างใกล้เคียง
- เมื่อพิจารณาการใช้เครือข่ายและ CPU จริงของแต่ละโหนด หากปรับจูนได้ดีขึ้นก็ยังมีโอกาสเพิ่ม throughput ได้อีก
งานต่อไปและข้อคิด
- ยืนยันอีกครั้งว่า แม้พาร์สเฉพาะ HTML ก็ยังเข้าถึงเว็บเพจได้จำนวนมาก แต่แพลตฟอร์มขนาดใหญ่บางแห่ง (เช่น GitHub) มีเนื้อหาสำคัญอยู่ใน JS จึงพาร์สไม่ได้
- โจทย์ในอนาคตคือการสำรวจต้นทุนและวิธีการของ การครอว์ลขนาดใหญ่แบบเรนเดอร์ JS
- ยังกล่าวถึงการวิเคราะห์ข้อมูลต่อ เช่น เมทาดาทาของเพจที่เก็บได้จริง หรือสัดส่วนของเพจที่ยังใช้งาน/ไม่ใช้งานแล้ว
- ระยะหลังมี การครอว์ลเชิงรุก ที่ผสาน AI เพิ่มขึ้น ขณะเดียวกันก็มีระบบป้องกันใหม่อย่าง Cloudflare pay-per-crawl ทำให้สภาพแวดล้อมของเว็บครอว์ลิงกำลังเปลี่ยนแปลงอีกครั้ง
3 ความคิดเห็น
สุดยอดมาก..ปรบมือรัวๆ...
น่าสนใจมากครับ อ่านแล้วได้ประโยชน์ดี ขอบคุณครับ
สุดยอดมาก.. นี่คือการต่อสู้ระหว่างหอกกับโล่สินะ 555