Long on Research, Short on Bandwidth

Hudson River Trading · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• Giao dịch của HRT dựa trên lượng tính toán nghiên cứu khổng lồ: train nhiều loại model trên nhiều năm lịch sử từ các sàn khắp thế giới rồi mô phỏng hành vi của chúng trong vô số kịch bản giao dịch.
• Xưa kia phần lớn chạy trong một site. Rồi HRT mở rộng storage và compute ra toàn cầu (cả Na Uy); chương trình ngày càng chạy xa dữ liệu, băng thông WAN thành ràng buộc. Khi lưu lượng liên site làm nghẽn mạng, họ không biết user hay workflow nào gây ra.
• Sự cố mẫu: một lần training dùng GPU ở Chicago, dữ liệu ở New York, chép qua dịch vụ chuyển dữ liệu liên vùng DupeDog; tốc độ chuyển tụt. Log DupeDog không thấy ai mới; cache file phân tán Cashy cũng không. Bộ đếm byte của switch cho thấy một nguồn lạ làm bão hoà đường vào Chicago.

Thay đổi chính

• Researcher được tự do chọn công cụ, nên không thể bắt 100% lưu lượng WAN đi qua một dịch vụ có log. Cần ghi nhận ở tầng kernel.
• eBPF hook vào tcp_recvmsg/tcp_sendmsg: mọi đường đọc/ghi TCP (read, recvmsg…) đều qua đây; lấy PID để quy cho user. Verifier của eBPF chứng minh tĩnh tính an toàn trước khi nạp.
• Đếm trong kernel thay vì xuất từng sự kiện: BPF map giữ tổng byte theo (pid, IP/port hai đầu), bộ đếm riêng mỗi CPU để tránh tranh chấp; mỗi phút kéo lên userspace, ghép metadata process (user, chương trình, workflow), downsample bằng priority sampling, đẩy vào nền tảng analytics (Iceberg + ClickHouse).
• NFS phá vỡ việc quy kết: lưu lượng hiện ra là của root qua worker kernel xprtiod. Hook vfs_read thì đếm thừa vì cache; cuối cùng phải trace các hàm NFS cấp thấp thật sự fetch dữ liệu (kể cả mmap, async I/O) và nối process khởi tạo với lần truyền.
• Thủ phạm: lỗi cấu hình. Hàng nghìn job ở Chicago đọc một file lớn ở New York; lẽ ra phải nạp vào Cashy ở Chicago một lần, nhưng tất cả trỏ thẳng vào filer New York, file bị gửi qua nước Mỹ hàng nghìn lần; cache của filer còn làm việc này nhanh hơn.
• Gộp nhiều nguồn, mỗi luồng đếm một lần: eBPF cho socket, eBPF cho NFS, log dịch vụ (DupeDog biết ai yêu cầu, eBPF chỉ thấy user dupedog), bộ đếm switch làm tổng đối chiếu. Loại phần eBPF của port dịch vụ và port 2049 (NFS) để không đếm ba lần. Heatmap so tổng quy kết với bộ đếm switch theo site; ô đỏ chỉ ra phần còn thiếu (ví dụ replication filer-filer không có recorder ở hai đầu).

Vì sao

• Giờ khi mạng quá tải, biết ngay workflow nào gây ra; khi dời một chương trình sang site khác, biết nó nói chuyện với dữ liệu và dịch vụ nào. Có quy trình tự động throttle workflow gây hại, và "làm bão hoà WAN" đã vào danh sách.

Bài học cho SWE

• Log ở tầng dịch vụ chỉ phủ lưu lượng đi qua dịch vụ đó; muốn đầy đủ phải đo ở tầng thấp hơn và ghép lại.
• Tổng hợp ngay trong kernel (đếm theo phút) thay vì xuất từng sự kiện.
• Luôn có một tổng độc lập (bộ đếm switch) để biết phần quy kết còn thiếu bao nhiêu.
• Hệ dùng chung nhiều tenant cần quy được tài nguyên cho từng tenant thì mới throttle được.

Liên quan

• Hudson River Trading 2025 · Hudson River Trading 2021 · Jane Street 2026
• Observability và monitoring · Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) · Multi-tenancy và cô lập tenant