Accelerating Search and Ingestion with High-Performance gRPC in OpenSearch

Uber · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Uber đã chuẩn hoá trên OpenSearch cho search và retrieval (ghép tài xế, chống gian lận, gợi ý Uber Eats). Hạ tầng nội bộ nói gRPC + Protobuf, còn OpenSearch chỉ có REST/JSON; các lớp chuyển đổi ở giữa thêm latency, phức tạp và rủi ro vận hành. Theo Uber, khi traffic, payload và độ nhạy latency tăng, REST/JSON không chỉ chậm hơn mà còn giới hạn cách nền tảng search tiến hoá.

Thay đổi chính

• gRPC native trong OpenSearch, làm upstream (cùng kỹ sư AWS) thay vì giữ fork hay lớp dịch: transport gRPC là một module chạy cạnh REST trên cổng khác; chỉ lớp client–server khác nhau, logic giữa các node dùng chung. Một SPI cho plugin ngoài core (như k-NN) tự cung cấp chuyển đổi Proto → đối tượng Java và gắn dịch vụ gRPC riêng.
• Ưu tiên API nhạy latency nhất: Search và Bulk.
• Giữ REST và Protobuf đồng bộ bằng pipeline tự động từ đặc tả OpenAPI: tiền xử lý làm rõ các quy ước ngầm của REST (method + path, query param, hành vi theo status code) thành message có kiểu; chuyển đổi chính bằng OpenAPI Generator (Uber đóng góp bộ quy tắc JSON → Protobuf); hậu xử lý kiểm tương thích wire với Protobuf đã sinh trước đó (Protobuf không chịu được đổi số thứ tự field như REST chịu được).
• Search Gateway (proxy mọi request search/ingest của khách nội bộ, lo bảo mật, observability, rate limit, audit) trước đó phải dịch Protobuf → JSON → Protobuf; nay chuyển thẳng Protobuf của client tới endpoint gRPC, bỏ adaptor.
• Kết quả production, theo Uber: M3 (hệ metric nội bộ) ghi qua Bulk gRPC: p99 34,1 → 13,6 ms (−60%), p50 15,8 → 10,5 ms; độ trễ index tối đa của M3 −20–35% (quan trọng lúc failover); job Spark nạp index theo lô chạy nhanh hơn 20–35%. Vector search hưởng nhiều nhất vì vector trong JSON được serialize rất kém so với repeated float đóng gói của Protobuf: danh sách mua sắm grocery p50 83 → 38 ms, p95 114 → 64 ms, p99 205 → 176 ms (đuôi do query lớn); chiều càng lớn (1.572 so với 512, 256) lợi càng nhiều. Tài liệu dạng nhị phân SMILE qua gRPC nhanh hơn REST JSON 30%.
• Kết luận đo: gRPC lợi nhất với request lớn, RPS cao, tài liệu nhị phân. Tiếp theo: thêm API, streaming, bảo mật và observability cho transport.

Vì sao

• Theo Uber, cách biểu diễn API không phải lựa chọn bề mặt: ở quy mô lớn nó quyết định trần hiệu năng, cách hệ tiến hoá và tốc độ developer.

Bài học cho SWE

• Lớp dịch giữa hai giao thức là chi phí ở mọi request; nếu được, đưa giao thức nội bộ vào chính hệ đó (upstream) thay vì giữ adaptor.
• Chi phí serialize tỉ lệ với kích thước payload: vector lớn trong JSON là chỗ lợi nhất khi chuyển sang định dạng nhị phân.
• Hai bề mặt API song song cần một nguồn đặc tả và kiểm tương thích tự động, nếu không sẽ trôi.
• Giữ giao thức cũ chạy cạnh để các team chuyển dần.

Liên quan

• Hạ tầng tìm kiếm · Batching và khấu hao round-trip
• Cùng công ty: Uber 2026 · Uber 2026
• Cùng bài toán: GitHub 2020 (sinh API từ đặc tả)