Bài 05: Tự tổ chức tới hạn — tại sao hệ thống luôn trôi về bờ vực sụp đổ

I. Tóm tắt #

Màn hình theo dõi báo CPU 80%, không lỗi nào, và trực giác kết luận: còn dư 20%, hệ thống an toàn. Mô hình đống cát của Bak, Tang và Wiesenfeld và lý thuyết Highly Optimized Tolerance về cái giá của tối ưu nói điều ngược lại. Hệ thống nhiều server không đứng yên ở vùng an toàn mà trôi dần về trạng thái tới hạn, nơi cùng một trục trặc nhỏ hôm nay vô hại, ngày mai lan ra cả cụm. Ở đó, trục trặc nhỏ rất nhiều, đợt sập lớn hiếm nhưng không bao giờ hiếm tới mức bỏ qua được. Thứ đưa hệ thống tới đó không phải quy luật tự nhiên, mà là từng đợt cắt giảm chi phí. Bài này giải thích cơ chế đó, và ba cách giữ hệ thống lùi khỏi mép cùng cái giá của từng cách.

II. Hệ thống trôi về mép nhờ chính những quyết định đúng #

Giả sử bạn làm ở một app giao đồ ăn ở TP.HCM. 11 giờ 45 trưa thứ Sáu, dashboard báo CPU 80%, không một lỗi nào; nhìn con số đó, phản xạ đầu tiên của tôi cũng là thấy còn dư 20% thì yên tâm. Năm phút sau, cache khởi động lại, và cả app đứng hình tới hết giờ trưa.

Dashboard là màn hình gom các số đo sức khỏe của hệ thống. Cache là vùng giữ sẵn dữ liệu hay dùng để khỏi phải hỏi database mỗi lần; cache trống thì mọi yêu cầu dồn thẳng xuống database. Tuần nào cache cũng khởi động lại vài lần, chưa lần nào gây chuyện. Cú kích hoạt không đổi. Hệ thống đã đổi.

Sáu tháng trước, cụm server chạy 50% CPU giờ cao điểm, lúc request đổ về nhiều nhất. Request là một lần app gửi yêu cầu tới server, như một lần bấm “Đặt món”. Mỗi sprint, đội cắt bớt vài server vì “còn dư nhiều”: 50% thành 60%, 70%, rồi 80%, không lần nào gây lỗi. Sprint là một chu kỳ làm việc ngắn, thường hai tuần.

Tỉ lệ bận đó gọi là utilization; phần còn trống gọi là headroom. Trong buổi review cuối quý, mỗi lần cắt server là một dòng xanh trong báo cáo chi phí. Trên hệ thống thật, đó là một lần rút headroom mà không ai phải ký phiếu chi.

Đứng sau các quyết định đó là trực giác tuyến tính: hậu quả tỉ lệ với nguyên nhân, và chừng nào tải còn dưới năng lực thì mọi thứ trong tầm kiểm soát. Muốn an toàn hơn thì thêm lớp bảo vệ: retry, cache, autoscaling. Retry là tự gửi lại request khi không nhận được trả lời. Autoscaling là tự thêm server khi tải tăng.

Jens Rasmussen (1997), một nhà nghiên cứu an toàn, vẽ lại bức tranh đó bằng ba đường biên bao quanh mọi hệ thống có người vận hành:

• Biên phá sản: đắt và chậm quá thì công ty chết.
• Biên quá tải: bắt người làm quá sức thì đội ngũ gãy.
• Biên an toàn: vượt qua thì hệ thống sập.

Vị trí hiện tại của hệ thống giữa ba biên đó gọi là điểm vận hành. Áp lực kinh doanh đẩy nó xa biên phá sản; mong muốn làm việc đỡ vất vả đẩy nó xa biên quá tải. Hai lực đó không nghỉ, nên điểm vận hành bị ép dần về biên thứ ba, dù không ai quyết định như vậy. Những lần cắt server ở app giao đồ ăn chính là lực thứ nhất.

Sidney Dekker (2011) gọi quá trình này là drift into failure: trôi dần về điểm đổ vỡ qua những bước nhỏ, bước nào cũng hợp lý. Theo ông, sự trôi đến từ thành công chứ không từ cẩu thả. Mỗi lần dồn thêm việc lên máy chủ hay bỏ bớt bước kiểm tra để nhanh thêm vài mili-giây, hệ thống có vẻ rẻ hơn. Nhưng đổi lại, bạn đang tiêu dần khoản dung lượng dự phòng mà không dashboard nào hiển thị.

Rồi cú kích hoạt tới: vài giây mạng chậm, một đợt cache trống sau kỳ nghỉ, một file cấu hình phình to. Lần này chỉ gợn nhẹ, lần sau thành đợt sập kéo dài nhiều giờ. Hậu quả không tỉ lệ với nguyên nhân. Đó là dấu hiệu của trạng thái tới hạn: một nhiễu nhỏ có thể tự tắt ngay hoặc bùng ra toàn hệ mà không ai đoán trước được. Vì sao hệ tự đi tới đó là việc của Mục III.

III. Hai mô hình: đống cát tự dốc lên, và cái giá của tối ưu #

Đống cát tự tìm tới mép #

Bak, Tang và Wiesenfeld (1987) mô tả hiện tượng này bằng một đống cát. Ai từng đổ cát hay gạo ra từ bao đều thấy: đống dốc dần tới một độ dốc nhất định rồi giữ ở đó. Thêm hạt nào cũng có thể gây sạt, to hay nhỏ không đoán trước được. Phiên bản trên máy tính của họ chỉ cần một lưới ô vuông và khả năng đếm tới bốn:

• Thả từng hạt cát xuống một ô ngẫu nhiên.
• Ô nào đủ 4 hạt thì sụp: chia cho mỗi ô bên cạnh 1 hạt. Hạt rơi ra ngoài mép lưới thì mất.
• Ô bên cạnh có thể đủ 4 hạt và sụp theo. Chuỗi sụp đó là một trận sạt lở; kích thước trận là tổng số lần sụp.

Không ai chỉnh tham số nào, nhưng lưới luôn đầy dần tới một mức nhất định rồi giữ ở đó, bất kể xuất phát từ đâu. Mức đó chính là trạng thái tới hạn, và lưới tự đi tới. Giới vật lý gọi hiện tượng này là Self-Organized Criticality, viết tắt SOC; tên bài này là cách gọi tiếng Việt của nó.

Ở trạng thái tới hạn, kích thước trận sạt lở tuân theo power law. Power law là kiểu phân phối có rất nhiều sự kiện nhỏ và ít sự kiện lớn, nhưng sự kiện lớn không bao giờ hiếm tới mức bỏ qua được. Chiều cao con người thì ngược lại: phần lớn quanh mức trung bình, không ai cao gấp mười người khác. Theo độ dốc đo ở Mục VI, trận 1.000 lần sụp chỉ hiếm hơn trận 10 lần sụp khoảng 160 lần.

Hệ quả là phân phối này không có kích thước điển hình. Cùng một hạt cát, hôm nay xáo trộn 2 ô, ngày mai kéo sạt cả lưới. Với phần mềm, câu hỏi “sự cố điển hình lớn cỡ nào” không có câu trả lời tốt, nên kế hoạch dung lượng dựa trên sự cố trung bình thường hụt. Kế hoạch dung lượng là việc tính trước cần bao nhiêu máy.

Hai điều kiện giữ đống cát ở trạng thái này:

• Nạp chậm, xả nhanh. Cát rơi từng hạt, sạt lở xảy ra gần như tức thì, nên các trận không chồng lên nhau và lưới kịp về lại mức tới hạn.
• Hệ số phân nhánh bằng 1. Hệ số phân nhánh là số lần sụp mới mà trung bình một lần sụp kéo theo. Dưới 1, chuỗi lỗi tắt dần: 0,8 lần, rồi 0,64, rồi tắt. Trên 1, đợt sập bùng lên: 1,2, rồi 1,44, rồi không dừng. Ở đúng 1, một nhiễu nhỏ có thể lan tới bất kỳ quy mô nào.

Trong cụm server, hệ số phân nhánh là số server mà trung bình một server sập kéo sập theo.

Đống cát không do ai thiết kế¹. Hệ thống phần mềm thì có. Nếu nó cũng nằm ở mép, ai đã đưa nó tới đó?

HOT: mép vực là sản phẩm của thiết kế #

Carlson và Doyle (1999) đề xuất Highly Optimized Tolerance, gọi tắt HOT, làm đối trọng cho SOC. Theo HOT, power law trong hệ do con người thiết kế đến từ chính bài toán tối ưu. Đội ngũ phải làm hệ thống chạy hiệu quả nhất trong giới hạn chi phí, đồng thời phòng thủ trước một danh sách rủi ro đã biết. Lời giải của bài toán này thường vững mà giòn: vững trước những nhiễu đã tính tới, và rất giòn trước nhiễu nằm ngoài danh sách.

Cơ chế là thế này: mỗi biện pháp chống lỗi thường ngày gom các rủi ro nhỏ lại và dồn chúng về phía những thảm họa hiếm gặp. Retry làm lỗi mạng lẻ tẻ biến khỏi thống kê, đổi lại mở ra nguy cơ retry storm khi hàng loạt request cùng gửi lại. Autoscaling giấu đi các đợt tải tăng vọt nhỏ, đổi lại mở ra khả năng một hóa đơn khổng lồ hoặc đợt thêm server hàng loạt đè sập database. Rủi ro không mất đi; nó được mua trước trả sau, đổi nhiều trục trặc nhỏ lấy ít đợt sập rất lớn.

Đây là điểm chính tôi muốn nhấn mạnh: hệ thống không trôi về mép vì quy luật tự nhiên nào bắt buộc, mà vì các đội vận hành đẩy nó tới đó qua từng sprint cắt chi phí và nâng utilization. SOC tả cách hệ trôi; HOT chỉ ra lực đẩy, như chuỗi quyết định cắt server ở Mục II, quyết định nào nhìn riêng cũng đúng.

IV. Từ đống cát sang hệ thống của bạn: bảng quy đổi #

Bảng quy đổi cần thêm một mô hình cùng họ SOC: mô hình cháy rừng của Drossel và Schwabl (1992). Cây mọc dần lên ô trống, thỉnh thoảng sét đánh, và sét trúng cây nào thì cả cụm cây liền kề với nó cháy ngay. Sét càng hiếm, rừng càng dày lên giữa hai lần cháy, và đám cháy lớn nhất càng lớn.

Trong phần mềm, “củi khô” tích dần mỗi khi một lỗi nhỏ bị che giấu thay vì sửa tận gốc. Đó là khi service rò bộ nhớ cứ đầy là tự restart, code âm thầm nuốt ngoại lệ, hay retry liên tục trên đường truyền đã đứt. Service là một phần mềm chạy trên server, lo một việc như xử lý thanh toán. Nợ kỹ thuật là những chỗ làm tạm để kịp tiến độ mà chưa quay lại sửa; nó nối các cụm nhỏ thành một khối liền, chờ một tia sét đủ lớn.

Một tháng không có cảnh báo nào trông giống một tháng yên bình. Theo mô hình này, nó cũng có thể là một tháng tích củi.

Bảng dưới quy đổi hai mô hình sang hệ thống thật. Cascading failure là sự cố dây chuyền: một server hỏng đẩy việc sang server khác, làm server đó hỏng theo. Deploy là đưa bản code mới lên chạy thật.

V. Khi nào một sự cố nhỏ lan ra cả hệ thống #

Hai điều kiện của đống cát dịch thẳng sang ngôn ngữ vận hành. Nạp chậm, xả nhanh còn đúng chừng nào thời gian khắc phục ngắn hơn nhiều so với khoảng cách giữa hai sự cố. Khi sự cố tới dày hơn tốc độ đội ngũ khắc phục, hệ không về được trạng thái nền nữa. Còn hệ số phân nhánh bị đẩy về 1 mỗi lần nâng utilization để tiết kiệm: càng ít chỗ trống, một server sập càng dễ đẩy server bên cạnh qua trần.

Một phép tính nhỏ cho thấy vì sao. Giả sử app có 10 server chia đều tải và một server sập; việc của nó chia cho 9 server còn lại. Ở 50%, mỗi server còn lại lên khoảng 56%; ở 80%, lên khoảng 89%, vẫn chạy nhưng gần hết chỗ đỡ. Ở 90%, chúng lên đúng 100%: con số đẹp nhất mà một báo cáo hiệu suất có thể ghi, và là con số cuối cùng trước khi sập. Ở 95%, 9 server phải gánh khoảng 106%, thêm một server sập, 8 server cuối gánh khoảng 119%, và cả cụm đổ theo.

Gọi mức utilization mà tại đó hàng chờ bắt đầu dài ra không dừng là ngưỡng tới hạn. Khi còn xa ngưỡng, cascading failure bị chặn nhanh, vì luôn có server còn chỗ hứng phần việc dở. Càng gần ngưỡng, giới hạn đó càng nới ra; khi hệ số phân nhánh chạm 1, giới hạn duy nhất còn lại là kích thước cả cụm.

Vậy điểm bùng phát ở đây không phải một ngưỡng dung lượng cứng bị vượt qua. Nó là lúc sự cố lớn đủ thường để sự cố toàn hệ thành chuyện định kỳ. Trước và sau điểm đó, dashboard trông y hệt nhau, vì nó đo tải hôm nay chứ không đo phân phối kích thước sự cố. Sơ đồ dưới tóm tắt ba trạng thái và lực chuyển giữa chúng.

Hệ thống phân tán là hệ thống gồm nhiều server phối hợp qua mạng. Trong loại hệ này, cơ chế đẩy hệ số phân nhánh vượt 1 rõ nhất là retry storm. Với retry 3 lần, mỗi request gốc có thể thành tới 4 lần gửi. Khi hệ đã sát trần, phần tải thêm làm request của người khác lỗi theo, họ cũng gửi lại, và tải tự nuôi chính nó dù cú kích hoạt đã qua.

Dạng lỗi kẹt này gọi là metastable failure: hệ kẹt ở trạng thái hỏng dù nguyên nhân ban đầu đã hết². Đợt sập tháng 9/2015 của DynamoDB, dịch vụ database trên cloud của Amazon (AWS), là một ví dụ: sau một lần mạng chập ngắn, retry giữ dịch vụ quá tải gần năm tiếng. Ở đợt gián đoạn của Slack tháng 1/2021, chính autoscaling góp phần: một đợt xin thêm 1.200 server trong khoảng 15 phút làm quá tải dịch vụ lo cấu hình server mới. Lớp an toàn thành một phần của chuỗi lỗi, đúng kiểu vững mà giòn ở Mục III.

Vì sao hệ kẹt lại sau khi cú kích hoạt đã qua là chủ đề của Bài 06. Ở đây chỉ cần một kết luận: muốn hệ ổn định, phải đưa hệ số phân nhánh xuống dưới 1 và giới hạn phạm vi lan của mỗi cascading failure. Còn đống cát có thật sự tự tìm tới mép không, Mục VI kiểm tra.

VI. Mô phỏng: đống cát tự tìm tới mép #

Tôi dựng lại trò chơi ở Mục III: lưới 64 × 64 ô, thả 60.000 hạt cát, đếm số lần sụp của từng trận. Kết quả có 23.398 trận sạt lở. Một nửa số trận có không quá 24 lần sụp. Nhưng cứ khoảng 10 trận lại có 1 trận từ 1.000 lần sụp trở lên, và trận lớn nhất có 16.480 lần sụp, gấp khoảng bốn lần số ô trên lưới.

Mọi hạt cát đều như nhau. Nếu tôi phải viết báo cáo sự cố cho trận 16.480 lần sụp, mục “nguyên nhân gốc” chỉ có một dòng: một hạt cát, giống hệt 59.999 hạt kia.

Cách đọc biểu đồ: trục ngang là kích thước trận, trục dọc (ghi P(s)) là xác suất gặp một trận cỡ đó; cả hai theo thang log, mỗi vạch lớn gấp 10 lần vạch trước. Trên thang này, power law là một đường thẳng. Các chấm cam bám đường đứt nét tới khoảng 1.000 lần sụp với độ dốc khoảng 1,1, nằm trong khoảng các nghiên cứu khác báo cáo cho lưới hai chiều³.

Ở cuối đường, các chấm cắm xuống dưới đường đứt nét: trận lớn nhất bị mép lưới chặn lại, giống như phạm vi lan của một đợt sập bị chặn bởi kích thước cụm server. Quan trọng hơn, không tham số nào được chỉnh để ra đường thẳng này; sau khoảng 9.000 hạt đầu, lưới tự tới trạng thái tới hạn và ở lại. Đó là phần “tự tổ chức” của SOC. Với phần mềm, nó nghĩa là không có công tắc cấu hình nào tắt được xu hướng trôi về mép, chỉ có cách liên tục đẩy ngược lại.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

import numpy as np

def run_sandpile(size=64, grains=60_000, z_c=4, seed=42):
    rng = np.random.default_rng(seed)
    grid = np.zeros((size, size), dtype=np.int64)
    avalanche_sizes = []

    for _ in range(grains):
        x, y = rng.integers(0, size, size=2)
        grid[x, y] += 1
        toppled = 0

        # Ô nào đủ 4 hạt thì sụp, chia đều cho 4 ô bên cạnh.
        # Cát rơi ra ngoài biên coi như mất - đây là cơ chế xả năng lượng.
        while np.any(grid >= z_c):
            xs, ys = np.where(grid >= z_c)
            toppled += len(xs)
            grid[xs, ys] -= z_c
            for dx, dy in ((1, 0), (-1, 0), (0, 1), (0, -1)):
                nx, ny = xs + dx, ys + dy
                inside = (nx >= 0) & (nx < size) & (ny >= 0) & (ny < size)
                np.add.at(grid, (nx[inside], ny[inside]), 1)

        if toppled:
            avalanche_sizes.append(toppled)

    return np.array(avalanche_sizes)

sizes = run_sandpile()
print(f"Số trận sạt lở:      {len(sizes)}")
print(f"Kích thước trung vị: {np.median(sizes):.0f}")
print(f"Trận lớn nhất:       {sizes.max()}")

# Độ dốc: chia nhóm theo thang log, kẻ đường thẳng tới 1.000 lần sụp.
edges = np.unique(np.logspace(0, np.log10(sizes.max() + 1), 30).astype(int))
density, _ = np.histogram(sizes, bins=edges, density=True)
centers = np.sqrt(edges[:-1] * edges[1:])
keep = (density > 0) & (centers <= 1_000)
slope, _ = np.polyfit(np.log10(centers[keep]), np.log10(density[keep]), 1)
print(f"Độ dốc tau:          {-slope:.2f}")

VII. Ba cách giữ hệ thống lùi khỏi mép, và cái giá của từng cách #

Nếu áp lực kinh tế không đổi và HOT đúng, không kiến trúc nào ngăn được hệ thống tiến về mép. Việc làm được là giữ khoảng cách tới ngưỡng và giới hạn phạm vi lan của mỗi cascading failure. Các biện pháp nhắm thẳng vào vòng lặp retry, như đặt trần cho tổng số lần gửi lại hay tự điều chỉnh số request nhận cùng lúc, thuộc một bài sau trong series.

1. Chừa headroom, đừng chạy sát mức tới hạn. Headroom là phần đệm hấp thụ cú kích hoạt, không phải lãng phí. Một số đội giữ utilization không quá khoảng 60% cho những service cần phản hồi nhanh. Ở mức đó, cụm 10 server ở Mục V mất liền 3 server thì 7 server còn lại mới lên khoảng 86%. Đây là quyết định ở tầng ngân sách chứ không ở tầng code, vì nó đi ngược đúng lực đã đẩy hệ tới mép ở Mục II. Và headroom là khoản khó bảo vệ nhất trong buổi họp ngân sách, vì nhìn qua nó giống hệt tiền trả cho máy chạy không.

   Câu nên hỏi đội kỹ thuật: utilization giờ cao điểm của hệ thống là bao nhiêu, và nếu mất một server thì con số đó vọt lên bao nhiêu?

2. Kiểm soát đầu vào: giới hạn tốc độ thả cát. Kiểm soát đầu vào là quyết định ngay từ cửa có nhận một request hay không. Khi hàng chờ bắt đầu dồn, nhận thêm việc chỉ đẩy hệ sâu hơn vào vùng tới hạn. Từ chối sớm lưu lượng không thiết yếu bằng lỗi 503, mã báo “dịch vụ tạm thời không phục vụ được”, giữ phần lớn lưu lượng còn chạy và chặn cascading failure từ gốc. Ở app giao đồ ăn, đó là tạm tắt phần gợi ý món để phần đặt món còn chạy; cái giá là chủ động bỏ một phần request thật, nên thứ tự ưu tiên phải đúng.

3. Chaos engineering như đốt rừng có kiểm soát. Chaos engineering là chủ động gây lỗi, như tắt ngẫu nhiên một server hay làm chậm mạng, để xem hệ thống chịu được tới đâu. Theo mô hình cháy rừng ở Mục IV, dập sạch mọi lỗi nhỏ chỉ tích củi cho đám cháy lớn. Gây lỗi có chủ đích là đốt trước những cụm mong manh ở quy mô còn kiểm soát được, và buộc cơ chế phục hồi chạy thật trước khi khủng hoảng thật tới.

VIII. Tài liệu tham khảo #

• Amazon Web Services (2015). Summary of the Amazon DynamoDB Service Disruption and Related Impacts in the US-East Region.
• Bak, P., Tang, C., & Wiesenfeld, K. (1987). Self-organized criticality: An explanation of the 1/f noise.
• Bronson, N., Aghayev, A., Charapko, A., & Zhu, T. (2021). Metastable Failures in Distributed Systems.
• Carlson, J. M., & Doyle, J. (1999). Highly optimized tolerance: A mechanism for power laws in designed systems.
• Dekker, S. (2011). Drift into Failure: From Hunting Broken Components to Understanding Complex Systems. Ashgate.
• Dhar, D. (1990). Self-organized critical state of sandpile automaton models.
• Drossel, B., & Schwabl, F. (1992). Self-organized critical forest-fire model.
• Frigg, R. (2003). Self-organised criticality — what it is and what it isn’t.
• Huang, L., Magnusson, M., Muralikrishna, A. B., et al. (2022). Metastable Failures in the Wild.
• Nolan, L. (2021). Slack’s Outage on January 4th 2021. Slack Engineering.
• Rasmussen, J. (1997). Risk management in a dynamic society: A modelling problem.