Günde 100 milyon log olayını nasıl saklarsınız?

Question

IT Interview Practice · Accepted Answer

Bir **append-only pipeline inşa edin: agent'lar → Kafka → tiered storage (hot ClickHouse/ELK'de, cold object storage'da)** ve son veriyi index'leyip geri kalanı ucuza arşivleyen bir retention policy ile. Günde 100 milyon olay ortalama ~1.200/sn'dir (spike'lar çok daha yüksek) ve günlük onlarca-yüzlerce GB — OLTP semantiği için değil, ucuz yazmalar ve sınırlı sorgu maliyeti için optimize edersiniz.

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

Log'lar write-once'dur, asla güncellenmez — bu yüzden ingest path bir **append**'tir. **Fluent Bit / Vector** gibi agent'lar satırları **Kafka**'ya ship eder, bu da patlamaları buffer'lar ve producer'ları storage'dan decouple eder. ClickHouse bakım için çökerse, olaylar Kafka'da kuyruğa girer ve replay olur — log'ları düşürmezsiniz. Yazmaları batch'leyin (insert başına binlerce satır) çünkü satır başına insert'ler columnar store'larda throughput'u yok eder.

## Hot store: arama için index'le

Son log'lar hızlı arama gerektirir ("X servisi için son bir saatteki hatalar"). **ClickHouse** (columnar, 10 kat sıkıştırır, saniyede milyarlarca satır tarar) veya **ELK stack** (Elasticsearch inverted index) buna hizmet eder. Gün/servise göre partition yapın, böylece sorgular birkaç partition'a budanır. Bu tier GB başına pahalıdır, bu yüzden küçük tutun — yalnızca son 7–30 gün.

## Cold store: object storage + tiering

Daha eski log'lar **S3'e Parquet olarak** taşınır — ucuz, dayanıklı, Athena/Trino aracılığıyla talep üzerine sorgulanabilir. Bir **lifecycle policy**, retention limitinizde S3 → Glacier → silme geçişi yapar (örn. 1 yıl). Bu *tiering* çekirdek maliyet kaldıracıdır: hot storage arşivlemenin 50 katı fiyat olabilir.

## Mülakat perspektifi

Mülakatı yapanlar **index-vs-maliyet ödünleşimini** yoklar: her şeyi index'lemek harika arama verir ama bütçeyi patlatır; hiçbir şeyi index'lememek ucuzdur ama sorgulanamaz. İyi: "ELK kullan." Harika: tier'larsınız — son hot dilimi index'leyin, geri kalanını cold arşivleyin — ve Kafka'yı ingestion'ı downstream kesintilerine dayanıklı kılan buffer olarak adlandırırsınız.

**Yaygın tuzak:** tüm log'ları sonsuza kadar Elasticsearch'e koymak. En pahalı seçenektir ve cluster'ı planlamadığınız cardinality/retention'da çöker.

## Ödünleşimler ve hata modları

- **Retention vs maliyet:** daha uzun retention = lineer storage büyümesi; agresif tier'layın.
- **Kafka backpressure:** consumer'lar gecikirse, disk dolar — retention boyutlandırın ve lag'i izleyin.
- **Cardinality patlaması:** yüksek cardinality alanlar (user_id) ES index'lerini şişirir; onları sample'layın veya düşürün.
- **Cold data'da sorgu maliyeti:** Athena TB başına tarama maliyeti alır — tarama'ların sınırlı kalması için Parquet'i tarih/servise göre partition yapın.
- **At-least-once dupe'lar:** tam sayımlar önemliyse bir event id üzerinde dedup yapın.

Append pipeline

Hot store: arama için index'le

Cold store: object storage + tiering

Mülakat perspektifi

Ödünleşimler ve hata modları

İlgili sorular