ארכיטקטורת Scraping למיליוני דפים ביום

למה ארכיטקטורת ה-"סקריפט על שרת" נשברת בסקייל?

כולנו התחלנו שם. סקריפט פייתון קטן שרץ על שרת EC2 קטן, פעם ביום עם cron job. הוא שומר נתונים לקובץ CSV או אולי לבסיס נתונים SQLite. זה עובד נהדר. עד שזה לא.

המעבר מ-10,000 דפים ביום ל-100,000 הוא לא קפיצה לינארית. המעבר למיליון דפים ביום הוא שבר מוחלט. הגישה המונוליטית קורסת תחת העומס. כתובת ה-IP היחידה של השרת נשרפת תוך שעות. הזיכרון מתמלא מדפדפנים זוללי משאבים שרצים במקביל. ה-cron job רץ יותר מ-24 שעות, והריצה של מחר מתחילה לפני שהריצה של היום הסתיימה. זה לא סקייל, זו קטסטרופה בהמתנה.

נתקלתי בזה יותר מדי פעמים. מערכת שעבדה יפה במשך חודשים פשוט נעצרת. הלקוח שואל איפה הדאטה, ואתה מוצא את עצמך מנסה לדבג תהליך שתקוע באמצע הלילה, רק כדי לגלות שנחסמת על ידי Cloudflare או שנגמר לך המקום בדיסק. זה הרגע שבו מבינים שצריך ארכיטקטורה אמיתית, כזו שנבנתה מראש לצמיחה.

עקרונות הליבה של מערכת Scraping מודרנית

כדי לבנות מערכת שתעמוד ב-10 מיליון בקשות ביום ותמשיך לעבוד, אנחנו צריכים לאמץ כמה עקרונות בסיסיים שכל מערכת מבוזרת נשענת עליהם:

• Decoupling (הפרדת רכיבים): כל חלק במערכת צריך להיות עצמאי ולא תלוי באופן הדוק באחרים. הוספת המשימות לתור לא צריכה לדעת כלום על איך ה-worker מבצע אותן. ה-worker לא צריך לדעת איך הנתונים יאוחסנו בסוף. ההפרדה הזו מאפשרת לנו לשנות ולהרחיב כל רכיב בנפרד.
• Stateless Workers (עובדים חסרי מצב): כל worker (התהליך שמבצע את ה-scraping בפועל) צריך להיות טיפש. הוא מקבל משימה, מבצע אותה, ומחזיר תוצאה. הוא לא שומר שום מידע בין משימות. זה המפתח ל-scalability אופקי. אם אנחנו צריכים יותר כוח, אנחנו פשוט מרימים עוד 200 workers זהים. אם אחד מהם קורס, לא קרה כלום. אחר יקח את המשימה שלו.
• Asynchronous Operations (פעולות אסינכרוניות): שום דבר לא צריך לחכות. שליחת בקשת רשת היא פעולה איטית. בזמן שה-worker מחכה לתשובה מהשרת, הוא יכול לעבוד על דברים אחרים. ספריות מודרניות כמו `httpx` או `Playwright` בנויות סביב `asyncio` בפייתון ומאפשרות יעילות מקסימלית.

העקרונות האלה הם לא תיאוריה. הם הבסיס הפרקטי למערכת שלא תעיר אותך באמצע הלילה.

ה-Stack המנצח: רכיב אחר רכיב

בואו נפרק את הארכיטקטורה לגורמים. זה ה-blueprint שאני חוזר אליו פעם אחר פעם, עם התאמות קלות, והוא פשוט עובד.

תזמור (Orchestration): Kubernetes לשלטון

לנהל מאות או אלפי workers ידנית זה בלתי אפשרי. Kubernetes (או K8s בקיצור) הוא הכלי המושלם למשימה. אנחנו מגדירים "Deployment" של ה-worker שלנו, והוא דואג להריץ כמה עותקים (pods) שאנחנו צריכים. היתרון המרכזי הוא Autoscaling. אנחנו יכולים להגדיר חוק פשוט: "אם עומק התור ב-Redis גדול מ-10,000 משימות, הוסף עוד pods, עד למקסימום של 500". כשהתור מתרוקן, K8s מכבה אותם אוטומטית. זה מבטיח שאנחנו משתמשים במשאבים רק כשאנחנו צריכים אותם.

תור המשימות (The Queue): Redis כמרכז העצבים

כל משימת scraping מתחילה כהודעה בתור. Redis הוא הבחירה הטבעית כאן בגלל המהירות הפנומנלית שלו. אנחנו לא משתמשים בתור פשוט (LIST), אלא ב-Sorted Sets. למה? כי זה מאפשר לנו ליצור תור עדיפויות. משימות של לקוח חשוב יותר יקבלו ציון (score) נמוך יותר ויטופלו קודם. משימות גילוי (discovery) יכולות לחכות. זה נותן לנו שליטה מלאה על זרימת העבודה.

import redis

# Connect to Redis
r = redis.Redis(host='localhost', port=6379, db=0)

# Add a high-priority job (score=1)
job_data = {'url': 'https://example.com/product/123', 'target': 'example_com'}
r.zadd('scraping_queue', {json.dumps(job_data): 1})

# Add a low-priority job (score=10)
job_data_low = {'url': 'https://example.com/category/all', 'target': 'example_com_discovery'}
r.zadd('scraping_queue', {json.dumps(job_data_low): 10})

העובדים (The Workers): פייתון, Playwright ו-Headless Browsers

ה-worker הוא סקריפט פייתון שמסתובב בלולאה אינסופית: קח משימה מהתור, בצע, דווח, וחזור. למטרות פשוטות שמחזירות JSON, ספריית `httpx` עם תמיכה ב-HTTP/2 היא בחירה מעולה ומהירה. כשהאתר מורכב, מריץ JavaScript, ומוגן במערכות זיהוי בוטים, אין מנוס משימוש בדפדפן אמיתי. כאן Playwright עם תוספי stealth נכנס לתמונה. הוא מאפשר לנו להיראות כמו משתמש אנושי, לעבור אתגרים, ולקבל את ה-HTML הסופי. הכל רץ בתוך קונטיינר דוקר, מה שמבטיח סביבה נקייה לכל משימה.

ניהול רשת ו-Proxies

בסקייל של מיליוני בקשות, אי אפשר להשתמש ב-IP אחד. המערכת צריכה אינטגרציה עמוקה עם ספק פרוקסי. לכל worker יש גישה למאגר של proxies, והוא מבצע רוטציה ביניהם. הסוג החשוב ביותר הוא residential proxies, שמאפשרים לנו להיראות כמו משתמשים ביתיים מרחבי העולם. המפתח הוא לנהל את ה-session. אם אנחנו צריכים לבצע מספר בקשות לאותו אתר כאילו אנחנו אותו משתמש, ה-worker צריך להשתמש באותו IP לכל הבקשות בסשן.

אחסון נתונים (Data Persistence): Postgres ו-S3

אחסון הוא נקודה קריטית. הטעות הנפוצה היא לדחוף הכל לבסיס נתונים יחיד. הגישה הנכונה מפרידה בין סוגי המידע:

• PostgreSQL: שומר את המטא-דאטה. סטטוס של כל משימה (המתנה, רצה, הצלחה, כישלון), התוצאות המובנות (structured data) שחילצנו, ומידע לוגיסטי. בסיס הנתונים צריך להישאר רזה ומהיר.
• Amazon S3 (או כל Object Storage): שומר את ה-artefacts הגדולים. קוד ה-HTML המלא של הדף, צילומי מסך, קבצי HAR. ב-Postgres אנחנו שומרים רק מצביע (pointer) לאובייקט ב-S3. זה מונע ניפוח של בסיס הנתונים ושומר על ביצועים גבוהים.

אירועים ו-Monitoring: Kafka ו-Prometheus

איך יודעים מה קורה במערכת עם 10,000 חלקים נעים? אנחנו צריכים נראות (observability). כל worker, בסוף כל משימה, שולח אירוע ל-Kafka. האירוע מכיל את ה-URL, סטטוס הסיום (למשל, `SUCCESS`, `FAILURE_429`, `CAPTCHA_DETECTED`), כמה זמן זה לקח, ובאיזה פרוקסי השתמש. הזרם הזה הוא מכרה זהב. הוא מאפשר לנו לבנות דשבורדים, להפעיל התראות, ולנתח ביצועים. לדוגמה, אם אנחנו רואים עלייה פתאומית באירועי `FAILURE_429` ממטרה מסוימת, אנחנו יודעים שנתקלנו ב-rate limiting וצריך להאט את הקצב. זה המקום ללמוד איך לטפל בשגיאות 429 ו-rate limiting בצורה חכמה.

במקביל, Prometheus אוסף מדדים טכניים: עומק התור ב-Redis, עומס ה-CPU על ה-workers, שימוש בזיכרון. Grafana מציג את הכל בדשבורד אחד שנותן לנו תמונת מצב מלאה בזמן אמת.

הכלכלה של הסקייל: איך עוקבים אחרי עלויות?

כשהמערכת רצה בסקייל, העלויות יכולות לצאת משליטה. פרוקסי, כוח מחשוב, אחסון – הכל עולה כסף. אחת הטעויות הגדולות היא לא למדוד עלות פר מטרה (per-target). הדרך הנכונה היא להוסיף תג (tag) לכל משימה עם מזהה המטרה או הלקוח. לאחר מכן, במערכת האירועים (Kafka), אנחנו יכולים לאגרגט את צריכת המשאבים – כמה CPU time, כמה bandwidth של פרוקסי, כמה שטח אחסון – לכל תג. זה מאפשר לנו לדעת בדיוק כמה עולה לנו כל פרויקט, לתמחר נכון, ולזהות פרויקטים לא רווחיים.

איפה הארכיטקטורה הזו היא Overkill?

בואו נהיה כנים. הארכיטקטורה הזו היא פטיש 5 קילו. אם כל מה שאתה צריך זה למסמר תמונה לקיר, זה הכלי הלא נכון. אם אתה עושה scraping לאתר אחד, 50,000 דפים בחודש, המערכת הזו היא מורכבות מיותרת. סקריפט פשוט על שרת וירטואלי עם Scrapy או `requests` יעשה את העבודה מצוין. המורכבות של K8s, Kafka ו-Redis מגיעה עם עלות – זמן פיתוח, תחזוקה, וידע נדרש. צריך לדעת מתי הבעיה גדולה מספיק כדי להצדיק את הפתרון. הגבול, מניסיוני, נמצא איפשהו סביב ה-100,000 עד 200,000 דפים ביום. מתחת לזה, אפשר להסתדר עם פתרונות פשוטים יותר. מעל זה, הכאב של גישה מונוליטית מתחיל לעלות על עלות ההקמה של מערכת מבוזרת.

מבט לעתיד: מה הלאה?

המערכת שתוארה כאן היא חזקה ויציבה, אבל התחום לא עוצר. אנחנו רואים יותר ויותר שימוש ב-AI ו-LLMs בתוך תהליך ה-scraping עצמו – לא רק לחילוץ נתונים מטקסט לא מובנה, אלא גם להבנת מבנה הדף באופן דינמי. במקום לכתוב selectors ידניים, מודל שפה יכול "להסתכל" על הדף ולהחזיר את פיסות המידע הרלוונטיות. זה עדיין בחיתוליו ודורש כוח מחשוב רב, אבל זה הכיוון. ארכיטקטורה מבוזרת כמו זו היא הבסיס המושלם לשלב יכולות כאלה בעתיד, על ידי הוספת worker מסוג חדש: AI-based extractor.