מלכודת ה-egress: סעיף החשבונית שאף אחד לא מתקצב

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

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

מה זה egress באמת, ולמה הוא מתומחר ככה

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

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

איך זה מעוות את הארכיטקטורה שלכם

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

• אתם מפסיקים להזיז נתונים. התכנון הנקי אומר להעתיק את מאגר הנתונים לאן שה-compute נמצא. החשבונית אומרת אל תעשו את זה. אז אתם מעוותים את הטופולוגיה כדי לשמור על הבייטים במקום, גם כשזו ההחלטה הלא נכונה.
• אתם חוששים מ-multi-region. שכפול ל-region שני לצורך עמידוּת זה בדיוק מה שצריך לעשות. egress בין regions הופך את זה למס חוזר, אז אתם משכנעים את עצמכם לוותר.
• אתם נמנעים מצינור הניתוח המתבקש, כי משיכת הנתונים אל הכלי שאמור לעבד אותם עולה יותר מהעיבוד עצמו.
• אתם נכנסים ל-lock-in. ברגע שהנתונים שלכם גדולים, עצם העלות של למשוך אותם החוצה כדי לבחון ספק אחר היא הרתעה בפני עצמה. מד ה-egress הוא חפיר, ואתם בצד הלא נכון שלו.

אף אחת מההחלטות האלה אינה החלטת נכונוּת. אלה החלטות התחמקות-מחשבונית בתחפושת של ארכיטקטורה.

תבנית הלם-החשבונית

זה תמיד נראה אותו הדבר. השקה הולכת טוב. batch job נעשה פטפטני יותר. client עם הגדרה שגויה מנסה שוב ושוב מעבר לגבול של region. דאשבורד חדש סוקר object store מהמקום הלא נכון. תנועה שהייתה שגיאת עיגול הופכת לעלות הדומיננטית, והחלק הכי גרוע הוא שאי אפשר לחזות אותה מראש — לכרטיס התעריפים יש כל כך הרבה מדרגות וגבולות, שהדרך היחידה ללמוד את המספר היא לקבל עליו חיוב. אתם בונים ארכיטקטורה הגנתית סביב עלות שאי אפשר למדל. זאת המלכודת.

מה אנחנו עושים במקום זה

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

אין שום חיוב egress בין משאבי Kaligon Cloud באותו region. ה-VM שלכם שמדבר עם ה-block volume שלכם, עם ה-object store שלכם, עם בסיס הנתונים שלכם, עם VM אחר — התנועה הזאת חינם. הזיזו נתונים לאן שה-compute נמצא. שכפלו בתוך ה-region לצורך עמידוּת. בנו את הצינור בדיוק לפי הספר. הבייטים שזורמים בין המשאבים שלכם עצמכם פשוט לא מופיעים בחשבונית.

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

זה מתאים לאופן שבו כל שאר Kaligon Cloud מתומחר: מחיר אחיד אחד לכל משאב, חיוב לפי שנייה עם תקרה חודשית, ותקציב קשיח שבאמת עוצר את ההוצאה. בלי התעמלות של reserved instances, בלי הנחות committed-use שצריך לרדוף אחריהן. ומכיוון שהנתונים שלכם נשארים ב-region שבחרתם, הם לא נודדים בשקט למקום שיקר יותר לעזוב ממנו.

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