Förbered för tillväxt
Du har förmodligen hört någon säga att förberedelse är nyckeln till framgång. Detta ordspråk gäller särskilt i förhållande till en smidig, framgångsrik och tillförlitlig tillväxt.
En av de största fördelarna med molnbaserad databehandling är möjligheten att skala. Den här möjligheten har lett vissa till det felaktiga antagandet att det inte finns något behov av att förbereda eller planera för tillväxt i molnet eftersom det har oändlig skala.
Det är sant att det troligtvis finns tillräckligt med resurser i molnet för att uppfylla behoven för ditt program. Det finns dock ett par orsaker till varför det fortfarande är viktigt att du förstår dina kapacitetsbehov:
Även om det troligtvis finns massor av resurser i molnet för att uppfylla dina behov skalas inte alla tjänster du använder automatiskt och alla har inte inbyggda skalningsmöjligheter. Därför måste du vara medveten om tjänstbegränsningar och veta när du behöver skala upp tjänster och resurser.
Molnresurser kan vara obegränsade, men din budget är förmodligen inte det. Du måste tänka på kostnaden och dina vänner på ekonomiavdelningen vill veta dina prognostiserade molnutgifter.
Planera för organisk tillväxt
Organisk tillväxt i affärsvärlden syftar på en process som innebär att organisationer utökar sin kapacitet genom att förlita sig på inbyggda resurser och kunskaper för att få en långsammare, mer naturlig tillväxt.
När du ska planera för kapacitet i molnet i samband med att företaget växer organiskt är det första du bör göra att kartlägga de aktuella resurskraven för de större komponenterna i ditt program.
Scenario: Organisk tillväxt
Nu ska vi gå tillbaka till arkitekturen som vi granskade tidigt i den här modulen. Tailwind Traders är på väg att lansera en innovativ ny produkt och förväntar sig en dramatisk tillväxt till följd av detta. Bara för att påminna dig, så här ser deras arkitekturdiagram ut.
Du börjar kapacitetsplaneringen med att identifiera de stora komponenterna. I det här exemplet som innehåller:
- Azure Kubernetes Service-kluster
- Belöningsapp som körs i Azure App Service
- Olika databaser, till exempel Cosmos DB, Azure SQL och liknande.
För var och en av dessa större komponenter måste du känna till vad den aktuella resursanvändningen är så att du kan planera för framtida användning. Nu ska vi gå igenom resursanvändningen för en av dessa stora komponenter.
Mäta kapacitet i Cosmos DB
I Cosmos DB mäts lagringen i gigabyte och skalas automatiskt, även om du fortfarande måste vara medveten om måtten av kostnadsskäl.
Dataflödet är företablerad och du använder ett mått som kallas Enheter för begäran för att mäta det här dataflödet. Enheter för programbegäran (RU: er) är en blandning av minne, CPU och IOPS, vilket ger dig ett enda mått som du kan planera kapacitet med. Du etablerar RU:er i steg om 100 RU:er per sekund.
Varje DB-åtgärd mäts i RU/s. Läsningar är enkla: 1 KB läsning är en enda enhet för begäran. Andra åtgärder beräknas baserat på flera faktorer, till exempel objektstorlek, datakonsekvens, frågemönster och så vidare.
När du profilerar ditt program innehåller varje svar från Cosmos DB huvudet för begärandeavgiften, vilket informerar dig om exakt hur många RU:er som begäran använde. Du kan jämföra antalet RU:er som används med det antal som har etablerats för att kontrollera att du har mer än tillräckligt med aktuell kapacitet.
Det är bra att korrelera din resursanvändning med ett affärsmått, till exempel månatliga aktiva användare eller intäkter. Den här korrelationen hjälper dig att planera för kapacitet baserat på hur du förväntar dig att verksamheten ska växa. Du kan hämta dessa kapacitetsmått i Azure Monitor. Att förstå systemets resursanvändning hjälper dig att veta när du behöver skala upp och vilka kostnader som kommer att bli över tid.
Nu ska vi få konkreta och titta på data från Tailwind Traders användning av Cosmos DB. Här är ett diagram över deras användning.
I det här exemplet växer Tailwind Traders i genomsnitt med 2 500 månatliga aktiva användare med en aktuell användarbas på 10 000.
Om vi tittar på lagring kan vi se att deras databas använder 300 GB av de 5 TB som är tillgängliga (6 %). Den växer med 1 % eller 50 GB/månad.
Ur ett dataflödesperspektiv ligger den på 300/1000 och växer med 10 %/månad:
Nu när vi förstår våra systemresursmått vet vi när vi sannolikt kommer att behöva skala vårt dataflöde och även vilka våra kostnader kommer att bli över tid.
Nu kan vi skapa ett diagram som hjälper oss med kapacitetsplanering.
Nu vet vi att vi i maj kommer att nå kapaciteten för RU:er i vår databas, så vi måste skala innan dess. En annan intressant insikt är att de kanske till och med kan skala ned sin Cosmos DB-databas just nu eftersom de inte använder någonstans i närheten av den företablerade kapaciteten.
Planera för organisk tillväxt
I föregående exempel planerade du organisk tillväxt. Oorganisk tillväxt uppstår på grund av externa faktorer snarare än en ökning av företagets egna affärsaktiviteter. I stället för att förloppet sker naturligt tenderar det uppstå en plötslig och större ökning av användningen.
Ibland vet du verkligen inte i förväg om en ökning av trafik, användare och så vidare. I väntan på sådana fall måste du skapa systemet så att det blir så skalbart som möjligt automatiskt och misslyckas korrekt när det inte är möjligt. Vi tar itu med det senare i den här modulen.
För andra gånger, som med en kommande produktlansering, kan du uppleva oorganisk tillväxt som du kan planera och förbereda dig för. Om dina team arbetar tillsammans inom teknik, produkt, marknadsföring och ekonomi, och du vet hur du får tillgång till dina resursanvändnings- och tillväxtmönster. Du kan göra en rimlig ansträngning för att förutsäga effekten av dessa händelser på dina resurskrav och implementera ändringar i enlighet med detta.
Att få detta rätt är specifikt för din organisation och den specifika händelsen. Du kanske inte alltid får det rätt, men att vara så förberedd som du kan ge dig ett försprång.
Scenario: Oorganisk tillväxt
Låt oss titta på en annan hypotetisk situation som ett exempel på planering för oorganisk tillväxt. Det finns ett kommande marknadsföringsevenemang för lanseringen av en högprofilerad innovativ ny produkt på Tailwind Traders. De förväntar sig att det kommer att driva 5000 fler användare till deras försäljningswebbplats.
Genom att använda data från föregående exempel på organisk tillväxt och korrelera dem, förhoppningsvis med orsakssamband, till ett affärsmått som du har fått från dina produkt-/marknadsföringsteam (till exempel antal användare). Du kan börja planera för oorganisk tillväxt.
Du vet från föregående scenario att för 2 500 användare behöver du cirka 50 GB lagringsutrymme och 100 RU:er. Nu kan du använda dessa data och avgöra om du är redo för evenemanget. Om vi kan förvänta oss 5 000 användare kommer det att kräva 100 GB lagringsutrymme och 200 RU/s.
Vi kan se att lagringskapaciteterna är mer än tillräckliga för den tillväxt som förväntas av händelsen. Dessa kapaciteter skalas automatiskt åt dig, så det är ingen fara här förutom att förstå de nya kostnaderna, som åtgärdas senare.
Du kan också förutsäga att deras RU:er bara når 50 % kapacitet efter händelsen. De har därför inga problem när det gäller Cosmos DB-kapacitet för den här händelsen.
Däremot kommer kostnaden att påverkas.
Du kan se att de 100 GB extra lagringsutrymmet kommer att kosta ytterligare 25 USD per månad. Dataflödespriset förblir detsamma som kunderna betalar för etablerade RU:er och de har redan mer än tillräckligt. Slutsatsen är att det här marknadsföringsevenemanget sannolikt kommer att öka deras CosmosDB-faktura med 25 USD.