An AKS Performance Journey: Part 1 — Sizing Everything Up

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

Phần 1/2. Phần 2: ASOS 2021 (DNS, conntrack, keep-alive).

Bối cảnh

• 2019–2020, đội ASOS Web chuyển một số micro-frontend từ Azure Cloud Services sang AKS để tăng mật độ service, khả năng scale và quyền kiểm soát. Mọi thay đổi kiến trúc lớn ở ASOS phải qua một loạt cổng kiểm tra trước khi lên production.
• Ứng dụng được nói tới là Product Listing Page (PLP) viết bằng NodeJS: phục vụ mọi trang danh mục, tìm kiếm, thương hiệu; tải cao thứ hai trong các ứng dụng front-end, hàng trăm QPS, phải co giãn theo đỉnh như Black Friday.
• Từ test hiệu năng quy mô nhỏ (Taurus, JMeter), họ tưởng đã biết số replica và request/limit CPU, RAM cần có. Theo họ: trên hạ tầng mới, không chỉ ứng dụng mà cả hạ tầng cũng phải tinh chỉnh.

Thay đổi chính

• Cạn cổng SNAT: test tải đỉnh (mô phỏng Black Friday) đang tăng đều thì latency mọi percentile nhảy lên mức timeout. Nguyên nhân ở chiều ra: load balancer của AKS hết cổng SNAT. Mỗi IP public có 64.000 cổng, nhưng Azure mặc định chỉ cấp 1.024 cổng mỗi node; kết nối giống nhau (cùng nguồn, cùng đích) không dùng chung cổng; cổng mất 4 phút mới được dùng lại. PLP gọi tới 5 request ra ngoài cho mỗi request vào, nên cạn rất nhanh, request chờ cổng lâu hơn timeout của ứng dụng. Sửa: thêm IP public cho load balancer, tăng số cổng cấp cho mỗi node.
• Latency chậm 2,5 lần so với Cloud Services:
  • SKU máy: Cloud Services dùng D4_v2 (8 vCPU, mỗi vCPU một core thật); AKS ban đầu dùng D4_v3 (4 vCPU nhưng hyper-threading, chỉ 2 core thật, ít NIC và băng thông hơn), tức khoảng 33% sức tính trước đây. Lên D16_v3 (16 vCPU, 8 core thật) giảm khoảng 100 ms ở mọi percentile (khoảng 33%). Hiệu năng NodeJS gần tuyến tính theo CPU.
  • Kích thước pod: nhiều replica hơn thì latency giảm tuyến tính. Nửa core mỗi pod làm latency tệ tới hơn 50% dù gấp đôi replica; 2 vCPU mỗi pod nhanh hơn khoảng 10% ở p75/p95 vì 2 vCPU hyper-thread ứng với một core thật, đúng với "một tiến trình NodeJS mỗi core". Pod to hơn cũng giảm số pod mỗi node, nên đỡ áp lực lên NIC và SNAT.
• Sau phần 1, latency ở percentile cao vẫn chậm hơn Cloud Services khoảng 100 ms.

Vì sao

• Giới hạn mặc định của hạ tầng mới (cổng SNAT mỗi node, vCPU là hyper-thread) không hiện ra trong test nhỏ; chỉ test ở tải đỉnh mới lộ. Cổng kiểm tra trước khi chuyển là thứ giúp migration không thành sự cố (Migration không downtime).
• "Cùng số vCPU" không có nghĩa cùng sức tính giữa hai thế hệ máy; so sánh chi phí phải theo core thật (Chi phí hạ tầng và build vs buy).

Bài học cho SWE

• Trước khi chuyển nền tảng, chạy test ở tải đỉnh, không chỉ test chức năng hay tải thấp.
• Với dịch vụ gọi nhiều request ra ngoài, kiểm tra giới hạn NAT/cổng của nền tảng.
• Định cỡ pod theo mô hình tiến trình của runtime (NodeJS: một tiến trình mỗi core thật).

Liên quan

• ASOS 2021 · Uber 2025 · Gojek 2020
• Migration không downtime · Chi phí hạ tầng và build vs buy