איך יצרנו את Cloud FaaS בתוך Kubernetes וזכינו בהאקתון של Tinkoff

החל משנה שעברה, החברה שלנו החלה לארגן האקתונים. התחרות הראשונה כזו הייתה מוצלחת מאוד, כתבנו עליה ב статье. ההאקתון השני התקיים בפברואר 2019 והיה מוצלח לא פחות. על המטרות להחזיק את האחרון לא כל כך מזמן כתבתי מְאַרגֵן.

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

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

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

מה זה ניקוד

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

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

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

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

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

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

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

מְשִׁימָה

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

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

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

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

הפתרון שלנו

לאחר סיעור מוחות קטן, החלטנו שפתרון FaaS יהיה אידיאלי להשלמת המשימה.

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

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

1. האנליסט כותב סקריפט, כלל או מודל ML המבוסס על נתונים מהמחסן. במסגרת ההאקתון החלטנו להשתמש ב-Mongodb, אך בחירת מערכת אחסון הנתונים אינה חשובה כאן.
2. לאחר בדיקת הכללים שפותחו על נתונים היסטוריים, האנליסט מעלה את הקוד שלו לפאנל הניהול.
3. כדי להבטיח ניהול גרסאות, כל הקוד יעבור למאגרי Git.
4. דרך פאנל הניהול ניתן יהיה לפרוס את הקוד בענן כמודול פונקציונלי נפרד של Serverless.

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

עוד לפני ההאקתון, החלטנו על המסגרת Serverless שבה נשתמש. כיום יש בשוק לא מעט טכנולוגיות שמיישמות גישה זו. הפתרונות הפופולריים ביותר בארכיטקטורת Kubernetes הם Fission, Open FaaS ו-Kubeless. יש אפילו מאמר טוב עם התיאור והניתוח ההשוואתי שלהם.

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

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

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

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

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

מה שקיבלנו

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

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

הארכיטקטורה של הפרויקט שלנו הייתה כדלקמן:

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

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

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

החלטנו להשתמש ב-MongoDB כאחסון במערכת שלנו עקב אחסון נתונים מונחה מסמכים בצורה של מסמכי JSON, שכן שירותי ההעשרה, כולל הבקשה המקורית, אספו את כל הנתונים באמצעות בקרי REST.

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

1. פאנלים קדמיים של ניהול לעבודה של האנליסט, דרכם יכול היה להוריד כללים ממערכת בקרת הגירסאות של סקריפטים כתובים, לבחור אפשרויות להעשרת נתוני קלט ולערוך סקריפטים של כללים באינטרנט.
2. אדמין אחורי, כולל REST API לחזית ואינטגרציה עם VCS.
3. הקמת תשתית ב-Google Cloud ופיתוח שירות להעשרת נתוני מקור.
4. מודול לשילוב אפליקציית הניהול עם ה-Serverless framework לצורך פריסה של כללים בהמשך.
5. סקריפטים של כללים לבדיקת ביצועי המערכת כולה וצבירת אנליטיקה על אפליקציות נכנסות (התקבלו החלטות) להדגמה הסופית.

בואו נתחיל בסדר.

החזית שלנו נכתבה ב-Angular 7 באמצעות ערכת ממשק המשתמש הבנקאית. הגרסה הסופית של פאנל הניהול נראתה כך:

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

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

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

הקצה האחורי של הפלטפורמה נכתב ב-Java והוטמע כיישום Spring Boot. תחילה תכננו להשתמש ב-Postgres כדי לאחסן נתוני ניהול, אבל, כחלק מההאקתון, החלטנו להגביל את עצמנו ל-H2 פשוט כדי לחסוך זמן. בקצה העורפי, הוטמע אינטגרציה עם Bitbucket לגרסה של פונקציות העשרת השאילתות וסקריפטים של כללים. לשילוב עם מאגרי Git מרוחקים, השתמשנו ספריית JGit, שהוא סוג של עטיפה על פקודות CLI, המאפשר לך לבצע כל הוראות git באמצעות ממשק תוכנה נוח. אז היו לנו שני מאגרים נפרדים לפונקציות וכללים העשרה, וכל התסריטים חולקו לספריות. דרך ממשק המשתמש ניתן היה לבחור את ה-commit האחרון של סקריפט של ענף שרירותי של המאגר. בעת ביצוע שינויים בקוד דרך פאנל הניהול, נוצרו התחייבויות של הקוד שהשתנה במאגרים מרוחקים.

כדי ליישם את הרעיון שלנו, היינו צריכים תשתית מתאימה. החלטנו לפרוס את אשכול Kubernetes שלנו בענן. הבחירה שלנו הייתה Google Cloud Platform. המסגרת ללא שרת Fission הותקנה על אשכול Kubernetes, אותו פרסנו ב-Gcloud. בתחילה, שירות העשרת נתוני המקור יושם כיישום Java נפרד עטוף ב-Pod בתוך אשכול k8s. אבל לאחר הדגמה ראשונית של הפרויקט שלנו באמצע ההאקתון, הומלץ לנו להגמיש את שירות ההעשרה כדי לספק את האפשרות לבחור כיצד להעשיר את הנתונים הגולמיים של אפליקציות נכנסות. ולא הייתה לנו ברירה אלא להפוך את שירות ההעשרה גם ללא שרת.

כדי לעבוד עם Fission, השתמשנו ב-Fission CLI, שיש להתקין על גבי Kubernetes CLI. פריסת פונקציות לתוך אשכול k8s היא די פשוטה; אתה רק צריך להקצות נתיב פנימי וכניסה לפונקציה כדי לאפשר תעבורה נכנסת אם יש צורך בגישה מחוץ לאשכול. פריסת פונקציה אחת נמשכת בדרך כלל לא יותר מ-10 שניות.

הצגה סופית של הפרויקט וסיכום

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

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

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

היו בסך הכל 3 מוצרי בנק פיקטיביים זמינים:

• אַשׁרַאי.
• צעצוע
• משכנתא.

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

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

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

כדי לאסוף ניתוחים מקוונים, פרסנו בנוסף כלי BI בקוד פתוח בסיס נתונים והברגה אותו ליחידת האחסון שלנו. Metabase מאפשר לך לבנות מסכים עם אנליטיקה על הנתונים שמעניינים אותנו; אתה רק צריך לרשום חיבור למסד הנתונים, לבחור טבלאות (במקרה שלנו, איסוף נתונים, מכיוון שהשתמשנו ב-MongoDB), ולציין את התחומים המעניינים אותנו .

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

מקור: www.habr.com