Design för användningsoptimering
 Maximera användningen av resurser och åtgärder. Tillämpa dem på de förhandlade funktionella och icke-funktionella kraven i lösningen. |
|---|
Tjänster och erbjudanden ger olika funktioner och prisnivåer. När du har köpt en uppsättning funktioner bör du undvika att underutnyttjera dem. Hitta sätt att maximera din investering på nivån. På samma sätt utvärderar du kontinuerligt faktureringsmodeller för att hitta de som bättre överensstämmer med din användning, baserat på aktuella produktionsarbetsbelastningar.
Exempelscenario
Contoso University är för närvarande värd för en kommersiell cots-lösning (off-the-shelf) som gör det möjligt för universitetsfakulteten att skapa och uppdatera kurser för skolåret och är den primära registreringsportalen som används av studenter för dessa kurser. Lösningen har en anpassad integrering med ett SaaS-utbildningssystem (Software-as-a-Service), som de hoppas kunna migrera alla sina funktioner till om några år. Under tiden vill de optimera kostnaderna för de anpassade integreringskomponenterna.
Tekniklösningen i COTS-erbjudandet behandlas vanligtvis som en svart ruta, förutom dess databas som är Azure Database for MySQL. Den anpassade integreringen är en Azure Durable-funktion som körs baserat på en standardtjänstplan i Azure App Service. Denna App Service var tidigare värd för en universitetswebbplats, men så är inte längre fallet. Den här varaktiga funktionen är ett Python-program som backas upp av ett dedikerat Azure Storage-konto som utför en nattlig synkronisering från MySQL-databasen till SaaS API.
Använd förbrukningsbaserad prissättning när det är praktiskt
Det kan finnas tjänster som erbjuder förbrukningsbaserad prissättning, vilket innebär att du bara debiteras för användningen av tjänsten, och du kan stänga av tjänsten när den inte behövs för att sluta medföra kostnader. Om du har arbetsbelastningskomponenter som endast används sporadiskt kan det minimera bortkastade kostnader jämfört med att betala för att komponenten ska köras dygnetrunt/7/365.
Genom att använda förbrukningsbaserad prissättning betalar du bara för exakt det du använder. Det här alternativet är ett bra alternativ när arbetsbelastningsberäkningen inte förväntas användas på heltid.
Contosos utmaning
- Synkroniseringsjobbet körs vanligtvis i ungefär en timme varje natt, vid en viss tidpunkt. Prestandan har historiskt sett varit tillfredsställande. Fel är sällsynta och tillfälliga fel hanteras väl i den aktuella konfigurationen.
- Eftersom den beräkning som behövs för synkroniseringsjobbet endast används ungefär en timme per dag och de betalar i 24 timmar oavsett användning, är arbetsbelastningsteamet intresserade av ett alternativ till den aktuella designen.
- Teamet har övervägt att skriva ett skript för att stänga av tjänsten varje natt efter att synkroniseringen har körts och distribuerat den igen nästa dag, men den här lösningen skulle medföra en hög grad av risk och komplexitet.
Tillämpa metoden och resultaten
- Teamet analyserar jobbhistoriken och upptäcker att den längsta funktionen någonsin har varit knappt två timmar. De jämför kostnaden för den dedikerade planen med kostnaden för Azure Functions-förbrukningsplanen för det värsta scenariot och drar slutsatsen att förbrukningsplanen blir billigare.
- Teamet kör ett prestandatest för att säkerställa att prestandan är tillräcklig och de märker en liten ökning av körningstiden, men den ligger fortfarande inom acceptabla gränser.
- Arbetsbelastningens totala kostnad minskas genom att använda förbrukningsplanen eftersom de endast medför kostnader när jobbet körs.
Optimera designen för hög tillgänglighet
Prioritera distribution av aktiva eller aktiva modeller framför aktiva-passiva modeller, som en del av återställningsplanen, om du redan har betalat för resurserna.
Om din design som standard använder aktiva-passiva modeller kan du ha inaktiva resurser som annars skulle kunna användas. Om du konverterar till aktiv-aktiv kan du uppfylla kraven på belastningsutjämning och skalningssprängning utan överförbrukning. Om du kan uppfylla dina återställningsmål med en modell som endast är aktiv kan kostnaderna för dessa resurser tas bort helt.
Contosos utmaning
- COTS-programmet använder Azure Database for MySQL – flexibel server som konfigurerats för hög tillgänglighet i samma zon, vilket ger en väntelägesserver i samma tillgänglighetszon som den primära servern. De har också aktiverat automatiska säkerhetskopieringar.
- Arbetsbelastningens RPO är relativt lång vid 12 timmar och RTO är tre timmar under skoldagen.
- Baserat på tidigare återställningstester vet teamet att de kan uppfylla sina RPO- och RTO-mål genom automatisk redundansväxling till väntelägesservern. De har också testat att återställa databasen från en säkerhetskopia och de kan uppfylla målen i det här scenariot.
Tillämpa metoden och resultaten
- Arbetsbelastningsteamet omvärderar fördelen med designen med hög tillgänglighet jämfört med att kostnaden för tjänsten är dubbelt så mycket som en enda instans.
- Teamet testar att skapa en ny instans och återställa en databas från säkerhetskopian och de är övertygade om att de fortfarande uppfyller sina återställningsmål, så de bestämmer sig för att eliminera standby-instansen.
- Teamet uppdaterar DR-planen för att återspegla den nya återställningsstrategin och realisera kostnadsbesparingarna genom den nya konfigurationen.
Håll din molnmiljö ren från oanvända resurser och data
Granska distributioner regelbundet för oanvända resurser och data och inaktivera dem. Med tiden kan resurser och data som tidigare krävdes för något ändamål, men som inte längre används, dröja kvar i dina molnmiljöer och i onödan ackumulera kostnader. Var uppmärksam på att hålla dina miljöer rena för att optimera för kostnadseffektivitet.
Att stänga av oanvända resurser och ta bort data när du inte längre behöver det minskar slöseriet och frigör pengar så att du kan investera dem någon annanstans.
Contosos utmaning
- Universitetet har historiskt sett intagit en konservativ inställning till avvecklingslösningar och befarat att de kan behöva återgå till en tidigare konfiguration. Denna försiktighet har lett till att tjänster har övergivits i en eller flera miljöer i månader som i vissa fall har glömts bort.
- När övergivna tjänster upptäcks är det vanligtvis av misstag eftersom det inte finns någon formell process för att se över miljön för sådana tjänster.
Tillämpa metoden och resultaten
- Teamet lägger till avveckling av App Service i kvarvarande uppgifter som en del av migreringen från App Service till förbrukningsvärd för Durable Function. Som en del av nästa sprint kommer de att stänga av App Service-distributionerna i alla miljöer.
- För att hjälpa till att proaktivt identifiera övergivna resurser konfigurerar teamet aviseringar i Azure Advisor för att meddela dem om oanvända resurser.
- Teamet implementerar en ny princip som kräver att teamet gör månatliga fullständiga granskningar av förproduktionsmiljöer och kvartalsvisa fullständiga granskningar av produktionsmiljön för att identifiera övergivna resurser. Alla övergivna resurser som hittas läggs till i kvarvarande uppgifter som ska inaktiveras.