Beräkning för SaaS-arbetsbelastningar i Azure
SaaS-programmet (programvara som en tjänst) måste köras på en beräkningsplattform. Precis som andra komponenter i din arkitektur måste den uppfylla affärskraven och utformas enligt din affärsmodell. Valet av beräkningsplattform är ett viktigt designbeslut. Ditt beslut påverkar kundisolering, prestanda och återhämtning, och din beräkningsplattform påverkar hur hela SaaS-lösningen kan skalas och växa.
Den här artikeln beskriver övervägandena för att välja din värdmodell, driftaspekterna av den modellen och hur du optimerar teknikalternativen för att hjälpa dig att uppfylla dina serviceavtal (SLA) och servicenivåmål (SLO).
Välj en beräkningsplattform
Det är viktigt att välja rätt beräkningsplattform för din SaaS-arbetsbelastning, men det stora antalet tillgängliga alternativ kan göra att valet känns överväldigande. Den bästa plattformen beror på faktorer som programarkitektur, skalning, prestandabehov och klientisoleringsmodellen. Det som är optimalt för ett program kanske inte är för ett annat.
Utformningsbeaktanden
Värdmodell. Azure erbjuder olika värdmodeller, främst infrastruktur som en tjänst (IaaS) och plattform som en tjänst (PaaS), var och en med sina egna fördelar och kompromisser. Utvärdera programmets krav och välj den lämpligaste modellen.
IaaS tillhandahåller virtuella datorer (VM) och fullständig kontroll över dem, inklusive nätverk och lagring. Det kräver dock hantering och korrigering, vilket kan vara driftintensivt. Exempel är VM-skalningsuppsättningar och AKS-kluster (Azure Kubernetes Service).
Med PaaS kan du distribuera program utan att hantera den underliggande infrastrukturen. Den innehåller inbyggda funktioner för automatisk skalning och belastningsutjämning. Exempel är Azure App Service och Azure Container Apps.
PaaS-tjänster ger mindre kontroll jämfört med IaaS, vilket kan vara problematiskt om programmet behöver en specifik konfiguration. Ditt program kan till exempel köras på ett operativsystem som PaaS-tjänsten inte stöder.
Arbetsbelastningstyp. Vissa plattformar är specialiserade för specifika arbetsbelastningar, medan andra är mångsidiga. App Service är till exempel utformat för webbprogram, medan AKS är mer generellt. Den kan vara värd för webbappar, AI-arbetsbelastningar och batchberäkningsuppgifter.
Utveckla teamexpertis. Stora förändringar kan vara utmanande om teamet saknar erfarenhet av den nya plattformen. Utvärdera teamets kunskaper och matcha dem efter dina plattformskrav. Börja med en enkel plattform och utveckla din arkitektur gradvis i stället för att hoppa direkt till ett mer avancerat alternativ.
Om du till exempel skapar ett containerbaserat program börjar du med Container Apps för enkel hantering. När dina behov blir mer komplexa kan du övergå till AKS när du får en bättre förståelse för plattformen över tid.
Hanteringskostnader. Beräkningsplattformar balanserar omkostnader och kontroll. Mer hanteringsansvar som flyttas bort från ditt team innebär mindre kontroll över plattformen.
Till exempel erbjuder IaaS hög kontroll över virtuella datorer men har betydande omkostnader. Om ditt program distribueras i en kunds miljö kan du ha begränsad åtkomst för hanteringsåtgärder. Utvärdera om dessa kompromisser är acceptabla och genomförbara.
Prestandakrav. Förstå programmets prestandakrav genom att modellera PROCESSOR, minne, nätverk, inklusive bandbredd och svarstid, GPU och tillgänglighetsbehov. Du bör också överväga framtida tillväxt. Använd den här informationen för att välja lämpliga beräkningsresurser, till exempel serien och storleken på virtuella datorer. Du kan också behöva välja specifika regioner som stöder vissa VM-serier för att uppfylla särskilda krav.
Tillförlitlighetskrav. Överväg tillförlitlighetsfunktionerna i din beräkningsplattform och se till att de uppfyller dina tillförlitlighetsmål. Du kan behöva använda specifika tjänstnivåer för att ha flera instanser av din lösning eller distribuera över tillgänglighetszoner för bättre tillförlitlighet.
Se RE:04 Rekommendationer för att definiera tillförlitlighetsmål.
Programsäkerhet och efterlevnad. Utvärdera säkerhetsfunktionerna och efterlevnadscertifieringarna för varje beräkningsplattform för att säkerställa att de uppfyller dina behov. Om du till exempel behöver övervaka och filtrera utgående trafik kan du behöva välja specifika beräkningstjänster eller nivåer.
Designrekommendationer
| Rekommendation | Förmån |
|---|---|
| Utvärdera kraven för beräkningsprestanda genom att uppskatta cpu-, minnes-, nätverks- och GPU-skalningsdimensioner. Utför belastningstestning för att samla in mer exakta data för att informera din modelleringsövning. |
De här uppgifterna hjälper dig att välja lämplig storlek för beräkningsplattformen och skala på rätt sätt när belastningen på systemet ökar. |
| Utvärdera teamets kunskaper och börja med den minst komplexa plattform som uppfyller dina behov eller en som teamet redan är bekant med. | Du säkerställer smidigare åtgärder och undviker att överbelasta ditt team genom att välja en beräkningsplattform som de är bekanta med. |
| Var flexibel i din design. Sikta på en lösning som du kan iterera med tiden för att anpassa dig till föränderliga affärs- och tekniska krav. | Med flexibilitet kan du enklare anpassa dig till ändringar och förbättringar över tid. Du kan svara effektivt på föränderliga affärsbehov och tekniska behov. |
| Utvärdera den totala ägandekostnaden (TCO), inklusive kostnaderna för att driva lösningen. | Du har en tydlig förståelse för kostnader, vilket är avgörande för att planera din prismodell och säkerställa kostnadseffektiva åtgärder. |
| Utvärdera om du behöver använda specifika beräkningsplattformar på grund av din teknikstack. Vissa beräkningsplattformar passar bättre för vissa programmeringsspråk, verktyg och operativsystem. Sträva efter att använda plattformar som internt stöder dina teknikval. | Du undviker kostnaden för att designa om arkitekturen, vilket kan innebära att migrera till en ny plattform. |
| Utvärdera plattformens tillförlitlighetsfunktioner och ta med molntjänstleverantörens garantier i dina serviceavtal. | Du minskar risken för lokala datacenterstopp genom att planera för tillförlitlighetsfunktioner och använda tillgänglighetszoner om de är tillgängliga. |
Innehavarmodell och isolering
Din SaaS-affärsmodell avgör om du är värd för resurser för kunder eller hanterar dem i kundens miljö. De flesta SaaS-leverantörer är värdar för resurser åt sina kunder, vilket ger flexibilitet i utformningen av beräkningsplattformen. Isolera kundens arbetsbelastningar effektivt för att optimera kostnadseffektiviteten utan att äventyra kundens upplevelse eller prestanda.
Utformningsbeaktanden
Planera din innehavarmodell. Din innehavarmodell avgör resursdelning mellan kunder och påverkas av dina affärs- och prismodeller. Modeller med en klientorganisation har högre kostnader per kund jämfört med helt multitenantmodeller. Prissättningen bör återspegla dessa skillnader.
Kundkrav. Vissa kunder kan ha specifika behov av datahemvist, prestandagarantier eller säkerhetsefterlevnad. Om dessa krav behöver högre isoleringsnivåer än vanligt bör du överväga hur du ska återspegla de ökade kostnaderna i din affärsmodell.
Problem med bullriga grannar. Tänk på problemet med den bullriga grannen när du delar resurser mellan klienter. Beräkningsresurser påverkas mest. Mer information finns i Antipattern för bullriga grannar.
När du väljer en innehavarmodell balanserar du kostnadsbesparingarna för resursdelning med behovet av att garantera kundernas prestanda. Överdelning av resurser eller överdriven förbrukning kan försämra kundupplevelsen.
Kompromiss: Prestanda och kostnad. Det kan vara kostnadseffektivt att dela resurser mellan kunder, men om vissa kunder använder mer resurser än förväntat kan den här metoden försämra prestandan för andra. För att förhindra detta implementerar du rätt resursstyrning för att säkerställa att klientanvändningen ligger inom förväntade gränser.
Designrekommendationer
| Rekommendation | Förmån |
|---|---|
| Utvärdera isoleringsfunktionerna i beräkningsplattformen för att säkerställa att den uppfyller kraven för din innehavarmodell. | Du undviker att omarbeta din plattform genom att verifiera den kritiska konfigurationen först. |
| Framtvinga din isoleringsmodell. Var försiktig med delade resurser som lokala diskcacheminnen, systemminne och externa cacheminnen eftersom de oavsiktligt kan läcka data mellan klienter om de inte hanteras korrekt. För höga isoleringskrav, framtvinga isolering inom beräkningsplattformen och i programmet. |
Stark isolering minskar risken för dataläckage mellan klientorganisationer, en allvarlig säkerhetsincident. |
| Implementera resursstyrning och övervakning med synlighet för mått på kundnivå. Övervaka varje kunds resursförbrukning proaktivt för att identifiera och åtgärda problem med bullriga grannar. |
Du kan förhindra att problem påverkar andra kunder genom att övervaka resursförbrukning och åtgärda problem tidigt. |
Konfigurera för skalbarhet och kostnadseffektivitet
Dina kunder kan använda ditt program med olika prestandaprofiler. De förväntar sig att programmet hanterar ökande användarkrav, storskaliga data och komplexa arbetsbelastningar utan att äventyra hastighet och prestanda. Systemarkitekturen måste säkerställa skalbarhet och optimala prestanda, oavsett om den hanterar hundratals eller miljontals användare, samtidigt som prestandabehov och kostnader balanseras.
Mer information om kostnadshantering finns i Fakturering och kostnadshantering för SaaS-arbetsbelastningar i Azure.
Utformningsbeaktanden
Horisontella och lodräta skalningsstrategier. Horisontella och lodräta skalningsmetoder är användbara för att hantera ökad belastning. Vilken metod du använder beror på programmets förmåga att skala över flera instanser.
- Horisontell skalning innebär att lägga till fler instanser av beräkningsnoder. Din arkitektur behöver en lastbalanserare för att distribuera inkommande trafik över flera servrar eller instanser.
- Vertikal skalning innebär att öka resurser, till exempel CPU och minne, på en enda server. Använd den här metoden för tillståndskänsliga program som inte behöver externa tillståndslager som cacheminnen. Vertikal skalning kan orsaka korta tjänstavbrott och har en resursgräns på en enskild server.
Autoskalning. Systemen behöver effektivt hantera olika nivåer av efterfrågan. När användartrafiken ökar måste dina programresurser skalas upp för att upprätthålla prestanda. När efterfrågan minskar skalas resurserna ned för att kontrollera kostnaderna utan att påverka användarupplevelsen. Faktorer som CPU-användning, tid på dagen eller inkommande begäranden vägleder dessa justeringar. Autoskalning hjälper till att balansera prestanda och kostnader och minskar effekten av hög efterfrågan på andra klienter.
Kapacitetsplanering och beräkningsallokering. När du registrerar nya kunder till din SaaS-arbetsbelastning används resurskapacitet. Även om du skalar lodrätt eller vågrätt når du så småningom gränser, till exempel nätverks- eller lagringsbegränsningar, i din lösnings skalbarhet.
Kommentar
Med mönstret Distributionsstämplar kan du distribuera flera oberoende instanser av din lösning. Det ger en annan skalningsdimension. Det är viktigt att förstå kapaciteten för varje stämpel för att avgöra när du ska distribuera mer. Det här konceptet kallas även för lagerplatsförpackning.
Designrekommendationer
| Rekommendation | Förmån |
|---|---|
| Välj vågrät skalning över lodrät skalning. Horisontell skalning är ofta mindre komplex, mer tillförlitlig och mer kostnadseffektiv än vertikal skalning. | Horisontell skalning är ofta enklare, mer tillförlitlig och kostnadseffektiv, vilket gör att du kan skala i högre grad än vertikal skalning. |
| Utför belastningstestning. | Om du simulerar användningen kan du identifiera flaskhalsar och skalningströsklar innan du distribuerar till produktion. |
| Definiera skalningströskelvärdet för att distribuera en ny stämpel i stället för att skala vågrätt eller lodrätt. För kostnadseffektiv skalning utan prestandaförlust kan du komprimera dina klienter till så få resurser som möjligt. |
Du är bättre förberedd på att hantera tillväxt utöver din nuvarande infrastruktur. |
| Implementera autoskalning, där det är möjligt. Ange regler för autoskalning för att återspegla programmets belastning korrekt. | Du optimerar prestanda och kostnader genom att öka och minska resurserna efter behov. |
| Övervaka och utvärdera kundanvändningsmönster. | Du vet när du ska justera infrastrukturen för att öka prestanda eller optimera kostnaderna. |
| Implementera cachelagringsmekanismer, där det är möjligt. | Du minskar den potentiella bearbetningsbelastningen på beräkningslagret. |
| Använd kostnadsaviseringar. | Varningar hjälper dig att upptäcka problem med hög användning och kontrollera kostnader tidigt. |
| Använd Azure-reservationer för kunder som har långsiktiga åtaganden och garanterad beräkningsanvändning för hela perioden. | Du maximerar kostnadseffektiviteten för din reserverade kapacitet. |
Designa för elasticitet
Återhämtning av beräkningslagret spelar en stor roll i din övergripande återhämtningsstrategi. Ditt program bör tolerera och återställa från vanliga fel automatiskt och sömlöst, utan att användaren påverkas.
Utformningsbeaktanden
Tillförlitlighetskrav. Ange tydliga tillförlitlighetskrav. Dessa krav omfattar interna mål, serviceavtal och kundåtaganden, eller serviceavtal, som ofta anger drifttidsmål som 99,9 % per månad.
Se RE:04 Rekommendationer för att definiera tillförlitlighetsmål.
Distributionsstrategi. Molnresurser distribueras i specifika geografiska regioner. I Azure är tillgänglighetszoner isolerade datacenteruppsättningar inom en region. För återhämtning distribuerar du program i flera tillgänglighetszoner. Distribution mellan regioner eller molnleverantörer förbättrar återhämtning men ökar kostnaderna och driftskomplexiteten.
Se RE:05 Rekommendationer för användning av tillgänglighetszoner och regioner.
Tillståndslösa arbetsbelastningar. För att distribuera elastiska program måste du vanligtvis köra redundanta kopior på olika platser. Den här uppgiften kan vara en utmaning för tillståndskänsliga arbetsbelastningar som behöver behålla sessionstillståndet. Sträva efter att skapa tillståndslösa arbetsbelastningar när det är möjligt.
Designrekommendationer
| Rekommendation | Förmån |
|---|---|
| Hantera tillfälliga fel i programmet. | Du ökar tillgängligheten genom att snabbt återställa från mindre problem. |
| Välj tillståndslösa program. Om ditt program behöver vara tillståndskänsligt använder du en lagringsmekanism för externt tillstånd som en cache för att lagra tillståndet. | Du kan förhindra tillståndsförlust som orsakas av att en instans inte är tillgänglig, till exempel under felaktig belastningsutjämning eller under ett avbrott. |
| Använd tillgänglighetszoner. | Du ökar din återhämtning genom att minimera lokaliserade datacenterstopp. |
| Utforma en arkitektur för flera regioner när det finns affärsmotivering för att göra det. | Du uppfyller höga drifttidskrav och stöder användare i olika regioner. |
| Utföra kaosteknik. | Du förstår bättre var dina felpunkter finns och kan korrigera dem innan ett avbrott inträffar. |
| Begränsa användningen av komponenter som flera stämplar delar. | Du eliminerar enskilda felpunkter och minskar det potentiella påverkansområdet för ett avbrott. |
Ytterligare resurser
Multitenancy är en viktig affärsmetod för att utforma SaaS-arbetsbelastningar. De här artiklarna innehåller mer information om överväganden för beräkningsplattformen:
Gå vidare
Lär dig mer om nätverksöverväganden för SaaS-arbetsbelastningar.