Comment stockez-vous 100M d'événements de log par jour ?

Question

IT Interview Practice · Accepted Answer

Construisez un **pipeline append-only : agents → Kafka → stockage à étages (hot dans ClickHouse/ELK, cold dans du stockage objet)** avec une politique de rétention qui indexe les données récentes et archive à bas coût le reste. 100M d'événements/jour, c'est ~1 200/sec en moyenne (pics bien plus élevés) et des dizaines à centaines de Go par jour — vous optimisez pour des écritures bon marché et un coût de requête borné, pas pour la sémantique OLTP.

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

## Pipeline d'append

Les logs sont write-once, jamais mis à jour — donc le chemin d'ingestion est un **append**. Des agents comme **Fluent Bit / Vector** envoient les lignes vers **Kafka**, qui bufferise les bursts et découple les producteurs du stockage. Si ClickHouse est down pour maintenance, les événements font la queue dans Kafka et rejouent — vous ne perdez pas de logs. Batchez les écritures (des milliers de lignes par insert) car les inserts par ligne détruisent le throughput des columnar stores.

## Hot store : indexer pour la recherche

Les logs récents nécessitent une recherche rapide (« erreurs de la dernière heure pour le service X »). **ClickHouse** (columnar, compresse 10x, scanne des milliards de lignes/sec) ou la **stack ELK** (index inversé Elasticsearch) servent cela. Partitionnez par jour/service pour que les requêtes se réduisent à quelques partitions. Ce tier est coûteux par Go, donc gardez-le petit — seulement les 7 à 30 derniers jours.

## Cold store : stockage objet + tiering

Les logs plus anciens migrent vers **S3 en Parquet** — bon marché, durable, interrogeable à la demande via Athena/Trino. Une **lifecycle policy** transitionne S3 → Glacier → suppression à votre limite de rétention (par ex. 1 an). Ce *tiering* est le levier de coût central : le stockage hot peut coûter 50x le prix de l'archivage.

## Perspective d'entretien

Les examinateurs sondent le **compromis index-vs-coût** : tout indexer donne une excellente recherche mais fait exploser le budget ; ne rien indexer est bon marché mais non interrogeable. Bien : « utiliser ELK ». Excellent : vous étagez — indexez la tranche hot récente, archivez le reste en cold — et nommez Kafka comme le buffer qui rend l'ingestion résiliente aux pannes en aval.

**Piège courant :** mettre tous les logs dans Elasticsearch pour toujours. C'est l'option la plus coûteuse et son cluster s'effondre sur la cardinalité/rétention que vous n'aviez pas planifiée.

## Compromis et pannes

- **Rétention vs coût :** une rétention plus longue = croissance linéaire du stockage ; étagez agressivement.
- **Backpressure Kafka :** si les consumers prennent du retard, le disque se remplit — dimensionnez la rétention et monitorez le lag.
- **Explosion de cardinalité :** les champs à haute cardinalité (user_id) gonflent les index ES ; échantillonnez-les ou abandonnez-les.
- **Coût de requête sur données froides :** les scans Athena coûtent au To — partitionnez le Parquet par date/service pour que les scans restent bornés.
- **Doublons at-least-once :** dédupliquez sur un event id si les compteurs exacts importent.

Pipeline d'append

Hot store : indexer pour la recherche

Cold store : stockage objet + tiering

Perspective d'entretien

Compromis et pannes

Questions connexes