המדריך השלם ל-Web scraping חוקית, יעילה וחסכונית | גיקטיים

מאת גדעון לב אלי, מומחה Web scraping, מנהל קהילות מפתחים ויועץ בתחום Web Data

כל מפתח פייתון שיחק לפחות פעם אחת עם ספריית BS4 ,Requests או Scrapy ובנה אלגוריתם ל-Web scraping מאתר פופולרי כלשהו. כשאנחנו קוצרים מידע מכמה דפים בודדים, כחלק מלימוד או פרויקט חד פעמי, שאלת העלות-תועלת אינה קריטית ולא חייבים לבחון את כל הרכיבים בתשתית קצירת המידע שלנו. אך כשמידע מהרשת הוא מרכיב חיוני עבור חברה, נדרשת בחינה מעמיקה של המרכיבים הדרושים להצלחה והיתכנות כלכלית של התשתית כולה.

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

מודל In-house: את המודל הזה מובילים המפתחים, ואלו המרכיבים העיקריים בו: בנייה מאפס של כמעט הכל, באמצעות צוות אחד לפחות (לרוב שניים) של מפתחות ומפתחים ברמת מומחיות יחסית גבוהה, שימוש ברשתות פרוקסי יחסית פשוטות, תחזוקה שוטפת של האלגוריתמים, התשתית (אחסון, עיבוד, שרתים) והממשקים ביניהם. מודל זה מאפשר שליטה ברמה גבוהה ותאימות כמעט מוחלטת.

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

מודל Data as a Service: במודל זה רוכשים דאטה מוכן, ומובילים אותו אנשי הדאטה – ללא צורך במפתחים או במומחיות גבוהה בקצירת מידע. הוא דורש ניהול אחסון בלבד ומאפשר גישה ישירה לשירותי מידע קיימים באיכות גבוהה, ללא עיכובי תשתית ובאגים בפיתוח.

ישנם הרבה שיקולים בבחירת מודל עבודה, הקשורים באופי החברה, המשאבים שלה (צוות, תשתית ותקציב) ורמת התלות שלה בדאטה מהרשת. הדילמות שאפרט במאמר זה רלוונטיות בעיקר לחברות שעונות להגדרה של המודל ההיברידי או ה-In-house ועוסקות בכל מה שקשור לתשתית קצירת מידע. חברות אלה לרוב עוסקות בקצירה מאסיבית של מידע בזמן אמת (אחרת לא היו משקיעות משאבים בפיתוח), מה שמוביל אותנו לשאלה: מה באמת קורה כאשר אנחנו קוצרים מידע בכמויות גדולות?

האתגרים בקצירת מידע ולמה צריך רשת פרוקסי

לפני שנצלול, אדגיש נקודה חשובה: אנחנו עוסקים כאן בקצירת מידע ציבורי מאתרים – כלומר, מידע נגיש וזמין לכל הגולשים ולמנועי החיפוש, שאינו מוגן באמצעות שם משתמש וסיסמה. קצירת מידע ציבורי ברשת היא חוקית לחלוטין, כפי שנקבע על בסיס כמה תקדימים משפטיים בשנים האחרונות, בהם מטא נגד ברייט דאטה (כן, זה אנחנו), לינקדאין נגד HIQ ועוד.

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

• סוג כתובת IP ממנה גולש המשתמש
• מיקום כתובת ה-IP
• תדירות הבקשות למידע שאותה כתובת שולחת
• קבלת מידע על הדפדפן ממנו מתבצעת הגלישה ו-Browser fingerprinting של המשתמש
• האם הגולש נמצא באינטראקציה עם אלמנטים בדף שהוא לא אמור לראות

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

רשתות פרוקסי שמורכבות מכתובות IP ביתיות (Residential Proxies) הפכו לסטנדרט בקצירת מידע (Web Scraping) ציבורי מאתרי מסחר ורשתות חברתיות. יש לכך כמה סיבות:

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

הקאץ', כמובן, הוא העלות הגבוהה של שימוש בכתובות אלה. לשם השוואה, גישה לרשת פרוקסי כזאת דרך חברת SOAX בשימוש כולל של 100GB (מחושב באמצעות תעבורת המידע הנקרא בעת השימוש ברשת) הוא 5.68 דולר ל-GB. זאת לעומת 0.65 דולר ל-GB בשימוש כולל זהה ברשת שמורכבת מכתובות Data Center. בשני המקרים מדובר במחירים כמעט ממוצעים לשוק (המידע באדיבות Proxyway).

כאן נכנס לתמונה מאזן שיקולים נוסף: הצורך באנונימיות (כלומר, הסוואה של משתמש רגיל) מול הצורך במהירות תעבורת נתונים. כתובות Data center מנוהלות על ידי חוות שרתים מהירות במיוחד. לעומת זאת, כתובות של משתמשים רגילים יכולות לשבת על גבי סמארטפון, טלוויזיה חכמה ומחשב לפטופ, כאשר הם מחוברים ברשת אלחוטית או קווית של מודם ביתי (לא תמיד דרך סיבים) ולא מאפשרים הורדה מהירה של מידע מאתרים ברשת.

כך תבחרו רשת פרוקסי שלא תרושש אתכם

הגרף הבא מציג ארבע סוגי רשתות פרוקסי אפשריים. העלות מיוצגת בציר ה-Y ומהירות הורדת המידע מיוצגת בציר ה-X.

ניתן להסתכל באופן גס על 4 רמות:

• רמה ראשונה (הכי אפקטיבית ביחס למחיר): שימוש בפרוקסי Data Center דרך API. שליחת פקודת get פשוטה מחזירה מהאתר HTML. אם אנחנו מצליחים לקבל מידע באופן עקבי מהאתר בשיטה הזאת, זהו החיסכון האולטימטיבי. כל פקודה כזאת שוקלת בערך 400KB, וכפי שראינו – 1GB של תעבורת נתונים דרך הכתובות האלה הוא ממש זול.
• רמה שנייה: שימוש ב-DC עם דפדפן Headless browser. שימוש ב-API לא עובד טוב מספיק באתרים מסוימים, מה שמאלץ אותנו להשתמש בדפדפן אוטומטי כגון Puppeteer או Selenium על מנת לקבל מידע מהאתר. זה קורה לרוב במקרים שבהם נדרשת אינטראקציה עם אלמנטים מסוימים בדף כדי לקבל מידע או כדי לבצע JavaScript Rendering.
• רמה שלישית: שימוש ב-Residential פרוקסי דרך API. השיטה הזאת מתאימה לאתרים שבהם מספיק להשתמש ב-API call פשוט, אך תוכנות ההגנה מפני בוטים חוסמות כתובות מסוג DC שממוספרות בצורה שיטתית. ננסה להתגבר על כך באמצעות שימוש בכתובות משתמשים ביתיות שמקבלות "ניקוד" גבוה יותר ולא נחסמות.
• רמה רביעית (והכי יקרה): שימוש ב-Residential פרוקסי דרך דפדפן. כשאנחנו מתמודדים עם אתר מורכב שבו המידע מוגן בצורה קיצונית, ניתן לעבוד איתו רק בצורה שאינה מיטבית עבורנו מבחינת עלות-תועלת. אבל לפעמים המידע הזה כל כך חיוני עבור העסק שלנו, שהעלות הזאת היא חלק מהמשוואה. השיטה הזאת איטית יחסית, שכן הדפדפן עובד לאט (אפילו במצב Headless) וטוען הרבה מרכיבים באתר לפני שהוא מקבל את המידע. גם כתובות ה-Residential נמצאות על שרתים של מכשירי קצה (סמארטפון, מחשב נייד, טלוויזיה חכמה וכדומה) ומודמים ביתיים, שעובדים הרבה יותר לאט מחוות השרתים המקצות את כתובות ה-DC.

אבל חשוב לא להישאר ברמת הדיון התיאורטי: הדרך הכי טובה לבחור רשת פרוקסי היא פשוט לבחון בפועל את ההבדל בין שימוש בכתובת DC לכתובת Residential. לדוגמה, העתיקו את כתובת ה-URL של הדף ממנו אתם מעוניינים לקצור מידע. אם אתם משתמשי כרום, פיתחו את תפריט הגדרות proxy settings במחשב שלכם (משתמשי firefox ימצאו תפריט בתוך הגדרות הדפדפן). ב-manual proxy setup בחרו use a proxy server והכניסו את כתובת שרת הפרוקסי של ספק רשת הפרוקסי שאתם מנויים אליו, ואת מספר ה-port כפי שמוגדר במנהל הפרוקסי של אותו ספק. שימו לב שצריך לבחור מספר port המשויך לכתובת DC (מסוג Random או Single session).

הדביקו את כתובת ה-URL בשורת הכתובת של הדפדפן ונסו לגלוש אליה (שימו לב: יכול להיות שתידרשו להזין שם משתמש וסיסמה של שרת הפרוקסי).

אם אתם מקבלים הודעת שגיאה – 403 לדוגמה – והדף לא נטען, סימן שהאתר מזהה וחוסם כתובות מסוג זה. במקרה כזה תצטרכו להתחיל להשתמש בכתובת Residential proxy. גם אותה כדאי לבדוק באמצעות שינוי מספר ה-port בהגדרות הפרוקסי במחשב או בדפדפן, באמצעות העתקתו מלוח הבקרה של שרת הפרוקסי שלכם.

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

פעולות נוספות שיחסכו לכם כסף בקצירת מידע

ישנן שלוש פעולות נוספות שמומלץ לעשות בקוד שלכם על מנת לחסוך כסף:

1. עצרו את טעינת הדף באתר מיד לאחר שכל המידע שאתם מעוניינים בו מופיע (כותרת, מחיר מוצר, תיאור וכדומה). כך תחסכו רוחב פס קריטי, שלרוב משפיע על מחיר השימוש בפרוקסי.

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

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

בנוסף, אל תוותרו על השוואה בין תוכניות ומנויים לשירותי פרוקסי וקצירת מידע. חשוב להעמיק בזה לפני שאתם בוחרים או מחליפים ספק של רשת פרוקסי. חלק מהתוכניות מתומחרות לפי רוחב פס המידע הנטען, וחלק לפי מספר בקשות (requests) הנשלחות דרך כתובות ה-IP של רשת הפרוקסי. זה יכול להיות קצת טריקי, אבל ניתן לבצע חישוב גס כדי להשוות בין תוכניות. והנה עוד טיפ: אל תחששו מתוכניות שדורשות התחייבות לטווח ארוך. היא עשויה להיתרגם לחיסכון של מאות ואלפי דולרים, אותם תוכלו להשקיע במקומות אחרים (אחסון, QA).

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

לא נגעתי כאן בטקטיקות מתקדמות שנועדו להתגבר על מערכות הגנה משופרות כנגד בוטים, המותקנות בחלק מהאתרים. ניתן למצוא הסברים מעמיקים עליהן במאמרים, סרטוני יוטיוב וקהילות מתכנתים באתרים כגון Github, Stackoverflow, reddit ואפילו Discord. הטקטיקות האלה משפיעות גם על יעילות התהליך, שכן כל מרכיב משפיע על קצב קצירת המידע (מספר הנסיונות שהאלגוריתם צריך לבצע עד שהוא מצליח, רוחב הפס ועוד).  אבל אם תבחרו את הפרוקסי הנכון למשימה, תנתחו ב-Dev tools מה האתר מבקש מהדפדפן כדי להיטען ותבצעו פעולות בסיסיות כמו הוספת Headers ו-Cookies לבקשות שלכם – מרבית האתרים לא יחסמו אתכם.

בהקשר זה חשוב לדעת שקיימות חברות המציעות תשתית לפיצוח מגננות נגד קצירת מידע, הנקראת Web Unlocking. ניתן לחבר אליה את האלגוריתם שלכם או להשתמש בדפדפן מיוחד, ולהשתמש במגוון יכולות מוגברות: רשת פרוקסי ביתי מהירה, ניהול של Headers ו-User agents של הדפדפן, פתירת CAPTCHA, רינדור של JS ועוד יכולות שעוזרות לאלגוריתם שלכם להיראות כמו כל משתמש אנושי רגיל המבקר באתר.

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