Geode-patroon

Het Geode-patroon omvat het implementeren van een verzameling back-endservices in een set geografische n ode's, die elk elke aanvraag voor elke client in elke regio kunnen verwerken. Met dit patroon kunt u aanvragen verwerken in een actief-actief-stijl, waardoor de latentie wordt verbeterd en de beschikbaarheid wordt verbeterd door aanvraagverwerking over de hele wereld te distribueren.

Context en probleem

Veel grootschalige services hebben specifieke uitdagingen op het gebied van geo-beschikbaarheid en schaal. Klassieke ontwerpen brengen de gegevens vaak naar de berekening door gegevens op te slaan op een externe SQL-server die fungeert als de rekenlaag voor die gegevens, afhankelijk van omhoog schalen voor groei.

De klassieke benadering kan een aantal uitdagingen met zich mee hebben:

• Netwerklatentieproblemen voor gebruikers van de andere kant van de wereld om verbinding te maken met het hosting-eindpunt
• Verkeersbeheer voor vraag bursts die de services in één regio kunnen overbelasten
• Het implementeren van kopieën van de app-infrastructuur in meerdere regio's voor een 24x7-service is te duur

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 zijn verdeeld over een ver verspreide gebruikersbasis, moeten de geografisch gedistribueerde gegevensstores ook worden toegewezen aan de rekenbronnen die de gegevens verwerken. Het geodepatroon brengt de rekenkracht 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 belangrijke functies van Azure om verkeer via het kortste pad naar een nabijgelegen geode te leiden, waardoor de latentie en prestaties worden verbeterd. Elke geode ligt achter een wereldwijd load balancer en maakt gebruik van een geografisch gerepliceerde lees-/schrijfservice, zoals Azure Cosmos DB, om het gegevensvlak te hosten, waardoor gegevensconsistentie tussen geografische regio's wordt gewaarborgd. Gegevensreplicatieservices zorgen ervoor dat gegevensopslag identiek is in meerdere geodes, zodat alle aanvragen vanuit alle geodes kunnen worden aangeboden.

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

Geodes hebben de volgende kenmerken:

• Bestaat uit een verzameling verschillende typen resources, vaak gedefinieerd in een sjabloon.
• Geen afhankelijkheden buiten de geode-footprint hebben en op zichzelf staan. Er is geen geode afhankelijk van een andere om te werken, en als er een overgaat, blijven de andere werken.
• Zijn losjes gekoppeld via een edge-netwerk en replicatiebackplane. U kunt bijvoorbeeld een Azure Traffic Manager of Azure Front Door voor het fronteren van de geodes, terwijl Azure Cosmos DB als de replicatiebackplane kan fungeren. Geodes zijn niet hetzelfde als clusters omdat ze een replicatiebackplane delen, dus het platform zorgt voor quorumproblemen.

Het geodepatroon treedt op in big data-architecturen die gebruikmaken van basishardware voor het verwerken van gegevens op dezelfde computer en MapReduce voor het consolideren van resultaten op computers. Een ander gebruik is near-edge compute, waarmee rekenkracht dichter bij de intelligente rand van het netwerk komt 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 elke geodes het over kunnen nemen 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 overgenomen door een opslag-engine zoals blobopslag die alleen kan worden gerepliceerd naar een gekoppelde regio. U kunt geodes implementeren in een zone-, zone- of regionale footprint, met het oog op regelgeving 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 om identieke geodes te produceren en snel te implementeren in een groot aantal regio's of instanties.
• Automatisch schalen om reken- en databasedoorvoer-instanties binnen een geode uit te schalen. Elke geode wordt afzonderlijk geschaald, binnen de algemene beperkingen voor backplanes.
• Een front-endservice zoals Azure Front Door die dynamische inhoudsversnelling, TCP- en Anycast-routering splitst.
• Een replicerende gegevensopslag zoals Azure Cosmos DB om gegevensconsistentie te bepalen.
• Waar mogelijk serverloze technologieën om de implementatiekosten voor always-on te verlagen, met name wanneer de belasting over de hele wereld regelmatig opnieuw wordt gebalanceerd. Met deze strategie kunnen veel geodes worden geïmplementeerd met minimale extra investering. Serverloze en op verbruik gebaseerde factureringstechnologieën verminderen verspilling en kosten door dubbele geografisch gedistribueerde implementaties.
• API Management is niet vereist voor het implementeren van het ontwerppatroon, maar kan worden toegevoegd aan elk geode dat de Azure-functie-app van de regio fronteert om een krachtigere API-laag te bieden, waardoor bijvoorbeeld aanvullende functionaliteit, zoals snelheidsbeperking, kan worden geïmplementeerd.

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-processor voor de wijzigingsfeed biedt dit gedetailleerde besturingselement met behulp van het concept van de leasecontainer en het leasecollectionprefix in de bijbehorende Azure Functions binding. Elke benadering heeft verschillende voor- en nadelen.
• Geodes kunnen samenwerken, met behulp van de Azure Cosmos DB en een realtime communicatieplatform zoals SignalR. Geodes kunnen communiceren met externe gebruikers via andere geodes in een mesh-patroon, zonder te weten of te weten waar de externe gebruiker zich bevindt.
• Dit ontwerppatroon ontkoppelt impliciet alles, wat resulteert in een zeer gedistribueerde en losgekoppelde architectuur. Denk na over het bijhouden van verschillende onderdelen van dezelfde aanvraag, aangezien deze asynchroon kunnen worden uitgevoerd op verschillende exemplaren. Een juiste bewakingsstrategie is van cruciaal belang. Zowel Azure Front Door als Cosmos DB kunnen 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 ingress-punten waarvoor beveiligingsmaatregelen voor eigenschappen zijn vereist. Key Vault biedt een veilige laag voor geheimbeheer en elke laag in de API-architectuur moet goed worden beveiligd, zodat het enige toegangspunt voor de API de front-endservice is, zoals Azure Front Door. De Cosmos DB moet het verkeer beperken tot de Azure Function-apps en de Functie-apps Azure Front Door met behulp van Azure Active Directory of procedures zoals IP-beperking.
• De prestaties worden drastisch beïnvloed door het aantal geodes dat wordt geïmplementeerd en de specifieke App Service-plannen die worden toegepast op de API-technologie in elke geode. Implementatie van extra geodes of verplaatsing naar Premium-lagen heeft hogere kosten voor het extra geheugen en rekenkracht, maar niet per transactie. Overweeg belastingstests uit te voeren voor de API-architectuur zodra deze is geïmplementeerd en het aantal geodes te contrasteren met het verhogen van de prijscategorie, zodat het meest rendabele model wordt gebruikt voor uw behoeften.
• Bepaal de beschikbaarheidsvereisten voor uw gegevens. Cosmos DB heeft optionele vlaggen voor het inschakelen van schrijf- en beschikbaarheidszones voor meerdere regio's en meer. Deze verhogen de beschikbaarheid voor de Cosmos DB-instantie en zorgen voor een meer flexibele gegevenslaag, maar brengen extra kosten met zich mee.
• Azure biedt diverse load balancers die verschillende functies 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:

• Voor het implementeren van een grootschalige platform waarop gebruikers zijn gedistribueerd over een breed gebied.
• Voor elke service die extreme beschikbaarheids- en tolerantiekenmerken vereist, omdat services op basis van het geode-patroon het verlies van meerdere serviceregio's tegelijkertijd kunnen overleven.

Dit patroon is mogelijk niet geschikt voor

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

Voorbeelden

• Windows Active Directory implementeert een vroege variant van dit patroon. Multi-primaire replicatie betekent dat alle updates en aanvragen in theorie kunnen worden uitgevoerd vanaf alle knooppunten die kunnen worden gebruikt, maar FSMO-rollen (Flexible Single Master Operation) betekenen dat niet alle geodes gelijk zijn.
• De geode-patroonversneller op GitHub laat dit ontwerppatroon in de praktijk zien en is ontworpen om ontwikkelaars te helpen deze te implementeren met echte API's.
• In het artikel Wereldwijd gedistribueerde toepassingen Cosmos DB wordt een geografische implementatie onderzocht die gebruikmaakt van Traffic Manager voor taakverdeling en Azure App Service voor het hosten van de API-code.
• Een QnA-voorbeeldtoepassing op GitHub laat dit ontwerppatroon in de praktijk zien.
• Geode-cache via SAP OData-API's:een voorbeeld van een geode van de OData-API die door Cosmos wordt gebruikt als een wereldwijd versnelde gegevenscache voor SAP Retail-toepassingen.