Mercari rút thời gian scale-out Elasticsearch trên Kubernetes từ 12 phút xuống 2 phút
Đội tìm kiếm của Mercari giữ sẵn bản sao shard trên PVC để bỏ bước copy dữ liệu khi scale-out, rồi điều chỉnh tolerance của HPA theo giai đoạn tải trong ngày. Bài tổng hợp ý chính và bài học cho hệ thống stateful trên Kubernetes.
Vibe DevOps biên soạn ngày · khoảng 574 từ
Điểm chính từ bài gốc
- Elasticsearch của Mercari đã autoscale theo CPU và giảm khoảng 40% chi phí, nhưng mỗi node mới phải copy shard qua mạng hơn 10 phút, nên ngưỡng CPU của HPA buộc phải đặt thấp quanh 65% để scale-out sớm.
- Giải pháp là các Pod Replicator chạy thường trực với tài nguyên nhỏ, liên tục đồng bộ shard xuống PVC nhưng không nhận truy vấn; khi scale-out, Replicator được nâng thành node thường và chỉ cần Local Recovery.
- Vì mọi Pod trong một StatefulSet dùng chung template, nhóm dùng MutatingWebhook để thu nhỏ request, limit, heap Java và gắn nhãn cho Pod Replicator dựa trên số thứ tự ordinal của Pod.
- Sau cải tiến, thời gian scale-out giảm từ 12 phút còn 2 phút và ngưỡng CPU của HPA được nâng từ 65% lên 80%.
- Ngưỡng cao làm lộ vấn đề tolerance mặc định 0.1 của HPA; nhóm dùng tolerance riêng cho từng HPA và từng chiều (KEP-4951, GA ở v1.37) cùng một CronJob đổi cấu hình theo giai đoạn tải tăng hay giảm.
Theo bài gốc
Thứ tự thao tác khi nâng cấp Replicator
Khi scale-out, controller cập nhật số node thường trước, xóa Pod Replicator để StatefulSet tạo lại với cấu hình lớn, sau đó mới tăng replicas để sinh lớp Replicator mới và cuối cùng tăng số replica của index. Bài gốc nhấn mạnh không được đảo thứ tự, vì Pod mới có thể đọc số node cũ và webhook sẽ áp sai cấu hình. Replicator mới vẫn copy toàn bộ dữ liệu, nhưng việc này đã nằm ngoài đường phục vụ truy vấn.
Nếu node hiện tại không đủ chỗ cho Pod lớn hơn, Pod được lên lịch sang node khác và volume được tháo, gắn lại trong khoảng một phút thay vì sao chép shard. HPA cũng chỉ đếm node thường, Replicator bị loại khỏi số lượng và selector.
Bình luận của Vibe DevOps — không phải nội dung bài gốc
Góc nhìn Vibe DevOps: bài học cho workload stateful
Góc nhìn Vibe DevOps: autoscaling của hệ thống stateful bị giới hạn bởi thời gian một node mới thực sự sẵn sàng, không phải bởi con số ngưỡng CPU. Trước khi chỉnh HPA, hãy đo xem Pod mới mất bao lâu để phục vụ được traffic; nếu con số đó lớn, mọi tinh chỉnh ngưỡng chỉ là đổi chi phí lấy độ an toàn.
Kỹ thuật giữ sẵn dữ liệu ấm trên volume và dùng webhook tùy biến từng Pod rất hiệu quả nhưng làm tăng độ phức tạp: thêm controller, plugin và bản vá riêng cho Elasticsearch. Đội nhỏ nên cân nhắc trước phương án đơn giản như lịch scale theo giờ, và chỉ chỉnh tolerance khi đã có số liệu cho thấy thrashing hoặc phản ứng chậm.
- Đo thời gian từ lúc Pod được tạo tới lúc sẵn sàng nhận truy vấn.
- Theo dõi số lần scale lên xuống mỗi ngày để phát hiện thrashing.
- Viết thứ tự thao tác scale thành runbook có thể kiểm thử.
Lệnh và khoá cấu hình xuất hiện trong bài gốc
Trích nguyên văn từ nguồn để tra cứu; hãy đọc ngữ cảnh tại bài gốc trước khi áp dụng.
spec.behavior.scaleUp.toleranceTrường cấu hình tolerance riêng cho chiều scale-out của từng HPA.
Lưu ý và giới hạn
- Giải pháp dựa trên plugin và bản vá riêng cho Elasticsearch, được bài gốc mô tả ở mức kiến trúc.
- Các con số là kết quả trên hệ thống của Mercari, với giả định mỗi node giữ đúng một shard.