הגדרת קנה מידה אוטומטי לשרתי אפליקציות מובייל

הגדרת קנה מידה אוטומטי לשרתי אפליקציות מובייל

אנחנו יודעים איך נראית שגיאת 503 על המסך של המשתמש אחרי פרץ של התראות push. כשנכנסות 3000 בקשות בשנייה לפוד בודד, השרת קורס והדירוג בחנות האפליקציות צונח. קנה מידה אוטומטי פותר את זה, אבל הגדרתו דורשת תובנה ארכיטקטונית. בניסיון שלנו, מעל 50 פרויקטים ראו הפחתה של 30–50% בעלויות התשתית בזכות כוונון נכון של HPA ו-KEDA. מאמר זה מפרק כיצד להשיג אפס זמן השבתה ל-API נייד עם SLA מובטחים.

איך לבחור בין HPA ל-KEDA?

עבור API נייד עם התראות push, KEDA מגיב לשינויי עומס פי 2–3 מהר יותר מ-HPA לפי CPU, כי קנה המידה מתחיל לפני שהתנועה מגיעה.

סוגי קנה מידה אוטומטי ומתי ליישם אותם

Horizontal Pod Autoscaler ב-Kubernetes מוסיף פודים תחת עומס ומסיר אותם כשהעומס יורד. המדד הבסיסי הוא ניצול CPU, אבל עבור API נייד, מדדים טובים יותר הם זמן תגובה p99, עומק תור הבקשות, או מדדי Prometheus מותאמים אישית שנחשפים דרך Custom Metrics API.

Vertical Pod Autoscaler משנה את הבקשות/מגבלות של פוד. שימושי עבור שירותי JVM שבהם הזיכרון גדל ככל שה-heap מתחמם. עם זאת, VPA דורש הפעלה מחדש של הפוד בעת שינוי משאבים, ולכן אינו מתאים לשירותים עם מצב (stateful). השתמשו ב-VPA במצב המלצה תחילה כדי לאסוף נתונים.

Cluster Autoscaler מוסיף/מסיר צמתי Kubernetes בענן (AWS EC2, GCP GKE, Azure AKS). הוא עובד לצד HPA: HPA רוצה 5 פודים אבל אין מקום — Cluster Autoscaler מוסיף צומת.

KEDA מבצע קנה מידה לפי מדדים חיצוניים: אורך תור RabbitMQ, פיגור Kafka, מספר הודעות ב-Redis Streams. עבור אפליקציה ניידת עם תור התראות push: עובדים מבצעים קנה מידה לפי מספר המשימות בתור, לא לפי CPU.

הגדרת HPA עבור API נייד

הבעיה עם קנה מידה סטנדרטי לפי CPU: במהלך קפיצת בקשות, ה-CPU עולה תחילה, ואז HPA מחליט להוסיף פוד (15–30 שניות), הפוד מתחיל (עוד 10–30 שניות), ובדיקות readiness עוברות. סה"כ: 30–60 שניות לפני שהפוד החדש מתחיל לקבל תנועה. עד אז, חלק מלקוחות המובייל כבר קיבלו 503.

פתרונות:

• קנה מידה חיזוי — קנה מידה החוצה לפני השיא הצפוי (שליחת push → מיד קנה מידה החוצה)
• ScaleUp מהיר יותר, ScaleDown איטי יותר — requests/limits (קנה מידה מיידי למעלה), scaleUp.stabilizationWindowSeconds: 0 (המתן 5 דקות לפני קנה מידה למטה כדי למנוע תנודתיות)
• MinReplicas: 2 — לעולם אל תרדו לפוד אחד כדי למנוע זמן השבתה במהלך עדכונים מתגלגלים

---
spec:
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Pods
          value: 4
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300

הגדרת HPA שלב אחר שלב:

1. הגדירו את המדד (CPU, זיכרון, או מותאם אישית דרך Prometheus Adapter).
2. קבעו ניצול מטרה (50–70% עבור CPU).
3. הגדירו התנהגות עבור scaleUp (מהיר) ו-scaleDown (איטי).
4. קבעו minReplicas >= 2.
5. בדקו עם בדיקות עומס (לדוגמה, k6 או Locust).
6. נטרו זמן תגובה ושגיאות באמצעות התראות מבוססות SLO.

למה קנה מידה לפי CPU לא מתאים ל-API נייד?

ה-CPU מפגר אחרי הבקשות — זו עובדה. בזמן ש-HPA מזהה את השיא ומוסיף פוד, חלק מהלקוחות כבר רואים 503. עבור API נייד, עדיף להשתמש במדדי זמן תגובה p99 או עומק תור הבקשות. במקרה שלנו עם אפליקציית חדשות iOS, פתרנו את זה עם KEDA ותור SQS — קנה המידה התחיל לפני שהתנועה הגיעה, ושגיאות 503 נעלמו.

בעיית התחלה קרה (Cold Start) לתנועה ניידת

Go ו-Node.js מתחילים תוך 1–3 שניות — מקובל. יישומי JVM (Spring Boot) לוקחים 10–20 שניות. התחלה קרה של Lambda (serverless) לוקחת 500ms–3 שניות תלוי בסביבת הריצה ובגודל החבילה.

עבור JVM: שמרו על לפחות 2 פודים חמים בכל עת. GraalVM Native Image — מתחיל תוך 0.1–0.3 שניות, אבל דורש הגדרת reflection. Spring Boot 3 + GraalVM Native — שילוב מוכן לייצור. מופעי JVM סטנדרטיים עולים כ-$200 לחודש, GraalVM כ-$300, Provisioned Concurrency כ-$500.

עבור serverless (AWS Lambda, Google Cloud Functions): Provisioned Concurrency שומר על N מופעים חמים. זה יקר יותר, אבל התחלות קרות נעלמות עבור אותם מופעים.

מקרה: אפליקציית חדשות iOS. אחרי push מערכתי, 40,000 פתיחות במקביל תוך 2 דקות. פוד אחד על 2 vCPU טיפל ב-400 בקשות בשנייה. HPA הוגדר ל-60% CPU — עד שנוסף פוד, שיא העומס כבר חלף. פתרון: KEDA עם מדד CloudWatch (עומק תור SQS) — בשליחת push, נוספו אוטומטית 8 פודים לפני שהתנועה הגיעה. אפס שגיאות 503 בשלושת השידורים הבאים.

מה כלול בהגדרה סוהר

• ביקורת ארכיטקטורה נוכחית ובדיקות עומס.
• הגדרת HPA, VPA, Cluster Autoscaler או KEDA.
• הגדרת מדדים מותאמים אישית (Prometheus, CloudWatch, Datadog).
• אופטימיזציה של התחלה קרה (GraalVM, Provisioned Concurrency).
• תיעוד של תוכניות קנה המידה.
• ניטור והתראות מבוססות SLO.
• מפגש הדרכה אחד לצוות.
• שבועיים של תמיכה לאחר המסירה.

הגדרה סוהר זמינה מ-$2,500, עם לוחות זמנים מ-2 עד 14 ימים תלוי במורכבות. פרויקט ממוצע חוסך $1,200 לחודש בעלויות ענן לאחר הגדרת קנה המידה האוטומטי.

תיעוד רשמי של Kubernetes על HPA

עם הגדרה נכונה באמצעות מדיניות scale של HPA ומצב ההמלצה של VPA, החיסכון במשאבי ענן מגיע ל-40%, ועלויות התפעול יורדות ב-$500–2000 לחודש עבור פרויקט ממוצע.