Muster „Warteschlangenbasierter Lastenausgleich“

Verwenden Sie eine Warteschlange, die als Puffer zwischen einer Aufgabe und dem Dienst fungiert, den sie aufruft. Dieser Ansatz glättet zeitweise hohe Lasten, die dazu führen können, dass der Dienst fehlschlägt oder beim Vorgang eine Zeitüberschreitung auftritt. Er trägt dazu bei, die Auswirkungen von Lastspitzen auf die Verfügbarkeit und Reaktionsfähigkeit von Vorgang und Dienst zu minimieren.

Kontext und Problem

Viele Lösungen in der Cloud führen Aufgaben aus, die Dienste aufrufen. In dieser Umgebung können zeitweise hohe Lasten bei einem Dienst zu Leistungs- oder Zuverlässigkeitsproblemen führen.

Ein Dienst ist möglicherweise Teil derselben Lösung wie die Aufgaben, die ihn verwenden, oder es ist ein Partnerdienst, der Zugriff auf häufig verwendete Ressourcen bietet. Beispiele für diese Arten von Diensten sind ein Cache oder ein Speicherdienst. Wenn mehrere Aufgaben gleichzeitig ausgeführt werden und denselben Dienst verwenden, ist es schwierig, das Volumen der Anforderungen jederzeit vorherzusagen.

Ein Dienst kann Nachfragespitzen aufweisen, die ihn überlasten und dazu führen, dass er nicht schnell auf Anfragen reagieren kann. Das Überfluten eines Dienstes mit vielen gleichzeitigen Anfragen kann auch dazu führen, dass der Dienst ausfällt, wenn er die durch diese Anfragen verursachte Konkurrenz um Ressourcen nicht bewältigen kann.

Lösung

Platzieren Sie eine Warteschlange zwischen der Aufgabe und dem Dienst. Der Task und der Dienst werden asynchron ausgeführt. Die Aufgabe stellt eine Nachricht bereit, die die Daten enthält, die der Dienst für die Warteschlange benötigt. Die Warteschlange fungiert als Puffer und speichert die Nachricht, bis der Dienst sie abruft. Der Dienst ruft Nachrichten aus der Warteschlange ab und verarbeitet sie. Anforderungen aus mehreren Aufgaben, die mit sehr variablen Raten generiert werden können, können über dieselbe Nachrichtenwarteschlange an den Dienst übergeben werden. Das folgende Diagramm zeigt, wie eine Warteschlange die Last bei einem Dienst ausgleichen kann.

Die Warteschlange entkoppelt die Aufgaben vom Dienst, damit der Dienst die Nachrichten in seinem eigenen Tempo verarbeiten kann, auch wenn gleichzeitige Aufgaben eine hohe Anzahl von Anforderungen generieren. Außerdem werden Aufgaben nicht verzögert, wenn der Dienst nicht verfügbar ist, wenn Nachrichten in die Warteschlange gestellt werden.

Dieses Muster bietet folgende Vorteile:

• Sie hilft dabei, die Verfügbarkeit zu maximieren, da Dienstverzögerungen nicht sofort und direkt auswirkungen auf die Anwendung haben. Die Anwendung kann nachrichten weiterhin in der Warteschlange posten, auch wenn der Dienst nicht verfügbar ist oder derzeit keine Nachrichten verarbeitet.

• Sie hilft dabei, die Skalierbarkeit zu maximieren, da die Anzahl der Warteschlangen und die Anzahl der Dienste variieren können, um die Nachfrage zu erfüllen.

• Dies trägt zur Kontrolle der Kosten bei, da Sie nur genügend Dienstinstanzen benötigen, um die Anforderungen für eine durchschnittliche Last und nicht die Spitzenlast zu erfüllen.

Probleme und Überlegungen

Berücksichtigen Sie die folgenden Punkte, wenn Sie sich für die Implementierung dieses Musters entscheiden:

• Implementieren Sie Anwendungslogik, die die Häufigkeit steuert, mit der Dienste Nachrichten verarbeiten, um zu vermeiden, dass die Zielressource überwältigend wird. Leiten Sie Nachfragespitzen nicht an die nächste Stufe des Systems weiter. Testen Sie das System unter Last, um sicherzustellen, dass es den erforderlichen Abgleich bereitstellt. Um den erforderlichen Abgleich zu erreichen, passen Sie die Anzahl der Warteschlangen und die Anzahl der Dienstinstanzen an, die Nachrichten verarbeiten.

• Nachrichtenwarteschlangen sind ein unidirektionaler Kommunikationsmechanismus. Wenn eine Aufgabe eine Antwort von einem Dienst erwartet, müssen Sie möglicherweise einen Mechanismus implementieren, den der Dienst zum Senden einer Antwort verwenden kann. Weitere Informationen finden Sie unter Asynchrone Messagingoptionen in Azure.

• Die automatische Skalierung , ohne die aggregierte Downstreamrate der Verbraucher zu beschränken, verschiebt die Überladung nur auf nachgeschaltete Abhängigkeiten. Diese Überlastung kann die Konkurrenz um Ressourcen erhöhen, die diese Dienste gemeinsam nutzen, und die Wirksamkeit der Warteschlange beim Ausgleichen der Last verringern.

• Wenn Ihre durchschnittliche Erzeugerrate die Verbraucherrate überschreitet, nimmt die Warteschlange weiter zu und erhöht sich die Latenz. Überwachen Sie die Warteschlangentiefe und skalieren Sie Verbraucher innerhalb sicherer Grenzwerte, oder arbeiten Sie am Produzenten.

• Dieses Muster hängt von der Haltbarkeit der Warteschlange ab, um den Verlust von Nachrichten zu verhindern. Wenn der Broker keine Nachrichten auf dauerhaften Speicher speichert, kann ein Absturz- oder Kapazitätslimit dazu führen, dass enqueuierte Daten verloren gehen, bevor Verbraucher sie verarbeiten. Wählen Sie einen Warteschlangendienst aus, der Nachrichten auf datenträger- oder repliziertem Speicher speichert, und verstehen Sie dessen Größenkontingente und Aufbewahrungsgrenzwerte. Bewerten Sie für Workloads, bei denen Nachrichten auch regionale Ausfälle überstehen müssen, die Optionen für die Notfallwiederherstellung über geografische Regionen hinweg.

• Die meisten Warteschlangendienste liefern Nachrichten mit mindestens einmal semantischer Semantik, was bedeutet, dass Verbraucher dieselbe Nachricht mehrmals empfangen können. Entwerfen Sie die Verbraucherlogik so, dass sie idempotent ist, damit auch die mehrfache Verarbeitung derselben Nachricht zum selben Ergebnis führt und Probleme wie doppelte Datensätze oder mehrfache Belastungen vermieden werden.

• Einige Nachrichten können nicht verarbeitet werden, da sie falsch formatierte Daten enthalten, auf fehlende Ressourcen verweisen oder dauerhafte Fehler auslösen. Anstatt diese Nachrichten endlos im Kreis laufen zu lassen und die Warteschlange zu blockieren, leiten Sie sie an eine Dead-Letter-Warteschlange weiter. Überwachen Sie den Füllstand der Dead-Letter-Queue, damit Ihr Betriebsteam Fehler untersuchen, das zugrunde liegende Problem beheben und Nachrichten bei Bedarf erneut senden kann.

• Die Einführung einer Warteschlange zwischen einem Produzenten und einem Verbraucher behält nicht den ursprünglichen Übermittlungsauftrag unter allen Bedingungen bei, insbesondere wenn mehrere Verbraucher Nachrichten parallel verarbeiten. Wenn Ihre Workload eine strenge Sortierung erfordert, verwenden Sie Features wie Nachrichtensitzungen in Azure Service Bus. Wenn keine strenge Sortierung erforderlich ist, entwerfen Sie Verbraucher für die Verarbeitung von Nachrichten in beliebiger Reihenfolge, was die Skalierung vereinfacht.

Wann dieses Muster verwenden

Verwenden Sie dieses Muster in folgenden Fällen:

• Bei Ihrer Workload kommt es zu sporadischen Lastspitzen, die nachgeschaltete Dienste überlasten können.

• Sie müssen die Anforderungsaufnahme vom Verarbeitungsdurchsatz entkoppeln, um die Resilienz und Kostenkontrolle zu verbessern.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

• Der Aufrufer erfordert eine synchrone Antwort mit geringer Latenz.

• Das Workloadvolumen ist vorhersagbar niedrig und stabil, sodass das Hinzufügen von Warteschlangenkomplexität wenig Vorteile bietet.

Arbeitslastgestaltung

Bewerten Sie, wie das Muster für den warteschlangenbasierten Lastenausgleich beim Entwurf einer Workload eingesetzt werden kann, um die in den Azure Well-Architected Framework-Säulen behandelten Ziele und Prinzipien zu berücksichtigen. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Beispiel

Eine Web-App schreibt Daten in einen externen Datenspeicher. Wenn mehrere Instanzen der Web-App parallel ausgeführt werden, kann der Datenspeicher möglicherweise nicht schnell genug auf Anfragen reagieren, sodass Anfragen ein Zeitlimit überschreiten, gedrosselt werden oder anderweitig fehlschlagen. Das folgende Diagramm zeigt einen Datenspeicher, der von gleichzeitigen Anforderungen aus Instanzen einer Anwendung überfordert wird.

Verwenden Sie zum Beheben dieses Problems eine Warteschlange, um die Last zwischen den Anwendungsinstanzen und dem Datenspeicher abzugleichen. Eine Azure Functions-App liest Nachrichten aus einer Service Bus-Warteschlange und führt die Lese-/Schreibanforderungen an den Datenspeicher aus. Azure Functions können Instanzen basierend auf Service Bus Backlog mithilfe der zielbasierten Skalierung innerhalb Ihrer konfigurierten Skalierungsgrenzen skalieren. Sie können auch die Einstellungen für die Trigger-Parallelität anpassen, um den Datenspeicher zu schützen. Anleitungen zur Implementierung finden Sie unter "Zielbasierte Skalierung " und "Einschränken des Skalierungsmaßstabs". Ohne diese Optimierung kann die Workerebene die Back-End-Contention wiedereinführen.

Als Technologievariation können Sie dasselbe Muster mithilfe von Azure Container Apps anstelle von Azure Functions implementieren. Bei diesem Ansatz nutzt ein containerisierter Worker Nachrichten aus Service Bus und schreibt in den Datenspeicher. Container-Apps skaliert den Worker zwischen konfigurierten mindest- und maximalen Replikaten basierend auf Warteschlangen-bezogenen Skalierungsregeln. Sie können auch denselben Ansatz implementieren, indem Sie Azure Queue Storage als Ereignisquelle verwenden. Anleitungen zur Implementierung finden Sie unter Festlegen von Skalierungsregeln in Container-Apps und Bereitstellen eines ereignisgesteuerten Auftrags mithilfe von Container-Apps.

Nächste Schritte

Die folgenden Richtlinien sind unter Umständen beim Implementieren dieses Musters ebenfalls relevant:

• Asynchrone Messagingoptionen in Azure: Nachrichtenwarteschlangen sind inhärent asynchron. Möglicherweise müssen Sie die Anwendungslogik einer Aufgabe neu gestalten, wenn sie direkt mit einem Dienst kommuniziert. Ebenso müssen Sie möglicherweise einen Dienst umgestalten, um Anforderungen aus einer Nachrichtenwarteschlange zu akzeptieren.

• Auswahl zwischen Azure-Messagingdiensten: Weitere Informationen, die Sie bei der Auswahl eines Mechanismus für Messaging und Warteschlangen in Azure-Anwendungen unterstützen.

• Empfehlungen für die Entwicklung von Hintergrundaufträgen: Wenden Sie dieses Muster auf Hintergrundaufträge an, damit Nachrichtenwarteschlangen Anforderungen für Hintergrundaufgaben speichern können, wenn die Anwendung hohe Auslastung aufweist.

• Web-Queue-Worker-Architekturmuster: Die Webkomponente und der Worker sind beide zustandslos. Der Sitzungsstatus kann in einem verteilten Cache zwischengespeichert werden. Der Worker führt lang andauernde Aufgaben asynchron aus und kann durch Nachrichten in der Warteschlange ausgelöst oder nach einem Zeitplan zur Batchverarbeitung ausgeführt werden.

Verwandte Ressourcen

• Konkurrierendes Verbrauchermuster: Es kann möglich sein, mehrere Instanzen eines Diensts auszuführen, die jeweils als Nachrichtenanwender aus der Warteschlange zum Lastenausgleich fungieren. Sie können diesen Ansatz verwenden, um die Rate anzupassen, mit der Nachrichten empfangen und an einen Dienst übergeben werden.

• Drosselungsmuster: Eine einfache Möglichkeit, die Drosselung in einem Dienst zu implementieren, besteht darin, die warteschlangenbasierte Lastnivellierung zu verwenden und alle Anfragen über eine Nachrichtenwarteschlange an einen Dienst weiterzuleiten. Der Dienst kann Anforderungen mit einer Rate verarbeiten, mit der sichergestellt wird, dass er die benötigten Ressourcen nicht auslastet und die Menge möglicher Konflikte reduziert.