Federatie in meerdere sites en regio's

  • Artikel

Voor veel geavanceerde oplossingen moeten dezelfde gebeurtenisstromen beschikbaar worden gesteld voor gebruik op meerdere locaties, of moeten gebeurtenisstromen op meerdere locaties worden verzameld en vervolgens worden samengevoegd tot een specifieke locatie voor gebruik. Vaak is het ook nodig om gebeurtenisstromen te verrijken of te verminderen of conversies van gebeurtenisindelingen uit te voeren, ook voor binnen één regio en oplossing.

In de praktijk betekent dit dat uw oplossing meerdere Event Hubs onderhoudt, vaak in verschillende regio's en Event Hubs-naamruimten, en vervolgens gebeurtenissen tussen beide repliceert. U kunt ook gebeurtenissen uitwisselen met bronnen en doelen zoals Azure Service Bus, Azure IoT Hub of Apache Kafka.

Het onderhouden van meerdere actieve Event Hubs in verschillende regio's stelt clients ook in staat om te kiezen en ertussen te schakelen als hun inhoud wordt samengevoegd, waardoor het algehele systeem beter bestand is tegen regionale beschikbaarheidsproblemen.

In dit hoofdstuk 'Federatie' worden federatiepatronen uitgelegd en wordt uitgelegd hoe u deze patronen kunt realiseren met behulp van de serverloze Azure Stream Analytics of de Azure Functions runtimes, met de mogelijkheid om uw eigen transformatie- of verrijkingscode rechtstreeks in het gebeurtenisstroompad te hebben.

Federatiepatronen

Er zijn veel mogelijke redenen waarom u gebeurtenissen wilt verplaatsen tussen verschillende Event Hubs of andere bronnen en doelen, en we inventariseren de belangrijkste patronen in deze sectie en koppelen ook een koppeling naar meer gedetailleerde richtlijnen voor het respectieve patroon.

Tolerantie tegen regionale beschikbaarheidsgebeurtenissen

Regionale beschikbaarheid

Hoewel maximale beschikbaarheid en betrouwbaarheid de belangrijkste operationele prioriteiten zijn voor Event Hubs, zijn er toch veel manieren waarop een producent of consument mogelijk niet kan communiceren met de toegewezen 'primaire' Event Hubs vanwege problemen met netwerken of naamomzetting, of wanneer een Event Hubs mogelijk tijdelijk niet reageert of fouten retourneert.

Dergelijke omstandigheden zijn niet 'rampzalig', zodat u de regionale implementatie helemaal wilt stopzetten, net als in een noodherstelsituatie , maar het bedrijfsscenario van sommige toepassingen wordt mogelijk al beïnvloed door beschikbaarheidsgebeurtenissen die niet langer dan een paar minuten of zelfs seconden duren.

Er zijn twee fundamentele patronen om dergelijke scenario's aan te pakken:

  • Het replicatiepatroon gaat over het repliceren van de inhoud van een primaire Event Hubs naar een secundaire Event Hubs, waarbij de primaire Event Hubs over het algemeen door de toepassing wordt gebruikt voor het produceren en gebruiken van gebeurtenissen en de secundaire als een alternatieve optie voor het geval de primaire Event Hubs niet meer beschikbaar zijn. Omdat replicatie unidirectioneel is, van de primaire naar de secundaire, zal een overgang van zowel producenten als consumenten van een niet-beschikbare primaire naar de secundaire primaire gebeurtenis ertoe leiden dat de oude primaire niet langer nieuwe gebeurtenissen ontvangt en daarom niet meer actueel is. Pure replicatie is daarom alleen geschikt voor scenario's met eenrichtingsfailover. Zodra de failover is uitgevoerd, wordt de oude primaire verwijderd en moet er een nieuwe secundaire Event Hubs worden gemaakt in een andere doelregio.
  • Het samenvoegpatroon breidt het replicatiepatroon uit door een continue samenvoeging van de inhoud van twee of meer Event Hubs uit te voeren. Elke gebeurtenis die oorspronkelijk is geproduceerd in een van de Event Hubs die in het schema zijn opgenomen, wordt gerepliceerd naar de andere Event Hubs. Wanneer gebeurtenissen worden gerepliceerd, worden ze zodanig geannoteerd dat ze vervolgens worden genegeerd door het replicatieproces van het replicatiedoel. De resultaten van het gebruik van het samenvoegpatroon zijn twee of meer Event Hubs die dezelfde set gebeurtenissen op een uiteindelijk consistente manier bevatten.

In beide gevallen is de inhoud van de Event Hubs niet identiek. Gebeurtenissen van een producent en gegroepeerd op dezelfde partitiesleutel worden weergegeven in dezelfde relatieve volgorde als oorspronkelijk ingediend, maar de absolute volgorde van gebeurtenissen kan verschillen. Dit geldt met name voor scenario's waarin het aantal partities van bron- en doel-Event Hubs verschillen, wat wenselijk is voor verschillende van de uitgebreide patronen die hier worden beschreven. Een splitter of router kan een segment verkrijgen van een veel grotere Event Hubs met honderden partities en trechter in een kleinere Event Hubs met slechts een handvol partities, meer geschikt voor het verwerken van de subset met beperkte verwerkingsresources. Omgekeerd kan een consolidatie gegevens van verschillende kleinere Event Hubs naar één grotere Event Hubs met meer partities leiden om te voldoen aan de geconsolideerde doorvoer- en verwerkingsbehoeften.

Het criterium voor het bijeenhouden van gebeurtenissen is de partitiesleutel en niet de oorspronkelijke partitie-id. Verdere overwegingen over de relatieve volgorde en het uitvoeren van een failover van de ene Event Hubs naar de volgende zonder afhankelijk te zijn van hetzelfde bereik van stroom offsets worden besproken in de beschrijving van het replicatiepatroon .

Begeleiding:

Optimalisatie van latentie

Optimalisatie van latentie

Gebeurtenisstromen worden eenmaal geschreven door producenten, maar kunnen een willekeurig aantal keren worden gelezen door gebeurtenisgebruikers. Voor scenario's waarin een gebeurtenisstroom in een regio wordt gedeeld door meerdere consumenten en herhaaldelijk moet worden geopend tijdens de analyseverwerking die zich in een andere regio bevindt, of met alle vereisten die gelijktijdige consumenten zouden uithongeren, kan het nuttig zijn om een kopie van de gebeurtenisstroom in de buurt van de analyseprocessor te plaatsen om de retourlatentie te verminderen.

Goede voorbeelden voor wanneer replicatie de voorkeur moet krijgen boven het extern verbruiken van gebeurtenissen vanuit verschillende regio's, zijn met name die waar de regio's zeer ver uit elkaar liggen, bijvoorbeeld Europa en Australië bijna antipoden, geografisch en netwerklatentie kan gemakkelijk groter zijn dan 250 ms voor elke retour. U kunt de snelheid van het licht niet versnellen, maar u kunt het aantal retouren met hoge latentie voor interactie met gegevens verminderen.

Begeleiding:

Validatie, reductie en verrijking

Validatie, reductie, verrijking

Gebeurtenisstromen kunnen worden verzonden naar een Event Hubs door clients buiten uw eigen oplossing. Dergelijke gebeurtenisstromen kunnen vereisen dat extern ingediende gebeurtenissen worden gecontroleerd op naleving van een bepaald schema en dat niet-compatibele gebeurtenissen worden verwijderd.

In scenario's waarin de bandbreedte van clients extreem beperkt is, zoals het geval is in veel 'Internet of Things'-scenario's met bandbreedte naar gebruik, of waarbij gebeurtenissen oorspronkelijk worden verzonden via niet-IP-netwerken met beperkte pakketgrootten, moeten de gebeurtenissen mogelijk worden verrijkt met referentiegegevens om meer context toe te voegen zodat ze kunnen worden gebruikt door downstream gebeurtenisprocessors.

In andere gevallen, met name wanneer stromen worden geconsolideerd, moeten de gebeurtenisgegevens mogelijk worden verkleind in complexiteit of grootte door bepaalde details weg te laten.

Elk van deze bewerkingen kan plaatsvinden als onderdeel van replicatie-, consolidatie- of samenvoegingsstromen.

Begeleiding:

Integratie met analyseservices

Integratie met analyseservices

Verschillende cloud-systeemeigen analyseservices van Azure, zoals Azure Stream Analytics of Azure Synapse het beste werken met gestreamde of vooraf in batches opgeslagen gegevens die worden geleverd vanuit Azure Event Hubs, en Azure Event Hubs maakt integratie ook mogelijk met verschillende opensource-analysepakketten zoals Apache Samza, Apache Flink, Apache Spark en Apache Storm.

Als uw oplossing voornamelijk gebruikmaakt van Service Bus of Event Grid, kunt u deze gebeurtenissen eenvoudig toegankelijk maken voor dergelijke analysesystemen en ook voor archivering met Event Hubs Capture als u ze naar Event Hubs verzendt. Event Grid kan dit systeemeigen doen met de Event Hubs-integratie. Voor Service Bus volgt u de Richtlijnen voor Service Bus-replicatie.

Azure Stream Analytics kan rechtstreeks worden geïntegreerd met Event Hubs.

Begeleiding:

Consolidatie en normalisatie van gebeurtenisstromen

Consolidatie en normalisatie van gebeurtenisstromen

Globale oplossingen bestaan vaak uit regionale voetafdrukken die grotendeels onafhankelijk zijn, inclusief hun eigen analysemogelijkheden, maar supraregionale en globale analyseperspectieven vereisen een geïntegreerd perspectief en daarom is een centrale consolidatie van dezelfde gebeurtenisstromen die worden geëvalueerd in de respectieve regionale voetafdrukken voor het lokale perspectief.

Normalisatie is een variant van het consolidatiescenario, waarbij twee of meer binnenkomende gebeurtenisstromen hetzelfde soort gebeurtenissen bevatten, maar met verschillende structuren of verschillende coderingen, en de gebeurtenissen het meest worden getranscodeerd of getransformeerd voordat ze kunnen worden gebruikt.

Normalisatie kan ook cryptografisch werk omvatten, zoals het ontsleutelen van end-to-end versleutelde nettoladingen en het opnieuw versleutelen ervan met verschillende sleutels en algoritmen voor de downstream-consumentenpubliek.

Begeleiding:

Splitsen en routeren van gebeurtenisstromen

Splitsen en routeren van gebeurtenisstromen

Azure Event Hubs wordt af en toe gebruikt in scenario's met de stijl 'publiceren-abonneren', waarbij een binnenkomende stroom van opgenomen gebeurtenissen de capaciteit van Azure Service Bus of Azure Event Grid ver overschrijdt, die beide systeemeigen filter- en distributiemogelijkheden voor publiceren/abonneren hebben en de voorkeur hebben voor dit patroon.

Hoewel een echte 'publiceren-abonneren'-mogelijkheid het aan abonnees overlaat om de gewenste gebeurtenissen te kiezen, laat het splitsingspatroon de producergebeurtenissen toewijzen aan partities door een vooraf bepaald distributiemodel en aangewezen consumenten vervolgens uitsluitend ophalen uit 'hun' partitie. Met de Event Hubs die het totale verkeer bufferen, kan de inhoud van een bepaalde partitie, die een fractie van het oorspronkelijke doorvoervolume vertegenwoordigt, vervolgens worden gerepliceerd naar een wachtrij voor betrouwbaar, transactioneel, concurrerend consumentenverbruik.

Veel scenario's waarin Event Hubs voornamelijk wordt gebruikt voor het verplaatsen van gebeurtenissen binnen een toepassing binnen een regio, hebben enkele gevallen waarin bepaalde gebeurtenissen, mogelijk alleen van één partitie, ook ergens anders beschikbaar moeten worden gemaakt. Dit scenario is vergelijkbaar met het splitsingsscenario, maar kan een schaalbare router gebruiken die rekening houdt met alle berichten die binnenkomen in een Event Hubs en slechts enkele items kiest voor verdere routering en die routeringsdoelen mogelijk onderscheidt op basis van metagegevens van gebeurtenissen of inhoud.

Begeleiding:

Logboekprojecties

Logboekprojectie

In sommige scenario's wilt u toegang hebben tot de meest recente waarde die is verzonden voor een substroom van een gebeurtenis, die doorgaans wordt onderscheiden door de partitiesleutel. In Apache Kafka wordt dit vaak bereikt door logboekcompressie in te schakelen voor een onderwerp, waardoor alle gebeurtenissen met een unieke sleutel worden genegeerd, behalve de meest recente gebeurtenis met een unieke sleutel. De benadering van logboekcompressie heeft drie samengestelde nadelen:

  • De compressie vereist een continue reorganisatie van het logboek. Dit is een extreem dure bewerking voor een broker die is geoptimaliseerd voor toevoegwerkbelastingen.
  • Compressie is destructief en maakt een gecomprimeerd en niet-gecomprimeerd perspectief van dezelfde stroom niet mogelijk.
  • Een gecomprimeerde stream heeft nog steeds een sequentiële toegangsmodel, wat betekent dat het vinden van de gewenste waarde in het logboek in het slechtste geval het hele logboek moet lezen, wat meestal leidt tot optimalisaties die het exacte patroon implementeren dat hier wordt weergegeven: het projecteren van de logboekinhoud in een database of cache.

Uiteindelijk is een gecomprimeerd logboek een sleutel-waardearchief en als zodanig is het de slechtst mogelijke implementatieoptie voor een dergelijk archief. Het is veel efficiënter voor zoekacties en voor query's om een permanente projectie van het logboek te maken en te gebruiken op een juiste sleutel-waardeopslag of een andere database.

Omdat gebeurtenissen onveranderbaar zijn en de volgorde altijd in een logboek wordt bewaard, is elke projectie van een logboek in een sleutel-waardearchief altijd identiek voor hetzelfde bereik van gebeurtenissen, wat betekent dat een projectie die u up-to-date houdt altijd een gezaghebbende weergave biedt en dat er nooit een goede reden is om het opnieuw op te bouwen op basis van de logboekinhoud.

Begeleiding:

Replicatietoepassingstechnologieën

Voor het implementeren van de bovenstaande patronen is een schaalbare en betrouwbare uitvoeringsomgeving vereist voor de replicatietaken die u wilt configureren en uitvoeren. In Azure zijn de runtime-omgevingen die het meest geschikt zijn voor dergelijke taken staatloze taken Azure Stream Analytics voor stateful stream-replicatietaken en Azure Functions voor staatloze replicatietaken.

Stateful replicatietoepassingen in Azure Stream Analytics

Voor stateful replicatietoepassingen die rekening moeten houden met relaties tussen gebeurtenissen, samengestelde gebeurtenissen moeten maken, gebeurtenissen moeten verrijken of verminderen, gegevensaggregaties moeten maken en gebeurtenispayloads moeten transformeren, is Azure Stream Analytics de beste implementatieoptie.

In Azure Stream Analytics maakt u taken die invoer en uitvoer integreren en integreert u de gegevens van de invoer via query's die een resultaat opleveren dat vervolgens beschikbaar wordt gesteld voor de uitvoer.

Query's zijn gebaseerd op de SQL-querytaal en kunnen worden gebruikt voor het eenvoudig filteren, sorteren, aggregeren en samenvoegen van streaminggegevens gedurende een bepaalde periode. U kunt deze SQL-taal ook uitbreiden met JavaScript en door de gebruiker gedefinieerde C#-functies (UDF's). U kunt eenvoudig de opties voor gebeurtenisvolgorde en de duur van tijdvensters aanpassen bij het uitvoeren van combinatiebewerkingen, met behulp van eenvoudige taalconstructs en/of configuraties.

Elke taak heeft een of meer uitvoerwaarden voor de getransformeerde gegevens, en u kunt bepalen wat er gebeurt als reactie op de informatie die u hebt geanalyseerd. U kunt bijvoorbeeld:

  • Stuur gegevens naar services zoals Azure Functions, Service Bus Topics of Queues om communicatie of downstream aangepaste werkstromen te activeren.
  • Stuur gegevens naar een Power BI-dashboard voor realtime dashboards.
  • Gegevens opslaan in andere Azure-opslagservices (bijvoorbeeld Azure Data Lake, Azure Synapse Analytics, enzovoort) om batchanalyses uit te voeren of machine learning-modellen te trainen op basis van zeer grote, geïndexeerde pools met historische gegevens.
  • Projecties (ook wel gerealiseerde weergaven genoemd) opslaan in databases (SQL Database, Azure Cosmos DB).

Staatloze replicatietoepassingen in Azure Functions

Voor staatloze replicatietaken waarbij u gebeurtenissen wilt doorsturen zonder rekening te houden met hun nettoladingen of ze afzonderlijk wilt verwerken zonder rekening te hoeven houden met de relaties van gebeurtenissen (met uitzondering van de relatieve volgorde), kunt u Azure Functions gebruiken, wat enorme flexibiliteit biedt.

Azure Functions heeft vooraf gedefinieerde, schaalbare triggers en uitvoerbindingen voor Azure Event Hubs, Azure IoT Hub, Azure Service Bus, Azure Event Grid en Azure Queue Storage, evenals aangepaste extensies voor RabbitMQ en Apache Kafka. De meeste triggers worden dynamisch aangepast aan de doorvoerbehoeften door het aantal gelijktijdig uitgevoerde exemplaren omhoog en omlaag te schalen op basis van gedocumenteerde metrische gegevens.

Voor het bouwen van logboekprojecties ondersteunt Azure Functions uitvoerbindingen voor Azure Cosmos DB en Azure Table Storage.

Azure Functions kunnen worden uitgevoerd onder een door Azure beheerde identiteit en daarmee kunnen de configuratiewaarden voor referenties worden bewaard in strikt beheerde opslag binnen Azure Key Vault.

Azure Functions maakt het bovendien mogelijk om de replicatietaken rechtstreeks te integreren met virtuele Azure-netwerken en service-eindpunten voor alle Azure-berichtenservices, en kan gemakkelijk worden geïntegreerd met Azure Monitor.

Met het Azure Functions verbruiksabonnement kunnen de vooraf gemaakte triggers zelfs omlaag schalen naar nul terwijl er geen berichten beschikbaar zijn voor replicatie. Dit betekent dat er geen kosten in rekening worden gebracht om de configuratie gereed te houden om weer omhoog te schalen. Het belangrijkste nadeel van het gebruik van het verbruiksabonnement is dat de latentie voor replicatietaken die vanuit deze status worden geactiveerd, aanzienlijk hoger is dan bij de hostingabonnementen waarin de infrastructuur actief blijft.

In tegenstelling tot dit alles moeten de meest voorkomende replicatie-engines voor berichten en gebeurtenissen, zoals MirrorMaker van Apache Kafka, een hostingomgeving bieden en de replicatie-engine zelf schalen. Dit omvat het configureren en integreren van de beveiligings- en netwerkfuncties en het vergemakkelijken van de stroom van bewakingsgegevens. Vervolgens hebt u nog steeds geen mogelijkheid om aangepaste replicatietaken in de stroom te injecteren.

Kiezen tussen Azure Functions en Azure Stream Analytics

Azure Stream Analytics (ASA) is de beste optie wanneer u de nettolading van uw gebeurtenissen moet verwerken tijdens het repliceren ervan. ASA kan gebeurtenissen één voor één kopiëren of aggregaties maken die de informatie van gebeurtenisstromen condenseren voordat deze worden doorgestuurd. Het kan gemakkelijk leunen op het aanvullen van referentiegegevens die zijn opgeslagen in Azure Blob Storage of Azure SQL Database zonder dat dergelijke gegevens in een stroom hoeven te worden geïmporteerd.

Met ASA kunt u eenvoudig permanente, gerealiseerde weergaven maken van stromen in databases op hyperschaal. Het is een veel betere benadering van het onhandige 'logboekcompressie'-model van Apache Kafka en de vluchtige tabelprojecties aan de clientzijde van Kafka Streams.

ASA kan gemakkelijk gebeurtenissen verwerken met payloads die zijn gecodeerd in de INDELINGen CSV, JSON en Apache Avro en u kunt aangepaste deserializers voor elke andere indeling aansluiten.

Voor alle replicatietaken waarbij u gebeurtenisstromen 'as-is' wilt kopiëren zonder de nettoladingen aan te raken, of als u een router moet implementeren, cryptografisch werk moet uitvoeren, de codering van nettoladingen wilt wijzigen of als u anderszins volledige controle over de inhoud van de gegevensstroom nodig hebt, is Azure Functions de beste optie.

Volgende stappen

In dit artikel hebben we een reeks federatiepatronen verkend en de rol van Azure Functions uitgelegd als de replicatieruntime voor gebeurtenissen en berichten in Azure.

Vervolgens kunt u lezen hoe u een replicatortoepassing instelt met Azure Stream Analytics of Azure Functions en vervolgens hoe u gebeurtenisstromen repliceert tussen Event Hubs en verschillende andere gebeurtenis- en berichtensystemen: