Capacity Planning – Dự toán công suất cho ứng dụng (Tập 1 )

Bài viết được sự cho phép của tác giả Edward Thiên Hoàng

Một trong những công việc cuối cùng trong khâu thiết kế hệ thống sau khi đã hoàn thành khâu logical design là dự toán công suất vật lý của hệ thống để xem cần bao nhiêu máy chủ, (v)CPU, RAM, Disk, network bandwidth là bao nhiêu để hệ thống có thể hoạt động đủ mượt nhưng không quá nhàn rỗi dẫn đến lãng phí tài nguyên. Hiện nay với xu hướng người người, nhà nhà đi lên Cloud để tận dụng khả năng elastic, auto-scaling thì có vẻ là công việc này sẽ nhẹ nhàng hơn, nhưng lại có những challenge khác liên quan đến việc thiết kế ứng dụng để làm sao scale được. Trong phạm vi bài viết này, hãy cùng xem xét về góc cạnh dự toán công suất cho ứng dụng.

1. GIỚI THIỆU

Khả năng xác định hoặc dự báo khả năng của một hệ thống hoặc tập hợp các thành phần, thường được gọi là ‘sizing’ của một hệ thống, là một hoạt động quan trọng trong thiết kế hệ thống. Một hệ thống với công suất quá khổ sẽ dẫn đến chi phí vượt trội về tài nguyên phần cứng, trong khi công suất quá thấp có thể dẫn đến giảm hiệu suất và không có khả năng để phục vụ mục đích của nó. Hãy tưởng tượng một nhà cung cấp thương mại điện tử sẽ hết bộ nhớ vào Black Friday hoặc một nhà cung cấp công cụ tìm kiếm phải trả gấp 20 lần chi phí cho công suất tối ưu của họ – cả hai kịch bản rõ ràng những nhà dự toán, kiến trúc sư phải xem xét kỹ hơn.

Lập kế hoạch công suất trong thiết kế hệ thống là nghệ thuật cũng như khoa học. Cùng với các tham số nhất định, nó cũng cần đến kinh nghiệm, kiến ​​thức về lĩnh vực kinh doanh và kiến ​​thức bên trong hệ thống. Trong một số trường hợp, chúng ta còn phải phân tích tâm lý của người của hệ thống, mô hình sử dụng của họ, v.v.

2. CÁC CHỈ SỐ HOẠCH ĐỊNH CÔNG SUẤT

Có nhiều phương pháp để thực hiện dự toán công suất. Bài viết này đề cập đến một số chỉ số tập trung vào cách các yếu tố như tính đồng thời, giao dịch mỗi giây (TPS), công việc được thực hiện trên mỗi giao dịch, v.v. Tất nhiên, nhiều yếu tố khác có thể xác định khả năng của một hệ thống, bao gồm sự phức tạp của các giao dịch, độ trễ và các cuộc gọi service bên ngoài, phân bổ và sử dụng bộ nhớ, v.v.

Cách tốt nhất là kiểm tra hiệu năng của hệ thống của bạn để xem liệu nó có hoạt động với công suất dự kiến hay không khi bạn đã thiết lập hệ thống theo phán đoán kế hoạch công suất, sau đó sẽ có những điều chỉnh kịp thời, lấy đó làm kinh nghiệm cho những lần lập kế hoạch tiếp theo.

Chúng ta hãy xem xét chi tiết một số các chỉ số này dưới đây.

2.1 THÔNG LƯỢNG (THROUGHPUT) VÀ TPS

Thông thường thông lượng được xác định là số lượng transaction được xử lý trong một khoảng thời gian nhất định. Thông lượng là thước đo số lượng hành động trên một đơn vị thời gian, trong đó thời gian có thể tính bằng giây, phút, giờ, v.v. TPS (Transaction Per Second) là số lượng giao dịch trên mỗi giây. Đối với một máy chủ stateless, đây sẽ là đặc điểm chính ảnh hưởng đến dung lượng máy chủ.

Về mặt lý thuyết, nếu người dùng thực hiện 60 giao dịch trong một phút, thì TPS sẽ là 60/60 TPS = 1 TPS. Tất nhiên, vì tất cả người dùng đồng thời đăng nhập vào hệ thống có thể không nhất thiết phải sử dụng hệ thống đó tại thời điểm nhất định, điều này có thể không chính xác. Ngoài ra, thời gian suy nghĩ, trì hoãn (think time) cũng nên được xem xét. Nhưng loại bỏ những điều trên, đây có thể được coi là trung bình 1 TPS khi người dùng truy cập thống nhất hệ thống trong hơn 60 giây.

2.2 CÔNG VIỆC ĐƯỢC THỰC HIỆN TRÊN MỖI GIAO DỊCH

Mỗi ‘giao dịch’ đến máy chủ sẽ có một số mức độ hoạt động để hoàn thành giao dịch đó. Điều này có nghĩa là CPU sẽ được kích hoạt để xử lý transaction bao gồm xử lý ứng dụng cũng như các hoạt động hệ thống như truy cập cơ sở dữ liệu, truy cập hệ thống bên ngoài, v.v. Nếu giao dịch đơn giản, điều đó có nghĩa là yêu cầu xử lý tương đối ít hơn so với giao dịch kích hoạt một tập hợp các hoạt động tiếp theo. Một sơ đồ trình tự của giao dịch sẽ giúp xác định các hoạt động thực tế có liên quan đến giao dịch.

2.3 THỜI GIAN SUY NGHĨ (THINK TIME)

Từ góc độ ứng dụng web, người dùng gửi yêu cầu, sau đó được xử lý ở phía máy chủ trước khi trả lại cho người dùng. Sau đó, người dùng thường chờ phản hồi và ‘xử lý, suy nghĩ’ trước khi gửi yêu cầu tiếp theo. Sự chậm trễ này là thời gian suy nghĩ của người dùng, rơi vào giữa các yêu cầu và có thể được tính đến khi tính toán tải hệ thống tối ưu. Đối với giao tiếp giữa máy với máy, thông số thời gian nghĩ này sẽ tương đối thấp hơn. Đối với lập dự toán công suất, thời gian suy nghĩ trung bình là hữu ích trong việc tính toán thông lượng chính xác.

2.4 NGƯỜI DÙNG TÍCH CỰC (ACTIVE USERS) VÀ ĐỒNG THỜI (CONCURRENT USERS HAY CCU)

Một hệ thống sẽ có tổng số người dùng – điều này có thể không ảnh hưởng trực tiếp đến công suất máy chủ, nhưng là một số liệu quan trọng trong việc định kích thước cho cơ sở dữ liệu. Trong tổng số nhóm người dùng này, một tập hợp con trong số họ sẽ là người dùng hoạt động – người dùng sử dụng hệ thống tại một thời điểm nhất định. Thông thường người dùng hoạt động đăng nhập vào một hệ thống, thực hiện một số thao tác và đăng xuất; hoặc họ chỉ để hệ thống hoạt động, đến lượt nó sẽ logout người dùng ra sau khi phiên hết hạn (thường trong 30 phút hoặc lâu hơn).

Hình 1: Users in Capacity Planning

Người dùng hoạt động đồng thời là số lượng người dùng riêng biệt truy cập đồng thời vào hệ thống tại bất kỳ thời điểm nào. Như trong ví dụ trong hình ở trên, người dùng đồng thời là một tập hợp con của những người dùng đang hoạt động đang sử dụng hệ thống tại một thời điểm nhất định. Nếu 200 người dùng hoạt động được đăng nhập vào hệ thống và có thời gian suy nghĩ 10 giây, thì đó sẽ là khoảng 20 người dùng đồng thời thực sự tấn công hệ thống. Trong dự toán công suất, điều này có một số ý nghĩa. Trong một máy chủ ứng dụng stateful với các session tương ứng cho từng user, số lượng người dùng đồng thời sẽ đóng vai trò lớn hơn việc xử lý stateless. Đối với các hệ thống được thiết kế theo cách như vậy, mỗi người dùng đồng thời tiêu thụ một số mức bộ nhớ cần phải được tính đến.

Thông thường, thông lượng của hệ thống tăng theo số lượng người dùng đồng thời cho đến khi đạt được công suất tối đa như trong Hình 2; từ đó trở đi hệ thống sẽ bị suy giảm hiệu năng. Do đó, điều quan trọng là phải tính toán số lượng user đồng thời tối đa mà một hệ thống có thể xử lý.

Hình 2: Server Performance – Throughput

2.5 KÍCH THƯỚC MESSAGE

Kích thước của message của các request cũng là một yếu tố quan trọng trong việc xác định dung lượng cần thiết của một hệ thống. Mesage với kích thước lớn hơn có nghĩa là yêu cầu năng lượng xử lý nhiều hơn, yêu cầu bộ nhớ nhiều hơn. Là một cơ sở để lập dự toán công suất, các kích thước message như bảng dưới đây nên được xem xét.

Hình 3: Message Sizes

2.6 ĐỘ TRỄ (LATENCY)

Độ trễ là thời gian bổ sung của hệ thống để thực hiện các thao tác. Các yêu cầu phi chức năng (Non-functional requirements – NFRs) của một hệ thống thường sẽ chỉ ra thời gian đáp ứng mong muốn của một giao dịch mà sau đó một hệ thống phải cố gắng đáp ứng. Xem xét ví dụ trong Hình 4, nếu một transaction đơn lẻ thực hiện một số lệnh gọi xuống cơ sở dữ liệu hoặc một tập hợp các lệnh gọi web service đồng bộ, transaction phải ‘chờ’ để nhận phản hồi. Điều này sau đó sẽ thêm vào thời gian phản hồi tổng thể của transaction.

Hình 4: Server Performance – Latency

Các kỹ thuật như bộ nhớ đệm có thể được sử dụng để cải thiện thời gian trễ.

Độ trễ thường là từ máy khách và cũng cần tính đến chi phí mạng / băng thông.

2.7 CÁC YÊU CẦU PHI CHỨC NĂNG KHÁC

Các yêu cầu về chất lượng dịch vụ (Quality of service – QoS), cùng với các yêu cầu phi chức năng khác, sẽ có ảnh hưởng đến cách bạn lập dự toán công suất. Ví dụ, nếu việc gửi message được đảm bảo (guaranteed delivery) hoặc việc truyền message an toàn (secure) là một yêu cầu bắt buộc, điều này sẽ ảnh hưởng đến hiệu suất chung của hệ thống và cũng cần phải được tính đến. Tương tự, nếu giải pháp với nhiều hệ thống với nhiều công suất khác nhau, thì cũng cần thực hiện một số điều chỉnh (throttling) giữa các hệ thống đó để tránh tình trạng thắt cổ chai (bottleneck).

Một khía cạnh khác cần được xem xét là tính sẵn sàng hoặc thời gian hoạt động của hệ thống. Về lý thuyết, tính khả dụng được xác định là tỷ lệ phần trăm khả dụng của hệ thống trong một năm. Lưu ý mặc dù tính khả dụng và thời gian hoạt động không đồng nghĩa – hệ thống có thể hoạt động, nhưng có thể không sẵn sàng để chấp nhận các yêu cầu, trong trường hợp đó hệ thống không khả dụng.

Thời gian chết (downtime) hệ thống được chấp nhận là một yêu cầu thực tế, thường được tìm thấy như một phần của các yêu cầu không chức năng. Điều này trực tiếp xác định làm thế nào một hệ thống có tính sẵn sàng cao cần thiết kế. Khi tính toán dung lượng, điều quan trọng là phải tính đến thời gian ngừng hoạt động theo kế hoạch, chẳng hạn như nâng cấp hệ thống và triển khai ứng dụng và thời gian ngừng hoạt động ngoài dự kiến, chẳng hạn như sự cố máy chủ.

Tính khả dụng của một hệ thống được xác định theo phương trình sau, mang lại kết quả tỷ lệ %.

x = (n – y) * 100 / n

trong đó ‘n’ là tổng số phút trong một tháng theo lịch nhất định và ‘y’ là tổng số phút dịch vụ không khả dụng trong một tháng theo lịch nhất định.

Hình 5: Availability Numbers

Source: Wikipedia – http://en.wikipedia.org/wiki/High_availability

3. DỰ BÁO YÊU CẦU NĂNG LỰC

Với các khái niệm trên (Hình 5), doanh nghiệp cần quyết định thời gian dự báo là gì. Bạn chỉ tập trung vào năm thứ nhất? Liệu các yêu cầu về năng lực sẽ tăng gấp đôi trong năm thứ hai, và nếu vậy sẽ có một thời gian chết đáng kể vào cuối năm thứ nhất để đáp ứng điều này? Một bảng, chẳng hạn như bảng được đưa ra trong Hình 6, sẽ hữu ích cho việc dự báo và có thể dựa trên các xu hướng trong quá khứ và dự báo kinh doanh trong tương lai.

Figure 6: Capacity Forecasting for 4 Years

Bài viết tham khảo từ: https://wso2.com/whitepapers/capacity-planning-for-application-design-part-1/

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

• Cấu hình định dạng ngày tháng, thời gian trên Windows cho ứng dụng Winform
• Firebase là gì ? Có nên dùng cho các ứng dụng lớn?

Xem thêm Việc làm Developer hấp dẫn trên TopDev