Tạm biệt ELK: Cách Uber xây dựng hệ thống Logging thế hệ mới

Tại Uber, chúng mình vận hành một nền tảng logging tập trung, tin cậy và có tính tương tác cao. Đây là “xương sống” giúp các kỹ sư làm việc nhanh hơn và tự tin hơn ở quy mô cực lớn.

Hiện tại, hệ thống này đang xử lý hàng triệu log mỗi giây từ hàng ngàn dịch vụ, lưu trữ hàng PB (Petabyte) dữ liệu và phục vụ hàng trăm truy vấn mỗi giây từ cả dashboard lẫn các chương trình tự động.

Tại sao chúng mình phải thay đổi?

Từ năm 2014, Uber bắt đầu với bộ công cụ ELK (Elasticsearch, Logstash, Kibana). Nhưng khi lưu lượng truy cập và số lượng các trường hợp sử dụng tăng vọt, chúng mình đã chạm tới giới hạn của hệ thống cũ.

Những “nỗi đau” với ELK:

1. Schema bị gò bó: Elasticsearch (ES) tự động suy luận schema và bắt buộc tính nhất quán trên toàn cụm. Chỉ cần một kỹ sư thay đổi kiểu dữ liệu của một trường (ví dụ: từ chuỗi sang số), ES sẽ báo lỗi xung đột và “vứt” luôn bản log đó. Với hàng ngàn kỹ sư cùng tham gia, việc bắt họ phải nhớ từng tên trường là điều không tưởng.
2. Chi phí vận hành quá cao: Chúng mình từng phải chạy hơn 20 cụm ES ở mỗi vùng để hạn chế rủi ro “sập dây chuyền”. Mỗi lần có truy vấn nặng hoặc “bùng nổ” mapping là cụm ES lại đơ, buộc phải khởi động lại thủ công.
3. Tốn phần cứng: ES tốn rất nhiều tài nguyên để duy trì các cấu trúc index phức tạp (inverted index).
4. Tốc độ tổng hợp (Aggregation) chậm: Hơn 80% truy vấn của chúng mình là truy vấn tổng hợp. ES không được thiết kế để chạy các phép tính này trên tập dữ liệu khổng lồ một cách nhanh chóng. Có những dashboard mất tới cả tiếng mới load xong log của 1 giờ trước đó.

Giải pháp mới: Schema-Agnostic dựa trên ClickHouse

Sau khi cân nhắc nhiều lựa chọn, đội ngũ kỹ sư Uber quyết định chọn ClickHouse — một hệ quản trị cơ sở dữ liệu cột (columnar DBMS) mã nguồn mở — làm nền tảng lưu trữ chính.

1. Mô hình dữ liệu “Bất chấp Schema”

Thay vì bắt log phải tuân theo một khuôn mẫu cố định, chúng mình thiết kế table schema trong ClickHouse theo cách cực kỳ thông minh:

• Lưu trữ dạng mảng (Array): Mỗi log được chuyển thành các cặp key-value. Chúng mình nhóm các cặp này theo kiểu dữ liệu (String, Number, Array…).
• Ví dụ: Các trường kiểu chuỗi sẽ vào cột string.names và string.values.
• Lợi ích: Cách làm này giúp tránh việc tạo ra quá nhiều cột trên đĩa cứng (vốn là điểm yếu của ClickHouse) mà vẫn đảm bảo tốc độ truy vấn nhanh gấp 5 lần so với việc parse JSON thô.

2. Tối ưu hóa hiệu năng

• Nén dữ liệu: Nhờ cấu trúc cột của ClickHouse, tỷ lệ nén đạt trung bình 3x, thậm chí có trường hợp lên tới 30x, tốt hơn hẳn so với ES.
• Tốc độ nạp (Ingestion): Một node ClickHouse có thể xử lý 300,000 log/giây, nhanh gấp 10 lần so với một node ES.

Kiến trúc hệ thống

Quy trình xử lý log diễn ra như sau:

1. Ingester: Tiêu thụ log từ Kafka, làm phẳng (flatten) dữ liệu JSON thành các cặp key-value.
2. Batcher: Gom log thành các đợt lớn để ghi vào ClickHouse (vì ClickHouse hoạt động tốt nhất khi ghi theo batch).
3. Query Service: Cung cấp một giao diện truy vấn tùy chỉnh. Người dùng không cần biết ClickHouse SQL phức tạp, họ chỉ cần viết những câu lệnh đơn giản, hệ thống sẽ tự động chuyển đổi và tối ưu hóa.

Điểm đặc biệt: Chúng mình vẫn giữ lại cột _source (chứa JSON gốc) để phục vụ việc xem log thô nhanh chóng mà không cần tái cấu trúc dữ liệu từ các cột lẻ.

Kết quả đạt được

Hệ thống mới không chỉ giúp giảm đáng kể chi phí phần cứng mà còn mang lại trải nghiệm cực kỳ “mượt” cho anh em kỹ sư:

• Tự do log: Cứ việc log bất cứ gì bạn muốn, không lo xung đột kiểu dữ liệu.
• Truy vấn thần tốc: Các dashboard trước đây hay bị timeout giờ đã load trong vài giây.
• Vận hành ổn định: Giảm thiểu tối đa việc can thiệp thủ công từ đội ngũ Ops.

Lời kết

Việc chuyển dịch từ ELK sang nền tảng dựa trên ClickHouse là một bước tiến lớn của Uber Engineering. Nó chứng minh rằng: khi công cụ cũ không còn theo kịp quy mô phát triển, việc dũng cảm xây dựng một giải pháp tùy chỉnh dựa trên nền tảng mã nguồn mở phù hợp sẽ mang lại giá trị khổng lồ.