Belasting versus Gebruik

Twee verschillende getallen, beide vereist

Capaciteitsplanning faalt wanneer teams slechts één van de twee essentiële dimensies meten.

Belasting: de vraag op het systeem van buiten. Verzoeken per seconde, transacties per minuut, megabytes per seconde, gelijktijdige gebruikers. Belasting beschrijft wat de wereld van je vraagt.

Gebruik: hoe vol het systeem draait terwijl het die vraag bedient. CPU-percentage, gebruikt geheugen, wachtrijdiepte, netwerkbandbreedte, disk-IOPS. Gebruik beschrijft hoe het systeem zich onder die vraag voelt.

Alleen belasting vertelt je wat eraan komt maar niet of je het kunt serveren. Alleen gebruik vertelt je hoe vol je bent maar niet wat je morgen verwacht. Je hebt beide nodig, naast elkaar uitgezet, om capaciteitsbeslissingen te nemen.

Capaciteitsratio = belasting / gebruik. Als je 1.000 verzoeken per seconde bedient bij 50% CPU, is je capaciteitsratio 2.000 RPS per 100% CPU per server. Deze conversiefactor laat je voorspelde belasting vertalen naar vereiste serverhoeveelheid.

Allspaw benadrukt het meten op de juiste granulariteit. Eén meting per minuut verbergt pieken van 30 seconden. Eén meting per uur verbergt alles. Echt capaciteitswerk vereist sub-minuutresolutie voor piekevenementen en minuutresolutie voor trends. Alles grover leidt tot gevaarlijk valse zekerheid.

Wat moet je inzetten

Je team lanceert capaciteitsinstrumentatie op een nieuwe productlancering (een videotranscodeservice). Je kunt maximaal 8 metrieke gegevens kiezen om op sub-minuutresolutie te volgen. De service neemt videoupload in, zet ze in een wachtrij, transcoderend in meerdere formaten, & schrijft outputs naar objectopslag.

Trend, Cycliciteit, Onzekerheid

Drie lagen van elke prognose

Allspaw en het Google SRE-boek zijn het eens over de structuur van een bruikbare prognose: trend, cycliciteit, & onzekerheidsmarges. Sla een van deze over en de prognose wordt misleidend.

Trend: de helling van de vraag over maanden of jaren. Vaak gemodelleerd met lineaire regressie voor korte vensters, exponentieel of stuksgewijs-lineair voor samengestelde groei. De trendlijn beantwoordt 'waar gaat de vraag in het algemeen heen?'

Cycliciteit: de cyclische patronen op meerdere tijdschalen. Dagelijks (piekverkeer in de middag), wekelijks (weekendpieken), jaarlijks (Black Friday, belastingseizoen, schooljaar). Multiplicatieve cycliciteit schaalt met de trend; additieve cycliciteit voegt een constant offset toe.

Onzekerheidsmarges: de prognosekegel. Een prognose zonder marges is een gok. Echte prognoses publiceren een centraal schattingswaarde met expliciete boven- en ondermarges, typisch op 90% of 95% betrouwbaarheid. De kegel verbreden naarmate je verder in de toekomst projecteert. Een prognose van 4 weken kan ±10% marges hebben; een prognose van 12 maanden heeft vaak ±50%.

Bedrijfsgroei van technische vraag scheiden: capaciteitsplanners prognosticeren technische belasting, maar bedrijfsteams prognosticeren inkomsten, aanmeldingen, of campagnes. Het werk van de capaciteitsplanner is bedrijfsprognoses in technische vraag vertalen: een groei van 30% aanmeldingen kan 30% meer API-aanroepen betekenen, maar het kan 80% meer zijn als nieuwe gebruikers het systeem zwaarder gebruiken, of slechts 15% als ze converteren met lagere tarieven. De conversieratio telt even zwaar als de onderliggende bedrijfsprognose.

Vakantieverkeerspronosticering

Je service bedient een e-commercesite. Het verkeer op Black Friday vorig jaar was 5x het gemiddelde in november, volgehouden over 12 uur. Het bedrijf is met 40% per jaar gegroeid. Marketing lanceert een betaalde promotie waarvan wordt verwacht dat deze dit jaar nog eens 20% aan Black Friday-verkeer toevoegt.

Je plafond kennen

Vind het plafond voordat productie het doet

Prognoses vertellen je wat eraan komt. Plafondtests vertellen je of het systeem het kan serveren. Allspaw behandelt plafondtesting als een onontkoombaarwaardig gegeven voor capaciteitsplanning: je kent je werkelijke capaciteit niet totdat je het onder gecontroleerde belasting hebt getest.

Drie soorten plafondtests:

- Synthetische belastingstest: een belastingsgenerator (k6, Locust, JMeter, vegeta) voert doelverkeer naar een service in staging. Verhoog belasting totdat iets breekt. Het breekpunt is het plafond. Het beste voor geïsoleerde servicetest.

- Productie-oefening: verlaag opzettelijk capaciteit in productie (drain een percentage servers, dood een regio) en observeer hoe de resterende capaciteit werkelijk verkeer aankan. Test werkelijk productiegedrag inclusief onverwachte interacties. Hoogste vertrouwen maar hoogste risico.

- Schaduwbelasting: speel werkelijk productieverkeer af op een doelservice die parallel aan productie draait. Vangt werkelijke werkloadpatronen (zeldzame querymix, rare useragents) zonder gebruikers te beïnvloeden. Sterke middengrond.

Bufferruimte is de buffer tussen huidige belasting en het plafond. SRE-vuistregels:

- 50% bufferruimte in steady state voor een single-regio-service (zodat een regiofalen de overgebleven regio niet uitput)

- 30% bufferruimte voor een multi-regia-service met N+2 redundantie

- 100%+ bufferruimte benaderend bekende piekgebeurtenissen (Black Friday, sportfinales)

Bufferruimte is geen verspilling. Het is de kosten om engineers om 3 uur 's nachts niet op te roepen, klanten niet kwijt te raken tijdens een piek, en geen cascadefalen te lijden wanneer één regio faalt. Financiële teams duwen soms om bufferruimte te verminderen; capaciteitsingenieurs moeten de kosten van strak draaien articuleren om dat gesprek feitelijk in plaats van emotioneel te maken.

Een plafondtestprogramma ontwerpen

Je erft een service met geen gedocumenteerd capaciteitsplafond. Huidge productiebelasting is 800 verzoeken per seconde over 12 servers, gemiddeld CPU 35%. Marketing kondigt een campagne in 6 weken aan waarvan wordt verwacht dat deze verkeer naar 3.000 RPS op piek drijft.

Omhoog, uit, of diagonaal

Wanneer voeg je kracht toe, voeg je dozen toe, of beide

Drie kernschaalstrategieën, elk met duidelijk onderscheid kosten- en betrouwbaarheidsprofiel:

Verticale schaling (omhoog schalen): grotere machines. Vervang 8-core servers met 32-core servers. Eenvoudigste pad; werkt totdat je limiet van één machine raakt. Enkel storingspunt blijft. Kosten groeien niet-lineair: een 32-core machine kost vaak meer dan 4x een 8-core.

Horizontale schaling (uit schalen): meer machines. Voeg servers achter een load balancer toe. Capaciteit schaalt lineair met serveraantal. Storingsmodi verschuiven: je moet gedistribueerde coördinatie afhandelen, maar een serverfalen vernietigt niet langer de service. Operationele complexiteit neemt toe.

Diagonale schaling (Allspaw's term): schaaal eerst omhoog naar een comfortabele grootte per server, schaaal dan uit vanuit daar. Combineert eenvoudiger operations van grote servers met redundantie van meerdere servers. De meeste productieservices leven in diagonaal schaalgebied.

Gereserveerde versus on-demand prijzen: cloudproviders belonen voorspelbaarheid. Gereserveerde capaciteit is 30-60% goedkoper dan on-demand maar vereist een verplichting van 1-3 jaar. Capaciteitsplanners vergrendelen typisch steady-state vraag met gereserveerde capaciteit en burst in on-demand voor pieken. Verkeerde beoordeling van deze split kan geld verspillen (over-gereserveerd) of budget blootstellen aan verrassing (onder-gereserveerd tijdens pieken).

Spot instances en onderbreekbare workloads: 60-90% goedkoper dan on-demand maar kunnen worden teruggeëist met minuten kennisgeving. Geschikt voor batchjobs, analytics, training workloads, of elke service ontworpen voor graceful onderbreking. Productie gebruiker-gericht verkeer vermijdt typisch spot.

Een schaalpad kiezen

Je videotranscodeservice draait op 8 gemiddelde cloudinstanties (8 cores elk). Je verwacht 3x groei over de komende 6 maanden. De workload is CPU-gebonden, paralleliseerbaar per video, & elke videotranscodeer duurt 90 seconden end-to-end. Gereserveerde instances kosten 50% van on-demand. Spot instances kosten 30% van on-demand maar kunnen met 2 minuten kennisgeving worden beëindigd.

Capaciteitsplanningscarrières

Waar capaciteitsplanningsvaardigheden betaald worden

Capaciteitsplanning is zelden een jobtitel op zichzelf. De vaardigheden verschijnen onder verschillende rollen:

Site-betrouwbaarheidsingenieur: capaciteitsplanning is een kernverantwoordelijkheid van SRE. De meeste SRE-teams hebben één of twee ingenieurs die zich in capaciteit specialiseren, eigenaar van de prognosemodellen, plafondtests, en inrichtingsautomatisering.

Cloud-kosten / FinOps-ingenieur: een nieuwere rol gericht op optimalisatie van clouduitgaven. Combineert capaciteitsplanning met financiële modellering, contractonderhandeling, en gereserveerd-instance-portfoliobeheer. Betaalt uitzonderlijk goed bij grote cloud-native bedrijven omdat cloudrekeningen vaak de tweede grootste uitgave na loonlijst zijn.

Prestatieingenieur: concentreert zich op per-node-efficiëntie en plafondtesting. Het werk: haal meer capaciteit uit dezelfde hardware door profilering, optimalisatie, & architecturale veranderingen. Zware systemen en taal-runtime-kennis.

Capaciteitsplanningsspecialist: bij zeer grote bedrijven (Google, Meta, Amazon, Netflix) bestaan de toegewijde capaciteitsplanningsteams. Ze bezitten prognosemodellen over de volledige vloot, onderhandelen aanschaffing op schaal, & coördineren met financiën op multi-jaarlijkse hardware-roadmaps.

Vaardigheden die samengesteld: tijdserieanalyse (R, Python statsmodels, Prophet), wachtrijtheorie (M/M/1, M/M/c, Little's Law), minstens één configuratiebeheertool, minstens één cloudbkostendashboard, & het vermogen om een prognoserapport te schrijven dat een CFO kan begrijpen en kan handelen. De technische vaardigheden krijgen je het interview; de communicatievaardigheden krijgen je het budget.

Afsluiting

Wat je nu weet

Capaciteitsplanning is een continue discipline, niet een jaarlijkse oefening. Je hebt behandeld:

- De corridor tussen onderinrichting en overinrichting

- Belasting versus gebruik als de twee dimensies van meting

- Trend, cycliciteit, & onzekerheidsmarges als de drie lagen van elke prognose

- Plafondtests (synthetisch, schaduw, oefening) als de enige manier om werkelijke capaciteit te kennen

- Bufferruimtebuffers en waarom zij geen verspilling zijn

- Diagonale schaling & de gereserveerd/on-demand/spot-prijsbeslissing

- Carriërepaden waar deze vaardigheden budgetautoriteit verdienen

Twee ideeën tellen het meest. Prognosticeer met marges, nooit met enkele punten. & meet je plafond voordat productie het doet. Draag deze twee vooruit en de rest volgt.

Aanbevolen lectuur: Allspaw's 'The Art of Capacity Planning' (O'Reilly, 2017 tweede editie), de relevante hoofdstukken in Google's SRE-boek (gratis op sre.google/books/), & Brendan Gregg's 'Systems Performance' voor het onderliggende systeemwerk. De geometrie-van aanvullende les gaat dieper in op de visuele structuur: Little's Law als gebied, wachtrijcurven, trendhellingen, & bufferruimteomsluiting.