פרק מספר 471 של רברס עם פלטפורמה, שהוקלט ב-30 באפריל 2024 - אורי ורן מארחים את גל ברק כדי לדבר על מלא (ממש מלא) נוטיפיקציות. גל עובד בחברת Plus500 - וגם דיבר לא מזמן בכנס רברסים האחרון {הנה ההקלטה - Real-time Market Event Notifications: Plus500's Scalable Fanout Architecture / Gal Barak).
(אורי) איך הייתה החוויה של לדבר בכנס?
- (גל) מדהימה. רציתי גם להגיד את זה - שאם יש איזה מישהו שמאזין ומתלבט האם להגיש לשנה הבאה, אז זו לגמרי חוויה מטורפת.
- זה גם היה כנס ראשון שדיברתי בו, כהרצאה. מדהים.
(אורי) עכשיו אתה עושה פרומו כאילו למודרטורים שלנו אין מספיק תכנים לעבור עליהם . . . .אבל הכל יתקבל בברכה.
(רן) אז תודה על המחמאות ותודה על זה שהיית - ובעצם המטרה שלנו היום זה קצת להרחיב, מעבר להרצאה שהייתה שם. אז זו לא חובת צפייה אבל מומלץ לצפות בהרצאה - ואחר כך גם להקשיב, או לעשות את זה בסדר ההפוך.
01:25 קצת על גל ו-Plus500
- (גל) אחלה. אז אני גל, עובד היום ב-Plus500, נשוי ואבא לשתיים במשרה מלאה.
- לפני שהתחלתי ב-Plus500, עבדתי גם קצת בתעשייה הביטחונית, אחרי שהשתחררתי מקבע.
- ועוד איזושהי גיחה לעולם המחקר, בעולמות של Computer Vision - קצת רחפנים אוטונומיים, שעלו לכותרות לא מעט בתקופה האחרונה, ובנסיבות פחות משמחות.
- ובעצם, בשלוש שנים האחרונות אני עובד ב-Plus500 ומוביל שם את תחום ה-Communication - נוטיפיקציות, כמו שאמרת.
- (גל) אז Plus היא בעצם קבוצת FinTech גלובאלית . . .
- (גל) לא, זה בקיצור - Plus500 זו קבוצת FinTech גלובלית, שבעצם מפתחת פלטפורמות שונות למסחר מקוון בשוק ההון.
- אנחנו חברת B2C, כלומר - המוצר משווק ללקוחות פרטיים.
- אנחנו היום עם למעלה מ-25 מיליון לקוחות, סדר גודל של חצי מיליון אקטיביים (Active Users) בכל רגע נתון.
- החברה עצמה הוקמה ב-2008, והיום היא בעצם חברה גלובלית - נסחרת בבורסה הראשית בלונדון, ואנחנו עם רישיון פעילות בלמעלה מ-50 מדינות, כולל אגב גם בישראל.
- הרגולטור, המפקח שלנו כאן בישראל, הוא הרשות לניירות ערך - ואני מניח שעוד ניגע בנושא הרגולציה בהמשך, כי זה מן הסתם משפיע גם על עולם הנוטיפיקציות (Notifications).
(רן) כלומר, מי שרוצה להשקיע בשווקי-ההון - זה המקום? או שיש פה איזשהו משהו יותר ספציפי?
- (גל) אז בגדול, רוב קהל-הלקוחות שלנו הוא בעצם מה שנקרא “Day Traders” - זאת אומרת, זה לא בהכרח אנשים שעכשיו קונים מדדים ושוכחים מהם.
- אנחנו בעצם זירת המסחר שמאפשרת את הפלטפורמות.
- (רן) בתרגום חופשי וממש לא מהימן - “Day Traders” הם כאלה שקונים במשך היום ומוכרים במשך היום, לא מחזיקים לאורך זמן.
- כלומר, כאלה שלפחות אמורים לדעת מה הם עושים - ועושים את זה מאוד במהירות. אוקיי.
- (אורי) רוצים לעשות את זה מאוד במהירות . . . .
- (רן) כן, זאת אומרת לא כאלה ש”עושים את זה מהצד", אלא כאלה שזה ממש העיסוק היומיומי שלהם, לסחור.
03:39 “נוטיפיקציות בסקייל” - איפה זה פוגש אותך?
(רן) אוקיי, אז בכנס דיברת - בוא נעשה אולי קצת Recap על מה דיברת בכנס: דיברת על “נוטיפיקציות בסקייל” (Notifications at scale). איפה זה פגש אותך, בפעם הראשונה?
- (גל) אז אולי רגע, לפני שנדבר על איפה זה פגש אותי, בעצם נדבר רגע . . . מבחינת המערכת שלנו, המערכת נוטיפיקציות שלנו - היא לא עוד איזושהי “מערכת נוטיפיקציות נחמדה”, שאיזושהי חברה מפתחת, כאיזשהו Feature-צד נחמד.
- בכלל, בעולמות המסחר המקוון, נוטיפיקציות זה נתיב קריטי:
- גם בגלל אופי הפעילות שלו, וגם מבחינת איך שהלקוחות תופסים את ה-Feature הזה, את הכלי הזה.
- זה יכול להיות החל מפעולות סטנדרטיות שלקוח עושה, כמו אם עכשיו הוא פותח פוזיציה או מחליט למשוך או להפקיד כסף - אז הוא מצפה לקבל מן הסתם איזושהי אסמכתא מיידית על הפעולה שהוא ביצע.
- אבל מעבר לזה, הלקוחות גם יכולים להגדיר לעצמם, לדוגמא, התראות שונות במערכת, עם כלי מסוים שהם עוקבים אחריו עלה מעל סף מסוים
- בין אם זה המחיר שלו או אחוז השינוי שלו.
- והם מצפים לקבל בזמן אמת את אותן נוטיפיקציות (Notifications).
- וזה, כמובן בלי שבכלל נגעתי בתוכן שיווקי או כל מיני דברים אחרים שאנחנו מעבירים באמצעות המערכת הזאת.
(רן) כלומר, זה כלי עבודה - זה לא סתם “FYI - הגיע מייל חדש!”, אלא . . .
- (גל) בדיוק, זה ממש נתיב-קריטי אצלנו במערכת, ולכן גם המשמעות והחשיבות שלו אצלנו, כשאנחנו מסתכלים על כל המערכות השונות, שבעצם מרכיבות את הפלטפורמה של Plus500.
(רן) כלומר, א' - שלא תתפספס נוטיפיקציה, וב' -שתגיע מהר . . .
- (גל) שתגיע “נכון” - אם, כלומר, רוצים להגיע עם כל מיני “Placeholder-ים” למשתנים כאלה ואחרים . . .
(אורי) כלומר, קרה . . . .
- (גל) קרה, בהחלט קרה . . .
(אורי) מקרים שקרו . . .
- (גל) לא אצלנו, כמובן . . .
(אורי) על גבי איזה Medium הנוטיפיקציות האלה עוברות?
- (גל) אוקיי, אז מבחינת ה-Medium, או מה שנקרא בשפה יותר רשמית, נקרא לזה Cross-Channel Orchestration - בעצם כל המבנה שנדרש כדי לתמוך בהודעות האלו.
- אז אנחנו מדברים על הודעות שנשלחות במספר ערוצים - Channels, בעצם
- זה יכול להיות ערוצים בתוך הפלטפורמה - אם זה הודעות ה-In-App, בתוך ה-Inbox שלנו; הודעות Pop-up, שאנחנו מקפיצים
- אבל זה יכול להיות גם מחוץ לפלטפורמה - אם זה הודעות Push, עבור תוכן שצריך לעבור בצורה מיידית ומהירה, או למשל ערוץ ה-Email או SMS או WhatsApp
- בעצם כל סוג של תוכן שאנחנו מעבירים - יש לו את הערוץ המותאם והרלוונטי ביותר עבורו.
- אגב - גם הרגולציה לפעמים מכתיבה לנו איזה תוכן צריך לעבור באיזה ערוץ או בכמה ערוצים שונים.
- זה מבחינת אופן ההפצה.
- מבחינת התמיכה בפועל - אז הפלטפורמה שלנו נתמכת במספר רחב של Client-ים.
- זה יכול להיות מכשירי Mobile ו-Tablet-ים ו-Smart Watches וגם כמובן Desktop או Web.
- אז גם מערכת הנוטיפיקציות בעצם צריכה לדעת לשלוח לכל אותם מכשירי-קצה את ההודעות.
(אורי) ויש גם איזשהו API או SDK, שעליהם אפשר לצרוך את ההודעות?
- (גל) אז בעצם, הנוטיפיקציות שלנו “רוכבות” על מספר ספקים שונים, שבסוף הם אלה ששולחים בפועל את ה-Mail או את ה-SMS וכו’.
- בסוף, אנחנו בנינו את המערכת שלנו על בסיס אותם APIs.
- אבל מבחינת SDK - לא הבנתי . . .
(אורי) אם אני - יש לי את האפליקציה שלי, אם אני Day Trader או שאני בנק, לצורך העניין . . .
(רן) אם אתם רוצים להציג איזשהו Widget, נגיד, באתר - ורוצים לקבל משם . . .
(אורי) או שיש לי מערכת מסחר, ואני מעוניין לקבל נוטיפיקציות ממך - ואני אסמוך על הנוטיפיקציות האלה לפעול.
- (גל) הבנתי את הכיוון - אז לא.
- המערכת שלנו היא בעצם מערכת שפיתחנו עבור עצמנו - אפשר גם לדבר על הייחודיות שלה, ובעצם על האתגרים שהיא הציבה לנו - אבל היא מערכת שמיועדת עבור הפלטפורמה של Plus500.
- אנחנו לא מספקים אותה כקוד פתוח או משהו כזה.
(אורי) לא, לא כקוד פתוח . . .
(רן) לא, אבל זה אפליקטיבי - אלו נוטיפיקציות אפליקטיביות, אם אני מבין נכון. זו לא פלטפורמה - זה לא במובן של “בוא תתחבר לפלטפורמה הזאת, ותקבל נוטיפיקציות על מה קרה בשוק” . . .
- (גל) לא - בדיוק כמו שכדי לסחור במנוע המסחר ש-Plus500 פיתחה, אתה צריך להיות לקוח של הפלטפורמה, אז אותו הדבר - אתה צריך להיות לקוח של הפלטפורמה, כדי לקבל נוטיפיקציות מהמערכת.
(אורי) אני יכול להיות לקוח של הפלטפורמה - באמצעות אפליקציה, שלי?
- (גל) אפליקציה של Plus500 . . .
(אורי) לא . . . לא משנה.
(רן) לא, אין פה “סינדיקציה” - זה B2C, כמו שגל אמר בהתחלה.
(אורי) כן.
08:18 זו לא בעיה פתורה?
(רן) אוקיי, “שאלת תם” - זה לא בעיה פתורה? כלומר, SNS, חברים . . . כאילו, אתה יודע, עושים נוטיפיקציות בעולם.
- (גל) אז כן, זה נכון. זאת בעיה - אני לא אגיד שהיא פתורה. זאת בעיה שנתנו לה מספר פתרונות אפשריים.
- בוא נדבר רגע, נשים את היסודות של מה שמייחד את המערכת נוטיפיקציות שלנו - ואז גם נבין למה היא לא באמת פתורה . . .
(רן) . . . למה הפתרונות האחרים לא מספקים פתרון מספיק טוב?
- (גל) בדיוק. אז קודם כל, התחלנו בזה שאמרתי קודם שאנחנו משווקים ללמעלה מחמישים מדינות, בעצם יש לנו רישיון פעילות בלמעלה מחמישים מדינות מסביב לעולם.
- המשמעות של זה היא קודם כל ריבוי שפות - אנחנו תומכים בעצם ב-30 שפות בפלטפורמה, וגם כמובן שמערכת הנוטיפיקציות צריכה לתמוך באותן שפות.
- זה בעצם מחייב אותנו לתוכן דינמי בצורה מאוד מאוד גבוהה.
- גם הטקסט עצמו מן הסתם צריך להיות מתורגם לשפות- לאותה שפה של הלקוח.
- אבל זה גם משפיע מעבר לזה - אפילו על הצורה שבה אנחנו רושמים את המספרים, התאריכים, השעות . . . בין תרבויות שונות גם הדבר הזה משתנה.
- אצלנו, אנחנו מסמנים אלפים עם פסיקים, ויש מדינות שזה עם נקודה.
- וזה גם משליך מעבר לזה, גם על כל נושא ה-Time-zone, שהוא מאוד מאוד שונה.
- אם עכשיו צוות השיווק שולח קמפיין, בנקודת זמן מסוימת - לצורך העניין חמש שעון ישראל - יש מדינות שבהן להעביר את ההודעה הזאת אפשר באותה שעה.
- אבל יש מקומות, למשל כמו אוסטרליה, שזו תהיה שעה קצת פחות לגיטימית להעביר בה הודעה.
- ולכן גם נדרש פה איזשהו מנגנון, של תזמון ההודעות בהתאם ל-Time-zone של הלקוחות.
- נוסיף עכשיו על הדבר הזה את סוגיית הרגולציה - שבעצם אין לנו אפשרות ל . . .
(רן) . . אבל פה, דרך אגב, בוא רגע נפריד. זאת אומרת, זה לא רק מערכת נוטיפיקציות - זה בעצם CMS לנוטיפיקציות, נכון? מערכת ניהול תוכן לנוטיפיקציות. כלומר מתי לשלוח את הקמפיין, מתי הבן אדם מתעורר וכל זה.
(אורי) . . . ואיך זה “מפורמט” . . .
- (גל) נכון, אז בעצם, כל עולם ה-Communication מכיל כמה מערכות שונות.
- בראש ובראשונה, אנחנו תומכים בהודעות מערכת - שזה בעצם כל מיני רכיבים שונים אצלנו בפלטפורמה -
- אם זה מערכת המסחר או מערכת ההפקדות או הכספים ודברים כאלה.
- שבעצם פונות אל מערכת הנוטיפיקציות - יש לנו איזשהו Client שה-Service-ים השונים במערכת הטמיעו אצלם, והם פונים ואומרים “תשלח עכשיו נוטיפיקציה ללקוח”.
- אלה הודעות, מה שנקרא “הודעות מערכת” - הודעות מיידיות, שצריכות לעבור ללקוחות.
- אבל המסה העיקרית היא בעצם הודעות - בין אם אלה קמפיינים שיווקיים, כשאגב, גם מערכת הקמפיינים היא מערכת שפיתחנו אצלנו
- ובין אם זה קמפייני Retention או Conversion וכל העולמות האלה - כשבעצם, מחלקת השיווק בוחרים לפנות ללקוחות מסוימים.
- ואז יש בבת אחת מסה של הודעות שצריכה לעבור לאותם לקוחות.
- אבל בעצם העניין היותר מעניין ומאתגר, שעליו גם דיברתי באריכות בכנס, הוא הנושא של “אירועי שוק”
- אנחנו מתמודדים בשוק ההון, והשוק הוא מאוד מאוד תנודתי.
- אנחנו מן הסתם לא יודעים לצפות מה יקרה למניות - כי אם כן, אז כנראה שהיינו עושים דברים אחרים לחלוטין . . .
- ובעצם, ברגע נתון יכול להיות לנו עכשיו איזשהו אירוע, לדוגמא מה שקרה עם Facebook או עם nVIDIA בחודשים האחרונים - כשיש איזשהו אירוע “שמטריף את כל השוק”.
- ואנחנו בעצם רוצים, כמערכת מסחר, לאתר, בזמן אמת, את אותם אירועים
- לאתר את הלקוחות, שזה אתגר בפני עצמו - איזה לקוחות יש, שהאירוע הזה עשוי לעניין אותם?
- ואז - בבת אחת, ברגע אחד - להעביר אליהם את ההודעות האלה, אל הלקוחות.
- אנחנו מדברים פה על מיליוני הודעות, שעוברות בפרקי זמן של שניות בודדות.
- ברור לך, כמו שאמרנו קודם - הקהל יעד הוא Day Traders. זאת אומרת, אנשים שרוצים לקבל את ההודעה כמה שיותר מהר ולבצע פעולה כמה שיותר מהר.
(רן) כן, זה לא שהם יקראו את ה-Email שנייה אחת מאוחר מדי - הם כנראה יכולים להפסיד על זה הרבה מאוד כסף, ואולי אתם תפסידו אותם בתור לקוחות . . .
- (גל) ולכן זה גם לא יהיה Email - זה יהיה Push, הודעת In-App, בתוך הפלטפורמה.
(רן) כן, זאת אומרת - יש פה חשיבות משמעותית לדחיפות בחלק מהמקרים, כמו שאמרת. במקרים אחרים אולי קצת פחות ,בסדר.
12:16 קצת יותר מתרומות לקבר רחל
(רן) וכשאתה אומר “Scale” - על איזה Scale אנחנו מדברים?
- (גל) אז כמו שאמרתי, אנחנו מדברים על מיליוני לקוחות.
- מה שנקרא “הרף העליון” - הבעיה שהגדרנו לעצמנו לעמוד בה מבחינת הספים (Thresholds) - אנחנו מדברים על כ-10 מיליון נוטיפיקציות שנשלחות.
- כשה”נוטיפיקציות" זה לא בהכרח 10 מיליון הודעות שונות - אלא 10 מיליון הודעות שנשלחות בערוצים שונים.
- לדוגמה, אותה הודעת Market Event שדיברנו עליה קודם, תשלח בשני ערוצים לפחות.
- ואם אתה בכלל לקוח שיש לו גם Mobile וגם Web, אז אתה גם תקבל לכל אחד מה-Client-ים שלך את ההודעה הזאת.
- אז אנחנו מדברים פה על סדר גודל של 10 מיליון הודעות, שעוברות ברגע נתון.
(רן) ברגע נתון?
- (גל) ברגע שמתקבלת ההחלטה לשלוח 10 מיליון הודעות ללקוחות - אז מבחינת הזמנים שעובדים בהם . . .
(רן) . . . ה-Burst, אוקיי . . .
- (גל) . . . אז זה ב-10 מיליון הודעות.
- אנחנו מדברים על סדר גודל של עד 10 שניות, בעצם של טיפול באותן הודעות.
- (גל) “קצת” . . . גם מבחינת ה-Scale שנדרש . . .
(רן) זאת אומרת, Throughput של כמיליון הודעות בשנייה, בסדר - זה כשיש לך איזה Peak, אבל לא כל היום הוא כזה . . .
- (גל) נכון - וזה, אגב, משהו שאני גם נוגע בו בהרצאה. זה בעצם שבגלל שכמו שאמרת, רוב הזמן זה לא קורה, אבל באותם הרגעים אתה לא יכול שלא לתמוך בזה.
- אז בעצם גם הארכיטקטורה צריכה לתמוך בדבר הזה, ולתת מענה גם לאותם Burst-ים, אבל בלי הצורך הבזבזני עכשיו להשקיע מלא מלא חומרה או משאבים, כדי שהדבר הזה ירוץ במשך כל שעות היום.
(רן) כן, שזה אתגר. זאת אומרת, אם זה כל הזמן היה מיליון בשנייה, אז היית יכול להגיד, “אוקיי זה ה-Stable State - מזה אני מרוויח כסף אז פה אני גם משקיע כסף”, אבל אתה לא יכול. אם זה קורה לך פעם ביום, אתה לא רוצה להחזיק “צי של מכונות” רק בשביל הפעם הזאת ביום.
(אורי) השאלה היא האם אתה יודע מתי זה הולך לקרות, ותוך כמה זמן אתה צריך להעלות את ה-Caps? . . . .
- (גל) אז אני לא יודע - כי אם הייתי יודע, אז היה מצוין . . . . אבל לצערי אני לא יודע.
(רן) אולי בחלק מהמקרים - נגיד, קמפיינים. זאת אומרת, דברים כאלו מתוכננים שאתה יודע, אבל באופן . . .
- (גל) אז קמפיינים כן - אבל קמפיינים הם אולי גם קצת פחות מעניינים, כי הם ברובם לא נדרשים להעברה מידית ללקוחות, ולכן אני יכול גם “למרוח אותם על ציר הזמן”.
- הבעיה שלי היא עם הודעות שהן גם מצד אחד מהירות, כמו הודעות מערכת, אבל ב-Volume-ים של קמפיינים. זו בעצם הבעיה שלי.
- אם אני אומר שאני מפריד עכשיו את הנוטיפיקציות לשני סוגים מרכזיים
- יש את הודעות המערכת - ההודעות שמצד אחד צריכות לעבור מאוד מאוד מהר, אבל בדרך כלל הכמויות שלהן יהיו הרבה יותר קטנות.
- בטח כי זה כאלה שמוטרגות (Triggered) מפעולות שהלקוח מבצע.
- ומצד השני יש לנו את הנוטיפיקציות, שהן הקמפיינים השיווקיים - שהן בעצם כמויות מאוד מאוד גדולות של בקשות, אבל שאפשר לפרוש אותן על ציר הזמן, כי הם לא דחופות לרגע אחד.
- אותם Market Events שדיברנו עליהם קודם, אותם אירועי שוק שאנחנו לא יודעים לצפות - הם בעצם גם וגם.
- הם גם מיידיים - והם גם בכמויות גדולות.
15:14 “כובע המודרטור” / סיימת את ההרצאה. מה קרה אז?
(רן) אוקיי. אז אחרי שהבנו את הצורך והבנו את האתגר - הרבה מהארכיטקטורה וכל הסיפור נמצא בהרצאה ואנחנו לא נחזור על כל זה. זאת אומרת, גם בווידאו זה משהו קצת שיותר קל לראות, כי יש שקפים והכול.
אבל בואו נתחיל מהרגע של אחרי - אוקיי, סיימת את ההרצאה. מה קרה אז?
- (גל) אז קודם כל - הרגשה מטורפת. זה אני חייב להגיד.
- בעצם, סיימתי את ההרצאה - ולא כל כך ידעתי איך אנשים “יאכלו את זה”.
- בסוף, הצגתי פה את מערכת הנוטיפיקציות שלנו - שאוקיי, זה איזשהו תהליך אבולוציוני שאנחנו עברנו, אבל זה משהו שאנחנו עברנו.
- וכדי בעצם להמחיש אותו, אז הצגתי את אותו סיפור, על אותם “אירועי שוק”.
- ולא כל כך ידעתי איך אנשים “יאכלו“ את זה והאם יהיה לדבר הזה בעצם ביקוש והאם יתעניינו.
- ומאוד מאוד הופתעתי מכמות הפניות - גם ברגע שאחרי ההרצאה, עם חבר'ה שניגשו אליי או בהודעות שקיבלתי לאחר מכן - שבעצם הבנתי שהנושא של נוטיפיקציות, כמערכת בכלל, הוא משהו שמעסיק לא מעט חברות.
- אגב, גם היה מאוד נחמד לקבל גם אנשים שאמרו לי “שמעתי כמה דברים בהרצאה שלך ואנחנו נשקול לקחת את זה גם אלינו”.
- אבל מה שבאמת “פתח לי את הראש”, זו העובדה שהצגתי איזשהו Use Case נורא ספציפי שלנו - Market Event, שנורא ספציפי לשוק ההון ולתנודתיות שלו.
- ופתאום בשיחה ככה, בשיחת מסדרון אחרי ההרצאה, ניגש אליי מהנדס, שגם עובד בין היתר עם משרד הביטחון על המערכת של פיקוד העורף, של ההתראות.
- הוא אמר לי, כמו שאתה לא יודע להגיד מתי יהיה לכם אירוע שוק, שעכשיו יכניס את כל המערכת ל-Stress, גם אנחנו לא יודעים מתי יהיה מטח טילים, שיכניס את כל גוש-דן עכשיו למקלטים, וצריך להעביר להם הודעות Push.
- גם בשיחה עם חבר, שככה ראה את ההרצאה אחר כך ב-YouTube, והוא אמר לי “אה, זה אולי גם קיים בעצם בחברות ששולחות Push-ים על אירועי כדורגל, נגיד”.
- נגיד, עכשיו קבוצה הבקיעה גול - ועכשיו צריך לשלוח הודעות Push למלא לקוחות.
- פתאום, הבעיה שהצגתי - היא הרבה יותר רחבה ממה שנחשבתי שהיא...
(רן) אז פה תרשה לי רגע לשים את “כובע ה-Moderator” [אוי, זה רעיון מעולה!]. הרבה פעמים באמת אנשים, כשדיברנו קודם על הכנס ועל להגיש הרצאות, הרבה פעמים אנשים מסתכלים על החוויה שלהם - על מה שהם למדו, על המוצר שהם פיתחו, על הטכנולוגיה שהם פיתחו - והם אומרים “אוקיי, אבל זה נורא ספציפי. זה אני עשיתי, כי הייתי צריך ב-Facebook משהו, זה אני עשיתי, כי הייתי צריך ב-Plus500 משהו” . . . וברוב המקרים אנשים באמת חושבים שזה לא מעניין אף אחד.
אולי יש מקרים כאלה - אבל מצד שני, יש הרבה מאוד מקרים שבהם קשה לך באמת לדמיין את מי זה הולך לעניין, ותהיה מופתע לגלות שזה באמת הרבה הרבה יותר גנרי. וזו באמת, ככה, “חוויה פותחת עיניים” - לבוא ופתאום לפגוש את האנשים עם Use Case-ים דומים, שאולי קוראים לזה אחרת. אולי זה גול, אולי זו רקטה . . . זה לא בהכרח אירוע שוק, אבל כן, העקרונות הם אותן עקרונות, וזה באמת מאוד נחמד לבוא ולהיפגש עם אותם Use Case-ים.
(אורי) האמת שגם המוח שלנו רגיל הרי לחשוב בתבניות, והוא רגיל לחשוב בתבניות של דברים שאנחנו מכירים . . .
(רן) . . . אבל זה בגלל שיש לך תבנית על המוח שלנו, אורי . . .
(אורי) כן . . . וגם, כשאתה מדבר על נוטיפיקציות של אירועי שוק, מישהו אחר שומע את הבעיה של פיקוד העורף. כאילו, אל תניחו - אנשים באים עם התבניות שלהם, והם ייקחו את מה שאתם אומרים לתוך התבנית שלהם, וזה פתאום יהיה רלוונטי.
(רן) כן, כן. אבל מעבר לזה, גם אם אי אפשר לקחת את הפתרון שלך, לצורך העניין, ופשוט להשתמש בו כ”פתרון מדף”, עדיין - הרעיונות, העקרונות, יכולים להיות אותם עקרונות: ה-Design של המערכת.
אז מה קרה אחר כך? זאת אומרת, באת ואמרת, “אוקיי, אני הולך לכתוב פרויקט ב-Open Source!, אני הולך לעשות כסף מחברה ששולחת נוטיפיקציות!” . . . כאילו, מה קורה אחר כך?
- (גל) לא. בעצם, אחרי הרצאה, קודם כל, הרבה אנשים פנו, זה היה מאוד מאוד נחמד גם לשמוע.
- גם, אגב, אנשים, בין אם זה מתוך התעשייה, שעובדים בתעשייה ובאו לדבר איתי על זה - או בין אם בכלל אנשים ממקומות אחרים, שאמרו, “רגע, אולי בעצם הפתרון הזה, או הפתרון האחר . . .”.
- ופתאום, זה פותח לי את הראש - מן הסתם הפתרון שלי, זה מה שאני עשיתי, ולכן זה הכי טוב, ברור.
- אבל, כמובן שיכולים להיות אינסוף פתרונות אחרים, שאנחנו יכולנו לקחת ולממש.
- וצריך ככה . . . זה באמת, גרם לי לחשוב “מחוץ לקופסא” קצת, על דברים אחרים שאפשר לעשות.
- ולקחת את המערכת הזאת, בעצם את העולם הזה של נוטיפיקציות, ולפתח אותו למקומות נוספים.
- אפילו מבחינת המעטפת של מי ואיך משתמשים במערכת הנוטיפיקציות הזאת
- היום, בעצם הצרכן המרכזי שלנו במערכת אלו אותם קמפיינים שווקיים
- אבל, אם עכשיו בעצם הגענו למצב שבו מערכת הנוטיפיקציות יודעת ברגע אחד לטפל בהמון המון בקשות מאוד מאוד מהר, אז עכשיו אפשר לשים את הפוקוס, רגע שנייה, על צעד אחורה - על איך אנחנו משפרים את בחירת התוכן שאנחנו שולחים ללקוחות, איך אנחנו בכלל משפרים את המנגנון של בחירת הלקוחות עבור אותם קמפיינים שווקיים . . .
- יש פה בעצם אינסוף אפשרויות בעולם הזה - והוא גם מאוד מאוד כלכלי.
- אנחנו רואים את זה בניסויי A-B Testing ובהשוואות מול קבוצות ביקורת של אותם קמפיינים שווקיים, שיש פה הרבה מאוד כסף שאפשר להכניס ולשנות את זה.
(רן) מה שבא ללמדנו, אולי זו לא תגלית גדולה, אבל שלפעמים טכנולוגיה היא Enabler ל-Content. זאת אומרת, אם לפני זה יכולת לשלוח, נגיד, עד 1000 נוטיפיקציות בשנייה, אז היית חוסך, ולא היית עושה שום A-B Testing או שום דבר כזה. ברגע שיש לך את הטכנולוגיה, אתה יכול בעצם לפתח תוכן, שלוקח ושמשתמש בזה.
- (גל) עם האוכל, בא התיאבון . . .
(רן) כן.
20:51 טעויות, תיקונים ו-Vicious Cycles
(רן) עכשיו, שוב, אנחנו לא ניכנס לכל ה-Design וכל הדברים שהיו בהרצאה - ושוב, מוזמנים ללכת ולראות את הווידאו, אבל אולי נדבר על דברים שלא הספקת להגיע אליהם בהרצאה. למשל, איזה כיוונים ניסיתם ללכת אליהם, ובסוף התחרטתם, או איזה דברים . . . נגיד, “ה-Playbook” או “פתרון הספר”, שלכאורה נתן פתרון, אבל גיליתם שלא.
- (גל) אוקיי, אז בוא נדבר על הטעויות - כי היו גם כאלה, צריך להגיד בכנות.
- באמת, אני מתחבר לכל מה שאמרת בסוף, עם ה-Playbook - אולי בעצם הטעות הראשונה שעשינו, זה ה-Playbook solution . . .
- בעצם, אני קצת מדבר על זה גם בהרצאה, על הפתרון הראשון שבעצם עשינו. לא ניכנס פה עכשיו לפרטים הטכניים, אבל בעצם יצרנו מעטפת אחת, Notifications Service
- שמכיל בתוכו את כל הלוגיקות שהיינו צריכים בשביל לתמוך בדרישות המוצר - עם כל מה שדיברנו קודם: רגולציה, בנייה של תוכן, וכן הלאה.
- ובנינו אותו בעצם על בסיס שני עקרונות מרכזיים:
- קודם כל, כמובן, תמיכה ב-Multi-instance - תצורה של Active-Active
- ואז בעצם, כדי לתמוך בזה,כל Instance כזה הוא בעצם Stateless.
- וכמובן, זה מאפשר לנו בעצם את ה-High Availability - אם עכשיו אחד ה-Instance-ים יקרוס, מכל סיבה שהיא, יהיה תמיד את ה-Service-ים האחרים.
- וככה אנחנו בעצם יכולים כל הזמן לוודא שהמערכת תהיה “למעלה”, שום מידע לא יאבד והכל יהיה בסדר.
- בפועל, כשהעלינו ל-Production והעומס התחיל לעלות ולגדול עם הזמן - בין אם זה הלקוחות, כי כמות הלקוחות גדלה, או בין אם זה כי ה-Use Case-ים השתנו
- אז פתאום ראינו שיש סוג-של יחס ליניארי כזה, בין כמות המידע שאנחנו צריכים לתת לו מענה ברגע אחד, כמות הבקשות - לבין כמות המשאבים, שאנחנו נדרשים להקצות, כדי לעמוד באותם עומסים.
- ואז בעצם הגענו למצב שבו מערכת הנוטיפיציות שלנו רצה על כמות משאבים כמו של מנוע המסחר
- וזה כבר ממש לא Infinite-Scale וזה כבר ממש לא Cost-Effective, וזה כבר ממש לא משהו שאנחנו יכולים להרשות לעצמנו, בעצם, להמשיך לתחזק ולעבוד איתו.
(רן) כלומר, זה “עומד ב-Spec”, במובן של אוקיי, זה Highly Available - אבל זה עולה המון כדי לתחזק את זה.
- (גל) בדיוק. עכשיו, יבואו הרי ויגידו “אוקיי, אבל בסדר - בוא נחזיק את רוב המערכת עם רוב המשאבים כל הזמן”
- אבל אז - בדיוק כמו שדיברנו קודם - אם האירועי-שוק האלה יהיו עכשיו במשך 10% או 20% מהזמן, אז, 80% מהזמן שילמתי המון כסף, ללא צורך.
- אז בעצם הבנו ש”ה-Playbook Solution” - אותו Service אחד, שעושה את העבודה כמו שחשבנו או שקיווינו שהוא יעשה - פשוט לא עשה כמו שצריך.
- ונדרשת פה חשיבה מחודשת על הארכיטקטורה.
- ואז עשינו פירוקים ודברים - וזה כבר מופיע בהרצאה.
- הטעות השנייה שהייתה לנו, קשורה לנושא השרידות, ה-Resiliency של המערכת.
- כמו שאמרתי קודם, אנחנו התבססנו בעיקר על High Availability - זאת אומרת, תמיד אמרנו לעצמנו “לא משנה, מה יקרה, המערכת תמיד תהיה למעלה”.
- תמיד יהיה לפחות Instance אחד שיגבה.
- והדבר הזה באמת היה נכון - רק שכשהגיע אותו עומס, המערכת לא קרסה וגם אף אחד מה-Instance-ים לא קרס . ..
- מה שקרה בפועל, זה ש-Flow-ים מסוימים, בעיקר ה-Flow-ים הסינכרונים -
- אלה שצריך כדי שעכשיו ה-Service יתן עכשיו תגובה מהירה, נגיד ל-Client, ללקוח, שפותח את האפליקציה, והוא רוצה עכשיו לקרוא תוכן בתוך האפליקציה - אז ה-Service לא היה זמין, כי הוא היה עסוק בהמון בקשות אחרות . . .
- וה-Flow הזה בעצם נתקע.
- אז במקרה הזה אין לנו פה בעיה של High Availability - פשוט יש לנו Flow, איזושהי קומפננטה (Component) שלמה, שפשוט לא מגיבה מספיק מהר.
- והמשמעות כאן היא פגיעה אפשרית בחוויית הלקוח.
(רן) כלומר, זו בעיה של Throughput? נוצר איזשהו צוואר-בקבוק במערכת הזאת?
- (גל) כן, בדיוק. המערכת, באופן שבו היא תוכננה בהתחלה, בעצם ברגע שהגיע עכשיו Burst של בקשות, אז המערכת התעסקה רק בזה.
- ואז בעצם יש איזה סוג של מעגל, Vicious Cycle כזה - שבעצם עכשיו המערכת מקבלת הבקשות האלה ושולחת אותן, נוצר בעצם עומס של כתיבות במערכת.
- הלקוחות מקבלים את ההודעות, נכנסים לפלטפורמה כדי לקרוא - ונוצר עכשיו עומס של קריאות.
- כל לקוח קורא את ההודעה - אנחנו צריכים גם לסמן שההודעה נקראה, אז נוצר עוד פעם עומס של עדכונים, . . .
- כשבעצם זה איזשהו מעגל כזה, שגם מזין את עצמו.
(רן) דרך אגב, רואים את זה הרבה פעמים במערכות מבוזרות - אני בטוח שראיתם [אורי] את זה גם ב-Outbrain - ברגע שנוצר איזשהו Failure, אז נוצר “כדור שלג” הרבה פעמים, “Vicious Cycle”, כמו שאמרת - כי אז יש יותר עומס על נגיד Instance-ים אחרים, ולפעמים צריכים כזה, ואז אולי Instance אחד בדיוק עלה כי רצית לעשות Scale-up - ונוצר יותר עומס על ה-Database . . . בקיצור, זה איזשהו Vicious Cycle, שלפעמים עושה יותר נזק מאשר תועלת.
אז כן, לצאת ממצבים כאלה זה לגמרי לא טריוויאלי.
- (גל) פתאום אנחנו, אתה יודע - פתאום ממערכת ששולחת הודעות, פתאום אנחנו צריכים להגיד לעצמנו “רגע, מה קורה עכשיו?”
- עכשיו לקוח מבצע, נכנס לפלטפורמה, מנסה לקרוא הודעות - והוא לא מצליח.
- מה עושה כל לקוח טוב, שמבצע פעולה והיא לא מצליחה? עושה אותה עוד פעם, ושוב ושוב . . . .
- ופתאום אנחנו משפיעים על חוויית הלקוח בצורה שבכלל לא היינו אמורים להשפיע עליה.
- ולכן גם נושא השרידות זו בעצם איזושהי טעות בהתחלה, כשהתייחסנו בעצם ל-High Availability כאל חזות הכל - וזה ממש לא זה.
- אז זו עוד איזושהי טעות ככה, שלמדנו תוך כדי.
(רן) דרך אגב, אם למישהו יצא לקרוא את ספר ה-SRE של Google - הם מדברים שם נגיד על Availability. ושם, אחד הדברים המעניינים שהם אומרים - אולי זה לא, שוב, לא גילוי גדול למי שמכיר - זה ש-Availability זה לא בינארי - זה לא שזה למעלה או למטה, זה באחוזים. זה יכול להיות למעלה ל-99.9% מה-USer-ים, או 99.9% מהזמן - ותמיד, להשיג עוד אחוזון קטן, זה הרבה הרבה הרבה יותר עבודה מאשר להשיג את האחוזון הקודם, ותתכננו את ה-Availability שלכם לפי זה. כלומר, אין טעם לדבר על 100% Availability, כי זה אינסוף כסף, אינסוף משאבים - אבל כן להציג איזושהי מטרה ריאלית, כי זה משהו שהוא לגמרי אפשרי, בין זה מבחינה גיאוגרפית, מבחינת מספר ה-User-ים, מבחינת אחוזי-זמן.
(אורי) אם תסתכלו על ההרצאה של יונתן זוסמן מאותו הכנס [Throttling your service: the good, the bad and the ugly / Yonatan Zusman], אז הוא מדבר על מערכת של Throttling - שאתה בעצם, כדי להשיג High Availability, אתה “מוריד מהאיכות”, או לצורך העניין מההכנסות. אבל אתה יודע שאתה עושה את זה לזמן מסוים, כשאתה ב-Peak, ומוכן לוותר טיפה על הכנסה. זה עוד מנגנון לא-בינארי ל-High Availability.
(רן) כן, כן, אז נגיד אני חשבתי על זה כשהזכרת ואמרת שאוקיי, יש נוטיפיקציות שצריכות “עכשיו-עכשיו” לצאת, ויש קמפיין, שזה בסדר, זה לא נורא גם אם יוצא בעוד חמש דקות. נגיד היום - המערכת שלכם יודעת לתעדף את העומסים האלה?
- (גל) בעצם, יש לנו “Priority-Queue כזה” - שלתוכו נכנסות כל הבקשות שמגיעות ברגע נתון, ובעצם הוא מסדר אותן לפי העדיפויות.
- כמובן, התוכן השיווקי מתועדף פחות מהודעות המערכת, בטח מהתוכן הרגולטורי או דברים כאלה.
- אז כן - אנחנו תומכים בזה.
28:03 עננים וסוגיות של גידור
(רן) אוקיי. דרך אגב - מבחינת Deployments: אתם, ככה, משתמשים בחומרה שלכם - ענן, Multi-region? . . . איך זה?
- (גל) אז זה משתנה - תלוי על איזה Component אנחנו מדברים במערכת. ספציפית על הנוטיפיקציות?
- אז כן - אנחנו מדברים בעצם על VM-ים שיושבים ב-GCP.
- אגב - אחד השיקולים, גם בגלל ה-Volume המאוד-מאוד גדול שיש על המערכות האלה, גם הפרדנו אותן, מן הסתם מה-Cluster-ים של מנוע-המסחר.
- כדי שלא משנה מה יקרה - מן הסתם, אנחנו לא נקריס עכשיו את מנוע המסחר.
- לכן הוא יושב ב-GCP - יש לו VM-ים משלו, וכל Instance כזה גם יושב על VM-ים, כל סוג של קומפוננטה (Component) שונה במערכת.
- אם זה ה-Write, אם זה ה-Fanout, ה-Read - אני מרחיב על זה בעיקר בהרצאה, אבל כל אחד הם יושב בתוך VM משלו.
- וגם ה-Cluster של ה-RabbitMQ - בעצם אותו Message Broker שאנחנו עובדים איתו - גם הוא נפרד מכלל המערכת.
(רן) כלומר - יש “גידור”, במובן הזה שאם רכיב אחד נכנס לאיזשהם צרות, אחרים לא בהכרח סובלים. זאת אומרת הם עלולים, כן? אבל לפחות בניתם את זה כך שהם לא בהכרח יסבלו.
29:21 ועכשיו מה? מה עכשיו?
(רן) טוב, אתם עוד עובדים על זה?
- (גל) אז מערכת הנוטיפיקציות - אנחנו כבר פחות. היום אנחנו בעיקר ב-Mode של תחזוקה.
- אנחנו כן בעיקר מנטרים (Monitor) ועובדים על המערכת, מבחינת זה שאם דברים יקרו, או שפתאום אותם ספים (Threshold) שהגדרנו לעצמנו . . .
(רן) . . . תקבלו נוטיפיקציה, מה הבעיה? . . .
- (גל) בדיוק . . . אז אנחנו כן - השקענו המון המון בתקופה האחרונה ב-Monitoring ו-Observability למערכת הזאת.
- כדי שאם יקרה משהו - אנחנו נדע.
- ועכשיו אנחנו מתעסקים באמת בעיקר במעטפת - כמו שאמרתי קודם, לנסות לאפטם (Optimize) את קהל הלקוחות ואת התוכן שאנחנו שולחים בפועל ללקוחות.
- ופחות את מנגנון-השליחה עצמו.
29:59
(רן) אוקיי - אז תודה רבה! היה מעניין.
שוב נזכיר, זאת אומרת - ה-Design הטכני של המערכת זה משהו שאנחנו לא מדברים עליו פה בפודקאסט, אבל אני כן ממליץ ללכת ולראות את הוידאו - ואת כל שאר ה-Video-ים של הכנס [יש Playlist לכל שנה] מיד אחריו.
- (גל) כן - אז אנחנו יושבים בחיפה, ויש גם Site בתל אביב - אבל ה--Headquarters יושבים בחיפה.
- ובאמת עוד פעם - כשאנחנו מסתכלים במבט של מה קורה בעתיד, אז באמת אנחנו נכנסים או שאנחנו נמצאים היום בתקופה שאנחנו נכנסים גם לשווקים חדשים - כולל, אגב, גם השוק האמריקאי.
- ולכן גם זה מן הסתם יביא איתו עוד אתגרים, גם בעולמות ה-Communication שאני מוביל, אבל בכלל, בכל עולמות הפיתוח.
- ולכן אנחנו מגייסים המון המון משרות - בין אם זה משרות פיתוח, אבל גם בכלל משרות אחרות.
- אז כל מי שככה מאזין ומחפש אתגר מעניין ולהשפיע על מיליוני לקוחות במוצר שלנו - מוזמן להגיש קורות חיים ולהצטרף אלינו.
- אני קצת משוחד, אבל שווה . . .
(רן) אתה עוד שם . . .
האזנה נעימה ותודה רבה לעופר פורר על התמלול!
