Geode-patroon

Het Geode-patroon omvat het implementeren van een verzameling back-endservices in een set geographicalnodes, die elk verzoek voor elke client in elke regio kunnen verwerken. Met dit patroon kunnen aanvragen in een actief-actief-stijl worden verwerkt, waardoor latentie wordt verbeterd en de beschikbaarheid wordt verhoogd door de verwerking van aanvragen over de hele wereld te distribueren.

Context en probleem

Veel grootschalige services hebben specifieke uitdagingen met betrekking tot geografische beschikbaarheid en schaal. Klassieke ontwerpen brengen de gegevens vaak naar de berekening door gegevens op te slaan in een externe SQL-server die als rekenlaag voor die gegevens fungeert, afhankelijk van opschalen voor groei.

De klassieke benadering kan een aantal uitdagingen opleveren:

• Netwerklatentieproblemen voor gebruikers die afkomstig zijn van de andere kant van de wereld om verbinding te maken met het hostingeindpunt
• Verkeersbeheer voor pieken in de vraag die de services in één regio kunnen overbelasten
• Kosten-verbiedende complexiteit van het implementeren van kopieën van app-infrastructuur in meerdere regio's voor een service van 24x7

Moderne cloudinfrastructuur is ontwikkeld om geografische taakverdeling van front-endservices mogelijk te maken, terwijl geografische replicatie van back-endservices mogelijk is. Voor beschikbaarheid en prestaties is het goed om gegevens dichter bij de gebruiker te krijgen. Wanneer gegevens geografisch worden verdeeld over een veel-geveerde gebruikersbasis, moeten de geografisch gedistribueerde gegevensarchieven ook worden gekoppeld aan de rekenresources die de gegevens verwerken. Het geode-patroon brengt de berekening naar de gegevens.

Oplossing

Implementeer de service in een aantal satellietimplementaties verspreid over de hele wereld, die elk een geode worden genoemd. Het geode-patroon maakt gebruik van de belangrijkste functies van Azure om verkeer te routeren via het kortste pad naar een geode in de buurt, waardoor de latentie en prestaties worden verbeterd. Elke geode bevindt zich achter een globale load balancer en maakt gebruik van een geo-gerepliceerde lees-schrijfservice zoals Azure Cosmos DB om het gegevensvlak te hosten, waardoor gegevensconsistentie tussen geografische gebieden wordt gegarandeerd. Services voor gegevensreplicatie zorgen ervoor dat gegevensarchieven identiek zijn over geodes, zodat alle aanvragen van alle geodes kunnen worden verwerkt.

Het belangrijkste verschil tussen een implementatiestempel en een geode is dat geodes nooit geïsoleerd bestaan. Er moeten altijd meer dan één geode in een productieplatform zijn.

Geodes hebben de volgende kenmerken:

• Bestaat uit een verzameling van verschillende typen resources, vaak gedefinieerd in een sjabloon.
• Geen afhankelijkheden buiten de geode-footprint hebben en zelfstandig zijn. Geen geode is afhankelijk van een ander om te opereren, en als de ene sterft, blijven de anderen werken.
• Losjes gekoppeld via een edge-netwerk en replicatiebackplane. U kunt bijvoorbeeld Azure Traffic Manager of Azure Front Door gebruiken voor de geodes, terwijl Azure Cosmos DB kan fungeren als het backplane voor replicatie. Geodes zijn niet hetzelfde als clusters omdat ze een replicatiebackplane delen, dus het platform zorgt voor quorumproblemen.

Het geode-patroon vindt plaats in big data-architecturen die gebruikmaken van basishardware voor het verwerken van gegevens op dezelfde computer en MapReduce om resultaten over machines samen te voegen. Een ander gebruik is near-edge compute, wat de intelligente rand van het netwerk dichter bij de intelligente rand van het netwerk brengt om de reactietijd te verminderen.

Services kunnen dit patroon gebruiken voor tientallen of honderden geodes. Bovendien neemt de tolerantie van de hele oplossing toe met elke toegevoegde geode, omdat alle geodes kunnen overnemen als een regionale storing een of meer geodes offline haalt.

Het is ook mogelijk om lokale beschikbaarheidstechnieken, zoals beschikbaarheidszones of gekoppelde regio's, te verbeteren met het geode-patroon voor wereldwijde beschikbaarheid. Dit verhoogt de complexiteit, maar is handig als uw architectuur wordt ondersteund door een opslagengine zoals blobopslag die alleen naar een gekoppelde regio kan worden gerepliceerd. U kunt geode's implementeren in een zone-, zonegebonden of regionale footprint, met een gedachte aan wettelijke of latentiebeperkingen op locatie.

Problemen en overwegingen

Gebruik de volgende technieken en technologieën om dit patroon te implementeren:

• Moderne DevOps-procedures en -hulpprogramma's voor het produceren en snel implementeren van identieke geodes in een groot aantal regio's of exemplaren.
• Automatisch schalen om reken- en databasedoorvoerexemplaren binnen een geode uit te schalen. Elke geode wordt afzonderlijk uitgeschaald, binnen de algemene beperkingen voor backplane.
• Een front-endservice zoals Azure Front Door die dynamische inhoudsversnelling, TCP en Anycast-routering splitst.
• Een replicerend gegevensarchief zoals Azure Cosmos DB om gegevensconsistentie te beheren.
• Serverloze technologieën, waar mogelijk, om de always-on-implementatiekosten te verlagen, met name wanneer de belasting regelmatig opnieuw wordt verdeeld over de hele wereld. Met deze strategie kunnen veel geodes met minimale extra investeringen worden geïmplementeerd. Serverloze en op verbruik gebaseerde factureringstechnologieën verminderen verspilling en kosten van dubbele geografisch gedistribueerde implementaties.
• API Management is niet vereist om het ontwerppatroon te implementeren, maar kan worden toegevoegd aan elke geode die de Azure Function-app van de regio fronteert om een krachtigere API-laag te bieden, waardoor de implementatie van aanvullende functionaliteit, zoals frequentiebeperking, mogelijk wordt gemaakt.

Beschouw de volgende punten als u besluit hoe u dit patroon wilt implementeren:

• Kies of u gegevens lokaal in elke regio wilt verwerken of aggregaties in één geode wilt distribueren en het resultaat over de hele wereld wilt repliceren. De Azure Cosmos DB-wijzigingenfeedprocessor biedt dit gedetailleerde beheer met behulp van het concept van de leasecontainer en het leasecollectionprefix in de bijbehorende Azure Functions-binding. Elke benadering heeft verschillende voordelen en nadelen.
• Geodes kan samenwerken met behulp van de Azure Cosmos DB-wijzigingenfeed en een realtime communicatieplatform zoals SignalR. Geodes kan communiceren met externe gebruikers via andere geodes in een mesh-patroon, zonder te weten of te zorgen waar de externe gebruiker zich bevindt.
• Dit ontwerppatroon ontkoppelt impliciet alles, wat resulteert in een ultra-sterk gedistribueerde en ontkoppelde architectuur. Overweeg hoe u verschillende onderdelen van dezelfde aanvraag kunt bijhouden, omdat ze asynchroon kunnen worden uitgevoerd op verschillende exemplaren. Een goede bewakingsstrategie is van cruciaal belang. Zowel Azure Front Door als Azure Cosmos DB kan eenvoudig worden geïntegreerd met Log Analytics en Azure Functions moeten naast Application Insights worden geïmplementeerd om een robuust bewakingssysteem te bieden voor elk onderdeel in de architectuur.
• Gedistribueerde implementaties hebben een groter aantal geheimen en ingangspunten waarvoor beveiligingsmaatregelen voor eigenschappen zijn vereist. Key Vault biedt een beveiligde laag voor geheimbeheer en elke laag binnen de API-architectuur moet correct worden beveiligd, zodat het enige ingangspunt voor de API de front-endservice is, zoals Azure Front Door. De Azure Cosmos DB moet verkeer naar de Azure Function-apps beperken en de functie-apps naar Azure Front Door met behulp van Microsoft Entra ID of procedures zoals IP-beperking.
• De prestaties worden drastisch beïnvloed door het aantal geode's dat wordt geïmplementeerd en de specifieke App Service-plannen die worden toegepast op de API-technologie in elke geode. De implementatie van extra geode's of verplaatsing naar Premium-lagen worden geleverd met verhoogde kosten voor het extra geheugen en de rekenkracht, maar doe dit niet per transactie. Overweeg belastingstests uit te voeren voor de API-architectuur zodra deze is geïmplementeerd en contrasteren, waardoor het aantal geodes wordt verhoogd met het verhogen van de prijscategorie, zodat het meest rendabele model wordt gebruikt voor uw behoeften.
• Bepaal de beschikbaarheidsvereisten voor uw gegevens. Azure Cosmos DB heeft optionele vlaggen voor het inschakelen van schrijfbewerkingen voor meerdere regio's, beschikbaarheidszones en meer. Hierdoor wordt de beschikbaarheid voor het Azure Cosmos DB-exemplaar verhoogd en wordt er een tolerantere gegevenslaag gemaakt, maar worden extra kosten in rekening gebracht.
• Azure biedt verschillende load balancers die verschillende functionaliteiten bieden voor de distributie van verkeer. Gebruik de beslissingsstructuur om de juiste optie voor de front-end van uw API te selecteren.

Wanneer dit patroon gebruiken

U gebruikt dit patroon voor het volgende:

• Als u een platform op grote schaal wilt implementeren dat gebruikers heeft verdeeld over een breed gebied.
• Voor elke service waarvoor extreme beschikbaarheids- en tolerantiekenmerken zijn vereist, omdat services op basis van het geode-patroon tegelijkertijd het verlies van meerdere serviceregio's kunnen overleven.

Dit patroon is mogelijk niet geschikt voor

• Architecturen met beperkingen, zodat alle geodes niet gelijk kunnen zijn aan gegevensopslag. Er kunnen bijvoorbeeld vereisten voor gegevenslocatie zijn, een toepassing die de tijdelijke status voor een bepaalde sessie moet behouden, of een zware weging van aanvragen naar één regio. In dit geval kunt u implementatiestempels gebruiken in combinatie met een globaal routeringsvlak dat weet waar de gegevens van een gebruiker zich bevinden, zoals het verkeersrouteringsonderdeel dat wordt beschreven in het patroon implementatiestempels.
• Situaties waarin er geen geografische verdeling vereist is. Overweeg in plaats daarvan beschikbaarheidszones en gekoppelde regio's voor clustering.
• Situaties waarin een verouderd platform moet worden aangepast. Dit patroon werkt alleen voor cloudeigen ontwikkeling en kan moeilijk te retrofit zijn.
• Eenvoudige architecturen en vereisten, waarbij georedundantie en geo-distributie niet vereist of voordelig zijn.

Workloadontwerp

Een architect moet evalueren hoe het geode-patroon kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:

Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.

Voorbeelden

• Windows Active Directory implementeert een vroege variant van dit patroon. Multi-primaire replicatie betekent dat alle updates en aanvragen in theorie kunnen worden geleverd vanaf alle serviceknooppunten, maar FSMO-rollen (Flexible Single Master Operation) betekenen dat alle geodes niet gelijk zijn.
• De geode-patroonversneller op GitHub toont dit ontwerppatroon in de praktijk en is ontworpen om ontwikkelaars te helpen deze te implementeren met echte API's.