Turborepo Remote Cache: Accelerating CI to Move Fast
Bài tóm tắt Mercari 2026 3. Quy mô lớn Độ khó: Trung bình
Mercari · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc
Dự án thực tập của đội Web Platform, viết 3/2025, đăng 2/2026. Cùng chủ đề runner tạm với Mercari 2026.
Bối cảnh
- Nhiều repo web của Mercari là monorepo dùng Turborepo (song song hoá task, cache theo task). Runner GitHub Actions tự host là runner tạm, nên cache cục bộ của Turborepo mất sau mỗi job; action cache chung của GitHub không hiểu phụ thuộc giữa task. Mercari không dùng Vercel (nơi có remote cache được quản lý sẵn), nên phải tự host.
Thay đổi chính
- Ba phương án cho server cache:
- Microservice trên GKE như thông lệ công ty: cụm CI ở Mỹ, cụm GKE chính ở Nhật, nên latency cao và phí truyền dữ liệu 0,08 USD/GiB quá đắt; một server chung cho mọi repo còn gây cache pollution và khó phân quyền.
- Cloud Run ở Mỹ: rẻ về truyền dữ liệu, nhưng muốn tách cache theo repo thì phải có rất nhiều instance, tốn compute.
- Custom GitHub Action (chọn): chạy chính server cache ngay trong job, lưu artifact trên storage của Google Cloud qua Workload Identity sẵn có của runner. Họ thừa nhận cách này "khác thường" nhưng rẻ và nhanh nhất.
- Hai dạng: action JavaScript khởi động server như tiến trình Node.js nền và tự đặt
TURBO_API,TURBO_TOKEN,TURBO_TEAM(người dùng chỉ thêm một bước vào workflow); với build trong Docker thì chạy server như container sidecar chung network namespace, khởi động sau bước lấy credential (nên không dùng service container của GitHub, vốn khởi động từ đầu job).
Kết quả (theo Mercari)
- Trên monorepo của chính đội: build vốn nhanh, cải thiện ít dù tỉ lệ trúng cache cao.
- Trên một repo lớn, module hoá tốt: thời gian task Turbo giảm khoảng 50%, tổng thời gian job giảm khoảng 30%.
- Khi thay đổi chạm nhiều package, có lúc chậm hơn: server cache mất khoảng 10 giây khởi động, ăn hết lợi ích với task ngắn; họ tính viết server nhẹ hơn.
- Repo có một ứng dụng lớn không phụ thuộc package nội bộ thì gần như không lợi gì; theo họ, đây là động lực để module hoá.
Vì sao
- Cache theo task chỉ có ích khi codebase chia thành nhiều đơn vị có ranh giới phụ thuộc rõ; với runner tạm, cache phải nằm ngoài máy (CI và build ở quy mô lớn, Cache và invalidation).
- Chỗ đặt server cache quyết định chi phí: phí truyền giữa vùng có thể lớn hơn mọi tiết kiệm.
Bài học cho SWE
- Tách cache theo repo để tránh nhiễm chéo và đơn giản hoá phân quyền.
- Đo chi phí cố định của chính cơ chế cache (khởi động 10 giây) so với task ngắn nhất.
- Remote cache không thay được module hoá; nó khuếch đại lợi ích của module hoá.
Liên quan
- Mercari 2026 · Uber 2022 (remote cache Bazel) · SoundCloud 2019 (cache có mà không trúng)
- CI và build ở quy mô lớn · Cache và invalidation
#Turborepo#Remote cache#Monorepo#GitHub Actions#Ephemeral runner#Workload Identity#Sidecar#Cache pollution#Data transfer cost#Modularization
Được nhắc tới trong
Công ty (1)
Bài tóm tắt (4)