תשתית מודרנית: בעיות וסיכויים

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

המשתתפים:

• יבגני פוטאפוב, מנכ"ל ITSumma. יותר ממחצית מהלקוחות שלה כבר עוברים או רוצים לעבור ל-Kubernetes.
• דמיטרי סטוליארוב, CTO "Flant". בעל ניסיון של 10+ שנים בעבודה עם מערכות מכולות.
• דניס רמצ'וקוב (המכונה אריק אולדמן), COO argotech.io, לשעבר RAO UES. הוא הבטיח לדבר על מקרים במפעל "המדמם".
• אנדריי פדורובסקי, CTO "News360.com"לאחר רכישת החברה על ידי שחקן אחר, הוא אחראי על מספר פרויקטים ותשתיות של ML ו-AI.
• איבן קרוגלוב, מהנדס מערכות, לשעבר-Booking.com.אותו אדם שעשה הרבה עם Kubernetes במו ידיו.

נושאים:

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

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

האם Kubernetes כבר שיווק סטנדרטי או מצוין?

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

תמונה מאת Reddit.com

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

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

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

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

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

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

תמונה על ידי טוויטר: @jankolario ב- Unsplash

כיום, ישנם מתכונים רבים להפעלת מסדי נתונים ב-Kubernetes. אפילו איך להפריד בין החלק שעובד עם דיסק ה-I/O, בתנאי, לחלק היישום של מסד הנתונים. האם ייתכן שבעתיד ישתנו מסדי נתונים עד כדי כך שהם יסופקו בקופסה, שבה חלק אחד יתוזמר באמצעות Docker ו-Kubernetes, ובחלק אחר של התשתית, באמצעות תוכנה נפרדת, יסופק חלק האחסון. ? האם הבסיסים ישתנו כמוצר?

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

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

משתתפי המפגש חולקו לשני מחנות.

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

אפילו מסדי נתונים מודרניים של ענן כמו MongoDB ו-Cassandra, או תורי הודעות כמו Kafka או RabbitMQ, דורשים מאגרי נתונים מתמשכים מחוץ ל-Kubernetes.

יבגני מתנגד: "הבסיסים בקוברה הם פגיעה כמעט רוסית, או כמעט ארגונית, הקשורה לעובדה שאין אימוץ ענן ברוסיה". חברות קטנות או בינוניות במערב הן ענן. מסדי נתונים של Amazon RDS קלים יותר לשימוש מאשר להתעסק עם Kubernetes בעצמך. ברוסיה משתמשים ב-Kuber "on-premise" ומעבירים אליו בסיסים כשהם מנסים להיפטר מגן החיות.

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

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

מקרה 1. אבטחת סייבר של "מגה-רגולטור" עם בסיסים מחוץ לקוברה

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

מקרה 2. העברה חלקית של מסדי נתונים של Booking.com ל-Kubernetes

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

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

המחלקה השלישית של מסדי נתונים היא שירות החיפוש של Booking.com, כאשר כל צומת שירות הוא מסד נתונים. ניסיונות להעביר את שירות החיפוש ל-Kuber נכשלו, מכיוון שכל צומת הוא 60-80 GB של אחסון מקומי, שקשה "להרים" ו"לחמם".

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

בחירת תשתית כמשימה ללא פתרון כללי

תמונה על ידי מנואל גייסינגר מפקסלס

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

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

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

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

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

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

דניס תיאר שני קריטריונים עיקריים - מדרגיות ויציבות הפעולה. הוא יבחר את הכלים המתאימים ביותר למשימה. "זה יכול להיות נושם שהורכב על הברכיים שלך, ויש עליו מהדורת Nutanix Community. זו יכולה להיות שורה שנייה בצורה של אפליקציה ב-Kuber עם מסד נתונים ב-backend, אשר משוכפל ומפרט פרמטרים של RTO ו-RPO" (יעדי זמן שחזור/נקודת שחזור - משוער).

Evgeniy זיהה בעיה אפשרית עם הצוות. כרגע, אין הרבה מומחים מוסמכים בשוק שמבינים את ה"אומץ". ואכן, אם הטכנולוגיה שנבחרה ישנה, ​​אז קשה להעסיק מישהו מלבד אנשים בגיל העמידה המשועממים ועייפים מהחיים. אמנם משתתפים אחרים מאמינים כי מדובר בהכשרת כוח אדם.
אם נשים את שאלת הבחירה: להשיק חברה קטנה ב-Public Cloud עם מסדי נתונים באמזון RDS או "on premise" עם בסיסי נתונים ב-Kubernetes, אז למרות כמה חסרונות, Amazon RDS הפכה לבחירה של המשתתפים.

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

הערכת השימוש ב-Kubernetes

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

תמונה על ידי טטיאנה ארמינה ב- Unsplash

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

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

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

מה מחכה לנו

תמונה על ידי דרו בימר ב-unsplash

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

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

התשובה ניתנה על ידי איוון: "גוגל בונה כעת את Anthos - זו ההצעה החבילה שלהם שפורסת את הענן וכוללת Kuber, Service Mesh, ניטור - כל החומרה הדרושה למיקרו-שירותים מקומיים". אנחנו כמעט בעתיד".

דניס גם הזכיר את Nutanix ו-VMWare עם המוצר vRealize Suite, שיכול להתמודד עם משימה דומה ללא קונטיינריזציה.

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

לסיכום הדיון, אנו מדגישים את הבעיות הבאות של תשתית מודרנית:

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

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

  
  תמונה על ידי Gabriel Santos Fotografia מ-Pexels

  אני רוצה לנצל את ההזדמנות לומר שלום לאמא שלי ולהזכיר לך שיש לנו קבוצת פייסבוק "ניהול ופיתוח של פרויקטי IT גדולים", ערוץ @feedmeto עם פרסומים מעניינים מבלוגים טכנולוגיים שונים. והערוץ שלי @rybakalexey, שם אני מדבר על ניהול פיתוח בחברות מוצר.

מקור: www.habr.com