Kompromisser för prestandaeffektivitet

  • Artikel

En arbetsbelastning som uppfyller sina prestandamål utan överetablering är effektiv. Målet med prestandaeffektivitet är att alltid ha tillräckligt med tillgång för att hantera efterfrågan. Viktiga strategier för prestandaeffektivitet är korrekt användning av kodoptimeringar, designmönster, kapacitetsplanering och skalning. Tydliga prestandamål och testning ligger till grund för den här grundpelare.

Under processen med att förhandla om en arbetsbelastnings prestandamål och utforma en arbetsbelastning för prestandaeffektivitet är det viktigt att vara medveten om hur designprinciperna för prestandaeffektivitet och rekommendationerna i checklistan Designgranskning för prestandaeffektivitet kan påverka optimeringsmålen för andra pelare. Vissa beslut om prestandaeffektivitet kan gynna vissa grundpelare men utgör kompromisser för andra. Den här artikeln innehåller exempel på kompromisser som ett arbetsbelastningsteam kan stöta på när de utformar arbetsbelastningsarkitektur och åtgärder för prestandaeffektivitet.

Kompromisser med prestandaeffektivitet med tillförlitlighet

Kompromiss: Minskad replikering och ökad densitet. En hörnsten i tillförlitligheten är att säkerställa motståndskraft genom att använda replikering och begränsa tryckvågsradien för fel.

  • En arbetsbelastning som uppnår effektivitet genom att fördröja skalningen tills det sista ansvarsfulla ögonblicket nära uppfyller efterfrågan, men som är sårbar för oförutsedda nodfel och skalningsfördröjningar.

  • Konsolidering av arbetsbelastningsresurser kan använda överkapacitet och förbättra effektiviteten. Det ökar dock sprängradien för ett fel i den samlokala komponenten eller programplattformen.

  • Genom att skala in eller skala ned för att minimera överskottskapaciteten kan en arbetsbelastning vara underetablerade under användningstoppar, vilket leder till avbrott i tjänsten på grund av otillräcklig tillgång.

Kompromiss: Ökad komplexitet. Tillförlitlighet prioriterar enkelhet.

  • Genom att använda autoskalning för att balansera arbetsbelastningstillgången mot efterfrågan införs variabilitet i arbetsbelastningens topologi och en komponent läggs till som måste fungera korrekt för att systemet ska vara tillförlitligt. Autoskalning leder till att fler programlivscykelhändelser utlöses, som att starta och stoppa.

  • Datapartitionering och horisontell partitionering hjälper dig att undvika prestandaproblem i stora eller ofta använda datauppsättningar. Implementeringen av dessa mönster ökar dock komplexiteten eftersom (eventuell) konsekvens måste upprätthållas mellan ytterligare resurser.

  • Att avnormalisera data för optimerade åtkomstmönster kan förbättra prestanda, men det medför komplexitet eftersom flera representationer av data måste synkroniseras.

  • Prestandacentrerade molndesignmönster kräver ibland införandet av ytterligare komponenter. Användningen av dessa komponenter ökar arbetsbelastningens yta. Komponenterna måste sedan göras tillförlitliga för att hålla hela arbetsbelastningen tillförlitlig. Exempel:

    • En meddelandebuss för belastningsutjämning, som introducerar en kritisk, tillståndskänslig komponent.
    • En lastbalanserare för autoskalade repliker, vilket kräver tillförlitlig åtgärd och registrering av repliker.
    • Avlastning av data till cacheminnen, vilket kräver tillförlitliga metoder för cacheintegrering.

Kompromiss: Testning och observation i aktiva miljöer. Att undvika onödig användning av produktionssystem är en självbevarande metod för tillförlitlighet.

  • Prestandatestning i aktiva miljöer, till exempel användning av syntetiska transaktioner, medför risk för att fel uppstår på grund av teståtgärder eller konfigurationer.

  • Arbetsbelastningar ska instrumenteras med ett APM-system (Application Performance Monitoring) som gör det möjligt för team att lära sig från aktiva miljöer. APM-verktygen installeras och konfigureras i programkod eller i värdmiljön. Felaktig användning, överskridna begränsningar eller felaktig konfiguration av verktyget kan äventyra dess funktioner och underhåll, vilket kan undergräva tillförlitligheten.

Kompromisser för prestandaeffektivitet med säkerhet

Kompromiss: Minskning av säkerhetskontroller. Säkerhetskontroller upprättas över flera lager, ibland redundanta, för att ge skydd på djupet.

En strategi för prestandaoptimering är att ta bort eller kringgå komponenter eller processer som bidrar till fördröjningar i ett flöde, särskilt när bearbetningstiden inte är motiverad. Den här strategin kan dock äventyra säkerheten och bör åtföljas av en grundlig riskanalys. Överväg följande exempel:

  • Om du tar bort kryptering under överföring eller i vila för att förbättra överföringshastigheten exponeras data för potentiella integritets- eller sekretessöverträdelser.

  • Att ta bort eller minska säkerhetsgenomsöknings- eller inspektionsverktyg för att minska bearbetningstiderna kan äventyra sekretessen, integriteten eller tillgängligheten som dessa verktyg skyddar.

  • Att minska frekvensen för säkerhetskorrigeringar för att begränsa prestandapåverkan kan göra en arbetsbelastning mer sårbar för nya hot.

  • Om du tar bort brandväggsregler från nätverksflöden för att förbättra nätverksfördröjningen kan du tillåta oönskad kommunikation.

  • Att minimera datavalidering för snabbare databehandling kan äventyra dataintegriteten, särskilt om indata är skadliga.

  • Att använda mindre entropin i krypterings- eller hashalgoritmer, till exempel på initieringsvektorn (IV), är mer effektivt men gör krypteringen enklare att knäcka.

Kompromiss: Ökad arbetsbelastningsyta. Säkerhet prioriterar en reducerad och innesluten yta för att minimera attackvektorer och minska hanteringen av säkerhetskontroller.

Prestandacentrerade molndesignmönster kräver ibland införandet av ytterligare komponenter. Dessa komponenter ökar arbetsbelastningens yta. De nya komponenterna måste skyddas, eventuellt på sätt som inte redan används i systemet, och de ökar ofta efterlevnadsomfånget. Tänk på dessa vanliga komponenter:

  • En meddelandebuss för belastningsutjämning

  • En lastbalanserare för autoskalningsrepliker

  • Avlasta data till cacheminnen, nätverk för programleverans eller nätverk för innehållsleverans

  • Avlastning av bearbetning till bakgrundsjobb eller till och med klientberäkning

Kompromiss: Ta bort segmentering. Pelaren Säkerhet prioriterar stark segmentering för att möjliggöra detaljerade säkerhetskontroller och minska sprängningsradien.

Att dela resurser är en metod för att förbättra effektiviteten. Den ökar densiteten för att optimera kapacitetsanvändningen. Exempel är scenarier med flera klientorganisationer eller att kombinera olika program i en arkitektur på en gemensam programplattform. Den ökade densiteten kan leda till följande säkerhetsproblem:

  • Ökad risk för obehörig lateral förflyttning från en klientorganisation till en annan.

  • En delad arbetsbelastningsidentitet som strider mot principen om lägsta behörighet och döljer enskilda granskningsloggar i åtkomstloggar.

  • Perimetersäkerhetskontroller, till exempel nätverksregler, som reduceras för att täcka alla samlokala komponenter, vilket ger enskilda komponenter mer åtkomst än nödvändigt.

  • En kompromiss av programplattformsvärden eller en enskild komponent på grund av en större sprängradie. Den här ökningen orsakas av enklare åtkomst till samlokala komponenter.

  • Samlokalisering av olika komponenter som leder till fler komponenter i efterlevnadsomfånget på grund av deras delade värd.

Kompromisser med prestandaeffektivitet med kostnadsoptimering

Kompromiss: För mycket tillgång för efterfrågan. Både kostnadsoptimering och prestandaeffektivitet prioriterar att ha tillräckligt med tillgång för att tillgodose efterfrågan.

  • Överetablering är en risk när team försöker minska prestandaproblem i en arbetsbelastning. Några vanliga orsaker till överetablering är:

    • Den inledande kapacitetsplaneringen missbedömdes eftersom teamet endast fokuserade på uppskattningar av högsta belastning, vilket försummade strategier för topputjämning i arbetsbelastningsdesignen.
    • Skala upp eller ut en resurs under ett felsökningssteg i ett incidenthanteringssteg.

  • Autoskalning kan vara felkonfigurerad. Några exempel på felkonfigurerad autoskalning är:

    • Att skala upp med minimala förändringar i efterfrågan eller en utökad nedkylningsperiod kan medföra mer kostnader än vad efterfrågan kräver.
    • Användning av autoskalning utan en angiven övre gräns kan leda till okontrollerad tillväxt på grund av systemfel eller missbruk och överskrida de förväntade arbetsbelastningskraven.

  • Om du expanderar till flera regioner kan du förbättra prestandan genom att föra arbetsbelastningarna närmare användaren och undvika tillfälliga resurskapacitetsbegränsningar. Men det ökar också komplexiteten och resursdupliceringen.

Kompromiss: Fler komponenter. En kostnadsoptimeringsteknik är att konsolidera med ett mindre antal resurser genom att öka densiteten, ta bort duplicering och samplacera funktioner.

  • Prestandacentrerade molndesignmönster kräver ibland införandet av extra komponenter. Dessa extra komponenter leder vanligtvis till en total kostnadsökning för arbetsbelastningen. Du kan till exempel inkludera en meddelandebuss för belastningsutjämning eller avlastningsuppgifter till ett program eller ett nätverk för innehållsleverans för bättre svarstider.

  • Med resurssegmentering kan olika delar av en arbetsbelastning ha distinkta prestandaegenskaper, vilket möjliggör oberoende justering för varje segment. Det kan dock öka de totala ägandekostnaderna eftersom det kräver flera optimerade segment i stället för en enda generaliserad komponent.

Kompromiss: Ökad investering på objekt som inte är anpassade till funktionella krav. En metod för kostnadsoptimering är att utvärdera värdet som tillhandahålls av alla lösningar som distribueras.

  • Premiumtjänster och SKU:er kan hjälpa en arbetsbelastning att uppfylla prestandamålen. Dessa tjänster kostar vanligtvis mer och kan ge extra funktioner. De kan vara underutnyttjade om många av premiumfunktionerna inte används specifikt för att uppfylla prestandamålen.

  • En högpresterande arbetsbelastning kräver telemetridata för observerbarhet som måste överföras och lagras. En ökning av prestandatelemetri som samlas in kan öka kostnaden för överföring och lagring av telemetridata.

  • Prestandatestningsaktiviteter lägger till kostnader som inte är associerade med produktionssystemets värde. Exempel på prestandatestningskostnader är:

    • Instansiera miljöer som är dedikerade till prestandacentrerade tester.
    • Använda specialiserade prestandaverktyg.
    • Ägna tid åt att köra testerna.

  • Medlemmar i utbildningsteamet för specialiserade prestandaoptimeringsuppgifter eller betalning för prestandajusteringstjänster ökar kostnaden för en arbetsbelastning.

Kompromisser för prestandaeffektivitet med driftseffektivitet

Kompromiss: Minskad observerbarhet. Observerbarhet är nödvändigt för att ge en arbetsbelastning meningsfulla aviseringar och bidra till att säkerställa en lyckad incidenthantering.

  • Att minska logg- och måttvolymen för att minska bearbetningstiden för insamling av telemetri i stället för andra uppgifter minskar systemets övergripande observerbarhet. Några exempel på den resulterande minskade observerbarheten är:

    • Den begränsar de datapunkter som används för att skapa meningsfulla aviseringar.
    • Det leder till luckor i täckningen för incidenthanteringsaktiviteter.
    • Den begränsar observerbarheten i säkerhetskänsliga eller efterlevnadskänsliga interaktioner och gränser.

  • När prestandadesignmönster implementeras ökar ofta arbetsbelastningens komplexitet. Komponenter läggs till i kritiska flöden. Strategin för arbetsbelastningsövervakning och prestandaövervakning måste innehålla dessa komponenter. När ett flöde sträcker sig över flera komponenter eller programgränser ökar komplexiteten i övervakningen av flödets prestanda. Flödesprestanda måste korreleras mellan alla sammankopplade komponenter.

Kompromiss: Ökad komplexitet i driften. En komplex miljö har mer komplexa interaktioner och större sannolikhet för en negativ inverkan från rutin-, ad hoc- och nödåtgärder.

  • Att förbättra prestandaeffektiviteten genom att öka densiteten ökar risken i operativa uppgifter. Ett fel i en enda process kan ha en stor sprängradie.

  • När prestandadesignmönster implementeras påverkar de operativa procedurer som säkerhetskopieringar, nyckelrotationer och återställningsstrategier. Till exempel kan datapartitionering och horisontell partitionering komplicera rutinuppgifter när teamen försöker se till att dessa uppgifter inte påverkar datakonsekvensen.

Kompromiss: Kulturstress. Operational Excellence är rotad i en kultur av skuldlöshet, respekt och kontinuerlig förbättring.

  • Vid rotorsaksanalys av prestandaproblem identifieras brister i processer eller implementeringar som kräver korrigering. Teamet bör betrakta övningen som en utbildningsmöjlighet. Om teammedlemmar anklagas för problem kan moralen påverkas.

  • Rutin- och ad hoc-processer kan påverka arbetsbelastningens prestanda. Det anses ofta vara bättre att utföra dessa aktiviteter under tider med låg belastning. Tider med låg belastning kan dock vara obekväma eller utanför ordinarie arbetstid för de teammedlemmar som ansvarar för eller är skickliga i dessa uppgifter.

Utforska kompromisserna för de andra pelarna: