Giới thiệu

Thiết kế hệ thống ổn định chủ yếu dựa vào hai yếu tố: yêu cầu rõ ràng và ước lượng thực tế. Phần này sẽ tập trung vào ước lượng và cách xác thực thiết kế của bạn với những ràng buộc thực tế.

Từ kinh nghiệm của tôi khi dẫn dắt các nhóm tại Microsoft và Meta, tôi nhận thấy một mẫu số lặp lại. Các hệ thống không thất bại do bất ngờ. Chúng thất bại vì không ai thực hiện ước lượng đủ sớm. Bỏ qua ước lượng giống như thiết kế mà không có tầm nhìn; bạn chỉ thực sự hiểu giới hạn khi hệ thống đã hoạt động, thường là trong một sự cố.

Tôi sẽ chia sẻ lý do tại sao ước lượng lại quan trọng cho khả năng mở rộng, các kỹ thuật tôi sử dụng và cách bạn có thể áp dụng chúng vào các vấn đề thực tế.

Tại sao ước lượng lại quan trọng

Trong kinh nghiệm của tôi, những đội bỏ qua ước lượng trước sẽ phải trả giá sau này, thường là trong một sự cố lớn khi hệ thống không thể xử lý tải. Ước lượng trong thiết kế hệ thống là một lĩnh vực định lượng sự không chắc chắn. Nó biến các yêu cầu trừu tượng thành các con số cụ thể cho tải người dùng, lưu trữ dữ liệu và tỷ lệ giao dịch.

Năm 2012, Instagram đã học được một bài học khó khăn. Sau khi được Facebook mua lại, số lượng người dùng của họ tăng nhanh đến mức cơ sở dữ liệu đơn lẻ không thể theo kịp. Lưu lượng truy cập quá lớn đã khiến dịch vụ bị chậm lại và tạo ra nguy cơ sập. Để xử lý sự gia tăng đáng kể này, họ đã phải khẩn cấp tái cấu trúc hệ thống của mình, phân chia dữ liệu và phân phối nó qua nhiều cơ sở dữ liệu riêng biệt.

Theo kinh nghiệm của tôi, ước lượng quan trọng vì ba lý do chính:

• Kế hoạch năng lực: Ước lượng dự đoán các chỉ số như người dùng hoạt động hàng ngày (DAUs) và các mẫu tương tác, giúp dự đoán việc sử dụng tài nguyên và hướng dẫn quyết định về dung lượng máy chủ, kích thước cơ sở dữ liệu và hạ tầng mạng. Mục tiêu là đáp ứng lưu lượng hiện tại trong khi chuẩn bị cho sự tăng trưởng trong tương lai.

• Tối ưu hóa hiệu suất: Ước lượng giúp xác định các điểm nghẽn tiềm ẩn. Khi việc sử dụng tăng lên, bạn có thể thiết kế các hệ thống phản hồi bằng cách tính toán số lượng truy vấn mỗi giây (QPS) hoặc thời gian phản hồi dưới tải đỉnh.

• Quản lý chi phí: Cung cấp quá nhiều tài nguyên sẽ lãng phí vốn, trong khi cung cấp không đủ sẽ ảnh hưởng đến trải nghiệm người dùng. Ước lượng chính xác tạo ra sự cân bằng, hỗ trợ việc mở rộng tiết kiệm chi phí. Trong các tổ chức lớn như Meta và Microsoft, ngay cả những sai sót nhỏ trong những ước lượng này cũng có thể dẫn đến hàng triệu chi phí cơ sở hạ tầng không cần thiết.

Cuối cùng, ba trụ cột này là liên kết với nhau. Sự thất bại trong kế hoạch năng lực sẽ ảnh hưởng trực tiếp đến hiệu suất, và cả hai đều có ý nghĩa chi phí đáng kể. Những ước lượng vững chắc là điểm khởi đầu để có được cả ba điều đúng. Bước tiếp theo là học các kỹ thuật thực tiễn để tạo ra những con số này một cách đáng tin cậy.

Kỹ thuật ước lượng cần thiết

Có một bộ công cụ các kỹ thuật ước lượng là rất quan trọng. Nghệ thuật là biết phương pháp nào để áp dụng dựa trên thông tin có sẵn và độ chính xác yêu cầu. Dưới đây là một số phương pháp đã được chứng minh để làm cơ sở cho các ước lượng của bạn.

Hãy thảo luận về chúng một cách chi tiết:

• Tính toán nhanh: Công cụ đầu tiên cần sử dụng là toán học trên giấy. Nó liên quan đến việc thực hiện các tính toán nhanh, ước lượng để thiết lập một cơ sở và kiểm tra tính khả thi. Mục tiêu không phải là con số hoàn hảo mà là thử nghiệm xem liệu một ý tưởng có khả thi hay không. Điều này bao gồm việc sử dụng các quy tắc và chia một ước lượng lớn thành các phần nhỏ hơn, dễ quản lý.

Ngay cả tại Google, Jeff Dean đã được biết đến với việc sử dụng toán học trên giấy trong các đánh giá thiết kế để nhanh chóng xác định xem các đề xuất có khả thi hay không.

• Tư duy theo thang đo: Trước khi đi vào chi tiết, hãy hỏi, "Quy mô của vấn đề này là gì?" Bạn đang thiết kế cho hàng ngàn người dùng, hàng triệu hay hàng tỷ? Ước lượng các giá trị gần nhất với luỹ thừa của mười là cách nhanh chóng để đánh giá quy mô mà không bị lạc vào chi tiết. Khung này định hình toàn bộ cách tiếp cận kiến trúc.

• Phân tích và tổng hợp: Khi đối mặt với một hệ thống phức tạp, hãy chia nó thành các thành phần cốt lõi của nó. Ước lượng yêu cầu cho từng phần riêng lẻ (ví dụ: dịch vụ xác thực, đường ống nhập dữ liệu) và sau đó tổng hợp chúng lại. Cách tiếp cận mô-đun này chính xác hơn nhiều so với việc ước lượng toàn bộ hệ thống đồng thời.

• Phân tích dữ liệu lịch sử và chuẩn mực: Dữ liệu từ các dự án trước thường là điểm khởi đầu đáng tin cậy nhất. Giả sử một dịch vụ tương tự đã xử lý lưu lượng A với tài nguyên B, điều này cung cấp một cơ sở mạnh mẽ. Các tổ chức như Netflix và Uber thường xuất bản các blog kỹ thuật với các chuẩn mực hiệu suất quý giá.

Bảng dưới đây chỉ ra các phương pháp khác nhau dựa trên tốc độ, độ chính xác và các trường hợp sử dụng của chúng.

Thực hành tốt nhất là bắt đầu rộng với các ước lượng theo thang đo và tinh chỉnh chúng theo từng bước khi có thêm dữ liệu.

Các kỹ thuật cung cấp cấu trúc, nhưng ước lượng thực tế đối mặt với những thách thức như yêu cầu thay đổi, thiên kiến lạc quan và công nghệ mới. Tiếp theo, chúng ta sẽ xem xét những thách thức này một cách chi tiết.

Những thách thức trong ước lượng

Ước lượng vừa là tính toán, vừa là phán đoán; ngay cả những đội kinh nghiệm cũng gặp khó khăn với nó. Các trở ngại lớn nhất thường là do con người và tổ chức hơn là thuần túy kỹ thuật.

Những cạm bẫy phổ biến nhất bao gồm:

• Sự không chắc chắn về yêu cầu: Các dự án giai đoạn đầu thường có yêu cầu mơ hồ hoặc thay đổi. Tầm nhìn của một quản lý sản phẩm có thể thay đổi, điều kiện thị trường thay đổi và hành vi của người dùng có thể không thể dự đoán được. Điều này khiến các ước lượng lâu dài cố định trở nên khó khăn.

• Yếu tố con người: Thiên kiến lạc quan là một lực mạnh mẽ trong kỹ thuật. Chúng ta thường đánh giá thấp độ phức tạp và thời gian cần thiết để hoàn thành các nhiệm vụ. Điều này có thể bị tăng cường bởi áp lực tổ chức để đáp ứng các thời hạn tham vọng, dẫn đến các cam kết không thực tế.

Nghiên cứu về các sáng kiến CNTT lớn cho thấy một mẫu nhất quán: các dự án thường vượt quá ngân sách và thời gian, trong khi chỉ cung cấp một phần nhỏ lợi ích kỳ vọng. Khoảng cách này ít đến từ các vấn đề kỹ thuật mà nhiều hơn từ những sai lầm ban đầu và sự tự tin thái quá.

• Hạn chế công nghệ: Khi làm việc với các công nghệ mới, thường thiếu dữ liệu lịch sử hoặc chuẩn mực đã được thiết lập. Sự thiếu tiền lệ này khiến việc dự đoán chính xác hiệu suất và nhu cầu tài nguyên trở nên khó khăn.

Xử lý những sự không chắc chắn này đòi hỏi phải lặp lại. Bắt đầu từ những ước lượng rộng, tinh chỉnh khi yêu cầu thay đổi, và điều chỉnh khi có dữ liệu thực tế. Tham gia các nhóm đa chức năng để mang lại những quan điểm đa dạng và giảm thiểu thiên kiến. Sử dụng dữ liệu lịch sử và chuẩn mực ngành để giữ cho các ước lượng có cơ sở thực tế. Trên hết, hãy xây dựng một văn hóa minh bạch nơi mà các dự đoán có thể phát triển thay vì được coi là những dự đoán cố định.

Với những thách thức đó trong tâm trí, đây là cách ước lượng diễn ra trong thực tế.

Ước lượng trong thực hành

Hãy cùng xem một ước lượng tóm tắt trên giấy cho một dịch vụ rút gọn URL để xem cách mà những con số này hướng dẫn thiết kế của chúng ta. Mặc dù ví dụ này rất đơn giản, quy trình là như nhau cho bất kỳ hệ thống quy mô lớn nào. Tất cả bắt đầu bằng cách thiết lập một vài giả định cơ bản để xác định quy mô của vấn đề.

Giả định cơ bản

Bước đầu tiên là định hình vấn đề với một vài giả định đơn giản về cách mà hệ thống sẽ được sử dụng và lượng dữ liệu nó sẽ xử lý.

• 200 triệu yêu cầu rút gọn URL mới mỗi tháng
• Tỷ lệ rút gọn-điều hướng là 1:100
• Mỗi bản ghi URL rút gọn yêu cầu khoảng 500 byte
• Các mục được lưu trữ trong tối đa 5 năm

Chúng ta có thể thực hiện các phép toán nhanh với những giả định này để tính toán các chỉ số cốt lõi của mình.

Tính toán nhanh

Hãy chuyển đổi những giả định này thành các ước lượng cụ thể về lưu trữ, lưu lượng, băng thông và nhu cầu máy chủ.

• Lưu trữ: 200M/tháng × 500 byte ≈ 6 TB trong 5 năm
• Lưu lượng ghi (trung bình): ~200M URL mới ÷ 30 ngày ÷ 24 giờ ÷ 3600 giây ≈ 77 URL/giây
• Lưu lượng đọc (trung bình): 77 ghi/giây × 100 đọc/ghi ≈ 7.7K điều hướng/giây
• Băng thông: Tại đỉnh điểm, điều hướng có thể tiêu thụ ~60 Mbps (dựa trên kích thước điều hướng trung bình khoảng ~1KB và lưu lượng đỉnh điểm ~7.7K yêu cầu mỗi giây)
• Máy chủ: Chúng ta cần 5–6 máy chủ cho logic ứng dụng (giả sử lưu lượng đỉnh là 3 lần trung bình, hoặc ~23K yêu cầu mỗi giây, và mỗi máy chủ xử lý 5K yêu cầu mỗi giây), cộng thêm máy chủ dự phòng.

Những ước lượng này không chính xác nhưng cung cấp một nền tảng cho kiến trúc của chúng ta.

Tỷ lệ điều hướng dự kiến cho thấy cần thiết phải có một lớp cache. Nhu cầu lưu trữ hàng tỷ liên kết chỉ ra rằng cần có một kho dữ liệu kiểu key-value mở rộng, không phải một cơ sở dữ liệu quan hệ đơn lẻ. Các mục tiêu về tính sẵn có nghiêm ngặt yêu cầu sự dư thừa và khả năng chuyển đổi tự động.

Sơ đồ dưới đây kết nối những ước lượng này với kiến trúc cuối cùng:

Đây là giá trị thực sự của ước lượng: nó biến những con số thành các lựa chọn thiết kế từ rất sớm trước khi bắt đầu triển khai.

Để có một hướng dẫn chi tiết, từng bước, hãy xem Thiết kế hệ thống TinyURL, điều này bao gồm quy trình tính toán.

Toán học nhanh mà chúng ta đã sử dụng cho TinyURL là hoàn hảo cho thiết kế cấp cao. Nhưng chúng ta cần khám phá thêm nhiều công cụ và mô hình chuyên biệt hơn cho các hệ thống phức tạp hơn hoặc khi cần độ chính xác cao hơn.

Mô hình ước lượng nâng cao

Các phép toán nhanh rất tốt cho việc xác định phạm vi, nhưng các hệ thống phức tạp thường cần các mô hình tinh vi hơn. Khi các thiết kế trưởng thành, việc di chuyển từ những ước lượng thô sang các phương pháp có cấu trúc sẽ giảm thiểu rủi ro.

Đối với các tình huống liên quan đến mức độ song song cao hoặc không chắc chắn, tôi đã thấy các đội sử dụng thành công các mô hình chuyên biệt:

• Mô hình BSP: Đối với các tính toán song song quy mô lớn như đường ống dữ liệu hoặc đào tạo ML, mô hình Bulk Synchronous Parallel (BSP) giúp dự đoán hiệu suất. Nó mô hình hóa các giai đoạn tính toán, giao tiếp và đồng bộ hóa để ước lượng thời gian hoàn thành và xác định các điểm nghẽn trong khả năng mở rộng. Ví dụ, lý luận theo kiểu BSP đã được áp dụng rộng rãi trong việc tối ưu hóa các công việc MapReduce và Spark để phát hiện nơi mà các giao tiếp mạng hoặc rào cản đồng bộ hóa giới hạn thông lượng.

• Mô hình logic mờ: Thiết kế hệ thống thường liên quan đến thông tin không đầy đủ hoặc không chắc chắn. Logic mờ giải quyết điều này bằng cách sử dụng các mức độ đúng thay vì các giá trị nhị phân, làm cho nó hữu ích trong việc mô hình hóa các yêu cầu mơ hồ hoặc dữ liệu thưa thớt. Nó có thể hướng dẫn các quyết định trong phân bổ tài nguyên và dự đoán hiệu suất dưới tải biến đổi. Khi ước lượng khả năng máy chủ cho một sản phẩm mới không có lịch sử sử dụng, một đội ngũ tôi đã làm việc đã sử dụng logic mờ. Thay vì cần những con số cứng nhắc, mô hình đã nhận các đầu vào định tính như "sự quan tâm của người dùng" (thấp, trung bình, cao) và cung cấp một phạm vi nhu cầu tài nguyên tiềm năng, hướng dẫn một kiến trúc linh hoạt và bền vững hơn.

Những mô hình nâng cao này bổ sung cho các kỹ thuật ước lượng cơ bản thay vì thay thế chúng. Hãy xem các phương pháp cổ điển như là bộ lọc đầu tiên, cung cấp cho bạn một cơ sở, và các phương pháp hiện đại như là bước tinh chỉnh khi vấn đề mang nhiều sự không chắc chắn hơn. Chìa khóa là phù hợp độ phức tạp của công cụ với mức độ không chắc chắn trong vấn đề.

Bảng dưới đây cho thấy sự khác biệt chính giữa các mô hình khác nhau về các kịch bản sử dụng chính, độ tin cậy, lợi ích và nhược điểm chính:

Hướng tới độ chính xác

Ước lượng chính xác trong thiết kế hệ thống phân biệt các hệ thống bền vững với những hệ thống thất bại dưới áp lực. Trong thời gian làm việc tại Microsoft và Meta, tôi đã thấy cách lý luận định lượng tạo ra sự khác biệt cho các kỹ sư xuất sắc.

Đây là một kiểm tra tính hợp lệ ước lượng nhanh mà bạn có thể áp dụng trong các thiết kế của riêng mình:
Định nghĩa 3–5 giả định cơ bản (người dùng, lưu lượng, tăng trưởng dữ liệu).
Thực hiện toán học nhanh cho lưu trữ, thông lượng và chi phí.
Tinh chỉnh các ước lượng khi yêu cầu phát triển.
Xác thực các con số với các chuẩn mực hoặc dữ liệu hệ thống trước đó.

Bằng cách áp dụng những kỹ thuật này, bạn chuyển từ các sửa chữa phản ứng sang kiến trúc chủ động. Bạn dự đoán sự tăng trưởng, quản lý chi phí và đảm bảo hiệu suất. Những kỹ sư xuất sắc nhất mà tôi đã làm việc là những người đã thực hiện tính toán sớm và tinh chỉnh chúng khi thiết kế phát triển.

Sẵn sàng áp dụng những nguyên tắc này? Hãy làm chủ những khái niệm này với các khóa học toàn diện: "Grokking the Modern System Design Interview", "Grokking the Frontend System Design", "Advanced System Design", và "Product and Architecture System Design". Những khóa học này và nhiều khóa học khác trên nền tảng sẽ giúp bạn chuyển đổi từ kiến thức lý thuyết sang kỹ năng thực tiễn trong thế giới thực.