Building a High-Throughput Metrics System Using Open Source Software

Two Sigma · 2019 · 2. Tăng trưởng · Độ khó: Dễ — bài gốc

Bối cảnh

Two Sigma xây nền tảng cho "nghiên cứu dạng hội thoại". Một nền tảng dữ liệu hiệu năng cao trả kết quả truy vấn của researcher (ví dụ "dataset x từ 2000 tới 2019, lấy log mọi giá trị"), tới 50.000 query/giây và 1,85 GiB/giây mỗi node.
Họ muốn đo usage metric ở mức từng query (tính năng và tham số nào được dùng, query phân bố theo dataset ra sao, thay đổi theo thời gian) và giữ dữ liệu thô để phân tích khám phá, mà không làm chậm hay giảm độ tin cậy của nền tảng.

Chia bài toán thành bốn câu hỏi, mỗi câu chọn một thành phần mã nguồn mở theo một checklist (đủ tính năng, có hỗ trợ nội bộ, giấy phép, cộng đồng hoạt động, mở rộng được, phiên bản ổn định):
1. Lưu ở đâu: Elasticsearch + Kibana (schema linh hoạt, có sẵn UI phân tích, mỗi ngày một index; có hỗ trợ nội bộ). So với Druid, Graphite, InfluxDB, PostgreSQL, TrailDB.
2. Chịu throughput: benchmark nội bộ cho thấy Elasticsearch không nhận nổi 50.000 message/giây; đặt Kafka làm bộ đệm như "bể nước" làm phẳng các đợt dồn. Chọn Kafka thay RabbitMQ vì đã có dạng dịch vụ nội bộ.
3. Chuyển từ Kafka sang Elasticsearch: Logstash, khoảng 20 dòng cấu hình thay cho hàng trăm dòng code consumer; scale bằng cách chạy thêm instance tới số partition.
4. HA: Elasticsearch, Kibana, Kafka do đội Infrastructure Reliability Engineering vận hành; Logstash tự quản nên chạy trên Marathon. Giữa 2017 Kubernetes chưa có sẵn ở Two Sigma; Waiter (của họ) chỉ dành cho web service.

Theo bài, hệ chạy gần như không downtime từ khi dựng, ít công hỗ trợ. Ba bài học họ nêu: yêu cầu định hình hệ thống; chọn mã nguồn mở cẩn thận và dùng khi có thể; nhiều khi việc chính là ghép và cấu hình chứ không phải viết code.

Ghi metric không được làm chậm hệ chính: đặt hàng đợi bền ở giữa để tách tốc độ ghi khỏi tốc độ kho đích.
Ưu tiên thành phần đã có hỗ trợ nội bộ; đó là tiêu chí ngang với tính năng.