Patroon voor implementatiestempels

Het Deployment Stamps-patroon richt, beheert en bewaakt een groep resources om meerdere workloads of tenants te hosten en uit te voeren. Elke afzonderlijke kopie wordt een stempel genoemd, of soms een service-eenheid, schaaleenheid of cel. In een omgeving met meerdere tenants dient elke stempel een vooraf gedefinieerd aantal tenants. U implementeert meerdere eenheden om de oplossing bijna lineair te schalen en een toenemend aantal huurders te bedienen. 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

Wanneer u een toepassing in de cloud host, moet u rekening houden met de prestaties en betrouwbaarheid van uw toepassing. Als u één exemplaar van uw oplossing host, zijn de volgende beperkingen mogelijk van toepassing:

• Schaallimieten: Een enkel exemplaar van uw toepassing kan natuurlijke schaallimieten bereiken. De services die u gebruikt, kunnen bijvoorbeeld het aantal binnenkomende verbindingen, hostnamen, TCP-sockets (Transmission Control Protocol) of andere resources beperken.

• 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 kunnen de prestaties dalen of kosten pieken nadat u aan een drempelwaarde hebt voldaan. U kunt bijvoorbeeld merken dat het toevoegen van meer capaciteit aan een database, of omhoog schalen, verboden duur wordt en dat uitschalen rendabeler is.

• Scheiding van klanten: Mogelijk moet u de gegevens van een klant isoleren van de gegevens van een andere klant. Mogelijk hebt u ook klanten die meer systeemresources verbruiken dan andere. U kunt ze groeperen op verschillende sets infrastructuur.

• Instanties met één tenant en meerdere tenants: Sommige grote klanten hebben mogelijk hun eigen onafhankelijke instanties van uw oplossing nodig. Kleinere klanten kunnen een implementatie met meerdere tenants 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: Sommige klanten verdragen frequente updates, terwijl risico-averse klanten niet regelmatig updates willen voor het systeem dat hun aanvragen verwerkt. U kunt deze klanten implementeren in geïsoleerde omgevingen.

• Geografische of geopolitieke beperkingen: Als u een lage latentie wilt bereiken of aan de vereisten voor gegevenssoevereine wilt voldoen, kunt u sommige klanten implementeren in specifieke regio's.

Deze beperkingen gelden vaak voor softwareontwikkelingsbedrijven die Software as a Service (SaaS) bouwen, die ze doorgaans ontwerpen als multitenant. Dezelfde beperkingen kunnen ook van toepassing zijn op andere scenario's.

Solution

U kunt deze problemen voorkomen door resources te groeperen in schaaleenheden en meerdere exemplaren van uw stempels in te richten. Elke schaaleenheid fungeert als host voor een subset van uw tenants. Stempels worden onafhankelijk van elkaar uitgevoerd en u kunt ze onafhankelijk implementeren en bijwerken. Eén geografische regio kan één stempel of meerdere stempels bevatten die horizontaal binnen de regio worden uitgeschaald. Elke stempel dient 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, zodat dit patroon kan helpen bij het uitschalen van iaaS-zware workloads.

U kunt stempels gebruiken om implementatieringen te implementeren. Als verschillende klanten service-updates met verschillende frequenties willen, groepeert u deze op verschillende stempels en implementeert u updates voor elke zegel met een andere frequentie.

Stempels worden onafhankelijk uitgevoerd, zodat ze impliciet uw gegevens sharden . Een enkele postzegel kan intern ook gebruikmaken van sharding om op te schalen en elastisch te blijven.

Het implementeren van identieke kopieën van dezelfde onderdelen is complex, dus goede DevOps-procedures zijn essentieel. Beschrijf uw infrastructuur als code, zodat de implementatie van elke zegel voorspelbaar en herhaalbaar is.

Implementatiestempels hebben betrekking op maar verschillen van geodes. In een implementatiestempelarchitectuur dient elk onafhankelijk exemplaar van uw systeem een subset van uw klanten en gebruikers. In een geode-architectuur kan elk exemplaar aanvragen van elke gebruiker verwerken, maar deze benadering is doorgaans complexer om te ontwerpen en te bouwen. U kunt ook de twee patronen in één oplossing combineren. De benadering voor verkeersroutering die verderop in dit artikel wordt beschreven, is een voorbeeld van een dergelijk hybride scenario.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

• Implementatieproces: Wanneer u meerdere stempels implementeert, automatiseert en herhaalt u uw implementatieprocessen. Gebruik Bicep of Terraform modules om uw stempels declaratief te definiëren en de definities consistent te houden.

• Bewerkingen voor kruisstempels: Wanneer u uw oplossing onafhankelijk van meerdere stempels implementeert, kan het lastig zijn om te bepalen hoeveel klanten u hebt op al uw stempels. Mogelijk moet u een query uitvoeren op elke stempel en de resultaten aggregeren. U kunt ook alle stempels gegevens laten publiceren in een gecentraliseerd datawarehouse voor geconsolideerde rapportage.

• Beleid voor uitschalen: Stempels hebben een eindige capaciteit, die u kunt definiëren met behulp van een proxy-metriek, zoals het aantal huurders dat u op de stempel kunt inzetten. Bewaak de beschikbare en gebruikte capaciteit voor elke stempel en implementeer proactief meer stempels om nieuwe tenants naar hen te leiden.

• Minimum aantal stempels: Wanneer u het patroon Implementatiestempels gebruikt, implementeert u ten minste twee stempels van uw oplossing. Als u slechts één stempel implementeert, kunt u eenvoudig veronderstellingen voor harde code in uw code of configuratie implementeren die niet van toepassing zijn wanneer u uitschaalt.

• Kosten: Met het patroon Implementatiestempels worden meerdere exemplaren van uw infrastructuuronderdelen geïmplementeerd, waardoor de kosten voor het uitvoeren van uw oplossing aanzienlijk worden verhoogd.

• Schakelen tussen stempels: Elke stempel werkt onafhankelijk, waardoor het verplaatsen van huurders tussen stempels lastig kan zijn. Uw toepassing heeft aangepaste logica nodig om de gegevens van een 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 om te communiceren tussen stempels, waardoor de complexiteit van uw oplossing verder toeneemt.

• Verkeersroutering: Zoals eerder in dit artikel is beschreven, kan het routeren van verkeer naar de juiste stempel voor een bepaalde aanvraag een extra onderdeel vereisen waarmee tenants worden omgezet in stempels. Dit onderdeel moet mogelijk ook maximaal beschikbaar zijn.

• Waarneembaarheid tussen stempels: Naarmate het aantal stempels toeneemt, wordt het moeilijker om de algehele status te begrijpen en incidenten snel te detecteren. Gebruik Azure Monitor om metrische gegevens, logboeken, traceringen en waarschuwingen voor alle stempels te verzamelen en correleren. Gebruik deze gegevens om beschadigde stempels te identificeren en problemen vast te stellen.

• Impact van regionale fouten: Stempels worden onafhankelijk uitgevoerd, maar ze zijn niet inherent redundant in verschillende regio's. Als een regio die als host fungeert voor een of meer stempels niet meer beschikbaar is, hebben de tenants op die stempels geen toegang meer totdat de regio herstelt of u migreert de tenants naar stempels in een andere regio. Als u dit scenario wilt plannen, documenteert u uw herstelprocedures, stelt u de verwachtingen van de huurders vast en overweegt u of kritieke huurders geografisch redundante stempelplaatsing nodig hebben.

• Gedeelde onderdelen: Mogelijk hebt u onderdelen die u kunt delen met stempels. Als u bijvoorbeeld een gedeelde app met één pagina voor alle tenants hebt, implementeert u deze in één regio en gebruikt u Azure Front Door edge-caching om deze wereldwijd te repliceren.

• Governance- en configuratiedrift: Naarmate het aantal stempels toeneemt, wordt het moeilijker om beveiligingsbeleid, RBAC-toewijzingen (op rollen gebaseerd toegangsbeheer), netwerkbeheer, waarneembaarheidsinstellingen en serviceconfiguraties consistent te houden. Gebruik Azure Policy om governance te behandelen als code en elke zegel continu te valideren voor afwijkingen om inconsistent gedrag en hiaten in de naleving te voorkomen.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

• Uw oplossing heeft natuurlijke limieten voor schaalbaarheid. Als sommige onderdelen bijvoorbeeld niet meer dan een bepaald aantal klanten of aanvragen kunnen worden geschaald, gebruikt u stempels om uit te schalen.

• U moet bepaalde tenants scheiden van de anderen. Als beveiligingsproblemen voorkomen dat u sommige klanten implementeert in een multitenant-zegel, implementeert u deze op hun eigen geïsoleerde stempel.

• U moet enkele tenants tegelijkertijd hosten in verschillende versies van uw oplossing.

• U bouwt toepassingen met meerdere regio's die de gegevens en het verkeer van elke tenant naar een specifieke regio moeten leiden.

• U wilt tolerantie bereiken tijdens storingen. Stempels worden onafhankelijk uitgevoerd, dus als een storing van invloed is op één stempel, hebben gebruikers op andere stempels hier geen last van. Deze isolatie bevat de explosiestraal van een incident of storing.

Dit patroon is mogelijk niet geschikt wanneer:

• Uw oplossing is eenvoudig en hoeft niet in hoge mate te worden geschaald.

• U kunt uw systeem binnen één exemplaar uitschalen of omhoog schalen, bijvoorbeeld door de grootte van de toepassingslaag te vergroten of door de gereserveerde capaciteit voor databases en de opslaglaag te verhogen.

• U moet gegevens repliceren voor alle geïmplementeerde exemplaren. Houd rekening met het geode-patroon voor dit scenario.

• U hoeft alleen bepaalde onderdelen te schalen en niet andere. Stel dat u uw oplossing kunt schalen door het gegevensarchief te sharden in plaats van een nieuwe kopie van alle oplossingsonderdelen te implementeren.

• Uw oplossing bestaat alleen uit statische inhoud, zoals een front-end JavaScript-toepassing. Lever deze inhoud door een Content Delivery Network.

Werklastontwerp

Evalueer hoe u het patroon "Deployment Stamps" kunt gebruiken in het ontwerp van een workload om de doelstellingen en principes aan te pakken die worden behandeld in de pijlers van het Azure Well-Architected Framework. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Als dit patroon compromissen binnen een pijler introduceert, moet u deze tegen de doelstellingen van de andere pijlers overwegen.

Voorbeeld

In de volgende voorbeeldarchitectuur wordt gebruikgemaakt van Azure Front Door, Azure API Management en Azure Cosmos DB om verkeer wereldwijd te routeren naar een reeks regiospecifieke stempels.

Stel dat een gebruiker zich in New York bevindt. Stempel 3, in de regio VS - oost, slaat hun gegevens op.

Als de gebruiker naar Californië reist en toegang heeft tot het systeem, stuurt het systeem de verbinding door via de regio VS - west 2, omdat die regio zich het dichtst bij hen bevindt wanneer ze de aanvraag indienen. Stamp 3 moet echter uiteindelijk de aanvraag dienen omdat het hun gegevens opslaat. Het verkeersrouteringssysteem stuurt de aanvraag naar de juiste stempel.

Deployment

Beschrijf uw infrastructuur als code met behulp van Bicep of Terraform. Deze aanpak zorgt ervoor dat de implementatie van elke zegel 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. Technologieën zoals Bicep kunnen de implementatie van uw infrastructuur en toepassingen coördineren. U kunt er ook voor kiezen om updates geleidelijk eerst naar bepaalde stempels uit te rollen, en vervolgens dit geleidelijk uit te breiden naar andere stempels. Overweeg het gebruik van een hulpprogramma voor releasebeheer, zoals Azure-pipelines of GitHub Actions , om implementaties voor elke stempel te organiseren.

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

• Normaal gesproken bevat een abonnement alle resources voor een enkele oplossing, dus overweeg om een enkel abonnement te gebruiken voor alle stamps. In somde Azure services gelden echter quota voor het hele abonnement. Als u dit patroon gebruikt om een hoge mate van uitschalen mogelijk te maken, moet u mogelijk stempels implementeren in verschillende abonnementen.

• Resourcegroepen bevatten over het algemeen onderdelen die dezelfde levenscyclus delen. Als u updates voor alle stempels tegelijk wilt implementeren, kunt u één resourcegroep gebruiken die alle onderdelen voor alle stempels bevat. Gebruik resourcenaamconventies en -tags 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 elke zegel ook implementeren in een eigen resourcegroep.

Capaciteitsplanning

Gebruik belasting- en prestatietests om de geschatte belasting te bepalen die een bepaalde stempel kan dragen. Metrieken kunnen zijn gebaseerd op het aantal klanten of huurders dat een enkele eenheid kan huisvesten, of op metrieken die door de services in de eenheid worden uitgegeven. Instrumenteer elke stempel zodat u kunt meten wanneer deze de capaciteit nadert en zorg ervoor dat u snel nieuwe stempels kunt implementeren om te reageren op de vraag.

Verkeersroutering

Het patroon Implementatiestempels werkt goed wanneer u elke zegel afzonderlijk adresseert. Als Contoso bijvoorbeeld dezelfde API-toepassing op meerdere stempels implementeert, kan Contoso Dns (Domain Name System) gebruiken om verkeer naar de relevante stempel 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.

In Azure kunt u deze records hosten in Azure DNS en een consistente subdomeinconventie gebruiken voor elke regio en stempel. Deze aanpak onderhoudt voorspelbare routering en bewerkingen.

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

Als voor uw oplossing één ingangspunt voor al het verkeer is vereist, kunt u een verkeersrouteringsservice gebruiken 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 door een HTTP 302-antwoordstatuscode te retourneren) of fungeert als een omgekeerde proxy en stuurt het verkeer door 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 die stempels host. Synchroniseer daarnaast het gegevensarchief dat tenants aan stempels koppelt. Het verkeersrouteringsonderdeel kan zelf een exemplaar van het geode-patroon zijn.

U kunt BIJVOORBEELD API Management implementeren om te fungeren als de verkeersrouteringsservice. API Management bepaalt het juiste stempel voor een aanvraag door gegevens op te zoeken in een Azure Cosmos DB verzameling waarin de toewijzing tussen tenants en stempels wordt opgeslagen. API Management stelt vervolgens de back-end-URL dynamisch in op de API-service van de relevante zegel.

Voor het geografisch distribueren van aanvragen en het bieden van georedundantie voor de verkeersrouteringsservice implementeer API Management in meerdere regio's en gebruikt u Azure Front Door om verkeer naar de dichtstbijzijnde API Management-gateway te leiden. In deze topologie gebruikt Azure Front Door origin-groepen, health probes en een geschikte routingsmethode om aanvragen weg te routeren van beschadigde regionale API Management-gateways. API Management routeert vervolgens naar de juiste stempel met behulp van de tenant-naar-stempeltoewijzing en de back-endconfiguratie (of back-endpools), inclusief failoverregels tussen stempeleindpunten, indien nodig. Als uw toepassing niet beschikbaar is via HTTP of HTTPS, kunt u een cross-regio Azure load balancer gebruiken om binnenkomende aanroepen te distribueren naar regionale Azure load balancers. Gebruik de globale distributiefunctie van Azure Cosmos DB om de toewijzingsgegevens in elke regio bijgewerkt te houden.

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

Volgende stappen

• Azure Front Door
• Bicep integreren met Azure-pipelines
• JSON ARM-sjablonen integreren met Azure-pipelines

Contributors

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Andere Inzenders:

• Federico Arambarri | Senior softwareontwikkelaar, Clarius Consulting
• Daniel Larsen | Principal Customer Engineer, FastTrack voor Azure
• Angel Lopez | Senior software-engineer, Azure-patronen en -procedures
• Paolo Salvatori | Principal Customer Engineer, FastTrack voor Azure
• Arsen Vladimirskiy | Hoofdklantingenieur, FastTrack voor Azure

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

Gerelateerde bronnen

• U kunt sharding gebruiken als een andere eenvoudigere benadering om uw gegevenslaag uit te schalen. Implementatiestempels voeren automatisch sharding uit van hun gegevens, maar sharding is niet afhankelijk van een implementatiestempel. Zie Sharding-patroon voor meer informatie.
• Als uw oplossing een verkeersrouteringsservice implementeert, kunt u de patronen voor gatewayroutering en gateway-offloading combineren om het beste gebruik te maken van dit onderdeel.