אחורי, למידת מכונה וללא שרתים - הדברים הכי מעניינים מכנס יולי Habr

ועידת הבר אינו סיפור בכורה. בעבר ערכנו אירועי טוסטר גדולים למדי ל-300-400 איש, אך כעת החלטנו שיהיו רלוונטיים פגישות נושאיות קטנות, שאת הכיוון שלהן תוכלו לקבוע, למשל, בהערות. הכנס הראשון בפורמט זה נערך ביולי והוקדש לפיתוח עורפי. המשתתפים האזינו לדיווחים על תכונות המעבר מה-backend ל-ML ועל עיצוב שירות Quadrupel בפורטל שירותי המדינה, וכן לקחו חלק בשולחן עגול שהוקדש ל-Serverless. למי שלא הצליח להגיע לאירוע באופן אישי, בפוסט הזה אנחנו מספרים לכם את הדברים הכי מעניינים.

מפיתוח אחורי ועד למידת מכונה

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

אלכסנדר פארינוב

כיום אלכסנדר עובד כאדריכל מערכות ראייה ממוחשבת ב-X5 Retail Group ותורם לפרויקטים של קוד פתוח הקשורים לראייה ממוחשבת ולמידה עמוקה (github.com/creafz). כישוריו מאושרים על ידי השתתפותו ב-100 המובילים בדירוג העולמי של Kaggle Master (kaggle.com/creafz), הפלטפורמה הפופולרית ביותר לתחרויות למידת מכונה.

למה לעבור ללמידת מכונה

לפני שנה וחצי תיאר ג'ף דין, ראש Google Brain, פרויקט מחקר בינה מלאכותית מבוססת למידה עמוקה של גוגל, כיצד חצי מיליון שורות קוד בגוגל טרנסלייט הוחלפו ברשת נוירונים Tensor Flow המורכבת מ-500 קווים בלבד. לאחר הכשרת הרשת, איכות הנתונים עלתה והתשתית הפכה לפשוטה יותר. נראה שזהו העתיד המזהיר שלנו: אנחנו כבר לא צריכים לכתוב קוד, זה מספיק כדי ליצור נוירונים ולמלא אותם בנתונים. אבל בפועל הכל הרבה יותר מסובך.

תשתית ML בגוגל

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

תהליך למידת מכונה

מה ההבדל בין ML ל-backend?

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

ניהול גרסאות נתונים

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

סימון נתונים

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

הדמיה ב- Tensor Board

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

ישנן פלטפורמות רבות ללמידת מכונה, אך אף אחת מהן לא מכסה 70% מהצרכים

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

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

דגם כקופסה שחורה

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

תהליך שרת נפרד עם דגם

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

דוגמה לשימוש במודל ב-Flask:

@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)

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

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

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

איך AutoML עובד

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

איך להיכנס ללמידת מכונה

הדרך הקלה ביותר להיכנס ל-ML היא אם אתה מפתח ב-Python, המשמש בכל מסגרות הלמידה העמוקה (והמסגרות הרגילות). שפה זו היא כמעט חובה עבור תחום פעילות זה. C++ משמש עבור כמה משימות ראייה ממוחשבת, למשל, במערכות בקרה למכוניות בנהיגה עצמית. JavaScript ו-Shell - להדמיה ודברים מוזרים כמו הפעלת נוירון בדפדפן. Java ו-Scala משמשים בעבודה עם ביג דאטה ולמידת מכונה. R וג'וליה אהובים על אנשים שלומדים סטטיסטיקה מתמטית.

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

אפשרות נוספת היא להצטרף לצוות ML כמפתח backend. יש הרבה סטארט-אפים של למידת מכונה שבהן אתה יכול לצבור ניסיון על ידי עזרה לעמיתיך לפתור את הבעיות שלהם. לבסוף, תוכלו להצטרף לאחת מקהילות מדעני הנתונים - Open Data Science (ods.ai) ואחרות.

הדובר פרסם מידע נוסף על הנושא בקישור https://bit.ly/backend-to-ml

"Quadrupel" - שירות של הודעות ממוקדות של הפורטל "שירותי מדינה"

יבגני סמירנוב

הדובר הבא היה ראש מחלקת פיתוח תשתיות לממשל אלקטרוני, יבגני סמירנוב, שדיבר על קוואדרופל. זהו שירות הודעות ממוקד עבור פורטל Gosuslugi (gosuslugi.ru), המשאב הממשלתי הפופולרי ביותר ב- Runet. הקהל היומי הוא 2,6 מיליון, בסך הכל יש 90 מיליון משתמשים רשומים באתר, מתוכם 60 מיליון מאושרים. העומס על ה-API של הפורטל הוא 30 אלף RPS.

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

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

איך עובד Quadrupel?

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

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

ערוצי הודעות קוואדרופל

מתחת למכסה המנוע של Quadrupel יש מסד נתונים שבו מאוחסנים נתוני משתמש, ושלושה יישומים: 

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

Для обновления данных бэкенд событийно ориентирован. Два интерфейса — рест или JMS. Событий много, перед сохранением и обработкой они агрегируются, чтобы не делать лишних запросов. Сама БД, табличка, в которой хранятся данные, выглядит как key value хранилище – ключ пользователя и само значение: флажки, обозначающие наличие или отсутствие соответствующих документов, их срок действия, агрегированная статистика по заказу услуг этим пользователем и прочее.

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

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

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

Backend-as-a-Service לעומת ללא שרת

משמאל לימין: אלכסנדר בורגרט, אנדריי טומילנקו, ניקולאי מרקוב, ארא ישראליאן

Backend כשירות או פתרון ללא שרת? המשתתפים בדיון בנושא דחוף זה בשולחן העגול היו:

• Ara Israelyan, CTO CTO ומייסד Scorocode.
• ניקולאי מרקוב, מהנדס נתונים בכיר בקבוצת המחקר Aligned.
• אנדריי טומילנקו, ראש מחלקת הפיתוח של RUVDS. 

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

- מה זה חסר שרת בהבנתך?

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

— האם ללא שרת זהה לשירותי מיקרו?

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

- איזה מאזניים טוב יותר?

ara: בעת שינוי קנה מידה אופקית, פונקציות Lambda מתנהגות בדיוק כמו microservices.
ניקולס: לא משנה מה מספר העתקים שתגדיר, יהיו כמה שיותר מהם; ל-Serverless אין בעיות בשינוי קנה מידה. הכנתי ערכת העתק ב-Kubernetes, השקתי 20 מופעים "איפשהו", ו-20 קישורים אנונימיים הוחזרו אליך. קָדִימָה!

— האם ניתן לכתוב backend ב-Serverless?

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

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

אנדרו: משימות שאינן דורשות אחסון משותף - אותה כרייה, בלוקצ'יין. איפה אתה צריך לעשות הרבה ספירה. אם יש לך כוח מחשוב רב, אז אתה יכול להגדיר פונקציה כמו "לחשב את ה-hash של משהו שם..." אבל אתה יכול לפתור את הבעיה עם אחסון נתונים על ידי לקיחת, למשל, פונקציות Lambda מאמזון והאחסון המבוזר שלהן . ומסתבר שאתה כותב שירות קבוע. פונקציות Lambda יגשו לאחסון ויספקו מענה כלשהו למשתמש.
ניקולס: קונטיינרים הפועלים ב-Serverless מוגבלים ביותר במשאבים. יש מעט זיכרון וכל השאר. אבל אם כל התשתית שלך פרוסה כולה על ענן כלשהו - גוגל, אמזון - ויש לך חוזה קבוע איתם, יש תקציב לכל זה, אז עבור כמה משימות אתה יכול להשתמש בקונטיינרים ללא שרת. יש צורך להיות בתוך התשתית הזו, כי הכל מותאם לשימוש בסביבה ספציפית. כלומר, אם אתם מוכנים לקשור הכל לתשתית הענן, תוכלו להתנסות. היתרון הוא שאתה לא צריך לנהל את התשתית הזו.
ara: העובדה ש-Serverless לא מחייבת אותך לנהל את Kubernetes, Docker, להתקין את Kafka וכן הלאה היא הונאה עצמית. אותן אמזון וגוגל מתקינות את זה. דבר נוסף הוא שיש לך SLA. אתה יכול באותה מידה לבצע מיקור חוץ של הכל במקום לקודד אותו בעצמך.
אנדרו: Serverless עצמו לא יקר, אבל אתה צריך לשלם הרבה עבור שירותי אמזון אחרים - למשל, מסד הנתונים. אנשים כבר תבעו אותם כי הם גבו סכומי כסף מטורפים עבור שער ה-API.
ara: אם אנחנו מדברים על כסף, אז צריך לקחת בחשבון את הנקודה הזו: תצטרכו להפוך את כל מתודולוגיית הפיתוח בחברה ב-180 מעלות על מנת להעביר את כל הקוד ל-Serverless. זה ייקח הרבה זמן וכסף.

- האם יש חלופות ראויות לשרת ללא תשלום מאמזון וגוגל?

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

- עד כמה חשוב לעקוב אחר מה שקורה ב-Serverless?

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

- בוא נסכם את זה.

אנדרו: חשיבה על פונקציות Lambda היא שימושית. אם אתה יוצר שירות בעצמך - לא מיקרו-שירות, אלא כזה שכותב בקשה, ניגש למסד הנתונים ושולח תגובה - פונקציית Lambda פותרת מספר בעיות: עם ריבוי הליכי שרשור, מדרגיות וכו'. אם ההיגיון שלכם בנוי בצורה כזו, אז בעתיד תוכלו להעביר את ה-Lambdas הללו לשירותי מיקרו או להשתמש בשירותי צד שלישי כמו אמזון. הטכנולוגיה שימושית, הרעיון מעניין. עד כמה זה מוצדק לעסקים היא עדיין שאלה פתוחה.
ניקולאי: ללא שרת משמש טוב יותר למשימות תפעול מאשר לחישוב לוגיקה עסקית כלשהי. אני תמיד חושב על זה כעל עיבוד אירועים. אם יש לך את זה באמזון, אם אתה ב-Kubernetes, כן. אחרת, תצטרך להשקיע די הרבה מאמץ כדי להפעיל את Serverless בעצמך. יש צורך להסתכל על מקרה עסקי ספציפי. למשל, אחת המשימות שלי עכשיו היא: כשקבצים מופיעים בדיסק בפורמט מסוים, אני צריך להעלות אותם לקפקא. אני יכול להשתמש ב-WatchDog או ב-Lambda. מנקודת מבט הגיונית, שתי האפשרויות מתאימות, אבל מבחינת יישום, Serverless יותר מסובך, ואני מעדיף את הדרך הפשוטה יותר, ללא Lambda.
ara: ללא שרת הוא רעיון מעניין, ישים ויפה מאוד מבחינה טכנית. במוקדם או במאוחר, הטכנולוגיה תגיע לנקודה שבה כל פונקציה תושק תוך פחות מ-100 מילישניות. ואז, באופן עקרוני, לא תהיה שאלה האם זמן ההמתנה קריטי למשתמש. יחד עם זאת, הישימות של Serverless, כפי שכבר אמרו עמיתים, תלויה לחלוטין בבעיה העסקית.

אנו מודים לנותני החסות שלנו שעזרו לנו רבות:

• חלל ועידות IT «אביב» לאתר הכנס.
• לוח אירועי IT Runet-ID ופרסום"אינטרנט במספרים» לתמיכה במידע וחדשות.
• «אקרוניס"עבור מתנות.
• אביטו ליצירה משותפת.
• "האגודה לתקשורת אלקטרונית" RAEC על מעורבות וניסיון.
• נותן חסות עיקרי RUVDS - לכולם!

מקור: www.habr.com