הגדרת קנה מידה אוטומטי לשרתים עבור יישומי אינטרנט

הערה: כאשר שירות האינטרנט שלך נתקל לפתע בעומס שיא—לדוגמה, לאחר קמפיין דוא"ל מוצלח או קמפיין פרסומי—השרתים עלולים לקרוס, ומשתמשים יעברו למתחרים. אתה מוסיף קיבולת ידנית, אבל זה איטי ויקר. קנה מידה אוטומטי (Autoscaling) פותר זאת, אך תצורה שגויה מובילה לתנודתיות (thrashing) ולחריגות עלויות. צוות המהנדסים שלנו, עם ניסיון של למעלה מעשור בתשתיות, סייע ליותר מ-50 פרויקטים ליישם קנה מידה אופקי, תוך חיסכון של 30–40% במשאבי ענן. עבור פרויקט טיפוסי עם חשבון ענן של $3,000 לחודש, המשמעות היא חיסכון חודשי של $900–$1,200. אנו מבטיחים שאתה משלם רק על משאבים שבאמת נעשה בהם שימוש, ומשתמשים לא יבחינו בעליות. אנו מציעים התקנת קנה מידה אוטומטי סוהר תוך 5 ימים. קבל ייעוץ—נעריך את הפרויקט שלך ונציע את הארכיטקטורה האופטימלית.

שירות הקנה מידה האוטומטי שלנו משתמש ב-AWS Auto Scaling וב-Kubernetes HPA לניהול מדדי CPU ומניעת תנודתיות, תוך אופטימיזציה של משאבי ענן ותשתית שרתים. עם התצורה שלנו, אירועי קנה מידה מתרחשים תוך 30 שניות מחריגת סף, ולקוחות בדרך כלל רואים חיסכון שנתי של $10,000–$20,000. הפתרון שלנו לקנה מידה אוטומטי מפחית עלויות תשתית ב-40% בהשוואה להקצאה סטטית.

קנה מידה מבוסס CPU בלבד אינו מספיק

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

בחירת מדדים לקנה מידה אוטומטי

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

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

תצורה בפלטפורמות ענן

AWS Auto Scaling Group

התרחיש הנפוץ ביותר—EC2 ASG עם Application Load Balancer. בתצורה אחת אנו משלבים Launch Template, ASG, ומדיניות target tracking:

# Terraform: Launch Template + ASG + Target Tracking Policies
resource "aws_launch_template" "app" {
  name_prefix = "myapp-"
  image_id = data.aws_ami.ubuntu.id
  instance_type = "t3.medium"
  user_data = base64encode(<<-EOF
    #!/bin/bash
    cd /var/www/myapp
    git pull origin main
    systemctl restart php8.3-fpm
    systemctl reload nginx
  EOF
  )
  network_interfaces {
    associate_public_ip_address = false
    security_groups = [aws_security_group.app.id]
  }
  iam_instance_profile {
    name = aws_iam_instance_profile.app.name
  }
  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group" "app" {
  name = "myapp-asg"
  vpc_zone_identifier = aws_subnet.private[*].id
  target_group_arns = [aws_lb_target_group.app.arn]
  health_check_type = "ELB"
  health_check_grace_period = 300
  min_size = 2
  max_size = 20
  desired_capacity = 2
  launch_template {
    id = aws_launch_template.app.id
    version = "$Latest"
  }
  instance_refresh {
    strategy = "Rolling"
    preferences {
      min_healthy_percentage = 50
    }
  }
  tag {
    key = "Name"
    value = "myapp-app"
    propagate_at_launch = true
  }
}

# Target Tracking Policy: CPU
resource "aws_autoscaling_policy" "cpu" {
  name = "myapp-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 = 65.0
    scale_in_cooldown = 300
    scale_out_cooldown = 60
  }
}

# Target Tracking Policy: ALB Request Count per Target
resource "aws_autoscaling_policy" "rps" {
  name = "myapp-rps-tracking"
  autoscaling_group_name = aws_autoscaling_group.app.name
  policy_type = "TargetTrackingScaling"
  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ALBRequestCountPerTarget"
      resource_label = "${aws_lb.main.arn_suffix}/${aws_lb_target_group.app.arn_suffix}"
    }
    target_value = 1000.0
  }
}

ECS Fargate Auto Scaling

עבור יישומים מבוססי קונטיינרים, ECS Fargate פשוט יותר—ללא EC2, רק משימות. אנו מגדירים את המשאב היעד ומדיניות עבור CPU ועומק תור SQS:

resource "aws_appautoscaling_target" "ecs" {
  max_capacity = 50
  min_capacity = 2
  resource_id = "service/${aws_ecs_cluster.main.name}/${aws_ecs_service.app.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace = "ecs"
}

resource "aws_appautoscaling_policy" "ecs_cpu" {
  name = "myapp-ecs-cpu"
  policy_type = "TargetTrackingScaling"
  resource_id = aws_appautoscaling_target.ecs.resource_id
  scalable_dimension = aws_appautoscaling_target.ecs.scalable_dimension
  service_namespace = aws_appautoscaling_target.ecs.service_namespace
  target_tracking_scaling_policy_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ECSServiceAverageCPUUtilization"
    }
    target_value = 60.0
    scale_in_cooldown = 300
    scale_out_cooldown = 30
  }
}

# Scale by SQS queue depth (worker service)
resource "aws_appautoscaling_policy" "ecs_sqs" {
  name = "myapp-worker-sqs"
  policy_type = "TargetTrackingScaling"
  resource_id = aws_appautoscaling_target.worker.resource_id
  scalable_dimension = aws_appautoscaling_target.worker.scalable_dimension
  service_namespace = aws_appautoscaling_target.worker.service_namespace
  target_tracking_scaling_policy_configuration {
    customized_metric_specification {
      metric_name = "ApproximateNumberOfMessagesNotVisible"
      namespace = "AWS/SQS"
      statistic = "Sum"
      dimensions {
        name = "QueueName"
        value = aws_sqs_queue.jobs.name
      }
    }
    target_value = 100.0
  }
}

Kubernetes HPA ו-KEDA

Horizontal Pod Autoscaler עובד עם CPU וזיכרון כברירת מחדל. KEDA מוסיף מדדים חיצוניים (SQS, RabbitMQ, Kafka).

דוגמה ל-HPA עם CPU + זיכרון, ייצוב והתנהגות:

---
# HPA по CPU + Memory
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  namespace: myapp
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-web
  minReplicas: 2
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 75
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Pods
          value: 4
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 25
          periodSeconds: 60

למידע נוסף במסמכים הרשמיים HorizontalPodAutoscaler. KEDA ScaledObject עבור RabbitMQ:

# KEDA ScaledObject — RabbitMQ queue apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: myapp-worker-scaler namespace: myapp spec: scaleTargetRef: name: myapp-worker minReplicaCount: 1 maxReplicaCount: 30 pollingInterval: 10 cooldownPeriod: 60 triggers: - type: rabbitmq metadata: host: amqp://rabbitmq.myapp.svc.cluster.local queueName: email-queue mode: QueueLength value: "50" 

כיצד ליישם כיבוי חלק (Graceful Shutdown) בקנה מידה אוטומטי?

בעת הקטנת קנה מידה, מופע מקבל אות סיום. היישום חייב לטפל בבקשות נוכחיות. דוגמה עבור Node.js Express:

// Node.js Express
const server = app.listen(3000);
process.on('SIGTERM', () => {
  console.log('SIGTERM received, shutting down gracefully');
  server.close(() => {
    console.log('HTTP server closed');
    process.exit(0);
  });
  setTimeout(() => {
    console.error('Forced shutdown');
    process.exit(1);
  }, 30000);
});

בנוסף, אנו מגדירים lifecycle hooks ב-AWS לביצוע פקודות לפני סיום מופע. ראה מסמכי AWS על Lifecycle Hooks לפרטים.

מהן בעיות נפוצות בקנה מידה אוטומטי וכיצד לפתור אותן?

בעת יישום קנה מידה אוטומטי, צוותים נתקלים לעתים קרובות בתנודתיות—הוספה והסרה תכופה של מופעים עקב תקופות צינון קצרות מדי. פתרון: הגדל את scale_in_cooldown ל-300–600 שניות והשתמש ב-stabilizationWindowSeconds ב-HPA. בעיה נוספת היא התנעה איטית של יישום: מופע חדש נוצר, אבל תנועה מגיעה לפני שהוא מוכן. תקופת חסד לבדיקת בריאות, readiness probe, ו-Warm Pool עוזרים. כמו כן, הקטנת קנה מידה יקרה מתרחשת כאשר מופע עם משימות רקע לא גמורות מוסר. lifecycle hook עם ריקון תור לפני CONTINUE פותר זאת. לבסוף, בחירת מדדים שגויה—לדוגמה, CPU ב-20% אבל היישום איטי עקב המתנת I/O. במקרים כאלה, השתמש במדדים מותאמים אישית כמו p95 latency דרך CloudWatch או Prometheus.

התקנת קנה מידה אוטומטי שלב אחר שלב ב-AWS

1. צור Launch Template עם AMI, סוג מופע, ו-user-data לפריסת היישום.
2. הגדר Auto Scaling Group: ציין VPC, רשת משנה, target group עבור ALB, הגדר מינימום, מקסימום ו-desired.
3. הוסף מדיניות Target Tracking עבור CPU ו-RPS, הגדר תקופות צינון.
4. הגדר בדיקות בריאות: בדיקת בריאות ELB, תקופת חסד (הגדר ל-300 שניות כדי למנוע סיום מוקדם).
5. אפשר Instance Refresh לעדכונים מתגלגלים.
6. ודא כיבוי חלק: lifecycle hook + ריקון.

היקף העבודה להתקנת קנה מידה אוטומטי

• ניתוח הארכיטקטורה הנוכחית ופרופיל העומס.
• עיצוב מדיניות קנה מידה (CPU, RPS, תור).
• הגדרת AWS Auto Scaling Group, ECS Service Auto Scaling, או Kubernetes HPA/KEDA.
• הגדרת בדיקות בריאות וכיבוי חלק.
• הגדרת ניטור (CloudWatch, Grafana) והתראות.
• תיעוד ארכיטקטורה והנחיות לצוות.
• הדרכת צוות (1–2 מפגשים).
• תמיכה של 30 יום לאחר הפריסה.

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

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