Konsolidera flera aktiviteter eller åtgärder i en enda beräkningsenhet. Det här kan öka användningen av beräkningsresurserna. Det kan dessutom minska kostnaderna och hanteringen kopplade till att beräkna i molnbaserade program.
Kontext och problem
Ett molnprogram implementerar ofta en mängd åtgärder. I vissa lösningar är det klokt att först följa designprincipen för separation av problem och dela upp dessa åtgärder i separata beräkningsenheter som hanteras och distribueras individuellt (till exempel som separata App Service-webbappar eller separata virtuella datorer). Den här strategin kan visserligen underlätta den logiska utformningen av lösningen, men du ska vara medveten om att distribution av ett stort antal beräkningsenheter som del av samma program kan öka runtime-värdkostnaderna och göra hantering av systemet mer komplex.
Bilden visar ett exempel på en förenklad struktur i en molnbaserad lösning som implementeras med hjälp av mer än en beräkningsenhet. Varje beräkningsenhet körs i en egen virtuell miljö. Varje funktion har implementerats som separat åtgärd (märkta aktivitet A till E) och körs med en egen beräkningsenhet.
Varje beräkningsenhet förbrukar resurser, även när den är inaktiv eller används i begränsad omfattning. Det är därför inte alltid den mest kostnadseffektiva lösningen.
I Azure gäller detta problem apptjänster, containerappar och virtuella datorer. Dessa objekt körs i sin egen miljö. Att köra en samling separata webbplatser, mikrotjänster eller virtuella datorer som är utformade för att utföra en uppsättning väldefinierade åtgärder, men som behöver kommunicera och samarbeta som en del av en enda lösning, kan vara en ineffektiv användning av resurser.
Lösning
Det går att konsolidera flera aktiviteter och åtgärder i en enda beräkningsenhet. Det här görs i syfte att minska kostnaderna, öka användningsgraden, skynda på kommunikationen och minska hanteringen.
Aktiviteter kan grupperas enligt villkor, baserat på funktionerna i miljön och kostnaderna knutna till de här funktionerna. En vanlig metod är att söka efter aktiviteter som har en liknande profil vad gäller krav på skalbarhet, livstid och behandling. När de här grupperas tillsammans kan de skalanpassas som en enhet. Många molnmiljöer har stor elasticitet. Det betyder att det går att starta och stoppa ytterligare instanser av en beräkningsenhet, allt enligt arbetsbelastning. Azure tillhandahåller till exempel automatisk skalning som du kan använda för App Services och VM-skalningsuppsättningar. Mer information finns i Vägledning om autoskalning.
Här visar vi två uppgifter som exempel på hur skalbarhet kan användas för att avgöra vilka åtgärder som inte ska grupperas tillsammans:
- Aktivitet 1 söker efter ovanliga, icke tidskänsliga meddelanden som har skickats till en kö.
- Aktivitet 2 hanterar stora och plötsliga toppar i nätverkstrafiken.
Den andra aktiviteten kräver elasticitet som kan omfatta att starta och stoppa ett stort antal instanser av beräkningsenheten. Att tillämpa samma skalning på den första aktiviteten skulle bara resultera i att fler aktiviteter skulle lyssna efter ovanliga meddelanden i samma kö. Det är slöseri med resurser.
I många molnmiljöer går det att specificera vilka resurser som är tillgängliga för en beräkningsenhet, vad gäller antal processorkärnor, minne, diskutrymme och så vidare. I allmänhet gäller att ju fler resurser som anges, desto större blir kostnaden. Om du vill spara pengar är det viktigt att maximera det arbete en dyr beräkningsenhet utför och inte låta den vara inaktiv någon längre tid.
Om det finns aktiviteter som kräver korta sekvenser med mycket intensiv processoreffekt kan du överväga att konsolidera de här i en enda beräkningsenhet som tillhandahåller den nödvändiga effekten. Det är dock viktigt att balansera behovet av att hålla dyra resurser aktiva mot konkurrensen som kan uppstå om de överbelastas. Det är till exempel inte bra att låta flera tidskrävande, beräkningsintensiva aktiviteter dela samma beräkningsenhet.
Problem och överväganden
Tänk på följande när du implementerar det här mönstret:
Skalbarhet och elasticitet. I många molnlösningar implementeras skalbarhet och elasticitet hos beräkningsenheten genom att instanser av enheter startas och stoppas. Undvik att samla aktiviteter med konkurrerande skalbarhetskrav i samma beräkningsenhet.
Livslängd. Molninfrastrukturen återanvänder regelbundet den virtuella miljö som är värd för en beräkningsenhet. När det finns många tidskrävande aktiviteter i en beräkningsenhet kan det vara nödvändigt att konfigurera enheten så att den inte återvinns förrän dessa aktiviteter har slutförts. Du kan också utforma aktiviteter med hjälp av kontrollpunkter som gör det möjligt för dem att stanna upp vid en viss punkt och sedan fortsätta från samma punkt när beräkningsenheten startar igen.
Frisläppningstakt. Om implementeringen eller konfigurationen för en aktivitet ändras ofta kan det bli nödvändigt att stoppa den beräkningsenhet som är värd för den uppdaterade koden, konfigurera om enheten, distribuera om den och sedan starta om den. Den här processen kräver också att alla andra aktiviteter inom samma beräkningsenhet stoppas, distribueras om och startas om.
Säkerhet. Aktiviteter i samma beräkningsenhet kan dela samma säkerhetskontext och kan eventuellt komma åt samma resurser. Förtroendegraden mellan aktiviteterna måste vara hög, och det måste vara sannolikt att ingen aktivitet skadar eller på annat sätt negativt påverkar någon annan. När antalet aktiviteter som körs i en beräkningsenhet växer ökar samtidigt risken för angrepp på enheten. Det är den aktivitet som har flest sårbarheter som bestämmer säkerhetsnivån.
Feltolerans. Om en aktivitet i en beräkningsenhet misslyckas eller beter sig onormalt kan det påverka de andra aktiviteterna som körs på samma enhet. Om en aktivitet till exempel inte kan startas på rätt sätt kan hela startlogiken för beräkningsenheten misslyckas och förhindra att andra aktiviteter i samma enhet körs.
Konkurrens. Undvik att införa konkurrens mellan aktiviteter som konkurrerar om resurser i samma beräkningsenhet. Vi rekommenderar att du ser till att aktiviteter som delar samma beräkningsenhet har olika resursanvändningsbehov. Du bör till exempel inte placera två beräkningsintensiva aktiviteter i samma beräkningsenhet, och inte heller två aktiviteter som använder stora mängder minne. Att blanda en beräkningsintensiv uppgift med en uppgift som kräver en stor mängd minne är dock en fungerande kombination.
Kommentar
Överväg att konsolidera beräkningsresurser endast för ett system som har varit i produktion under en viss tid så att operatörer och utvecklare kan övervaka systemet och skapa en värmekarta som identifierar hur varje uppgift använder olika resurser. Kartan kan användas för att avgöra vilka aktiviteter som kan dela beräkningsresurser.
Komplexitet. När du kombinera flera aktiviteter i en beräkningsenhet gör det koden för enheten mer komplex. Det kan göra den svårare att testa, felsöka och underhålla.
Stabil logisk arkitektur. Utforma och implementera koden i varje aktivitet så att den inte behöver ändras, även om den fysiska miljön som aktiviteten körs i ändras.
Andra strategier. Konsolidering av beräkningsresurser är bara ett sätt att minska kostnaderna förknippade med flera samtidiga aktiviteter. Det krävs noggrann planering och övervakning för att säkerställa att det förblir en effektiv strategi. Andra strategier kan vara bättre lämpade. Det beror på arbetets typ och var de användare som är kopplade till aktiviteterna finns. En funktionell uppdelning av arbetsbelastningen (som beskrivs i guiden om beräkningspartitionering) kan vara ett bättre alternativ.
När du ska använda det här mönstret
Använd det här mönstret för aktiviteter som inte är kostnadseffektiva när de körs i egna beräkningsenheter. Om en aktivitet är inaktiv en stor del av tiden kan det bli dyrt att köra den här aktiviteten i en egen enhet.
Det här mönstret kanske inte är lämpligt för aktiviteter som utför kritiska feltoleranta åtgärder. Det kanske inte heller är lämpligt för aktiviteter som bearbetar mycket känsliga eller privata data som kräver en egen säkerhetskontext. Den typen av aktiviteter ska köras i en egen isolerad miljö, i en separat beräkningsenhet.
Design av arbetsbelastning
En arkitekt bör utvärdera hur konsolideringsmönstret för beräkningsresurser kan användas i arbetsbelastningens design för att uppfylla de mål och principer som beskrivs i grundpelarna i Azure Well-Architected Framework. Till exempel:
| Grundpelare | Så här stöder det här mönstret pelarmål |
|---|---|
| Kostnadsoptimering fokuserar på att upprätthålla och förbättra arbetsbelastningens avkastning på investeringen. | Det här mönstret maximerar användningen av beräkningsresurser genom att undvika oanvänd etablerad kapacitet via sammansättning av komponenter eller till och med hela arbetsbelastningar i en poolinfrastruktur. - CO:14 Konsolidering |
| Operational Excellence hjälper till att leverera arbetsbelastningskvalitet genom standardiserade processer och teamsammanhållning. | Konsolidering kan leda till en mer homogen beräkningsplattform som kan förenkla hantering och observerbarhet, minska olika metoder för operativa uppgifter och minska mängden verktyg som krävs. - OE:07 Övervakningssystem - OE:10 Automation-design |
| Prestandaeffektivitet hjälper din arbetsbelastning att effektivt uppfylla kraven genom optimeringar inom skalning, data och kod. | Konsolidering maximerar användningen av beräkningsresurser med hjälp av extra nodkapacitet och minskar behovet av överetablering. Stora (lodrätt skalade) beräkningsinstanser används ofta i resurspoolen för dessa infrastrukturer. - PE:02 Kapacitetsplanering - PE:03 Välja tjänster |
Som med alla designbeslut bör du överväga eventuella kompromisser mot målen för de andra pelarna som kan införas med det här mönstret.
Val av programplattform
Det här mönstret kan uppnås på olika sätt, beroende på vilken beräkningstjänst du använder. Se följande exempeltjänster:
- Azure App Service och Azure Functions: Distribuera delade App Service-planer som representerar värdserverinfrastrukturen. En eller flera appar kan konfigureras för att köras på samma databehandlingsresurser (eller i samma App Service-plan).
- Azure Container Apps: Distribuera containerappar till samma delade miljöer, särskilt i situationer där du behöver hantera relaterade tjänster eller om du behöver distribuera olika program till samma virtuella nätverk.
- Azure Kubernetes Service (AKS): AKS är en containerbaserad värdinfrastruktur där flera program eller programkomponenter kan konfigureras för att köras samlokalt på samma beräkningsresurser (noder), grupperade efter beräkningskrav som processor- eller minnesbehov (nodpooler).
- Virtuella datorer: Distribuera en enda uppsättning virtuella datorer som alla klienter kan använda, så att hanteringskostnaderna delas mellan klienterna. Vm-skalningsuppsättningar är en funktion som stöder delad resurshantering, belastningsutjämning och horisontell skalning av virtuella datorer.
Relaterade resurser
Följande mönster och riktlinjer kan vara relevanta när du implementerar det här mönstret:
Vägledning om autoskalning. Automatisk skalning kan användas för att starta och stoppa instanser av bearbetningsresurser av typen värd för tjänst, beroende på förväntat bearbetningsbehov.
Riktlinjer för beräkningspartitionering. Beskriver hur du tilldelar tjänster och komponenter i en molntjänst på ett sätt som hjälper till att minimera de löpande kostnaderna samtidigt som tjänstens skalbarhet, prestanda, tillgänglighet och säkerhet bibehålls.
Arkitekturmetoder för beräkning i lösningar med flera klientorganisationer. Ger vägledning om de överväganden och krav som är viktiga för lösningsarkitekter när de planerar beräkningstjänsterna för en lösning med flera klienter.