Software Architecture Metrics: Những tiêu chí cần đo lường cho một hệ thống

Nhiều năm đi dạy lớp Solution Architecture, một trong những phần mình thích nhất khi dạy nhập môn SA chính là Quality Attributes, tên gọi sách vở của non-functional requirements. Đây cũng là các tiêu chí quan trọng để đánh giá các giải pháp, công việc của người SA cũng xoay quanh những tiêu chí này.

Đây là một trong những phần mình cho là khó dạy khi cần phải nói về khái niệm và ứng dụng thực tiễn. Mình đánh giá khó cân bằng giữa việc để học viên hiểu được bản chất, nguyên lý của các tiêu chí này như sách vở đã định nghĩa và ứng dụng vào trong hệ thống thực tế.

Mình hay đùa rằng: “Chém gió cũng quan trọng, miễn là chém ra được vận tốc”.

Vì sự phức tạp cũng như sự thay đổi không ngừng của công nghệ và ngành phần mềm, ngày nay một kiến trúc tốt cần phải trải qua sự tiến hóa và cải thiện dần theo thời gian. Một lý do nữa đó là sự phát triển của ứng dụng hay nền tảng (platform) đều song hành với nhu cầu của quy mô bài toán kinh doanh. Một ứng dụng tốt không sinh ra từ trong không khí bởi một sự xuất sắc của một cá nhân, mà là cả một quá trình học hỏi từ phản hồi của người dùng và sự trưởng thành của kiến trúc, đội ngũ cũng như quá trình sản xuất. Mình tin rằng đo đạc là cách khách quan và minh bạch nhất để đánh giá bất cứ phạm trù nào của sản phẩm.

Ở bài viết trước về bộ tiêu chí DORA, mình có nói về các tiêu chí mình hay dùng để hướng đến phương thức sản xuất của một đội ngũ hiệu năng cao. Hôm nay nhân một ngày mưa ở Sài Gòn, chúng ta lại bàn về các tiêu chí non-functional và thực tế của việc đo đạc.

Performance - Hệ thống thực hiện một khối lượng công việc nhanh ở mức nào

Hiệu năng là một tiêu chí quan trọng và dễ đo nhất trong các bộ tiêu chí mà SA cần quan tâm. Thông thường, tiêu chí performance có hai cách đo phổ biến:

1. Latency - Mất bao lâu để hệ thống có thể xử lý một đơn vị công việc
2. Throughput - Lượng công việc được xử lý trong một đơn vị thời gian

Ví dụ: đối với hệ thống xử lý message, latency chính là thời gian bao lâu một message được xử lý, throughput là số lượng message được xử lý trong một phút.

Tiêu chí này ngày nay thường bị xem nhẹ vì nhầm lẫn với khả năng scalability của hệ thống. Hệ thống có thể scale để đáp ứng khối lượng công việc không có nghĩa là cách thức xử lý đang hiệu quả. Ngày nay khi API phổ biến, tiêu chí response time (thời gian phản hồi) là một thang đo chính trong việc xác định hiệu năng của hệ thống.

Thách thức ở thực tế:

• Các đội dự án gặp khá nhiều khó khăn cả về kỹ thuật lẫn chi phí để tạo ra môi trường kiểm thử gần với môi trường production nhất, dẫn tới kết quả đo đạc không giúp giảm thiểu rủi ro trên thực tế.
• Không đơn giản để tạo ra giả lập workload trong các bài toán phức tạp về nghiệp vụ. Đội phát triển thường dễ bỏ qua vấn đề này vì họ cho rằng có thể giám sát trong quá trình vận hành.
• Khi vận hành, vấn đề về hiệu năng khó xác định lý do vì không đủ thông tin log cũng như việc khắc phục hiệu năng thường đòi hỏi nhiều kinh nghiệm

Lời khuyên: Đo sớm, đo giống thực tế nhất và chỉ đo ở các tính năng quan trọng cần chú ý (80/20).

Scalability - Bài toán tài nguyên và hiệu quả chi phí

Scalability được hiểu là khả năng mở rộng của hệ thống khi có sự gia tăng về workload cũng như việc lựa chọn cấu hình phù hợp của tài nguyên được cấp phát để đảm bảo hệ thống chạy hiệu quả.

Tiêu chí này thường cần thực hiện scale test để theo dõi các chỉ số về hiệu năng nhằm xác định điều kiện scale cho phù hợp cũng như lựa chọn cấu hình, đặc biệt còn liên quan đến vấn đề lựa chọn kiến trúc cũng như tồn tại bug trong ứng dụng nếu đội ngũ lập trình không có tư duy scalable. Ngày nay, với sự phát triển của các dịch vụ public cloud, việc lựa chọn kiến trúc scalable cũng như dùng các dịch vụ serverless đã trở nên phổ biến với nhiều bạn lập trình viên.

Thách thức ở thực tế:

• Scale test vẫn luôn cho ra kết quả bất ngờ về điểm nghẽn của hệ thống và cần được thực hiện, tuy nhiên nhiều đội sẽ bỏ qua khi chỉ kiểm định yếu tố này ở mức đánh giá kiến trúc.
• Vấn đề chi phí của các dịch vụ scale không giới hạn cũng là bài toán đau đầu.
• Khả năng scale che mờ đi vấn đề về việc hiệu năng xử lý của hệ thống là không thực sự tốt, dễ dẫn đến tình trạng đổ tiền vào tài nguyên.

Lời khuyên: Thực hiện scale test thường xuyên và sớm, đặt mức trần giới hạn các dịch vụ để tránh bất ngờ về chi phí.

Availability - Tính liên tục của dịch vụ

Availability thường được đo dưới dạng tỉ lệ thời gian hệ thống có thể đáp ứng dịch vụ cho người dùng. Đây là một tiêu chí lâu đời và vô cùng quan trọng với các doanh nghiệp vì trực tiếp liên quan đến khả năng kinh doanh liên tục. Chỉ số này bị ảnh hưởng bởi những lần lỗi xảy ra dẫn tới hệ thống không đáp ứng được dịch vụ. Đồng thời, nó cũng đến từ những lần chủ động bảo trì, ngừng cung cấp dịch vụ đến từ đội quản trị hệ thống.

Có hai thang đo chính thường được nhắc đến khi bàn về Availability:

• Mean time between failure (MTBF): thời gian giữa những lần xảy ra lỗi, ám chỉ tuần suất lỗi xảy ra với hệ thống dẫn đến ảnh hưởng dịch vụ
• Mean time to repair (MTTR): thời gian để khôi phục hệ thống khi lỗi xảy xa

Trên thực tế, MTBF chỉ có thể đo đạc khi lỗi xảy ra với hệ thống và MTTR trở thành một tiêu chí dễ mô hình hóa, đo đạc cũng như cải thiện. Ngoài ra có hai tiêu chí liên quan đến dữ liệu của dịch vụ khi lỗi xảy ra, bao gồm:

• Recovery point objective (RPO): lượng dữ liệu chấp nhận mất khi lỗi xảy ra
• Recovery time objective (RTO): thời gian chờ dữ liệu trở lại bình thường sau khi lỗi xảy ra

Ví dụ, một hệ thống có thể khôi phục với chỉ một phần dữ liệu dẫn đến RTO lớn hơn MTTR, hoặc nếu chấp nhận RPO lớn ở mức vô cực (chấp nhận mất hết dữ liệu), RTO có thể về 0 và ngược lại.

Thách thức ở thực tế:

DR vẫn luôn là bài toán khó. Trên thực tế, nhiều hệ thống không thực hiện bài tập DR.

• MTBF là chỉ số quan trọng nhưng khó dự đoán và mô hình hóa.
• Hiệu ứng các con số 9 tạo cảm giác hệ thống gần như hoàn hảo, nhưng trên thực tế lỗi vẫn xảy ra.

Lời khuyên: Thực hiện chaos testing, thực hiện bảo trì hệ thống theo kế hoạch, hạn chế việc lệ thuộc vào con người, tập trung vào các điểm single point of failure.

Mình tạm thời không nhắc đến tiêu chí Security trong khuôn khổ bài viết này, đề tài này sẽ cần viết riêng một bài vì sự thay đổi trong cách làm và xu hướng DevSecOps.

Lời kết

Vấn đề mấu chốt không phải là nghĩ ra kiến trúc 10 điểm, mà là có chiến lược rõ ràng và đo đạc cụ thể, phù hợp với hệ thống để dần dần cải thiện và phát triển kiến trúc cho phù hợp với bài toán kinh doanh. Lựa chọn tiêu chí nào, tại sao và đo như thế nào chính là vẻ đẹp của việc thấm nhuần nguyên lý và uyển chuyển trong thực tiễn khi bạn làm nghề SA.