Micro – הבלוג של חץ ביז

המעבר ממונוליטי ל-Microservices

כל מי שנמצא ברמה ניהולית של IT (מנמ"ר/CTO/CIO וכו') בוודאי מכיר את הדבר הבא: חברה מעוניינת לפתח מוצר גדול, "הדבר הבא" בתחום שלהם. מתקיימות מספר ישיבות עם גורמים שונים בחברה ותוך כדי כותבים מפרט ארוך מה הולך להיות בתוך המוצר, במה הולכים לתמוך בתוך המוצר וכו' וכו'.

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

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

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

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

פרויקט גדול מורכב מחלקים רבים שצריך לכתוב. בשיטה המונוליטית כל החלקים משתלבים אחד עם השני (Linking) כך שאי אפשר לשלב קוד בחופשיות של מפתחים שונים. צריך לבדוק כל חלק שמבצעים לו Commit שהוא לא שובר חלקים אחרים במוצר. בשיטת ה-Microservices (אני אקרא לזה מ"ש במשך פוסט זה) עושים דברים בשיטה הפוכה: כל חלק שצריך לכתוב, יכתב באופן עצמאי לחלוטין, הוא יכול להיות כתוב בשפה אחרות או עם פלטפורמה/Framework שונה מחלקים אחרים – כל עוד לאותו חלק יהיה ממשק RESTful API שאליו נוכל לשלוח פרמטרים (דרך YAML, JSON וכו') ונוכל לקבל נתונים בחזרה מאותו חלק בפורמט שנרצה.

וכך, בשיטה זו הצוותים השונים עובדים בצורה עצמאית לחלוטין והדבר היחיד שהם צריכים לשמור, זה פורמט API שמוסכם בין כל הצוותים ומתועד. זו בדיוק ההזדמנות גם להשתמש בטכנולוגיות חדשות, או לקחת מפתחים מבחוץ שיודעים לבנות לדוגמא UI בכלים מודרניים, אפשר להשתמש בכלי CI/CD לבדוק ולקמפל כל חלק באופן עצמאי, לכתוב טסטים ולבצע Stress testing לכל חלק.

לאחר שהחלקים השונים נכתבו (או במהלכם) – אנחנו נשתמש במערכת אורקסטרציה לקונטיינרים (כמו Kubernetes/OpenShift) בכדי להריץ כל חלק בקונטיינר/POD והתקשורת בין החלקים תהיה דרך HTTP/HTTPS ודרך פרוטוקולים אלו נשתמש ב-API כך שכל חלק יוכל לדבר עם חלקים אחרים.

במתודה המונוליטית, כשאנחנו צריכים לבצע Scaling, אנחנו בעצם נשכפל מכונות VM ונגדיר את ה-Load Balancer שידע להפנות פניות למכונות ה-VM השונות. הבעיה המהותית בשיטה הזו, היא שאנחנו משתמשים במשאבים רבים כשברוב המקרים רק חלק מסויים או חלקים מסויימים צריכים את ה-Scaling ושאר החלקים רק תופסים זכרון מבלי לעשות כמעט כלום. במתודת ה-מ"ש לעומת זאת, אנחנו יכולים לבצע Scaling דינמי לאותו חלק שמשאביו נגמרים וה-Scaling עצמו יבוצע תוך שניות בודדות (בניגוד להקמת VM נוסף), כך שברוב המקרים, כמות המשאבים שנצטרך לבצע Scaling – תהיה נמוכה בהרבה בהשוואה למתודות הרצה של אפליקציות מונוליטיות (הוספת עוד ועוד מכונות VM).

בכל הקשור לשדרוגי חלקים, HA, אחסון ושליפת נתונים, תקשורת ואבטחה – עבודה עם Kubernetes/Openshift תהיה הרבה יותר טובה ויעילה בהשוואה לשיטות העבודה הקלאסיות. שדרוגים לדוגמא מבוצעים בפקודה אחת מבלי להפסיק את כל החלקים השונים, ובמקרה הצורך, אותו דבר מתבצע בשנמוכים. את ה-HA מקבלים כברירת מחדל עם Kubernetes/Openshift, ובכל הקשור לאחסון – אותן מערכות יודעות "לדבר" עם כל אחסון מקומי או שקיים בענן ציבורי. מה עם אבטחה? כיום עם istio אפשר לעשות דברים רבים שבמערכות קלאסיות מצריכות תוכנות מסחריות (יקרות) מצד ג', ויש כמובן כלים נוספים, רובם בקוד פתוח זמינות לציבור.

אנסה לסכם את הפוסט כך: כיום, אם יש צורך בפיתוח אפליקציות גדולות ומורכבות, עדיף לעבוד במתודות ה-Microservices (ואגב, לחובבי ה-Mainframe – כן, אפשר לעשות זאת בקרוב גם על Mainframe של IBM עם Z/OS) שנותנות יתרונות רבים מאוד על פני המתודה המונוליטית. נכון, Kubernetes הוא לא בדיוק דבר קליל ללימוד אך מצד שני, המאמץ שווה, מה גם שאם אתם הולכים להשתמש בעננים ציבוריים, החיים הרבה יותר קלים עם שרותי הקונטיינרים הטבעיים שאותם ספקי ענן ציבורי מציעים.

להלן מצגת (קצת ישנה) על הנושא (ותודה ליבגני זיסליס על הלינק):

Microservices Workshop All Topics Deck 2016 from Adrian Cockcroft

סקירה: מיקרו שרת של HPE דור 10

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

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

נתחיל במפרט הטכני:

מעבדים – AMD Opteron (קיימים 3 דגמים: X3216, X3418, X3421). הדגם שמיובא לארץ הוא הדגם הנמוך עם מעבד X3216 עם 2 ליבות, 1 מגה זכרון מטמון, APU מובנה, ומבחינת כח – הוא הכי נמוך עם הספק של 12-15 וואט). שאר הדגמים הם עם 4 ליבות, 2 מגה זכרון מטמון, כח גרפי מעט יותר חזק, והספק של 12-35 וואט.
זכרון – עד 32 ג'יגהבייט (ECC).
אחסון: 4 דיסקים קשיחים בגודל 3.5 אינטש ללא תמיכה להחלפה חמה, ואפשרות להוסיף דיסק 2.5 אינטש בחיבור SATA (לצרכים של Boot או Cache עם SSD).
חיבור PCIe: ישנם 2 תושבות, הראשונה היא PCIe X8 והשניה היא PCIe X1 בחיבור של PCIe X4.
חיבורי רשת – 2 חיבורים של 1 ג'יגה עם LOM
חיבורי תצוגה – 2 חיבורי Display Port כולל תמיכה ברזולוציית 4K.
חיבורי USB – כ-2 חיבורי USB 2.0 ו-2 חיבורי USB 3.0.

נתחיל בקהל היעד: קהל היעד למכונה זו (בשימוש כ-NAS) הם אלו שמעוניינים ליצור לעצמם גיבויים – הן מבחינת תכנים שקיימים להם, גיבוי מכונות Windows או לינוקס. HPE רשמית ממליצה על מערכת הפעלה ClearOS שמתאימה ל-SMB/SOHO אבל כמובן כל מערכת הפעלה מודרנית תרוץ ללא בעיות על מכונה כזו. (שימו לב: המערכות שנמכרות בארץ עם X3216 יהיו איטיות בהרבה מ-2 האופציות האחרות ש-HPE מוכרת ולכן לא כדאי "להשתולל" עם התקנת שרותים רבים על המכונה).

למי שמעוניין להקים LAB קטן לעצמו ורוצה את המכונה הזו כשרת NFS או iSCSI או SMB/CIFS – כדאי שיקח בחשבון שהביצועים שהמערכת שנמכרת בארץ, מנפיקה ביצועים די איטיים, כך שאם אתה רוצה להרים מספר דו ספרתי של VM, אולי עדיף שתחפש פתרון אחר או … תצטייד בסבלנות (או שתכניס כרטיסי 10 ג'יגהביט ו-SSD ל-NAS וכרטיסי 10 ג'יגה לשרתים האחרים שלך).

מבחינת המעבד עצמו, HPE ו-AMD עשו בסופו של דבר עיסקה לא רעה בכלל: ל-AMD יש מלאי רציני של מעבדי Opteron ישנים שהם רוצים להיפטר מהם (לטובת ה-Ryzen V1000 ו-EPYC Embedded), ו-HP חיפשו מעבדים לשרתים בקצה הנמוך מאוד ובמחיר זול מאוד. AMD, לפי השמועות, מוכרים את המעבדים בכחמישית מהמחיר שאינטל מבקשת על אותו מפרט וה-Opteron (לפחות ה-X3421) נותן פייט די רציני למעבדי ה-Atom C3000 של אינטל. התוצאה: הלקוח מקבל מכונה עם ביצועים די מכובדים כ-NAS (שוב, לא הגירסה שנמכרת בארץ) במחיר מאוד נמוך של כמה מאות דולרים. אגב, אחד השימושים הכי מעניינים שיצא לי לשמוע עליו בשימוש מכונות כאלו, אגב, הם מקומות עם תקציב די קטן שמריצים קונטיינרים. לפחות מ-2 מקומות (בחו"ל) שמעתי שהם מרוצים מהתוצאות.

מבחינתי, הבעיה המרכזית במכונות הללו היא התכנון שלהם. ב-HPE יכלו לדוגמא לוותר על יציאת Display Port אחת ולהחליף את חיבורי הרשת הקבועים בחיבור של מודול, כך שהלקוח היה יכול להחליף בין 2 חיבורי 1 ג'יגה ל-2 חיבורי 10 ג'יגה, ובנוסף הם יכלו להוסיף ללוח האם כניסת M.2 PCIe X4. הוספת 2 הדברים הללו היו יכולים לשדרג מכונה כזו לביצועי NAS מכובדים מאוד, לשמש כ-Storage למספר קטן של מכונות פיזיות המריצות וירטואליזציה ועוד, אבל כנראה ש-HPE מעדיפים שאם אתה רוצה משהו עם ביצועים קצת יותר גבוהים – תכיר את המכונות שלנו שמבוססות Xeon SP או AMD EPYC – שהן כמובן הרבה הרבה יותר יקרות.

לסיכום: האם הייתי ממליץ לאחרים לרכוש את המכונה הזו? כן, אם הצרכים שלהם הם מה שציינתי לעיל. אם הם צריכים משהו יותר חזק, אז עדיף שיחפשו את הגירסה עם מעבד X3421 או שיחפש פתרון NAS אחר או שיבנה לעצמו NAS. אישית, אני מקווה בזמן הקרוב לבחון לוח אם חדש (שעדיין לא יצא – מחברת ASRock Rack) המבוסס על מעבד EPYC Embedded ושתומך בהרבה יותר דיסקים קשיחים, יש בו כניסת M.2, תושבת PCIe X16 ו-2 כניסות 10 ג'יגהביט מובנות – ואת זה להכניס למארז 2U.

דעה: כמה מילים על פרשת הריגול ו-Super Micro

עדכון בסוף הפוסט

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

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

כשאני מסתכל על עולם השרתים, אני מחלק אותם ל-2. רוב השרתים שנרכשים בישראל ובחברות Enterprise אמריקאיות רוכשים שרתים, הם רוכשים אותם מחברות כמו Dell, HPE, Cisco, Lenovo, Fujitsu ואצל האירופאים יש גם את Siemens, Huawai ועוד כמה. את כל אלו אני מכניס תחת קטגוריית "פתרון שרתים רגיל".

לעומת זאת, אצל חברות מחשוב ענן (גוגל, פייסבוק, אפל, אמזון, מיקרוסופט, אקמאי ועוד כמה) הכל שונה. בחברות רגילות ירכשו שרת בגודל 1U ובחברות ענן לא יהיה דבר כזה – יהיו לפחות 4 שרתים במארז 1U. אין ספק כח (או זוג ספקים) בכל שרת – הם פשוט יזרימו את המתח שצריך ישירות, פתרונות האוורור/קירור שונים, אין מתגים/סוויצ'ים של ג'וניפר, פורטיגייט, סיסקו ואחרים – אלא מתגים "תוצרת בית" מבוססי לינוקס שמשתמשים במעבד כמו של Avago בסוויצ' לעשות את העבודה + מעבד אינטל מהקצה הנמוך ללינוקס. אין סטורג' כמו NetApp או EMC ואין אחסון מקומי (למעט במכונות מסויימים ללקוח – אחסון שנמחק מיידית ברגע שהלקוח מסיים את העבודה עם המכונה) בשרתים. לא משתמשים בדיסקים ל-Enterprise בשום מצב (כי זה סתם מייקר את העלויות) ומה שהכי חשוב – בדרך כלל אצל ספק הענן מתכננים את כל הלוחות והדברים מוצאים החוצה לייצור (בכמויות של מינימום כמה אלפים, אחרת אין עיסקה). בד"כ מי שמייצר את הדברים הללו הם חברות כמו Super Micro, Compal, WyWinn ועוד מספר חברות סיניות או שהייצור שלהם בסין. רוב הטכנולוגיות והתוכניות ללוחות אם מופיעות תחת רשיון בקוד פתוח בפרויקט OCP שמשותף לכל ספק הענן. כמעט כל הטכנולוגיות הללו לא מופיעים אצל יצרני פתרונות שרתים רגילים מכל מיני סיבות (במיוחד רווח של היצרנים).

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

כפי שתיארתי לעיל, כמעט כל אותן חברות ענן מתכננות In House את הלוחות לשרתים ולשאר הציודים. הם מעבירים את התוכנית ליצרן, היצרן מעביר את הייצור לסין (כי בארה"ב ובשאר מקומות בעולם או שאין תשתית או שזה יקר מדי והלקוחות לא ממש רוצים לשלם פרמייה יקרה רק שזה ייוצר בארה"ב). בהתחלה מעבירים תוכנית לאב טיפוס (תהליך סופר יקר!) – חוזרים מס' לוחות בודדים עם הרכיבים ואותם לוחות עוברים בדיקות. במידה ויש בעיות, ייצרו שוב אב-טיפוס נוסף (וכמה אנשים יחטפו על הראש), הלוח המיוצר חוזר ללקוח, עובר בדיקות, ואם יש אישור QC מלא, מוציאים אישור הזמנה לכמה אלפי עותקים. כאן יכולה להיות בעיה שאף אחד מצד הלקוח לא בדק מה הרכיבים שיש והאם יש כל מיני דברים שנוספו (ואני בטוח שכבר 3 שנים החברות הללו הפיקו את הלקחים והם בודקים עם מיקרוסקופ).

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

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

עכשיו לגבי ה-So called "פריצה".

מכיוון שאף אחד לא פירסם איך אותו מיקרו שבב חובר ללוח האם ולאיזה שבב או רכיבים – קשה לדעת מה בדיוק תפקיד השבב, אבל אם יש משהו אחד (במיוחד ב-GOV Cloud ובעננים כמו באמזון) שאין בשרתים – זה גישה חופשית לאינטרנט. כל מי שהקים אי פעם VPC (חוץ מברירת המחדל) באמזון יודע שברירת מחדל – אין לך גישה לאינטרנט, וכך גם בשרתים עצמם – אין גישה לאינטרנט. כשאתה מקים Instance ואתה מריץ אפילו פקודת ping 8.8.8.8, אותו ping עובר דרך כמה שרתים וכמה ניתובים עד שהוא יוצא החוצה, ולשרת שמריץ את אותו VM אין מושג ירוק מהיכן זה יוצא – הוא מעביר את הבקשה ל-hop הבא ומשם זה ממשיך ובחזרה.

נמשיך: אותו מיקרו שבב לא יכל לעשות הרבה מהסיבה הפשוטה שכל ספק מריץ מערכת אחרת, מודולים שונים, ה-TCP/IP לפעמים מבוצע בשרת ולפעמים מבוצע בכלל כ-Offload על שבב יעודי בכרטיס הרשת. בנוסף, כשמדובר בלינוקס או VMWare, המודולים חתומים כך שכל נסיון שינוי שלהם יגרום להם פשוט לא לעלות. נוסיף על כך שבמכונות האלו אין UEFI שדרכו ניתן להיכנס (יש Core Boot, כל הספקים מספיק חכמים לזרוק את ה-UEFI המעפן לפח!) וגם המודולים של Core Boot חתומים, שינית? אין Boot לשרת.

בקיצור, בניגוד למצב של הרבה חברות שכמעט לכל מכונה יש גישה דרך סוויצ' ב-Firewall החוצה, אצל ספקי ענן אין את הדברים הללו, כך שעם כל הכבוד לנסיון הסיני, אני מאמין שהטריק הנבזי הזה נכשל (במיוחד בענן GOV Cloud ששם אין אינטרנט בשום מצב). מי שאכל אותה מזה היתה חברת Super Micro שהפסידה חוזים ולקוחות, ואישית, כאחד שמדי פעם משוחח עם החברה – זו אחת החברות שהכי כיף לעבוד איתם ולמצוא אצלם פתרונות שאין אצל אף אחד אחר בשוק החופשי (ואפשר להתכתב באנגלית מבלי לקבל תשובות באנגלית ברמה של כיתה ה').

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

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