כיצד לייעל את עלויות אמזון EC2 שלך?

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

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

חלק 1 מתוך 9: הבנה אם ec2 מתאים לך

1
הבן כי ec2 אינו הזול ביותר. מבחינת יחסי מחיר-ביצועים עבור החומרה בלבד, EC2 היא רחוקה מהחלופה הזולה ביותר בשוק. אפילו התחשבות באמינות השירות אינה הופכת אותו לתחרותי ביותר.
- אם אתה מצפה להעביר הרבה נתונים (יוצא מהשרת שלך) שירותי האינטרנט של אמזון יכולים להיות יקרים למדי בהשוואה לספקי שרתים וירטואליים פרטיים (VPS) שונים כגון Linode ו- Digital Ocean. הסיבה לכך היא ש- AWS גובה כ- 9 סנט ל- GB, מה שמתורגם לכ- 67 € / TB, סכום שרוב ספקי ה- VPS מציעים בחינם עם התוכניות החודשיות המינימליסטיות שלהם (כ- 3,70 € או 7,50 € לחודש). במילים אחרות, אם יש לך אתר פשוט שמשיג תנועה רבה, סביר להניח ש- AWS לא תהיה הבחירה הנכונה עבורך.
- מבחינת ביצועי החומרה, אמזון EC2 הציעה היסטורית ביצועים גרועים יותר מ- Linode ו- Digital Ocean לשרתים באותו מחיר ולמפרט חומרה דומה (מבחינת vCPU וזיכרון). חלקית, זה בגלל הבדלים בארכיטקטורה הבסיסית.
2
להבין כמה מהיתרונות המרכזיים של ec2 ושל פתרונות תשתיות כשירות (iaas) באופן כללי.
- תשתית גמישה וניתנת להרחבה שתוכלו להתאים לצרכים המשתנים שלכם.
- יכולת לפרוס מקרים ולבצע שינויים בארכיטקטורה באופן פרוגרמטי.
- הזמינות של מקרים נקודתיים.
- מספר רב של שירותים מנוהלים שאם משתמשים בהם באותו אזור, לא עולים דבר (או מעט מאוד) בהעברת נתונים.
3

זכור כי אינך צריך להשתמש ב- ec2 רק בגלל שאתה משתמש בשירותי אמזון אחרים. למשל, מספר אנשים משתמשים באמזון S3 לאחסון בתפזורת זולה, גמישה ומיותרת, אך אינם מריצים את המכונות שלהם ב- EC2.

חלק 2 מתוך 9: הבנת סוגי מופעים

1
הבן את ההיבטים השונים בתיאור סוג של מופע אמזון.
- שם טיפוסי כולל שלושה חלקים: אות המתארת את מחלקת המופע (R, M, C, T, G, D, I, P, X), מספר המתאר את הדור (1, 2, 3, 4, 5), ומחרוזת המתארת את הגודל באותה מופע ודור (קטן, בינוני, גדול, xlarge, 2xlarge, 4xlarge, 8xlarge, 10xlarge, 16xlarge, 32xlarge). למשל, "r3,4xlarge" הוא סוג מופע R, דור 3 וגודל 4xlarge.
- דרך פשוטה לזכור מה משמעות הגודל: "גדול" מייצג 2 vCPUs, "xlarge" מייצג 4 vCPUs, ו- n xlarge פירושו 4n vCPUs. VCPU הוא "חוט יתר" בז'רגון של אינטל, יצרנית השבבים. ניתן לחשוב על זה בתמימות שהוא תואם לליבה אחת במחשב נייד או שולחן עבודה לצרכן; עם זאת, מבחינה פיזית, לשבבי אינטל המשמשים את הדורות האחרונים של מופעי EC2 יש שני vCPU (או שני שרשורים) לכל ליבה. אם משווים לשרתים פיזיים קיימים, עליכם להכפיל את מספר ליבות השרת הפיזיות בשניים כדי לקבל את מספר ה- vCPU הנכון.
- מחלקת המופע נותנת את היחס בין החלקים השונים של מפרט המופע. היחס הרלוונטי ביותר הוא היחס בין vCPU ל- RAM. לדוגמא, מחלקת מופע C (כאשר C מייצג אופטימיזציה לחישוב) מציעה vCPU אחד לכל (בערך) 2 ג'יגה זיכרון RAM. היחסים המדויקים שונים במקצת בין דורות שונים, מאז במקרים מאוחרות לעשות עבודה טובה יותר לסחוט יותר ערך החומרה.
- הדורות נבדלים גם בחלק מהתכונות הנוספות שהם מציעים. למשל, בכיתות C, M ו- R של הדור השלישי (C3, M3 ו- R3) יש כונני SSD מקומיים, אך לדור הרביעי (C4, M4 ו- R4) אין.
- עבור סוג ודור של מופע נתון, הפרשי גודל פשוט פירושם כמויות שונות של כל משאב, אך באותו הפרופורציה (שים לב שחלק מההיבטים ההיקפיים של המפרט, כגון אחסון SSD ותפוקה, אינם מתרחשים באופן ליניארי). עבור מקרים לפי דרישה ושמורות, העלויות מתרחבות באופן ליניארי עם הגודל בתוך סוג ומופע נתון. במקרה נקודתי, ייתכן שהעלויות אינן מתרחבות באופן ליניארי מכיוון שהן נקבעות על פי היצע וביקוש, אך עבור סוגי המופעים הנפוצים ביותר, קנה המידה קרוב לליניארי.
- עבור סוג ודור מופע נתון, בדרך כלל ניתן לשנות סוג הזמנה (לאחר שההזמנה כבר בוצעה) כדי להקצות מחדש קיבולת בין גדלים שונים. לדוגמה, c3,2xlarge הוא כפול מהקיבולת של c3.xlarge, כך שאפשר לשנות הזמנה של 5 c3,2xlarge ל- 10 c3.xlarge, או ל- 3 c3,2xlarge ו- 4 c3.xlarge.
- זכור שלשמות סוגי המופעים אין משמעות עמוקה יותר מאשר מתן תיאור אינטואיטיבי של המפרט. כך, למשל, C הוא "אופטימיזציה מחשבית" אך כל המשמעות היא שהיחס בין vCPUs לזיכרון הוא יותר לטובת vCPUs מאשר בזיכרון. אין אופטימיזציה ספציפית לחישוב מעבר למה שהמפרט כבר חושף.
- תפוקת הרשת לא ממש משתנה באופן ליניארי.
2
הבן את היחס בין שלושת המחלקות העיקריות. שים לב שהיחס המדויק משתנה בין הדורות.
- מחלקת המופע R מותאמת בזיכרון ומציעה את הזיכרון המרבי לכל vCPU (כלומר, המספר הנמוך ביותר של vCPU ליחידה). היחס הוא כ- 7,5 GB / vCPU.
- מחלקת מופע M היא ביניים. הוא מציע 3,75 GB / vCPU.
- מחלקת המופע C מותאמת למחשבים ומציעה את הזיכרון הנמוך ביותר לכל vCPU (כלומר, המספר הרב ביותר של vCPU ליחידת זיכרון). היחס הוא כ -1,875 GB / vCPU.
3
להבין את היכולות המרביות הזמינות של המקרים, כדי לזהות את גבולות קנה המידה האנכי.
- מחלקה למשל M: M3 עולה ל- m3,2xlarge בלבד (30 GB, 8 vCPU). M4 עולה ל- m4,16xlarge (256 GB, 64 vCPU) אך חסר SSD.
- מחלקת מופע R: R3 עולה ל- r3,8xlarge (244 GB, 32 vCPU). R4 עולה ל- r4,16xlarge (488 GB, 64 vCPU) אך חסר SSD.
- מחלקת מופע C: C3 עולה ל- c3,8xlarge (60 GB, 32 vCPU). C4 עולה ל- c4,8xlarge (60 GB, 36 vCPU) אך חסר SSD. C5 (שמושק החל מדצמבר 2016) יעלה ל- c5,18xlarge (144 ג'יגה בייט, 72 vCPU) וגם חסר SSD.
4
הבן אילוצים נוספים שאתה עלול להתמודד איתם על סמך מערכת ההפעלה ו- AMI שאתה מתכוון להשתמש בהם.
- מרבית ההערות במאמר זה, כמו גם רוב הדיונים המקוונים ב- EC2, מתמקדים במקרה השימוש במקרים של לינוקס / יוניקס ללא עלויות רישוי.
- ניתן גם לפרוס מופעי EC2 עם מערכות הפעלה אחרות כמו Windows. מקרים אלה עולים יותר (מחזיקים קבועים את סוג המופע ואופציית הרכישה). הם גם מציעים פחות גמישות עם שינוי הזמנות. אין עמלות רישוי נפרדות; אמזון משלמת עבור הרישיונות וכוללת אותם בעלויות המקרה.

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

חלק 3 מתוך 9: הבנת דרישות היישום

1
הפעל את היישום שלך במקרים מסוימים כדי לראות כיצד הוא משתמש במשאבים שונים (מחשוב, זיכרון, אחסון מקומי, רשת) ומהם צווארי הבקבוק.
- השימוש במעבד ורשת מאוחסן במדדים ב- Amazon CloudWatch, מערכת הקלטת מדדים של אמזון. ניתן לגשת אליהם גם במסוף EC2.
- לא ניתן לעקוב אחר שימוש בזיכרון באמצעות קונסולת EC2 של אמזון. לכן יהיה עליך לעקוב אחר השימוש בזיכרון ביישום שלך, או באמצעות תהליך רישום זיכרון אחר שתתקין במופע שלך. תהליך כזה המומלץ על ידי אמזון (ויכול לייצא ל- CloudWatch) הוא אספנות.
- זכור כי נתוני השימוש במעבד ורשת אינם זמינים עוד במסוף EC2 לאחר סיום המופעים שלך. עם זאת, ניתן לצפות בהם במדדי CloudWatch (למעשה הסיבה שלא תוכלו לראות אותם במסוף EC2 היא שהמופע לא מופיע שם יותר).
- מדדי CloudWatch על שימוש במעבד ורשת (כמו גם כל מדדים מותאמים אישית אחרים שאתה מייצא) נשמרים למשך חלון נע של 15 חודשים, לעומת חלון נע של שבועיים קודם לכן. מכיוון שהשינוי הונהג לאחרונה, נכון לעכשיו, אתה יכול לקבל את המדדים רק בשלושת החודשים האחרונים.
2
זהה את משתני המפתח המשפיעים על השימוש במשאבים ביישומים שלך.
- עבור יישומי חזית, משתנה מפתח אחד המשפיע על השימוש במשאבים הוא רמות התנועה. זהה כיצד השימוש במשאבים שלך (הן זיכרון והן משאבי חישוב) משתנה עם רמות תנועה שונות. רמות התנועה עשויות להשתנות מדי יום ועונתיות וכן יש מגמות חילוניות (כלומר מגמות ארוכות טווח). ייתכן שתרצה לדמות באופן מלאכותי עומסי תנועה גבוהים יותר באמצעות כלים כגון Gatling או שירותים כגון Blitz.io.
- גודל הנתונים שבהם היישום שלך משתמש עשוי להשתנות גם ללא תלות ברמות התנועה. למשל, אם היישום שלך משרת אתר, מדדים הקשורים לגודל האתר (מספר עמודים, מספר חשבונות משתמש נפרדים) עשויים להשפיע על השימוש במשאבים. מדדים אלה אינם משתנים הרבה לטווח הקצר, אך נוטים לגדול עם הזמן, לכן יהיה עליך להקצין מהשימוש הנוכחי או לדמות באופן מלאכותי גודל אתר גדול יותר או יותר חשבונות משתמש.
3
זהה אינטראקציות ופרדות בין שימוש במשאבים בקוד שלך.
- עבור יישומים הפועלים במכונה הווירטואלית של Java (JVM), ככל שזיכרונך קרוב יותר לניצול מלא, כך מושקע זמן ומשאבים באיסוף אשפה. זה יכול לגרום לניצול המעבד לשמיים ולהגדלת החביון. תופעות דומות עשויות להופיע עבור יישומים הפועלים בסביבות אחרות.
- לכן, חשוב במיוחד לעקוב ולהבין מה הגורם המקורי לצווארי הבקבוק. פשוט לראות את השימוש במעבד מרקיע שחקים עד 100% לא מרמז שהבעיה הייתה במעט מדי מעבד. הבעיה יכולה להיות עם מעט מדי זיכרון שגורם למשאבי CPU להיאלץ לאיסוף אשפה.
4
אם אתה שוקל להריץ יישומים זהים במספר מופעים (אופייני לחזית המשרתת עומסים גבוהים), בדוק את הפשרות בין קנה המידה האופקי (תוך שימוש במקרים רבים יותר) וקנה המידה האנכי (באמצעות מקרים גדולים יותר). למשל, קבע אם עדיף להשתמש במספר מקרים גדולים, או פי שניים ממופעים גדולים.
- גבולות (לטובת קנה המידה האופקי): קנה המידה האנכי כולל גבולות הדוקים למדי: יש גבול עליון נמוך למדי בגודל של מקרים EC2 שבהם אתה יכול להשתמש (ראה חלק 2, שלב 3). עם סולם התשתית של AWS, המגבלות על קנה המידה האופקי הן הרבה יותר גדולות (למרות שלחשבון שלך מוגדרים מגבלות משלו על ידי AWS, אתה יכול לבקש העלאת מגבלה). אם אתה זקוק ל -1000 vCPU של חישוב, עליך להשתמש לפחות בקנה מידה אופקי, מכיוון שאפילו מגבלות קנה המידה האנכי מביאות אותך רק ל 64 vCPU.
- חלוקה רבה יותר ולכן דיוק טוב יותר ביכולות (לטובת קנה המידה האופקי): שימוש בסוגי מופעים קטנים יותר מאפשר לך לכוונן בצורה מדויקת יותר את מספר המופעים לקיבולת התעבורה. לדוגמה, נניח שאתה יודע שדרישת התעבורה שלך תצטרך 9 מקרים גדולים 3 כדי להגיש. בהנחה שאין זיכרון משותף או בעיות אחרות במשאבים משותפים, אם תרצה להשתמש במופעים c3.xlarge, תזדקק לחמישה כאלה, מכיוון שלא תוכל להשיג 4,5 מופעים, ובכך למעשה תבזבז את המקבילה של c3 משאבי חישוב. אם השתמשת במקרים c3,2xlarge, תזדקק לשלושה מהם, ובכך בוזבז למעשה את המקבילה לשלושה c3.large במשאבי חישוב. אם השתמשת ב- c3,4xlarge היית זקוק לשניים מהם, ובכך לבזבז למעשה את המקבילה לשבעה c3.large.שים לב שהדבר חל גם אם יש לך צרכי תעבורה קבועים מאוד וגם אם יש לך צרכי תנועה משתנים, אך יש לך מערכת טובה לסולם אוטומטי.
- זמינות משופרת (מעורבת, אך בדרך כלל לטובת קנה המידה האופקי): קנה המידה האופקי מאפשר זמינות רבה יותר מכיוון שאם כל מקרה אחד יורד, הקיבולת שלך מופחתת זמנית רק מעט. לעומת זאת, עם קנה המידה האנכי, כל מקרה בודד שיורד פוגע מאוד ביכולת. מצד שני, קנה המידה האופקי יכול להפחית את הזמינות אם למקרים, בהיותם קטנים, יש פחות מאגר לטיפול בבקשה יחידה אינטנסיבית, ויורדים באופן זמני לקבלת בקשה כזו.
- יציבות עלויות (מעורבת, אך בדרך כלל לטובת קנה מידה אופקי): במקרים נקודתיים במיוחד, העלויות יציבות יותר עבור מקרים קטנים יותר בגלל מספר האנשים הגדול יותר שמשתמש בהן. עם זאת, זה לא נכון באופן אחיד.
- זכרון משותף (לטובת קנה המידה האנכי): אם היישום שלך משתמש בנתונים נפוצים רבים בזיכרון לצורך עיבוד בקשות, אז קנה המידה האנכי עדיף מכיוון שהוא מאפשר לשתף את נתוני הזיכרון. למשל, אם אתם מספקים מנוע חיפוש ואתם מאחסנים את כל האינדקסים ב- RAM, והאינדקסים משתמשים ב -6 GB של נתונים. אם אתה משתמש בשני מופעים גדולים של m3.lar, אתה משכפל את 6 ג'יגה בייט בשתי המכונות ונותר לך רק 1,5 ג'יגה-בתים (= 7,5 - 6) לביצוע חישוב בכל מופע. מצד שני, אם אתה משתמש ב- m3,2xlarge אחד, נותר לך זיכרון יעיל של 9 ג'יגה בייט לחישוב. גם אם אינך שומר את כל הנתונים בזיכרון, אך שואל אותם מחנות נתונים, זיכרון משותף עדיין יכול לעזור לך בכך שהוא מאפשר לך לשמור מטמון במשאבים. שים לב ששיקול הזיכרון המשותף רלוונטי גם להחלטה בין מחלקות מופע, למשללקבוע אם M או C הגיוניים יותר.

חלק 4 מתוך 9: הבנת אזורי AWS ואזורי זמינות

1
להבין את הרעיון של אזור AWS. אזורי AWS הם שמות שניתן לאשכולות של מרכזי נתונים של אמזון שירותי אינטרנט סמוכים מבחינה גאוגרפית. נכון לאפריל 2020, ישנם שתים עשרה אזורי AWS (למעט AWS GovCloud): ארבעה באירופה, אחד בקנדה, שבעה באסיה-פסיפיק, חמישה באירופה, אחד במזרח התיכון ואחד בדרום אירופה. אזורים נוספים של AWS צפויים להתווסף בקרוב באירופה.
- זמני הלוך ושוב באזור AWS הם כ -2 אלפיות השנייה.
- העברת נתונים בין שירותי AWS שונים באזור, כולל למקרי EC2 וממנה, היא זולה משמעותית מהעברת נתונים חוצה אזורים אך אינה חינמית לחלוטין.
- המחירים שונים לפי אזור AWS, אך הם זהים באזור AWS נתון.
2
להבין את הרעיון של אזור זמינות AWS (AZ).
- אזורי ה- AZ הם חלוקות משנה באזורי AWS. מספר אזורי ה- AZ בכל אזור נע בין 2 ל -4.
- אזורי ה- AZ מבודדים כולם זה מזה, כך שכשלים ב- AZ אחד (כגון שריפות או הפסקות חשמל) לא אמורים להשפיע לרעה על פעולתו של ה- AZ האחר.
- ה- AZ עבור מופע EC2 מוגדר בזמן יצירת המופע.
- למרות שהמחירים למקרים לפי דרישה ושמורה זהים בכל אזורי זמינות שונים באזור, שווקי המופע הספציפי שונים באזורי הזמינות השונים.
- הזמנות היו קשורות בעבר לאזור זמינות מסוים. החל מחודש ספטמבר 2016, ניתן לתת הזמנות להיקף אזור הזמינות או להיקף האזור. אם ניתן להיקף האזור, ההזמנה אינה קשורה לאזור זמינות. למופעים ששמורים לפני כן יש אזור היקף זמינות אך ניתן לשנותם לטווח האזורים.

זכור כי אינך צריך להשתמש ב- ec2 רק בגלל שאתה משתמש בשירותי אמזון אחרים.

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

1
הבן את שני הסוגים השונים של אחסון הדיסקים שמציעה אמזונה למקרי ה- ec2 שלה.
- אחסון בלוקים אלסטי (EBS) הוא נפח אחסון בעל תפוקה גבוהה המשוכפל על פני אזור הזמינות. ניתן לצרף EBS נתון לכל היותר למופע EC2 אחד בכל פעם, אך ניתן לשנות את המופע אליו הוא מצורף. EBS יכול להימשך גם כאשר המופע הופסק (אם צוין בעת ההשקה) גם לאחר סיום המופע.
- אחסון מופעים הוא אחסון מקומי המשויך למופע מסוים. הוא מציע קלט / פלט מהיר יותר אך ללא יתירות וללא התמדה.
- תלוי בתמונת המכונה של אמזון (AMI) המשמשת בעת הפעלת מופע, נפח הבסיס של המופע עשוי להיות חנות EBS או חנות מופעים. סוגים קודמים של מקרים נקראים מופעי אתחול EBS או מופעים מגובים EBS.
- מופעים מהדור החדש (C4, M4, R4 ו- C5) אינם מציעים אחסון מופעים. הם תומכים רק ב- EBS.
2
הבן את השלכות העלות של השימוש במקרים מגובים ב- ebs.
- העלות של מופע EBS תלויה בגודלו כפי שצוין בעת יצירת אמצעי האחסון.
- EBS גובה גם תשלום עבור קלט / פלט. ישנם כמה סוגים שונים של EBS עם מודלים שונים של תמחור. עבור EBS רגיל, חיובי קלט / פלט מתרחשים בכל פעם שקלט / פלט מתרחש. עבור gp2, המיועד לתפוקה גבוהה, תחויב בגין תפוקה שהוקצה, ולא בשימוש בפועל, אך במערכת של הפיכת אשראי.
- עבור מקרים מגובים ב- EBS, אמצעי האחסון של EBS נמשכים גם כאשר מופע מופסק. במקרים ארוכי טווח, עלויות ה- EBS נמוכות למדי בהשוואה לעלויות המופע. עם זאת, במקרים המופעלים למספר שעות בלבד ביום ועוצרים בשאר הזמן, נפחי ה- EBS יכולים להיות חלק ניכר מהעלויות הכוללות.
- בהתאם להגדרות המשמשות בעת הפעלת ה- EBS, נפח ה- EBS עשוי להימשך או לא לאחר סיום המופע. אם הנפח נמשך, זה יכול לגרום לדליפת עלות משמעותית אם נפחי ה- EBS לא יוסרו.
- אם אתה מספק לעתים קרובות מקרים חדשים ולא מסיים את ה- EBS באופן אוטומטי עם סיום המופע, EBS עלול לגרום לדליפת עלויות משמעותית.
3
הבן כיצד פועלות תמונות של EBS. תמונת מצב של EBS מאחסנת תמונת מצב של התוכן הנוכחי של ה- EBS ל- S3.
- בעוד ש- EBS קשור לאזור זמינות, תמונת המצב של EBS זמינה בכל האזור, כך שניתן לאחזר אותו בכל אזור זמינות באזור. ניתן להעביר אותו גם על פני אזורים.
- אף על פי שצילומי EBS מאוחסנים ב- S3, המטא נתונים לאחזורם נשמרים במערכת EBS. לא ניתן לגשת אליהם ישירות כאובייקטים S3. לפיכך, אף על פי שהנתונים הבסיסיים נשמרים בצורה מיותרת ביותר, התמונות נהנות מאמינות של 99,9% בלבד (לעומת 99,99% + עבור S3).
- ניתן להעביר צילומי EBS בין אזורים. החיובים הרגילים עבור העברת נתונים חוצה אזורים חלים.
- אחסון תמונות של EBS הוא מצטבר, כך שאם מצלמים תמונות EBS מספר פעמים, רק התוכן שהשתנה בין תמונות מאוחסנות. תהליך המחיקה, לעומת זאת, הוא חכם ומשחזר תמונות מאוחרות יותר לפני מחיקת קודמות.

חלק 6 מתוך 9: הבנת אפשרויות רכישה

1
מקרים לפי דרישה הם היקרים ביותר אך הקלים ביותר להתחיל איתם.
- ניתן לסובב מופעים לפי דרישה בכל עת, והם מחויבים על פי סוג המופע ומשך הזמן בו מופעלת המופע.
- ניתן להפסיק ולהפעיל מחדש מקרים לפי דרישה בכל עת. המופע אינו מחויב בזמן שהוא נעצר. האחסון המקומי (אם קיים) של המופע נהרס וכל כתובת IP ציבורית הקשורה למופע משוחררת (אלא אם כן הייתה זו כתובת IP אלסטית). עם זאת, אחסון החסימה האלסטי (EBS) המשויך למופע נשמר, ו- AWS עדיין גובים על כך תשלום.
- המשתמש יכול להפסיק מקרים לפי דרישה בכל עת. לאחר סיום המופע על פי דרישה, ניתן למחוק את אחסון הבלוקים האלסטי המתאים. זה תלוי בהגדרות שצוינו בהשקה.
- AWS לא יפסיק או יפסיק מקרים לפי דרישה, אם כי המופעים עשויים להיות מדי פעם לא זמינים עקב השפלה בחומרה או בעיות מרכז נתונים אחרות.
- מקרים לפי דרישה זכאים גם להגנת סיום המקשה על המשתמש לסיים את המופע בטעות.
2
מקרים נקודתיים הם זולים משמעותית מאשר מקרים לפי דרישה.
- בזמן היצירה, המשתמש שיוצר את המופע מציין את מחיר הספוט המרבי בנוסף לציין את אזור הזמינות וסוג המופע.
- כל עוד מחיר הספוט הנוכחי עבור אותו אזור זמינות וסוג מופע נמוך ממחיר הספוט המרבי, המופע יכול להיווצר ולא יסתיים. עם זאת, ברגע שהמחיר הנוכחי עולה על מחיר המופע הספציפי, המופע מסתיים.
- המחיר הנגבה בפועל ליחידת זמן הוא המחיר הספציפי הנוכחי ולא המחיר הספציפי המקסימלי.
- לא ניתן לעצור מקרים ספוטים. ניתן לסיים אותם רק על ידי המשתמש או על ידי AWS מטעמי מחיר.
- לא ניתן לשנות את מחיר הספוט עבור מופע ספוט לאחר יצירת המופע.
- היסטוריית תמחור של נקודת מופע לפי אזור, אזור זמינות וסוג מופעים זמינה באמזון ובאמצעותה ניתן לקבל החלטות חכמות להצעות מחיר.
- ישנן מגבלות על מספר המופעים הנקודתיים שניתן ליצור על ידי משתמש נתון עבור סוג מופע ואזור זמינות נתון. מגבלות אלה בדרך כלל הדוקות בהרבה מהמגבלות הקשורות למספר המקרים הכללי, בגלל ההרס שאנשים יכולים ליצור על ידי סיבוב חסר אחריות של מקרים נקודתיים עם מחירי נקודה גבוהים (וגורם למחירים הכוללים לעלות). עם זאת, בדרך כלל ניתן להגדיל מגבלות אלה על פי בקשה, בכפוף לכך שיש יכולת.
- עבור סוגים מסוימים של מקרים ואזורי זמינות, במיוחד סוג המופע I, סיבוב מקרים ספוטים יכול לקחת זמן רב בגלל יכולת הספוט הכוללת הנמוכה, למרות מחיר נקודתי נמוך.
3
ניתן לבצע הזמנות למשך שנה או שלוש שנים, עם שלושה סוגים של תוכניות תשלום: ללא מראש, חלקית מראש, והכל מראש.
- לא ניתן לשנות היבטים מסוימים של הזמנה לאחר ביצוע ההזמנה. אלה כוללים את פרק הזמן להזמנה, סוג תוכנית התשלומים, מערכת ההפעלה, סוג השכירות (ייעודי לעומת ברירת מחדל) והאזור.
- עבור מופעים שמורים סטנדרטיים (RI רגילים), לא ניתן לשנות את מחלקת המופע והדור (כגון R3, C3, M3, M4).
- עבור RI רגילים, באפשרותך לשנות את גודל המופע באותו מחלקה ודור של מופע זהה. ניתן לשנות את גודל המופע תוך שמירה על אותה קיבולת כוללת. לדוגמה, ניתן לשנות הזמנה לשלושה מופעים m3.xlarge להזמנה למופע m3,2xlarge אחד ומופע m3.xlarge אחד.
- אם להזמנות שלך יש טווח אזור זמינות, עליך לעבור לאזור הזמינות או לשנות לטווח האזורים כדי להשתמש בהזמנה באזור זמינות אחר.
- שים לב ששינוי גודל של מקרים, קבלת היקף אזור או שינוי אזור זמינות אינו אפשרי עבור הזמנות הקשורות למערכות הפעלה בעלות רישיון, כגון מערכות הפעלה Windows.
- ההזמנה אינה קשורה לשום מקרה מסוים. למעשה, המקרים עליהם חלים הסתייגויות נוצרים באותו אופן כמו מקרים לפי דרישה. הדרך בה הזמנות עובדות היא שבכל שעה בה מחושב החיוב, המקרים הקיימים לפי דרישה הנמצאים בשימוש נבדקים מול ההזמנות הפעילות כיום. אם כל אחת מההזמנות חלה, המחירים המופחתים בהתבסס על ההזמנות חלים על המקרים. אחרת, המחיר המלא לפי דרישה חל.
- עבור מקרים שמורים להמרה (RIs להמרה) ניתן לשנות את מחלקת המופע ואת הדור. אם התצורה החדשה עולה יותר מהקודמת, אתה משלם את ההפרש, אם זה עולה פחות, AWS לא מחזיר לך את ההפרש, אך אתה יכול למכור את הקיבולת העודפת בשוק המקרים השמורים.

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

חלק 7 מתוך 9: עבודה על ארכיטקטורה חזקה ללא תלות

1

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

אם היישום שלך מטפל בעומסים משתנים מתעבורת אינטרנט בזמן אמת, שים את המקרים מאחורי איזון עומסים אלסטי (ELB).
3

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

שמור על כל הנתונים הקריטיים לאורך זמן מחוץ למופעי EC2 בודדים (למעט פוטנציאל למופעים מיוחדים המיועדים לחנויות נתונים, אותם אתה מגבה מעת לעת). במידת האפשר, השתמש ב- S3 או בבסיסי נתונים עבור נתונים ארוכי טווח.
5
הסקריפטים שלך אמורים להיות מסוגלים לטפל בעדכונים ליישום שלך בצורה חלקה. הם יכולים לטפל בעדכונים באחת מהדרכים הבאות:
- ניתן לעדכן את היישומים עצמם במופע הפקה חי ללא צורך לקחת את אותה מופע במצב לא מקוון. אמנם זה נכון לגבי סוגים מסוימים של עדכונים, אך אינך צריך להסתמך על זה כדרך היחידה שבה ניתן לעדכן את היישום.
- מופעים חדשים עם קוד היישום המעודכן נפרסים, ומחוברים לאיזון העומס, והמופעים הישנים מנותקים לאחר מכן מאיזון העומסים ומסתיימים. עבור עדכון מסוג זה, הקיבולת גדולה באופן זמני במהלך העדכון. שים לב שקיבולת המופע העודפת תיפול מחוץ לקיבולת השמורה, ולכן המקרים החדשים, אם הם על פי דרישה, יחויבו בשיעורים מלאים לפי דרישה במהלך המעבר.
- כל אחד מהמקרים הקיימים עודכן. אם ניתן לטפל בעומס הייצור הנוכחי על ידי פחות ממכלול המופעים המלא, ניתן לעדכן את המופעים בזה אחר זה: כל מופע מנותק מאיזון העומסים, מעודכן ואז מתחבר מחדש למאזנת העומס. בעדכון מסוג זה, הקיבולת זמנית קטנה יותר במהלך העדכון. אם עומסי הייצור משתנים לפי שעות היום, ניתן לבצע עדכון מסוג זה בזמן שעומס הייצור נמוך.
6

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

הפץ מקרים על פני אזורי זמינות מרובים באזור כדי לקבל חוסן רב יותר מפני פגיעה באזור זמינות מסוים. ניתן להפעיל כל אזור זמינות באזור נתון עבור ELB הקשור לאזור זה.
8

השתמש במסלול 53 ובדיקות בריאות וכשלים לצורך יתירות בין אזורים בהגשה בשידור חי.

קרא גם: איך מכינים לימונדה של ריבס?

חלק 8 מתוך 9: הגדרת מעקב וניטור

1

בשנות ה EC2 של אמזון קונסולת ("דוחות" סעיף), אתה יכול לקבל דוחות על עלויות EC2 של אמזון (זו אינה כוללת חלק מעלויות העברת נתונים) וכן ניצול למשל שמורות. באפשרותך לפרק את המידע לפי אזור, אזור זמינות, סוג מופע, סוג מופע ואופציית רכישה, ולהסתכל על השימוש על בסיס שעתי או יומי. הנתונים לא זורמים מיד ויכולים להתעכב ב-24-48 שעות.
2

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

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

לחשבון AWS שלך יש גישה לנתוני החיוב המספקים את פירוט העלויות המלא.

חלק 9 מתוך 9: קבלת ושיפור החלטות הרכישה שלך

1

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

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