Wie man Container-Images ausführt, bevor sie vollständig heruntergeladen sind: Ein Blick auf AWS SOCI

Ein Beitrag, der die interne Funktionsweise von AWS SOCI (Seekable OCI) – das es ermöglicht, Container-Images „vor dem vollständigen Download auszuführen“ – aus der Perspektive von HTTP Range Request/FUSE/zTOC (Index) erklärt.

Hintergrund der Einführung (Erkenntnisse aus dem Slacker-Paper)

• Slacker: Fast Distribution with Lazy Docker Containers (USENIX FAST ’16) untersucht zunächst, warum der „Cold Start“ von Containern langsam ist
• Dafür wurde ein Benchmark namens HelloBench erstellt, und für 57 Container-Workloads wurde die Zeit von „Beginn der Bereitstellung → sinnvolle Arbeit möglich (Service bereit)“ gemessen
• Beobachtung 1) Der Großteil der Startzeit entfällt auf „Image-/Paket-Pull + Kopieren“
  • pulling packages (Kopieren von Paket-/Image-Daten) macht 76 % der Container-Startzeit aus
• Beobachtung 2) Direkt nach dem Start wird tatsächlich nur ein sehr kleiner Teil der Daten gelesen
  • Von den gepullten/kopierten Daten werden im Durchschnitt nur 6,4 % tatsächlich gelesen, „bevor der Container mit sinnvoller Arbeit beginnt“
• Beobachtung 3) Images teilen und duplizieren mehr Daten als erwartet
  • Berichtet wird, dass einfache block-level dedup zwischen Images bessere Kompressionseffekte zeigte als gzip-Komprimierung auf Image-Ebene, indem gemeinsame Blöcke zwischen Images gefunden wurden
• Schlussfolgerung (Problemstellung): Der Ansatz „erst alles herunterladen und dann ausführen“ ist verschwenderisch,
  und ein Verfahren, das zunächst nur das für den Start Nötige holt (frühe Ausführung) und den Rest erst bei Bedarf nachlädt (lazy), kann wirksam sein
• Auf Basis dieser Beobachtungen wurde der Docker-Storage-Treiber Slacker entworfen
• Alle Docker-Worker/Registries teilen sich einen zentralen Storage, und durch Snapshots/Klone des Backend-Storage werden die Kosten für die Dateisystem-Provisionierung gesenkt
• Container-Daten werden „bei Bedarf“ lazy geladen; dadurch wurden laut Bericht Push/Pull sowie Entwicklungs- und Deployment-Zyklen deutlich verkürzt

SOCI Snapshotter (AWS)

• Auch im README des SOCI Snapshotter wird die Slacker-Beobachtung „76 % vs. 6,4 %“ direkt als Beleg dafür zitiert, warum Lazy Loading funktioniert
• Während Slacker stark auf einen „Docker-Treiber + bestimmte Storage-(Server-)Funktionen“ angewiesen war,
  verallgemeinert SOCI diesen Ansatz für den Einsatz im OCI-Ökosystem als „Lazy Loading aus einer Registry (z. B. ECR)“
• SOCI lädt zum Zeitpunkt der Container-Ausführung nicht das gesamte Image herunter,
  sondern verschafft sich zunächst über einen separaten Index (zTOC/Index Manifest) Informationen zu Dateipositionen und Spans, lädt dann nur die benötigten Teile zuerst (on-demand), um den Start zu beschleunigen,
  und prefetcht den Rest im Hintergrund weiter – als Hybridstrategie

Zentrale Bestandteile von SOCI

• HTTP Range Request: Holt aus einer Registry (ECR) nur die benötigten Byte-Bereiche per 206 Partial Content
• zTOC: Ermöglicht mit Datei-Offsets/-Metadaten und Kompressions-Checkpoints (zInfo) die Dekompression „ab der Mitte“
• FUSE: Mountet Layer wie ein Dateisystem, fängt open/read ab und lädt benötigte Spans (standardmäßig 4 MB) on-demand

Ablauf (am Beispiel ECS Fargate)

• Index (Manifest) prüfen → zTOC herunterladen → FUSE mounten → Container starten
• Beim Dateizugriff wird nur der betreffende Span per Range Request sofort heruntergeladen, dekomprimiert und ausgeliefert
• Gleichzeitig wird das gesamte Image im Hintergrund weiter heruntergeladen – als „Hybrid“-Strategie

Grenzen/Trade-offs

• Durch Overhead für Index/Mount können kleine Images (z. B. unter 250 MB) nachteilig sein
• Der Effekt hängt weniger von der Image-Größe als vom „anfänglichen Dateizugriffsmuster“ ab
• Es gibt Spielraum für Tuning der Span-Größe (Anzahl der Requests vs. unnötige Downloads), außerdem werden Verbesserungsrichtungen wie LOD (Load Order Document) erwähnt