Hvordan skalerer du individuelle tjenester og finner ytelsesflaskehalser?

Question

Accepted Answer

En nøkkelfordel med mikrotjenester er **skalering av hver tjeneste uavhengig** for å tilpasse dens egen belastning, i stedet for å skalere hele appen. Å finne flaskehalser er da et spørsmål om å måle per-tjeneste og per-hop.

## Skaleringstekniker

- **Horisontal skalering** — legg til tilstandsløse instanser bak en lastbalanser.
- **Autoskalering** — skalering basert på CPU, minne, køsdybde eller egendefinerte metrikker.
- **Caching** — reduser gjentatt arbeid og nedstrøms belastning.
- **Async + køer** — absorbér topper; koble fra tung arbeid.
- **Dataskalering** — lesesekundærer, sharding, per-tjeneste lagre.

```yaml
# Kubernetes HPA: scale orders on CPU
minReplicas: 3
maxReplicas: 20
metric: cpu
targetUtilization: 70   # add pods when avg CPU > 70%
```

## Finne flaskehalser

```text
1. Metrics: which service has high latency / saturation? (RED/USE)
2. Traces: which SPAN in the request is slow?
3. Drill in: DB query? lock? N+1 calls? GC pause?
```

```text
Gateway ──┤ Orders ──┤ Payments ████████████ ← 80% of latency here
                       Inventory ─┤
```

## Vanlige flaskehalser

```text
⚠️ Chatty synchronous calls (fan-out per request)
⚠️ Shared/overloaded database
⚠️ Missing or cold cache
⚠️ Unbounded retries amplifying load
```

## Fallgruve

Skalering av en tjeneste hvis flaskehals er en **delt database** flytter bare mer belastning til databasen — skalér den faktiske begrensningen, ikke symptomet.

## Hvorfor det er viktig

Uavhengig skalering lar deg bruke kapasitet nøyaktig der belastningen er, noe som er langt billigere enn å skalere en monolitt wholesale.

Men blind skalering sløser med penger og kan gjøre ting verre; måling av per-tjeneste metrikker og per-hop spor er hva som forteller deg den virkelige begrensningen som skal fikses.