Xác định nút cổ chai trước khi lưu lượng truy cập đến
Độ trung tâm giữa (Betweenness Centrality)
Đối với mỗi cặp nút trong một đồ thị, có một đường đi ngắn nhất giữa chúng. Độ trung tâm giữa của một nút N = tỷ lệ phần trăm của tất cả các đường đi ngắn nhất đi qua N.
Một nút có độ trung tâm giữa cao nằm trên đường đi giữa nhiều cặp nút khác. Nếu nó chậm lại, nhiều luồng sẽ chậm lại. Nếu nó bị lỗi, nhiều luồng sẽ bị gián đoạn.
Cách đọc kiến trúc: các nút có độ trung tâm giữa cao là những thành phần mà mọi cuộc đánh giá kiến trúc nên đặc biệt chú ý. Chúng là nút cổ chai, điểm lỗi đơn (SPOF) & các thành phần quan trọng về mặt năng lực xử lý trong một. Chúng thường là:
- Nhà cung cấp DNS (nằm giữa mọi client & mọi service)
- Proxy ingress (nằm giữa mọi client & mọi backend)
- Database primary (nằm giữa mọi backend & mọi thao tác đọc)
- Dịch vụ xác thực (nằm giữa mọi user & mọi hành động được ủy quyền)
Phát hiện mà không cần đo lường: chỉ riêng cấu trúc đồ thị đã có thể xác định các nút có độ trung tâm giữa (betweenness) cao. Bạn không cần dữ liệu lưu lượng truy cập; bạn chỉ cần sơ đồ kiến trúc. Một nút nằm giữa nhiều cặp nút khác là một nút quan trọng về mặt cấu trúc.
Hệ quả về mặt vận hành: các nút có độ trung tâm giữa cao xứng đáng nhận được mức đầu tư không tương xứng (tỷ lệ lớn hơn) cho (1) dung lượng dự phòng, (2) dự phòng (redundancy), (3) khả năng quan sát (observability), & (4) kịch bản ứng phó sự cố.
Cắt nhỏ nhất ngắt kết nối phần nhỏ nhất
Định lý Min-Cut bằng ngôn ngữ thông thường
Cắt nhỏ nhất (min-cut) giữa hai nút trong đồ thị = số lượng cạnh (hoặc nút) nhỏ nhất mà bạn phải loại bỏ để ngắt kết nối giữa chúng.
Cách đọc theo góc độ vận hành: min-cut đặt ra giới hạn cho bán kính ảnh hưởng (blast radius) trong trường hợp xấu nhất. Nếu min-cut giữa 'clients' & 'database' là 1 cạnh (một proxy duy nhất), thì việc mất cạnh đó sẽ ngắt kết nối tất cả clients khỏi database. Nếu min-cut là 5, bạn cần mất đồng thời 5 thành phần để ngắt kết nối hoàn toàn; đây là rủi ro xấu, nhưng đã được giới hạn.
Thiết kế cho bán kính ảnh hưởng: tăng min-cut tại mọi ranh giới quan trọng. Nhiều proxy; nhiều nút cache; nhiều đường dẫn mạng giữa các trung tâm dữ liệu (DC). Mỗi thành phần được thêm vào sẽ làm tăng min-cut lên 1.
Mô hình bulkhead (bố trí ngăn cách) theo thuật ngữ đồ thị: phân chia tài nguyên thành các đồ thị con riêng biệt không chia sẻ min-cut với nhau. Một sự cố trong một đồ thị con không thể lan sang các đồ thị con khác vì các cạnh kết nối không tồn tại.
Đường kính (Diameter) quy định khoảng cách lan truyền sự cố
Đường kính đồ thị (Graph diameter) = đường đi ngắn nhất dài nhất giữa bất kỳ hai nút nào.
Lan truyền sự cố: khi một nút gặp sự cố & các lệnh thử lại (retries) quay ngược dòng, chúng sẽ chạm đến các nút phía thượng nguồn (upstream) ở khoảng cách bằng đường kính. Một hệ thống có đường kính 3 (client -> proxy -> backend -> DB) có nghĩa là sự cố ở DB sẽ ảnh hưởng đến 3 lớp thượng nguồn trong một cơn bão thử lại (retry storm).
Hệ quả: đường kính ngắn hơn = sự cố được kiểm soát nhanh hơn nhưng cũng dẫn đến sự tập trung nút cao hơn. Mỗi thiết kế đều có sự đánh đổi của nó.
Tính Min-Cut cho một Kiến trúc Thực tế
Một kiến trúc: 1 DNS, 1 CDN, 3 reverse proxy, 12 bản sao backend, 1 DB primary.
Kiểm toán chế độ lỗi thông qua các chỉ số đồ thị
Tổng hợp
Bạn giờ có thể xác định các nút có độ trung gian cao, tính min-cut tại mọi ranh giới & ước tính khoảng cách lan truyền lỗi thông qua đường kính.
Áp dụng cả ba.
Một hệ thống: 50 điểm cuối người dùng -> 1 DNS -> 2 POP CDN -> 4 proxy ngược -> 16 bản sao backend -> { cụm DB (1 primary + 2 standby), cụm Redis (5 nút), 3 API bên ngoài }.
Ghi chú đồng hành
Ghi chú đồng hành
Bài học về hình học này diễn giải lại bài học chính Failure Modes & Blast Radius thông qua các chỉ số đồ thị (betweenness, min-cut, diameter).
Ghi chú đồng hành cuối cùng, geometry_of_observability_and_capacity, xem xét các ô Voronoi cho vùng phủ sóng PoP của CDN, sàn tốc độ ánh sáng của tam giác độ trễ, & đường cong hàng đợi được xem xét lại ở tầng proxy.
Làm tốt lắm.