MicrocosmWorksInnovation und Architektur digitaler Kosmen
Über unsKontakt
MicrocosmWorksInnovieren und Gestalten digitaler Kosmen

Bereitstellung von IT-Lösungen, die zählen. Wir sind leidenschaftlich für Technologie, Sicherheit und helfen Unternehmen, durch zuverlässige, innovative IT-Infrastruktur zu wachsen.

[email protected]
+91 7011868196
New Delhi, India

AI Wachstumszentrum

AI HubStartup-InnovationUnternehmensbeschleuniger

Lösungen

Alle LösungenWellness- & Fitness-AppsAI Video PlattformAI Agent Entwicklung

Ressourcen

EinblickeBranchenleitfädenAnwendungsfall-BlaupausenArchitektur-MusterFallstudien

Unternehmen

Über unsKontaktUnsere Arbeit

Dienstleistungen

Digitale BeratungCloud-InfrastrukturSaaS-EntwicklungKI-EntwicklungVideotechnologie
ERP-EntwicklungZoho-AnpassungOdoo-EntwicklungSalesforce-IntegrationBenutzerdefinierte CRM-Entwicklung
QuickBooks-IntegrationIoT-LösungenBlockchain-Entwicklung
Cybersecurity-BeratungIT-Support - L3

© 2026 MicrocosmWorks. Alle Rechte vorbehalten.

DatenschutzrichtlinieNutzungsbedingungen
Zurück zu Architekturmustern
InfrastructureAdvanced

On-Off-Skalierungsarchitektur

Bezahlen Sie nicht für inaktive GPUs. Stellen Sie Rechenleistung just-in-time bereit, verarbeiten Sie die Workload und fahren Sie sie wieder herunter – wodurch Investitionsausgaben zu laufenden Kosten pro Auftrag werden.

June 18, 2026
|
2 topics covered
Diskutieren Sie diese Architektur
Infrastructure
Category
Advanced
Complexity
AI/ML, Media & Entertainment
Industries
2+
Technologies

Wann Sie das brauchen

Ihre Workload ist sprunghaft – Video-Encoding-Aufträge, die bei Uploads ansteigen, ML-Trainingsläufe, die 8 GPUs für 4 Stunden benötigen und dann nichts, Batch Inference-Jobs, die durch Geschäftsereignisse ausgelöst werden, oder Rendering-Pipelines, die über Nacht laufen. Sie sind entweder überversorgt (zahlen 80 % der Zeit für inaktive Ressourcen) oder unterversorgt (Jobs stehen während Spitzenzeiten stundenlang in der Warteschlange). Sie benötigen eine Architektur, die genau die Rechenleistung bereitstellt, die Sie benötigen, wenn Sie sie benötigen, und diese freigibt, wenn der Auftrag abgeschlossen ist – ohne die Kaltstartstrafe, die „scale to zero“ für GPU-Workloads unpraktisch macht.

Related Architecture Patterns

Explore more design patterns and system architectures

cloud-native-infrastructure.webp
Infrastructure

Cloud-native Infrastruktur

Infrastruktur, die wie Anwendungscode versioniert, getestet und bereitgestellt wird – denn Ihre Plattform ist nur so zuverlässig wie das, was ihr zugrunde liegt.

EnterpriseView
security-first-architecture.webp

Benötigen Sie Hilfe bei der Implementierung dieser Architektur?

Unsere Architekten können Ihnen helfen, Systeme mit diesem Muster für Ihre spezifischen Anforderungen zu entwerfen und zu erstellen.

Kontakt aufnehmen
on-off-scaling-architecture.webp

Musterübersicht

Die On-Off-Skalierungsarchitektur verwaltet Rechenressourcen durch Warm-/Kalt-Pooling, Job-Queue-gesteuerte Bereitstellung und automatisiertes Herunterfahren. Ein Warm Pool unterhält eine kleine Anzahl vorinitialisierter Instanzen, die sofort einsatzbereit sind. Ein Cold Pool stellt zusätzliche Kapazitäten aus Spot-/Preemptible-Instanzen bereit, wenn die Nachfrage den Warm Pool übersteigt. Ein Job Orchestrator leitet Aufträge an verfügbare Instanzen weiter, überwacht den Fortschritt, handhabt Wiederholungen bei Spot Eviction und löst eine Skalierung nach unten aus, wenn die Warteschlange leer ist. Das Muster ist besonders kritisch für GPU-Workloads, bei denen der Kaltstart (Container-Pull + Modell-Laden) 3-10 Minuten dauern kann.

Referenzarchitektur

Das System konzentriert sich auf eine Job Queue (SQS, Redis oder benutzerdefiniert), die eingehende Arbeitsanfragen puffert. Ein Scaling Controller überwacht die Warteschlangentiefe und stellt Instanzen zuerst aus dem Warm Pool und dann aus dem Cold Pool (Spot-Instanzen) bereit. Jede Worker Instance zieht Jobs aus der Warteschlange, führt die Workload aus (Encoding, Training, Inference), meldet den Abschluss und kehrt zum Pool zurück oder wird beendet. Ein Checkpoint Manager handhabt Spot Eviction, indem er den Zwischenzustand in S3 speichert, sodass Jobs auf einer anderen Instanz fortgesetzt werden können, ohne von vorne zu beginnen.

Kernkomponenten
  • Job Queue & Scheduler: Priorisierte Job Queue mit konfigurierbaren Parallelitätslimits pro Jobtyp. Unterstützt verzögerte Ausführung, Dead-Letter Queues für fehlgeschlagene Jobs und Prioritätsspuren (Express-Jobs erhalten Warm Pool-Instanzen, Standard-Jobs verwenden den Cold Pool). AWS SQS, BullMQ auf Redis oder Temporal für komplexe Workflows
  • Warm Pool Manager: Verwaltet N vorinitialisierte Instanzen mit in den GPU-Speicher geladenen Modellen, laufenden Containern und bestandenen Health Checks. Instanzen durchlaufen: idle → assigned → processing → idle. Die Poolgröße ist nach Tageszeit konfigurierbar (größer während der Geschäftszeiten, kleiner über Nacht) und basierend auf historischen Nachfragemustern anpassbar
  • Cold Pool Provisioner: Stellt zusätzliche Kapazität von Spot-Instanzen (AWS), Preemptible VMs (GCP) oder Serverless GPU-Anbietern (RunPod, Modal, Salad) bereit. Handhabt Spot-Unterbrechungsbenachrichtigungen durch Migration von Jobs zu verfügbaren Instanzen. Verwendet eine diversifizierte Instanztypstrategie (mehrere GPU-Typen, mehrere AZs), um die Spot-Verfügbarkeit zu maximieren
  • Checkpoint & Recovery: Für langlaufende Jobs (ML-Training, große Video-Encodierung) speichert die periodische Checkpointierung den Zwischenzustand in S3. Bei Spot Eviction wird der Job erneut in die Warteschlange gestellt und vom letzten Checkpoint aus fortgesetzt. Für kurze Jobs (< 10 Min.) übersteigen die Kosten der Checkpointierung die Kosten eines Neustarts – diese Jobs werden einfach von Grund auf neu versucht

Designentscheidungen & Kompromisse

Warm Pool Größe
Der Warm Pool ist ein Kompromiss zwischen Kosten (Zahlung für inaktive Instanzen) und Latenz (Kaltstartzeit für den ersten Job). MW dimensioniert Warm Pools basierend auf den Job-Ankunftsmustern: Wenn Jobs während der Geschäftszeiten kontinuierlich ankommen, deckt der Warm Pool den durchschnittlichen Durchsatz ab; der Cold Pool deckt Spitzen ab. Wenn Jobs in unvorhersehbaren Bursts ankommen, halten wir einen kleineren Warm Pool und akzeptieren eine Kaltstartlatenz für die ersten Burst-Jobs, während der Cold Pool bereitgestellt wird.
Spot Instances vs. Serverless GPU (RunPod/Modal)
Spot-Instanzen sind pro Stunde günstiger, erfordern aber die Verwaltung von Bereitstellung, Eviction-Handling und Instanz-Lebenszyklus. Serverless GPU-Anbieter (RunPod Serverless, Modal, Banana) übernehmen die Bereitstellung und bieten eine Abrechnung pro Sekunde, jedoch zu einem höheren Preis pro Rechensekunde. MW verwendet Spot-Instanzen für vorhersehbare, langlaufende Workloads (>30 Min.) und Serverless GPU für kurze, sprunghafte Jobs (<10 Min.), bei denen der Bereitstellungs-Overhead dominieren würde.
Aggressivität der Skalierung nach unten
Skalieren Sie zu schnell herunter, zahlen Sie Kaltstartstrafen, wenn der nächste Job ankommt. Skalieren Sie zu langsam herunter, zahlen Sie für inaktive Instanzen. MW implementiert eine „Cooldown mit Decay“-Strategie: Nachdem die Warteschlange leer ist, bleiben Instanzen für eine konfigurierbare Dauer warm (Standard: 10 Minuten). Wenn keine neuen Jobs ankommen, werden Instanzen progressiv heruntergefahren (50 % nach 10 Min., der Rest nach 30 Min.). Die Cooldown-Periode ist einstellbar und passt sich automatisch an die Statistiken der Ankunftszeiten an.
GPU-Modelllade-Optimierung
Bei der ML Inference ist der Kaltstart-Engpass oft das Laden des Modells (Herunterladen von S3 + Laden in den GPU-Speicher), nicht der Container-Start. MW optimiert dies durch: (a) Vorbacken von Modellen in Container-Images (für kleine Modelle), (b) Verwendung von gemeinsamem NVMe-Speicher über Instanzen hinweg mit Modell-Caching (für große Modelle) und (c) Vorhalten von Warm Pool-Instanzen mit im GPU-Speicher vorgeladenen Modellen.
On-Off-Skalierungsarchitektur - System Architecture Diagram

System Architecture Overview

Technologieauswahl

SchichtTechnologien
RechenleistungAWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal
OrchestrierungKubernetes (Karpenter für Autoscaling), AWS Batch, benutzerdefinierter Job Orchestrator
Job QueueAWS SQS, BullMQ (Redis), Temporal, Celery
SpeicherS3 (Checkpoints, Modell-Artefakte), NVMe (Modell-Cache), EFS (gemeinsamer Arbeitsbereich)
MonitoringCloudWatch/Prometheus (Warteschlangentiefe, Instanzauslastung, Job-Latenz), benutzerdefinierte Kosten-Dashboards

Wann zu verwenden / Wann zu vermeiden

Verwenden, wennVermeiden, wenn
Workload ist sprunghaft – Spitzennachfrage ist 5x+ der durchschnittlichen NachfrageTraffic ist stetig und vorhersehbar – richtig dimensionierte Reserved Instances sind günstiger
GPU-/High-Compute-Jobs, die im Leerlauf teuer sindDie Workload ist leichte CPU-Verarbeitung, die für Serverless (Lambda) geeignet ist
Jobs können 1-5 Minuten Kaltstart für die Cold Pool-Bereitstellung tolerierenJob-Startlatenz im Sub-Sekundenbereich ist erforderlich – Sie benötigen Always-On-Infrastruktur
Kostenoptimierung ist ein Hauptanliegen und Spot-Preise bieten 60-90% ErsparnisseSpot-Unterbrechung würde Datenverlust verursachen, den Checkpointing nicht mindern kann

Unser Ansatz

MW entwickelt On-Off-Skalierung unter dem Blickwinkel der „Kosten pro Job“ – wir modellieren die Gesamtkosten für die Verarbeitung einer Arbeitseinheit (ein Video, ein Trainingslauf, eine Batch Inference) über verschiedene Skalierungsstrategien hinweg und wählen diejenige, die die Kosten bei der erforderlichen Latenz-SLA minimiert. Unsere Implementierungen umfassen Echtzeit-Kosten-Dashboards, die Kosten pro Job, Infrastrukturnutzung und Spot-Einsparungen anzeigen. Wir haben On-Off-GPU-Infrastruktur aufgebaut, die die Videoverarbeitungskosten um 70 % im Vergleich zu Reserved Instances reduziert hat, und ML-Trainingscluster, die 64 GPUs für einen 4-stündigen Trainingslauf bereitstellen und diese automatisch wieder freigeben.

Verwandte Blueprints

  • GPU Cluster Orchestration for AI Workloads – GPU-Bereitstellung und -Orchestrierung für ML-Training
  • Real-Time AI Video Surveillance System – Burst Inference für Videoanalyse-Ereignisse
  • Live Sports Highlight Generator – Ereignisgesteuerte Videoverarbeitung mit Burst Compute

Verwandte Fallstudien

  • On-Off Pattern Video Processing – GPU-Bereitstellung mit Warm-/Cold-Pools für Video-Encoding-Workloads
  • Video Encoding Platform – Serverless und Spot-basierte Codierung mit automatisch skalierten Worker-Pools
Related Technologies
Cloud SolutionsAI Development
Infrastructure

Security-First-Architektur

Sicherheit ist kein Feature, das man nach dem Launch hinzufügt. Es ist eine architektonische Eigenschaft – entweder wurde das System dafür konzipiert, oder eben nicht.

EnterpriseView
serverless-first-architecture.webp
Infrastructure

Serverless-First-Architektur

Bezahlen Sie nur für das, was Sie nutzen, skalieren Sie auf Null, wenn Sie es nicht nutzen, und hören Sie ganz auf, Server zu verwalten – aber wissen Sie, wann sich die Wirtschaftlichkeit nicht mehr lohnt.

AdvancedView

Häufig gestellte Fragen

Kunden von MicrocosmWorks mit Batch-lastigen oder periodischen Workloads erzielen in der Regel 60-80% Cloud-Kostenreduzierungen nach der Implementierung von On-Off-Skalierung, da Compute-Ressourcen nur während aktiver Verarbeitungsfenster laufen statt 24/7. Wir entwickeln Skalierungsrichtlinien basierend auf tatsächlicher Nutzungs-Telemetrie – zum Beispiel zahlt eine Datenverarbeitungspipeline, die täglich 4 Stunden läuft, nur für diese 4 Stunden anstatt für die vollen 24 Stunden. Unsere Architekten analysieren Ihre Workload-Muster während einer Discovery-Phase, um genaue Einsparungen zu prognostizieren, bevor eine Implementierung beginnt.

Cold-Start-Zeiten variieren von 2-3 Sekunden für containerisierte Anwendungen auf vorgewärmten Node-Pools bis zu 5-10 Minuten für Workloads, die spezialisierte GPU-Instanzen oder das Laden großer Modelle erfordern, und MicrocosmWorks verwendet mehrere Techniken, um diese Verzögerung zu minimieren. Wir implementieren prädiktive Skalierung, die Ressourcen vor erwarteter Nachfrage mithilfe historischer Traffic-Muster und geplanter Ereignisse hochfährt, und wir nutzen Container-Image-Pre-Pulling sowie Warm-Pool-Reservierungen für latenzempfindliche Workloads. Für Anwendungen, die keinen Cold Start tolerieren können, halten wir eine minimale warme Basislinie aufrecht, die bei eintreffender Nachfrage aggressiv hochskaliert.

MicrocosmWorks implementiert reaktive Auto-Skalierung mit aggressiven Scale-up-Richtlinien, die durch Queue-Tiefe, CPU-Auslastung oder benutzerdefinierte Anwendungsmetriken ausgelöst werden, kombiniert mit graduelleren Scale-down-Richtlinien, die Cooldown-Perioden beinhalten, um Thrashing zu vermeiden. Wir konfigurieren Over-Provisioning-Puffer während Scale-up-Ereignissen, sodass das System kontinuierliches Wachstum antizipiert, anstatt die Nachfrage Instanz für Instanz zu verfolgen. Für wirklich unvorhersehbare Spitzen wie Flash Sales oder virale Ereignisse pre-provisionieren wir Kapazität mithilfe ereignisgesteuerter Trigger aus Ihrem Marketing- oder Operations-Kalender.

MicrocosmWorks wendet On-Off-Skalierung auf Datenbanken an, indem es serverlose Datenbankangebote wie Aurora Serverless, Neon oder PlanetScale nutzt, die Compute-Ressourcen in Leerlaufzeiten auf null skalieren, während der Speicher persistent und sofort verfügbar bleibt. Für zustandsbehaftete Workloads, die keine serverlosen Datenbanken nutzen können, implementieren wir Read-Replica-Skalierung, die Replicas basierend auf der Query-Last hinzufügt und entfernt, während eine minimale primäre Instanz immer läuft. Dieser hybride Ansatz bietet Kunden die Kostenvorteile der Skalierung für ihre Daten-Tier, ohne die Komplexität der Verwaltung des Datenbankstatus während der Shutdown- und Neustart-Zyklen.

MicrocosmWorks implementiert eine umfassende Skalierungs-Observability, die Instanzzahlen, Skalierungsereignislatenz, fehlgeschlagene Skalierungsversuche und die Diskrepanz zwischen gewünschter und tatsächlicher Kapazität in Echtzeit mithilfe von Grafana- oder Datadog-Dashboards verfolgt. Wir konfigurieren Mehrkanal-Alerts für Skalierungsfehler, anhaltend hohe Auslastung, die darauf hindeutet, dass die Skalierungsobergrenze zu niedrig ist, und Kostenanomalien, die auf eine außer Kontrolle geratene Skalierung hinweisen. Unsere Runbooks beinhalten automatisierte Behebung für gängige Fehlerursachen wie das Erreichen von Cloud Provider Instanzlimits oder das Auftreten von Fehlern aufgrund unzureichender Kapazität in bestimmten Availability Zones.