From inevitable overprovisioning to the “on-demand” tax: why DynamoDB is bloody hard to cost-control לאחרונה עם המטרה הספציפית של לעזור ללקוחות ScyllaDB פוטנציאליים להבין את העלות האמיתית של הפעלת DynamoDB. עכשיו, אם אתה הולך אחורה ורואה את המטרה שלי, זה לא הגיוני הרבה, נכון? חישוב עלויות DynamoDB בשלב זה, הבנתי שישנן סיבות רבות מדוע צוותים בסופו של דבר משלמים מאות אלפי דולרים (אם לא מיליוני דולרים) כדי להפעיל את DynamoDB בקנה מידה. הדבר העיקרי שמצאתי: DynamoDB קל לאמץ, אבל קשה מאוד לשלוט על עלויות. עובדתי ג'וליה ואני אבל אם אין לך זמן לצפות, להמשיך לקרוא כדי לגלות את הממצאים העיקריים. הוצאנו סדנאות webinar בקווים האלה. ייתכן שכבר שמעתם מונחים כמו יחידות יכולת קריאה ו יחידות יכולת כתיבה, ולקבל את המילה "אתה משלם עבור מה שאתה משתמש" במונחים של מספר קריאות וכתובות. כתיבת DynamoDB היא יקר. אם אתה מסתכל , תראה כי יחידת בקשת קריאה (RRU) עולה $ 0.125 למיליון יחידות, ו יחידת בקשת כתיבה (WRU) עולה $ 0.625 למיליון יחידות. אז, כתיבה היא 5 פעמים יקר יותר מאשר קריאה. אני לא יודע את הסיבה הטכנית המדויקת, אבל אין ספק שיש משהו לעשות עם נתיב כתיבה להיות כבד יותר (קיימות, עקביות, אינדקס, וכו ') וכמעט קצת כותרת. 5x נראה קצת בצד המפואר עבור מסדי נתונים ואחד המלכודות הראשונות מנקודת מבט עלות. אתה יכול בקלות למצוא את עצמך לבלות סדר של גודל יותר אם עומס העבודה שלך הוא כתיבה כבדה, במיוחד במצב על-ביקוש. מחירי היכולת לפי דרישה לדבר על מה ... יש את האופנה השנייה: כפי שהשם אומר, זה אומר שאתה יכול לציין כמה אתה הולך להשתמש (אפילו אם אתה לא משתמש בו), ולקוות לשלם קצת פחות. בואו נבדוק את היחס, עם זאת. יחידת יכולת קריאה (RCU) עולה $ 0,00013 לכל RCU ו יחידת יכולת כתיבה (WCU) עולה $ 0,00065, כך כתיבה היא מפתיע 5 פעמים יותר יקר מאשר קריאה. אז אפילו במצב מתוכנן, אתה עדיין לשלם עונש 5x על כתיבה. היכולת המתוכננת אתם לא מציעים בקשות, אתם מציעים מחירים... הנה ההצלחה: יחידות היכולת המוצעות נמדדות לשנייה, לא למיליון בקשות, כמו בדרישה.זה גרם לי להתחיל בהתחלה.למה לא רק לספק את המספר הכולל של בקשות?אבל מנקודת המבט של AWS, זה הגיוני לחלוטין. N פעולות לשנייה, בין אם אתה משתמש ביכולת זו או לא. היכולת להתמודד אז אם התנועה שלך מתפוצצת, או שאתה מעל אספקת כדי למנוע דחיפה בקשה (עוד על זה קצת), אתה בעצם משלם עבור יכולת ריקה. יכולת מוגבלת... אז הנה העסקה: אם אתה שומר על קיבולת, אתה הימור גדול מראש כדי מקווה לחסוך קצת מאוחר יותר. אם אתה בטוח בשימוש בסיסי שלך, AWS נותנת לך את האפשרות להזמין קיבולת DynamoDB, בדיוק כמו עם EC2 או RDS. זוהי התחייבות בתשלום מראש של 1 או 3 שנים, שבה אתה מחזיק בשיעור קבוע של קריאות וכתובות לשנייה. גוצ'ה אחד: אין אפשרות קדימה חלקית; זה לשלם במלואו או ללכת. בואו נסתכל על מקרה שימוש פשוט להשוות את מודלים המחירים ... נניח שהממוצע של עומס העבודה שלך הוא 10,000 קריאה / שניה ו 10,000 כתיבה / שניה במשך שעה. מחירים לפי דרישה: כתיבה: $ 22.50 / שעה ... 10,000 * 3600 * 0.625 / 1M קריאה: $ 4.50 / שעה ... 10,000 * 3600 * 0.125 / 1M (5x זול יותר מאשר כותבים, כרגיל) מחירים מוגבלים (לא מוגבלים) : כתיבה: $6.50 / שעה ... 10,000 * $0.00065 קריאה: $1.30 / שעה ... 10,000 * $0.00013 זמינות בתנאי 1 שנה: כתיבה: ~ $ 2.99 / שעה קריאה: ~$0.59 / שעה “איפה השיטה המוגבלת?” אני שומע אותך. אתה לוקח את המחיר המוגן עבור 100 WCUs ($0.0128 / שעה) ו RCUs ($0.0025 / שעה), לחלק על ידי 730 שעות בחודש, לחלק על ידי 12 חודשים בשנה, לחלק שוב על ידי 100 יחידות, להכפיל על ידי שיעור הנדרש שלך ... ולאחר מכן לסובב את זה, לבכות קצת, ולהדביק את "גברת המתמטיקה" ממה. הנקודה שלי היא: מוצר מסופק - 3.4x זול יותר מאשר על-ביקוש הזמנה זולה פי 7.5 יותר מאשר על-ביקוש On-demand הוא עבור אנשים שאוהבים לשלם יותר מדי, או שונאים לחזות. תשלומים , בשביל : AWS ממליץ על On-Demand דפוסי תנועה המתפתחים עם הזמן Spiky או batchy workloads שימוש נמוך (נפילה עד אפס או מתחת ל-30% של השיא) זה בעצם כל עומס עבודה בחיים האמיתיים - לפחות עבור הלקוחות של ScyllaDB. אז כן, לצפות לשלם פרמיה עבור גמישות זו, אלא אם כן התנועה שלך נראית כמו גל סין של ספר לימוד ויש לך כדור קריסטל. זה לא הגודל של הפריט, אבל זה ... זהו אחד שאתה לא יכול לפגוע עד שאתה משתמש נתוני יישום אמיתיים ... בשלב זה תתחרט מיד להתעלם ממנו. ב-DynamoDB, אתה לא רק משלם עבור כל פעולה; אתה משלם עבור כל חלק של הנתונים המועברים. כתיבת בקשות (Write Request Units או WRUs) בקשות קריאה: 4KB (Read Request Units או RRU) אז אם אתה כותב פריט 1.1KB, זה 2 WRUs. כותב פריט 3KB? עדיין 3 WRUs, כל 1KB (או חלק ממנו) נחשב. קריאות עובדות באותו אופן, רק בגבולות 4KB. קרא פריט 1KB? 1 RRU. קרא פריט 4.1KB? זה 2 RRUs. האם זה לא כיף? אני בטוח שיש סיבות טכניות חזקות לגבולות אלה. אתה יכול לראות את המלכודת כאן. שילוב זה עם 5x עלות של כתיבה בהשוואה לקריאה, והדברים יכולים להיות מכוערים מהר, במיוחד אם גודל הפריט שלך חוצה את הגבולות הללו מבלי שאתה מבין. זה כנראה בסדר אם יש לך גודל פריט קבוע בתוכנית שלך, אבל בהחלט לא בסדר עם סוגים של מקרים של שימוש שאנחנו רואים ב ScyllaDB. לדוגמה, הלקוחות עשויים להקים שדות JSON או blob שיכולים להתכווץ או לגדול עם השימוש. ולזכור, זה גודל הפריט האמיתי, לא רק גודל התוכנית הלוגית. זה מופרך, כי אתה חייב ... נקודה נוספת של כאב, וחוסר אונים מהמחשב של AWS עצמו, היא הצורך להגדיל את הסכום כאשר משתמשים ביכולת מוגבלת.זה נשמע אינטואיטיבי, אבל אתה נאלץ להגדיל את הסכום – לא כי אתה רוצה, אלא כי DynamoDB עונש אותך אם אתה לא. אם תעברו את היכולת המיועדת, תקבלו אני אוהב את הבהירות של מסר יוצא מן הכלל מסוג זה.אני לא אוהב את מה שהוא באמת עושה, אם כי: בקשה זלזול. זה שומר על יכולת קריאה וכתיבה לא בשימוש, אבל מעבר לזה, האפליקציה שלך פשוט נכשלת. תגית: Exception 300s חלון של יכולת פיצוץ לכן, הדרך הטובה ביותר להתמודד עם זה היא על-ידי תשלום יתר. על-ידי כמה? זה מבטיח תשובה "זה תלוי". אבל זה תלוי בסוג עומס העבודה שלך. הוספנו פונקציונליות זו לחשבוננו כך שאתה יכול באופן דינמי תשלום יתר על-ידי אחוז, רק כדי לקחת בחשבון את העלויות הנוספות עבור עומס העבודה שלך. כמובן, עלויות אלה יכולות להוסיף במהירות כי בפועל, אתה משלם עבור השיא גם אם אתה פועל במעגל. אם אתה לא מספק כוח גבוה מספיק, השיאים שלך עלולים להיות מוטל, נותן לך כישלונות מול הלקוח בזמן הגרוע ביותר האפשרי. לפני שאנחנו עוזבים... אם יש כאן נושא חוזר, זהו זה: המחיר של DynamoDB אינו שגוי באופן טבעי. אתה משלם עבור מה שאתה משתמש. בין אם זה: 5x write cost multiplier 7.5x On-Demand Multiplier של העלות מחירי Opaque Per Second Provisioned Rates פירוק עונשין וגבולות מלאכותיים של גודל פריט או רק את הצורך של אספקת יתר כדי למנוע השתילה פנים במהלך עומס פס אתה כל הזמן צריך לנחש את האדריכלות שלך רק כדי להישאר קדימה עלויות התפרצויות. האירוניה? DynamoDB מסומנת כ"ללא שרת" ו"מנוהלת לחלוטין", אבל אתה בסופו של דבר לנהל את המתמטיקה של היכולת, שגיאות שלטון, רמות מחירים ארקניות, וגימסטיקה אינסופית של קנה מידה.לאחר שתצפו רבים של תחזיות לוח המחשב של הלקוחות שלנו (ואפילו ייצוא AWS Cost Explorer) עבור DynamoDB, אפילו צוותים בוגרים המפעילים מערכות בקנה מידה גדול אין מושג מה העלות היא ... עד שזה מאוחר מדי. זו הסיבה שבנו מחשב שמדגם עומסי עבודה אמיתיים, לא רק ממוצעים, כי הצעד הראשון לקביעת עלויות הוא להבין מאיפה הם מגיעים. ב , אני הולך דרך כמה דוגמאות בעולם האמיתי של לקוחות שעברו מ- DynamoDB ל- ScyllaDB כדי להראות את ההשפעה האמיתית של דפוסי התנועה, גדלים של פריטים, קישוריות וטופולוגיות מרובות אזורים. ב . הבלוג הבא שלי לקפוץ קדימה ולעצב את עומסי העבודה שלך תגית: calculator.scylladb.com מודל את עומסי העבודה שלך DynamoDB על מחשב העלות החדש שלנו אודות Tim Koopmans טים עבד בכל צורות הנדסה במשך כמה עשורים האחרונים עם תשוקה לאמינות ובטיחות. בשנת 2013 הוא הקים את Flood IO; פלטפורמת בדיקות ביצועים מפוזרת.
