Adopting Arm at Scale: Transitioning to a Multi-Architecture Environment

Uber · 2025 · 4. Điều chỉnh · Độ khó: Khó — bài gốc

Phần 2/2. Phần 1: Uber 2025.

Bối cảnh

• Sau khi chạy được vài service trên Arm, cần mở rộng cho 5.000+ service. Phân bổ CPU theo monorepo: 60% Go, 20% Java, 10% Web, phần còn lại rải ở nhiều micro-repo.
• Monorepo build bằng Bazel, đồng nhất nên dễ chuyển; micro-repo có toolchain riêng, tốn thời gian. Uber làm monorepo trước, chỉ ngoại lệ cho service micro-repo quan trọng.

Thay đổi chính

• Mã nguồn: mọi dependency trong monorepo phải có bản Linux Arm (lấy qua Artifactory nội bộ); C++ dùng Zig CC để cross-compile, bọc trong Bazel. Build cho Arm thành một target bình thường, không còn ngoại lệ.
• Ảnh container: sửa base image cũ chỉ một kiến trúc, gói Debian chưa từng build cho Arm, từng cái một.
• Kiểm tra: CI chạy unit test trên cả hai kiến trúc; bắt được khác biệt dấu phẩy động (Go cho phép fused floating-point dù làm tròn khác). Công cụ monitoring so sánh latency, lỗi, CPU, throttling theo kiểu A/B giữa hai kiến trúc và giữa các miền lỗi. Dev Pod (môi trường dev từ xa) hỗ trợ Arm.
• Đánh giá SKU: benchmark Ampere A1, A2 so với x86, cùng team sản phẩm chạy tải giả lập. Phát hiện A1 cho hiệu năng ổn định, không bùng nổ như một số máy x86; dùng kết quả để quyết định chia traffic giữa hai loại máy.
• Chiến lược chuyển: theo tier (độ quan trọng; sau mỗi đợt lớn có production readiness review rồi mới sang tier sau), non-prod trước prod, từng zone (để còn failover hoặc rút traffic khỏi một AZ). Test tự chạy mỗi lần deploy; tự revert khi có alert hay SLA xấu đi, nên không cần người canh.
• Tự động hoá: hệ goal-state: đọc kế hoạch (service nào, zone nào), một vòng reconcile chạy như workflow Cadence chọn service cần chuyển ở mỗi bước, theo lô nhỏ, không "big bang".

Kết quả (theo Uber, 2025)

• Hơn 2.800 service Go stateless chạy trên Arm; gần 20% dung lượng OCI chuyển từ x86 sang Ampere A1/A2, không có sự cố nghiêm trọng.
• Tiếp theo: service Java, rồi workload stateful (Redis, etcd, Cassandra, MySQL, M3), batch và ML.

Vì sao

• Theo Uber: price-performance tốt hơn, nền tảng linh hoạt hơn, giảm phát thải. Làm nhóm dễ và đồng nhất trước để không bị kẹt.

Bài học cho SWE

• Migration hàng nghìn service: đồng nhất hoá cách build trước, rồi chuyển bằng máy, theo lô nhỏ và tự revert theo tín hiệu (Migration không downtime, Tự động hoá vận hành và auto-remediation).
• Rollout theo tier, môi trường, zone là ba trục giới hạn bán kính hỏng (Deploy và release an toàn).
• Chạy test trên cả hai môi trường đích bắt được lỗi mà review không thấy (dấu phẩy động).
• Benchmark tổng hợp không đủ; tải thật cho thấy tính chất khác (ổn định so với bùng nổ) ảnh hưởng tới cách chia traffic (Chi phí hạ tầng và build vs buy).

Liên quan

• Uber 2025 (phần 1) · Uber 2025 · Uber 2026
• Migration không downtime · Deploy và release an toàn · Tự động hoá vận hành và auto-remediation · Chi phí hạ tầng và build vs buy