בניית API להרחבה במופעי AWS Spot

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

מהם מופעי ספוט?

לְזַהוֹת מופעים הם שרתים של משתמשי AWS אחרים שאינם פעילים כרגע, והם מוכרים אותם בהנחה גדולה (אמזון כותבת עד 90%, מניסיוננו ~3x, משתנה בהתאם לאזור, AZ וסוג המופע). ההבדל העיקרי שלהם מהרגילים הוא שהם יכולים לכבות בכל עת. לכן, במשך זמן רב האמנו שזה נורמלי להשתמש בהם עבור סביבות בתוליות, או עבור משימות של חישוב משהו, עם תוצאות ביניים נשמרות ב-S3 או במסד הנתונים, אבל לא עבור מכירות. ישנם פתרונות של צד שלישי המאפשרים לך להשתמש בספוטים בייצור, אבל יש הרבה קביים למקרה שלנו, אז לא יישמנו אותם. הגישה המתוארת במאמר פועלת כולה במסגרת הפונקציונליות הסטנדרטית של AWS, ללא סקריפטים נוספים, כתרים וכו'.

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

m5.large באזור eu-west-1 (אירלנד). המחיר יציב ברובו במשך 3 חודשים, כרגע חוסך פי 2.9.

m5.large באזור us-east-1 (N. Virginia). המחיר משתנה ללא הרף במשך 3 חודשים, כרגע חוסך מ-2.3x ל-2.8x בהתאם לאזור הזמינות.

t3.small באזור us-east-1 (N. Virginia). המחיר יציב במשך 3 חודשים, כרגע חוסך פי 3.4.

ארכיטקטורת שירות

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

מאזן עומסי יישומים → EC2 Target Group → שירות מיכל אלסטי

מאזן עומסי יישומים (ALB) משמש כמאזן, ששולח בקשות לקבוצת היעד של EC2 (TG). TG אחראית על פתיחת נמלים על מופעים עבור ALBs וחיבורם לנמלים של מכולות Elastic Container Service (ECS). ECS הוא אנלוגי של Kubernetes ב-AWS, המנהלת מכולות Docker.

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

EC2 Auto Scaling Groups + ECS Capacity

התרשים לעיל אינו מציג את שירות EC2 Auto Scaling Groups (ASG). מהשם אפשר להבין שהוא אחראי על קנה מידה של מופעים. עם זאת, עד לאחרונה, ל-AWS לא הייתה יכולת מובנית לנהל את מספר המכונות הפועלות מ-ECS. ECS אפשרה להתאים את מספר המשימות, למשל, לפי שימוש במעבד, זיכרון RAM או מספר בקשות. אבל אם המשימות תפסו את כל המופעים החינמיים, מכונות חדשות לא נוצרו אוטומטית.

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

תבניות הפעלה של EC2

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

אחד מפרמטרי התצורה החשובים ביותר עבור מאמר זה הוא ECS_ENABLE_SPOT_INSTANCE_DRAINING=נכון. אם פרמטר זה מופעל, אז ברגע ש-ECS מקבל אות כי מופע ספוט נלקח, הוא מעביר את כל המשימות שעובדות עליו למצב Draining. לא יוקצו משימות חדשות למופע זה; אם יש משימות שרוצות להתגלגל אליו עכשיו, הן יבוטלו. גם בקשות מהמאזן מפסיקות להגיע. הודעה על מחיקת מופע מגיעה 2 דקות לפני האירוע בפועל. לכן, אם השירות שלך לא מבצע משימות יותר מ-2 דקות ואינו שומר דבר בדיסק, אז אתה יכול להשתמש במופעים נקודתיים מבלי לאבד נתונים.

לגבי דיסק - AWS לאחרונה עשה אפשר להשתמש במערכת הקבצים האלסטית (EFS) יחד עם ECS; עם סכמה זו, אפילו הדיסק אינו מהווה מכשול, אך לא ניסינו זאת, מכיוון שבאופן עקרוני איננו זקוקים לדיסק כדי לאחסן את המצב. כברירת מחדל, לאחר קבלת SIGINT (נשלח כאשר משימה מועברת למצב ניקוז), כל המשימות הפועלות יופסקו לאחר 30 שניות, גם אם הן טרם הושלמו; ניתן לשנות את הזמן הזה באמצעות הפרמטר ECS_CONTAINER_STOP_TIMEOUT. העיקר לא להגדיר אותו ליותר מ-2 דקות עבור מכונות ספוט.

יצירת שירות

בואו נעבור ליצירת השירות המתואר. בתהליך, אתאר בנוסף מספר נקודות שימושיות שלא הוזכרו לעיל. באופן כללי, זו הוראה שלב אחר שלב, אבל אני לא אתייחס למקרים מאוד בסיסיים או להיפך, מאוד ספציפיים. כל הפעולות מבוצעות במסוף הוויזואלי של AWS, אך ניתן לשחזר אותם באופן תוכניתי באמצעות CloudFormation או Terraform. ב-Adapty אנו משתמשים ב- Terraform.

תבנית הפעלה של EC2

שירות זה יוצר תצורה של מכונות שישמשו. התבניות מנוהלות בסעיף EC2 -> מופעים -> הפעלה של תבניות.

תמונת מכונת אמזון (AMI) - ציין את תמונת הדיסק איתה יופעלו כל המופעים. עבור ECS, ברוב המקרים כדאי להשתמש בתמונה האופטימלית מאמזון. הוא מתעדכן באופן קבוע ומכיל את כל הדרוש ל-ECS לעבוד. כדי לגלות את מזהה התמונה הנוכחי, עבור לדף AMIs מותאמים לאמזון ECS, בחר את האזור שבו אתה משתמש והעתק את מזהה AMI עבורו. לדוגמה, עבור אזור us-east-1, המזהה הנוכחי בזמן הכתיבה הוא ami-00c7c1cf5bdc913ed. יש להכניס את המזהה הזה לפריט ציין ערך מותאם אישית.

סוג מופע - ציין את סוג המופע. בחר את המתאים ביותר למשימה שלך.

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

הגדרות רשת - ציין את פרמטרי הרשת. פלטפורמת רשת ברוב המקרים צריך להיות ענן פרטי וירטואלי (VPC). קבוצות אבטחה - קבוצות אבטחה עבור המקרים שלך. מכיוון שנשתמש באיזון לפני המופעים, אני ממליץ לציין כאן קבוצה שמאפשרת חיבורים נכנסים רק מהאיזון. כלומר, יהיו לך 2 קבוצות אבטחה, האחת עבור האיזון, המאפשרת חיבורים נכנסים מכל מקום ביציאות 80 (http) ו-443 (https), והשנייה למכונות, המאפשרת חיבורים נכנסים בכל פורט מקבוצת האיזון. . יש לפתוח חיבורים יוצאים בשתי הקבוצות באמצעות פרוטוקול TCP לכל היציאות לכל הכתובות. אתה יכול להגביל יציאות וכתובות לחיבורים יוצאים, אבל אז אתה צריך לפקח כל הזמן שאתה לא מנסה לגשת למשהו ביציאה סגורה.

אחסון (נפחים) - ציין את פרמטרי הדיסק עבור המכונות. גודל הדיסק לא יכול להיות קטן מזה שצוין ב-AMI; עבור ECS Optimized הוא 30 GiB.

פרטים מתקדמים - ציין פרמטרים נוספים.

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

פרופיל מופע IAM - ציין את התפקיד שבו יופעלו המופעים. כדי שמופעים יפעלו ב-ECS, הם זקוקים להרשאות, שבדרך כלל נמצאות בתפקיד ecsInstanceRole. במקרים מסוימים ניתן ליצור אותו, אם לא, אז כאן הוראה על איך לעשות זאת. לאחר היצירה, אנו מציינים זאת בתבנית.
בשלב הבא יש פרמטרים רבים, בעצם אתה יכול להשאיר ערכי ברירת מחדל בכל מקום, אבל לכל אחד מהם יש תיאור ברור. אני תמיד מפעיל את המופע המותאם ל-EBS ואפשרויות T2/T3 Unlimited אם משתמשים בהם מתפרץ מקרים.

זמן משתמש - ציין את נתוני המשתמש. אנו נערוך את הקובץ /etc/ecs/ecs.config, המכיל את תצורת סוכן ECS.
דוגמה לאיך עשויים להיראות נתוני משתמש:

#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> /etc/ecs/ecs.config

ECS_CLUSTER=DemoApiClusterProd — הפרמטר מציין שהמופע שייך לאשכול עם השם הפרטי, כלומר, אשכול זה יוכל למקם את המשימות שלו בשרת זה. עדיין לא יצרנו אשכול, אבל נשתמש בשם זה בעת יצירתו.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true - הפרמטר מציין שכאשר מתקבל אות לכיבוי מופע ספוט, יש להעביר את כל המשימות עליו למצב ניקוז.

ECS_CONTAINER_STOP_TIMEOUT=1m - הפרמטר מציין שאחרי קבלת אות SIGINT, לכל המשימות יש דקה אחת לפני הרג.

ECS_ENGINE_AUTH_TYPE=docker - הפרמטר מציין שסכימת Docker משמשת כמנגנון ההרשאה

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

למטרות מאמר זה, אשתמש בתמונה ציבורית מ- Docker Hub, אז ציין את הפרמטרים ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA לא צריך.

טוב לדעת: מומלץ לעדכן את ה-AMI באופן קבוע, כי גרסאות חדשות מעדכנות גרסאות של Docker, Linux, ECS agent וכו'. כדי לא לשכוח את זה, אתה יכול להגדיר התראות על שחרור גרסאות חדשות. אתה יכול לקבל הודעות באימייל ולעדכן באופן ידני, או שאתה יכול לכתוב פונקציית Lambda שתיצור אוטומטית גרסה חדשה של Launch Template עם AMI מעודכן.

קבוצת קנה מידה אוטומטי של EC2

Auto Scaling Group אחראית על השקה ושינוי קנה מידה של מופעים. קבוצות מנוהלות בקטע EC2 -> קנה מידה אוטומטי -> קבוצות קנה מידה אוטומטי.

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

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

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

אחוז לפי דרישה מעל הבסיס - יחס באחוזים של מופעים רגילים ונקודתיים, 50-50 יחולקו באופן שווה, 20-80 לכל מופע רגיל יועלו 4 נקודות נקודתיות. לצורך דוגמה זו, אציין 50-50, אך במציאות אנו עושים לרוב 20-80, במקרים מסוימים 0-100.

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

רשת — הגדרות רשת, בחר VPC ורשתות משנה למכונות, ברוב המקרים עליך לבחור את כל רשתות המשנה הזמינות.

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

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

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

הגנה על קנה מידה - הגנה על מופעים מפני מחיקה בעת הקטנה. אנו מאפשרים זאת כך ש-ASG לא תמחק את המחשב שיש לו משימות פועלות. ECS Capacity Provider ישבית את ההגנה עבור מופעים שאין להם משימות.

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

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

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

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

מאזן עומס אפליקציות וקבוצת יעד EC2

המאזן נוצר בסעיף EC2 → Load Balancer → Load Balancers. אנו נשתמש ב- Application Load Balancer; ניתן לקרוא השוואה בין סוגים שונים של מאזנים דף שירות.

מאזינים - הגיוני לבצע יציאות 80 ו-443 ולנתב מחדש מ-80 ל-443 באמצעות כללי איזון מאוחר יותר.

אזורי זמינות - ברוב המקרים, אנו בוחרים אזורי נגישות לכולם.

הגדר את הגדרות האבטחה - תעודת SSL עבור המאזן מסומנת כאן, האפשרות הנוחה ביותר היא לעשות תעודה ב-ACM. לגבי ההבדלים מדיניות אבטחה ניתן לקרוא ב תיעוד, אתה יכול להשאיר אותו נבחר כברירת מחדל ELBSecurityPolicy-2016-08. לאחר יצירת האיזון, תראה אותו שם DNS, שאתה צריך כדי להגדיר את ה-CNAME עבור הדומיין שלך. לדוגמה, כך זה נראה ב-Cloudflare.

קבוצת אבטחה - צור או בחר קבוצת אבטחה עבור המאזן, כתבתי עוד על זה ממש למעלה ב-EC2 Launch Template ← סעיף הגדרות רשת.

קבוצת היעד — אנו יוצרים קבוצה שאחראית על ניתוב בקשות מהמאזן למכונות ובדיקת זמינותן על מנת להחליפן במקרה של בעיות. סוג היעד חייב להיות Instance, פרוטוקול и נָמָל כל, אם אתה משתמש ב-HTTPS לתקשורת בין המאזן למופעים, עליך להעלות להם אישור. למטרות הדוגמה הזו, לא נעשה זאת, פשוט נעזוב את יציאה 80.

בדיקות בריאות - פרמטרים לבדיקת פונקציונליות השירות. בשירות אמיתי זו צריכה להיות בקשה נפרדת המיישמת חלקים חשובים מהלוגיקה העסקית; למטרות דוגמה זו אשאיר את הגדרות ברירת המחדל. לאחר מכן, תוכל לבחור את מרווח הבקשות, הזמן הקצוב, קודי ההצלחה וכו'. בדוגמה שלנו, נציין את קודי ההצלחה 200-399, מכיוון שתמונת ה-Docker שתשמש מחזירה קוד 304.

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

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

הגדרת משימות ECS

בשלבים הקודמים יצרנו את כל מה שקשור לתשתית השירות, כעת נעבור לתיאור הקונטיינרים שנשיק. זה נעשה בסעיף ECS → הגדרות משימות.

תאימות לסוג ההשקה - בחר EC2.

ביצוע משימה תפקיד IAM - בחר ecsTaskExecutionRole. באמצעותו נכתבים יומנים, ניתנת גישה למשתנים סודיים וכו'.

במקטע הגדרות מיכל, לחץ על הוסף מיכל.

תמונה - קישור לתמונה עם קוד הפרויקט; לדוגמא זו אשתמש בתמונה ציבורית מ- Docker Hub bitnami/node-example:0.0.1.

מגבלות זיכרון - מגבלות זיכרון עבור המיכל. גבול קשה - מגבלה קשה, אם המיכל חורג מהערך שצוין, תבוצע פקודת docker kill, המיכל ימות מיד. מגבלה רכה - מגבלה רכה, המיכל יכול לחרוג מהערך שצוין, אך פרמטר זה יילקח בחשבון בעת ​​הצבת משימות על מכונות. לדוגמה, אם למכונה יש 4 GiB של זיכרון RAM, והמגבלה הרכה של מיכל היא 2048 MiB, אז למכונה הזו יכולות להיות לכל היותר 2 משימות פועלות עם מיכל זה. במציאות, 4 GiB של זיכרון RAM הוא מעט פחות מ-4096 MiB, ניתן לראות זאת בכרטיסייה ECS Instances באשכול. גבול רך לא יכול להיות גדול מגבול קשה. חשוב להבין שאם יש כמה מכולות במשימה אחת, אז הגבולות שלהם מסוכמים.

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

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

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

פיקוד - פקודה להפעלת שירות בתוך קונטיינר, כל הפרמטרים מצוינים מופרדים בפסיקים. זה יכול להיות גוניקורן, npm וכו'. אם לא צוין, הערך של הוראת CMD מה- Dockerfile ישמש. אנו מציינים npm,start.

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

אחסון ורישום - כאן נגדיר רישום ב-CloudWatch Logs (שירות ליומנים מ-AWS). כדי לעשות זאת, פשוט הפעל את תיבת הסימון הגדר אוטומטית של CloudWatch Logs. לאחר יצירת הגדרת המשימות, קבוצה של יומנים תיווצר אוטומטית ב-CloudWatch. כברירת מחדל, יומנים מאוחסנים בו ללא הגבלת זמן; אני ממליץ לשנות את תקופת השמירה מ-Nover Expire לתקופה הנדרשת. זה נעשה בקבוצות CloudWatch Log, אתה צריך ללחוץ על התקופה הנוכחית ולבחור תקופה חדשה.

Cluster ECS וספק קיבולת ECS

עבור למקטע ECS → אשכולות כדי ליצור אשכול. אנו בוחרים ב-EC2 Linux + Networking כתבנית.

שם אשכול - חשוב מאוד, אנו יוצרים כאן את אותו השם כפי שצוין בפרמטר ה-Launch Template ECS_CLUSTER, במקרה שלנו - DemoApiClusterProd. סמן את תיבת הסימון צור אשכול ריק. לחלופין, תוכל לאפשר ל-Container Insights להציג מדדים עבור שירותים ב-CloudWatch. אם עשית הכל נכון, בקטע ECS Instances תראה מכונות שנוצרו בקבוצת Auto Scaling.

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

קבוצת קנה מידה אוטומטי — בחר את הקבוצה שנוצרה קודם לכן.

קנה מידה מנוהל - אפשר זאת כך שהספק יוכל להגדיל את השירות.

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

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

ECS שירות והגדרת קנה מידה

שלב אחרון :) כדי ליצור שירות, עליך לעבור לאשכול שנוצר בעבר בלשונית שירותים.

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

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

שם השירות - כדי למנוע בלבול, אנו תמיד מציינים את אותו הדבר כהגדרת משימה.

סוג שירות - תמיד העתק.

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

מינימום אחוז בריא и אחוז מקסימום - לקבוע את התנהגות המשימות במהלך הפריסה. ערכי ברירת המחדל הם 100 ו-200, מה שמצביע על כך שבזמן הפריסה מספר המשימות יגדל מספר פעמים, ולאחר מכן יחזור לערך הרצוי. אם יש לך משימה אחת שפועלת, min=1 ומקסימום=0, אז במהלך הפריסה היא תהרוג, ואחריה תועלה משימה חדשה, כלומר, זה יהיה השבתה. אם משימה אחת פועלת, min=100, max=1, אז הפריסה לא תתרחש כלל, מכיוון שלא ניתן לחלק משימה אחת לשניים או להגדיל אותה פי אחד וחצי.

סוג פריסה - השאר עדכון מתגלגל.

תבניות מיקום - כללים להצבת משימות על מכונות. ברירת המחדל היא AZ Balanced Spread - המשמעות היא שכל משימה חדשה תוצב על מופע חדש עד שהמכונות בכל אזורי הזמינות יעלו. בדרך כלל אנו עושים BinPack - CPU ו-Spread - AZ; עם מדיניות זו, משימות ממוקמות בצפיפות ככל האפשר על מכונה אחת לכל מעבד. אם יש צורך ליצור מכונה חדשה, היא נוצרת באזור זמינות חדש.

סוג איזון עומסים — בחר מאזן עומס יישומים.

שירות IAM תפקיד - בחר ecsServiceRole.

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

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

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

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

תפקיד IAM עבור שירות קנה מידה אוטומטי - בחר AWSServiceRoleForApplicationAutoScaling_ECSService.

מדיניות קנה מידה אוטומטי של משימות - כללי קנה מידה. ישנם 2 סוגים:

1. מעקב אחר יעדים - מעקב אחר מדדי יעד (שימוש ב-CPU/RAM או מספר בקשות לכל משימה). לדוגמה, אנו רוצים שעומס המעבד הממוצע יהיה 85%, כאשר הוא הופך גבוה יותר, יתווספו משימות חדשות עד שיגיע לערך היעד. אם העומס נמוך יותר, המשימות יוסרו, להיפך, אלא אם מופעלת הגנה מפני הקטנה (השבת את קנה המידה).
2. קנה מידה שלב - תגובה לאירוע שרירותי. כאן אתה יכול להגדיר תגובה לכל אירוע (אזעקת CloudWatch), כאשר הוא מתרחש, אתה יכול להוסיף או להסיר את מספר המשימות שצוין, או לציין את המספר המדויק של המשימות.

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

מסקנה

אם עקבת אחר ההוראות והשתמשת באותה תמונת Docker, השירות שלך אמור להחזיר עמוד כזה.

1. יצרנו תבנית לפיה כל המכונות בשירות מופעלות. למדנו גם כיצד לעדכן מכונות כאשר התבנית משתנה.
2. הגדרנו את העיבוד של אות עצירת המופע הנקודתי, כך שבתוך דקה לאחר קבלתו, כל המשימות הפועלות יוסרו מהמכונה, כך ששום דבר לא יאבד או מופרע.
3. הרמנו את המאזן כדי לפזר את העומס באופן שווה על פני המכונות.
4. יצרנו שירות שפועל על מופעים נקודתיים, מה שמפחית את עלויות המכונה בכפי 3.
5. הגדרנו קנה מידה אוטומטי בשני הכיוונים כדי להתמודד עם עומסי עבודה מוגברים מבלי להיגרם בעלויות של זמן השבתה.
6. אנחנו משתמשים ב-Capacity Provider כדי שהאפליקציה תנהל את התשתית (המכונות) ולא להיפך.
7. אנחנו מעולים.

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

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

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

בקרוב יהיו מאמרים על האופן שבו אנו מעבדים אלפי אירועים אנליטיים בשנייה על מחסנית נטולת שרתים (עם כסף) וכיצד פועלת פריסת השירותים באמצעות GitLab CI ו- Terraform Cloud.

הירשמו אלינו, זה יהיה מעניין!

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

האם אתה משתמש במופעים נקודתיים בהפקה?

• 22,2%כן6

• 66,7%מספר 18

• 11,1%למדתי עליהם ממאמר ומתכננת להשתמש בהם3

27 משתמשים הצביעו. 5 משתמשים נמנעו.

מקור: www.habr.com