คุณจะเก็บ log event 100M รายการต่อวันอย่างไร?

Question

IT Interview Practice · Accepted Answer

สร้าง **pipeline แบบ append-only: agents → Kafka → tiered storage (hot ใน ClickHouse/ELK, cold ใน object storage)** พร้อม retention policy ที่ index ข้อมูลล่าสุดและ archive ส่วนที่เหลืออย่างประหยัด 100M event/วันคือเฉลี่ยราว 1,200/วินาที (spike สูงกว่านั้นมาก) และหลายสิบถึงหลายร้อย GB ต่อวัน — คุณ optimize เพื่อการเขียนที่ถูกและต้นทุน query ที่มีขอบเขต ไม่ใช่ semantics แบบ 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
```

## Append pipeline

Log เขียนครั้งเดียว ไม่เคย update — ดังนั้น ingest path จึงเป็น **append** agent อย่าง **Fluent Bit / Vector** ส่งบรรทัดไปยัง **Kafka** ซึ่ง buffer การพุ่งและ decouple producer ออกจาก storage ถ้า ClickHouse ล่มเพื่อ maintenance event จะ queue ใน Kafka และ replay — คุณไม่ทิ้ง log เขียนแบบ batch (หลายพัน row ต่อ insert) เพราะการ insert ต่อ row ทำลาย throughput บน columnar store

## Hot store: index เพื่อการ search

log ล่าสุดต้องการ search ที่เร็ว ("error ในชั่วโมงที่แล้วสำหรับ service X") **ClickHouse** (columnar, บีบอัด 10x, สแกนพันล้าน row/วินาที) หรือ **ELK stack** (inverted index ของ Elasticsearch) รองรับสิ่งนี้ partition ตาม day/service เพื่อให้ query prune เหลือไม่กี่ partition tier นี้แพงต่อ GB ดังนั้นให้มันเล็ก — เฉพาะ 7–30 วันล่าสุด

## Cold store: object storage + tiering

log ที่เก่ากว่าย้ายไปยัง **S3 เป็น Parquet** — ถูก, durable, query ตามต้องการผ่าน Athena/Trino **lifecycle policy** เปลี่ยน S3 → Glacier → ลบเมื่อถึงขีดจำกัด retention (เช่น 1 ปี) *tiering* นี้คือคันโยกต้นทุนหลัก: hot storage อาจมีราคา 50 เท่าของ archival

## มุมมองการสัมภาษณ์

ผู้สัมภาษณ์จี้ **ข้อแลกเปลี่ยน index-vs-cost**: index ทุกอย่างให้ search ที่ดีเยี่ยมแต่ระเบิดงบ index ไม่มีอะไรเลยถูกแต่ query ไม่ได้ ดี: "ใช้ ELK" เยี่ยม: คุณทำ tier — index slice ล่าสุดที่ร้อน archive ส่วนที่เหลือแบบ cold — และระบุ Kafka ว่าเป็น buffer ที่ทำให้ ingestion ทนต่อการล่มของ downstream

**กับดักที่พบบ่อย:** ใส่ log ทั้งหมดใน Elasticsearch ตลอดกาล มันคือตัวเลือกที่แพงที่สุดและ cluster ของมันจะล้มเมื่อเจอ cardinality/retention ที่คุณไม่ได้วางแผน

## ข้อแลกเปลี่ยน & โหมด failure

- **Retention vs cost:** retention นานขึ้น = storage โตเชิงเส้น tier อย่างเข้มข้น
- **Kafka backpressure:** ถ้า consumer ล่าช้า disk เต็ม — ปรับขนาด retention และ monitor lag
- **Cardinality ระเบิด:** field ที่มี cardinality สูง (user_id) ทำให้ ES index บวม sample หรือ drop มันทิ้ง
- **ต้นทุน query บน cold data:** Athena สแกนคิดเงินต่อ TB — partition Parquet ตาม date/service เพื่อให้การสแกนมีขอบเขต
- **At-least-once ซ้ำ:** dedup บน event id ถ้า count ที่แม่นยำสำคัญ

Append pipeline

Hot store: index เพื่อการ search

Cold store: object storage + tiering

มุมมองการสัมภาษณ์

ข้อแลกเปลี่ยน & โหมด failure

คำถามที่เกี่ยวข้อง