Load test và kiểm chứng capacity

Bài toán

Trước một mốc tải chưa từng gặp (ra mắt game, tính năng mới gửi push toàn quốc, mùa giải, tăng trưởng nhanh), cần biết hệ chịu được bao nhiêu, cái gì gãy trước, và cần bao nhiêu máy. Test từng service riêng không đủ vì một thao tác của user kéo theo chuỗi gọi qua nhiều service và tải dồn vào các service dùng chung ở downstream. Bài toán gồm: tạo đủ tải giống thật (kịch bản, dữ liệu, bộ sinh tải hàng trăm máy), chọn nơi chạy (môi trường thu nhỏ, bản sao production, hay chính production), đặt tiêu chí qua/không qua, và biến kết quả thành cấu hình scale cho ngày thật.

Trang này nói về tải và capacity. Gây lỗi có chủ đích (chaos, fault injection, mô phỏng) ở Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định); scale theo lịch và autoscaling ở Tự động hoá vận hành và auto-remediation và Chi phí hạ tầng và build vs buy; đỉnh tải do chính hệ thống tạo ra ở Hot partition và thundering herd.

Diễn tiến theo thời gian

• 2011→2014 · WhatsApp (qua HighScalability): tải tổng hợp gần như vô dụng ở quy mô hàng triệu kết nối mỗi máy (không tái tạo được hành vi theo nước, thiết bị, sự kiện); thay bằng rẽ traffic production sang hệ riêng và dồn DNS để một máy nhận gấp đôi, gấp ba tải. WhatsApp 2014
• 2013 · Netflix (Scryer): capacity dự đoán thay cho chỉ phản ứng: traffic streaming có chu kỳ ngày/tuần rõ và instance khởi động mất 10–45 phút, nên đặt lịch scale theo dự đoán, giữ autoscale phản ứng cho đột biến. Theo Netflix: hiệu năng, availability tốt hơn và giảm chi phí EC2. Netflix 2013
• 2013→2019 · LinkedIn: load test hằng ngày bằng traffic thật: offline bucket Stickyrouting ở các DC khác để dồn traffic vào DC cần đo. Làm tay mất 2–3 giờ/ngày → tự động ba giai đoạn (75%, 90%, rồi tiến trong cửa sổ watermark), query metric dày hơn để bù trễ pipeline, có pause/terminate. LinkedIn 2019
• 2015→2018 · LinkedIn (Dynamometer): sau sự cố 3/2015 (thêm 500 máy, NameNode chậm hai bậc vì một hồi quy upstream), dựng cụm HDFS giả lập bằng dưới 5% phần cứng: NameNode thật nạp FsImage production, DataNode giả chỉ có metadata block, phát lại audit log (chia theo IP nguồn để giữ thứ tự); dùng trước mỗi lần nâng cấp, xác nhận non-fair lock. LinkedIn 2018
• 2018 · Hotstar: load test cỡ IPL dùng hơn 500 máy CPU lớn chạy 4 giờ; máy sinh tải không giữ trạng thái nên chạy Spot, tiết kiệm 75–80%. Disney Hotstar 2018
• 2018 · LinkedIn: load test DC ngày 5/2/2018 làm 10% call feed không có kết quả; sau khi sửa hàng đợi, retry và timeout thì qua được mức cao hơn mục tiêu 10%; bài học là cần headroom test theo service, không chỉ load test toàn site. LinkedIn 2018
• 2019 · Hotstar: chọn broker pub/sub cho 50 triệu kết nối bằng tiêu chí đặt trước (đủ kết nối, latency trung bình dưới 1 giây và không tăng dần, số tin nhận đủ), tìm trần một node rồi mới lên cụm; load test lộ ra trần của chính load balancer (ELB rớt kết nối từ khoảng 500.000, phải pre-warm). Disney Hotstar 2019
• 2019 · Tinder: Swipe Night (6/10/2019) mở cho cả nước cùng lúc, kèm push toàn quốc; autoscaler phản ứng không kịp đỉnh nhọn. Mục tiêu 3 lần traffic thường: môi trường 1/30 production tắt autoscaler Dynamo để lộ điểm yếu, test từng service rồi test riêng downstream dùng chung; đường dữ liệu mới thử bằng traffic production có kill switch, tăng 1% → 100%; diễn tập cuối bằng push thật trong 5 phút lộ ra autoscaler Dynamo mất 10 phút để phản ứng. Tinder 2020
• 2019→2020 · Miro: ở mốc 12.000 user đồng thời, đúng lúc bản load test đầu chạy thì production sập hai giờ; chuyển sang hạ tầng load test thường trực. Một test lớn trên bản sao mạnh hơn production, kịch bản dựng từ metric production (phân bố board, tỉ lệ sửa/xem, số lần gọi DB theo model), dữ liệu tạo qua API như user thật; bộ sinh tải nhúng chính client thật vào JMeter (730 luồng mỗi máy, 69 máy Spot cho 50.000 user). Từ test lớn sinh ra test DB bằng pgreplay và test thoái hoá cho mỗi release. Miro 2020
• 2019→2021 · LinkedIn (YARN): DynoYARN chạy cụm YARN giả trong YARN (1.200 node giả trên 8 máy) phát lại audit log nhân 1,5–2 lần: p95 chờ dưới 10 phút giữ được tới khoảng 11.000 node, từ đó tính ra còn bao lâu trước khi phải chia cụm (Robin). LinkedIn 2021
• 2019 · Dropbox: Tìm biên throughput Kafka tự động: Spark sinh tải, binary search trên số producer cho từng kích thước message, quá tải định nghĩa bằng chính metric cảnh báo production (IO thread idle < 20%, ISR đổi > 50%); khoảng 60 MB/s/broker, cấp phát 50 MB/s để chịu 20% broker offline. Dropbox 2019
• 2020 · Miro: khoảng 100 máy sinh tải và 150 máy service mỗi lần; dùng cùng Terraform/Ansible và autoscale như production, nên test cho biết capacity cần ở mức user chưa từng gặp; monitoring của test là monitoring của production, nên test kiểm luôn observability. Miro 2020
• 2020 · Riot Games: VALORANT cần 2 triệu người đồng thời mỗi shard khi mới thử với khoảng 100. Harness Go giả lập người chơi (vòng polling nền + scenario + pool theo tốc độ đăng nhập), game server giả hơn 500 trận mỗi core; bắt đầu 1.000 người, sửa hết rồi gấp đôi; lần 2 triệu đầu tiên đạt khi còn chưa tới hai tuần trước ra mắt. Load test đòi hỏi chia dữ liệu theo service rồi 64 bảng theo hash người chơi, chia việc nền thành 256 phần trong Redis. Riot Games 2020
• 2020→2021 · Dream11: IPL 2020 hơn 5,5 triệu user đồng thời. Torque gom test tải thành code (Gatling), chạy qua Jenkins, tự dựng máy sinh tải và chia dữ liệu duy nhất cho từng generator (khoá Redis, S3, Lambda/Spark); hơn 50 service quan trọng benchmark ở 5 lần tải thường. Game day theo mức concurrency dự báo cho ra các "bậc" scale đã kiểm chứng. Dream11 2021 Dream11 2021
• 2020 · Etsy: Mùa lễ 2020 sau khi traffic quý 2 tăng bằng vài năm: báo GCP ước lượng cận trên, mỗi đội xin quota trước tháng 9, "scale day" hơn 15 đội nâng capacity cho 3 lần traffic tháng 8 rồi replay request chồng lên traffic thật. Theo tác giả, load test toàn site chủ yếu kiểm quota, công cụ scale và lộ nút thắt cấu hình (Memcache, relay StatsD). Etsy 2021
• 2021 · LinkedIn (Capacity Analyzer): traffic tăng đột biến làm load test trượt; công cụ chấm mức hồi quy từng service theo Site QPS và call graph, tỉ lệ qua load test lên trên 95%, sự cố do thiếu capacity giảm 73%. LinkedIn 2021
• 2023 · Achievers: framework k6 trên cụm Kubernetes riêng nằm ngoài mạng ứng dụng; ngưỡng qua/không qua suy ra từ SLO (SLO 99% thì lỗi trong test không quá 1%). Nút thắt tìm được: gRPC không cân tải theo request, Cloud NAT của chính bộ sinh tải, lock trong connector DB dùng chung, Redis OOM, dải IP pod giới hạn số node. Throughput gấp 4, đủ để một region gánh failover. Achievers 2023 Achievers 2023
• 2025 · Stack Overflow: lần đầu load test site public trước khi lên cloud, vì app giả định phản hồi dưới 30 ms; môi trường giống production dựng bằng Terraform, mỗi vòng sửa chỗ chậm mà data center che đi, tới khi request/giây vượt xa mức ở data center. Stack Overflow 2025
• 2026 · Airbnb: load test DB bằng replay traffic production đã capture ở 2× hay theo QPS mục tiêu thay cho sysbench; worker hàng nghìn instance cùng một giờ xuất phát cho mỗi batch để giữ độ đồng thời gốc. Một cụm lớn khi tăng 80% traffic ghi thì commit latency từ khoảng 6 lên 34 ms. Có công cụ tự phục vụ, dùng cả để tìm cụm dư. Airbnb 2026
• 2026 · Optiver: runner CI gắn phần cứng (FPGA, bare metal) không thể thêm nhanh; lập kế hoạch capacity bằng dữ liệu queue time (p90), utilisation theo lớp phần cứng và mẫu tải trong ngày (đỉnh giờ trưa, đêm là job theo lịch). Optiver 2026
• 2026 · Meta/WhatsApp: World Cup: WhatsApp đạt hơn 30 triệu tin/giây ở chung kết, 8,4 tỉ tin trong 5 phút; hơn 100 service được load test và chỉnh kích thước trước giải, test lại khi nhánh đấu thu hẹp. Đỉnh theo giờ nghỉ của trận; đệm capacity cấp trước là đòn bẩy hiệu quả nhất (theo Meta). Meta 2026

Các lựa chọn và đánh đổi

Quy tắc rút ra

1. Đặt tiêu chí qua/không qua trước khi chạy, tốt nhất suy ra từ SLO; "qua" nghĩa là mọi metric trong ngưỡng suốt thời gian test, kể cả latency không tăng dần. Achievers 2023 Riot Games 2020 Disney Hotstar 2019
2. Hiệu chỉnh kịch bản theo tải lên server, không theo analytics sử dụng; phần lớn user bình thường, vài user "phá hoại" như account lớn thật. Dữ liệu test là một phần của kịch bản. Miro 2020
3. Test từng service rồi test theo tổng tải ở downstream dùng chung, vì test riêng chỉ đẩy một phần tải vào chúng. Tinder 2020
4. Tăng theo bậc (gấp đôi), sửa hết ở mỗi bậc rồi mới lên. Riot Games 2020 Tinder 2020
5. Kiểm bộ sinh tải trước khi kết luận về hệ thống: NAT, số luồng mỗi máy, code tuỳ biến trong công cụ đều có thể là nút thắt. Achievers 2023 Miro 2020
6. Nút thắt thường nằm ở mặc định của nền tảng (cân tải theo kết nối, dải IP, ELB chưa pre-warm, autoscaler 10 phút), không ở code nghiệp vụ. Achievers 2023 Disney Hotstar 2019 Tinder 2020
7. Đỉnh tải theo sự kiện thì scale trước theo cấu hình đã đạt trong test, không trông vào autoscaler. Riot Games 2020 Dream11 2021 Tinder 2020
8. Dùng chung công cụ hạ tầng và monitoring với production: test kiểm luôn capacity của autoscale và độ đủ của observability. Miro 2020
9. Máy sinh tải không giữ trạng thái: chạy Spot, dựng và huỷ theo lần chạy. Disney Hotstar 2018 Miro 2020 Dream11 2021

Câu hỏi mở

• Chưa có nguồn so sánh độ chính xác của các cách (thu nhỏ rồi suy ra, bản sao lớn hơn, traffic thật) trên cùng một hệ; Tinder và Miro chọn ngược nhau mà không đối chiếu.
• Chi phí load test so với chi phí hạ tầng production: chỉ có Miro (khoảng 3.000 USD/tháng cho 50.000 user, 2020) và Hotstar (Spot rẻ hơn 75–80%).
• Load test liên tục trong CI (Achievers, Dream11, Miro test thoái hoá) có bắt được hồi quy hiệu năng thật không: chưa nguồn nào nêu số.
• Liên hệ: Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định), Tự động hoá vận hành và auto-remediation, Chi phí hạ tầng và build vs buy, Hot partition và thundering herd, Sharding và tách database (VALORANT), Observability và monitoring.