Miten tallennat 100M lokitapahtumaa päivässä?

Question

IT Interview Practice · Accepted Answer

Rakenna **append-only-pipeline: agentit → Kafka → tiered storage (kuuma ClickHousessa/ELK:ssa, kylmä object storagessa)** retentiopolitiikalla, joka indeksoi tuoreen datan ja arkistoi loput halvalla. 100M tapahtumaa/päivä on ~1 200/s keskimäärin (piikit paljon korkeampia) ja kymmeniä-satoja GB päivittäin — optimoit halpojen kirjoitusten ja rajatun kyselykustannuksen mukaan, et OLTP-semantiikan.

```text
App/agents ─▶ Kafka ─▶ Consumers ─┬─▶ ClickHouse / ELK   (hot: last 7–30d, indexed, fast search)
 (Fluent Bit)  (buffer,            │
                replay)            └─▶ S3/Parquet         (cold: 90d–years, cheap, scan-on-demand)
                                          │
                                   Lifecycle/tiering ─▶ Glacier (archive) ─▶ delete at retention
```

## Append-pipeline

Lokit kirjoitetaan kerran, ei koskaan päivitetä — joten sisäänottopolku on **append**. Agentit kuten **Fluent Bit / Vector** lähettävät rivit **Kafkaan**, joka puskuroi purskeet ja irtikytkee tuottajat tallennuksesta. Jos ClickHouse on alhaalla huollon vuoksi, tapahtumat jonottavat Kafkassa ja toistetaan — et pudota lokeja. Batch-kirjoita (tuhansia rivejä per insert), koska per-rivi-insertit tuhoavat throughputin kolumnaarisissa storeissa.

## Kuuma store: indeksoi hakua varten

Tuoreet lokit tarvitsevat nopean haun ("virheet viimeisen tunnin aikana palvelulle X"). **ClickHouse** (kolumnaarinen, pakkaa 10x, skannaa miljardeja rivejä/s) tai **ELK-stack** (Elasticsearchin käänteisindeksi) palvelevat tätä. Partitioi päivän/palvelun mukaan, jotta kyselyt karsiutuvat muutamaan partitioon. Tämä taso on kallis per GB, joten pidä se pienenä — vain viimeiset 7–30 päivää.

## Kylmä store: object storage + tiering

Vanhemmat lokit siirtyvät **S3:een Parquetina** — halpa, kestävä, kyseltävissä tarpeen mukaan Athenan/Trinon kautta. **Lifecycle-politiikka** siirtää S3 → Glacier → poisto retentiorajallasi (esim. 1 vuosi). Tämä *tiering* on ydinkustannusvipu: kuuma tallennus voi olla 50x arkistoinnin hinta.

## Haastattelunäkökulma

Haastattelijat tutkivat **indeksi-vs-kustannus-kompromissia**: kaiken indeksointi antaa loistavan haun mutta räjäyttää budjetin; ei mitään indeksointia on halpaa mutta kyselemätöntä. Hyvä: "käytä ELK:tä." Loistava: tieroit — indeksoit tuoreen kuuman siivun, arkistoit loput kylmänä — ja nimeät Kafkan puskurina, joka tekee sisäänotosta kestävän downstream-häiriöille.

**Yleinen ansa:** kaikkien lokien laittaminen Elasticsearchiin ikuisesti. Se on kallein vaihtoehto ja sen klusteri kaatuu kardinaliteetin/retention alle, jota et suunnitellut.

## Kompromissit ja virhetilanteet

- **Retentio vs kustannus:** pidempi retentio = lineaarinen tallennuksen kasvu; tieroi aggressiivisesti.
- **Kafka-backpressure:** jos consumerit laahaavat, levy täyttyy — mitoita retentio ja monitoroi lag.
- **Kardinaliteettiräjähdys:** korkean kardinaliteetin kentät (user_id) pöhöttävät ES-indeksejä; sämplää tai pudota ne.
- **Kyselykustannus kylmällä datalla:** Athena-skannaukset maksavat per TB — partitioi Parquet päivän/palvelun mukaan, jotta skannaukset pysyvät rajattuina.
- **At-least-once-duplikaatit:** dedup event id:llä, jos tarkat luvut merkitsevät.

Append-pipeline

Kuuma store: indeksoi hakua varten

Kylmä store: object storage + tiering

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset