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 ungenutzte GPUs. Stellen Sie Rechenressourcen Just-in-Time bereit, verarbeiten Sie die Workload und fahren Sie sie wieder herunter – so werden Investitionsausgaben (CAPEX) zu betrieblichen Kosten pro Auftrag (OPEX).

June 22, 2026
|
2 topics covered
Diskutieren Sie diese Architektur
Infrastructure
Category
Advanced
Complexity
AI/ML, Medien & Unterhaltung
Industries
2+
Technologies

Wann Sie das benötigen

Ihre Workload ist stoßweise – Video-Encoding-Aufträge, die Spitzen aufweisen, wenn Inhalte hochgeladen werden, ML-Trainingsläufe, die 8 GPUs für 4 Stunden benötigen und dann nichts mehr, Batch-Inferenzaufträge, die durch Geschäftsereignisse ausgelöst werden, oder Rendering-Pipelines, die über Nacht laufen. Sie sind entweder überdimensioniert (bezahlen 80% der Zeit für ungenutzte Ressourcen) oder unterdimensioniert (Aufträge stauen sich während Spitzenzeiten stundenlang). 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 Kaltstart-Penalty, 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-Warteschlangen-gesteuerte Bereitstellung und automatisierte Beendigung. Ein warm pool hält eine kleine Anzahl vorinitialisierter Instanzen bereit für den sofortigen Einsatz. Ein cold pool stellt zusätzliche Kapazität von Spot-/Preemptible-Instanzen bereit, wenn die Nachfrage den warm pool übersteigt. Ein job orchestrator leitet Aufgaben an verfügbare Instanzen weiter, überwacht den Fortschritt, handhabt Wiederholungsversuche bei Spot-Eviction und löst die Skalierung nach unten aus, wenn die Warteschlange leer ist. Das Muster ist besonders kritisch für GPU-Workloads, bei denen der Kaltstart (container pull + model loading) 3-10 Minuten dauern kann.

Referenzarchitektur

Das System zentriert sich um eine job queue (SQS, Redis oder custom), die eingehende Arbeitsanfragen puffert. Ein scaling controller überwacht die Warteschlangentiefe und stellt Instanzen zuerst aus dem warm pool, dann aus dem cold pool (spot instances) bereit. Jede worker instance zieht Aufträge aus der Warteschlange, führt die Workload (encoding, training, inference) aus, 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, wodurch Aufträge auf einer anderen Instanz ohne Neuanfang fortgesetzt werden können.

Kernkomponenten
  • Job Queue & Scheduler: Priorisierte Job-Warteschlange mit konfigurierbaren Gleichzeitigkeitsgrenzen pro Auftragstyp. Unterstützt verzögerte Ausführung, Dead-Letter-Queues für fehlgeschlagene Aufträge und Prioritätsspuren (Express-Aufträge erhalten warm pool Instanzen, Standard-Aufträge nutzen den cold pool). AWS SQS, BullMQ on Redis oder Temporal für komplexe Workflows
  • Warm Pool Manager: Verwaltet N vorinitialisierte Instanzen mit in GPU-Speicher geladenen Modellen, laufenden Containern und bestandenen Health Checks. Instanzen durchlaufen: idle → zugewiesen → in Bearbeitung → idle. Die Poolgröße ist nach Tageszeit konfigurierbar (größer während der Geschäftszeiten, kleiner über Nacht) und anpassbar basierend auf historischen Nachfragemustern
  • Cold Pool Provisioner: Stellt zusätzliche Kapazität von Spot-Instanzen (AWS), preemptible VMs (GCP) oder serverlosen GPU-Anbietern (RunPod, Modal, Salad) bereit. Behandelt Spot-Unterbrechungsbenachrichtigungen, indem Aufträge zu verfügbaren Instanzen migriert werden. Verwendet eine diversifizierte Instanztyp-Strategie (multiple GPU types, multiple AZs), um die Spot-Verfügbarkeit zu maximieren
  • Checkpoint & Recovery: Für langlaufende Aufträge (ML training, large video encoding) speichert periodisches Checkpointing den Zwischenzustand in S3. Bei Spot-Eviction wird der Auftrag neu in die Warteschlange gestellt und vom letzten Checkpoint aus fortgesetzt. Für kurze Aufträge (< 10 min) übersteigen die Kosten des Checkpointings die Kosten eines Neustarts – diese Aufträge werden einfach von Grund auf neu versucht

Entwurfsentscheidungen & Kompromisse

Warm Pool Größe
Der warm pool ist ein Kompromiss zwischen Kosten (Zahlung für ungenutzte Instanzen) und Latenz (Kaltstartzeit für den ersten Auftrag). MW dimensioniert warm pools basierend auf Ankunftsmustern in der Warteschlange: Wenn Aufträge während der Geschäftszeiten kontinuierlich eintreffen, deckt der warm pool den durchschnittlichen Durchsatz ab; der cold pool deckt Spitzen ab. Wenn Aufträge in unvorhersehbaren Bursts eintreffen, halten wir einen kleineren warm pool und akzeptieren eine Kaltstart-Latenz für die ersten Burst-Aufträge, während der cold pool bereitgestellt wird.
Spot-Instanzen vs. Serverless GPU (RunPod/Modal)
Spot-Instanzen sind pro Stunde günstiger, erfordern jedoch, dass Sie die Bereitstellung, das Eviction Handling und den Instanzlebenszyklus selbst verwalten. Serverless GPU-Anbieter (RunPod Serverless, Modal, Banana) übernehmen die Bereitstellung und bieten eine sekundengenaue Abrechnung an, aber zu einem höheren Preis pro Rechensekunde. MW nutzt Spot-Instanzen für vorhersehbare, langlaufende Workloads (>30 min) und serverlose GPUs für kurze, stoßweise Aufträge (<10 min), bei denen der Bereitstellungs-Overhead dominieren würde.
Aggressivität der Skalierung nach unten
Skalieren Sie zu schnell herunter, zahlen Sie Kaltstart-Penalties, wenn der nächste Auftrag eintrifft. Skalieren Sie zu langsam herunter, zahlen Sie für ungenutzte Instanzen. MW implementiert eine "Cooldown mit Zerfall"-Strategie: Nachdem die Warteschlange leer ist, bleiben Instanzen für eine konfigurierbare Periode warm (Standard: 10 Minuten). Wenn keine neuen Aufträge eintreffen, skalieren Instanzen progressiv herunter (50% nach 10 min, der Rest nach 30 min). Die Cooldown-Periode ist einstellbar und passt sich automatisch an basierend auf Statistiken zur Ankunftszeit zwischen Aufträgen.
GPU-Modellladeoptimierung
Für ML-Inferenz ist der Kaltstart-Engpass oft das Modellladen (downloading from S3 + loading into GPU memory), nicht der Container-Start. MW optimiert dies durch: (a) Vorab-Backen von Modellen in Container-Images (für kleine Modelle), (b) Verwendung von gemeinsam genutztem NVMe-Speicher über Instanzen hinweg mit Modell-Caching (für große Modelle) und (c) Halten von warm pool Instanzen mit vorab in den GPU-Speicher geladenen 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 for autoscaling), AWS Batch, benutzerdefinierter job orchestrator
Job-WarteschlangeAWS SQS, BullMQ (Redis), Temporal, Celery
SpeicherS3 (Checkpoints, Modellartefakte), NVMe (Modell-Cache), EFS (gemeinsamer Arbeitsbereich)
ÜberwachungCloudWatch/Prometheus (Warteschlangentiefe, Instanzenauslastung, Job-Latenz), benutzerdefinierte Kosten-Dashboards

Wann zu verwenden / Wann zu vermeiden

Verwenden, wennVermeiden, wenn
Die Workload stoßweise ist — die Spitzennachfrage das 5-fache der durchschnittlichen Nachfrage übersteigtDer Traffic stetig und vorhersehbar ist — richtig dimensionierte Reserved Instances günstiger sind
GPU-/High-Compute-Jobs bei Leerlauf teuer sindDie Workload eine leichte CPU-Verarbeitung ist, die für Serverless (Lambda) geeignet ist
Jobs einen Kaltstart von 1-5 Minuten für die cold pool Bereitstellung tolerieren könnenSub-Sekunden-Job-Startlatenz erforderlich ist — Sie Always-on-Infrastruktur benötigen
Kostenoptimierung ein Hauptanliegen ist und Spot Pricing 60-90% Einsparungen bietetSpot-Unterbrechungen zu Datenverlust führen würden, den Checkpointing nicht mindern kann

Unser Ansatz

MW entwirft On-Off-Skalierung mit dem Fokus auf "Kosten pro Auftrag" – wir modellieren die Gesamtkosten der Verarbeitung einer Arbeitseinheit (ein Video, ein Trainingslauf, eine Batch-Inferenz) ü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 Auftrag, Infrastrukturauslastung und Spot-Einsparungen anzeigen. Wir haben On-Off-GPU-Infrastruktur aufgebaut, die die Videoverarbeitungskosten um 70% im Vergleich zu Reserved Instances reduzierte, und ML-Trainingscluster, die 64 GPUs für einen 4-stündigen Trainingslauf bereitstellen und sie automatisch wieder freigeben.

Verwandte Blueprints

  • GPU-Cluster-Orchestrierung für AI-Workloads — GPU-Bereitstellung und -Orchestrierung für ML-Training
  • Echtzeit-AI-Videoüberwachungssystem — Burst-Inferenz für Videoanalyse-Ereignisse
  • Live-Sport-Highlight-Generator — Ereignisgesteuerte Videoverarbeitung mit Burst Compute

Verwandte Fallstudien

  • On-Off-Muster Videoverarbeitung — GPU-Bereitstellung mit Warm-/Cold-Pools für Video-Encoding-Workloads
  • Video-Encoding-Plattform — Serverlose und Spot-basierte Codierung mit automatisch skalierten Worker Pools
Related Technologies
Cloud-LösungenAI-Entwicklung
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-intensiven oder periodischen Workloads sehen typischerweise 60-80% Cloud-Kostenreduzierungen nach der Implementierung von On-Off-Skalierung, da Rechenressourcen nur während aktiver Verarbeitungsfenster anstatt 24/7 laufen. Wir entwerfen Skalierungsrichtlinien basierend auf der tatsächlichen Nutzungstelemetrie – zum Beispiel zahlt eine Datenverarbeitungs-Pipeline, die täglich 4 Stunden läuft, nur für diese 4 Stunden anstatt für die vollen 24. Unsere Architekten analysieren Ihre Workload-Muster während einer Evaluierungsphase, um genaue Einsparungen zu prognostizieren, bevor eine Implementierung beginnt.

Kaltstartzeiten 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 nutzt mehrere Techniken, um diese Verzögerung zu minimieren. Wir implementieren prädiktive Skalierung, die Ressourcen vor der erwarteten Nachfrage basierend auf historischen Traffic-Mustern und geplanten Ereignissen hochfährt, und wir nutzen Container-Image-Pre-Pulling sowie Warm-Pool-Reservierungen für latenzempfindliche Workloads. Für Anwendungen, die keinen Kaltstart tolerieren können, halten wir eine minimale warme Basislinie aufrecht, die aggressiv hochskaliert, wenn Nachfrage entsteht.

MicrocosmWorks implementiert reaktives Auto-Scaling mit aggressiven Scale-up-Richtlinien, die durch Warteschlangentiefe, CPU-Auslastung oder benutzerdefinierte Anwendungsmetriken ausgelöst werden, kombiniert mit sanfteren Scale-down-Richtlinien, die Cooldown-Perioden beinhalten, um Thrashing zu vermeiden. Wir konfigurieren Over-Provisioning-Puffer während Scale-up-Ereignissen, damit das System ein anhaltendes Wachstum antizipiert, anstatt der Nachfrage Instanz für Instanz hinterherzujagen. Für wirklich unvorhersehbare Spitzen wie Flash Sales oder virale Ereignisse provisionieren wir Kapazität vorab unter Verwendung 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 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 Replikate basierend auf der Abfragelast hinzufügt und entfernt, während eine minimale primäre Instanz stets läuft. Dieser hybride Ansatz bietet Kunden die Kostenvorteile der Skalierung für ihre Datenschicht, ohne die Komplexität der Verwaltung des Datenbankzustands während Herunterfahr- und Neustartzyklen.

MicrocosmWorks implementiert umfassende Skalierungs-Observability, die Instanzanzahlen, die Latenz von Skalierungsereignissen, fehlgeschlagene Skalierungsversuche und die Lücke zwischen gewünschter und tatsächlicher Kapazität in Echtzeit mithilfe von Grafana- oder Datadog-Dashboards verfolgt. Wir konfigurieren Mehrkanal-Alarme für Skalierungsfehler, anhaltend hohe Auslastung, die darauf hindeutet, dass die Skalierungsobergrenze zu niedrig ist, und Kostenanomalien, die eine unkontrollierte Skalierung anzeigen. Unsere Runbooks beinhalten eine automatisierte Fehlerbehebung für häufige Fehlermodi, wie das Erreichen von Instanzlimits des Cloud-Anbieters oder das Auftreten von Fehlern bei unzureichender Kapazität in bestimmten Availability Zones.