Patroon Implementatiestempels

Het implementatiestempelpatroon omvat het inrichten, beheren en bewaken van een heterogene groep resources voor het hosten en uitvoeren van meerdere workloads of tenants. Elke afzonderlijke kopie wordt een zegel of soms een service-eenheid of schaaleenheid genoemd. In een omgeving met meerdere tenants kan elke zegel of schaaleenheid een vooraf gedefinieerd aantal tenants bedienen. Er kunnen meerdere stempels worden geïmplementeerd om de oplossing bijna lineair te schalen en een toenemend aantal tenants te bedienen. Met deze aanpak kunt u de schaalbaarheid van uw oplossing verbeteren, exemplaren in meerdere regio's implementeren en uw klantgegevens scheiden.

Context en probleem

Bij het hosten van een toepassing in de cloud moeten bepaalde overwegingen worden gemaakt. Een belangrijk ding om rekening mee te houden is de prestaties en betrouwbaarheid van uw toepassing. Als u één exemplaar van uw oplossing host, gelden mogelijk de volgende beperkingen:

• Schaallimieten. Het implementeren van één exemplaar van uw toepassing kan leiden tot natuurlijke schaallimieten. U kunt bijvoorbeeld services gebruiken die limieten hebben voor het aantal binnenkomende verbindingen, hostnamen, TCP-sockets of andere resources.
• Niet-lineaire schaalbaarheid of kosten. Sommige onderdelen van uw oplossing worden mogelijk niet lineair geschaald met het aantal aanvragen of de hoeveelheid gegevens. In plaats daarvan kan er een plotselinge afname van de prestaties of hogere kosten optreden zodra aan een drempelwaarde is voldaan. U kunt bijvoorbeeld een database gebruiken en ontdekken dat de marginale kosten voor het toevoegen van meer capaciteit (omhoog schalen) onbetaalbaar worden en dat uitschalen een rendabeler strategie is. Op dezelfde manier Azure Front Door hogere prijzen per domein wanneer een groot aantal aangepaste domeinen wordt geïmplementeerd en is het wellicht beter om de aangepaste domeinen over meerdere Front Door te spreiden.
• Scheiding van klanten. Mogelijk moet u de gegevens van bepaalde klanten geïsoleerd houden van de gegevens van andere klanten. Op dezelfde manier hebt u mogelijk enkele klanten die meer systeemresources nodig hebben voor de service dan andere, en kunt u overwegen om ze te groeperen op verschillende infrastructuursets.
• Verwerken van exemplaren met één en meerdere tenants. Mogelijk hebt u enkele grote klanten die hun eigen onafhankelijke instanties van uw oplossing nodig hebben. Mogelijk hebt u ook een groep kleinere klanten die een implementatie met meerdere tenants kunnen delen.
• Complexe implementatievereisten. Mogelijk moet u updates voor uw service op een gecontroleerde manier implementeren en op verschillende tijdstippen implementeren in verschillende subsets van uw klantenbestand.
• Frequentie bijwerken. Mogelijk hebt u een aantal klanten die tolerant zijn voor regelmatige updates van uw systeem, terwijl andere mogelijk risico-averse zijn en niet-frequente updates willen voor het systeem dat hun aanvragen afhandelt. Het kan zinvol zijn om deze klanten te laten geïmplementeerd in geïsoleerde omgevingen.
• Geografische of geopolitieke beperkingen. Als u wilt ontwerpen voor lage latentie of om te voldoen aan de vereisten voor gegevenssoevereiniteit, kunt u enkele van uw klanten in specifieke regio's implementeren.

Oplossing

Om deze problemen te voorkomen, kunt u resources groeperen in schaaleenheden en meerdere kopieën van uw stempels inrichten. Elke schaaleenheid zal een subset van uw tenants hosten en bedienen. Stempels werken onafhankelijk van elkaar en kunnen onafhankelijk worden geïmplementeerd en bijgewerkt. Eén geografische regio kan één stempel bevatten of meerdere stempels bevatten om horizontaal uit te schalen binnen de regio. Stempels bevatten een subset van uw klanten.

Implementatiestempels kunnen van toepassing zijn, ongeacht of uw oplossing gebruikmaakt van Infrastructuur als een dienst (IaaS) of platform as a service(PaaS)-onderdelen, of een combinatie van beide. IaaS-workloads vereisen doorgaans meer interventie om te schalen, dus het patroon kan nuttig zijn voor IaaS-zware workloads om uit te schalen.

Stempels kunnen worden gebruikt om implementatieringen te implementeren. Als verschillende klanten service-updates met verschillende frequenties willen ontvangen, kunnen ze worden gegroepeerd op verschillende stempels en kunnen voor elke zegel updates met verschillende frequenties worden geïmplementeerd.

Omdat stempels onafhankelijk van elkaar worden uitgevoerd, worden gegevens impliciet geshard. Bovendien kan één stempel gebruikmaken van verdere sharding om intern schaalbaarheid en elasticiteit binnen de stempel mogelijk te maken.

Het implementatiestempelpatroon wordt intern gebruikt door veel Azure-services, waaronder App Service, Azure Stacken Azure Storage.

Implementatiestempels zijn gerelateerd aan, maar verschillen van, geodes. In een implementatiestempelarchitectuur worden meerdere onafhankelijke exemplaren van uw systeem geïmplementeerd en bevatten ze een subset van uw klanten en gebruikers. In geodes kunnen alle instanties aanvragen van alle gebruikers verwerken, maar deze architectuur is vaak complexer om te ontwerpen en te bouwen. U kunt ook overwegen om de twee patronen binnen één oplossing te combineren; de verkeersrouteringsbenadering die hieronder wordt beschreven, is een voorbeeld van een dergelijk hybride scenario.

Implementatie

Vanwege de complexiteit die betrokken is bij het implementeren van identieke exemplaren van dezelfde onderdelen, zijn goede DevOps-procedures essentieel om succes te garanderen bij het implementeren van dit patroon. U kunt uw infrastructuur beschrijven als code, zoals met behulp van Bicep, JSON Azure Resource Manager-sjablonen (ARM-sjablonen), Terraformen scripts. Met deze methode kunt u ervoor zorgen dat de implementatie van elke zegel voorspelbaar en herhaalbaar is. Het vermindert ook de kans op menselijke fouten, zoals onbedoelde niet-overeenkomende configuraties tussen stempels.

U kunt updates automatisch op alle stempels parallel implementeren. In dat geval kunt u technologieën zoals Resource Manager-sjablonen of Azure Deployment Manager overwegen om de implementatie van uw infrastructuur en toepassingen te coördineren. U kunt er ook voor kiezen om eerst geleidelijk updates voor sommige stempels uit te rollen en vervolgens geleidelijk aan andere. Azure Deployment Manager kunt dit type gefaseeerde implementatie ook beheren, of u kunt overwegen een hulpprogramma voor releasebeheer zoals Azure Pipelines te gebruiken om implementaties voor elke zegel te beheren. Zie voor meer informatie:

• Bicep integreren met Azure Pipelines
• JSON ARM-sjablonen integreren met Azure Pipelines

Overweeg zorgvuldig de topologie van de Azure-abonnementen en -resourcegroepen voor uw implementaties:

• Normaal gesproken bevat een abonnement alle resources voor één oplossing, dus in het algemeen kunt u voor alle stempels één abonnement gebruiken. Sommige Azure-servicesleggen echter quota voor het hele abonnement op, dus als u dit patroon gebruikt om een hoge mate van uitschalen mogelijk te maken, moet u mogelijk overwegen om stempels in verschillende abonnementen te implementeren.
• Resourcegroepen worden over het algemeen gebruikt om onderdelen met dezelfde levenscyclus te implementeren. Als u van plan bent om updates voor al uw stempels tegelijk te implementeren, kunt u overwegen om één resourcegroep te gebruiken om alle onderdelen voor al uw stempels te bevatten en resourcenaamconventie en -tags te gebruiken om de onderdelen te identificeren die bij elke stempel horen. Als u van plan bent om updates voor elke zegel onafhankelijk te implementeren, kunt u ook overwegen om elke zegel in een eigen resourcegroep te implementeren.

Capaciteitsplanning

Gebruik belastings- en prestatietests om de geschatte belasting te bepalen die een bepaalde zegel kan opvangen. Metrische gegevens over de belasting kunnen worden gebaseerd op het aantal klanten/tenants dat met één zegel kan worden gebruikt, of op metrische gegevens van de services die de onderdelen in de zegel kunnen gebruiken. Zorg ervoor dat u voldoende instrumentatie hebt om te meten wanneer een bepaalde zegel de capaciteit nadert en de mogelijkheid om nieuwe stempels snel te implementeren om te reageren op de vraag.

Verkeersroutering

Het patroon Implementatiestempel werkt goed als elke zegel onafhankelijk wordt geadresseerd. Als Contoso bijvoorbeeld dezelfde API-toepassing op meerdere stempels implementeert, kan het worden gebruikt om DNS te gebruiken om verkeer naar de relevante stempel te sturen:

• unit1.aus.myapi.contoso.com routeer verkeer naar een unit1 stempel binnen een Australische regio.
• unit2.aus.myapi.contoso.com routeer verkeer naar een unit2 stempel binnen een Australische regio.
• unit1.eu.myapi.contoso.com routeer verkeer naar een unit1 stempel binnen een Europese regio.

Clients zijn vervolgens verantwoordelijk voor het maken van verbinding met de juiste zegel.

Als één toegangspunt voor al het verkeer is vereist, kan een verkeersrouteringsservice worden gebruikt om de stempel voor een bepaalde aanvraag, klant of tenant om te zetten. De verkeersrouteringsservice stuurt de client naar de relevante URL voor de zegel (bijvoorbeeld met behulp van een HTTP 302-antwoordstatuscode), of kan fungeren als een omgekeerde proxy en het verkeer doorsturen naar de relevante zegel zonder dat de client hiervan op de hoogte is.

Een gecentraliseerde verkeersrouteringsservice kan een complex onderdeel zijn om te ontwerpen, met name wanneer een oplossing wordt uitgevoerd in meerdere regio's. Overweeg de verkeersrouteringsservice te implementeren in meerdere regio's (mogelijk inclusief elke regio waar stempels worden geïmplementeerd) en ervoor te zorgen dat het gegevensopslag (tenants toewijzen aan zegels) wordt gesynchroniseerd. Het verkeersrouteringsonderdeel kan zelf worden gebruikt door een instantie van het geodepatroon.

Azure-API Management bijvoorbeeld worden geïmplementeerd om te handelen in de servicerol verkeersroutering. Het kan de juiste stempel voor een aanvraag bepalen door gegevens op te zoeken in een Cosmos DB de toewijzing tussen tenants en stempels op te slaan. API Management kunt de back-end-URL vervolgens dynamisch instellen op de API-service van de relevante stempel.

Als u geo-distributie van aanvragen en geo-redundantie van de verkeersrouteringsservice wilt inschakelen, kunnen API Managementworden geïmplementeerd in meerdere regio's of Azure Front Door worden gebruikt om verkeer naar het dichtstbijzijnde exemplaar te leiden. Front Door kunnen worden geconfigureerd met een back-API Management,zodat aanvragen kunnen worden omgeleid naar het dichtstbijzijnde beschikbare API Management exemplaar. Als uw toepassing niet beschikbaar is via HTTP/S, kunt u een regio-overschrijdende Azure Load Balancer om binnenkomende aanroepen te distribueren naar regionale Azure Load Balancers. De functie voor wereldwijde distributie van Azure Cosmos DB kan worden gebruikt om de toewijzingsinformatie in elke regio bij te houden.

Als er een verkeersrouteringsservice in uw oplossing is opgenomen, moet u overwegen of deze fungeert als gateway en daarom gateway-offloading kan uitvoeren voor services zoals tokenvalidatie, beperking en autorisatie.

Problemen en overwegingen

U moet de volgende punten overwegen wanneer u besluit hoe u dit patroon wilt implementeren:

• Implementatieproces. Bij het implementeren van meerdere stempels is het raadzaam om geautomatiseerde en volledig herhaalbare implementatieprocessen te hebben. Overweeg bicep-, JSON ARM-sjablonenof Terraform-modules te gebruiken om de zegel declaratief te definiëren.
• Bewerkingen voor kruisstempels. Wanneer uw oplossing onafhankelijk wordt geïmplementeerd op meerdere stempels, vragen zoals 'hoeveel klanten hebben we voor al onze zegels?' kan complexer worden om te beantwoorden. Query's moeten mogelijk worden uitgevoerd op elke stempel en de resultaten worden geaggregeerd. U kunt ook overwegen om alle stempels gegevens te laten publiceren in een gecentraliseerd datawarehouse voor geconsolideerde rapportage.
• Het bepalen van beleid voor uitschalen. Stempels hebben een eindige capaciteit, die kan worden gedefinieerd met behulp van proxymetrische gegevens, zoals het aantal tenants dat op de zegel kan worden geïmplementeerd. Het is belangrijk om de beschikbare capaciteit en gebruikte capaciteit voor elke zegel te bewaken en proactief extra stempels te implementeren zodat nieuwe tenants er naar kunnen worden omgeleid.
• Kosten. Het implementatiestempelpatroon omvat het implementeren van meerdere exemplaren van uw infrastructuuronderdeel, wat waarschijnlijk een aanzienlijke toename van de kosten voor het gebruik van uw oplossing met zich meebrengt.
• Verplaatsen tussen stempels. Omdat elke zegel onafhankelijk wordt geïmplementeerd en uitgevoerd, kan het moeilijk zijn om tenants tussen stempels te verplaatsen. Uw toepassing heeft aangepaste logica nodig om de informatie over een bepaalde klant naar een andere zegel te verzenden en vervolgens de gegevens van de tenant uit de oorspronkelijke zegel te verwijderen. Dit proces vereist mogelijk een backplane voor communicatie tussen stempels, waardoor de algehele oplossing complexer wordt.
• Verkeersroutering. Zoals hierboven beschreven, kan het routeren van verkeer naar de juiste stempel voor een bepaalde aanvraag een extra onderdeel vereisen om tenants om te zetten in stempels. Dit onderdeel moet op zijn beurt mogelijk zeer beschikbaar worden gemaakt.
• Gedeelde onderdelen. Mogelijk hebt u een aantal onderdelen die kunnen worden gedeeld met andere stempels. Als u bijvoorbeeld een gedeelde app met één pagina voor alle tenants hebt, kunt u overwegen deze in één regio te implementeren en Azure CDN te repliceren.

Wanneer dit patroon gebruiken

Dit patroon is handig wanneer u het volgende hebt:

• Natuurlijke limieten voor schaalbaarheid. Als sommige onderdelen bijvoorbeeld niet kunnen of moeten worden geschaald tot een bepaald aantal klanten of aanvragen, kunt u overwegen uit te schalen met behulp van zegels.
• Een vereiste om bepaalde tenants van anderen te scheiden. Als u klanten hebt die niet kunnen worden geïmplementeerd in een zegel met meerdere tenants met andere klanten vanwege beveiligingsproblemen, kunnen ze worden geïmplementeerd op hun eigen geïsoleerde zegel.
• Een behoefte aan een aantal tenants in verschillende versies van uw oplossing op hetzelfde moment.
• Toepassingen voor meerdere regio's waarbij de gegevens en het verkeer van elke tenant naar een specifieke regio moeten worden omgeleid.
• Een wens om tolerantie te bereiken tijdens uitval. Omdat stempels onafhankelijk van elkaar zijn, mogen de tenants die op andere stempels zijn geïmplementeerd, niet worden beïnvloed als een storing van invloed is op één zegel. Deze isolatie helpt om de 'radius' van een incident of storing in te houden.

Dit patroon is niet geschikt voor:

• Eenvoudige oplossingen die niet naar een hoge mate hoeven te worden geschaald.
• Systemen die eenvoudig kunnen worden uit- of omhoog geschaald binnen één instantie, bijvoorbeeld door de toepassingslaag te vergroten of door de gereserveerde capaciteit voor databases en de opslaglaag te vergroten.
• Oplossingen waarin gegevens moeten worden gerepliceerd in alle geïmplementeerde exemplaren. Houd rekening met het geodepatroon voor dit scenario.
• Oplossingen waarin slechts enkele onderdelen moeten worden geschaald, maar andere niet. Denk bijvoorbeeld na of uw oplossing kan worden geschaald door sharding van het gegevensopslag in plaats van een nieuwe kopie van alle oplossingsonderdelen te implementeren.
• Oplossingen bestaan uitsluitend uit statische inhoud, zoals een front-end JavaScript-toepassing. Overweeg dergelijke inhoud op te slaan in een opslagaccount en gebruik Azure CDN.

Ondersteunende technologieën

• Infrastructuur als code. U kunt bijvoorbeeld Resource Manager, Azure CLI, Terraform, PowerShell, Bash.
• Deployment Manager,waarmee implementaties van een oplossing op meerdere stempels kunnen worden geïmplementeerd.
• Azure Front Door,waarmee verkeer naar een specifieke stempel of naar een verkeersrouteringsservice kan worden doorgeleid.

Voorbeeld

In het volgende voorbeeld worden meerdere stempels van een eenvoudige PaaS-oplossing geïmplementeerd, met een app-service en een SQL Database in elke stempel. Hoewel stempels kunnen worden geconfigureerd in elke regio die ondersteuning biedt voor de services die in de sjabloon zijn geïmplementeerd, implementeert deze sjabloon ter illustratie twee stempels in de regio VS - west 2 en een extra zegel in de Europa - west regio. Binnen een stempel ontvangt de app-service een eigen openbare DNS-hostnaam en kan deze onafhankelijk van alle andere stempels verbindingen ontvangen.

Klik op de onderstaande koppeling om de oplossing te implementeren.

Voorbeeld van verkeersrouteringsbenadering

In het volgende voorbeeld wordt een implementatie geïmplementeerd van een verkeersrouteringsoplossing die kan worden gebruikt met een set implementatiestempels voor een hypothetische API-toepassing. Om geografische distributie van binnenkomende aanvragen mogelijk te maken, Front Door geïmplementeerd naast meerdere exemplaren van API Management in de verbruikslaag. Elk API Management leest de tenant-id van de aanvraag-URL en zoekt vervolgens de relevante stempel voor de aanvraag op uit een geografisch gedistribueerd Cosmos DB gegevensopslag. De aanvraag wordt vervolgens doorgestuurd naar de relevante back-endstempel.

Klik op de onderstaande koppeling om de oplossing te implementeren.

Verwante informatie

• Sharding kan worden gebruikt als een andere, eenvoudigere benadering voor het uitschalen van uw gegevenslaag. Stempels sharden impliciet hun gegevens, maar voor sharding is geen implementatiestempel vereist. Zie het Sharding-patroon voor meer informatie.
• Als er een verkeersrouteringsservice wordt geïmplementeerd, kunnen de patronen gatewayroutering en gateway-offloading samen worden gebruikt om optimaal gebruik te maken van dit onderdeel.