How we optimized infrastructure spend at GitLab

GitLab · 2020 · 4. Điều chỉnh · Độ khó: Dễ — bài gốc

Bối cảnh

GitLab.com chạy trên GCP. Họ muốn kiểm soát chi phí cloud mà vẫn ra tính năng, theo hướng dữ liệu: mục tiêu là mọi thay đổi chi phí đều được hiểu, không còn bất ngờ.

Khám phá: tiền đi đâu ở mức cao (nhà cung cấp, sản phẩm, project, SKU) từ billing console và billing export của GCP vào BigQuery.
Gán chi phí cho chiều kinh doanh: chi bao nhiêu cho CI runner, cho nhân viên dùng GitLab.com so với khách. Bắt đầu từ label GCP sẵn có chỉ service nội bộ; sau đó ra chuẩn hạ tầng về tạo project và đặt tên label.
Tối ưu theo câu hỏi cụ thể (cùng chuyên gia từng mảng):
- CI runner: báo cáo chi phí theo repo, pipeline, job để tối ưu CI nội bộ.
- Object storage: backup Postgres cũ tốn nhiều; bật lifecycle policy, giảm 900 TB ở một bucket.
- Mạng: một thay đổi kiến trúc mạng làm chi phí đổi; cho runner tải artifact thẳng từ GCS thay vì đi qua proxy, giảm đáng kể chi phí mạng.
Đánh đổi: khi hết việc dễ, cân giá trị của thay đổi phức tạp hơn, và chi phí của tính năng/kiến trúc mới (advanced global search cho mọi user trả phí: bản thử đầu rất đắt, team giảm mạnh chi phí rồi mới ra).
Chủ động: phát hiện và cảnh báo khi chi tiêu lệch khỏi ngưỡng kỳ vọng; khi không còn tăng chi phí bất ngờ nào ngoài tăng nhu cầu thật thì việc tối ưu trở nên "nhàm chán". Lúc viết, mỗi workload ở giai đoạn 1–4, phần lớn công sức là đưa mọi thứ lên ít nhất giai đoạn 2.

Ưu tiên trên issue board theo bốn yếu tố: tiết kiệm, ảnh hưởng khách, chi phí tương lai, công sức; analyst, PM của SaaS và chuyên gia cùng duyệt, PM xếp vào milestone của team.

Không gán được chi phí cho service và tính năng thì không ai hỏi được câu hỏi đúng; nhãn và chuẩn hạ tầng là nền của mọi tối ưu (Chi phí hạ tầng và build vs buy).

Ép chuẩn label/project từ sớm; gán chi phí khó làm lại về sau.
Nhiều khoản lớn là "rác" dễ dọn (backup cũ, traffic đi vòng qua proxy) chỉ thấy được khi có báo cáo chi tiết.
Coi chi phí là một thuộc tính khi duyệt tính năng mới.