Patroon Implementatiestempels

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

Context en probleem

Bij het hosten van een toepassing in de cloud is het belangrijk om rekening te houden met de prestaties en betrouwbaarheid van uw toepassing. Als u één exemplaar van uw oplossing host, is het mogelijk dat u de volgende beperkingen ondervindt:

• 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-lineair schalen 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 een toename van de 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) verboden worden en dat uitschalen een rendabelere strategie is.
• 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 u kunt overwegen deze te groeperen op verschillende sets infrastructuur.
• Het verwerken van instanties 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 multitenant-implementatie 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.
• Updatefrequentie. Mogelijk hebt u een aantal klanten die tolerant zijn voor frequente updates voor uw systeem, terwijl andere mogelijk risico-averse zijn en onregelmatige updates willen uitvoeren voor het systeem dat hun aanvragen services. Het kan zinvol zijn om deze klanten te laten implementeren in geïsoleerde omgevingen.
• Geografische of geopolitieke beperkingen. Als u wilt ontwerpen voor lage latentie of om te voldoen aan vereisten voor gegevenssoevereine, kunt u enkele van uw klanten implementeren in specifieke regio's.

Deze beperkingen zijn vaak van toepassing op onafhankelijke softwareleveranciers (ISV's) die Software as a Service (SaaS) bouwen, die vaak zijn ontworpen om meerdere tenants te gebruiken. Dezelfde beperkingen kunnen echter ook van toepassing zijn op andere scenario's.

Oplossing

U kunt deze problemen voorkomen door resources te groeperen in schaaleenheden en meerdere exemplaren van uw stempels in te richten. Elke schaaleenheid host en levert een subset van uw tenants. Stempels werken onafhankelijk van elkaar en kunnen onafhankelijk worden geïmplementeerd en bijgewerkt. Een enkele geografische regio kan één stempel bevatten of meerdere stempels bevatten om horizontaal uitschalen binnen de regio mogelijk te maken. Stempels bevatten een subset van uw klanten.

Implementatiestempels kunnen van toepassing zijn of uw oplossing infrastructuur als een dienst (IaaS) of PaaS-onderdelen (Platform as a Service) of een combinatie van beide gebruikt. IaaS-workloads vereisen doorgaans meer tussenkomst om te schalen, dus het patroon kan nuttig zijn voor iaaS-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 kan elke zegel updates op verschillende frequenties hebben 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 patroon implementatiestempel wordt intern gebruikt door veel Azure-services, waaronder App Service, Azure Stack en 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 exemplaren 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 benadering voor verkeersroutering die verderop in dit artikel wordt beschreven, is een voorbeeld van een dergelijk hybride scenario.

Implementatie

Vanwege de complexiteit die betrokken is bij het implementeren van identieke kopieën van dezelfde onderdelen, zijn goede DevOps-procedures essentieel om te zorgen voor succes bij het implementeren van dit patroon. Overweeg om uw infrastructuur als code te beschrijven, zoals met bicep, JSON Azure Resource Manager-sjablonen (ARM-sjablonen), Terraform en scripts. Met deze aanpak kunt u ervoor zorgen dat de implementatie van elke stempel voorspelbaar en herhaalbaar is. Het vermindert ook de kans op menselijke fouten, zoals onbedoelde niet-overeenkomende fouten in de configuratie tussen stempels.

U kunt updates automatisch implementeren voor alle stempels parallel. In dat geval kunt u technologieën zoals Bicep - of Resource Manager-sjablonen overwegen om de implementatie van uw infrastructuur en toepassingen te coördineren. U kunt er ook voor kiezen om eerst updates voor sommige stempels geleidelijk uit te rollen en vervolgens geleidelijk aan anderen uit te rollen. Overweeg het gebruik van een hulpprogramma voor releasebeheer, zoals Azure Pipelines of GitHub Actions , om implementaties voor elke stempel te organiseren. 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:

• Doorgaans bevat een abonnement alle resources voor één oplossing, dus over het algemeen kunt u overwegen om één abonnement te gebruiken voor alle stempels. Sommige Azure-services leggen echter quota voor het hele abonnement op, dus als u dit patroon gebruikt om een hoge mate van uitschalen mogelijk te maken, moet u 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 resourcenaamconventies en tags te gebruiken om de onderdelen te identificeren die bij elke stempel horen. Als u van plan bent om updates voor elke zegel afzonderlijk te implementeren, kunt u ook overwegen om elke zegel in een eigen resourcegroep te implementeren.

Capaciteitsplanning

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

Verkeersroutering

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

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

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

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

Een gecentraliseerde verkeersrouteringsservice kan een complex onderdeel zijn om te ontwerpen, met name wanneer een oplossing wordt uitgevoerd in meerdere regio's. Overweeg om de verkeersrouteringsservice in meerdere regio's te implementeren (mogelijk inclusief elke regio waarin stempels worden geïmplementeerd) en ervoor te zorgen dat het gegevensarchief (toewijzing van tenants aan stempels) wordt gesynchroniseerd. Het verkeersrouteringsonderdeel kan zelf een exemplaar van het geode-patroon zijn.

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

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

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

Voorbeeld van verkeersrouteringsarchitectuur

Bekijk de volgende voorbeeldarchitectuur voor verkeersroutering, die gebruikmaakt van Azure Front Door, Azure API Management en Azure Cosmos DB voor wereldwijde verkeersroutering en vervolgens een reeks regiospecifieke stempels:

Stel dat een gebruiker zich normaal gesproken in New York bevindt. Hun gegevens worden opgeslagen in de stempel 3, in de regio VS - oost.

Als de gebruiker naar Californië reist en vervolgens toegang krijgt tot het systeem, wordt de verbinding waarschijnlijk gerouteerd via de regio VS - west 2, omdat deze zich het dichtst bij de locatie bevindt waar ze zich geografisch bevinden wanneer ze de aanvraag indienen. De aanvraag moet echter uiteindelijk worden verwerkt met stempel 3, omdat daar hun gegevens worden opgeslagen. Het verkeersrouteringssysteem zorgt ervoor dat de aanvraag wordt gerouteerd naar de juiste stempel.

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 om Bicep-, JSON ARM-sjablonen of Terraform-modules te gebruiken om uw stempels declaratief te definiëren en om de definities consistent te houden.
• Kruisstempelbewerkingen. Wanneer uw oplossing onafhankelijk van meerdere stempels wordt geïmplementeerd, kunnen vragen zoals 'hoeveel klanten hebben we in al onze stempels?' 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 publiceren in een gecentraliseerd datawarehouse voor geconsolideerde rapportage.
• Het bepalen van scale-outbeleid. Stempels hebben een eindige capaciteit, die kan worden gedefinieerd met behulp van een metrische proxygegevens, zoals het aantal tenants dat kan worden geïmplementeerd op de stempel. Het is belangrijk om de beschikbare capaciteit en de gebruikte capaciteit voor elke stempel te bewaken en proactief extra stempels te implementeren om nieuwe tenants naar hen te sturen.
• Minimum aantal stempels. Wanneer u het patroon Implementatiestempel gebruikt, is het raadzaam ten minste twee stempels van uw oplossing te implementeren. Als u slechts één stempel implementeert, is het eenvoudig om per ongeluk aannames voor harde code in uw code of configuratie te implementeren die niet van toepassing zijn wanneer u uitschaalt.
• Kosten. Het implementatiestempelpatroon omvat het implementeren van meerdere kopieën van uw infrastructuuronderdeel, wat waarschijnlijk een aanzienlijke toename van de kosten van het uitvoeren van uw oplossing omvat.
• Schakelen tussen stempels. Elke stempel wordt onafhankelijk geïmplementeerd en beheerd, zodat het verplaatsen van tenants tussen stempels lastig kan zijn. Uw toepassing heeft aangepaste logica nodig om de informatie over een bepaalde klant naar een andere stempel te verzenden en vervolgens de gegevens van de tenant uit de oorspronkelijke stempel te verwijderen. Dit proces vereist mogelijk een backplane voor communicatie tussen stempels, waardoor de complexiteit van de algehele oplossing verder wordt verhoogd.
• Verkeersroutering. Zoals eerder in dit artikel is beschreven, kan het doorsturen van verkeer naar de juiste stempel voor een bepaalde aanvraag een extra onderdeel vereisen om tenants om te lossen op stempels. Dit onderdeel moet mogelijk maximaal beschikbaar worden gesteld.
• Gedeelde onderdelen. Mogelijk hebt u enkele onderdelen die kunnen worden gedeeld via stempels. Als u bijvoorbeeld een gedeelde app met één pagina voor alle tenants hebt, kunt u overwegen dat te implementeren in één regio en Azure CDN te gebruiken om deze wereldwijd te repliceren.

Wanneer dit patroon gebruiken

Dit patroon is handig wanneer u het volgende hebt:

• Natuurlijke limieten voor schaalbaarheid. Als sommige onderdelen bijvoorbeeld niet meer dan een bepaald aantal klanten of aanvragen kunnen worden geschaald, kunt u overwegen om uit te schalen met behulp van stempels.
• Een vereiste om bepaalde tenants van anderen te scheiden. Als u klanten hebt die niet kunnen worden geïmplementeerd in een multitenant-stempel met andere klanten vanwege beveiligingsproblemen, kunnen ze worden geïmplementeerd op hun eigen geïsoleerde stempel.
• Een aantal tenants op verschillende versies van uw oplossing tegelijk moeten hebben.
• Toepassingen met meerdere regio's waar de gegevens en het verkeer van elke tenant moeten worden omgeleid naar een specifieke regio.
• Een wens om tolerantie te bereiken tijdens storingen. Als stempels onafhankelijk van elkaar zijn, geldt dat als een storing van invloed is op één stempel, de tenants die op andere stempels zijn geïmplementeerd, niet worden beïnvloed. Deze isolatie helpt bij het bevatten van de 'straalstraal' van een incident of storing.

Dit patroon is niet geschikt voor:

• Eenvoudige oplossingen die niet in hoge mate hoeven te worden geschaald.
• Systemen die eenvoudig kunnen worden uitgeschaald of omhoog kunnen worden geschaald binnen één exemplaar, zoals door de grootte van de toepassingslaag te vergroten of door de gereserveerde capaciteit voor databases en de opslaglaag te verhogen.
• Oplossingen waarin gegevens moeten worden gerepliceerd in alle geïmplementeerde exemplaren. Houd rekening met het geode-patroon voor dit scenario.
• Oplossingen waarin slechts enkele onderdelen moeten worden geschaald, maar niet andere. U kunt bijvoorbeeld overwegen of uw oplossing kan worden geschaald door het gegevensarchief te sharden in plaats van een nieuwe kopie van alle oplossingsonderdelen te implementeren.
• Oplossingen die uitsluitend bestaan uit statische inhoud, zoals een front-end JavaScript-toepassing. U kunt dergelijke inhoud opslaan in een opslagaccount en Azure CDN gebruiken.

Workloadontwerp

Een architect moet evalueren hoe het patroon Implementatiestempels 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.

Ondersteunende technologieën

• Infrastructuur als code. Bijvoorbeeld Bicep, Resource Manager-sjablonen, Azure CLI, Terraform, PowerShell, Bash.
• Azure Front Door, waarmee verkeer naar een specifieke stempel of naar een verkeersrouteringsservice kan worden gerouteerd.

Opmerking

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 voor illustratiedoeleinden twee stempels binnen de regio VS - west 2 en een verdere stempel in de regio Europa - west. Binnen een stempel ontvangt de app-service zijn eigen openbare DNS-hostnaam en kan deze verbindingen onafhankelijk van alle andere stempels 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. Front Door wordt geïmplementeerd naast meerdere exemplaren van API Management in de verbruikslaag om geografische distributie van binnenkomende aanvragen mogelijk te maken. Elke API Management-instantie leest de tenant-id uit de aanvraag-URL en zoekt vervolgens de relevante stempel voor de aanvraag op uit een geografisch gedistribueerd Azure Cosmos DB-gegevensarchief. De aanvraag wordt vervolgens doorgestuurd naar de relevante back-endstempel.

Klik op de onderstaande koppeling om de oplossing te implementeren.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• John Downs | Principal Program Manager

Andere Inzenders:

• Daniel Larsen | Principal Customer Engineer, FastTrack voor Azure
• Angel Lopez | Senior software-engineer, Azure-patronen en -procedures
• Paulo Salvatori | Principal Customer Engineer, FastTrack voor Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Verwante resources

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