Aanbevelingen voor het optimaliseren van schaalkosten
Van toepassing op deze aanbeveling voor de controlelijst voor kostenoptimalisatie van Azure Well-Architected Framework:
| CO:12 | Schaalkosten optimaliseren. Evalueer alternatieve schaalaanpassing binnen uw schaaleenheden. Overweeg alternatieve schaalconfiguraties en stem af op het kostenmodel. Overwegingen moeten betrekking hebben op het gebruik ten opzichte van de overnamelimieten van elke instantie, resource en schaaleenheidgrens. Strategieën gebruiken voor het beheren van vraag en aanbod. |
|---|
Deze handleiding bevat aanbevelingen voor het optimaliseren van de schaalkosten. Het optimaliseren van kosten is het proces van het verwijderen van inefficiëntie bij het schalen van workloads. Het doel is om de schaalkosten te verlagen en tegelijkertijd te voldoen aan alle niet-functionele vereisten. Minder uitgeven om hetzelfde resultaat te krijgen. Door de schaal te optimaliseren, voorkomt u onnodige uitgaven, te veel inrichting en verspilling. Het helpt ook onverwachte pieken in de kosten te voorkomen door de vraag te beheersen en het aanbod te beperken. Inefficiënte schaalprocedures kunnen leiden tot hogere workload en operationele kosten en hebben een negatieve invloed op de algehele financiële status van de workload.
Definities
| Termijn | Definitie |
|---|---|
| Automatisch schalen | Een schaalbenadering waarmee automatisch resources worden toegevoegd of verwijderd wanneer aan een set voorwaarden wordt voldaan. |
| Metrische gegevens over kosten | Numerieke gegevens met betrekking tot workloadkosten. |
| Omlaag schalen | Een strategie voor verticaal schalen die verschuift naar een lagere SKU om minder resources aan de workload te bieden. |
| Inschalen | Een horizontale schaalstrategie waarmee instanties worden verwijderd om minder resources aan de workload te bieden. |
| Uitschalen | Een horizontale schaalstrategie waarmee instanties worden toegevoegd om meer resources aan de workload te bieden. |
| Schaaleenheid | Een groep resources die proportioneel samen worden geschaald. |
| Omhoog schalen | Een strategie voor verticaal schalen die verschuift naar een hogere SKU om meer resources aan de workload te bieden. |
| Voorraadbeheereenheid (SKU) | Een servicelaag voor een Azure-service. |
| Gebruiksgegevens | Gebruiksgegevens zijn directe informatie (echt) of indirecte/representatieve informatie (proxy) over hoeveel een taak, service of toepassing wordt gebruikt. |
Belangrijke ontwerpstrategieën
Het doel van kostenoptimalisatie is om op het laatste verantwoorde moment omhoog en uit te schalen en omlaag en in te schalen zodra dit praktisch is. Als u het schalen voor uw workload wilt optimaliseren, kunt u alternatieve schaalopties binnen de schaaleenheden evalueren en deze afstemmen op het kostenmodel. Een schaaleenheid vertegenwoordigt een specifieke groepering van resources die onafhankelijk of samen kunnen worden geschaald. U moet schaaleenheden ontwerpen voor het afhandelen van een specifieke hoeveelheid belasting. Deze kunnen bestaan uit meerdere exemplaren, servers of andere resources. U moet de kosteneffectiviteit van uw workloadschaaleenheden en model-alternatieven evalueren.
Als u geen gebruik maakt van schalen, raadpleegt u de richtlijnen voor het schalen van de workload. U moet nagaan of uw toepassing kan worden geschaald. Stateless toepassingen zijn eenvoudiger te schalen omdat ze meerdere aanvragen tegelijk kunnen verwerken. Evalueer ook of de toepassing is gebouwd met behulp van gedistribueerde systeemprincipes. Gedistribueerde systemen kunnen verhoogde belasting verwerken door de workload over meerdere knooppunten te distribueren. Een singleton-toepassing is echter ontworpen om slechts één exemplaar op een bepaald moment uit te voeren. Daarom is schalen mogelijk niet geschikt voor alle workloads.
Uitschalen evalueren versus omhoog schalen
Het evalueren van uitschalen versus omhoog schalen omvat het bepalen van de meest kosteneffectieve benadering tussen het verhogen van resources in een bestaand systeem (omhoog schalen) of het toevoegen van meer exemplaren van dat systeem (uitschalen) op basis van verschillende factoren, zoals prijzen, workloadvereisten en acceptabele downtime. Het kiezen van de juiste schaalbenadering kan leiden tot aanzienlijke besparingen, zodat u alleen betaalt voor wat u nodig hebt, terwijl u nog steeds voldoet aan de prestatie- en betrouwbaarheidsstandaarden.
Het doel is om de meest kostenefficiënte keuze te bepalen op basis van prijzen voor servicelagen, workloadkenmerken, acceptabele downtime en het kostenmodel. Voor sommige kan het voordeliger zijn om te kiezen voor duurdere exemplaren in minder aantallen. Voor anderen is een goedkopere laag met meer exemplaren misschien beter. Als u een weloverwogen beslissing wilt nemen, moet u echte of representatieve gegevens van uw installatie analyseren en de relatieve kosten van elke strategie evalueren. Bekijk de volgende aanbevelingen om de meest kostenefficiënte aanpak te evalueren:
Gebruiksgegevens verzamelen: verzamel werkelijke productiegegevens of proxygegevens die de gebruikspatronen van de workload en het resourcegebruik vertegenwoordigen. Deze gegevens moeten metrische gegevens bevatten, zoals CPU-gebruik, geheugengebruik, netwerkverkeer en andere relevante metrische gegevens die van invloed zijn op de schaalkosten.
Metrische gegevens over kosten definiëren: identificeer de metrische gegevens over kosten die relevant zijn voor uw workload, zoals de kosten per uur, de kosten per transactie of de kosten per eenheid resourcegebruik. Met deze metrische gegevens kunt u de kosteneffectiviteit van verschillende schaalopties vergelijken.
Gebruiksgegevens verzamelen: verzamel werkelijke productiegegevens of proxygegevens die de gebruikspatronen van de workload en het resourcegebruik vertegenwoordigen. Deze gegevens moeten metrische gegevens bevatten, zoals CPU-gebruik, geheugengebruik, netwerkverkeer en andere relevante metrische gegevens die van invloed zijn op de schaalkosten
Metrische gegevens over kosten definiëren: identificeer de metrische gegevens over kosten die relevant zijn voor uw workload, zoals de kosten per uur, de kosten per transactie of de kosten per eenheid resourcegebruik. Deze metrische gegevens helpen u bij het vergelijken van de kosteneffectiviteit van verschillende schaalopties.
Raadpleeg vereisten: houd bij het kiezen tussen uitschalen en opschalen rekening met de betrouwbaarheid, prestaties en schaalvereisten van uw workload. Uitschalen kan de betrouwbaarheid verbeteren door redundantie. Omhoog schalen verhoogt de capaciteit van een resource, maar er kunnen beperkingen zijn voor de hoeveelheid omhoog schalen.
Overweeg resourcelimieten: bij het evalueren van schaalopties is het belangrijk om rekening te houden met de inherente limieten van elke instantie, resource en schaaleenheidgrens. Houd rekening met de bovenste schaallimieten voor elke resource en plan dienovereenkomstig. Houd ook rekening met de limieten van uw abonnement en andere resources.
Testschalen: maak tests voor verschillende schaalscenario's, waaronder opties voor uitschalen en omhoog schalen. Door de gebruiksgegevens toe te passen, simuleert u het gedrag van de workload onder verschillende schaalconfiguraties. Voer praktijktests uit met behulp van de gemodelleerde schaalscenario's.
Kosten berekenen: gebruik de verzamelde gegevens en metrische gegevens voor kosten om de kosten te berekenen die zijn gekoppeld aan elke schaalconfiguratie. Houd rekening met factoren zoals exemplaarprijzen, resourcegebruik en eventuele extra kosten met betrekking tot schalen.
Automatisch schalen optimaliseren
Het optimaliseren van het beleid voor automatisch schalen omvat het verfijnen van automatisch schalen om te reageren op belastingswijzigingen op basis van de niet-functionele vereisten van de workload. U kunt overmatige schaalactiviteiten beperken door drempelwaarden aan te passen en de juiste afkoelperiode te gebruiken. Houd rekening met de volgende aanbevelingen om automatisch schalen te optimaliseren:
Het huidige beleid voor automatisch schalen analyseren: inzicht in het bestaande beleid en het gedrag ervan als reactie op verschillende belastingsniveaus.
Raadpleeg niet-functionele vereisten: identificeer de specifieke niet-functionele vereisten waarmee u rekening moet houden, zoals reactietijd, resourcegebruik of kosten.
Schaaldrempels aanpassen: pas de schaaldrempels aan op basis van de kenmerken van de workload en niet-functionele vereisten. Stel drempelwaarden in voor omhoog of omlaag schalen op basis van factoren zoals CPU-gebruik in de loop van de tijd, netwerkverkeer of wachtrijlengte.
Een afkoelperiode aanpassen: pas de afkoelperiode aan om overmatige schaalbewerkingen te voorkomen die worden geactiveerd door tijdelijke belastingpieken. Een afkoelperiode leidt tot een vertraging tussen schaalgebeurtenissen, waardoor het systeem zich kan stabiliseren voordat verdere schaalacties worden uitgevoerd.
Bewaken en verfijnen: continu het gedrag en de prestaties van het systeem bewaken. Analyseer de schaalactiviteiten en pas het beleid zo nodig aan om de kosten te optimaliseren en te voldoen aan de gewenste niet-functionele vereisten.
Afweging: het verminderen van het aantal schaalbewerkingen verhoogt de kans op problemen met betrekking tot schalen. Dit betekent dat u de extra buffer of buffer elimineert die u kan helpen bij het beheren van potentiële problemen of vertragingen bij het schalen.
Schalen op basis van gebeurtenissen overwegen
Met gebeurtenisgestuurde automatische schaalaanpassing kan de toepassing resources dynamisch aanpassen op basis van specifieke gebeurtenissen of triggers in plaats van traditionele metrische gegevens zoals CPU- of geheugengebruik. Kubernetes, gebeurtenisgestuurde automatische schaalaanpassing (KEDA) kan bijvoorbeeld toepassingen schalen op basis van scalers, zoals de lengte van een Kafka-onderwerp. Precisie helpt onnodige schaalschommelingen en resourceverspilling te voorkomen. Een hoge mate van precisie optimaliseert uiteindelijk de kosten. Als u schaalaanpassing op basis van gebeurtenissen wilt gebruiken, voert u de volgende stappen uit:
Kies een gebeurtenisbron: bepaal de gebeurtenisbron die het schalen van uw schaaleenheid activeert. Een bron kan een berichtenwachtrij, een streamingplatform of een ander gebeurtenisgestuurd systeem zijn.
Opname van gebeurtenissen instellen: configureer uw toepassing om gebeurtenissen uit de gekozen gebeurtenisbron te gebruiken. Dit omvat meestal het tot stand brengen van een verbinding, het abonneren op de relevante onderwerpen of wachtrijen en het verwerken van de binnenkomende gebeurtenissen.
Schaallogica implementeren: schrijf de logica die bepaalt wanneer en hoe uw schaaleenheid moet worden geschaald op basis van de binnenkomende gebeurtenissen. Deze logica moet rekening houden met factoren zoals het aantal gebeurtenissen, de snelheid van binnenkomende gebeurtenissen of andere relevante metrische gegevens.
Integreren met schaalmechanismen: afhankelijk van de runtime-omgeving van uw toepassing kunt u verschillende schaalmechanismen gebruiken om de resources aan te passen die aan de toepassing zijn toegewezen.
Schaalregels configureren: definieer de schaalregels die aangeven hoe uw schaaleenheid moet worden geschaald als reactie op gebeurtenissen. Deze regels kunnen worden gebaseerd op drempelwaarden, patronen of andere criteria die zijn afgestemd op de vereisten van uw toepassing. Schaaldrempels moeten betrekking hebben op zakelijke metrische gegevens. Als u bijvoorbeeld twee extra exemplaren toevoegt, kunt u 50 meer gebruikers ondersteunen bij het verwerken van winkelwagentjes.
Testen en bewaken: Valideer het gedrag van uw implementatie van schaalaanpassing op basis van gebeurtenissen door deze te testen met verschillende gebeurtenisscenario's. Bewaak de schaalacties en zorg ervoor dat de acties overeenkomen met uw verwachtingen.
Vraag en aanbod optimaliseren
Controleer de vraag ten opzichte van uw aanbod. Bij workloads waarbij het gebruik de schaal bepaalt, komen de kosten overeen met de schaalaanpassing. Als u de kosten van schalen wilt optimaliseren, kunt u de uitgaven voor schalen minimaliseren. U kunt de vraag offloaden door de vraag te distribueren naar andere resources, of u kunt de vraag verminderen door prioriteitswachtrijen, gateway-offloading, buffering en snelheidsbeperking te implementeren. Beide strategieën kunnen ongewenste kosten als gevolg van schalen en resourceverbruik voorkomen. U kunt het aanbod ook beheren door de schaallimieten te beperken. Houd rekening met de volgende aanbevelingen om de vraag en het aanbod van workloads te optimaliseren.
Offloadvraag
Offloading-vraag verwijst naar de praktijk van het distribueren of overdragen van de vraag naar resources naar andere resources of services. U kunt verschillende technologieën of strategieën gebruiken:
Caching: gebruik caching om veelgebruikte gegevens of inhoud op te slaan, waardoor de belasting van uw back-endinfrastructuur wordt verminderd. Gebruik bijvoorbeeld netwerken voor contentlevering (CDN's) om statische inhoud in de cache op te cachen en te leveren, waardoor de back-end minder hoeft te worden geschaald. Niet elke workload kan echter gegevens opslaan in de cache. Werkbelastingen waarvoor actuele en realtime gegevens nodig zijn, zoals handels- of gameworkloads, mogen geen cache gebruiken. De gegevens in de cache zijn oud en niet relevant voor de gebruiker.
Compromis. Caching kan problemen met zich brengen op het gebied van cache-ongeldigheid, consistentie en het beheren van het verloop van de cache. Het is belangrijk om zorgvuldig cachestrategieën te ontwerpen en te implementeren om mogelijke compromissen te voorkomen.Offloading van inhoud: offloaden van inhoud naar externe services of platforms om de werkbelasting van uw infrastructuur te verminderen. In plaats van videobestanden op uw primaire server op te slaan, kunt u deze bestanden bijvoorbeeld hosten in een afzonderlijke opslagservice die onafhankelijk is van uw primaire server. U kunt deze grote bestanden rechtstreeks vanuit de opslagservice laden. Met deze aanpak worden resources op uw servers vrijgemaakt, zodat u een kleinere server kunt gebruiken. Het kan goedkoper zijn om grote bestanden op te slaan in een afzonderlijk gegevensarchief. U kunt een CDN gebruiken om de prestaties te verbeteren.
Taakverdeling: distribueer binnenkomende aanvragen over meerdere servers met behulp van taakverdeling. Taakverdeling verdeelt de workload gelijkmatig en voorkomt dat één server overbelast raakt. Load balancers optimaliseren het resourcegebruik en verbeteren de efficiëntie van uw infrastructuur.
Database-offloading: verminder de belasting op de hoofdtoepassingsserver door databasebewerkingen te offloaden naar een afzonderlijke databaseserver of een gespecialiseerde service. Gebruik bijvoorbeeld een CDN voor het opslaan van statische inhoud in de cache en een Redis-cache voor het opslaan van dynamische inhoud (gegevens uit database). Technieken zoals database-sharding, leesreplica's of het gebruik van beheerde databaseservices kunnen ook de belasting verminderen.
Afweging: Door specifieke taken naar alternatieve resources te offloaden, kunt u extra schaalaanpassing en kosten voor het schalen verminderen of voorkomen. Het is echter belangrijk om rekening te houden met de operationele en onderhoudsuitdagingen die kunnen optreden als gevolg van offloading. Het uitvoeren van een uitgebreide kosten-batenanalyse is van cruciaal belang bij het selecteren van de meest geschikte offloadingtechnieken voor uw workload. Deze analyse zorgt ervoor dat de gekozen methode zowel efficiënt als haalbaar is in relatie tot de verwachte besparingen en operationele complexiteit.
Vraag verminderen
Het verminderen van de vraag naar resources betekent het implementeren van strategieën die helpen bij het minimaliseren van het resourcegebruik in een workload. Offloading van de vraag verschuift de vraag naar andere resources. Het verminderen van de vraag vermindert de vraag naar de workload. Door de vraag te verminderen, kunt u overprovisioning van resources voorkomen en betalen voor ongebruikte of onderbenutte capaciteit. U moet ontwerppatronen op codeniveau gebruiken om de vraag naar workloadresources te verminderen. Volg deze stappen om de vraag te verminderen via ontwerppatronen:
Inzicht in ontwerppatronen: maak uzelf vertrouwd met verschillende ontwerppatronen die resourceoptimalisatie bevorderen.
Vereisten voor workloads analyseren: evalueer de specifieke vereisten van uw workload, inclusief de verwachte vraagpatronen, piekbelastingen en resourcebehoeften.
Selecteer de juiste ontwerppatronen: kies de ontwerppatronen die zijn afgestemd op de vereisten en doelstellingen van uw workload. Als uw workload bijvoorbeeld te maken heeft met een fluctuerende vraag, kunnen gebeurtenisgestuurde schaal- en beperkingspatronen helpen de workload te beheren door resources dynamisch toe te wijzen. Pas de geselecteerde ontwerppatronen toe op uw workloadarchitectuur. Mogelijk moet u workloadonderdelen scheiden, toepassingen containeriseren, opslaggebruik optimaliseren en meer.
Continu bewaken en optimaliseren: Evalueer regelmatig de effectiviteit van de geïmplementeerde ontwerppatronen en pas deze indien nodig aan. Bewaak het resourcegebruik, metrische prestatiegegevens en mogelijkheden voor kostenoptimalisatie.
Door deze stappen te volgen en de juiste ontwerppatronen te gebruiken, kunt u de vraag naar resources verminderen, de kosten optimaliseren en zorgen voor een efficiënte werking van hun workloads.
Gebruik deze ontwerppatronen om de vraag te verminderen:
Cache apart: het patroon controleert de cache om te zien of de gegevens al in het geheugen zijn opgeslagen. Als de gegevens in de cache worden gevonden, kan de toepassing de gegevens snel ophalen en retourneren, waardoor er minder query's hoeven te worden uitgevoerd op het permanente gegevensarchief.
Claimcontrole: door gegevens te scheiden van de berichtenstroom, vermindert dit patroon de grootte van berichten en ondersteunt een kosteneffectievere oplossing voor berichten.
Concurrerende consumenten: met dit patroon worden items in een wachtrij efficiënt verwerkt door gedistribueerde en gelijktijdige verwerking toe te passen. Dit ontwerppatroon optimaliseert de kosten door te schalen op basis van de wachtrijdiepte en limieten in te stellen voor maximale gelijktijdige consumentenexemplaren.
Consolidatie van rekenresources: dit patroon verhoogt de dichtheid en consolideert rekenresources door meerdere toepassingen of onderdelen in een gedeelde infrastructuur te combineren. Het maximaliseert het resourcegebruik, vermijdt ongebruikte ingerichte capaciteit en verlaagt de kosten.
Implementatiestempels: Het gebruik van implementatiestempels biedt verschillende voordelen, zoals het geografisch distribueren van groepen apparaten, het implementeren van nieuwe functies voor specifieke zegels en het observeren van de kosten per apparaat. Implementatiestempels zorgen voor betere schaalbaarheid, fouttolerantie en efficiënt resourcegebruik.
Gateway-offloading: met dit patroon wordt de verwerking van aanvragen op een gatewayapparaat offload, waarbij de kosten van resources per knooppunt worden omgeleid naar de gateway-implementatie. Het gebruik van dit ontwerppatroon kan leiden tot lagere eigendomskosten in een gecentraliseerd verwerkingsmodel.
Uitgever/abonnee: met dit patroon worden onderdelen in een architectuur losgekoppeld, waarbij directe communicatie wordt vervangen door een tussenliggende berichtenbroker of gebeurtenisbus. Het maakt een gebeurtenisgestuurde benadering en facturering op basis van verbruik mogelijk, waardoor overprovisioning wordt voorkomen.
Load leveling op basis van wachtrij: het patroon buffert binnenkomende aanvragen of taken in een wachtrij. De buffering maakt de werkbelasting soepeler en vermindert de noodzaak van overprovisioning van resources om piekbelasting te verwerken. Binnenkomende aanvragen worden asynchroon verwerkt om de kosten te verlagen.
Sharding: Met dit patroon worden specifieke aanvragen naar een logische bestemming geleid, waardoor optimalisaties met colocatie van gegevens mogelijk zijn. Sharding kan leiden tot kostenbesparingen door meerdere exemplaren van reken- of opslagresources met een lagere specificatie te gebruiken.
Hosting van statische inhoud: Dit patroon levert efficiënt statische inhoud door gebruik te maken van een hostingplatform dat hiervoor is ontworpen. Het voorkomt het gebruik van duurdere dynamische toepassingshosts, waardoor het resourcegebruik wordt geoptimaliseerd.
Beperking: Met dit patroon worden limieten ingesteld voor de snelheid (snelheidsbeperking) of doorvoer van binnenkomende aanvragen naar een resource of onderdeel. Het helpt bij het informeren van kostenmodellering en kan rechtstreeks worden gekoppeld aan het bedrijfsmodel van de toepassing.
Valetsleutel: Dit patroon verleent veilige en exclusieve toegang tot een resource zonder dat er meer onderdelen nodig zijn, waardoor de behoefte aan intermediaire resources wordt verminderd en de efficiëntie wordt verbeterd.
Toevoer controleren
Het definiëren van een bovengrens voor het bedrag dat u bereid bent te besteden aan een bepaalde resource of service is een manier om het aanbod te beheren. Het is een belangrijke strategie om de kosten onder controle te houden en ervoor te zorgen dat de uitgaven een bepaald niveau niet overschrijden. Stel een budget in en controleer de uitgaven om ervoor te zorgen dat deze binnen het gedefinieerde bedrag blijven. U kunt platformen voor kostenbeheer, budgetwaarschuwingen gebruiken of gebruiks- en bestedingspatronen bijhouden. Met sommige services kunt u leverings- en limietsnelheden beperken, en u moet deze functies gebruiken waar nuttig.
Het beheren van het aanbod verwijst naar het definiëren van een bovengrens voor het bedrag dat u bereid bent te besteden aan een bepaalde resource of service. Het is een belangrijke strategie omdat het helpt bij het beheersen van de kosten en ervoor zorgt dat de uitgaven een bepaald niveau niet overschrijden. Stel een budget in en controleer de uitgaven om ervoor te zorgen dat deze binnen de gedefinieerde drempelwaarde blijven. U kunt platformen voor kostenbeheer, budgetwaarschuwingen gebruiken of gebruiks- en bestedingspatronen bijhouden. Met sommige services kunt u leverings- en limietsnelheden beperken, en u moet deze functies gebruiken waar nuttig.
Azure-facilitering
Uitschalen versus omhoog schalen evalueren: Azure biedt een testomgeving waarin u verschillende schaalconfiguraties kunt implementeren en testen. Door de werkelijke workloadgegevens of proxygegevens te gebruiken, kunt u praktijkscenario's simuleren en de effecten op de kosten meten. Azure biedt hulpprogramma's en services voor prestatietests, belastingstests en bewaking, waarmee u de kosteneffectiviteit van uitschalen en omhoog schalen kunt evalueren.
Azure biedt aanbevelingen voor kostenbeheer via verschillende hulpprogramma's en services, zoals Azure Advisor. Deze aanbevelingen analyseren uw gebruikspatronen, resourcegebruik en schaalconfiguraties om inzichten en suggesties te bieden voor het optimaliseren van de kosten.
Azure Load Testing is een volledig beheerde taaktestservice die grootschalige belasting genereert. De service simuleert verkeer voor uw toepassingen, ongeacht waar ze worden gehost. Ontwikkelaars, testers en QA-technici (Quality Assurance) kunnen belastingstests gebruiken om de prestaties, schaalbaarheid of capaciteit van toepassingen te optimaliseren.
Automatische schaalaanpassing optimaliseren: veel Azure-rekenservices ondersteunen het implementeren van meerdere identieke exemplaren en het snel afstemmen van de schaaldrempels en beleidsregels. Azure biedt mogelijkheden voor automatisch schalen waarmee u het aantal exemplaren of resources automatisch kunt aanpassen op basis van de vraag naar workloads. U kunt schaalregels en drempelwaarden definiëren om acties voor uitschalen of inschalen te activeren. Door automatische schaalaanpassing te gebruiken, kunt u resourcetoewijzing en kostenefficiëntie optimaliseren door resources dynamisch te schalen op basis van de werkelijke vraag.
Azure houdt een lijst met abonnements- en servicelimieten bij. Er is een algemene limiet voor het aantal exemplaren van een resource dat u in elke resourcegroep kunt implementeren, met enkele uitzonderingen. Zie Limieten voor resource-exemplaren per resourcegroep voor meer informatie.
Vraag en aanbod optimaliseren: Azure Monitor biedt inzicht in de prestaties en status van uw toepassingen en infrastructuur. U kunt Azure Monitor gebruiken om de belasting van uw resources te bewaken en trends in de loop van de tijd te analyseren. Met behulp van metrische gegevens en logboeken die zijn verzameld door Azure Monitor, kunt u gebieden identificeren waar aanpassingen nodig kunnen zijn. Deze informatie kan helpen bij het verfijnen van uw beleid voor automatisch schalen om ervoor te zorgen dat het overeenkomt met de niet-functionele vereisten en doelstellingen voor kostenoptimalisatie.
Offloading-levering: Azure heeft een modern Cloud Content Delivery Network (CDN) genaamd Azure Front Door en cachingservices (Azure Cache voor Redis en Azure HPC Cache). Het CDN slaat inhoud dichter bij de eindgebruikers op, waardoor de netwerklatentie wordt verminderd en de reactietijden worden verbeterd. In cache wordt een kopie van de gegevens voor het hoofdgegevensarchief opgeslagen, waardoor herhaalde aanvragen naar de back-end minder nodig zijn. Door CDN en cachingservices te gebruiken, kunt u de prestaties optimaliseren en de belasting van servers verminderen voor mogelijke kostenbesparingen.
Levering beheren: Met Azure kunt u ook resourcelimieten instellen voor uw cloudworkload. Door resourcelimieten te definiëren, kunt u ervoor zorgen dat uw workload binnen de toegewezen resources blijft en onnodige kosten voorkomen. Azure biedt verschillende mechanismen voor het instellen van resourcelimieten, zoals quota, beleid en budgetwaarschuwingen. Deze mechanismen helpen u bij het bewaken en beheren van het resourcegebruik.
API Management kunt aanvragen beperken en beperken. Het beperken van binnenkomende aanvragen is een belangrijke rol van Azure API Management. Door de snelheid van aanvragen of het totale aantal aanvragen/overgedragen gegevens te beheren, kunnen API MANAGEMENT API-providers hun API's beschermen tegen misbruik en waarde creëren voor verschillende API-productlagen.
Verwante koppelingen
- De workload schalen
- Kostenaanbeveling voor Azure Advisor
- Wat is Azure Load Testing?
- Limieten, quota's en beperkingen voor het Azure-abonnement en de Azure-service
- Resources niet beperkt tot 800 exemplaren per resourcegroep
- Wat is Azure Front Door?
- Wat is Azure Cache voor Redis?
- Wat is Azure HPC Cache?
- Geavanceerde aanvraagbeperking met Azure API Management
Controlelijst voor kostenoptimalisatie
Raadpleeg de volledige set aanbevelingen.
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor