קנה מידה אוטומטי של משאבים לפי עומס

תארו לעצמכם: אתר מסחר אלקטרוני בערב שישי תחת עומס — CPU ב-90%, זמן התגובה עולה, ואי אפשר להוסיף שרתים ידנית בזמן. או ההפך: בימי חול, שרתים בטלים בזמן שאתם משלמים על 80% קיבולת שאינה בשימוש. קנה מידה אוטומטי פותר את שתי הבעיות. הקמנו קנה מידה אופקי ל-20+ פרויקטים — מסטארטאפים ועד ארגונים. להלן — קוד אמיתי, קונפיגורציות וטעויות נפוצות.

בעיות שאנו פותרים

הוצאות יתר על משאבים בזמני שקט

ניצול ה-CPU הממוצע של שרתי אינטרנט הוא 15-20%. החזקת קיבולת לשיא משמעותה תשלום על 80% כוח שאינו בשימוש. קנה מידה אוטומטי שומר על מספר מינימלי של מופעים ומוסיף חדשים ככל שהעומס גדל. לדוגמה, אתר מסחר אלקטרוני עם עומס שיא של 20k RPS מפעיל בדרך כלל 10 שרתים, אף שעומס ממוצע הוא 2k RPS. קנה מידה אוטומטי מאפשר להפעיל 2 שרתים ולהוסיף לפי הצורך. לאופטימיזציה של עלויות תשתית, החיסכון מגיע ל-30-40% מהתקציב. עבור לקוח אחד (מסחר אלקטרוני עם שיא של 20k RPS), היישום קיצץ הוצאות חודשיות ב-$4,500. חיסכון בעלויות: $4,500 לחודש.

זמן השבתה בזמן קפיצות פתאומיות

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

מורכבות הניהול הידני

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

איך אנחנו עושים את זה: מחסנית ומקרה בוחן

AWS Auto Scaling Group עם Target Tracking

אנו משתמשים ב-Terraform לתשתית כקוד. דוגמת קונפיגורציה:

resource "aws_autoscaling_group" "app" {
  name = "app-asg"
  min_size = 2
  max_size = 20
  desired_capacity = 3
  vpc_zone_identifier = var.private_subnet_ids
  launch_template {
    id = aws_launch_template.app.id
    version = "$Latest"
  }
  health_check_type = "ELB"
  health_check_grace_period = 60
  target_group_arns = [aws_lb_target_group.app.arn]
}

# Target Tracking: держать CPU на 60%
resource "aws_autoscaling_policy" "cpu_tracking" {
  name = "cpu-tracking"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type = "TargetTrackingScaling"
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 60.0
    scale_in_cooldown = 300
    scale_out_cooldown = 60
  }
}

ה-cooldown לקנה מידה החוצה (60 שניות) קצר יותר מזה של קנה מידה פנימה (300 שניות) — מגיבים במהירות לגידול, מסירים משאבים לאט.

Kubernetes HPA עם מדדים מותאמים אישית

Horizontal Pod Autoscaler בשילוב עם Prometheus Adapter מאפשר קנה מידה לפי מדדים מותאמים אישית:

---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "100"

המדד resource "aws_autoscaling_group" "app" { name = "app-asg" min_size = 2 max_size = 20 desired_capacity = 3 vpc_zone_identifier = var.private_subnet_ids launch_template { id = aws_launch_template.app.id version = "$Latest" } health_check_type = "ELB" health_check_grace_period = 60 target_group_arns = [aws_lb_target_group.app.arn] } # Target Tracking: держать CPU на 60% resource "aws_autoscaling_policy" "cpu_tracking" { name = "cpu-tracking" autoscaling_group_name = aws_autoscaling_group.app.name policy_type = "TargetTrackingScaling" target_tracking_configuration { predefined_metric_specification { predefined_metric_type = "ASGAverageCPUUtilization" } target_value = 60.0 scale_in_cooldown = 300 scale_out_cooldown = 60 } } מגיע מ-Prometheus דרך kube-state-metrics ו-Prometheus Adapter.

KEDA: קנה מידה לפי מקורות חיצוניים

KEDA (Kubernetes Event-Driven Autoscaling) מבצע קנה מידה של פודים לפי אורך תור מ-RabbitMQ, Kafka, SQS:

---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: queue-processor
spec:
  scaleTargetRef:
    name: worker-deployment
  minReplicaCount: 1
  maxReplicaCount: 30
  triggers:
    - type: rabbitmq
      metadata:
        host: amqp://rabbitmq:5672/
        queueName: tasks
        queueLength: "50"
---

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

קנה מידה חיזוי

AWS Predictive Scaling חוזה עומס על סמך נתונים היסטוריים (מינימום 14 ימים) ומוסיף משאבים באופן יזום:

resource "aws_autoscaling_policy" "predictive" {
  name = "predictive"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type = "PredictiveScaling"

  predictive_scaling_configuration {
    mode = "ForecastAndScale"
    scheduling_buffer_time = 300
    max_capacity_breach_behavior = "IncreaseMaxCapacity"

    metric_specification {
      target_value = 60

      predefined_scaling_metric_specification {
        predefined_metric_type = "ASGAverageCPUUtilization"
      }

      predefined_load_metric_specification {
        predefined_metric_type = "ASGTotalNetworkIn"
      }
    }
  }
}

השוואת שיטות קנה מידה

איך לבחור את המדד הנכון?

המדד הוא המפתח לקנה מידה אפקטיבי. CPU מפגר, קצב בקשות דורש קו בסיס, P95 הוא המדויק ביותר אך מורכב. בפועל אנו משתמשים בשילוב של CPU + קצב בקשות. לעובדים אסינכרוניים — עומק תור. לפי תיעוד AWS Auto Scaling (Amazon EC2 Auto Scaling) תומך במספר מדדים במדיניות אחת. עלויות התשתית יורדות ב-35% עם מדדים שנבחרו כראוי.

מה אם קנה המידה לא מופעל בזמן?

בדקו cooldown (קנה מידה החוצה מהיר יותר מקנה מידה פנימה), תקופת חסד לבדיקת בריאות. לפעמים המדד לא התעדכן. אנו ממליצים על בדיקת עומס עם k6: apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: app minReplicas: 2 maxReplicas: 50 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: "100" .

תהליך

1. אנליטיקה: ניתוח פרופיל עומס, נתונים היסטוריים, בחירת מדדים.
2. עיצוב: קביעת סוג קנה המידה, כלים (AWS ASG, K8s HPA, KEDA).
3. יישום: כתיבת IaC (Terraform/Pulumi), הגדרת ניטור (CloudWatch, Prometheus).
4. בדיקות: בדיקות עומס, אימות זמן תגובה וזמן השבתה.
5. פריסה: פריסה לייצור, התראות (SNS, PagerDuty).
6. תמיכה: ניטור אפקטיביות, התאמת ספים.

מה כלול

• תיעוד ארכיטקטוני
• קוד תשתית (Terraform/Helm)
• ניטור והתראות
• מקרה בדיקת עומס
• הדרכת צוות (מפגש אחד)

לוחות זמנים ליישום

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

הניסיון שלנו

מעל 5 שנים בתשתיות עומס גבוה. יישמנו קנה מידה אופקי ל-20+ פרויקטים — מסטארטאפים ועד ארגונים (מסחר אלקטרוני, פינטק). אנו משתמשים בפתרונות מוכחים עם ערבויות SLA. רוצים להקים קנה מידה אוטומטי? קבלו ייעוץ — נעריך את הפרויקט שלכם ונציע את הפתרון האופטימלי.