SignalR Skalierung mit Azure EventHub

Question

Ich suche Hochfrequenz-Skalierungslösung für SignalR. Ich frage mich, ob ich es mit Azure EventHub machen kann. Wenn ich EventHub als Backplane für SignalR-Nachrichten verwende, wird es für mich ein Engpass?

Ich habe überprüft this Seite, aber es gibt nichts über EventHub, wie es ziemlich neu ist.

Answer 1

Ich kann nicht mit den genauen Einzelheiten von SignalR sprechen; Sie können EventHubs jedoch grundsätzlich für eine Rückwandplatine verwenden, müssen sich jedoch der Einschränkungen bewusst sein.

Das Backplane Scaleout-Muster von SignalR setzt voraus, dass alle Server Zugriff auf alle Nachrichten haben und vermutlich alle verarbeiten werden. Dies bietet eine ziemlich klare Begrenzung dessen, was eine einzelne Rückwandplatine auf Standardhardware oder in der Cloud leisten kann. In einer typischen Cloud können Sie möglicherweise einen Datendurchsatz von 100 MB/s (schöne runde Zahl für 1 GB/s nic), oberes Ende der Standardhardware (und Azures HPC-Maschinen) 1000 MB/s (10 GBit/Sekunde nic) aufrechterhalten.

Die Frage ist also, können Azure EventHubs Sie zu dieser architektonischen Begrenzung des Durchsatzes bringen?

Die Antwort darauf ist einfach ja. 100 oder 1000 Partitionen bieten ausreichend Schreibdurchsatz und ausreichend Lesekapazität für 2 Server. Die nächste Frage ist, ob Sie nur 100MB/Sekunde benötigen, um in Ihrer Backplane pro Server zu lesen, wie viele Server die Daten lesen können (dh wenn Sie 100MB/Sekunde von Aktienzellen aussenden, bei denen die Datengröße nicht zunimmt mit der Anzahl der Server).

Die Antwort hier ist, so viele Sie wollen, aber es gibt ein paar Tricks.

EventHubs skalieren, indem Sie den Datenstrom partitionieren. Jede Partition hat einen maximalen Lesedurchsatz von 2 MB/s, der von allen Lesern gemeinsam genutzt wird. Sie können jedoch einfach die Anzahl der Partitionen multiplizieren, um die Aufteilung auszugleichen (das Hinzufügen von mehr als 32 erfordert das Gespräch mit Microsoft). Die Designannahme von EventHubs (wie Kafka und Kinesis) ist, dass der Verbrauch auf Maschinen aufgeteilt wird, wodurch die oben diskutierte Rückwandbegrenzung vermieden wird. Verbraucher, die zusammenarbeiten, um den Stream zu lesen, sind eine Consumer-Gruppe (Azure scheint eine benannte CG selbst für ein direktes Lesegerät zu benötigen), in diesem Backplane-Modell gibt es keine logischen Verbrauchergruppen, also stellt sich die Frage, wie man die Daten liest.

Die einfachste Lösung ist die Verwendung des High-Level-Autoport-Ereignisprozessor-Hosts, wobei jeder Server seine eigene Consumer-Gruppe mit einem festen Namen ist. Mit nur einem Server in jeder Verbrauchergruppe erhält jeder Server alle Partitionen (500 für 10 Server erreichen 100 MB/Sekunde, aka $ 11.000/Monat + $ 0,028 pro Million Ereignisse).

Dieser Ansatz hat eine wichtige Einschränkung: Sie sind auf 20 consumer groups per event hub beschränkt. So können Sie Event Hubs miteinander verketten oder einen Baum mit diesem Ansatz bilden, um beliebige Zahlen zu erhalten.

Die andere Option besteht darin, direkte Clients zu verwenden, die eine Verbindung zu bestimmten Partitionen herstellen. A single partition in a consumer group can have 5 readers, wodurch die Notwendigkeit verringert wird, Hubs um den Faktor 5 zu verketten, wodurch die Kosten pro Ereignis um den Faktor 5 reduziert werden (was die Anforderungen an die Durchsatzeinheit nicht verringert).

Zusammenfassend sollte es nicht zu einem Flaschenhals werden bevor irgendeine Backplane ein Flaschenhals werden würde. Aber bauen Sie nicht etwas auf einer Backplane auf, wenn Sie erwarten, dass es im Datenverkehr 100 MB/Sekunde überschreitet.

Ich sprach nicht über Latenz, Sie müssen das selbst testen, aber die Chancen stehen gut, dass Sie nicht HFT in der Cloud machen und es gibt einen Grund, warum Echtzeitspiele typischerweise in Instanzen sind.