Adopting Arm at Scale: Bootstrapping Infrastructure

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

Phần 1/2. Phần 2: Uber 2025. Bài không có trong sheet, là phần đầu của series có trong sheet.

Bối cảnh

2/2023, Uber bắt đầu chuyển từ data center tự vận hành lên cloud (Oracle Cloud Infrastructure và Google Cloud), và đặt thêm mục tiêu đưa máy Arm (Ampere) vào đội máy toàn x86.
Lý do theo Uber: giảm chi phí, tốt hơn về price-performance, đa dạng nguồn phần cứng khi chuỗi cung ứng khó đoán, và giảm phát thải (Arm tiết kiệm điện, OCI có mật độ tính toán cao hơn nên rẻ hơn cho Uber).
Bảy giai đoạn: host readiness, build readiness, platform readiness, SKU qualification, workload readiness, adoption readiness, adoption.

Mục tiêu đầu tiên tưởng đơn giản: build một service cho Arm và deploy bằng nền tảng deploy sẵn có. Hoá ra mọi tầng, từ host tới pipeline build, đều gắn chặt với x86.
Host: dựng image host cho Arm (OS, kernel, phần mềm nền), build lại và kiểm từng thành phần.
Build: ảnh container của 5.000+ service build bằng Makisu trên Buildkite; Makisu không cross-compile được, và nhiều service có bước build riêng gắn với Makisu. Thay vì bỏ Makisu, dùng Bazel (build được ảnh cho kiến trúc khác) để build ra Makisu bản Arm.
Phụ thuộc vòng: Makisu chạy trên Buildkite, Buildkite chạy trên nền tảng stateful Odin, Odin dựa vào các host agent (log, metric, mạng) mà tất cả đều build bằng Makisu. Phải chuyển lần lượt sang Bazel: host agent → thành phần Odin → Buildkite → cuối cùng Makisu.
Pipeline build phân tán: chạy Makisu native trên cả máy x86 lẫn Arm, rồi ghép thành một ảnh đa kiến trúc (manifest list). Đổi lại chi phí build gấp đôi với hơn 400.000 lượt build ảnh/tuần; theo Uber, kinh tế đơn vị của Arm vẫn đáng.
Deploy: thêm ràng buộc đặt chỗ theo kiến trúc vào nền tảng deploy; cơ chế an toàn tự bỏ ràng buộc Arm và quay về x86 nếu một service lỡ deploy ảnh chỉ có một kiến trúc.

Không chuyển 5.000 service khỏi Makisu, vì quá lớn; thay vào đó "bootstrap" đúng chỗ cần và giữ quy trình build cũ.
Ảnh đa kiến trúc cho phép cùng một tag deploy lên cả hai loại máy, điều kiện để chuyển dần.

Đổi phần cứng là migration xuyên mọi tầng; giả định "chỉ có một kiến trúc" ẩn ở host image, build tool, CI và cả chính công cụ build (Migration không downtime).
Gặp phụ thuộc vòng thì gỡ từ đáy lên (công cụ dùng để build công cụ).
Chi phí chuyển đổi (build gấp đôi) phải so với lợi ích đơn vị lâu dài (Chi phí hạ tầng và build vs buy).
Luôn có đường lui tự động khi một artifact không chạy được trên máy đích.