סקירה כללית של ארכיטקטורת השירות להערכת מראה המבוססת על רשתות עצביות

כניסה

היי!

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

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

תהנה קריאה!

כמה מילים על הבעיה ופתרונה

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

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

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

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

1. בחירת פרצופים בתמונות
2. דירוג של כל אדם
3. עבד את התוצאה

הראשון נפתר על ידי הכוחות של מאומנים מראש MTCNN. עבור השני, רשת נוירונים קונבולוציונית אומנה על PyTorch, באמצעות 34. ResNetXNUMX - מהאיזון "איכות / מהירות מסקנות על המעבד"

תרשים פונקציונלי של צינור הערכה

ניתוח דרישות ארכיטקטורת הפרויקט

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

מחזור חיים של פרויקט ML

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

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

אדריכלות

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

על מנת להיפטר מכאבי ראש מיותרים, נבחר ה-API של Telegram כ-frontend.

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

תרשים מבני של הארכיטקטורה המוגמרת

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

Microservice "attrai-telegram-bot"

שירות מיקרו זה מקפל את כל האינטראקציות עם ה-API של Telegram. ישנם 2 תרחישים עיקריים: עבודה עם תמונה מותאמת אישית ועבודה עם תוצאה של צינור הערכה. בואו נסתכל על שני התרחישים במונחים כלליים.

בעת קבלת הודעה מותאמת אישית עם תמונה:

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

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

כאשר מקבלים משימה חדשה מ-"after_estimate":

1. אם התמונה מעובדת בהצלחה, אנו שולחים את התוצאה למשתמש; אם לא, אנו מודיעים על שגיאה.
2. הסרת התמונה שהיא תוצאה של צינור ההערכה

הערכה microservice "attrai-estimator"

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

כאשר מקבלים משימה חדשה מ-"to_estimate":

1. בואו נעביר את התמונה דרך צינור ההערכה:
   1. טעינת התמונה לזיכרון
   2. אנו מביאים את התמונה לגודל הנדרש
   3. מציאת כל הפנים (MTCNN)
   4. אנו מעריכים את כל הפרצופים (אנו עוטפים את הפרצופים שנמצאו בשלב האחרון באצווה ומסיקים את ResNet34)
   5. עבד את התמונה הסופית
      1. בואו נצייר את התיבות התוחמות
      2. ציור הרייטינג
2. מחיקת תמונה מותאמת אישית (מקורית).
3. שמירת הפלט מצינור ההערכה
4. שמנו את המשימה בתור "לאחר_הערכה", אליו מקשיבים המיקרו-שירות "attrai-telegram-bot" שנדון לעיל.

Graylog (+ mongoDB + Elasticsearch)

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

הבחירה נפלה עליו, ולא על הרגילה דִישׁוֹן מחסנית, בשל הנוחות בעבודה איתו מ-Python. כל מה שאתה צריך לעשות כדי להיכנס ל-Graylog הוא להוסיף את GELFTCPHandler מהחבילה אפור לשאר המטפלים ב-Root Loger של מיקרו-שירות הפיתון שלנו.

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

RabbitMQ

RabbitMQ הוא מתווך הודעות המבוסס על פרוטוקול AMQP.

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

Redis

Redis הוא NoSQL DBMS שעובד עם מבני נתונים של ערך מפתח

לפעמים יש צורך להשתמש באובייקטים נפוצים המיישמים מבני נתונים מסוימים במיקרו-שירותי Python שונים.

לדוגמה, Redis מאחסנת מפת hash בצורת "telegram_user_id => מספר המשימות הפעילות בתור", המאפשרת להגביל את מספר הבקשות ממשתמש אחד לערך מסוים ובכך למנוע התקפות DoS.

בואו ננסח את התהליך של עיבוד תמונה מוצלח

1. המשתמש שולח תמונה לבוט הטלגרם
2. "attrai-telegram-bot" מקבל הודעה מה-API של Telegram ומנתח אותה
3. המשימה עם התמונה מתווספת לתור האסינכרוני "להערכה"
4. המשתמש מקבל הודעה עם זמן ההערכה המתוכנן
5. "attrai-estimator" לוקח משימה מהתור של "להעריך", מריץ את ההערכות דרך הצינור ומפיק את המשימה לתור "אחרי_הערכה"
6. "attrai-telegram-bot" מאזין לתור "אחר_הערכה", שולח את התוצאה למשתמש

דופים

לבסוף, לאחר סקירת הארכיטקטורה, תוכלו לעבור לחלק המעניין לא פחות – DevOps

נחיל דוקר

 

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

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

אשכול עם מנהל מנהיג אחד ושלושה עובדים

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

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

Docker Stack

במצב נחיל, הוא אחראי על פריסת ערימות (סטים של שירותי עגינה) מחסנית docker

הוא תומך בתצורות docker-compose, מה שמאפשר לך להשתמש בנוסף באפשרויות הפריסה.  

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

attrai_estimator:
  image: 'erqups/attrai_estimator:1.2'
  deploy:
    replicas: 4
    resources:
      limits:
        cpus: '4'
    restart_policy:
      condition: on-failure
      …

חשוב לציין ש- Redis, RabbitMQ ו- Graylog הם שירותים ממלכתיים ולא ניתן להתאים אותם בקלות כמו "אומדן אטרקטיבי"

מבשרת את השאלה - למה לא Kubernetes?

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

תשתית

כל זה נפרס על VDS עם המאפיינים הבאים:

• מעבד: מעבד 4 ליבות Intel® Xeon® Gold 5120 @ 2.20GHz
• RAM: 8 GB
• SSD: 160 ג'יגה-בתים

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

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

עוד קצת גרפיקה

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

התפלגות זמן מסקנת צינור הערכה

ממצאים

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

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

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

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

מקור: www.habr.com