Hvordan lagrer du 100M log-events per dag?

Question

IT Interview Practice · Accepted Answer

Bygg en **append-only pipeline: agenter → Kafka → tiered storage (hot i ClickHouse/ELK, cold i object storage)** med en retention-policy som indekserer nylig data og arkiverer resten billig. 100M events/dag er ~1 200/sek i snitt (spikes langt høyere) og titalls-til-hundrevis av GB daglig — du optimaliserer for billige writes og avgrenset query-kostnad, ikke OLTP-semantikk.

```text
App/agenter ─▶ Kafka ─▶ Consumers ─┬─▶ ClickHouse / ELK   (hot: siste 7–30d, indeksert, rask søk)
 (Fluent Bit)  (buffer,             │
                replay)             └─▶ S3/Parquet         (cold: 90d–år, billig, scan-on-demand)
                                          │
                                   Lifecycle/tiering ─▶ Glacier (arkiv) ─▶ slett ved retention
```

## Append-pipeline

Logger er write-once, aldri oppdatert — så ingest-stien er en **append**. Agenter som **Fluent Bit / Vector** sender linjer til **Kafka**, som buffrer bursts og avkobler produsenter fra lagring. Hvis ClickHouse er nede for vedlikehold, køes events i Kafka og replayes — du dropper ikke logger. Batch writes (tusenvis av rader per insert) fordi per-rad-inserts ødelegger throughput på columnar stores.

## Hot store: indekser for søk

Nylige logger trenger rask søk ("errors siste time for service X"). **ClickHouse** (columnar, komprimerer 10x, scanner milliarder av rader/sek) eller **ELK-stacken** (Elasticsearch inverted index) betjener dette. Partisjoner på dag/service slik at spørringer beskjærer til noen få partisjoner. Dette laget er dyrt per GB, så hold det lite — kun de siste 7–30 dagene.

## Cold store: object storage + tiering

Eldre logger flyttes til **S3 som Parquet** — billig, varig, spørrbar on demand via Athena/Trino. En **lifecycle-policy** overfører S3 → Glacier → sletting ved retention-grensen din (f.eks. 1 år). Denne *tiering*-en er den sentrale kostnadsspaken: hot storage kan være 50x prisen av arkivering.

## Intervjuperspektiv

Intervjuere undersøker **indeks-vs-kostnad-avveiningen**: å indeksere alt gir utmerket søk men sprenger budsjettet; å indeksere ingenting er billig men uspørrbart. Bra: "bruk ELK." Utmerket: du tierer — indekser den nylige hot skiven, arkiver resten cold — og navngir Kafka som bufferet som gjør ingestion motstandsdyktig mot nedstrøms utfall.

**Vanlig felle:** å legge alle logger i Elasticsearch for alltid. Det er det dyreste alternativet og klusteret dets faller over på kardinalitet/retention du ikke planla for.

## Avveininger og feilmoduser

- **Retention vs kostnad:** lengre retention = lineær lagringsvekst; tier aggressivt.
- **Kafka backpressure:** hvis consumers henger etter, fylles disk — dimensjoner retention og overvåk lag.
- **Kardinalitetseksplosjon:** høykardinalitetsfelt (user_id) blåser opp ES-indekser; sample eller dropp dem.
- **Query-kostnad på cold data:** Athena-scans koster per TB — partisjoner Parquet på dato/service slik at scans forblir avgrenset.
- **At-least-once-dupliktater:** dedup på en event-id hvis eksakte tellinger betyr noe.

Append-pipeline

Hot store: indekser for søk

Cold store: object storage + tiering

Intervjuperspektiv

Avveininger og feilmoduser

Relaterte spørsmål