Yêu cầu về khả năng mở rộng hệ thống học tập

Khả năng mở rộng cũng không đồng nghĩa với việc chỉ nâng CPU hoặc RAM cho một máy chủ. Kiến trúc cần cho phép bổ sung tài nguyên theo chiều ngang, phân phối tải, mở rộng lớp dữ liệu và điều chỉnh năng lực theo nhu cầu. AWS Well-Architected xem horizontal scaling và tự động cấp thêm tài nguyên theo tải là những nguyên tắc quan trọng để thích ứng với thay đổi nhu cầu; Azure cũng xác định scaling và partitioning là hai cơ chế cốt lõi để phân phối xử lý và dữ liệu khi workload tăng.

Khả năng mở rộng phải được xác định bằng tải thực tế, không chỉ bằng tổng số tài khoản

Một trường đại học có 100.000 tài khoản nhưng chỉ vài nghìn người truy cập đồng thời có bài toán tải khác hoàn toàn một nền tảng tổ chức kỳ thi trực tuyến cho hàng chục nghìn học viên cùng bắt đầu trong vài phút. Vì thế, tổng số người dùng đã đăng ký chỉ phản ánh một phần rất nhỏ của yêu cầu năng lực.

Đầu vào quan trọng hơn là mô hình tải: số phiên hoạt động đồng thời, số yêu cầu mỗi giây, loại chức năng được sử dụng, thời gian duy trì cao điểm và tốc độ tăng tải. Đăng nhập, xem trang khóa học, phát video, tải tài liệu, nộp bài và làm bài kiểm tra không tạo ra cùng mức tiêu thụ CPU, bộ nhớ, cơ sở dữ liệu, lưu trữ hay băng thông.

Do đó không tồn tại một tỷ lệ phổ quát kiểu “một máy chủ phục vụ được X học viên” có thể áp dụng cho mọi hệ thống. Hướng dẫn kiểm thử hiệu năng của Microsoft khuyến nghị xác định mục tiêu đo được, bao gồm chính số người dùng đồng thời cần hỗ trợ, rồi liên kết các mục tiêu này với SLO của workload. AWS cũng yêu cầu kiểm tra khả năng mở rộng qua nhiều tình huống, từ tải thông thường đến tải tăng đột biến và tải cao duy trì.

Vì vậy, một yêu cầu khả năng mở rộng tốt nên được mô tả theo dạng: hệ thống phải chịu được một workload xác định và vẫn giữ latency, throughput cùng error rate trong giới hạn đã đặt. Cách này có thể kiểm thử được; yêu cầu chung chung như “hỗ trợ số lượng lớn người học” thì không.

Hệ thống phải tăng năng lực xử lý khi số người dùng đồng thời tăng

Khi lượng người truy cập tăng, lớp ứng dụng không nên phụ thuộc vào khả năng nâng cấp vô hạn của một máy chủ duy nhất. Vertical scaling — thêm CPU hoặc RAM cho một máy — vẫn hữu ích ở một số giai đoạn, nhưng cuối cùng sẽ gặp giới hạn phần cứng, chi phí hoặc thời gian gián đoạn.

Kiến trúc có khả năng mở rộng tốt cần hỗ trợ horizontal scaling, tức bổ sung nhiều instance hoặc node xử lý và phân phối request giữa chúng. Microsoft mô tả horizontal scaling là việc thêm hoặc loại bỏ instance mà ứng dụng vẫn tiếp tục chạy; AWS cũng khuyến nghị phân phối request trên nhiều tài nguyên nhỏ hơn thay vì tập trung toàn bộ tải vào một điểm duy nhất.

Điều này đặc biệt quan trọng với hệ thống học tập vì tải thường biến động mạnh. Đầu học kỳ, hạn nộp bài, thời điểm công bố điểm hoặc một kỳ thi trực tuyến có thể tạo peak load lớn hơn nhiều so với mức trung bình.

Auto-scaling giúp hệ thống tăng hoặc giảm năng lực dựa trên nhu cầu thay vì luôn duy trì hạ tầng ở mức cao nhất. AWS nêu rõ automatic scaling có thể cấp lượng compute, database và các tài nguyên khác phù hợp với tải hiện tại hoặc tải dự báo.

Tuy nhiên, thêm máy chủ ứng dụng chỉ có tác dụng nếu kiến trúc không giữ quá nhiều trạng thái cục bộ trên từng instance. Nếu session của người học chỉ tồn tại trong bộ nhớ của một máy, việc bổ sung hoặc loại bỏ instance sẽ phức tạp hơn. Các hướng dẫn kiến trúc Azure vì thế khuyến nghị ứng dụng stateless khi có thể và đưa trạng thái cần chia sẻ sang kho dữ liệu có khả năng mở rộng độc lập.

Dữ liệu học tập phải mở rộng độc lập với lớp ứng dụng

Số người dùng tăng thường kéo theo tốc độ tăng dữ liệu nhanh hơn số tài khoản. Một người học có thể tạo hàng loạt bản ghi đăng nhập, tiến độ, lượt xem, câu trả lời, điểm số, bài nộp, sự kiện tương tác và tệp nội dung. Nếu hệ thống có learning analytics, dữ liệu sự kiện còn có thể tăng liên tục trong suốt quá trình sử dụng.

Do đó, khả năng mở rộng hệ thống học tập phải xem data layer là một bài toán riêng, thay vì giả định chỉ cần tăng số application server.

Khi một cơ sở dữ liệu duy nhất trở thành giới hạn, kiến trúc có thể phải phân chia workload và dữ liệu thành những đơn vị nhỏ hơn. Azure định nghĩa partitioning là quá trình chia workload thành các phần quản lý được để phân phối dữ liệu và xử lý trên nhiều tài nguyên. Với workload đọc nhiều, mô hình read replica cũng có thể tách lưu lượng đọc khỏi máy chủ dữ liệu chính; tài liệu Amazon RDS mô tả read replica là một cơ chế horizontal scaling dành cho các workload đọc lớn.

Điểm quan trọng là không phải mọi vấn đề dữ liệu đều giải quyết được bằng cách mua database lớn hơn. Truy vấn kém tối ưu, quá nhiều round trip, thiếu index hoặc thiết kế truy cập dữ liệu không phù hợp vẫn có thể tạo bottleneck sau khi tăng tài nguyên. Hướng dẫn Azure SQL lưu ý rằng các ứng dụng có truy vấn hoặc mô hình truy cập kém tối ưu có thể không cải thiện đáng kể chỉ bằng việc chuyển sang compute size cao hơn.

Vì vậy, yêu cầu mở rộng dữ liệu phải bao gồm cả tăng dung lượng lưu trữ, throughput đọc/ghi, khả năng phân vùng, chiến lược lưu trữ dữ liệu lịch sử và hiệu năng truy vấn khi kích thước dataset tăng.

Tệp học liệu và dữ liệu sự kiện không nên tạo thành nút thắt mới

Trong hệ thống học tập, dữ liệu không chỉ nằm ở bảng người dùng và điểm số. Video, tài liệu, bài nộp, bản ghi lớp học, hình ảnh hoặc package học liệu có thể chiếm phần lớn dung lượng. Nếu toàn bộ tệp lớn đi qua cùng lớp ứng dụng và cùng storage với giao dịch nghiệp vụ, tăng trưởng nội dung có thể làm suy giảm hiệu năng của những chức năng vốn nhẹ hơn.

Kiến trúc vì vậy cần cho phép các nhóm workload phát triển tương đối độc lập: xử lý request của người học, lưu trữ tệp lớn, database giao dịch và pipeline dữ liệu phân tích không nên bị buộc phải mở rộng theo cùng một đơn vị.

Nguyên tắc này cũng áp dụng cho dữ liệu sự kiện. Các nền tảng có analytics có thể tạo một event stream lớn từ hoạt động đọc, xem media, làm bài, đánh giá và sử dụng công cụ. 1EdTech Caliper Analytics chẳng hạn chuẩn hóa dữ liệu hoạt động học tập thành nhiều nhóm sự kiện như assessment, media, reading, session và tool use. Điều đó cho thấy dữ liệu học tập ở quy mô lớn không còn chỉ là hồ sơ tài khoản mà còn bao gồm luồng hành vi phát sinh liên tục.

Khi thiết kế khả năng mở rộng, cần tính tới tốc độ phát sinh loại dữ liệu này, khả năng ghi nhận bất đồng bộ và việc tách xử lý analytics khỏi các giao dịch thời gian thực. Nếu một tác vụ phân tích nặng làm chậm quá trình nộp bài hoặc mở bài kiểm tra, hệ thống tuy có nhiều tài nguyên nhưng vẫn chưa có kiến trúc mở rộng tốt.

Tích hợp dữ liệu phải mở rộng mà không làm số kết nối tăng mất kiểm soát

Một hệ thống học tập hiếm khi hoạt động độc lập. Nó thường phải trao đổi dữ liệu với hệ thống quản lý người học, công cụ giảng dạy, hệ thống đánh giá hoặc các dịch vụ khác. Khi quy mô tổ chức tăng, số ứng dụng tích hợp cũng có thể tăng theo.

Nếu mỗi hệ thống sử dụng một cấu trúc dữ liệu và một kết nối tùy biến riêng, chi phí vận hành có thể tăng nhanh hơn chính số người dùng. Do đó, khả năng mở rộng dữ liệu còn bao gồm khả năng chuẩn hóa trao đổi thông tin giữa các hệ thống.

Trong hệ sinh thái giáo dục, OneRoster của 1EdTech hỗ trợ trao đổi roster, thông tin khóa học và điểm bằng CSV hoặc REST; LTI là tiêu chuẩn kết nối công cụ học tập với môi trường học tập và hỗ trợ truyền dữ liệu như người dùng, enrollment và role.

Các tiêu chuẩn này không tự làm database nhanh hơn và cũng không thay thế kiến trúc scale-out. Giá trị của chúng nằm ở việc hạn chế sự phụ thuộc vào hàng loạt tích hợp point-to-point riêng biệt khi số hệ thống và khối lượng dữ liệu trao đổi tăng. Đây là một ranh giới quan trọng: interoperability hỗ trợ khả năng mở rộng về tích hợp, nhưng không đồng nghĩa với scalability về năng lực xử lý.

Khả năng mở rộng phải được chứng minh bằng benchmark và kiểm thử tải

Một kiến trúc được gọi là “scalable” trên sơ đồ chưa đủ để chứng minh nó thực sự mở rộng được. Cần xác định tải mục tiêu, tạo workload đại diện và đo hệ thống ở nhiều mức tải khác nhau.

Các chỉ số nên tập trung vào hành vi mà người dùng và hệ thống thực sự cảm nhận được: latency, throughput, error rate, thời gian hoàn thành giao dịch và mức sử dụng tài nguyên. Microsoft khuyến nghị thu thập throughput, latency và completion time ở cấp ứng dụng, kết hợp metrics, traces và logs để tìm thành phần gây chậm. AWS cũng khuyến nghị xác định baseline, kịch bản kiểm thử và KPI như CPU utilization, latency hoặc throughput trước khi benchmark.

Một yêu cầu kiểm thử khả năng mở rộng có thể được tổ chức quanh các tình huống sau:

·         Tải thông thường để thiết lập baseline

·         Tăng dần số người dùng đồng thời để xác định đường cong hiệu năng

·         Peak load tương ứng với kỳ thi, hạn nộp bài hoặc thời điểm đăng ký

·         Spike load để kiểm tra hệ thống phản ứng khi lưu lượng tăng nhanh

·         Sustained load để kiểm tra hệ thống khi tải cao duy trì trong thời gian dài

·         Tăng kích thước dataset để phát hiện database hoặc storage suy giảm khi dữ liệu tích lũy

·         Kiểm tra sau khi scale-out để xác nhận thêm tài nguyên thực sự tạo thêm throughput

Các ngưỡng cụ thể không nên sao chép từ một LMS hay nhà cung cấp hạ tầng khác. Chúng phải xuất phát từ quy mô người học dự kiến, hành vi sử dụng, SLO và workload của chính tổ chức. Microsoft cũng nhấn mạnh rằng mục tiêu performance test cần được định nghĩa thành các giá trị đo được và gắn với SLO thay vì chỉ dùng nhận định định tính.

Một hệ thống mở rộng tốt phải tránh bottleneck chuyển từ tầng này sang tầng khác

Sai lầm phổ biến là coi scalability như bài toán của web server. Trong thực tế, khi mở rộng tầng ứng dụng, bottleneck có thể đơn giản chuyển xuống database, cache, storage, network, hệ thống xác thực hoặc một API bên ngoài.

Capacity planning vì thế phải xem xét đồng thời CPU, memory, storage, network bandwidth, transaction rate và các peak usage pattern. Azure mô tả capacity planning là quá trình xác định tài nguyên cần thiết để đáp ứng mục tiêu hiệu năng và cảnh báo rằng thiếu kế hoạch năng lực có thể gây bottleneck, suy giảm performance và hành vi workload khó dự đoán.

Khả năng mở rộng thực sự được thể hiện khi năng lực của toàn bộ chuỗi xử lý có thể tăng theo nhu cầu, chứ không phải khi một thành phần riêng lẻ có thể tăng cấu hình. Nếu application server tăng gấp đôi nhưng database đã bão hòa, throughput toàn hệ thống có thể gần như không đổi. Nếu compute còn dư nhưng bandwidth storage đã đạt giới hạn, thêm instance cũng không giải quyết được vấn đề.

Vì vậy, hệ thống học tập nên được giám sát liên tục ở cả cấp ứng dụng lẫn tài nguyên để xác định saturation và lượng headroom còn lại. Các chỉ số này đồng thời cung cấp tín hiệu cho auto-scaling và dữ liệu thực tế để cập nhật capacity plan theo tốc độ tăng người học và dữ liệu.

Một khả năng mở rộng hệ thống học tập đạt yêu cầu không được đánh giá chỉ bằng số tài khoản mà hệ thống có thể lưu. Nó phải chứng minh được rằng khi số người dùng đồng thời, lưu lượng giao dịch và dữ liệu học tập tăng, hệ thống vẫn giữ các mục tiêu hiệu năng đã xác định.

Điều này đòi hỏi kiến trúc có thể scale-out lớp xử lý, mở rộng và phân vùng lớp dữ liệu, tách các workload có đặc tính khác nhau, tránh state cục bộ gây cản trở việc thêm instance và không để một thành phần cố định trở thành bottleneck. Đồng thời, mọi tuyên bố về năng lực phải được xác nhận bằng workload thực tế, benchmark và kiểm thử tải thay vì một con số người dùng chung áp dụng cho mọi hệ thống.