טיפול בשגיאות רשת ב-Web Scraping: המדריך המעמיק לשרידות

למה הגישה הנאיבית של "נסה שוב" פשוט לא עובדת

כולנו התחלנו שם. לולאת for פשוטה, try/except, ואם נכשל — מנסים שוב. זה נראה הגיוני בהתחלה, אבל זה מתכון לאסון בסקייל. למה? כי זה טיפש. זה לא מבדיל בין סוגי שגיאות. שגיאת DNS, שרת יעד שנפל (503), או שגיאת rate limit הן חיות שונות לגמרי. גישה נאיבית מתייחסת לכולן אותו דבר — ופשוט "מפציצה" את השרת שוב ושוב, מה שלפעמים רק מחמיר את הבעיה.

דמיין תרחיש: אתר נופל תחת עומס ומחזיר 503 Service Unavailable. מה עושה ה-scraper הנאיבי שלך? מנסה שוב. ושוב. ושוב. בפועל, אתה משתתף בהתקפת DDoS על שרת שכבר נאבק לנשום. זה לא יעיל, זה לא קולגיאלי, וזה בעיקר גורם לחסימת ה-IP שלך מהר יותר. אנחנו צריכים גישה מתוחכמת יותר.

אסטרטגיית ה-Retry שתשנה לכם את המשחק

במקום לנסות שוב באופן מיידי, אנחנו צריכים מדיניות חכמה שמבוססת על סוג השגיאה ומשתמשת בטכניקה שנקראת Exponential Backoff with Jitter.

הרעיון פשוט: אחרי כשלון ראשון, חכה שנייה. אחרי השני, חכה שתי שניות. אחרי השלישי, ארבע. ההמתנה גדלה באופן אקספוננציאלי. ה-"Jitter" הוא תוספת אקראית קטנה לזמן ההמתנה הזה, כדי למנוע מצב שבו כל ה-workers שלך מנסים שוב באותו זמן בדיוק ויוצרים עומס מחודש (Thundering Herd problem).

התאמת המדיניות לסוג השגיאה

לא כל שגיאה דורשת את אותה תגובה:

• שגיאות 5xx (בעיות צד-שרת): כמו 500, 502, 503, 504. אלו שגיאות זמניות בדרך כלל. כאן, exponential backoff הוא מושלם. 3-5 ניסיונות חוזרים עם המתנה גדלה זה סטנדרט טוב.
• שגיאות 429 (Too Many Requests): השרת אומר לנו מפורשות "אתם מהירים מדי". פה צריך להאט משמעותית. לעיתים קרובות, השרת אפילו יחזיר header בשם Retry-After עם מספר השניות שעלינו לחכות. חובה לכבד אותו. למידע נוסף, יש לנו מאמר שלם על טיפול בשגיאות 429 ו-rate limiting.
• שגיאות רשת (Connection Timeout, DNS Error): אלו יכולות להיות בעיות אצלנו, אצל ספק הפרוקסי, או בדרך. הן בדרך כלל מאוד זמניות. retry מהיר יחסית (אך עדיין עם backoff) הוא הגיוני כאן.

import time
import random

def retry_with_backoff(retries=5, backoff_in_seconds=1):
    def rwb(f):
        def wrapper(*args, **kwargs):
            attempts = 0
            while attempts < retries:
                try:
                    return f(*args, **kwargs)
                except Exception as e:
                    print(f"Attempt {attempts + 1} failed: {e}")
                    attempts += 1
                    if attempts == retries:
                        raise

                    sleep = (backoff_in_seconds * 2 ** (attempts - 1)) + \
                            random.uniform(0, 1)
                    print(f"Retrying in {sleep:.2f} seconds...")
                    time.sleep(sleep)
        return wrapper
    return rwb

@retry_with_backoff(retries=4, backoff_in_seconds=2)
def fetch_url(url):
    # Your request logic here, e.g., using requests or httpx
    print(f"Fetching {url}")
    # This will raise an exception to simulate failure
    import requests
    response = requests.get("http://this-url-does-not-exist.com")
    response.raise_for_status()
    return response

# Example usage
try:
    fetch_url("http://example.com")
except Exception as e:
    print(f"Request failed after all retries: {e}")

Circuit Breakers: להפסיק להרביץ לסוס מת

גם עם מדיניות retry חכמה, מה קורה אם שרת יעד ספציפי פשוט מת? או אם אחד מה-IPs ברשת הפרוקסים שלנו נחסם לצמיתות? אנחנו נמשיך לנסות שוב ושוב, נבזבז זמן, משאבים, ובעיקר כסף על בקשות שדינן להיכשל. הפתרון הוא Circuit Breaker.

כמו מפסק חשמל בבית, ה-Circuit Breaker מזהה כשיש "קצר" — כלומר, כשלונות חוזרים ונשנים מול יעד מסוים. אחרי מספר X של כשלונות רצופים (למשל, 10), המפסק "קופץ" (מצב Open). מרגע זה, למשך זמן מוגדר (נניח, 5 דקות), כל בקשה חדשה לאותו יעד תיכשל מיידית, בלי בכלל לנסות לצאת לרשת. זה חוסך לנו את כל המשאבים של הבקשה הכושלת.

אחרי 5 דקות, המפסק עובר למצב Half-Open. הוא יאפשר לבקשה אחת בודדת לעבור. אם היא מצליחה, המערכת מניחה שהשירות חזר לעצמו והמפסק נסגר (מצב Closed). אם היא נכשלת, הוא קופץ שוב ל-Open, אולי הפעם לזמן ארוך יותר. כלים כמו ספריית pybreaker בפייתון הופכים את המימוש לפשוט להפליא.

Dead Letter Queues (DLQ): אף בקשה לא נשארת מאחור

אז ניסינו שוב עם backoff, וה-circuit breaker פתוח. הבקשה נכשלה סופית. מה עכשיו? פשוט רושמים ללוג ושוכחים ממנה? ממש לא. כל בקשה שנכשלה היא דאטה פוטנציאלי שאבד.

כאן נכנס לתמונה ה-Dead Letter Queue (DLQ). זהו תור (Queue) ייעודי שאליו אנחנו שולחים כל בקשה שנכשלה בכל ניסיונות ה-retry. הבקשה הזו צריכה להכיל את כל המידע הדרוש לשחזור: ה-URL, ה-headers, ה-payload, וגם מטא-דאטה על הכשלון (סיבת הכשלון האחרון, מספר ניסיונות). כלים כמו RabbitMQ, SQS של אמזון, או אפילו רשימה פשוטה ב-Redis יכולים לשמש כ-DLQ.

היופי ב-DLQ הוא שהוא מפריד את תהליך איסוף הדאטה מתהליך הטיפול בשגיאות. פעם ביום, או כשהבעיה שגרמה לכשלונות נפתרה, אפשר להריץ תהליך נפרד שצורך את הבקשות מה-DLQ ומנסה אותן שוב. זה מבטיח 100% כיסוי דאטה, וזה קריטי במערכות סקרייפינג גדולות. בניית DLQ היא חלק בלתי נפרד מכל ארכיטקטורת סקרייפינג בסקייל רצינית.

Monitoring והתראות: לדעת שיש בעיה לפני הלקוח

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

אלו המדדים שאתה חייב לעקוב אחריהם:

• אחוז הצלחה כולל: היחס בין תגובות 2xx לכל השאר. צניחה פתאומית כאן היא דגל אדום.
• פיזור קודי שגיאה: האם יש קפיצה פתאומית בשגיאות 403? אולי נחסמת. קפיצה ב-502? אולי רשת הפרוקסים שלך בבעיה.
• Latency ממוצע ו-p95: אם זמן התגובה הממוצע קופץ, משהו לא בסדר.
• גודל ה-DLQ: אם התור מתחיל להתמלא במהירות, זה סימן לבעיה מערכתית שדורשת התערבות מיידית.

כלים כמו Prometheus ו-Grafana הם הסטנדרט בתעשייה לבניית דשבורדים כאלה. הגדר התראות אוטומטיות (למשל ב-Slack) על חריגות. למשל: "שלח התראה אם אחוז שגיאות ה-5xx עובר את 5% בחלון של 10 דקות". זה ההבדל בין לגלות בעיה בעצמך אחרי 10 דקות, לבין לקבל טלפון זועם מלקוח אחרי יומיים.

איפה כל זה נשבר? כשאתה מניח שהרשת אמינה

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

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

גם כשמשתמשים ברשתות הפרוקסי הכי טובות, כמו אלו שמוסברות במדריך ל-residential proxies, כשלונות הם חלק מהמשחק. שיעור כשלון של 1-3% הוא נורמלי לחלוטין. בסקייל של מיליון בקשות ביום, זה 10,000-30,000 כשלונות. בלי המנגנונים שתיארנו, זה דאטה שהולך לפח. לכן, בנייה מתוך ציפייה לכשל היא האסטרטגיה היחידה שעובדת בטווח הארוך.