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

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

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

שומרים על קשרים פעילים

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

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

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

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

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

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

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

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

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

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

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

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

טיפול בעומס יתר בחן

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תגובה לפינגים

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

Google

id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true

פורמט JSON של OpenRTB

"id": "4YB27BCXimH5g7wB39nd3t"

OpenRTB Protobuf

id: "7xd2P2M7K32d7F7Y50p631"

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

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

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

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

  • לעומת זאת, כשמתקיים הסכם קישור בין רשתות שכנות (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, אבל מרווח הרענון לא ודאי.