Kiến trúc dựa trên cell (Cell-Based Architecture) và cô lập bán kính ảnh hưởng

1. Tổng quan

Định nghĩa: Kiến trúc dựa trên cell là một mẫu kiến trúc lấy tính sẵn sàng làm trung tâm, phân chia toàn bộ hệ thống thành nhiều cell độc lập và tự hoàn chỉnh — mỗi cell là một đơn vị triển khai tự chứa (self-contained) có đầy đủ compute, dữ liệu, hàng đợi và cache — rồi để bộ định tuyến cell (Cell Router) cố định định tuyến mỗi yêu cầu tới một cell cụ thể theo khóa phân vùng, nhờ đó dù xảy ra sự cố, triển khai lỗi hay quá tải nào thì ảnh hưởng của nó cũng được chứa (contain) trong một cell duy nhất.

Khi điện toán đám mây và microservices trở nên phổ biến, hệ thống vận hành trên hàng nghìn dịch vụ và hạ tầng khổng lồ, và một cách nghịch lý, vấn đề một khiếm khuyết duy nhất lan ra toàn bộ — "bán kính ảnh hưởng vô hạn (unlimited blast radius)" càng thêm trầm trọng. Khi một cơ sở dữ liệu dùng chung bị bão hòa, một cấu hình sai được triển khai toàn cục, hoặc lưu lượng bất thường của một tenant (poison pill) làm cạn tài nguyên dùng chung, thì dù dịch vụ có được chia nhỏ đến đâu, sự cố vẫn lan tới mọi khách hàng cùng lúc. Từ cuối thập niên 2010, các dịch vụ quy mô lớn như Slack, DoorDash, Roblox đã trải qua các sự cố cấp vùng sẵn sàng (AZ) và sự cố toàn cục, khiến triết lý thiết kế dịch chuyển từ "ngăn chặn thất bại" sang "giới hạn ngay từ đầu phạm vi mà thất bại lan ra bằng biện pháp vật lý", và kiến trúc dựa trên cell nổi lên như lời giải cụ thể.

Nhận thức cốt lõi của kiến trúc dựa trên cell là tính sẵn sàng phải được quản lý như tổng của các đơn vị được cô lập, chứ không phải tích của các xác suất. Trong một hệ thống nguyên khối, xác suất sự cố p chuyển trực tiếp thành ảnh hưởng toàn bộ, nhưng khi chia hệ thống thành N cell độc lập, sự cố của một cell về nguyên tắc chỉ ảnh hưởng tới 1/N tổng số khách hàng. Nghĩa là tăng số cell là hành động thu nhỏ bán kính ảnh hưởng theo số học, và nếu kết hợp thêm Shuffle Sharding trình bày bên dưới thì có thể tối đa hóa mức cô lập theo tổ hợp. AWS chính thức hóa tư duy này thành kiến trúc bulkhead (REL10) của trụ cột độ tin cậy trong Well-Architected Framework, trình bày như thực hành tốt nhất "giới hạn phạm vi ảnh hưởng của sự cố".

Điều cần lưu ý ở đây là kiến trúc dựa trên cell khác với dự phòng (redundancy) đơn thuần. Dự phòng truyền thống đặt các bản sao của cùng một hệ thống và chuyển sang bản khác khi một bản chết — một chiến lược "sẵn sàng" — nhưng vì các bản sao chia sẻ cùng mã, cùng cấu hình và cùng khiếm khuyết, nó bất lực trước các sự cố tương quan (correlated failure) như triển khai lỗi hay lỗi phần mềm. Cell cũng đặt bản sao nhưng triển khai thay đổi theo từng cell một cách lệch pha (decorrelated), nhờ đó chứa được cả sự cố "mọi bản sao chết cùng lúc vì cùng một lý do" mà dự phòng không ngăn được. Chính việc chứa sự cố tương quan này là giá trị độc đáo mà kiến trúc cell mang lại.

Các đặc trưng có thể tóm tắt như sau. Thứ nhất, tính hoàn chỉnh — mỗi cell xử lý một yêu cầu từ đầu đến cuối một cách độc lập mà không chia sẻ tài nguyên của cell khác. Thứ hai, định tuyến cố định — cùng một khóa phân vùng luôn ánh xạ tới cùng một cell, đảm bảo nhất quán trạng thái và dễ gỡ lỗi. Thứ ba, khả năng nhân bản theo chiều ngang — cell là các bản sao có cùng cấu hình, nên khi thiếu năng lực thì mở rộng bằng cách "in thêm" cell. Thứ tư, triển khai độc lập — thay đổi được triển khai theo từng cell để chặn triển khai lỗi lan ra toàn cục. Thứ năm, năng lực dự đoán được — nếu đo trước thông lượng tối đa của một cell, có thể lập kế hoạch tổng năng lực bằng mô hình tuyến tính "năng lực cell × số cell", tránh được vách hiệu năng phi tuyến và dự đoán được thời điểm mở rộng theo tăng trưởng bằng con số.

Tổng hợp lại, kiến trúc dựa trên cell là cách tiếp cận trên tiền đề "sự cố nhất định sẽ xảy ra" nhằm đặt trước trần cho phạm vi thiệt hại tối đa bằng thiết kế, và vì nâng đồng thời tính sẵn sàng, khả năng mở rộng và an toàn triển khai qua một chiến lược phân chia duy nhất, nó được đánh giá là mẫu độ tin cậy cốt lõi cho các hệ thống phân tán quy mô lớn.

2. Cấu trúc tổng thể và các thành phần

Kiến trúc dựa trên cell nhìn từ bên ngoài giống như một dịch vụ đơn, nhưng bên trong gồm một tầng định tuyến mỏng, nhiều cell độc lập, và một control plane điều phối chúng. Nhìn bao quát cấu trúc tổng thể như sau.

graph TD
    U["Yêu cầu người dùng/tenant"] --> R["Bộ định tuyến cell (Cell Router)"]
    R -->|"băm khóa phân vùng"| C1
    R --> C2
    R --> C3
    subgraph C1["Cell 1"]
      A1["API/compute"] --> B1["DB/cache/hàng đợi riêng"]
    end
    subgraph C2["Cell 2"]
      A2["API/compute"] --> B2["DB/cache/hàng đợi riêng"]
    end
    subgraph C3["Cell N"]
      A3["API/compute"] --> B3["DB/cache/hàng đợi riêng"]
    end
    CP["Control Plane"] -.->|"ánh xạ/triển khai/năng lực"| R
    CP -.-> C1
    CP -.-> C2
    CP -.-> C3

A. Cell — miền sự cố tự chứa

Cell là đơn vị cơ bản của kiến trúc này, là một ngăn xếp hoàn chỉnh chứa mọi thành phần mà dịch vụ cần để xử lý một yêu cầu từ đầu đến cuối. Bên trong một cell có đầy đủ API gateway, compute ứng dụng, kho dữ liệu riêng, hàng đợi thông điệp và cache, và về nguyên tắc không chia sẻ bất kỳ trạng thái nào với cell khác. Nguyên tắc "không chia sẻ (share-nothing)" này là cơ sở vật lý của sự cô lập. Dù cơ sở dữ liệu của một cell ngừng vì tranh chấp khóa, cơ sở dữ liệu của cell khác hoàn toàn không bị ảnh hưởng.

Kích thước cell (cell size) quyết định sự đánh đổi cốt lõi của thiết kế. Nhiều cell nhỏ thì bán kính ảnh hưởng giảm nhưng chi phí hạ tầng cố định lặp lại trên mỗi cell và độ phức tạp vận hành tăng. Ngược lại ít cell lớn thì hiệu quả chi phí tốt nhưng ảnh hưởng của một cell gặp sự cố lớn hơn. Trong thực tế, người ta đặt trần bằng cách xác định đồng thời "số tenant tối đa một cell gánh được" và "tỷ lệ khách hàng chấp nhận được khi một cell gặp sự cố", và vận hành bằng cách thêm cell mới khi một cell chạm trần đó.

Hơn nữa cell cũng là đơn vị vận hành nhỏ nhất có thể kiểm thử và xác thực. Nếu đo trước năng lực xử lý tối đa của một cell bằng kiểm thử tải, có thể đơn giản hóa việc lập kế hoạch năng lực toàn hệ thống thành mô hình tuyến tính "năng lực cell × số cell". Điều này mang lại lợi ích thực tiễn là làm cho giới hạn năng lực — vốn xuất hiện phi tuyến trong một hệ thống nguyên khối khổng lồ — trở nên dự đoán được.

B. Bộ định tuyến cell (Cell Router) — tầng mỏng nhưng quan trọng nhất

Bộ định tuyến cell là tầng nhìn khóa phân vùng (ví dụ: ID khách hàng, ID tenant, số tài khoản) của yêu cầu đến để quyết định gửi tới cell nào. Bộ định tuyến phải cực kỳ đơn giản và cực kỳ ổn định. Bởi vì nếu bản thân bộ định tuyến phức tạp hoặc giữ trạng thái phụ thuộc vào cell, nó sẽ trở thành một điểm lỗi đơn (SPOF) mới và một bán kính ảnh hưởng dùng chung, làm sụp đổ chính ý nghĩa của việc cô lập cell. Do đó bộ định tuyến được thiết kế chỉ dùng ánh xạ băm phi trạng thái (stateless), hoặc một bảng ánh xạ (khóa phân vùng → ID cell) ít thay đổi và được nhân bản sẵn sàng cao.

Vì tính sẵn sàng của bộ định tuyến quyết định trần của tính sẵn sàng toàn cục, bộ định tuyến được vận hành thận trọng hơn nhiều so với cell. Nhiều triển khai cấu thành bộ định tuyến bằng DNS (ví dụ: Route 53), bộ cân bằng tải L7, hoặc một dịch vụ định tuyến nhẹ, và không đưa quy tắc nghiệp vụ vào logic của bộ định tuyến. Nếu bộ định tuyến tham chiếu sức khỏe của cell để vòng tránh cell gặp sự cố thì tính sẵn sàng tăng, nhưng bộ định tuyến lại gắn kết với trạng thái cell và độ phức tạp tăng, nên khuyến nghị phân công vai trò "bộ định tuyến giữ đơn giản, phục hồi do control plane đảm nhận".

Việc chọn khóa phân vùng quyết định thành bại của kiến trúc. Khóa phải đảm bảo tính cục bộ dữ liệu (locality) để một yêu cầu hoàn tất trong một cell, đồng thời tạo phân bố đều để tải không dồn vào một cell cụ thể. Chẳng hạn trong thương mại điện tử, nếu dùng "ID đơn hàng" làm khóa thì xử lý đơn hàng kết thúc trong một cell nhưng việc truy vấn toàn bộ đơn hàng của một khách hàng có thể phân tán trên nhiều cell gây truy vấn xuyên cell; ngược lại nếu dùng "ID khách hàng" thì truy vấn lấy khách hàng làm trung tâm kết thúc trong một cell nhưng một khách hàng siêu lớn có thể làm bão hòa một cell cụ thể, gây vấn đề cell nóng (hot cell). Do đó phải phân tích đặc tính miền và mẫu truy vấn để chọn khóa, và thiết kế kèm chiến lược tái phân bố cell nóng.

Ví dụ cụ thể, trong mô tả của AWS Well-Architected, Route 53 thực hiện định tuyến bằng cách gán một khách hàng vào một shard cụ thể (gồm hai cell trở lên). Vì thay đổi quy tắc định tuyến (tái bố trí cell) kéo theo di trú dữ liệu, nên phải xác định việc chọn khóa phân vùng và chiến lược tái bố trí ngay tại thời điểm thiết kế bộ định tuyến.

C. Tách Control Plane và Data Plane

Kiến trúc dựa trên cell tách rõ data plane xử lý yêu cầu (bộ định tuyến + các cell) khỏi control plane quản lý hệ thống (tạo/xóa cell, cập nhật ánh xạ, điều phối triển khai, tái phân bố năng lực). Sự tách này quan trọng vì control plane tương đối phức tạp và thay đổi thường xuyên nên khả năng sự cố cao, trong khi data plane sống còn nhờ sự đơn giản và ổn định. Dù control plane ngừng tạm thời, các yêu cầu đã được định tuyến vẫn phải được xử lý bình thường trong mỗi cell (tính ổn định tĩnh, static stability).

Tính ổn định tĩnh là tính chất "data plane tiếp tục vận hành ở trạng thái tốt được biết cuối cùng ngay cả khi không có control plane". Chẳng hạn việc thêm cell mới hay thay đổi ánh xạ là trách nhiệm của control plane, nhưng dù công việc đó thất bại, các cell hiện có vẫn tiếp tục phục vụ mà không bị ảnh hưởng. Nguyên tắc này ngăn các sự cố quy mô lớn lan ra theo dạng thường gặp "control plane kéo data plane xuống".

Control plane cũng là điểm tụ của khả năng quan sát (Observability). Nó thu thập tỷ lệ lỗi, độ trễ, mức bão hòa của từng cell để phán đoán cell nào bất thường, và quyết định mở rộng triển khai sang cell tiếp theo hay quay lui. Tuy nhiên phải thiết kế sao cho đường quan sát này không trở thành thiết yếu đối với hoạt động bình thường của data plane — một sự cố quan sát không được trở thành sự cố dịch vụ.

D. Shuffle Sharding — tối đa hóa cô lập theo tổ hợp

Việc chia khách hàng 1:1 vào mỗi cell chỉ đơn thuần thu nhỏ bán kính ảnh hưởng còn 1/N, nhưng những khách hàng dồn vào một cell vẫn chịu thiệt hại toàn bộ khi cell đó gặp sự cố. Shuffle sharding là kỹ thuật gán mỗi khách hàng (hoặc workload) không vào một cell mà vào một tổ hợp nhiều cell khác nhau, giảm mạnh xác suất hai khách hàng chia sẻ chính xác cùng một tổ hợp cell.

Ví dụ của AWS rất trực quan. Giả sử có 8 cell và một shard gồm 2 cell. Với sharding theo quy tắc thông thường chỉ có 4 shard, nên khi một shard gặp vấn đề thì 25% (1/4) tổng khách hàng bị ảnh hưởng. Nhưng shuffle sharding có thể tạo C(8,2) = 28 tổ hợp duy nhất của 2 trong 8 cell, nên ảnh hưởng của một vấn đề giảm còn khoảng 1/28 — bán kính ảnh hưởng hẹp hơn khoảng 7 lần so với sharding theo quy tắc. Số cell và kích thước shard càng lớn thì số tổ hợp càng bùng nổ, nên mức cô lập cải thiện theo hàm mũ.

Sự gia tăng số tổ hợp càng kịch tính hơn khi quy mô lớn. Càng nhiều cell, và chỉ cần tăng nhẹ số cell cấu thành một shard, số tổ hợp cũng tăng bùng nổ. Chẳng hạn chọn 5 trong 100 cell cho khoảng 75 triệu tổ hợp, nên xác suất hai workload chia sẻ chính xác cùng một tập cell hội tụ về gần như 0. Đây là cơ sở toán học để AWS Route 53 và các dịch vụ đa tenant quy mô lớn phòng vệ bằng shuffle sharding trước tình huống "một thiểu số rất nhỏ tenant bất thường (noisy/poison tenant) kéo toàn bộ xuống". Tuy nhiên mức cô lập càng cao thì mỗi shard càng cần nhiều năng lực dự phòng (redundancy), nên điểm cân bằng giữa cô lập và chi phí được điều chỉnh bằng kích thước tổ hợp.

Tuy vậy hướng dẫn kiến trúc dựa trên cell của AWS cảnh báo rằng shuffle sharding nên áp dụng "bên trong" cell và không được làm mờ ranh giới cell bằng cách chia sẻ trạng thái xuyên cell. Nghĩa là dù phân nhỏ cô lập bằng shuffle sharding, nguyên tắc không chia sẻ giữa các cell vẫn phải được giữ nguyên. Nếu không tuân thủ ràng buộc này, lợi ích tổ hợp lại bị triệt tiêu bởi bán kính ảnh hưởng dùng chung phát sinh từ phụ thuộc xuyên cell.

3. Quy trình xử lý yêu cầu và triển khai tịnh tiến

Giá trị của kiến trúc dựa trên cell thể hiện ở sự chứa đựng khi sự cố và khi triển khai nhiều hơn là ở định tuyến lúc bình thường. Đặc biệt, nó chặn loại sự cố quy mô lớn phổ biến nhất — "triển khai lỗi lan ra toàn cục" — bằng triển khai tịnh tiến theo từng cell (wave deployment). Sơ đồ hóa luồng triển khai như sau.

graph LR
    S["bắt đầu thay đổi/triển khai"] --> W1["Đợt 1: một cell (canary)"]
    W1 --> H{"tỷ lệ lỗi/độ trễ bình thường?"}
    H -->|"có"| W2["Đợt 2: mở rộng ra một số cell"]
    H -->|"không"| RB["chỉ quay lui cell đó<br/>bán kính ảnh hưởng = 1 cell"]
    W2 --> W3["Đợt 3: mở rộng tuần tự ra mọi cell"]
    W3 --> DONE["đã triển khai toàn bộ"]

Triển khai luôn bắt đầu từ một cell (hoặc một số ít cell rủi ro thấp). Nếu quan sát tỷ lệ lỗi, độ trễ, mức bão hòa ở cell thứ nhất này và đánh giá là khỏe mạnh thì mở rộng sang đợt tiếp theo, nếu phát hiện bất thường thì chỉ quay lui cell đó. Cốt lõi của cấu trúc này là dù triển khai có lỗi thì thiệt hại cũng chỉ giới hạn ở khách hàng của một cell — một sự cố mà nếu triển khai đồng thời toàn cục sẽ gây hại cho toàn bộ khách hàng thì ở triển khai theo cell được thu nhỏ thành sự cố 1/N.

Hãy cảm nhận bằng con số cụ thể. Nếu tổng khách hàng là 10 triệu người và hệ thống gồm 50 cell, thì khi triển khai lỗi bị chặn lại ở cell canary thứ nhất, khách hàng bị ảnh hưởng chỉ khoảng 200.000 người (1/50). Nếu là triển khai đồng thời toàn cục, cùng khiếm khuyết đó sẽ lan ngay tới toàn bộ 10 triệu người. Hơn nữa, nếu cấu thành cell thứ nhất bằng "nhân viên nội bộ / tenant rủi ro thấp" thì ảnh hưởng thực tế tới khách hàng bên ngoài có thể đưa về gần 0. Như vậy cell cung cấp cấu trúc "sự cố có thể xảy ra, nhưng quy mô thiệt hại tối đa khi xảy ra đã bị đóng đinh thành trần ngay tại thời điểm thiết kế".

Ở góc độ chuyển đổi dự phòng (failover), cell cũng rất mạnh. Khi một cell hoặc vùng sẵn sàng cụ thể gặp vấn đề, control plane sẽ rút cạn (drain) lưu lượng của cell đó sang các cell khỏe mạnh hoặc loại nó khỏi định tuyến. Chẳng hạn Slack báo cáo rằng sau khi áp dụng cấu hình cell theo vùng sẵn sàng, họ đã có thể rút cạn dần toàn bộ lưu lượng của một AZ gặp vấn đề trong khoảng 5 phút. Đây là ví dụ chuyển mục tiêu phục hồi từ "thời gian sửa sự cố" sang "thời gian vòng tránh sự cố".

Thành phần	Vai trò	Nguyên tắc thiết kế	Ảnh hưởng khi lỗi
Bộ định tuyến cell	ánh xạ khóa phân vùng → cell	đơn giản/phi trạng thái/siêu sẵn sàng	ảnh hưởng toàn bộ (nguy hiểm nhất)
Cell	xử lý yêu cầu tự chứa	không chia sẻ/nhân bản được	giới hạn ở 1/N khách hàng
Control plane	triển khai/ánh xạ/năng lực	tách khỏi data plane/ổn định tĩnh	suy giảm quản lý (dịch vụ tiếp tục)
Shuffle sharding	cô lập theo tổ hợp	áp dụng bên trong cell/giữ ranh giới	giảm mức cô lập

Bảng trên chỉ là phần tóm tắt bổ trợ, còn bản chất "vì sao phải thiết kế từng thành phần như vậy" nằm ở phần diễn giải văn xuôi của các mục trước. Đặc biệt, việc ảnh hưởng khi lỗi của bộ định tuyến là "toàn bộ" chính là gót chân Achilles của kiến trúc cell, và vì thế giữ bộ định tuyến đơn giản nhất có thể một cách nghịch lý lại là quyết định thiết kế quan trọng nhất.

4. So sánh với các mẫu tương tự

Kiến trúc dựa trên cell thường bị nhầm với bulkhead, microservices, đa tenant và sharding, nhưng "phạm vi" và "tầng" của sự cô lập khác nhau. Mẫu bulkhead chủ yếu tách tài nguyên như thread pool, connection pool bên trong một dịch vụ để sự bão hòa của một phụ thuộc không lan sang chức năng khác. Ngược lại, kiến trúc dựa trên cell nhân bản và phân chia toàn bộ hệ thống theo đơn vị full-stack, là mức cô lập ở tầng lớn hơn nhiều. Nghĩa là nếu bulkhead là "vách ngăn kín nước của con tàu" thì cell gần với "nhiều con tàu giống hệt nhau cùng chạy độc lập".

Sự khác biệt với microservices cũng quan trọng. Microservices chia hệ thống theo chức năng (chiều dọc), nhưng các dịch vụ vẫn vận hành trên hạ tầng dùng chung, DB dùng chung và đường ống triển khai toàn cục, nên bán kính ảnh hưởng có thể vẫn ở mức toàn cục. Thực tế InfoQ chỉ ra rằng "các kiến trúc microservices quy mô lớn đã trải qua những sự cố nghiêm trọng vì bán kính ảnh hưởng vô hạn của hạ tầng dùng chung". Kiến trúc dựa trên cell là mẫu bổ trợ lẫn nhau, phân chia lại chùm microservices này theo khách hàng/workload (chiều ngang) để thêm sự cô lập.

Nó cũng được so với sharding cơ sở dữ liệu. Sharding chỉ phân chia tầng dữ liệu, trong khi cell phân chia toàn bộ ngăn xếp bao gồm không chỉ dữ liệu mà cả compute, hàng đợi và cache. Vì vậy cell cung cấp "sự cô lập toàn bộ đường đi của yêu cầu", còn chỉ riêng sharding thì tầng ứng dụng dùng chung vẫn là điểm lỗi chung. Khác biệt này là câu trả lời cho "chỉ cần chia dữ liệu là xong mà, tại sao phải đi tới tận cell?" — vì sự cố xảy ra không chỉ ở tầng dữ liệu mà ở bất cứ đâu.

Quan hệ với kiến trúc đa tenant cũng đáng nhắc tới. Đa tenant là một phổ về việc nhiều tenant dùng chung tài nguyên (pooled) hay tách riêng (siloed), và kiến trúc dựa trên cell có thể xem là chiến lược trung gian "gom tenant theo cell rồi tách riêng" trên phổ này. Nghĩa là đặt mọi tenant vào một pool thì chi phí thấp nhất nhưng bán kính ảnh hưởng lớn nhất, còn cho mỗi tenant một ngăn xếp riêng thì cô lập hoàn hảo nhưng chi phí bùng nổ. Cell cung cấp điểm thỏa hiệp thực tiễn ở giữa bằng cách "gom N tenant vào một cell nhưng tách hoàn toàn giữa các cell". Như vậy mỗi mẫu không phải vật thay thế mà là vật bổ trợ ở tầng cô lập khác nhau, và trong thực tế người ta kết hợp theo nhiều tầng cô lập: bulkhead (bên trong dịch vụ) → microservices (theo chức năng) → cell (theo khách hàng/workload) → region (theo địa lý) để cấu thành phòng vệ chiều sâu.

5. Chuyên sâu — ứng dụng trong công nghiệp và xu hướng mới nhất

Gần đây kiến trúc dựa trên cell lan nhanh như một chiến lược tính sẵn sàng cho các dịch vụ siêu lớn, và nhiều trường hợp công bố của các công ty cho thấy các lựa chọn thiết kế cụ thể.

Slack, sau khi trải qua sự cố mạng cấp AZ, đã di trú phần lớn các dịch vụ hướng người dùng cốt lõi sang cell. Họ cấu hình mỗi AZ chứa một triển khai backend hoàn toàn cô lập và nhốt các thành phần vào một AZ duy nhất để loại bỏ phụ thuộc xuyên AZ. Kết quả là họ có thể rút cạn toàn bộ lưu lượng của một AZ gặp vấn đề trong khoảng 5 phút. Điều này cho thấy hiệu quả của kiến trúc cell được tối đa hóa khi kết hợp "cô lập + di chuyển lưu lượng nhanh".

DoorDash đã chuyển sang thiết kế cell dựa trên AZ bằng cách tận dụng định tuyến nhận biết vùng (zone-aware routing) của service mesh trên nền Envoy. Mỗi cell gồm nhiều cụm Kubernetes, và mỗi microservice chỉ được triển khai vào một cụm trong một cell nhất định. Một tác dụng phụ thú vị là lưu lượng xuyên AZ giảm và cả chi phí truyền dữ liệu cũng được cắt giảm — một trường hợp cải thiện đồng thời hai mục tiêu dễ xung đột là tính sẵn sàng và chi phí.

Roblox đang tái tổ chức hạ tầng thành cell trong quá trình mở rộng để nâng hiệu quả và khả năng phục hồi, và để có thể vô hiệu hóa một cell bất thường mà không ảnh hưởng tới toàn hệ thống. Động cơ chung của mọi trường hợp đều là "loại bỏ bán kính ảnh hưởng vô hạn của hạ tầng dùng chung". Về mặt chuẩn hóa, AWS đã hệ thống hóa thiết kế dựa trên cell thành thực hành tốt nhất qua trụ cột độ tin cậy của Well-Architected (REL10: dùng ranh giới cô lập sự cố) và nhiều whitepaper; về hướng ra đề dự kiến, "chiến lược kiến trúc để ngăn sự cố toàn cục trong các hệ thống công/tài chính quy mô lớn", "thiết kế chứa đựng sự cố AZ/region", và "cô lập tenant bằng shuffle sharding" là những chất liệu luận văn có khả năng cao.

6. Các điểm cần cân nhắc và hàm ý

Vì kiến trúc dựa trên cell là sự chuyển đổi tư duy từ "loại bỏ sự cố" sang "giới hạn phạm vi sự cố bằng thiết kế", nên ở góc độ Kỹ sư chuyên nghiệp cần cân nhắc cân bằng các điểm sau.

Chiến lược đánh đổi về kích thước và số lượng cell: Chia cell càng nhỏ thì bán kính ảnh hưởng càng giảm, nhưng chi phí hạ tầng cố định/giám sát/định tuyến lặp lại trên mỗi cell và độ phức tạp vận hành tăng hơn cả tuyến tính. Quyết định cốt lõi là đặt trần cell bằng cách suy ngược "tỷ lệ ảnh hưởng khách hàng tối đa chấp nhận được" từ SLA, và tìm điểm mà hiệu quả cô lập bão hòa so với chi phí. Phải trình bày được điểm cân bằng giữa chi phí (redundant infrastructure) và khả năng phục hồi một cách định lượng.
Quản lý trần tính sẵn sàng của bộ định tuyến và control plane: Dù cô lập cell tốt đến đâu, nếu bộ định tuyến hay control plane còn là điểm lỗi đơn dùng chung thì tính sẵn sàng toàn cục bị trói vào mắt xích yếu đó. Điều kiện tiên quyết là giữ bộ định tuyến cực kỳ đơn giản và phi trạng thái, tách control plane khỏi data plane để bảo đảm tính ổn định tĩnh, và thiết kế sao cho sự cố control plane không lan thành gián đoạn dịch vụ.
Kiểm soát phụ thuộc xuyên cell: Ngay khoảnh khắc nảy sinh phụ thuộc dữ liệu/lời gọi giữa các cell, sự cô lập sụp đổ và bán kính ảnh hưởng dùng chung sống lại. Do đó phải xác minh ở giai đoạn thiết kế khóa phân vùng rằng "một yêu cầu có hoàn tất trong một cell hay không", và tách các tương tác xuyên cell không tránh khỏi (ví dụ: tổng hợp toàn cục, tính cước) sang đường bất đồng bộ, giao dịch bù trừ, bản sao chỉ đọc để giảm thiểu suy giảm tính sẵn sàng.
Khả năng vận hành di trú dữ liệu và tái bố trí: Thêm cell, tái phân bố tải của cell nóng (hot cell), di chuyển tenant là các thao tác khó độ cao kéo theo di trú dữ liệu. Nếu không tự động hóa trước quy trình thay đổi ánh xạ không gián đoạn, bảo đảm nhất quán trong lúc di trú, và kế hoạch quay lui, thì lợi ích của cô lập bị triệt tiêu bởi rủi ro vận hành.
Liên kết với khả năng quan sát và chaos engineering: Phải thu thập độc lập các chỉ số của từng cell (tỷ lệ lỗi, mức bão hòa, độ trễ) và liên tục xác minh bằng tiêm sự cố cấp cell (chaos engineering) xem "toàn bộ có chịu được khi giết một cell hay không", thì mới bảo đảm được sự chứa đựng khi sự cố thật. Về triển vọng, định tuyến nhận biết vùng của service mesh, topo cell đa AZ/đa region, và tự động hóa cấp phát cell của platform engineering sẽ kết hợp lại, và kiến trúc cell được kỳ vọng sẽ định hình thành mẫu độ tin cậy chuẩn mực cho các hệ thống quy mô lớn.

Tài liệu tham khảo

AWS Well-Architected Framework, REL10-BP03 Use bulkhead architectures to limit scope of impact — https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_use_bulkhead.html
InfoQ, How Cell-Based Architecture Enhances Modern Distributed Systems — https://www.infoq.com/articles/cell-based-architecture-distributed-systems
InfoQ, Slack's Migration to a Cellular Architecture — https://www.infoq.com/news/2024/01/slack-cell-based-architecture
Rackspace, Cell-Based Architecture on AWS — https://www.rackspace.com/blog/cell-based-architecture-aws

Tóm tắt một câu: Kiến trúc dựa trên cell phân chia hệ thống thành các cell tự hoàn chỉnh không chia sẻ và cố định định tuyến yêu cầu theo khóa phân vùng qua một bộ định tuyến đơn giản, sẵn sàng cao, chứa bán kính ảnh hưởng của sự cố, triển khai lỗi và quá tải trong 1/N (với shuffle sharding thì nhỏ hơn nữa theo tổ hợp) — một mẫu lấy tính sẵn sàng làm trung tâm.