Voorbereiden op groei
Je hebt waarschijnlijk gehoord dat voorbereiding de sleutel is tot succes. Dit gezegde geldt vooral voor een soepele, succesvolle, betrouwbare groei.
Een van de grootste voordelen van cloud-computing is de mogelijkheid om te schalen. Deze mogelijkheid heeft geleid tot een aantal onjuiste veronderstellingen dat het niet nodig is om groei in de cloud voor te bereiden of te plannen, omdat deze oneindige schaal heeft.
Het is waar dat er waarschijnlijk meer dan voldoende resources in de cloud zijn om te voldoen aan de eisen van uw toepassing. Er zijn echter een aantal redenen waarom het nog steeds belangrijk is om inzicht te krijgen in uw capaciteitsbehoeften:
Hoewel er waarschijnlijk veel resources in de cloud zijn om aan uw behoeften te voldoen, zijn niet alle services die u gebruikt automatisch geschaald of inherent schaalbaar. Daarom moet u rekening houden met servicelimieten en weten wanneer u services en resources moet opschalen.
Cloudresources zijn mogelijk onbeperkt, maar uw budget is waarschijnlijk niet. U moet rekening houden met de kosten en uw vrienden op de afdeling Financiën willen weten wat uw geraamde clouduitgaven zijn.
Plan voor organische groei
Organische groei in de bedrijfswereld verwijst naar het proces waarmee organisaties hun eigen capaciteit uitbreiden, afhankelijk zijn van intrinsieke resources en vaardigheden om een tragere, natuurlijkere groei te stimuleren.
Het eerste wat u moet doen om cloudcapaciteit te plannen naarmate uw bedrijf organisch groeit, is de huidige resourcevereisten in kaart brengen voor de grotere componenten van uw applicatie.
Scenario: Organische groei
We gaan terug naar de architectuur die we vroeg in deze module hebben bekeken. Tailwind Traders staat op het punt om een innovatief nieuw product te lanceren en verwacht als gevolg hiervan een dramatische groei. Om u eraan te herinneren, ziet het architectuurdiagram er als volgt uit.
Als u wilt beginnen met capaciteitsplanning, moet u de grotere onderdelen identificeren. In dit voorbeeld dat bevat:
- Azure Kubernetes Service-cluster
- Rewards-app die wordt uitgevoerd in Azure App Service
- Verschillende databases, zoals Cosmos DB, Azure SQL en dergelijke.
Voor elk van deze grote onderdelen moet u begrijpen wat het huidige resourcegebruik is, om u te helpen bij het plannen van toekomstig gebruik. Laten we het resourcegebruik voor een van deze grote onderdelen doorlopen.
Capaciteit meten in Cosmos DB
In Cosmos DB wordt opslag automatisch gemeten in gigabytes en schaalt, hoewel u nog steeds rekening moet houden met de metingen om kostenredenen.
Doorvoer is vooraf ingericht en u gebruikt een metrische waarde met de naam aanvraageenheden om deze doorvoer te meten. Aanvraageenheden (RU's) zijn een combinatie van geheugen, CPU en IOPS, waardoor u één metriek krijgt waarmee u capaciteit kunt plannen. Je richt RU's in stappen van 100 RU's per seconde in.
Elke DB-bewerking wordt gemeten in RU/s. Leesbewerkingen zijn eenvoudig: 1 kB lezen is één aanvraageenheid. Andere bewerkingen worden berekend op basis van verschillende factoren, zoals itemgrootte, gegevensconsistentie, querypatronen, enzovoort.
Wanneer u uw toepassing profileert, bevat elk antwoord van Cosmos DB de aanvraagheader, waarin u precies wordt geïnformeerd over hoeveel RU's die aanvraag heeft gebruikt. U kunt het aantal RU's dat wordt gebruikt vergelijken met het aantal dat is ingericht om te controleren of u meer dan voldoende huidige capaciteit hebt.
Het is goed om uw resourcegebruik te correleren met een zakelijke metrische gegevens, zoals maandelijkse actieve gebruikers of inkomsten. Met deze correlatie kunt u capaciteit plannen op basis van hoe u verwacht dat het bedrijf groeit. U kunt deze metrische capaciteitsgegevens ophalen in Azure Monitor. Inzicht in het resourcegebruik van het systeem helpt u te weten wanneer u omhoog moet schalen en wat uw kosten in de loop van de tijd zullen zijn.
Laten we concreter worden en kijken naar de gegevens van Tailwind Traders die gebruikmaken van Cosmos DB. Hier volgt een grafiek van hun gebruik.
In dit voorbeeld groeien Tailwind-handelaren met gemiddeld 2500 maandelijkse actieve gebruikers (MAU's) met een huidige gebruikersbasis van 10.000.
Als we opslag bekijken, kunnen we zien dat hun database 300 GB van de beschikbare 5 TB (6%) gebruikt. Het groeit met 1% of 50 GB per maand.
Vanuit doorvoerperspectief staat het op 300/1000 en groeit het met 10%/maand.
Nu we inzicht hebben in de metrische gegevens van onze systemenresources, weten we wanneer we waarschijnlijk onze doorvoer moeten schalen en ook wat onze kosten in de loop van de tijd zijn.
We kunnen nu een grafiek maken die ons helpt bij het plannen van capaciteit.
Nu weten we dat we in mei de capaciteit van RU's in onze database gaan bereiken, dus moeten we eerst schalen. Een ander interessant inzicht is dat ze hun Cosmos DB-database op dit moment zelfs kunnen omlaag schalen omdat ze nergens in de buurt van de vooraf ingerichte capaciteit werken.
Plan voor anorganische groei
In het vorige voorbeeld was u van plan om organische groei te realiseren. Anorganische groei ontstaan door externe factoren in plaats van een toename van de eigen bedrijfsactiviteiten van het bedrijf. In plaats van een natuurlijke progressie te zijn, is het meestal een meer plotselinge en grotere toename van het gebruik.
Soms weet u echt niet van tevoren over een toename van verkeer, gebruikers enzovoort. In afwachting van zulke gevallen moet u uw systeem zo schaalbaar mogelijk maken op een automatische manier en op een nette manier mislukken wanneer dat niet mogelijk is. We behandelen dit verderop in deze module.
In andere gevallen kunt u, net als bij een aanstaande productlancering, anorganische groei ervaren waarvoor u kunt plannen en voorbereiden. Als uw teams samenwerken in engineering, product, marketing en financiën en u weet hoe u uw resourcegebruik en groeipatronen kunt verkrijgen. U kunt een redelijke inspanning leveren om de impact van deze gebeurtenissen op uw resourcevereisten te voorspellen en wijzigingen dienovereenkomstig te implementeren.
Dit goed doen is specifiek voor uw organisatie en de enkele gebeurtenis. Je krijgt het misschien niet altijd goed, maar als je zo goed mogelijk voorbereid bent, geeft dat je een voorsprong.
Scenario: Anorganische groei
Laten we eens kijken naar een andere hypothetische situatie als voorbeeld van het plannen van anorganische groei. Er is een gepland marketingevenement voor de lancering van een hoogwaardig innovatief nieuw product bij Tailwind Traders. Ze verwachten dat ze 5000 meer gebruikers naar hun verkoopsite sturen.
Door gegevens uit het vorige voorbeeld van organische groei te gebruiken en deze, hopelijk met causaliteit, te correleren met een zakelijke metrische gegevens die u hebt verkregen van uw product-/marketingteams (bijvoorbeeld het aantal gebruikers). U kunt beginnen met het plannen van anorganische groei.
U weet uit het vorige scenario dat u voor 2500 gebruikers ongeveer 50 GB opslagruimte en 100 RU's nodig hebt. U kunt deze gegevens nu gebruiken en bepalen of u klaar bent voor deze gebeurtenis. Als we 5000 gebruikers kunnen verwachten, is er 100 GB opslagruimte en 200 RU/s vereist.
We kunnen zien dat de opslagcapaciteit meer dan voldoende is voor de verwachte groei van de gebeurtenis. Deze capaciteiten worden automatisch voor u geschaald, dus u hoeft zich hier geen zorgen te maken, met uitzondering van inzicht in de nieuwe kosten, die later worden aangepakt.
U kunt ook voorspellen dat hun RU's na het evenement slechts 50% capaciteit zullen bereiken. Ze hebben dus geen zorgen in termen van Cosmos DB-capaciteit voor deze gebeurtenis.
Er zal echter gevolgen zijn voor de kosten.
U kunt zien dat de 100 GB extra opslagruimte een extra $ 25/maand kost. De doorvoerprijs blijft hetzelfde als klanten betalen voor toegewezen RU's, en ze hebben al meer dan genoeg. De bottom line is dat deze marketingevenement waarschijnlijk hun CosmosDB-factuur met $ 25 USD zal verhogen.