הגדרת מופעי Spot/Preemptible עבור עבודות אצווה

ללא Spot Instances, עיבוד אצווה בענן עולה פי 3–5 יותר. לקוחות לעיתים קרובות משלמים יתר על המידה עבור משאבים לפי דרישה שיושבים בטלים בין משימות. כמהנדסים, אנו משתמשים ב-Spot ו-Preemptible Instances כבר למעלה מ-5 שנים כדי להפחית עלויות ב-60–80% מבלי לפגוע באמינות. להלן שיטות ספציפיות, תצורות ופתרונות מוכחים שנבדקו על עשרות פרויקטים.

אילו משימות מבוצעות ביעילות הרבה ביותר על Spot Instances?

Spot Instances אידיאליות למשימות אצווה חסרות מצב: עובדי CI/CD (כל build מבודד), עיבוד תמונות ווידאו (transcoding, resizing), אימון ML עם גישות מבוססות checkpoint, צינורות parsing ו-ETL, rendering, סריקות אנטי-וירוס, שאילתות אנליטיות. הן אינן מתאימות למאגרי נתונים עם מצב (סיכון לאובדן נתונים), שרתי אינטרנט ללא החלפה מהירה, או שירותים עם SLA מחמיר ללא אסטרטגיית DR.

כיצד Spot Fleet מפחית את הסבירות להפרעות?

המפתח ליציבות הוא Spot Fleet עם מספר סוגי instances. אם m5.xlarge אינו זמין, ה-Fleet בוחר ב-m5a.xlarge או c4.xlarge. אנו משתמשים באסטרטגיית capacityOptimized — היא בוחרת pools עם הקיבולת הפנויה הגדולה ביותר, ומפחיתה את הסבירות להפרעות. דוגמת תצורה:

{ "SpotFleetRequestConfig": {
    "AllocationStrategy": "capacityOptimized",
    "TargetCapacity": 10,
    "LaunchTemplateConfigs": [
      {
        "LaunchTemplateSpecification": {
          "LaunchTemplateId": "lt-xxx",
          "Version": "1"
        },
        "Overrides": [
          { "InstanceType": "m5.xlarge", "WeightedCapacity": 1 },
          { "InstanceType": "m5a.xlarge", "WeightedCapacity": 1 },
          { "InstanceType": "m4.xlarge", "WeightedCapacity": 1 },
          { "InstanceType": "c5.xlarge", "WeightedCapacity": 1 }
        ]
      }
    ]
  }
}

מדוע checkpointing הוא קריטי?

Spot Instances יכולות להיות מופסקות בכל רגע. ללא checkpointing, אובדן התקדמות הופך את חיסכון העלויות לחסר משמעות. יישום מנגנון שמירת מצב מאפשר למשימות להתחיל מחדש מהנקודה האחרונה שנשמרה, וממזער הפסדים. בפועל, זה מניב עד 95% זמן ריצה אפקטיבי גם תחת הפרעות תכופות.

כיצד לטפל כראוי ב-Spot Interruption Notice?

AWS שולח אירוע metadata 2 דקות מראש (פרטים נוספים ב-תיעוד AWS). היישום צריך לבדוק את ה-endpoint, ועם קבלת אות הפרעה, לשמור checkpoint. הקוד שלהלן מציג יישום Python עם יציאה מסודרת:

import requests
import signal
import sys

def check_spot_interruption():
    """Вызывать каждые 5 секунд из воркера"""
    try:
        response = requests.get(
            'http://169.254.169.254/latest/meta-data/spot/interruption-notice',
            timeout=1
        )
        if response.status_code == 200:
            return True  # Прерывание ожидается
    except requests.exceptions.RequestException:
        pass
    return False

class BatchWorker:
    def process_task(self, task):
        # Checkpoint каждые N элементов
        for i, item in enumerate(task.items):
            if i % 100 == 0 and check_spot_interruption():
                self.save_checkpoint(task.id, i)
                sys.exit(0)  # Graceful exit, задача будет перезапущена
            self.process_item(item)
        task.mark_complete()

שלבי טיפול בהפרעות:

1. בדוק את ה-metadata endpoint כל 5 שניות.
2. עם קבלת האות, שמור checkpoint (לדוגמה, ב-S3 או Redis).
3. יציאה מסודרת עם קוד 0 כך שה-queue (SQS) לא יסמן את המשימה כנכשלה.

ניתן גם להשתמש ב-AWS EventBridge לאוטומציה: אירוע → Lambda → שמירת checkpoint, הסרת ה-instance מה-pool, החזרת המשימה ל-queue.

מה זה Karpenter וכיצד הוא מנהל צמתי Spot?

Karpenter (AWS) בוחר אוטומטית את סוג ה-instance (כולל Spot) ומטפל בהפרעות: עם קבלת הודעה, הוא מבצע cordon ו-drain לצומת, ומתזמן מחדש את ה-pods. דוגמת Provisioner:

---
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: batch-workers
spec:
  requirements:
    - key: "karpenter.sh/capacity-type"
      operator: In
      values: ["spot", "on-demand"]
    - key: "node.kubernetes.io/instance-type"
      operator: In
      values: ["m5.xlarge", "m5a.xlarge", "m4.xlarge", "c5.xlarge"]
  taints:
    - key: batch
      effect: NoSchedule
  consolidation:
    enabled: true
---

השוואת אסטרטגיות: Karpenter בהשוואה לניהול ידני של Spot Fleet מפחית את זמן התגובה להפרעות בחצי בזכות cordon ו-drain אוטומטיים. Spot Fleet פשוט אך דורש ניהול ידני של תבניות. Karpenter מציע קנה מידה דינמי והתאוששות אוטומטית אך מורכב יותר להגדרה. שניהם מספקים חיסכון של 60–80%.

GCP Preemptible / Spot VMs: ניואנסים

GCP Preemptible: אורך חיים מקסימלי של 24 שעות, הודעה של 30 שניות. Spot VMs — ללא מגבלת 24 שעות, רק לפי זמינות. יצירה באמצעות gcloud:

gcloud compute instances create batch-worker \
  --machine-type=n2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=STOP \
  --zone=us-central1-a

גם כאן מיושם checkpointing, אך עם הודעה קצרה יותר (30 שניות). היישום דומה ל-AWS, אך עם בדיקת שרת ה-metadata של GCP.

מה כלול בהתקנה סוהר?

• ביקורת עומסי עבודה נוכחיים ובחירת אלו המתאימים
• תכנון Spot Fleet / Provisioner עם מספר סוגי instances
• יישום checkpointing וטיפול בהפרעות (קוד Python/Go/Java)
• אינטגרציה עם EventBridge, Lambda, queues (SQS, RabbitMQ)
• הגדרת ניטור (CloudWatch, Prometheus) והתראות
• תיעוד והדרכת צוות
• בדיקות עם סימולציית הפרעות
• תמיכה לאחר השקה למשך חודש

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

העלות מחושבת באופן אישי לפי הנפח והמורכבות שלך. בקש הערכה — פשוט כתוב לנו. אנו מבטיחים תמחור שקוף וקביעת היקף.

חיסכון אמיתי במספרים

החיסכון האופייני הוא 60–80% בהשוואה לפי דרישה. תקורה עבור הפרעות והפעלות מחדש היא 5–15% מהזמן. בפרויקט אימון ML אחד באמצעות p3.2xlarge, החיסכון הגיע ל-70%. הלקוחות שלנו מאשרים: יישום נכון של checkpointing מחזיר את ההשקעה תוך 1–2 חודשים. צור קשר כדי לחשב את החיסכון עבור עומס העבודה שלך. הזמן ביקורת על משימות האצווה שלך — המהנדסים שלנו עם ניסיון של 5+ שנים והסמכות AWS/GCP יעזרו לך להפחית את חשבון הענן שלך ללא אובדן ביצועים.