SpeechKit (DMD/4voice Stream) und Loadbalancer

Technischer Überblick

Zusatandsloses Kommunikationsprotokoll

Alle SpeechKit-Clients (egal, ob DMD/DMO selbst oder bspw. unsere 4voice Stream) kommunizieren mit dem Dragon Medical Server über eine web-basierte API über das HTTP Protokoll.

Das bedeutet, dass der Client eine HTTP(S)-Verbindung zu einer bestimmten IP-Adresse und einem bestimmten Port öffnet und eine Anfrage über diese Verbindung verschickt. Der Server antwortet auf der selben Verbindung und die Verbindung wird geschlossen.

Es handelt sich um eine zustandslose Kommunikation, d.h. der Server behandelt jede Anfrage gleich, unabhängig davon, was vorher passiert ist.

Sitzungen im DMS

Wenn man sich die Kommunikation zwischen einem Client und einem Dragon Medical Server im Detail ansieht, wird klar, dass doch ein gewisser Zustand zwischen aufeinander folgenden Calls beibehalten werden muss: Der User muss sich zuerst anmelden/eine Sitzung erstellen, dann erst kann diktiert werden.

Die Anmeldung muss nicht vor jedem Diktat erfolgen, sondern nur einmal vor dem ersten Diktat.

Solange keine Abmeldung erfolgt, muss immer wieder die selbe Sitzung verwendet werden.

Diese Information wird automatisch mit übertragen, so dass sich der Nutzer von SpeechKit darum nicht kümmern muss.

Mehrere Erkennungsserver hinter Load Balancer

Wenn nur ein einziger DMS verwendet wird, stellt der Client seine Anfragen auch immer an den selben Rechner und dieser bekommt eine Sitzungs-ID zu einer Sitzung, die auf ihm selbst erstellt worden ist.

Sollen im Rahmen einer Lastverteilung aber mehrere DMS-Server verwendet werden, kann es sein, dass auf einander folgende Anfragen an das API nicht auf dem selben Server landen.

Beispiel:

Client wendet sich zum Erstellen einer Sitzung an den Load Balancer und dieser leitet die Anfrage an Server01 weiter.

Nach dem erfolgreichen Anlegen einer Sitzung geht der Client davon aus, dass er diese nun nutzen kann und ruft die verfügbaren Sprachbefehle für den gerade angemeldeten User ab.

Diesmal geht die Anfrage vom Load Balancer aber an Server03, weil dieser aktuell die geringste Auslastung hat.

Server03 kennt aber die auf Server01 erstellte Sitzung nicht, daher wird es zu Fehlern kommen.

Lösung

Bei Load Balancern kann man i.d.R. konfigurieren, wie sie einlaufende Anfragen verarbeiten und an welchen der nachgelagerten Server sie die Anfrage weitergeben.

Die bei SpeechKit genutzte Variante nennt sich "Cookie-based affinity".

ChatGPT erklärt das Verfahren so:

Cookie-basierte Affinität, auch als Session-Affinität oder Sticky Sessions bezeichnet, ist eine Technik, die beim Load Balancing eingesetzt wird, um sicherzustellen, dass aufeinanderfolgende Anfragen eines Clients an denselben Backend-Server geleitet werden, der die ursprüngliche Anfrage bearbeitet hat. Dies wird erreicht, indem eine eindeutige Kennung, die typischerweise in einem Cookie gespeichert ist, der Sitzung des Clients zugewiesen wird und diese Kennung zur Bestimmung des Backend-Servers für nachfolgende Anfragen verwendet wird.

Die konkreten Schritte zur Einrichtung hängen vom verwendeten Load Balancer ab, wobei die gängigen Load Balancer wie Nginx, HAProxy und AWS Elastic Load Balancer (ELB) alle diese Funktion anbieten.

Dadurch kann der Load Balancer erkennen, dass es bereits Anfragen an einen bestimmten Server gab und dass folgende Anfragen ebenfalls wieder an den gleichen Server weitergeleitet werden sollen.