האם מסדי נתונים חיים ב-Kubernetes?

איכשהו, היסטורית, תעשיית ה-IT מחולקת לשני מחנות מותנים מכל סיבה שהיא: אלה שהם "בעד" ואלה שהם "נגד". יתרה מכך, נושא המחלוקות יכול להיות שרירותי לחלוטין. איזו מערכת הפעלה עדיפה: Win או Linux? בסמארטפון אנדרואיד או iOS? האם לאחסן הכל בעננים או לשים אותו על אחסון RAID קר ולשים את הברגים בכספת? האם לאנשי PHP יש את הזכות להיקרא מתכנתים? מחלוקות אלו הן, לעיתים, קיומיות בלעדיות בטבען ואין להן בסיס מלבד עניין ספורטיבי.

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

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

הצד החיובי

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

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

נכון, נתונים. הלב של כל פרויקט הוא הנתונים שלו: זה יכול להיות DBMS טיפוסי - MySQL, Postgre, MongoDB, או אחסון המשמש לחיפוש (ElasticSearch), אחסון ערך מפתח לאחסון במטמון - למשל, redis וכו'. כרגע אנחנו לא נדבר על אפשרויות הטמעת קצה עקום כאשר מסד הנתונים קורס עקב שאילתות כתובות בצורה גרועה, ובמקום זאת נדבר על הבטחת סובלנות התקלות של מסד הנתונים הזה בדיוק בעומס לקוח. אחרי הכל, כאשר אנו מאחסנים את האפליקציה שלנו ומאפשרים לה להתרחב בחופשיות כדי לעבד כל מספר של בקשות נכנסות, זה כמובן מגביר את העומס על מסד הנתונים.

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

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

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

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

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

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

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

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

ועכשיו הגיע הזמן להפוך למתנגדים לאשכול מסדי נתונים.

צד אפל

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

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

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

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

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

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

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

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

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

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

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

במקום פלט

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

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

מקור: www.habr.com