איך לעבור לענן תוך שעתיים בזכות Kubernetes ואוטומציה

חברת URUS ניסתה את Kubernetes בצורות שונות: פריסה עצמאית על מתכת חשופה, ב-Google Cloud, ולאחר מכן העבירה את הפלטפורמה שלה לענן Mail.ru Cloud Solutions (MCS). איגור שישקין מספר איך הם בחרו ספק ענן חדש ואיך הצליחו לעבור אליו תוך שעתיים שיא (t3ran), מנהל מערכת בכיר ב-URUS.

מה עושה URUS?

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

איך URUS עובד מבפנים

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

גרף ניטור ריכוזי H2S מציג פליטות לילה קבועות ממפעל סמוך

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

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

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

כיצד אנו מאחסנים נתונים. הסיפור של Kubernetes על מתכת חשופה

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

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

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

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

המעבר ל-Google Cloud Platform הוא פתרון זמני

הבנו שזה לא יכול להימשך, והעברנו את הנתונים שלנו ממתכת חשופה ל-Google Cloud Platform. למעשה, באותה תקופה לא היו הרבה אפשרויות מעניינות עבור חברה רוסית: מלבד Google Cloud Platform, רק אמזון הציעה שירות דומה, אבל בכל זאת הסתפקנו בפתרון מגוגל. אחר כך זה נראה לנו יותר רווחי מבחינה כלכלית, קרוב יותר ל-Upstream, שלא לדבר על העובדה שגוגל עצמה היא סוג של PoC Kubernetes in Production.

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

איך ראינו את שירות הענן האידיאלי

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

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

באותה תקופה, היו מעט ספקי Kubernetes aaS ברוסיה, וכאשר בחרנו ספק, היה לנו חשוב לא להתפשר על סדרי העדיפויות שלנו. צוות Mail.ru Cloud Solutions, איתו התחלנו לעבוד ועדיין משתפים פעולה, סיפק לנו שירות אוטומטי לחלוטין, עם תמיכה ב-API ולוח בקרה נוח הכולל את Horizon – איתו יכולנו להעלות במהירות מספר שרירותי של צמתים.

איך הצלחנו לעבור ל-MCS תוך שעתיים

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

הודות לאוטומציה של תהליכי פיתוח ו-CI/CD, Kubernetes ב-URUS מטופל על ידי מומחה אחד (וזה אני). באיזשהו שלב עבד איתי מנהל מערכת אחר, אבל אז התברר שכבר עשינו אוטומציה של כל השגרה העיקרית והיו עוד ועוד משימות מצד המוצר הראשי שלנו והיה הגיוני להפנות משאבים לזה.

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

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

איך אנחנו רואים עבודה עם עננים בעתיד

כעת העבודה שלנו קשורה קשר הדוק ל-Kubernetes, והיא מתאימה לנו לחלוטין מנקודת המבט של משימות תשתית. לכן, אנחנו לא מתכננים להגר ממנה לשום מקום, למרות שאנו מציגים כל הזמן שיטות ושירותים חדשים כדי לפשט משימות שגרתיות ולהפוך חדשות לאוטומטיות, להגביר את היציבות והאמינות של השירותים... אנו משיקים כעת את שירות Chaos Monkey (במיוחד , אנו משתמשים ב-chaoskube, אבל זה לא משנה את הקונספט: ), שנוצר במקור על ידי Netflix. Chaos Monkey עושה דבר אחד פשוט: הוא מוחק תרמיל Kubernetes אקראי בזמן אקראי. זה הכרחי כדי שהשירות שלנו יחיה כרגיל עם מספר המקרים n–1, אז אנחנו מאמנים את עצמנו להיות מוכנים לכל בעיה.

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

מה למדנו מהעבודה עם שירותי ענן

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

מקור: www.habr.com