EC2-Startzeit verkürzen

• Es ist möglich, die Startzeit von EC2-Instanzen von 40 Sekunden auf 5 Sekunden zu reduzieren
• Das ist besonders wichtig, wenn für die Verarbeitung bestimmter Aufgaben neue EC2-Instanzen benötigt werden.

Warum die Startzeit lange dauert

• Wenn eine neue EC2-Instanz angefordert wird, führt AWS mehrere Schritte aus:
  • Erstellen des Root-EBS-Volumes aus dem ausgewählten AMI
  • Zuweisung einer privaten IP-Adresse an die Instanz
  • Auswahl eines Hosts für die Instanz
  • Das eigentliche Booten der Maschine
• Auch nachdem die Hardware eingeschaltet ist, müssen Bootloader, Kernel und User-Space-Prozesse starten.

Möglichkeiten, das Problem zu umgehen

• Betreiben eines Pools an bereitstehender Rechenkapazität, um Build-Anfragen an bereits laufende EC2-Instanzen weiterzuleiten.
• Das ist jedoch nicht für alle Workloads wirtschaftlich sinnvoll.
• Bei GitHub Actions-Runnern wird jeder Job an eine dedizierte EC2-Instanz weitergeleitet.
• Um 50 parallele Jobs zu verarbeiten, 50 EC2-Instanzen online zu halten, ist unrealistisch.

Schnellere Startzeiten

• Bei bestimmten Aufgaben ist es immer schneller, unnötige Arbeit zu vermeiden.
• Jede Phase der Instanzerstellung, des Bootvorgangs und des Anwendungsstarts wird systematisch optimiert.
• Verwendet wird eine Methode, bei der eine Instanz einmal gebootet, dann gestoppt und bei Bedarf erneut gestartet wird.

Streaming des EBS-Root-Volumes

• Die Vorbereitung des EBS-Root-Volumes hat großen Einfluss auf die Bootzeit der EC2-Instanz und die Anwendungsleistung.
• Wenn ein EBS-Volume aus einem AMI erstellt wird, müssen Datenblöcke beim ersten Zugriff aus S3 geholt werden.
• AWS empfiehlt, alle Datenblöcke vorab zu laden.

Instanz nur einmal booten

• EBS-gestützte Instanzen können nach dem Stoppen erneut gestartet werden.
• Eine gestoppte Instanz behält nur ihre Konfiguration, und es fallen nur Kosten für das Root-EBS-Volume an.
• Wenn die Instanz einmal gebootet wird, um Initialisierungsarbeiten auszuführen, und dann gestoppt wird, entsteht ein „aufgewärmtes“ EBS-Root-Volume.

Auto Scaling Warm Pool

• AWS bietet Warm Pools für EC2 Auto Scaling an.
• Auto-Scaling-Gruppen benötigen jedoch Zeit, um auf Anfragen zu reagieren.
• Für die beste Performance werden EC2-Instanzen direkt über die API-Aufrufe LaunchInstances und StartInstances gestartet.

Instanzgröße anpassen

• Die Bootzeit wird optimiert, indem der Typ der aufgewärmten Instanz geändert wird.
• Für Initialisierungsarbeiten wird ein günstiger Instanztyp verwendet, und für die eigentliche Aufgabe wird auf einen leistungsstärkeren Instanztyp umgestellt.

Gesamtablauf

• Die GitHub Actions-Runner-Instanz durchläuft den folgenden Ablauf:
  • Erstellung als t3.large-Instanz
  • Zuweisung einer privaten IP-Adresse im Ziel-VPC
  • Kernel und User-Space-Prozesse werden einmal gestartet
  • Instanz wird gestoppt
  • Wenn eine Job-Anfrage eingeht, wird der Instanztyp auf m7a aktualisiert und die Instanz gestartet
  • Falls keine m7a-Kapazität verfügbar ist, wird auf einen Backup-Typ umgestellt und erneut gestartet
• Mit diesem Ablauf sinkt die Vorbereitungszeit der Instanz für einen Job von 40 Sekunden auf 5 Sekunden.

[GN⁺]

Hacker-News-Kommentare

Zusammenfassung

• Boot-Zeit: Ein Schlüsselfaktor für erfolgreiches Auto-Scaling; je kürzer die Boot-Zeit, desto kleiner das Vorhersagefenster und desto höher die Prognosegenauigkeit. Zur Kostensenkung kann es sinnvoll sein, EBS-Volumes im Voraus bereitzustellen.
• Amazons Optimierung: Amazon hat mit Technologien wie Firecracker ultraschnelles Booten umgesetzt und könnte ähnliche Funktionen auch in EC2 anbieten.
• Unveränderliche Konfiguration: Durch unveränderliche/atomare Konfigurationen lassen sich EBS-Volumes gemeinsam nutzen und mit minimalen Boot-AMIs Optimierungen erreichen.
• Messung der Boot-Zeit: Die Boot-Zeit von EC2-Instanzen zeigt eine bimodale Verteilung und liegt entweder bei 15–20 Sekunden oder bei 80 Sekunden. Die Ursache muss geklärt werden.
• GitHub Actions: Trotz Optimierungen beim Booten von GitHub-Action-Runnern ist die Zeit bis zur Auftragsübergabe lang, sodass weitere Optimierungen nötig sind.
• Vergleich mit AWS: Vergleich der Boot-Zeiten von AWS mit anderen Cloud-Anbietern. Hetzner erstellt Instanzen in wenigen Sekunden.
• EC2-Auto-Scaler: Erwähnt werden die Grenzen des EC2-Auto-Scalers und der Bedarf an Verbesserungen. Der von AWS bereitgestellte Auto-Scaler ist langsam und eingeschränkt.
• Warum EBS verwendet wird: EBS opfert Kosten und Performance zugunsten von Haltbarkeit. Als netzwerkgebundenes Volume ist es langsam. Eine minimale Linux-Installation und schneller lokaler Storage wären besser geeignet.
• Fehlende Copy-on-Write-Unterstützung in EBS: EBS unterstützt kein Copy-on-Write, und Snapshots werden in S3 gespeichert, wodurch sich die Zuweisung von IOPS verzögert.
• Wechsel zu On-Premises-Hardware: Depot könnte durch den Wechsel zu On-Premises-Hardware die Performance optimieren und Kosten senken. Es könnte besser sein, die CI-Jobs der Kunden direkt auf dem Hypervisor zu booten.