System Design — Bài 4: Scalability: mở rộng hệ thống từ đúng điểm nghẽn

Bạn tăng số app server lên gấp ba nhưng throughput gần như giữ nguyên. Điều đó thường cho thấy tài nguyên dùng chung vẫn là giới hạn. Muốn scale có hiệu quả, cần biết công việc đang chờ ở đâu, trạng thái thuộc về ai và thêm tài nguyên vào vị trí nào mới có tác dụng.

Khóa học System Design: mục lục 21 bài — bạn đang đọc bài 4.

Bộ nguyên lý nền

Nguyên lý đầu tiên là xác định mục tiêu. Nếu chưa biết cần đáp ứng bao nhiêu tải và độ trễ nào, ta không thể kết luận phương án hiện tại chưa đủ. Tiếp theo là giữ thiết kế đơn giản ở mức vẫn đáp ứng nhu cầu, tránh thêm tầng chỉ vì có thể cần trong tương lai.

Các nguyên lý như SOLID giúp quản lý trách nhiệm và phụ thuộc trong code; khi lên kiến trúc, tinh thần đó vẫn có ích nhưng phải đặt trong bối cảnh vận hành. Một service nhỏ hơn chưa chắc làm hệ thống dễ hiểu hơn nếu tạo ra hàng chục lời gọi qua mạng.

Mọi công nghệ đều có giới hạn. Khi nói chọn một công cụ, hãy trả lời nó giải quyết điểm nghẽn nào, giới hạn mới nằm ở đâu và nếu đo không đạt thì phương án tiếp theo là gì.

Hai hướng scale và điều kiện tiên quyết

Scale dọc là nâng cấu hình một máy. Ưu điểm là thường ít thay đổi ứng dụng, nhưng có trần phần cứng và vẫn cần giải quyết lỗi của máy đó. Scale ngang là thêm máy cùng chia công việc; lúc này phải biết request và trạng thái được phân phối ra sao.

Nếu phiên đăng nhập chỉ nằm trong bộ nhớ máy A, request sau tới máy B sẽ không thấy phiên. Có thể dùng kho session chung hoặc cơ chế token phù hợp. Sticky session giữ người dùng ở một máy giúp trong vài tình huống, nhưng không tự giải quyết mất máy và tải lệch.

Stateless làm tầng ứng dụng dễ nhân bản hơn. Hệ stateful vẫn scale được, nhưng phải phân vùng trạng thái, sao chép và phục hồi rõ ràng. Cũng đừng quên: thêm mười app server không tăng capacity nếu tất cả cùng nghẽn ở một database.

Bản đồ Scalability — nhánh 1 & 2

Resource utilization là dùng hiệu quả CPU, bộ nhớ, ổ đĩa và mạng. Ví dụ, tạo quá nhiều thread có thể làm CPU tốn thời gian chuyển ngữ cảnh. Một cấu trúc dữ liệu có nhiều object nhỏ có thể tốn bộ nhớ và công dọn rác hơn dự kiến.

Với ổ đĩa, cách truy cập và kích thước thao tác quan trọng. Ghi theo lô hoặc đọc các vùng liên tiếp thường giúp tận dụng thiết bị, nhưng mức chênh lệch phụ thuộc phần cứng và cache. Không được suy từ đó rằng mọi database SQL chậm hay mọi NoSQL nhanh.

Nhánh stateless bổ sung một lợi ích khác: instance có thể thay thế nhau dễ hơn. Như vậy, một hướng làm mỗi máy hiệu quả hơn; hướng kia làm việc phân phối công việc qua nhiều máy đơn giản hơn. Hai hướng thường được dùng cùng nhau.

Bản đồ Scalability — nhánh SEPARATION

Ở tầng dữ liệu, ta có thể tách theo nghiệp vụ hoặc chia các nhóm bản ghi qua nhiều nơi. Ở tầng xử lý, có thể tách theo domain, theo loại người gọi hoặc theo mức quan trọng của chức năng.

Ví dụ, báo cáo cuối ngày có thể chạy riêng để không chiếm kết nối database của thanh toán. Khi quá tải, hệ thống tạm ngừng tạo gợi ý nhưng vẫn giữ đường đặt hàng. Đây là tách tài nguyên và ưu tiên có chủ đích, chứ không nhất thiết phải biến mọi phần thành microservice.

Đọc từ replica cũng là tách tải đọc khỏi nơi xử lý ghi, nhưng phải chấp nhận hoặc kiểm soát replication lag. Mỗi đường tách cần một câu trả lời: dữ liệu liên quan nhau sẽ đồng bộ thế nào và việc nào vẫn cần thực hiện cùng nhau?

Chọn công nghệ thế nào

Boring technology là công nghệ đội đã hiểu, có thể dự đoán cách nó hỏng và biết phục hồi. Từ “boring” ở đây không có nghĩa lạc hậu; nó nói về mức độ kiểm chứng và khả năng vận hành.

Một công cụ mới có thể giải quyết vấn đề tốt hơn, nhưng cần ngân sách để học, thử tải, xây giám sát và xử lý sự cố. Nếu cùng lúc đổi ngôn ngữ, database và cơ chế triển khai, rất khó biết sự cố đến từ đâu. Vì vậy nên dành sự đổi mới cho nơi có lợi ích đủ lớn.

Khi so sánh, ngoài tính năng hãy hỏi đội nào trực vận hành, khả năng backup và restore, chi phí di chuyển dữ liệu và mức phụ thuộc nhà cung cấp. Lựa chọn tốt là lựa chọn phù hợp với bài toán và con người chịu trách nhiệm cho nó.

Thêm máy ứng dụng và giới hạn ở tầng dữ liệu

                    +-> App A --+
Client -> LB -------+-> App B --+-> DB primary
                    +-> App C --+   [nút thắt cần đo]

Đo: CPU / I/O / lock wait / connection pool / p99
Sau đó cân nhắc: query -> index -> cache -> replica
Chỉ shard khi bài toán và số đo chứng minh cần thiết.

Replica phù hợp một số nhu cầu đọc, còn ghi và hot key có thể vẫn dồn về primary. Stateless chỉ giảm phụ thuộc trạng thái ở tầng app; hệ thống vẫn cần nơi sở hữu dữ liệu và quy trình phục hồi.

Thuật ngữ cần nhớ

CPU — Central Processing Unit: Bộ xử lý trung tâm; CPU-bound là tải bị giới hạn chủ yếu bởi thời gian tính toán.
I/O — Input/Output: Vào/ra: trao đổi dữ liệu với đĩa, mạng hoặc thiết bị; I/O-bound là tải dành nhiều thời gian chờ các thao tác này.
SPOF — Single Point of Failure: Điểm lỗi đơn: một thành phần hỏng có thể làm cả luồng dịch vụ ngừng hoạt động nếu không có dự phòng phù hợp.

Bài tập tự thực hành

App server đã scale gấp ba nhưng throughput không tăng.

Gợi ý kiểm tra lời giải

Kiểm tra database, pool, lock hoặc tài nguyên chung; nêu metric trước khi đổi công nghệ.

Tự kiểm tra sau bài học

Xác định được tài nguyên đang giới hạn throughput.
Mô tả được session và dữ liệu khi một instance chết.
Tính chi phí phối hợp và vận hành bên cạnh số máy.

Tiếp tục lộ trình

Bài trước — Ước lượng capacity và phân tích trade-off

Bài tiếp — Performance và availability: đo đúng, tối ưu đúng

Xem toàn bộ khóa học System Design 21 bài