Die Kunst der Container-Skalierung: Wiederholungsversuche
Beim Skalieren von Containern handelt es sich um mehr, als einfach einen Proxy vor einen Dienst zu setzen und sich dann zurückzuziehen. Zur Skalierung gehört mehr als nur die Verteilung. In der schnelllebigen Welt der Container sind zur Sicherstellung der Skalierbarkeit fünf verschiedene Funktionen erforderlich: Wiederholungsversuche, Leistungsschalter, Erkennung , Verteilung und Überwachung.
In diesem Beitrag zur Kunst der Containerskalierung befassen wir uns mit Wiederholungsversuchen.
Wiederholungsversuche
Wenn Sie als Kind ein Spiel spielen, ist das Konzept eines Wiederholungsversuchs bei vielen Spielen üblich. „Noch einmal!“ wird häufig nach einem Fehlschlag gerufen, in der Hoffnung, dass die anderen Spieler einen noch einmal versuchen lassen. Manchmal ist das so. Manchmal ist das nicht der Fall. Ich habe festgestellt, dass das ein Kind selten davon abhält, es zu versuchen.
Beim Skalieren von Apps (oder Diensten, wenn Sie das bevorzugen) ist das Konzept eines Wiederholungsversuchs weitgehend dasselbe. Wenn ein Proxy einen Dienst auswählt und versucht, eine Anfrage zu erfüllen, erhält er eine Fehlermeldung. In grundlegenden Lastausgleichsszenarien wird dies normalerweise durch die Untersuchung des HTTP-Antwortcodes ermittelt. Alles andere als „200 OK“ ist ein Fehler. Dazu gehören Timeouts auf Netzwerk- und TCP-Ebene. Der Load Balancer kann die fehlgeschlagene Antwort entweder blind an den
Anforderer oder, wenn es intelligent genug ist, kann es die Anfrage wiederholen, in der Hoffnung, dass eine nachfolgende Anfrage zu einer erfolgreichen Antwort führt.
Das klingt ziemlich einfach, aber zu Beginn des Skalierens gab es so etwas wie einen erneuten Versuch nicht. Wenn es scheiterte, dann scheiterte es und wir haben uns damit befasst. Normalerweise durch einen manuellen Neuladeversuch über den Browser. Mit der Zeit wurden die Proxys intelligent genug, um selbst Wiederholungsversuche durchzuführen, wodurch viele Tastaturen vor der Abnutzung der Tasten „STRG“ und „R“ bewahrt wurden.
Oberflächlich betrachtet ist dies ein existenzielles Beispiel für die Definition von Wahnsinn. Wenn die Anfrage beim ersten Mal fehlgeschlagen ist, warum sollten wir dann erwarten, dass sie beim zweiten (oder sogar dritten) Mal erfolgreich ist?
Die Antwort liegt im Grund des Scheiterns. Beim Skalieren von Apps ist es wichtig, die Auswirkungen der Verbindungskapazität auf Ausfälle zu verstehen. Die Belastung einer bestimmten Ressource ist zu einem bestimmten Zeitpunkt nicht festgelegt. Es werden ständig Verbindungen geöffnet und geschlossen. Die zugrunde liegende Web-App-Plattform – sei es Apache oder IIS, eine Node.js-Engine oder ein anderer Stack – unterliegt definierten Kapazitätsbeschränkungen. Es kann nur eine X-Anzahl gleichzeitiger Verbindungen aufrechterhalten werden. Wenn dieses Limit erreicht ist, bleiben Versuche, neue Verbindungen herzustellen, hängen oder schlagen fehl.
Wenn dies die Ursache für einen Fehler ist, wurde in den Mikrosekunden, die der Proxy benötigte, um eine fehlgeschlagene Antwort zu empfangen, möglicherweise eine andere Verbindung geschlossen, wodurch die Möglichkeit für einen erfolgreichen erneuten Versuch eröffnet wurde.
In einigen Fällen liegt ein Fehler innerhalb der Plattform vor. Der gefürchtete „ 500 Internal Server Error “. Dieser Status tritt häufig auf, wenn der Server nicht überlastet ist, sondern einen Aufruf an einen anderen (externen) Dienst getätigt hat, der nicht rechtzeitig geantwortet hat. Manchmal ist dies die Folge davon, dass ein Datenbankverbindungspool seine Grenzen erreicht. Die Abhängigkeit von externen Diensten kann zu einer Kette von Fehlern führen, die, wie etwa eine Verbindungsüberlastung, oft bereits behoben sind, wenn der erste Fehler auftritt.
Möglicherweise wird Ihnen auch der äußerst hilfreiche Fehler „ 503 Service Unavailable “ angezeigt. Dies kann eine Reaktion auf eine Überlastung sein, aber wie bei allen HTTP-Fehlercodes sind sie nicht immer ein guter Indikator dafür, was tatsächlich schief läuft. Dies kann möglicherweise als Reaktion auf einen DNS-Fehler oder, im Fall von IIS und ASP, auf eine volle Warteschlange angezeigt werden. Die Möglichkeiten sind wirklich sehr vielfältig. Und wiederum gilt: Bis die Fehlermeldung angezeigt wird, sind die Probleme möglicherweise bereits behoben. Ihre erste Reaktion sollte also definitiv ein erneuter Versuch sein.
Natürlich können Sie es nicht einfach bis zum Sankt-Nimmerleins-Tag noch einmal versuchen. Wie bei den unbeabsichtigten Folgen einer TCP-Neuübertragung, die Netzwerke überlasten und Empfänger überfordern kann, sind Wiederholungsversuche letztendlich sinnlos. Es gibt keine feste Regel, wie oft Sie es erneut versuchen sollten, bevor Sie aufgeben, aber zwischen 3 und 5 sind üblich.
An diesem Punkt ist es an der Zeit, dem Antragsteller seine Entschuldigung mitzuteilen und einen Schutzschalter einzuschalten. Wir werden in unserem nächsten Beitrag tiefer auf diese Fähigkeit eingehen.