Tối ưu Chi phí Storage Logs và Execution Data: Lưu trữ trên S3 – Object Storage thay Database

Tối ưu hóa chi phí storage cho logs và execution data – Chiến lược lưu trữ logs trên S3/Object Storage thay vì Database

Bài viết sẽ đưa ra:
1️⃣ Tóm tắt nội dung chính.
2️⃣ Những vấn đề thực tế mà mình và các khách hàng thường gặp mỗi ngày.
3️⃣ Giải pháp tổng quan (với text‑art).
4️⃣ Hướng dẫn chi tiết từng bước triển khai.
5️⃣ Template quy trình tham khảo.
6️⃣ Các lỗi phổ biến & cách khắc phục.
7️⃣ Khi muốn scale lớn thì làm sao.
8️⃣ Chi phí thực tế (bảng so sánh).
9️⃣ Số liệu trước – sau khi chuyển sang S3.
🔟 FAQ hay gặp nhất.
1️⃣1️⃣ Giờ tới lượt bạn hành động.

1. Tóm tắt nội dung chính

• Vấn đề: Logs và execution data thường được ghi trực tiếp vào relational database (RDBMS) → tăng tải, chi phí lưu trữ nhanh chóng bùng nổ, thậm chí gây downtime.
• Giải pháp: Đẩy logs sang Amazon S3 / các object storage tương tự, dùng Athena / Presto / BigQuery để query khi cần.
• Lợi ích: Giảm tải DB > 70 %, chi phí lưu trữ giảm tới 80 %, khả năng mở rộng không giới hạn, đồng thời vẫn giữ được khả năng truy vấn nhanh chóng qua công cụ phân tích dữ liệu.

2. Vấn đề thật mà mình và khách hay gặp mỗi ngày

2.1 Đầy DB, query chậm, mất dữ liệu

🐛 Lỗi thực tế: Khách A (startup fintech) chạy một pipeline ETL mỗi phút, mỗi lần ghi 200 KB log vào bảng pipeline_logs. Chỉ sau 2 tuần, bảng này đã vượt quá 30 GB, khiến PostgreSQL bị “out of memory” và một vài transaction bị rollback.

2.2 Chi phí lưu trữ “bùng nổ”

⚡ Câu chuyện tiền: Khách B (e‑commerce) dùng MySQL để lưu trữ logs API. Hóa đơn tháng đầu tiên chỉ 150 USD, nhưng sau 3 tháng chi phí storage tăng lên 1 200 USD – hơn 8 lần so với dự tính ban đầu.

2.3 Khó mở rộng khi traffic tăng đột biến

🛡️ Vấn đề mở rộng: Khi một chiến dịch flash sale diễn ra, lượng request tăng gấp 10×, log sinh ra tương ứng. DB không kịp ghi, dẫn tới timeout và mất khách hàng tiềm năng.

3. Giải pháp tổng quan (text‑art)

+-------------------+          +-------------------+
|   Application     |  -->    |   Log Producer    |
| (API / Service)   |          | (Fluentd / Logstash)|
+-------------------+          +-------------------+
          |                               |
          v                               v
+-------------------+          +-------------------+
|   Kafka / SQS     |  -->    |   S3/Object Store |
|   (optional)      |          |   (raw logs)      |
+-------------------+          +-------------------+
          |                               |
          v                               v
+-------------------+          +-------------------+
|   Athena / Presto |  <--    |   Metadata DB     |
|   (query)         |          | (index pointers) |
+-------------------+          +-------------------+

• Log Producer (Fluentd, Logstash, Filebeat…) ⚡ Đẩy log dưới dạng JSON lên S3.
• Metadata DB chỉ lưu đường dẫn (S3 URI) và timestamp, giảm tải DB xuống < 5 % so với việc lưu toàn bộ log.

4. Hướng dẫn chi tiết từng bước

Bước 1: Chuẩn bị bucket S3 (hoặc MinIO, Wasabi…)

aws s3api create-bucket --bucket my-logs-bucket --region ap-southeast-1
aws s3api put-bucket-versioning --bucket my-logs-bucket --versioning-configuration Status=Enabled

• Lưu ý: Bật Versioning để có khả năng rollback khi log bị ghi sai.

Bước 2: Cài đặt Fluentd (hoặc Logstash) trên server ứng dụng

<source>
  @type tail
  path /var/log/app/*.log
  pos_file /var/log/fluentd.pos
  tag app.log
  format json
</source>

<match app.log>
  @type s3
  s3_bucket my-logs-bucket
  s3_region ap-southeast-1
  path logs/%Y/%m/%d/
  buffer_path /var/log/fluentd/buffer
  time_slice_format %Y%m%d%H
  time_slice_wait 10m
  compress gzip
</match>

• ⚡ time_slice_format chia log thành các file mỗi giờ, giúp query nhanh hơn.

Bước 3: Tạo bảng Athena để query log

CREATE EXTERNAL TABLE IF NOT EXISTS logs_raw (
    request_id string,
    user_id    string,
    endpoint   string,
    status     int,
    latency_ms double,
    ts         timestamp
)
PARTITIONED BY (year string, month string, day string, hour string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://my-logs-bucket/logs/';

• 🛡️ Best Practice: Đặt partition theo thời gian (year/month/day/hour) để giảm chi phí scan.

Bước 4: Đồng bộ partition tự động

aws glue start-crawler --name logs-crawler

Hoặc dùng AWS Lambda để chạy MSCK REPAIR TABLE logs_raw mỗi giờ.

Bước 5: Lưu trữ metadata trong DB (MySQL)

⚡ Lưu ý: Chỉ lưu đường dẫn và metadata → bảng chỉ chiếm < 100 MB dù log hàng tháng lên TB.

5. Template quy trình tham khảo

1️⃣ Log generation → Fluentd → S3 (gzip)
2️⃣ Metadata insert → MySQL (log_id, s3_path, ts)
3️⃣ Partition update → Athena/Glue crawler
4️⃣ Query → Athena/Presto → Dashboard (QuickSight, Metabase)
5️⃣ Retention policy → Lifecycle rule S3 (expire after 90 days)

6. Những lỗi phổ biến & cách sửa

> Blockquote: Nếu bạn gặp lỗi “AccessDenied” khi Fluentd cố gắng ghi vào S3, hãy kiểm tra lại policy IAM của instance role. Đừng quên bật “Object Ownership” = “Bucket owner preferred”.

7. Khi muốn scale lớn thì làm sao

1. Sử dụng Kafka / Kinesis làm buffer – giảm tải trực tiếp từ app tới S3.
2. Partition theo nhiều chiều (year/month/day/hour + app_name) → query chỉ quét dữ liệu cần thiết.
3. Sử dụng S3 Intelligent‑Tiering – tự động chuyển dữ liệu “cold” sang lớp lưu trữ rẻ hơn.
4. Triển khai Athena Serverless – trả phí theo lượng dữ liệu scan, không cần provision cluster.

⚡ Tip: Khi traffic > 10 K rps, hãy cân nhắc dùng AWS Firehose để stream log trực tiếp vào S3 mà không cần Fluentd trung gian.

8. Chi phí thực tế

Bảng so sánh chi phí lưu trữ (tháng)

⚡ Nhận xét: Chỉ với < 1 USD/tháng cho storage, bạn có thể giảm chi phí DB từ 7.5 USD xuống 0.7 USD, đồng thời giảm tải DB > 80 %.

Công thức tính chi phí S3

ROI = (Chi phí DB cũ – Chi phí S3 mới) / Chi phí DB cũ × 100%

Giải thích: Nếu chi phí DB cũ là 7.5 USD, chi phí S3 mới là 0.7 USD → ROI ≈ 90 % giảm chi phí.

9. Số liệu trước – sau

• Trước chuyển:
  • DB size: 30 GB → CPU usage avg = 75 %
  • Downtime: 2 h/tháng (do lock DB)
  • Chi phí storage: 7.5 USD/tháng
• Sau chuyển:
  • DB size: < 2 GB (chỉ metadata) → CPU usage avg = 15 %
  • Downtime: < 5 phút/tháng (chỉ do network)
  • Chi phí storage: 0.7 USD/tháng

⚡ Kết quả: Giảm tải DB ≈ 85 %, giảm chi phí storage ≈ 90 %, thời gian downtime giảm hơn 95 %.

10. FAQ hay gặp nhất

Q1: Logs có cần mã hoá khi lưu trên S3?
A: Đối với dữ liệu nhạy cảm, bật SSE‑S3 hoặc SSE‑KMS; chi phí tăng < 0.01 USD/GB.

Q2: Có thể query log real‑time không?
A: Với Athena, latency thường ~5‑10 giây sau khi file đã được ghi; nếu cần real‑time hơn, dùng Kinesis Data Analytics hoặc OpenSearch.

Q3: Retention policy nên đặt bao lâu?
A: Tùy vào yêu cầu pháp lý; thường giữ logs “hot” 30 ngày trên Standard, sau đó chuyển sang Glacier Deep Archive.

Q4: Có ảnh hưởng tới GDPR/PDPA không?
A: Cần đảm bảo dữ liệu cá nhân được mã hoá và có chính sách xóa tự động; sử dụng bucket policy để giới hạn truy cập.

11. Giờ tới lượt bạn

1️⃣ Đánh giá hiện trạng DB: Kiểm tra kích thước bảng logs hiện tại và mức CPU/IO đang dùng.
2️⃣ Tạo bucket S3 và bật versioning + lifecycle rule (30‑90 ngày).
3️⃣ Cài đặt Fluentd hoặc Logstash để stream log vào S3 ngay hôm nay.
4️⃣ Thiết lập một bảng Athena đơn giản để thử query một vài file log mẫu.
5️⃣ Theo dõi chi phí qua AWS Cost Explorer – bạn sẽ thấy sự khác biệt chỉ sau một tháng.

⚡ Hành động nhanh: Nếu bạn chưa có môi trường AWS, có thể dùng MinIO trên EC2 để thử nghiệm mà không tốn phí.

Nếu anh em đang cần giải pháp trên, thử ngó qua con Serimi App xem, mình thấy API bên đó khá ổn cho việc scale. Hoặc liên hệ mình để được trao đổi nhanh hơn nhé.