Compute voor SaaS-workloads in Azure
Uw SaaS-toepassing (Software as a Service) moet worden uitgevoerd op een rekenplatform. Net als andere onderdelen in uw architectuur moet deze voldoen aan de bedrijfsvereisten en worden ontworpen op basis van uw bedrijfsmodel. De keuze van het rekenplatform is een belangrijke ontwerpbeslissing. Uw beslissing is van invloed op klantisolatie, prestaties en tolerantie, en uw rekenplatform heeft invloed op de schaal en groei van uw hele SaaS-oplossing.
In dit artikel worden de overwegingen beschreven voor het kiezen van uw hostingmodel, de operationele aspecten van dat model en het optimaliseren van de technologieopties om u te helpen voldoen aan uw SLA's (Service Level Agreements) en serviceniveaudoelstellingen (SLO's).
Een rekenplatform selecteren
Het kiezen van het juiste rekenplatform voor uw SaaS-workload is belangrijk, maar de overvloed aan beschikbare opties kan de keuze overweldigend maken. Het beste platform is afhankelijk van factoren zoals toepassingsarchitectuur, schaal, prestatiebehoeften en het tenantisolatiemodel. Wat optimaal is voor één toepassing, is mogelijk niet voor een andere toepassing.
Ontwerpoverwegingen
Hostingmodel. Azure biedt verschillende hostingmodellen, voornamelijk IaaS (Infrastructure as a Service) en PaaS (Platform as a Service), elk met zijn eigen voordelen en compromissen. Evalueer de vereisten van uw toepassing en kies het meest geschikte model.
IaaS biedt virtuele machines (VM's) en volledige controle over deze machines, inclusief netwerken en opslag. Hiervoor is echter het beheren en patchen vereist, wat operationeel intensief kan zijn. Voorbeelden hiervan zijn schaalsets voor virtuele machines en AKS-clusters (Azure Kubernetes Service).
Met PaaS kunt u toepassingen implementeren zonder de onderliggende infrastructuur te beheren. Het bevat ingebouwde functies voor automatisch schalen en taakverdeling. Voorbeelden zijn Azure-app Service en Azure Container Apps.
PaaS-services bieden minder controle in vergelijking met IaaS, wat problematisch kan zijn als uw toepassing een specifieke configuratie nodig heeft. Uw toepassing kan bijvoorbeeld worden uitgevoerd op een besturingssysteem dat niet door de PaaS-service wordt ondersteund.
Type werkbelasting. Sommige platforms zijn gespecialiseerd voor specifieke workloads, terwijl andere veelzijdig zijn. App Service is bijvoorbeeld ontworpen voor webtoepassingen, terwijl AKS algemener is. Het kan web-apps, AI-workloads en batch-rekentaken hosten.
Ontwikkel teamexpertise. Grote wijzigingen kunnen lastig zijn als het team geen ervaring heeft met het nieuwe platform. Beoordeel de vaardigheden van uw team en koppel deze aan uw platformvereisten. Begin met een eenvoudig platform en ontwikkel geleidelijk uw architectuur in plaats van rechtstreeks naar een geavanceerdere optie te springen.
Als u bijvoorbeeld een containertoepassing bouwt, begint u met Container Apps voor eenvoudig beheer. Naarmate uw behoeften complexer worden, kunt u overstappen naar AKS wanneer u het platform na verloop van tijd beter begrijpt.
Beheeroverhead. Rekenplatforms verdelen de overhead en controle. Meer beheerverantwoordelijkheid die van uw team is verschoven, betekent minder controle over het platform.
IaaS biedt bijvoorbeeld hoge controle over VM's, maar wordt geleverd met aanzienlijke overhead. Als uw toepassing is geïmplementeerd in de omgeving van een klant, hebt u mogelijk beperkte toegang voor beheerbewerkingen. Beoordeel of deze compromissen acceptabel en haalbaar zijn.
Prestatievereisten. Inzicht in de prestatievereisten van uw toepassing door cpu, geheugen, netwerk te modelleren, inclusief bandbreedte en latentie, GPU en beschikbaarheidsbehoeften. U moet ook rekening houden met toekomstige groei. Gebruik deze informatie om de juiste rekenresources te kiezen, zoals de reeks en grootte van VM's. Mogelijk moet u ook specifieke regio's selecteren die ondersteuning bieden voor bepaalde VM-reeksen om te voldoen aan gespecialiseerde vereisten.
Betrouwbaarheidsvereisten. Houd rekening met de betrouwbaarheidsfuncties van uw rekenplatform en zorg ervoor dat ze voldoen aan uw betrouwbaarheidsdoelen. Mogelijk moet u specifieke servicelagen gebruiken om meerdere exemplaren van uw oplossing te hebben of te implementeren in beschikbaarheidszones voor verbeterde betrouwbaarheid.
Raadpleeg RE:04-aanbevelingen voor het definiëren van betrouwbaarheidsdoelen.
Toepassingsbeveiliging en -naleving. Evalueer de beveiligingsfuncties en nalevingscertificeringen van elk rekenplatform om ervoor te zorgen dat ze aan uw behoeften voldoen. Als u bijvoorbeeld uitgaand verkeer wilt bewaken en filteren, moet u mogelijk specifieke rekenservices of -lagen kiezen.
Ontwerpaanaanvelingen
| Aanbeveling | Voordeel |
|---|---|
| Evalueer de rekenprestatievereisten door de schaaldimensies cpu, geheugen, netwerk en GPU te schatten. Voer belastingstests uit om nauwkeurigere gegevens te verzamelen om uw modelleringsoefening te informeren. |
Met deze taken kunt u de juiste grootte voor uw rekenplatform selecteren en op de juiste manier schalen wanneer de belasting van het systeem toeneemt. |
| Evalueer de bekwaamheid van uw team en begin met het minst complexe platform dat voldoet aan uw behoeften of een platform waarmee het team al bekend is. | U zorgt voor soepelere bewerkingen en vermijd overbelasting van uw team door een rekenplatform te kiezen waarmee ze bekend zijn. |
| Wees flexibel in uw ontwerp. Richt u op een oplossing die u na verloop van tijd kunt herhalen om zich aan te passen aan veranderende bedrijfs- en technische vereisten. | Dankzij flexibiliteit kunt u zich gemakkelijker aanpassen aan wijzigingen en verbeteringen in de loop van de tijd. U kunt effectief reageren op veranderende bedrijfs- en technische behoeften. |
| Evalueer de totale eigendomskosten (TCO), inclusief de kosten voor het uitvoeren van de oplossing. | U hebt een duidelijk inzicht in de kosten, wat cruciaal is bij het plannen van uw prijsmodel en het garanderen van rendabele bewerkingen. |
| Beoordeel of u specifieke rekenplatforms moet gebruiken vanwege uw technologiestack. Sommige rekenplatforms zijn beter geschikt voor bepaalde programmeertalen, hulpprogramma's en besturingssystemen. Streven naar het gebruik van platforms die systeemeigen ondersteuning bieden voor uw technologiekeuzes. | U vermijdt de kosten voor het opnieuw ontwerpen van uw architectuur, zoals migreren naar een nieuw platform. |
| Evalueer de betrouwbaarheidsfuncties van het platform en factor de garanties van uw cloudserviceprovider in uw SLO's. | U vermindert het risico op gelokaliseerde datacentrumstoringen door te plannen voor betrouwbaarheidsfuncties en beschikbaarheidszones te gebruiken als deze beschikbaar zijn. |
Tenancymodel en isolatie
Uw SaaS-bedrijfsmodel bepaalt of u resources voor klanten host of beheert in de omgeving van de klant. De meeste SaaS-providers hosten resources namens hun klanten, wat flexibiliteit biedt in het ontwerp van het rekenplatform. Isoleer klantworkloads effectief om kostenefficiëntie te optimaliseren zonder de klantervaring of prestaties in gevaar te brengen.
Ontwerpoverwegingen
Plan uw tenancymodel. Uw tenancymodel bepaalt het delen van resources tussen klanten en wordt beïnvloed door uw bedrijf en prijsmodellen. Modellen met één tenant hebben hogere kosten per klant vergeleken met volledig multitenant-modellen. Uw prijzen moeten deze verschillen weerspiegelen.
Vereisten van de klant. Sommige klanten hebben mogelijk specifieke behoeften voor gegevenslocatie, prestatiegaranties of beveiligingsnaleving. Als deze vereisten hogere isolatieniveaus nodig hebben dan normaal, kunt u overwegen om de verhoogde kosten in uw bedrijfsmodel weer te geven.
Luidruchtige burenprobleem. Let op het probleem met ruis bij het delen van resources tussen tenants. Rekenresources worden het meest beïnvloed. Zie Voor meer informatie, noisy neighbor antipatroon.
Wanneer u een tenancymodel kiest, moet u de kostenbesparingen van het delen van resources in balans houden met de noodzaak om de prestaties van klanten te garanderen. Over delen van resources of het toestaan van overmatig verbruik kan de klantervaring verminderen.
Compromis: prestaties en kosten. Het delen van resources tussen klanten kan kostenefficiënt zijn, maar als sommige klanten meer resources gebruiken dan verwacht, kan deze aanpak de prestaties voor anderen verminderen. Om dit te voorkomen, implementeert u de juiste resourcebeheer om ervoor te zorgen dat het tenantgebruik binnen de verwachte limieten blijft.
Ontwerpaanaanvelingen
| Aanbeveling | Voordeel |
|---|---|
| Evalueer de isolatiefuncties van het rekenplatform om ervoor te zorgen dat het voldoet aan uw tenancymodelvereisten. | U voorkomt dat uw platform opnieuw wordt bewerkt door eerst de kritieke configuratie te controleren. |
| Uw isolatiemodel afdwingen. Wees voorzichtig met gedeelde resources, zoals lokale schijfcaches, systeemgeheugen en externe caches, omdat ze onbedoeld gegevens tussen tenants kunnen lekken als ze niet goed worden beheerd. Voor hoge isolatievereisten dwingt u isolatie af binnen het rekenplatform en in de toepassing. |
Sterke isolatie vermindert het risico op gegevenslekken tussen tenants, een ernstig beveiligingsincident. |
| Implementeer resourcebeheer en bewaking, met zichtbaarheid van metrische gegevens op klantniveau. Bewaak proactief het resourceverbruik van elke klant om problemen met lawaaierige buren te detecteren en te beperken. |
U voorkomt dat problemen van invloed zijn op andere klanten door het resourceverbruik te bewaken en problemen vroeg op te lossen. |
Configureren voor schaalbaarheid en kostenefficiëntie
Uw klanten kunnen uw toepassing gebruiken met verschillende prestatieprofielen. Ze verwachten dat de toepassing te maken krijgt met toenemende gebruikersvereisten, grootschalige gegevens en complexe workloads zonder dat de snelheid en prestaties in gevaar komen. Uw systeemarchitectuur moet zorgen voor schaalbaarheid en optimale prestaties, ongeacht of deze honderden of miljoenen gebruikers beheert, terwijl de prestatiebehoeften en kosten in balans worden gebracht.
Zie Facturering en kostenbeheer voor SaaS-workloads in Azure voor meer informatie over kostenbeheer.
Ontwerpoverwegingen
Strategieën voor horizontaal en verticaal schalen. Horizontale en verticale schaalaanpassingsmethoden zijn geschikt voor het verwerken van een verhoogde belasting. De benadering die u gebruikt, is afhankelijk van de mogelijkheid van uw toepassing om te schalen op meerdere exemplaren.
- Horizontaal schalen omvat het toevoegen van meer exemplaren van rekenknooppunten. Uw architectuur heeft een load balancer nodig om binnenkomend verkeer over meerdere servers of exemplaren te verdelen.
- Verticaal schalen omvat het verhogen van resources, zoals CPU en geheugen, op één server. Gebruik deze methode voor stateful toepassingen die geen externe statusarchieven nodig hebben, zoals caches. Verticaal schalen kan korte serviceonderbrekingen veroorzaken en heeft een resourcelimiet op één server.
Raadpleeg PE:05-aanbevelingen voor schalen en partitioneren.
Automatisch schalen. Systemen moeten efficiënt omgaan met verschillende vraagniveaus. Naarmate het gebruikersverkeer toeneemt, moeten uw toepassingsbronnen omhoog worden geschaald om de prestaties te behouden. Wanneer de vraag afneemt, worden resources omlaag geschaald om de kosten te beheren zonder dat dit van invloed is op de gebruikerservaring. Factoren zoals CPU-gebruik, tijdstip van de dag of binnenkomende aanvragen leiden deze aanpassingen aan. Automatisch schalen helpt bij het verdelen van prestaties en kosten en vermindert de impact van hoge vraag op andere tenants.
Raadpleeg RE:06-aanbevelingen voor betrouwbare schaalaanpassing.
Capaciteitsplanning en rekentoewijzing. Het onboarden van nieuwe klanten voor uw SaaS-workload verbruikt resourcecapaciteit. Zelfs als u verticaal of horizontaal schaalt, bereikt u uiteindelijk limieten, zoals netwerk- of opslagbeperkingen, in de schaalbaarheid van uw oplossing.
Notitie
Met het patroon Implementatiestempels kunt u meerdere onafhankelijke exemplaren van uw oplossing implementeren. Het biedt een andere schaaldimensie. Het is van cruciaal belang om inzicht te hebben in de capaciteit van elke stempel om te bepalen wanneer er meer moet worden geïmplementeerd. Dit concept wordt ook wel bakverpakking genoemd.
Ontwerpaanaanvelingen
| Aanbeveling | Voordeel |
|---|---|
| Kies horizontaal schalen boven verticaal schalen. Horizontaal schalen is vaak minder complex, betrouwbaarder en rendabeler dan verticaal schalen. | Horizontaal schalen is vaak eenvoudiger, betrouwbaarder en rendabeler, waardoor u omhoog kunt schalen dan verticaal schalen. |
| Voer belastingstests uit. | Door het gebruik te simuleren kunt u knelpunten en drempelwaarden voor schaalaanpassing identificeren voordat u in productie gaat. |
| Definieer de schaaldrempel voor het implementeren van een nieuwe stempel in plaats van horizontaal of verticaal te schalen. Voor kosteneffectieve schaalaanpassing zonder prestatieverlies beperkt u uw tenants tot zo weinig mogelijk resources. |
U bent beter voorbereid op het afhandelen van groei buiten uw huidige infrastructuur. |
| Implementeer waar mogelijk automatisch schalen. Stel regels voor automatisch schalen in om de belasting van uw toepassing nauwkeurig weer te geven. | U optimaliseert de prestaties en kosten door zo nodig resources te verhogen en te verlagen. |
| Bewaak en evalueer gebruikspatronen van klanten. | U weet wanneer u uw infrastructuur moet aanpassen om de prestaties te verbeteren of de kosten te optimaliseren. |
| Implementeer waar mogelijk cachingmechanismen. | U vermindert de potentiële verwerkingsbelasting op de rekenlaag. |
| Kostenwaarschuwingen gebruiken. | Waarschuwingen helpen u bij het detecteren van problemen met hoog gebruik en het in een vroeg stadium beheren van kostenproblemen. |
| Gebruik Azure-reserveringen voor klanten met langetermijnverplichtingen en gegarandeerd rekengebruik voor die hele periode. | U maximaliseert de kostenefficiëntie voor uw gereserveerde capaciteit. |
Ontwerpen voor tolerantie
Tolerantie van uw rekenlaag speelt een grote rol in uw algehele tolerantiestrategie. Uw toepassing moet veelvoorkomende fouten automatisch en naadloos tolereren en herstellen, zonder gebruikersimpact.
Ontwerpoverwegingen
Betrouwbaarheidsvereisten. Stel duidelijke betrouwbaarheidsvereisten in. Deze vereisten omvatten interne doelen, SLO's en klanttoezeggingen, of SLA's, die vaak uptimedoelen opgeven, zoals 99,9% per maand.
Raadpleeg RE:04-aanbevelingen voor het definiëren van betrouwbaarheidsdoelen.
Implementatiestrategie. Cloudresources worden geïmplementeerd in specifieke geografische regio's. In Azure zijn beschikbaarheidszones geïsoleerde datacentersets binnen een regio. Implementeer toepassingen in meerdere beschikbaarheidszones voor tolerantie. Het implementeren tussen regio's of cloudproviders verbetert de tolerantie, maar voegt kosten en operationele complexiteit toe.
Raadpleeg RE:05-aanbevelingen voor het gebruik van beschikbaarheidszones en regio's.
Stateless workloads. Als u tolerante toepassingen wilt implementeren, moet u doorgaans redundante kopieën uitvoeren op verschillende locaties. Deze taak kan lastig zijn voor stateful workloads, die de sessiestatus moeten behouden. Probeer waar mogelijk staatloze workloads te bouwen.
Ontwerpaanaanvelingen
| Aanbeveling | Voordeel |
|---|---|
| Tijdelijke fouten in uw toepassing afhandelen. | U verhoogt uw beschikbaarheid door snel te herstellen van kleine problemen. |
| Kies stateless toepassingen. Als uw toepassing stateful moet zijn, gebruikt u een opslagmechanisme voor externe status, zoals een cache om de status op te slaan. | U voorkomt dat statusverlies wordt veroorzaakt doordat een exemplaar niet beschikbaar is, zoals tijdens onjuiste taakverdeling of tijdens een storing. |
| Gebruik beschikbaarheidszones. | U verhoogt uw tolerantie door gelokaliseerde datacenterstoringen te beperken. |
| Ontwerp een multiregionale architectuur wanneer er zakelijke redenen zijn om dit te doen. | U voldoet aan hoge uptimevereisten en ondersteunt gebruikers in verschillende regio's. |
| Chaos engineering uitvoeren. | U begrijpt beter waar uw storingspunten zich bevinden en kunt deze corrigeren voordat er een storing optreedt. |
| Beperk het gebruik van onderdelen die meerdere stempels delen. | U elimineert single points of failure en vermindert het potentiële impactgebied voor een storing. |
Aanvullende bronnen
Multitenancy is een kernbedrijfsmethodologie voor het ontwerpen van SaaS-workloads. Deze artikelen bevatten meer informatie over overwegingen voor rekenplatforms:
Volgende stap
Meer informatie over de netwerkoverwegingen voor SaaS-workloads.