תכנון קיבולת

1) מהי תכונת הקיבולת ומדוע היא נחוצה

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

• ביצוע SLO/SLA אפילו בפסגות ומשפלות.
• למזער את TCO ואת הגדלת ההון.
• הפחת את הסיכון שבתקריות ייגמרו המשאבים (רוויה p99/שגיאה).
• להבטיח את יכולת החיזוי של פרסומות וקמפיינים (שיווק, טורנירים, גפרורים).

2) כניסות ומקורות אמת

תצפיות: RPS/concatentation, p50/p95/p99, שגיאה-קצב, רוויה (CPU, mem, disk IOPS, network pps/mbps), אורכי תור, מגבלות קצב.
אירועים עסקיים: לוחות שנה לקמפיין, עונתיות (ערבים/סופי שבוע/מגה-אירועים), אזורים/תחום שיפוט.
חוב/תכונות טכניות: מפת דרכים של שחרורים, שינויים ארכיטקטוניים (לדוגמה, הצפנה, כריתת עצים חדשים).
ספקים: מכסות והפקת תשלומים/CUS/דואר/שירותי נגד הונאה.
אירועים מן העבר: היכן צוואר הבקבוק (מסד נתונים, מטמון, L7 Balancer, אוטובוס, CDN, דיסק).

3) מושגי יסוד ונוסחאות

מרווח קיבולת של חדר הראש: (max _ stable _ RPS )/max _ stable _ RPS.
המטרה בשיא של 20-40% (לזרמים קריטיים).
רוויה - היחס בין המשאב הכבוש לזמין (CPU%, זיכרון/GC, חיבורים, תיאורי קבצים, IOPS, עומק תור).
דרך יציבה - המהירות שבה p99 וקצב שגיאה מבצעים SLO במשך זמן רב (לא פרץ חד פעמי).
יחידת קיבולת (CU) - יחידת כוח מנורמלת עבור השירות (לדוגמה, X RPS per Pod VCPU = 1, RAM = 2 GiB).
גבול המערכת הוא מקסימום ללא פיגור: ”N _ pods × CU”. חשוב לקחת בחשבון תלויות משותפות (DB/cache/bus).

4) מודל דרישה: חיזוי

סדרה סטטיסטית: עונה שבועית/יומית, חגים, גמר ספורט, פסגות אזוריות.
קוהורטות: ע ”י מדינה, ספקי תשלומים, מכשירים, מקטעי אח” מים.
דלתות אירוע: השפעה של קמפיינים/כלבלבים/משחררים/SEO.
”מה אם” (תכנון תרחיש): + 50% לתנועה בשעות 19: 00-22: 00; טיפה של ספק A * חלוקה מחדש ל-B (+ 30% עד איחור).
התאמות בזמן אמת: עכשיו על ידי מדדי עופרת (חידוש הפעלות, תור להתאמה, סלים).

5) מודל אספקה: היכן שהשרשרת ”נשברת” ‏

מסוע חקירה: Edge/CDN * L7 balancer # application # cache # DB # extreme API * turn/tire actors/ETL.

• קיבולת (CU/Extreme), סקלביליות (אופק/ורטקס), גבולות (חיבורים, pps, IOPS), עיכובים.
• מדיניות כישלון (מגבלת קצב, מפסק מעגל חשמלי, הידרדרות).
• SLOs הם מקומיים ותרומתם e2e-SLO.

6) מרווח שגיאה ותקציב

אנו קושרים את חדר הראש לתקציב השגיאה: פחות תקציב = יותר מניות.
לזרימות קריטיות (תשלום/אימות) - חדר ראש למעלה, לזרימות משניות - למטה.
רזרבות קרות/חמות: מופעלות בשיא/תאונה.

7) קנה מידה: טקטיקות

HPA (על ידי מטרי טעינה): RPS, Latency, אורך תור, SLIS משתמש (טוב יותר מ-CPU%).
VPA: תיקון משאבי פודאם (זהירות עם p99 GC מדינתי).
KEDA/מתאם: הגדלה לפי מקורות חיצוניים (Kafka lag, Redis list long, Cloudqueue extreme).
בריכות חימום/חימום: מקרים שהועלו מראש כדי למנוע התחלה קרה.
גישת Load-as-Code: מדיניות Autoscale/limit/timeout/regray מבוססות ומבוססות.

8) תורים, תרמיל גב ובקרת זנב

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

9) DB, מטמונים ואחסון

DB: מגבלת חיבור, רישום/FSync, אינדקסים, תוכנית שאילתה, העתק לג, מקשים חמים/טבלאות, מקסימום TPS לעסקאות.
קשי: יחס להיט אחרי קטע, ”סערה של פספוסים” במהלך שחרור/נכות, הפצת מפתח.
אחסון: IOPS/breadput, עיכובים, דחיסה, TTL, ניקוי חבורות/תמונות ישנות.
תכנית הגירה: הרחיבו את action action is ללא מנעולי עצירה.

10) אירוע זורם ואט "ל

קפקא/אוטובוס: גיבוש צד, פיגור, ISR, קומפוזיציה, מגבלות יצרן/צרכן.

ETL/חבורות: להתחיל חלונות, תקציבי זמן ריצה, מצערת I/O

אידמפוטנטיות ובדיוק-פעם-כמו עבור זרימה קריטית (תשלומים/מאזן).

11) רשת והיקף

L4/L7 מאזנים: מגבלות חיבור, צבר סין, פריקת TLS, שימוש חוזר.
CDN/Edge: רוחב פס, מדיניות מטמון להפחתת עומס המוצא.
גבולות רשת: pps/mbps ב- VPC/subnet, egress-cost (FinOps).

12) אזור מרובה, ד "ר ותחומי שיפוט

אסטרטגיות: פעיל-פעיל (GSLB/Anycast), פעיל-פסיבי (חם/חם/קר DR).
N + 1 לפי אזור: קיומו של אובדן AZ/אזור תוך שמירה על זרמי ליבת SLO.
לוקליזציה משפטית: חלוקה של תנועה/נתונים על ידי מדינה, גבולות שונים ו-SLOs לספקים.
בדיקות ד "ר: ימי משחק רגילים עם העברת עומס אמיתי.

13) ספקים חיצוניים: מכסות ומסלולים

תשלומים/KYC/אנטי הונאה/דואר/SMS: TPS, מכסות פרץ, מגבלות יומיות.
רב ספק: ניתוב על ידי latency/הצלחה, SLO לכל ספק, אוטומטי-feiler.
חוזי SLA: e2e-SLO ציות, ערוצי הסלמה, סטטוסים באינטרנט.

14) פינוסים: עלות ויעילות

TCO: חישוב + אחסון + יציאת רשת + רישיונות/ספקים + חובה.
כלכלת יחידה: עלות 1 אלף בקשות/1 העברות הפקדה/1 KYC.
אופטימיזציה: הגדרה נכונה, הנחות ספוט/קידומת, היטראט מטמון, רישום/עקבות דדופ, רמות אחסון קרות.
העברה בזמן: קבוצות לא קריטיות בחלונות ”לילה” ובאזורים זולים.

15) לוחות מחוונים ודיווח (סט מינימלי)

• עומס נוכחי נגד תפוקה יציבה על פני קישורים.
• ראש על ידי שירות ואזור; תחזית 24/72 שעות.
• FinOps KPI: בקשות $1 $, $/הפקדה.

• צווארי בקבוק עליונים (p99, רוויה, פיגור), שולי DR.

• ספק הצלחה/איחור והגבלות; נתח של תנועה על נתיבים.

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

16) תהליכים ותפקידים

RACI: פלטפורמה (infra/clusters/balancers), מסד נתונים/נתונים (index), פקודות שירות (פרופיל/מטמון), SRE (SLO, התראות), Sec/Complices (קריפטו/לוגים), Finance (תקציב).
קצב: סקירת קיבולת שבועית (מפת דרכים, תחזית, סיכונים), דו "חות FinOps-Reports חודשיים, מבחני DR רבעוניים.
שינויי ניהול: מסעות פרסום ראשיים/משחררים שער קיבולת (רשימה להלן).

17) קיבולת שער

[ ] תחזית עומס שיא ו ”+ x% זנב חירום”.

[ ] ראש זמין לזרמי ליבה (תשלומים/ACC/Login).

[ ] המכסות אושרו לספקים; נתיבים חלופיים פעילים.

[ ] מסף HPA/KEDA ובריכת חימום מוגדרים.

[ ] תורים/גבולות והשפלה שנבדקו (ספרי משחקים מוכנים).

[ ] מניות הקנריים והחילוץ האוטומטי הופעלו.

[ ] לוחות מחוונים/התראות (שרפה, רוויה, p99) שנבדקו.

[ ] ד "ר תוכנית וקשרי הסלמה רלוונטיים.

18) אנטי דפוסים

”מעבד <70% - הכל בסדר”: התעלמות מגבולות התלות (קשרי DB, IOPS, תורים).
”קופסה שחורה” מרכזית ללא מדדים לכל קישור - זה בלתי אפשרי להבין איפה הגבול.
חוסר באסטרטגיה של מטמון - שחרור מחטיא את המקור.
המגש המוגבל ללא תקציבים הוא סערה של בקשות.
”ספק תשלום אחד” הוא נקודת כישלון בשיאה.
התעלמות ממאגרים חמים היא התחלה קרה כגורם לתקריות.
אין בדיקות תקופתיות ד "ר - התכנית לא עובדת בעת הצורך.

19) הערכות עלות מיני (דוגמה)

שירות X: יציב 350 RPS לפוד (VCPU = 1, RAM = 2 GiB). המטרה היא 5,000 RPS, חדר ראש 25%.
דרוש כוח = 5000/0. 75 = 6667 RPS '.
Podov = 'ceil (6667/350) = 20'. פלוס בריכה חמה 15% * 3 תרמילים נוספים.
DB: 12k TPS מוגבל, 9k TPS הנוכחי אשראי, 10 תחזית שיא. 5K TPS = מניה 1. 5k (14%). דורש אינדקסים/חדירה/העתקים או מזומנים כדי להפחית ל-8. חמש אלפיות.
ספקית A (KYC): מכסת 120 RPS, שיא 95 RPS, קמפיין + 40% * 133 RPS> מכסה 70% A/30% B.

20) תבנית יישום קיבולת

1. תאר את השביל e2e וצווארי הבקבוק.
2. הזן את המז "פ ומדוד את התפוקה הממושכת של כל שכבה.
3. הגדרות רוויה ומדדים p99 על כל הקישורים.
4. צור לוח שנה של אירוע/קמפיין/שחרור.
5. לבנות תחזית קוהורטה ומה-אם תרחישים.
6. סיכת ראש לכל חוט ולכל אזור (מחייב לתקציב שגיאה).
7. הגדר HPA/VPA/KEDA + בריכות חימום, הגבלות/מגשים/תורים.
8. בדוק מכסות ספק, אפשר רב נתיבים.
9. לאסוף לוחות מחוונים וסקירת קצב שבועית.
10. רבעון - תרגילי ד "ר ושינוי מודל.

21) השורה התחתונה

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