Patroon implementatiestempels

Front Door
Azure

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 vrijwel 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 moeten er bepaalde overwegingen worden gemaakt. Een belangrijk ding om in gedachten te houden, is de prestaties en betrouwbaarheid van uw toepassing. Als u één exemplaar van uw oplossing host, hebt u 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-lineair schalen of kosten. Sommige onderdelen van uw oplossing kunnen niet lineair worden geschaald met het aantal aanvragen of de hoeveelheid gegevens. In plaats daarvan kan er sprake zijn van een plotselinge afname van de prestaties of een toename van de kosten 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. Op dezelfde manier heeft Azure Front Door hogere prijzen per domein wanneer een groot aantal aangepaste domeinen wordt geïmplementeerd en is het misschien beter om de aangepaste domeinen over meerdere Front Door-exemplaren te verspreiden.
  • 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 overweeg ze te groeperen op verschillende sets infrastructuur.
  • Het verwerken van exemplaren met één tenant en meerdere tenants. Mogelijk hebt u een aantal grote klanten die hun eigen onafhankelijke exemplaren 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 momenten implementeren in verschillende subsets van uw klantenbestand.
  • Updatefrequentie. Mogelijk hebt u een aantal klanten die tolerant zijn voor frequente updates voor uw systeem, terwijl anderen risico-averse zijn en onregelmatige updates willen 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.

Oplossing

U kunt deze problemen voorkomen door resources in schaaleenheden te groeperen 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. Eén 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.

An example set of deployment stamps

Implementatiestempels kunnen van toepassing zijn of uw oplossing gebruikmaakt van IaaS-onderdelen (Infrastructure as a Service) of PaaS-onderdelen (Platform as a Service), of een combinatie van beide. Voor IaaS-workloads is doorgaans meer interventie vereist om te schalen, dus het patroon kan handig zijn voor IaaS-workloads om uit te schalen.

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

Omdat stempels onafhankelijk van elkaar worden uitgevoerd, worden gegevens impliciet sharded. 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 voor het ontwerpen en bouwen. U kunt ook overwegen om de twee patronen binnen één oplossing te combineren; de hieronder beschreven verkeersrouteringsbenadering 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 door Bicep, JSON Azure Resource Manager-sjablonen (ARM-sjablonen), Terraform en scripts te gebruiken. 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 updates geleidelijk eerst uit te rollen op sommige stempels en vervolgens geleidelijk aan anderen. 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:

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

  • Normaal gesproken bevat een abonnement alle resources voor één oplossing, dus over het algemeen kunt u overwegen om één abonnement voor alle stempels te gebruiken. 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 mogelijk overwegen om stempels voor verschillende abonnementen te implementeren.
  • Resourcegroepen worden over het algemeen gebruikt voor het implementeren van onderdelen met dezelfde levenscyclus. 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 onafhankelijk 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 zijn mogelijk gebaseerd op het aantal klanten/tenants dat door éé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 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.

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

Als één ingangspunt voor al het verkeer vereist is, kan een verkeersrouteringsservice worden gebruikt om de stempel voor een bepaalde aanvraag, klant of tenant op te lossen. De verkeersrouteringsservice stuurt de client naar de relevante URL voor de stempel (bijvoorbeeld met behulp van een HTTP 302-antwoordstatuscode) of kan fungeren als een omgekeerde proxy en het verkeer doorsturen naar de relevante stempel, zonder dat de client zich 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 te implementeren in meerdere regio's (mogelijk inclusief elke regio waarin stempels worden geïmplementeerd) en vervolgens ervoor te zorgen dat het gegevensarchief (toewijzing van tenants aan stempels) wordt gesynchroniseerd. Het verkeersrouteringsonderdeel kan zich voordoen door een instantie van het geode-patroon.

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

Om geodistributie van aanvragen en georedundantie van de verkeersrouteringsservice mogelijk te maken, kan API Management worden geïmplementeerd in meerdere regio's, of Azure Front Door kan worden gebruikt om verkeer naar het dichtstbijzijnde exemplaar te leiden. Front Door kan worden geconfigureerd met een back-endpool, zodat aanvragen kunnen worden doorgestuurd naar de dichtstbijzijnde beschikbare API Management-instantie. Als uw toepassing niet beschikbaar is via HTTP/S, kunt u een regiooverschrijdende Azure Load Balancer gebruiken om binnenkomende oproepen 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, moet 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:

Example traffic routing architecture

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 heeft 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 geleverd met stempel 3, omdat daar hun gegevens worden opgeslagen. Het verkeersrouteringssysteem zorgt ervoor dat de aanvraag wordt doorgestuurd 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 geautomatiseerde en volledig herhaalbare implementatieprocessen te hebben. Overweeg om Bicep-, JSON ARM-sjablonen of Terraform-modules te gebruiken om het stempel declaratief te definiëren.
  • 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 antwoord te geven. Query's moeten mogelijk worden uitgevoerd op basis van elke stempel en de resultaten die zijn geaggregeerd. U kunt ook overwegen om alle stempels gegevens te publiceren in een gecentraliseerd datawarehouse voor geconsolideerde rapportage.
  • Het bepalen van uitschaalbeleid. Stempels hebben een eindige capaciteit, die kan worden gedefinieerd met behulp van een metrische proxygegevens, zoals het aantal tenants dat op de stempel 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 om nieuwe tenants naar hen te sturen.
  • Minimum aantal stempels. Wanneer u het patroon Implementatiestempel gebruikt, is het raadzaam om ten minste twee stempels van uw oplossing te implementeren. Als u slechts één stempel implementeert, is het eenvoudig om per ongeluk aannames van 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. Dit leidt waarschijnlijk tot een aanzienlijke toename van de kosten voor het uitvoeren van uw oplossing.
  • Schakelen tussen stempels. Wanneer elke stempel onafhankelijk wordt geïmplementeerd en beheerd, kan het lastig zijn om tenants tussen stempels te verplaatsen. 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 hierboven beschreven, kan het routeren van verkeer naar de juiste stempel voor een bepaalde aanvraag een extra onderdeel vereisen om tenants om te lossen op stempels. Dit onderdeel moet op zijn beurt 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 deze implementeren in één regio en Azure CDN 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 schalen, 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 multitenantstempel 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 waarbij de gegevens en het verkeer van elke tenant moeten worden omgeleid naar een specifieke regio.
  • Een verlangen om tolerantie te bereiken tijdens storingen. Als stempels onafhankelijk zijn van elkaar, als een storing van invloed is op één stempel, mogen de tenants die op andere stempels zijn geïmplementeerd, niet worden beïnvloed. Deze isolatie helpt bij het bevatten van de 'straal van een explosie' 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. Overweeg het geode-patroon voor dit scenario.
  • Oplossingen waarin slechts enkele onderdelen moeten worden geschaald, maar niet andere. Overweeg bijvoorbeeld 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. Overweeg om dergelijke inhoud op te slaan in een opslagaccount en Azure CDN te gebruiken.

Ondersteunende technologieën

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

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, worden voor illustratiedoeleinden twee stempels geïmplementeerd in 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.

Waarschuwing

In het onderstaande voorbeeld wordt een SQL Server administratoraccount gebruikt. Het is over het algemeen geen goede gewoonte om een beheerdersaccount van uw toepassing te gebruiken. Voor een echte toepassing kunt u een beheerde identiteit gebruiken om vanuit uw toepassing verbinding te maken met een SQL-database of een account met minimale bevoegdheden te gebruiken.

Klik op de onderstaande koppeling om de oplossing te implementeren.

Deploy to Azure

Notitie

Er zijn alternatieve methoden voor het implementeren van stempels met een Resource Manager-sjabloon, waaronder het gebruik van geneste sjablonen of gekoppelde sjablonen om de definitie van elke stempel los te koppelen van de iteratie die nodig is om meerdere exemplaren 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 Cosmos DB-gegevensarchief. De aanvraag wordt vervolgens doorgestuurd naar de relevante back-endstempel.

Klik op de onderstaande koppeling om de oplossing te implementeren.

Deploy to Azure

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