Von 13% Fehler bei den Black Friday-Anfragen bis zu null Ausfällen: Durch die Containerisierung haben wir 60% der Serverkosten eingespart.

Letztes Jahr ist unsere Adress解析-Schnittstelle während des Black Friday-Events völlig zusammengebrochen – 13 Prozent der Anfragen erhielten die Fehlermeldung 429, und das Kundenservice-Team erhielt über 300 Beschwerden von Händlern. Drei Backend-Systeme mussten 24 Stunden lang ununterbrochen arbeiten, um den Spitzenverkehr zu bewältigen. Zu dieser Zeit lief unser Service noch auf zwei Cloud-Servern mit festen Konfigurationen, und die Skalierung erfolgte ausschließlich durch manuelle Anpassungen der Konfigurationen. Erst nachdem neue Instanzen online waren, war der Verkehrsspitzen wieder vorbei.

Zuerst erklären wir Ihnen genau, was Containerisierte Bereitstellung eigentlich ist.

Einfach ausgedrückt: Man packt seinen Code, die abhängigen Bibliotheken sowie die Konfigurationsdateien in einen standardisierten „Container“ mit einer Größe von einigen MB bis zu mehreren hundert MB. Egal auf welchem Server der Code ausgeführt wird, die Laufumgebung ist zu 100 % identisch. Die Größe des ursprünglich gepackten Images für den Dienst zur Adressauflösung betrug …187MBDie gesamte Startprozedur dauert nicht länger als 10 Sekunden.

Die drei Kernvorteile, die wir tatsächlich erhalten haben

• Automatische Skalierung rettet wirklich das Leben: In diesem Jahr ist der Datenverkehr am Black Friday um das Dreifache gestiegen. Das System hat automatisch 27 Container-Instanzen gestartet und nach dem Höchstwert automatisch auf 3 reduziert – ohne jegliche menschliche Eingriffe. Die Fehlerrate ist direkt auf unter 0,1% gesunken.
• Der Bug aufgrund von inkonsistenten Umgebungen ist endgültig beseitigt: Das mysteriöse Problem, das vorher lokal ohne Probleme funktionierte, aber sofort nach der Veröffentlichung abstürzte, machte 40 Prozent unserer gesamten Bugs aus. Seit dem Umzug in Container sind solche Probleme nicht mehr aufgetreten.
• Die Serverkosten wurden direkt um die Hälfte reduziert: Früher mussten wir aus Gründen der Spitzenbelastung das ganze Jahr über acht hochausgestattete Server mieten, wobei die Nutzungsrate nur bei 15% lag. Jetzt zahlen wir nur für die tatsächliche Nutzung, was uns im Jahresvergleich 60% der Serverausgaben erspart.

Schauen Sie nicht nur auf die Vorteile – wir sind bereits mehrmals in diese Fallen getreten.

Als wir das Container-System zum ersten Mal verwendet haben, wollten wir es uns einfach machen und haben alle Protokolle sowie temporären Dateien direkt im Container abgelegt. Leider führte dies dazu, dass eine Instanz automatisch abgeschaltet wurde und die Protokolle der letzten drei Tage verloren gingen. Die Wiederherstellung dieser Daten dauerte ganze zwei Tage. Ein weiteres Mal enthielt das Image zu viele unnötige Abhängigkeiten, wodurch die Startzeit von 10 Sekunden auf 2 Minuten anstieg. Bei plötzlichem Anstieg des Datenverkehrs konnten wir nicht rechtzeitig die Kapazitäten erweitern, was beinahe zu einem weiteren Ausfall geführt hätte.

Am leichtesten übersehen werden die Probleme mit den Berechtigungen: Ursprünglich haben wir den Containern Root-Berechtigungen gewährt, was später von Mining-Programmen ausgenutzt wurde, die 30% der CPU-Ressourcen in Anspruch nahmen. Erst nach einer Woche wurde dies über die Überwachungssysteme festgestellt.

Zuerst musst du dir klar werden, ob du es wirklich verwenden solltest oder nicht.

Wenn Sie ein kleines Team von ein paar Personen sind, das interne Tools entwickelt, bei denen die Datenverkehrsflüsse sehr stabil sind und es nur 1-2 Dienste gibt, dann ist es wirklich nicht notwendig, sich damit aufzuhalten. Es ist am einfachsten, einfach einen Server zu mieten.

Aber wenn Ihre Service-Nachfrage stark schwankt, häufige Updates erforderlich sind, die Entwicklungsumgebungen der verschiedenen Teammitglieder oft zu Konflikten führen, oder Sie bereits über die Kosten für ungenutzte Serverressourcen nachdenken, dann lohnt sich eine Containerisierung definitiv – auch wenn es bedeutet, eine Woche Zeit dafür aufzuwenden, es auszuprobieren.

Drei konkrete Ratschläge für Anfänger

• Versuchen Sie nicht gleich, mit dem K8S-Cluster zu arbeiten. Führen Sie zunächst eine Einzelserver-Installation mit Docker Compose durch, um die Logik der Paketierung, des Betriebs und des Log-Mountens zu verstehen. So haben wir die ersten drei Monate verbracht – und das war völlig ausreichend.
• Beim ersten Packen der Image wird das „Prinzip der Minimierung“ angewendet – nur die für den Betrieb unerlässlichen Abhängigkeiten werden installiert. Mit einer Alpine-Basisimage kann das Volumen um mehr als die Hälfte reduziert werden.
• Alle erzeugten Daten und Protokolle müssen auf einem externen Speichervolumen abgelegt werden und dürfen auf keinen Fall im Container selbst gespeichert werden. Dieser Punkt steht ganz zu Beginn der operativen Richtlinien eurer Team.

Häufig gestellte Fragen und Antworten

Frage: Niemand in unserem Team versteht Container – wird der Lernaufwand dann sehr hoch sein?
Antwort: Für die grundlegende Nutzung reichen zwei Tage aus, um die offiziellen Einführungsdokumente zu lesen, und dann kannst du den ersten Dienst erfolgreich in Betrieb nehmen. Die etwas komplexeren Konfigurationen für Clusters kannst du gerne später lernen, wenn du sie benötigst – es ist noch genug Zeit dafür.

Frage: Wird es sehr aufwendig sein, die bestehenden Dienste in Container zu migrieren?
Unsere drei Backend-Dienste wurden in einer Woche vollständig migriert. Der größte Teil der Zeit wurde mit der Aufklärung der Abhängigkeiten verbracht; die eigentliche Erstellung der Dockerfiles dauerte weniger als einen Tag.