Die Kunst der Containerskalierung: Wiederholungsversuche

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Die Skalierung von Containern erfordert mehr, als einfach einen Proxy vor einen Dienst zu schalten und es dabei zu belassen. Skalierung umfasst mehr als nur die Verteilung, und in der schnelllebigen Welt der Container sind fünf verschiedene Funktionen erforderlich, um Skalierbarkeit zu gewährleisten: Wiederholungsversuche, Leistungsschalter, Erkennung, Verteilung, und Überwachung.

In diesem Beitrag über die Kunst der Skalierung von Containern befassen wir uns eingehend mit Wiederholungsversuchen.

Wiederholungsversuche

Wenn man als Kind ein Spiel spielt, gehört die Möglichkeit eines neuen Versuchs bei vielen Spielen einfach dazu. Nach einem Fehlschlag ruft man oft: „Noch mal!“, in der Hoffnung, dass die anderen einen erneut versuchen lassen. Manchmal tun sie es. Manchmal auch nicht. Wie ich festgestellt habe, hält das ein Kind nur selten davon ab, es trotzdem zu versuchen.

Bei der Skalierung von Apps (oder Diensten, wenn Ihnen das lieber ist) ist das Konzept eines erneuten Versuchs ganz ähnlich. Nachdem ein Proxy einen Dienst ausgewählt und versucht hat, eine Anfrage zu erfüllen, erhält er eine Fehlermeldung. In einfachen Lastverteilungsszenarien wird dies üblicherweise anhand des HTTP-Antwortcodes ermittelt. Alles außer „200 OK“ gilt als Fehler. Dazu gehören auch Zeitüberschreitungen auf Netzwerk- und TCP-Ebene. Der Load Balancer kann die fehlgeschlagene Antwort entweder ungeprüft an den

Anfragenden zurückgeben oder, wenn es intelligent genug ist, die Anfrage erneut senden, in der Hoffnung, dass ein weiterer Versuch zu einer erfolgreichen Antwort führt.

Das klingt ziemlich banal, aber in den Anfängen der Skalierung gab es so etwas wie einen erneuten Versuch noch nicht. Wenn etwas fehlschlug, dann war das eben so, und wir mussten damit umgehen. Meistens, indem wir manuell versuchten, die Seite im Browser neu zu laden. Irgendwann wurden Proxys intelligent genug, um selbstständig erneute Versuche durchzuführen, wodurch bei so mancher Tastatur die Tasten „Strg“ und „R“ vor dem Verschleiß bewahrt wurden.

Auf den ersten Blick ist dies ein geradezu existenzielles Beispiel für die Definition von Wahnsinn. Wenn die Anfrage beim ersten Mal fehlgeschlagen ist, warum sollten wir schließlich erwarten, dass sie beim zweiten (oder gar dritten) Mal erfolgreich ist?

Die Antwort liegt in der Ursache des Fehlers. Bei der Skalierung von Apps ist es wichtig zu verstehen, wie sich die Verbindungskapazität auf Fehler auswirkt. Die Auslastung einer bestimmten Ressource ist zu keinem Zeitpunkt konstant. Verbindungen werden fortlaufend geöffnet und geschlossen. Die zugrunde liegende Webanwendungsplattform – ob Apache oder IIS, eine Node.js-Engine oder ein anderer Stack – unterliegt festgelegten Kapazitätsbeschränkungen. Sie kann nur X gleichzeitige Verbindungen aufrechterhalten. Sobald dieses Limit erreicht ist, bleiben Versuche, neue Verbindungen zu öffnen, hängen oder schlagen fehl.

Wenn dies die Ursache für einen Fehler ist, wurde möglicherweise in den Mikrosekunden, die der Proxy benötigte, um eine Fehlerantwort zu erhalten, eine andere Verbindung geschlossen, sodass ein erneuter Versuch erfolgreich sein kann.

In einigen Fällen liegt der Fehler innerhalb der Plattform. Der gefürchtete „500 Internal Server Error“. Dieser Status tritt häufig auf, wenn der Server nicht überlastet ist, aber einen anderen (externen) Dienst aufgerufen hat, der nicht rechtzeitig geantwortet hat. Manchmal liegt es daran, dass ein Datenbankverbindungspool an seine Grenzen stößt. Die Abhängigkeit von externen Diensten kann eine Kaskade von Fehlern auslösen, die – ähnlich wie eine Verbindungsüberlastung – oft bereits behoben ist, wenn Sie die ursprüngliche Fehlermeldung erhalten.

Möglicherweise wird Ihnen auch der ach so hilfreiche Fehler „503 Service Unavailable“ angezeigt. Dieser kann auf eine Überlastung zurückzuführen sein, doch wie bei allen HTTP-Fehlercodes lässt sich daraus nicht immer zuverlässig ableiten, was tatsächlich schiefgelaufen ist. Er kann beispielsweise bei einem DNS-Fehler oder – im Fall von IIS und ASP – bei einer vollen Warteschlange auftreten. Die möglichen Ursachen sind äußerst vielfältig. Und auch hier kann das Problem bereits behoben sein, wenn Sie die Fehlermeldung erhalten. Daher sollten Sie es auf jeden Fall zunächst erneut versuchen.

Natürlich können Sie die Anfrage nicht endlos wiederholen. Ähnlich wie bei den unbeabsichtigten Folgen von TCP-Neuübertragungen – die Netzwerke überlasten und Empfänger überfordern können – werden auch Wiederholungsversuche irgendwann zwecklos. Es gibt keine feste Regel dafür, wie oft Sie es erneut versuchen sollten, bevor Sie aufgeben, üblich sind jedoch drei bis fünf Versuche.

An diesem Punkt ist es an der Zeit, dem Anfragenden eine Fehlermeldung zu senden und einen Circuit Breaker auszulösen. Auf diese Funktion gehen wir in unserem nächsten Beitrag näher ein.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie