Miten skaalaat yksittäisiä palveluja ja löydät suorituskyvyn pullonkaulat?

Question

Accepted Answer

Mikropalveluiden keskeinen etu on **jokaisen palvelun riippumaton skaalaus** sen omaa kuormitusta vastaavaksi koko sovelluksen skaalaamisen sijaan. Pullonkaulojen löytäminen on siis kysymys palvelukohtaisesta ja hypykohtaisesta mittauksesta.

## Skaalaustekniikat

- **Horisontaalinen skaalaus** — lisää tilattomia instansseja kuormantasaimen taakse.
- **Autom skaalaus** — skaalaa CPU:n, muistin, jonon syvyyden tai mukautettujen mittareiden perusteella.
- **Välimuistitus** — vähennä toistuvia töitä ja loppupään kuormitusta.
- **Asynkroninen + jonot** — ime huiput; irroita hidas työ.
- **Tietojen skaalaus** — lukemisen replikat, sharding, palvelukohtaiset varastot.

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

## Pullonkaulojen löytäminen

```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 ─┤
```

## Yleiset pullonkaulat

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

## Sudenkuoppa

Palvelun skaalaus, jonka pullonkaula on **jaettu tietokanta**, siirtää vain enemmän kuormitusta tietokantaan — skaalaa todellista rajoitusta, ei oiretta.

## Miksi tämä on tärkeää

Riippumaton skaalaus antaa sinulle mahdollisuuden käyttää kapasiteettia täsmällisesti siellä, missä kuormitus on, mikä on paljon halvempaa kuin monoliittin koko mittakaavassa skaalaaminen.

Mutta sokea skaalaus tuhlaa rahaa ja voi pahentaa asioita; palvelukohtaisten mittareiden ja hypykohtaisten jäljitysten mittaaminen kertoo sinulle todellisen rajoituksen, joka pitää korjata.