כך תנהלו תהליכי data באמצעות טכנולוגיות serverless ותחסכו זמן רב

אם תשקיעו 5 דקות ביצירת BIJO תוכלו לחסוך למפתחים שלכם זמן רב. אז מה זה BIJO ואיך זה עובד?

מקור: Pixabay

מאת תומר לוי 

ברוב חברות הדאטה קיימים מספר בעלי תפקידים כמו Data Analysts – משתמשים בדאטה כדי לשפר תהליכים קיימים (למשל, בדיקת כדאיות של יכולת חדשות במוצר) וניתוחים פיננסים; Data Scientists – משתמשים במודלים מתמטיים וסטטיסטיים כדי להסיק מסקנות מדאטה, לדוגמה: בניית מודל סטטיסטי שחוזה האם הלקוח ירכוש שירות של החברה ב-30 יום הקרובים; Data Engineers – אחראיים על שינוע המידע ועיבודו, אבטחת הדאטה, ומתפקדים כ״מנגישי״ הדאטה לשני בעלי התפקידים הקודמים ולשאר החברה.

כמובן שישנם בעלי תפקידים נוספים הניגשים למידע של החברה אך שלושת אלו הם המשתמשים ה״כבדים״ ביותר. כדי שהם יוכלו לבצע את עבודתם הם יכולים להשתמש במגוון די רחב של כלים. Data Engineers נעזרים ב-ETL, כדי לטפל במידע חדש ולשנע אותו פנימה לתוך ה-Data Lake או ה-Warehouse.

כשהחברה וכמות המידע קטנות, הדרך שבה מהנדס או Data Scientist, מריצים את תהליכי הדאטה שלהם היא די ״פרימיטיבית״. מתחברים לשרת מרוחק דרך SSH, מעלים את הקוד (בד״כ Python או SQL שרץ באמצעות Python) לשרת ומריצים. כשנדרש תזמון של משימות פשוט עורכים את קובץ ההגדרה של crontab.

ככל שגדלה החברה ותהליכים אלו הפכו לפופולאריים יותר, מורכבים יותר ובעלי דרישות שונות התלוו אליהם גם הבעיות.

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

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

נקודת המפנה

בנקודה מסויימת הגענו למסקנה כי דרוש שינוי, ולכן המצאנו את BIJO, שירות שיעשה סדר ויתן מענה לכל הבעיות. השירות שהחל דרכו כ-BI Job Orchestrator ומשם גם שמו, הפך במהרה לפופולארי ותרם לביצוע מגוון רחב של תהליכים, BI מהווה רק חלק מאותם תהליכים. את השם השארנו.

בתכנון של BIJO החלטנו על שלושה קווים מנחים:

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

ניטור – משתמשים בשירות יקבלו גישה לנתוני הריצה של התהליך שלהם, יקבלו התראות על שגיאות ויוכלו לקרוא את הלוג של התהליך

ניתן להרחבה – השירות יהיה ניתן להרחבה ושימוש ע״י משתמשים מתקדמים. ב-OOP קיים עקרון שאני מאוד מחבב ומקפיד להשתמש בו שנקרא S.O.L.I.D, כשהאות O מגיעה מתת-עקרון הנקרא “Open/Close principle”, שמשמעותו היא שקוד צריך להיות פתוח להרחבה אך סגור לשינויים. עקרון זה הוביל אותנו בקו מנחה זה.

פשטות

אז כמה זה פשוט? מאוד!

כדי ליצור תהליך ב-BIJO כל שצריך הוא:

לייצר תיקייה ב-Github Repository ייעודי
בתיקייה זו ליצור קובץ config.yaml שמגדיר את סוג התהליך ואת התזמון הרצוי
להעתיק את הקוד או סקריפט SQL שאותו רוצים להריץ לתוך תיקייה בשם resources
בסיום, מעלים ל-repository ע״י pull request
ומקבלים התראה ל-Slack במידה ויש כשלון

בדוגמה זו ניתן לראות כיצד יצרנו תהליך חדש בשם integration-s3, בתיקייה של התהליך מיקמנו את תיקיית resources וגם את קובץ ה-config.yaml כנדרש, ניתן לראות שהקובץ מכיל מאפיינים פשוטים כמו type, אשר קובע את סוג התהליך – python/sql וכן הגדרות נוספות אשר קובעות מה יהיה ה-trigger לתהליך.

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

כיצד זה עובד?

מאחורי הקלעים, כל תיקייה כזו נארזה לתוך Docker container והועלתה ל-ECR – שירות Registry מנוהל ל-Docker

לרשותנו 2 סוגי תהליכים:

  1. תהליכים המשתמשים בקוד Python – פשוט רצו ב-Container ללא שינויים.
    לדוגמה: python my job.py
  2. תהליכים המשתמשים בסקריפט SQL – מכיוון שסקריפט SQL אינו יכול לרוץ בכוחות עצמו, נארז יחד איתו קוד ייעודי שפיתח הצוות כחלק מהתשתית, פקודת הריצה לקונטיינר הותאמה לכך. לדוגמה: python default_sql_runner.py my_job.sql

ניטור

אריזת התהליכים לתוך קונטיינר בהחלט גרמה ל-BIJO להיות פשוט ומודולארי אך זהו צעד מזערי בתשתית. ניטור הוא ללא ספק אחד החלקים החשובים ביותר בדרך להשגת תשתית ברמת “production level”.

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

AWS Step Functions הוא שירות המאפשר תיאום בין מספר רב של שירותים ב-AWS. באמצעות הגדרה די פשוטה (json), ניתן ליצור State Machine ולחבר שירותים כמו AWS Lambda ו-ECS יחד ליצירת ערך משותף. לדוגמה:

ה-Step Function בתמונה לקוח מתוך BIJO, כל תהליך ב-BIJO מתורגם ל-Step Function כזו. התרשים מתחיל בקודקוד העליון כאשר מגיע ה-trigger (לפי לוח זמנים, תלות בתהליך אחר, קובץ שהגיע ועוד), במרכז רואים את הצעד העיקרי Run Fargate Task אשר מריץ את ה-Docker container בסופו, מחליטים האם לשלוח הודעת הצלחה או כישלון.

די בפשטות יצרנו תהליך שמריץ Docker container על ECS (שירות לניהול containers) ושולח הודעת SNS.

התמונה הבאה מציגה כישלון של Step Function:

ה-Step Function שלנו צריכה כמובן להשתמש בתשתית עוטפת ע״מ להריץ את ה-Container וכן יעד אליו ישלחו הודעות הסיום. בשלב זה התשתית נראית כך:

בחלק השמאלי רואים את השירותים עליהם דיברנו קודם לכן, במרכז את Step Functions המהווה בסיס שעליו רצים התהליכים השונים ומתחתיו AWS Fargate שירות המאפשר להריץ Docker containers ללא צורך בשרתים מוגדרים מראש.

מימין ל- Step Functions, בסגול, שירות ה- SNS ֿהמאפשר שליחה וקבלת הודעות, אליו נשלחות הודעות הסיום של כל Step Function וממנו מופצות ל-2 AWS Lambda Functions.

הפונקציה העליונה – Sns-to-Slack – שולחת הודעות כשלון ל-Slack באמצעות Rest API שחושף Slack

הפונקציה השניה – Job-Dependency – קוראת את הודעות הסיום ומחליטה האם צריך להזניק פונקציות נוספות, את רשימת התלויות שומרת הפונקציה בטבלאות בתוך DynamoDB, המידע מגיע לפונקציה דרך Jenkins.

פונקציה זו היא תוספת מאוד חשובה ל-BIJO, תלות בין Step Functions מאפשרת למפתחים, Data Scientists ו-BI Engineers ליצור ערך לחברה יחד וללא תלות בתשתית.

קובץ ה-config.yaml בתמונה מעלה מכיל שורה המגדירה תלות שכזו, כאשר יסתיים התהליך בשם dataops/integration-s3 בהצלחה יוזנק התהליך המכיל קובץ זה. Jenkins קורא את הגדרות ה-depends-on  ושולח אותן ל-Lambda Functions אשר שומרת את התלויות ב-DynamoDB כאמור.

בצד השמאלי של הארכיטקטורה, השתמשנו ב- CloudWatch לשתי משימות, האחת תזמון של התהליכים באמצעות Cron Expression. והשניה שמירת הודעות ה-Log של התהליכים.

*על API Gateway נרחיב בהמשך

ניתן להרחבה

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

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

כדי לשפר זאת החלטנו לפתח API שיאפשר למפתחים גישה ל-BIJO מבחוץ. הממשק שהתווסף מנגיש למפתחים את סט הכלים הבא:

– הרצה של תהליכים on-demand
– קבלת היסטוריית ריצה של תהליך מסוים וסטטוס נוכחי (נכשל/הצליח/בריצה)
– שליחת מידע מתוך BIJO ל-Slack. מידע הכולל טקסט, גרפים ועוד.

הפיתוח של ה- API התאפשר בקלות בזכות הארכיטקטורה של BIJO. פרקטית, של שהיה עלינו לעשות כדי לפתח את ה-API הוא להוסיף פונקצית Lambda אחת.

לאחר תוספת זו, הארכיטקטורה נראית כך:

הפונקציה שנוספה מופיעה בריבוע התכלת בתמונה מעל. הפונקציה- Job-manager עונה לבקשות REST שמגיעות אליה דרך API Gateway.

API Gateway הוא שירות המאפשר למפתחים ליצור ממשקי REST או Web Socket מנוהלים בענן. היתרונות בשימוש בשירות זה הם רבים, במקום לתחזק שרת כגון Tomcat או Apache Web Server שעולים כסף גם אם ה-API אינו בשימוש, כאן משלמים לפי צורך ובנוסף מקבלים Scale לא מוגבל (על הנייר), ניטור, ניהול גרסאות ועוד.

פשטות – Take 2

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

כאשר תהליך נכשל, ב-90% מהמקרים נוכל לגלות את הסיבה ע״י קריאת הלוג של התהליך, לעומת זאת, תהליך שרץ כ-Docker container איפשהו ב-AWS קשה יותר לניטור ע״י משתמשים שאינם טכניים.

לכן, החלטנו לחשוף את כל היכולות של Job-manager דרך Slack ובנוסף לאפשר גישה ל-Log של התהליכים ישירות מ-Slack:

כדי לאפשר זאת, יצרנו Slack Bot ייעודי ל-BIJO, הבוט קיבל את הנתונים שלו באמצעות REST API שהוספנו לתשתית בדומה ל-Job-manager.

סיכום

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

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

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

במבחן התוצאה, BIJO משמש היום את כל בעלי התפקידים שהזכרנו בתחילת הכתבה, הזמן הממוצע של יצירת תהליך הוא פחות מ-5 דקות. נכון לזמן כתיבת שורות אלו מתקיימות למעלה מ-4000 ריצות של תהליכים בכל יום.

הכותב הינו Senior Data Engineer ב-Fundbox

 

כתב אורח

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

הגב

7 תגובות על "כך תנהלו תהליכי data באמצעות טכנולוגיות serverless ותחסכו זמן רב"

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

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

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

תומר תעשה לי אנליזה

barnash
Guest

סיבכת והסתבכת! היה אפשר לבנות הרבה יותר פשוט

דעה
Guest

“ולכן המצאנו את BIJO, שירות שיעשה סדר”
כשהייתי קטן היה משהו דומה במכולת והמוכר כל הזמן התייעץ איתו “מה קרה ביז’ו?”

מישהו
Guest

למה לעבוד כל כך קשה כשהשוק מפוצץ ב Jobe queres בכל מיני אוריינטציות. מה שתכתוב לעולם לא יגיע לרמה של Apache Airflow למשל

תומר לוי
Guest

אין ספק ש airflow הרבה יותר טוב בהרצה של גובים. ביז׳ו זה framework הרבה יותר רחב, יש לו סט שלם של APIs עבור messaging, notifications, parameter store ועוד המון. נושא ה scheduling הוא חלק חשוב אבל קטן ממנו

Itamar
Guest

אנחנו עשינו משהו שנראה די דומה, ואחת הנקודות הכי רגישות אצלנו היא ה-environment לכל קוד python.
איך יצרתם סביבה דינאמית? (או שהחלטתם על סביבה אחת המכילה את כולם?)

תומר לוי
Guest

אשמח לפרט לך – צור איתי קשר בלינקדאין?

wpDiscuz

תגיות לכתבה: