בשבוע שעבר הלכתי לכנס DUMP IT (https://dump-ekb.ru/) ביקטרינבורג ואני רוצה לספר לכם מה נדון בסעיפים Backend ו-Devops, והאם כנסים IT אזוריים ראויים לתשומת לב.
ניקולאי סברצ'קוב מ-Evil Martians על ללא שרתים
מה היה בכלל?
בסך הכל היו לכנס 8 חלקים: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science and Management.
האולמות הגדולים ביותר, אגב, נמצאים במדע וניהול)) עבור ~350 איש כל אחד. Backend ו-Frontend אינם קטנים בהרבה. חדר Devops היה הקטן ביותר, אך פעיל.
הקשבתי לדיווחים במדורי Devops ו-Backend ודיברתי קצת עם הרמקולים. ברצוני לדבר על הנושאים הנידונים ולסקור את החלקים הללו בכנס.
נציגי SKB-Kontur, DataArt, Evil Martians, Ekaterinburg web studio Flag, Miro (RealTimeBoard) דיברו במדורי Devops ו-Backend. נושאים מכוסים CI/CD, עבודה עם שירותי תור, רישום; נושאים ללא שרת ועבודה עם PostgreSQL ב-Go כוסו היטב.
היו גם דיווחים של Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, אבל לא הספקתי להשתתף בהם פיזית (הקלטות וידאו ושקופיות של הדוחות עדיין לא זמינים, הם מבטיחים לפרסם אותם תוך שבועיים ב-dump-ekb.ru).
מדור Devops
מה שהפתיע הוא שהמדור נערך באולם הקטן ביותר, כ-50 מקומות ישיבה. אנשים אפילו עמדו במעברים :) אני אספר לכם על הדיווחים שהצלחתי להקשיב להם.
אלסטי במשקל פטה-בייט
המדור התחיל בדיווח של ולדימיר ליל (SKB-Kontur) על Elasticsearch ב-Kontur. יש להם אלסטי גדול ועמוס למדי (~800 TB של נתונים, ~1.3 פטה-בייט בהתחשב ביתירות). Elasticsearch עבור כל שירותי Kontur הוא יחיד, מורכב מ-2 אשכולות (של 7 ו-9 שרתים), והוא כל כך חשוב שלקונטור יש מהנדס Elasticsearch מיוחד (למעשה, ולדימיר עצמו).
ולדימיר גם שיתף את מחשבותיו על היתרונות של Elasticsearch ועל הבעיות שהוא מביא.
הטבה:
- כל היומנים נמצאים במקום אחד, גישה נוחה אליהם
- אחסון יומנים למשך שנה וניתוחם בקלות
- מהירות גבוהה של עבודה עם יומנים
- הדמיית נתונים מגניבה מחוץ לקופסה
בעיות:
- מתווך מסרים הוא חובה (עבור Kontur תפקידו ממלא קפקא)
- תכונות של עבודה עם Elasticsearch Curator (נוצר מעת לעת עומס גבוה ממשימות רגילות ב- Curator)
- ללא הרשאה מובנית (רק עבור כסף נפרד, די גדול, או כתוספי קוד פתוח בדרגות שונות של מוכנות לייצור)
היו רק ביקורות חיוביות על Open Distro for Elasticsearch :) אותה בעיה של הרשאה נפתרה שם.
מאיפה הפטאבייט?הצמתים שלהם מורכבים משרתים עם 12*8 Tb SATA + 2*2 Tb SSD. אחסון קר ב-SATA, SSD רק עבור מטמון חם (אחסון חם).
שרתים 7+9, (7 + 9) * 12 * 8 = 1536 TB.
חלק מהשטח נמצא במילואים, מופרש לפיטורים וכו'.
יומנים מכ-90 אפליקציות נשלחים אל Elasticsearch, כולל כל שירותי הדיווח של Kontur, Elba וכו'.
תכונות הפיתוח ב-Serverless
הבא הוא דוח של רוסלן סרקין מ-DataArt על Serverless.
רוסלן דיבר על מה זה בכלל פיתוח עם גישת ה-Serverless, ומהן התכונות שלה.
Serverless היא גישה לפיתוח שבה מפתחים לא נוגעים בתשתית בשום צורה. דוגמה - AWS Lambda Serverless, Kubeless.io (Serverless בתוך Kubernetes), Google Cloud Functions.
יישום אידיאלי ללא שרת הוא פשוט פונקציה ששולחת בקשה לספק ללא שרת דרך שער API מיוחד. שירות מיקרו אידיאלי, בעוד AWS Lambda תומך גם במספר רב של שפות תכנות מודרניות. עלות התחזוקה והפריסה של תשתית הופכת לאפס במקרה של ספקי ענן, גם תמיכה באפליקציות קטנות תהיה זולה מאוד (AWS Lambda - $0.2 / 1 מיליון בקשות פשוטות).
המדרגיות של מערכת כזו היא כמעט אידיאלית - ספק הענן דואג לזה בעצמו, Kubeless מדרג אוטומטית בתוך אשכול Kubernetes.
יש חסרונות:
- פיתוח יישומים גדולים הופך לקשה יותר
- יש קושי עם יישומי פרופיל (רק יומנים זמינים לך, אבל לא פרופיל במובן הרגיל)
- ללא גרסאות
למען האמת, שמעתי על Serverless לפני כמה שנים, אבל כל השנים האלה לא היה ברור לי איך להשתמש בו נכון. לאחר הדו"ח של רוסלן, הופיעה הבנה, ואחרי הדו"ח של ניקולאי סברצ'קוב (אנוסים מרושעים) מהמדור האחורי, הוא אוחד. לא בכדי הלכתי לכנס :)
CI מיועד לעניים, או ששווה לכתוב CI משלך לאולפן אינטרנט?
מיכאיל רדיונוב, ראש אולפן האינטרנט Flag מיקטרינבורג, דיבר על CI/CD בכתב עצמי.
האולפן שלו הפך מ-"CI/CD ידני" (כניסה לשרת דרך SSH, בצע משיכה של git, חזור על 100 פעמים ביום) לג'נקינס ולכלי שנכתב בעצמו המאפשר לך לעקוב אחר קוד ולבצע מהדורות בשם Pullkins .
למה ג'נקינס לא עבד? זה לא סיפק מספיק גמישות כברירת מחדל והיה קשה מדי להתאמה אישית.
"דגל" מתפתח ב-Laravel (מסגרת PHP). בעת פיתוח שרת CI/CD, מיכאיל ועמיתיו השתמשו במנגנונים המובנים של Laravel הנקראים Telescope and Envoy. התוצאה היא שרת ב-PHP (שימו לב) שמעבד בקשות webhook נכנסות, יכול לבנות את ה-frontend וה-backend, לפרוס לשרתים שונים ולדווח ל-Slack.
לאחר מכן, כדי להיות מסוגלים לבצע פריסה כחולה/ירוקה ולקבוע הגדרות אחידות בסביבות ה-dev-stage prod, הם עברו ל-Docker. היתרונות נותרו זהים, נוספו האפשרויות להומוגזציה של הסביבה ופריסה חלקה, והתווסף הצורך ללמוד את Docker לעבוד איתו נכון.
איך הפחתנו את מספר ההחזרות לשחרור שרתים ב-99%
הדיווח האחרון במדור Devops היה מאת ויקטור ארמצ'נקו, מהנדס מוביל ב-Miro.com (לשעבר RealTimeBoard).
RealTimeBoard, מוצר הדגל של צוות מירו, מבוסס על יישום ג'אווה מונוליטי. איסוף, בדיקה ופריסה ללא השבתה היא משימה קשה. במקרה זה, חשוב לפרוס גרסה כזו של הקוד כך שלא יהיה צורך להחזיר אותו לאחור (זה מונוליט כבד).
בדרך לבניית מערכת המאפשרת לך לעשות זאת, מירו עבר מסלול שכלל עבודה על הארכיטקטורה, הכלים בהם נעשה שימוש (Atlassian Bamboo, Ansible וכו') ועבודה על מבנה הצוותים (כיום יש להם צוות Devops ייעודי + צוותי Scrum רבים נפרדים ממפתחים של פרופילים שונים).
הדרך התבררה כקשה וקוצנית, וויקטור שיתף את הכאב והאופטימיות שהצטברו שלא נגמרו בכך.
זכה בספר על שאילת שאלות
קטע אחורי
הספקתי להשתתף ב-2 דוחות - של ניקולאי סברצ'קוב (אנוסים מרושעים), גם על חסרי שרת, ומגריגורי קושלב (חברת קונטור) על טלמטריה.
ללא שרת עבור בני תמותה בלבד
אם רוסלן סירקין דיבר על מה זה Serverless, ניקולאי הראה יישומים פשוטים באמצעות Serverless, ודיבר על הפרטים המשפיעים על העלות והמהירות של יישומים ב-AWS Lambda.
פרט מעניין: הרכיב המינימלי בתשלום הוא 128 מגה-בייט של זיכרון ו-100 ms CPU, הוא עולה $0,000000208. יתרה מכך, מיליון בקשות כאלה בחודש הן בחינם.
חלק מהפונקציות של ניקולאי חרגו לעתים קרובות ממגבלת ה-100 אלפיות השנייה (האפליקציה הראשית נכתבה ברובי), כך ששכתוב אותן ב-Go סיפק חיסכון מצוין.
Vostok Hercules - הפוך את הטלמטריה למצוינת שוב!
הדוח האחרון של מדור Backend מ-Grigori Koshelev (חברת Kontur) על טלמטריה. טלמטריה פירושה יומנים, מדדים, מעקבי יישומים.
למטרה זו, Contour משתמש בכלים שנכתבו בעצמם שפורסמו ב- Github. כלי מהדוח - הרקולס, , משמש להעברת נתוני טלמטריה.
הדו"ח של ולדימיר לילה במדור Devops דן באחסון ועיבוד יומנים ב- Elasticsearch, אך עדיין נותרה המשימה של אספקת יומנים מאלפים רבים של מכשירים ויישומים, וכלים כמו Vostok Hercules פותרים אותם.
המעגל הלך בדרך המוכרת לרבים - מ-RabbitMQ ועד אפאצ'י קפקא, אבל לא הכל כל כך פשוט)) הם היו צריכים להוסיף למעגל את Zookeeper, Cassandra ו-Graphite. לא אחשוף את המידע במלואו על דוח זה (לא בפרופיל שלי), אם אתה מעוניין, אתה יכול להמתין לשקופיות ולסרטונים באתר הכנס.
איך זה בהשוואה לכנסים אחרים?
אני לא יכול להשוות את זה עם כנסים במוסקבה וסנט פטרסבורג, אני יכול להשוות את זה עם אירועים אחרים באורל ועם 404fest בסמארה.
DAMP מתקיים ב-8 חלקים, זהו שיא עבור ועידות אוראל. מדורי מדע וניהול גדולים מאוד, זה גם יוצא דופן. הקהל ביקטרינבורג די מובנה - בעיר יש מחלקות פיתוח גדולות עבור Yandex, Kontur, Tinkoff, וזה משאיר את חותמו על הדוחות.
נקודה מעניינת נוספת היא שלחברות רבות יש 3-4 דוברים בכנס בבת אחת (זה היה המקרה עם Kontur, Evil Martians, Tinkoff). רבים מהם היו נותני חסות, אבל הדיווחים די בקנה אחד עם אחרים, אלה לא דוחות פרסומיים.
ללכת או לא ללכת? אם אתם גרים באזור אוראל או בסביבה, יש לכם את ההזדמנות ואתם מתעניינים בנושאים - כן, כמובן. אם אתה חושב על טיול ארוך, הייתי מסתכל על נושאי הדוחות ודיווחי הווידאו משנים קודמות וקיבל החלטה.
יתרון נוסף של כנסים באזורים, ככלל, הוא שקל לתקשר עם הדובר לאחר הדיווחים, פשוט יש פחות מועמדים לתקשורת כזו.
תודה ל-Dump ויקטרינבורג! )
מקור: www.habr.com