רשמים מכנס AWS 2022 תל אביב – על ענן, דאטה וחווית משתמש

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

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

כיצד הזרקה של כאוס למערכת יכולה לתרום לסוף שבוע שקט?

בהרצאה Using AWS Fault Injection Simulator and Chaos engineering to increase Fault Tolerance יעל גרוסמן דיברה על כך שכל מערכת תיפול בסופו של דבר ולרוב זה יהיה בזמן הכי פחות נוח. בין עם זה קישוריות רשת שפתאום מתנתקת, עומס גדול מדי על המחשב, נפילה של השרת או כל דבר אחר. כדי להתכונן לתרחיש כזה אפשר להשתמש בשירות AWS Fault Injection Simulator שמדמה כל מיני אירועי נפילה בחלקים שונים בארכיטקטורת הענן, לבדוק עד כמה הם משפיעים על השירות שהמערכת שלנו נותנת ולהבין איזה חלקים צריך להפוך לעמידים יותר וכיצד אנחנו מתמודדים עם המצבים האלה.

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

Everything fails, all the time!

Dr. Werner Vogels, Amazon CTO

איך בונים נכון ארכיטקטורת מיקרוסרוויס מונחת מידע?

הנטייה היום (ובצדק) היא לעבור כמה שיותר למערכות הבנויות על מיקרוסרוויסים שונים – אבל כיצד דואגים לכך שהסרוויסים השונים לא יכירו אחד את השני? (במידה והם מכירים אחד את השני לדוגמא פונקציית למדא שקוראת לפונקציות למדא אחרות אזי נשארנו עם אותם הבעיות של מערכות מונולטיות). אורי שגב בהרצאה בשם Building Event Driven Applications on AWS הסביר כיצד להשתמש בנגנוי ארועים שונים של דחיפה ומשיכה על מנת להעביר את המידע בין הסרוויסים השונים.

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

מערכות דחיפה של אירועים כוללות את שירות SNS המאפשר דחיפה מהירה (פרסום) של אירועים שיכולים להפעיל שירותים חדשים בענן או לשלוח אימייל, סמס, פושים או קריאות http ישר למשתמשים, כאשר יכולים להיות הרבה צרכנים שונים שמקבלים את ההודעה. ושירות EventBridge הנותן יותר גמישות בלסנן את סוג האירוע שמגיע (אך מצד שני דורש שהאירוע יהיה בJSON) ונותן גם אפשרות לשמור בארכיון.

ממני תראו וכך על תעשו – מייסדי סטארטאפ מספרים על טעויות שלהם

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

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

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

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

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

העתיד של החיפוש הטסטואלי

המוצר החם היום לחיפוש טקסטואלי Elasticsearch או כמו שהגרסה של אמזון נקראת Opensearch מציע יכולות מצוינות ומהירות לחיפוש טקסטואלי. אך מכיוון שעבור רוב החברות נפח המידע גדל (בדרך הטבע או בדרישות רגולריות של שמירה של מידע ליותר זמן) אזי צריך למצוא דרך זולה ויעילה להמשיך להשתמש במוצר. בהרצאה Building the future of search together (ES) רועי גמליאל הראה כמה אופטימציות שיכולות לחסוך הרבה כסף בשימוש.

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

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

לעבור למעבדי ARM היכן שאפשר
על פי הנתונים שהוא הציג משפחת המעבדים החדשה של אמזון Graviton2 משפרים את הביצועים יחסית למחיר ב44%.

איך קונים שמלת חתונה

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

1. שמלת כלה
2. שמלה כחולה
3. שמלה קייצית
4. שמלת נשף

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

1. שמלת כלה, (0,0,2,4)
2. שמלה כחולה, (1,5,3,4)
3. שמלה קייצית, (2,6,4,6)
4. שמלת נשף, (9,8,7,6)

עכשיו כשנחפש ״שמלת חתונה״ נחפש גם מה הכי קרוב לווקטור של ״שמלת חתונה״ שיהיה משהו כמו (0,0,1,4) וכך נוכל לקבל את שמלה #1.

ניטור ושיפור חווית המשתמש

סיימת להרים אפליקציה בענן, כעת איך אתה מוודא שאתה נותן למשתמש חוויה טובה? שהאתר שלך תמיד זמין? וכיצד אתה משפר את חווית המשתמש של האתר בעזרת ניסויים ונתונים? שחר דניאל ועדי אבני הציגו בהרצאה Data driven software development – Elevate the experience of your users כמה כלים של Amazon CloudWatch שעונים על השאלות הנ״ל.

Amazon CloudWatch Synthetics

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

Amazon CloudWatch RUM

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

Amazon CloudWatch Evidently

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

מילות סיום

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

להתראות בכנס הבא!