Improving Resiliency and Stability of a Large-scale Monolithic API Service

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

Bối cảnh

Voyager-API: tầng API cho web và mobile của LinkedIn, ra đời từ chiến lược "mobile-first". Hai nguyên tắc thiết kế:
- cross-platform: mọi nền tảng dùng chung endpoint;
- all-encompassing: một service cho mọi product vertical (mỗi vertical là một nhóm tính năng do một team sở hữu).
Lợi ích: tái dùng code và schema, không phải phối hợp phiên bản; hơn 400 kỹ sư lặp nhanh.
2017: 500+ triệu thành viên, deploy 3 lần/ngày, gọi gần 300 service phía dưới. Trong một năm có thêm hàng trăm endpoint, user tăng hơn 25%.
Vấn đề: mọi instance phục vụ mọi endpoint, nên một endpoint hỏng (bug, hoặc service phía dưới chậm) tăng tải trên mọi instance và làm chậm, thậm chí tắc cả API. Kết quả là sự cố một phần thường xuyên, deploy bị hoãn.
Các cách đã thử, chưa đủ:
- scale ngang tới mức chưa từng có (tốn phần cứng, không bền);
- timeout (service phía dưới không có SLA nên phải đặt timeout cao, mất tác dụng);
- tối ưu bộ nhớ và GC của JVM.

Chẩn đoán (theo LinkedIn): nguyên tắc "một monolith" được áp dụng quá đà, lan cả sang kiến trúc deploy. Họ không tách thành microservice (dự án lớn, tốn công, có thể giảm năng suất, cần công cụ mới).
Multi-clustering: chia tập endpoint theo vertical mà không đổi code; mỗi phần được route tới một cụm server riêng, mỗi server chạy nguyên bản monolith.
Quy trình cho từng vertical:
- runbook và lịch mẫu cho team infra, SRE, team vertical;
- build sinh thêm một deployable mang tên vertical, với config kế thừa config chung;
- ước lượng cỡ cụm = QPS tối đa khi failover colo × 1,2 / QPS tối đa mỗi host. Thực tế sai từ 30–300%, nên phải đo lại;
- chuyển traffic nội bộ (Rest.li D2) trước, rồi tăng dần HTTP. Khi đủ tải để làm quá tải ít nhất 3 server thì rút dần server để đo QPS thật mỗi host; không lên 100% trước khi chỉnh lại tài nguyên theo số đo.

Cô lập lỗi: có lúc một cụm sập vì sự cố backend mà linkedin.com vẫn chạy.
Capacity planning theo từng vertical (năng lực mỗi host giữa các vertical chênh nhau đáng kể).
Log tách theo vertical; hệ thống so sánh hiệu năng giữa hai bản deploy (EKG) chạy theo từng vertical, nên endpoint ít traffic không bị endpoint nhiều traffic che mất.
Fan-out trung bình tới service phía dưới giảm còn 35% so với một cụm chung. Chỉnh được quota truy vấn tới backend và cấu hình bảo mật theo vertical.

Monolith về code ≠ monolith về deploy. Có thể giữ một codebase nhưng chạy nhiều cụm riêng theo vùng tính năng, đây là bulkhead ở mức deploy. Đường giữa, giống tinh thần modular monolith của Shopify (Shopify 2019).
Chia theo ranh giới sở hữu đã có (vertical) thì việc tách dễ và khớp với tổ chức.
Ước lượng dung lượng chỉ là điểm bắt đầu; đo bằng traffic thật trước khi lên 100%.