שיטות מומלצות לאפליקציות לבידינג בזמן אמת (RTB)

במדריך הזה מפורטות שיטות מומלצות שכדאי להביא בחשבון כשמפתחים אפליקציות בהתאם לפרוטוקול RTB.

ניהול החיבורים

שמירה על החיבורים

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

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

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

הימנעות מסגירת חיבורים

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

• הזמן הקצוב (בדקות) עד לכניסה למצב 'לא פעיל' הוא 2.5 דקות.
• מספר הבקשות המקסימלי בחיבור לערך הגבוה ביותר האפשרי.
• מספר החיבורים המקסימלי הוא הערך הגבוה ביותר שזיכרון ה-RAM יכול להכיל, תוך הקפדה על כך שמספר החיבורים לא יתקרב לערך הזה יותר מדי.

ב-Apache, לדוגמה, צריך להגדיר את KeepAliveTimeout לערך 150, את MaxKeepAliveRequests לערך אפס ואת MaxClients לערך שמשתנה בהתאם לסוג השרת.

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

איך שומרים על איזון החיבורים

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

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

1. אם אתם משתמשים בשרתי proxy לקצה קדמי, עליכם לבחור את הקצה העורפי לכל בקשה ולא פעם אחת לכל חיבור.
2. צריך לציין מספר מקסימלי של בקשות לכל חיבור אם אתם משתמשים בשרת proxy לחיבורים דרך מאזן עומסים או חומת אש לחומרה, והמיפוי קבוע אחרי שהחיבורים נוצרים. חשוב לזכור ש-Google כבר מציינת מגבלה עליונה של 10,000 בקשות לכל חיבור, כך שצריך לספק ערך מחמיר יותר רק אם עדיין מוצאים קשרים חמים שמצטברים בסביבה. ב-Apache, לדוגמה, מגדירים את MaxKeepAliveRequests לערך 5,000
3. צריך להגדיר את השרתים של המגישים לבדיקת שיעורי הבקשות שלהם ולסגור חלק מהחיבורים שלהם אם הם מטפלים באופן קבוע במספר גדול מדי של בקשות בהשוואה למגישים אחרים.

טיפול יעיל בהתקפי עומס

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

כדי להתאים לשינויים זמניים בתנועה (עד שבוע) בין אזורים (במיוחד בין אסיה וארה"ב המערבית לבין ארה"ב המזרחית וארה"ב המערבית), מומלץ להגדיר מרווח של 15% בין השיא של 7 הימים לבין קצב הבקשות לשנייה לכל מיקום מסחר.

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

המגיש הצעות המחיר מסוג 'תגובה לכל'

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

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

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

המגיש של הצעת המחיר 'שגיאה בעומס יתר'

המשתתף במכרז הזה מקבל קריאות לפעולה עד שיעור מסוים, ואז מתחיל להחזיר שגיאות לגבי חלק מהקריאות לפעולה. אפשר לעשות זאת באמצעות זמן קצוב לתפוגה פנימי, השבתת תורים של חיבורים (שנשלט על ידי ListenBackLog ב-Apache), הטמעת מצב ירידה פרובובלסטית כשהשימוש או זמני האחזור גבוהים מדי, או מנגנון אחר כלשהו. אם Google תזהה שיעור שגיאות גבוה מ-15%, נתחיל לבצע ויסות נתונים. בניגוד למגיש הצעות המחיר שמגיב לכל בקשה, מגיש הצעות המחיר הזה 'מקטין את ההפסדים', מה שמאפשר לו להתאושש באופן מיידי כששיעורי הבקשות יורדים.

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

המשתמש שמגדיר את האפשרות 'ללא הצעת מחיר במצב עומס'

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

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

מומלץ לשלב את הגישה 'שגיאה במקרה של עומס יתר' עם הגישה 'ללא בידינג במקרה של עומס יתר', באופן הבא:

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

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

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

כדאי לשקול קישור בין רשתות שכנות (peering)

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

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

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

שליחת DNS סטטי

אנחנו ממליצים לקונים לשלוח תמיד תוצאת DNS סטטית אחת ל-Google ולהסתמך על Google לטיפול בהעברת התנועה.

ריכזנו כאן שתי שיטות נפוצות של שרתי ה-DNS של המגישים במכרזים כשהם מנסים לאזן את העומס או לנהל את הזמינות:

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

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

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

אם מציע מחיר מבצע שינוי ב-DNS, Google תכבד את TTL(משך החיים) שהוגדר ברשומות ה-DNS שלו, אבל פרק הזמן לרענון עדיין לא ברור.