איך חסכנו 90% מעלויות השימוש שלנו בענן של גוגל

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

מקור: Pexels

מאת אלכסנדרה פיינבורד

אני מאוהבת ב-Google App Engine.

באמת.

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

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

במאמר זה אני רוצה לספר איך חסכנו יותר מ-90% מההוצאות על ידי שינוי טכנולוגיה ועברנו מ-Google App Engine ל-Kubernetes.

אבל בואו נתחיל מהתחלה.

מה זה Google App Engine (או GAE)

GAE הוא מוצר של גוגל ששייך למשפחת ה-Serverless, אבל האמת היא שהוא היה קיים כבר בשנת 2008 עוד לפני שהמציאו את המושג הזה. בזמנו הוא היה מוצג כ-PaaS או Platform-as-a-Service – הדרך החדשנית של גוגל לתת למפתחים כלי, שמאפשר להם רק לכתוב תוכנה ולא לדאוג לתשתית – בניגוד ל-IaaS או Infrastructure-as-a-service, שהוצע באותו הזמן על ידי אמזון בתור מוצר הדגל למפתחים בענן.

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

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

אז איפה הקאץ’?

כל הנוחות הזאת באה עם תג מחיר.

מודל התמחור של GAE הוא תשלום עבור שימוש בזמן המעבד.

בזכות ה-scaling האוטומטי של השרתים, הזמן הזה יכול להיות משמעותי אפילו עבור משימות פשוטות ותמימות.

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

עבור כל אירוע כזה נשלחה בקשה לשרת (המאוחסן ב-GAE) ונתוני האירוע נשלחים ל-data warehouse של גוגל המכונה Big Query. אז בואו נעשה חשבון, ולצורך הפשטות בואו ניקח רק חלק קטן מהפעולות של הקלטות הנתונים ולא השירותים המרכזיים שלנו:

ביום רגיל אנחנו מקבלים כ-1,000 אירועים בממוצע בשנייה. עבור עומס כזה – GAE מקצה לנו בממוצע 50 instances, המשרתים את הבקשות הללו. השליחה ל-BIGQUERY לוקחת 20-50 מילישניות ושעה אחת של אינסטנס אחד עולה $0.05 בשרת הכי זול.

אז מה היה לנו?

50 X 0.050 = $2.5 בשעה

= $60 ביום

= $1800 בחודש

אאוץ’… וכמו שאמרתי כבר, זה רק החלק הפשוט של המערכת שמקליט את התנהגות משתמשי הקצה, ולא כל האלגוריתמים המתקדמים שלנו!

הבעיה. אז מה בעצם הבעיה? למה אנחנו צריכים כל כך הרבה אינסטנסים ולמה הם עובדים כל כך הרבה זמן עבור משימה כה פשוטה?

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

אז איך אפשר לפתור את הסוגיה הזאת?

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

איך מממשים את הפתרון הזה?

למזלנו, קיימת פרדיגמה שמיועדת בדיוק לתסריט כזה ושמה Publish-Subscribe pattern וכל אחד מהספקים המודרניים של שירותי הענן מציע מימוש משלו של הפרדיגמה. כך למשל אמזון ארזה את השירות בשם Amazon SNS; מיקרוסופט קוראת לשירות שלה Azure Service Bus; וב-IBM קוראים לזה IBM MQ. ב–Google Cloud יש שירות שמיועד לתסריט כזה ושמו Google Cloud Pub/Sub.

מודל 1: request-response (שרת – לקוח) – המודל הזה הוא מודל טיפוסי לתקשורת בווב או בין מכשירים שונים ברשת. הוא מורכב מלקוח ששולח בקשה ושרת שעונה לבקשה. למשל, אם בא לך לראות סרטון ביוטיוב, המכשיר שלך שולח בקשה לשרתים של יוטיוב ומקבל תשובה עם תוכן הסרטון. או במקרה שלנו, האפליקציה שולחת בקשה להכניס הודעה לטבלת BIGQUERY ומקבלת תשובה אם ההכנסה הסתיימה בהצלחה (או נכשלה).

הארכיטקטורה של אפליקציית המשתמשת במודל של שרת לקוח נראית כך:

מודל 2: Publisher-Subscriber – הדרך השניה לתקשר ברשת נקראת PUBLISH-SUBSCRIBE (או בקיצור Pub/Sub). במודל הזה קיימת ישות מרכזית שנקראת ברוקר שהיא מקבלת הודעות ומפזרת אותם למי שמעוניין לקבל אותן. אין יותר לקוחות ושרתים, כולם הם הלקוחות של הברוקר.

הארכיטקטורה נראית כך:

 

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

מה קורה היום?

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

Google Cloud Pub/Sub הוא שירות של Google Cloud המהווה את הברוקר שלנו ועוזר לבנות הפרדה טובה בין שירותים שונים באפליקציה כללית.

הפתרון

כנראה כבר הבנתם שהכיוון לפתרון הוא שההודעות אמורות להיכתב ל-GOOGLE Pub/Sub במקום ישירות ל-BQ. אבל מי יקרא אותן ואיפה הוא ימצא?

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

הקאץ’ הקטן הוא שהמכונה המינימלית שחייבים להשתמש בה ב-DATAFLOW צריכה להכיל 4 מעבדים ומומלץ להחזיק לפחות 2 מכונות כאלה. אנחנו לא צריכים את הכוח הזה (וגם רוצים לחסוך). הלולאה הפשוטה שקוראת פעם בשנייה מה-Pub/Sub ושולחת כל ההודעות שהצטברו ל-BIGQUERY עובדת מצויין במכונה עם מעבד אחד.

אז איפה נחזיק את השירות עם הלולאה שלנו?

בעולם הענן של גוגל נשארו לנו 2 אופציות: GCE – Google Compute Engine; ו-GKE – Google Kubernetes Engine. האופציה הראשונה דורשת יותר ניהול, וכמו שכבר הבנתם אנחנו אוהבים להתרכז במוצר ולא בניהול תשתית, לכן בחרנו את האופציה השנייה.

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

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

מה זה GKE? שירות GKE הינו שירות מנוהל של גוגל למערכת קוד פתוח Kubernetes, מערכת של ניהול יישומים על גבי קונטיינרים. היא מגדירה אבני בניין שונים של תחזוקה של מערכות מבוזרות. בעצם, כל מה היינו רגילים אליו ב-GAE קיים כאן וניתן לשליטה – עדכונים שוטפים, התאמה לעומסים, ניהול הרשאות וחיבור לכל השירותים השונים של Google Cloud.

כבונוס נחמד – ניתן להגדיר מכונות להיות preemptible (כלומר ניתנות להחלפה פעם ב-24 שעות) ולקבל הנחה של 80% במחיר. זה מתאים לגמרי במקרה הבוחן שלנו כי אין לנו שום state ולכן המכונות שלנו מוכנות למות בכל רגע ללא בעיה. שוב, אנחנו מתייחסים ל-GKE, אבל היכולת הזאת היא לא ייחודית לגוגל קלאו. אם אתם לקוחות AWS, תוכלו להשתמש ב-spot instances, ואם אתם ב-Azure, תוכלו להשתמש ב-Spot VM.

הפתרון המלא

שנעשה חישוב מהיר?

ההכנסה ל-Pub/Sub היא מאוד מהירה ומספיק לנו חמישה instances כדי לשרת את כל הבקשות. העלות של GAE יורדת פי 10 – והופכת ל-$180 לחודש; Pub/Sub – עולה $1 ליום – $30 לחודש; Kubernetes – מספיק לנו 2 מכונות עם מעבד אחד – $48 לחודש; ההנחה של מכונות שהן preemptible משאירה לנו $9.6 לחודש; סה”כ – $180 + $30 + $9.6 = $219.6 – כלומר חיסכון של 88% מהעלות של $1,800 שהיתה לנו.

כפי שהזכרתי בתחילת הדוגמה, $1,800 זה רק חלק קטן מכלל ההוצאות, אבל החיסכון של 90% ישים לכל השאר.

לסיכום

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

הכותבת היא CTO בחברת Fast Simon

Avatar

כתבת אורחת

הגב

20 תגובות על "איך חסכנו 90% מעלויות השימוש שלנו בענן של גוגל"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
דימה
Guest

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

One Nose
Guest

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

יפה מאוד.

אורן
Guest

בסופו של דבר היה ניתן להוריד את העלות בלי לעבור לקוברנטיס. ניתן להשתמש בשרתי ספוט גם בECS/EC2 וגם בGCE.

ארז
Guest

כתבה מעולה, מעניינת, בלי פרסום ומקצועי.
שאפו.

חיים
Guest

כיף לקרוא כתבה מקצועית שלא זועקת “תוכן ממומן”.
אהבתי גם את האיזכורים לשירותים מקבילים בגוגל ובאמזון.

עמית
Guest

אחלה כתבה!
יש לך אולי טיפים נוספים מהנסיון איך לחסוך עלויות ב- GAE מבלי לעבור ל- Kubernetes?

אורח
Guest

תעלו את המשכורת לכתבת שכתבה את הכתבה המעניינת הזו, בלי תוכן שיווקי שצועק “תוכן ממומן”, פשוט תענוג.
אגב, מה עם הענן של Oracle ?

גון
Guest

הענן של מי?

אברהם
Guest

הכתבת היא CTO בחברת Fast Simon אם ששילמו לה רק על הכתבה הזאת, או שהיא פשוט רצתה במה לפרסם את דבריה (שזה מצויין), אבל משכורת מGeekTime – היא לא מקבלת

אייל
Guest

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

Rel
Guest

אכן מעניין, רק שהכותרת לא ממש נכונה, חסכתם על ידי redsign של המערכת ושימוש message q, הקוברנטיס כאן שולי לחלוטין ולא חסך כלום. היה יכל לחסוך אם גם את השרתים הייתם מעבירים, במקום GAE

דני
Guest

מדויק

הבאובב
Guest

כתבה מעולה – ישר ולעניין!

ירוו
Guest

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

גגג
Guest

פשוט היה כיף לקרוא. תוכן מעולה וכתיבה משובחת

יורי
Guest

כתבה מעולה !!!

גון
Guest

מגניב שמצאתם תירוץ לעבור לk8s אבל בשביל datapipeline כמו שרבים כתבו פה, אפשר לרוץ גם בלי :)

יהודה
Guest

כתבה מעניינת ומפורטת.

עמי
Guest

קצר ברור ולעניין – מעולה!

נתן
Guest

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

wpDiscuz

תגיות לכתבה: