দিনে ১০ কোটি log event কীভাবে সংরক্ষণ করবেন?

Question

IT Interview Practice · Accepted Answer

একটি **append-only pipeline তৈরি করুন: agent → Kafka → tiered storage (hot ClickHouse/ELK-তে, cold object storage-এ)** এমন একটি retention policy সহ যা সাম্প্রতিক data index করে এবং বাকিটা সস্তায় archive করে। দিনে ১০ কোটি event গড়ে ~১,২০০/sec (spike অনেক বেশি) এবং দৈনিক দশ-থেকে-শত GB — আপনি সস্তা write ও সীমাবদ্ধ query খরচের জন্য optimize করেন, OLTP semantics-এর জন্য নয়।

```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 write-once, কখনও update হয় না — তাই ingest path একটি **append**। **Fluent Bit / Vector**-এর মতো agent লাইন **Kafka**-তে পাঠায়, যা burst buffer করে এবং producer-কে storage থেকে decouple করে। ClickHouse maintenance-এর জন্য down থাকলে event Kafka-তে queue হয় এবং replay হয় — আপনি log drop করেন না। Batch write করুন (প্রতি insert-এ হাজার হাজার row) কারণ per-row insert columnar store-এ throughput ধ্বংস করে।

## Hot store: search-এর জন্য index

সাম্প্রতিক log-এর দ্রুত search লাগে ("service X-এর জন্য গত ঘণ্টার error")। **ClickHouse** (columnar, ১০x compress করে, প্রতি সেকেন্ডে শত কোটি row scan করে) বা **ELK stack** (Elasticsearch inverted index) এটি পরিবেশন করে। day/service দিয়ে partition করুন যাতে query কয়েকটি partition-এ prune করে। এই tier প্রতি GB ব্যয়বহুল, তাই এটি ছোট রাখুন — কেবল শেষ ৭–৩০ দিন।

## Cold store: object storage + tiering

পুরনো log **S3-তে Parquet হিসেবে** সরে — সস্তা, durable, Athena/Trino দিয়ে on demand queryable। একটি **lifecycle policy** আপনার retention limit-এ (যেমন ১ বছর) S3 → Glacier → deletion transition করে। এই *tiering* হলো মূল খরচ lever: hot storage archival-এর চেয়ে ৫০x দামি হতে পারে।

## ইন্টারভিউ দৃষ্টিভঙ্গি

ইন্টারভিউয়াররা **index-বনাম-খরচ trade-off** যাচাই করেন: সবকিছু index করলে দারুণ search কিন্তু budget উড়ে যায়; কিছুই index না করলে সস্তা কিন্তু unqueryable। ভালো: "ELK ব্যবহার করুন।" দারুণ: আপনি tier করেন — সাম্প্রতিক hot slice index করুন, বাকিটা cold archive করুন — এবং Kafka-কে সেই buffer হিসেবে নাম ধরে বলেন যা ingestion-কে downstream outage-এর প্রতি resilient করে।

**সাধারণ ফাঁদ:** সব log চিরকাল Elasticsearch-এ রাখা। এটি সবচেয়ে ব্যয়বহুল বিকল্প এবং যে cardinality/retention আপনি পরিকল্পনা করেননি তাতে এর cluster ধসে পড়ে।

## ট্রেড-অফ ও ব্যর্থতার ধরন

- **Retention বনাম খরচ:** দীর্ঘ retention = রৈখিক storage বৃদ্ধি; আক্রমণাত্মকভাবে tier করুন।
- **Kafka backpressure:** consumer পিছিয়ে পড়লে, disk ভরে যায় — retention সাইজ করুন এবং lag monitor করুন।
- **Cardinality বিস্ফোরণ:** high-cardinality field (user_id) ES index ফোলায়; sample বা drop করুন।
- **Cold data-তে query খরচ:** Athena প্রতি TB scan খরচ করে — date/service দিয়ে Parquet partition করুন যাতে scan সীমাবদ্ধ থাকে।
- **At-least-once dupe:** exact count গুরুত্বপূর্ণ হলে একটি event id-তে dedup করুন।

Append pipeline

Hot store: search-এর জন্য index

Cold store: object storage + tiering

ইন্টারভিউ দৃষ্টিভঙ্গি

ট্রেড-অফ ও ব্যর্থতার ধরন

সম্পর্কিত প্রশ্ন