Như đã trình bày ở Chương 1, SPN là mô hình được đề xuất nhằm đánh giá hiệu năng của hệ thống thời gian thực và có các sự kiện ngẫu nhiên rời rạc. Với mục tiêu là đánh giá hệ thống phần mềm thì SPN có thể coi là một lựa chọn tối ưu nhất.
Chương 2 tập trung trình bày về công cụ TimeNET, các đặc điểm nổi bật về giao diện, thành phần bên trong. TimeNET là công cụ hỗ trợ SPN với hai lớp mạng eDSPN và SCPN. Lớp eDSPN bao gồm GSPN và DSPN có khả năng mô hình bài toán trình bày trong phần 3.1.
CHƢƠNG 3: SỬ DỤNG CÔNG CỤ TIMENET ĐÁNH GIÁ HIỆU NĂNG PHẦN MỀM
3.1. Bài toán
3.1.1. Đặt vấn đề
Hệ thống xác thực một lần (SSO) là hệ thống xác thực yêu cầu người dùng đăng nhập vào chỉ một lần với một tài khoản và mật khẩu để truy cập vào nhiều ứng dụng trong một phiên làm việc.
Khi chưa có hệ thống SSO, người dùng phải đăng nhập tài khoản và mật khẩu cho từng ứng dụng mỗi khi cần đăng nhập vào các hệ thống khác nhau. Không những vậy có thể có những hệ thống có chính sách bảo mật khác nhau và thời gian tạo tài khoản khác nhau dẫn đến một người dùng phải nhớ nhiều mật khẩu cũng có thể bao gồm nhiều tài khoản cho các hệ thống khác nhau. Việc này hiển nhiên là tốn thời gian cũng như công sức ghi nhớ, đặc biệt là trong môi trường doanh nghiệp.
SSO là một mô đun xác thực riêng biệt với tất cả các hệ thống khác, nó đóng vai trò như cửa ngõ của tất cả các ứng dụng yêu cầu đăng nhập. Hiển nhiên rằng với SSO thì người dùng được thuận tiện hơn và cũng ít tốn công nghi nhớ, điều này sẽ làm giảm thiểu rủi ro trong việc ghi nhớ nhiều tài khoản và mật khẩu. Dù vậy, hệ thống SSO cũng gặp phải vấn đề về an ninh, bảo mật vì khi bị mất an toàn sẽ gây ảnh hưởng đến toàn bộ các ứng dụng trong hệ thống cũng như vấn đề về đáp ứng truy cập do có quá nhiều yêu cầu xác thực đến một hệ thống.
Hệ thống SSO đã được phát triển tại Viettel từ năm 2014 và tích hợp lần lượt tất cả các tài khoản cá nhân của nhân viên vào hệ thống (thư điện tử, văn phòng điện tử V- Office, quản lý công tác kỹ thuật, quản lý bán hàng, quản lý tài nguyên, giám sát mạng lưới toàn cầu…). Tuy nhiên, với số lượng nhân viên lớn, việc xác thực vào đầu mỗi buổi sáng lên đến khoảng trên 30 nghìn lượt. Hệ thống được triển khai với mục tiêu phản hồi nhanh nhất tất cả các yêu cầu xác thực. Tuy nhiên, với số yêu cầu xác thực quá lớn thì hệ thống có thể không đủ khả năng đáp ứng, không những vậy nếu yêu cầu xác thực không được phản hồi thì người dùng có xu hướng sẽ yêu cầu lại lien tục khiến lượng yêu cầu có khả năng tăng thêm. Bởi vậy, cần xác định tài nguyên để hệ thống hoạt động ổn định cũng như thỏa mãn KPI toàn trình là hết sức cần thiết.
3.1.2. Mô tả hệ thống
Hệ thống được triển khai trên một hạ tầng phần cứng riêng biệt. Khi nhận được yêu cầu từ các hệ thống mà người dùng cần đăng nhập (phần lớn là mạng nội bộ), các hệ thống này sẽ gửi yêu cầu đến SSO.
Khi người dùng đăng nhập lần đầu, hệ thống sẽ gửi yêu cầu đến cơ sở dữ liệu thực hiện hai bước kiểm tra, thứ nhất là kiểm tra tài khoản và mật khẩu có khớp hay không, nếu thông qua bước thứ nhất sẽ kiểm tra quyền của người dùng trong hệ thống đó. Sau đó, hệ thống sẽ gửi phản hồi lại cho ứng dụng và một thẻ sẽ lưu trên trình duyệt của người dùng. Thẻ này cũng được lưu vào bộ nhớ tạm của hệ thống.
Khi người dùng sử dụng vẫn trình duyệt đó để đăng nhập hệ thống khác, hệ thống sẽ kiểm tra thẻ trong bộ nhớ tạm. Lúc này thẻ có trong bộ nhớ tạm, yêu cầu vẫn được gửi đến cơ sở dữ liệu để kiểm tra tuy nhiên bỏ qua bước xác thực người dùng. Và sau đó gửi phản hồi cho ứng dụng.
Trong quá trình thực hiện nhận và xử lý yêu cầu, có một mô đun lưu lại thời gian thực thi trong từng giai đoạn, các thông tin này sau đó sẽ được ghi vào cơ sở dữ liệu để làm căn cứ đánh giá KPI toàn trình của hệ thống.
3.2. Mô hình GSPN
3.2.1. Mô tả
Trong các mô hình dưới đây mô tả hệ thống cũng như tài nguyên phục vụ hoạt động xác thực của hệ thống. Nghĩa là không bao gồm tài nguyên cần để hệ thống hoạt động (khi không có yêu cầu) ví dụ như tiến trình nền của cơ sở dữ liệu, tiến trình kiểm soát tài nguyên…
Mô tả hệ thống được mô hình hóa thành GSPN như Hình 12.
Ứng dụng nhận yêu cầu đăng nhập hệ thống của người dùng và gửi yêu cầu xác thực đến hệ thống SSO. Giai đoạn này đại diện bởi các place AppRequest, SendingRequest
và transition generateRequest. Trong hình thái khởi tạo, AppRequest có nRQ token. Để mô hình hóa khả năng gửi yêu cầu đồng thời từ nhiều người dùng, transition
generateRequest là exponential transition và là Infinte-Server. Khi một yêu cầu được tạo, một token được đẩy vào place SendingRequest, thể hiện yêu cầu đang được gửi đi. Độ trễ của transition này (delayRQ) là một tham số có thể thay đổi để thể hiện khả năng thay đổi tần suất gửi yêu cầu từ phía người dùng.
Hệ thống gồm các thành phần chia sẻ quyền truy cập tới CPU của máy chủ (thể hiện bởi token trong place CPUs). Trước bất cứ công việc tốn thời gian nào, mỗi thành phần phải có một CPU sẵn sàng để thực hiện công việc. Sau khi có được một CPU, một
thành phần bắt đầu thực thi đến khi khi hoàn thành và giải phóng CPU. Trong hình thái khởi tạo, tại place CPUs có nCPU token.
Hình 12: Mô hình GSPN
Yêu cầu gửi đến đến hệ thống sẽ được thực hiện bởi transition sendRequest và việc xuất hiện token tại place ReceivedRequest thể hiện sự kiện yêu cầu đã gửi thành công. Yêu cầu được đưa tới bộ nhớ tạm thể hiện bởi place WaitingCheckCache, transition checkCache sẽ kiểm tra có tồn tại thẻ trùng với thẻ của người dùng gửi tới trong bộ nhớ tạm. Sau đó yêu cầu sẽ được gửi đến cơ sở dữ liệu, thể hiện bởi token ở place
WaitingDB, thực hiện hai bước kiểm tra: kiểm tra tài khoản và kiểm tra quyền của tài khoản. Bước kiểm tra tài khoản có thể bỏ qua khi thẻ có trong bộ nhớ tạm. Tuy nhiên trong mô hình này ta chỉ mô tả quá trình kiểm tra trên cơ sở dữ liệu bởi một transition
trong bộ nhớ tạm) thì một thẻ sẽ được gán cho phiên yêu cầu đó đồng thời được ghi vào bộ nhớ tạm với place WriteInCache và transition writeCache.
Kết thúc việc xác thực, các thông tin về yêu cầu xác thực cũng như thời gian ở từng bước được ghi lại vào cơ sở dữ liệu làm cơ sở đánh giá hoạt động của hệ thống. Quá trình này gồm place WriteInLog, WritingLog và transition writeLog.
Cuối cùng hệ thống gửi phản hồi cho ứng dụng gửi yêu cầu bởi transition
sendResponse.
3.2.2. Tham số
Để hoàn thành đặc tả mô hình, xác định độ trễ của transition là rất cần thiết. Như đã trình bày ở trên, thời gian thực thi ở mỗi bước sẽ được ghi lại vào cơ sở dữ liệu. Đây là nguồn dữ liệu để xác định tham số cấu hình trong mô hình.
Dựa trên dữ liệu KPI toàn trình của hệ thống tác giả thu được kết quả thống kê như sau:
- Có trung bình 376445 yêu cầu mỗi ngày làm việc (từ thứ 2 đến thứ 6).
- Có trung bình 36240 yêu cầu trong khoảng thời gian cao điểm (8h đến 9h) các ngày làm việc.
- Giá trị trễ trung bình tại mỗi sự kiện được xác định bằng tổng tất cả tích của độ trễ với xác suất xuất hiện giá trị đó. Tuy nhiên, riêng dữ liệu thời gian ghi thông tin thời gian vào cơ sở dữ liệu được lấy từ kết quả phân tích của cơ sở dữ liệu Oracle. Mặc dù quá trình xác thực cũng thực hiện trên cơ sở dữ liệu, tuy nhiên do quá trình có nhiều bước (trong khi cơ sở dữ liệu chỉ phân tích với cụ thể từng câu lệnh) nên vẫn lấy thời gian hệ thống đo được.
Bảng 1: Thông tin tham số của timed transition trong GSPN
Transition Giá trị trễ trung bình ServerType
checkCache 8.992 Infinite-Server authorize 13.096 Infinite-Server writeCache 1.98 Infinite-Server writeLog 28.82 Infinite-Server sendRequest 13.125 Infinite-Server sendResponse 15.217 Infinite-Server
Từ dữ liệu KPI cũng như báo cáo của cơ sở dữ liệu, ta tính toán được độ trễ tương đối chi tiết của timed transition và được tổng kết trong Bảng 1. Chi tiết liên quan đến immediate transition được thể hiện trong Bảng 2.
Bảng 2: Thông tin tham số của immediate transition trong GSPN
Transition Weight Priority Enabling Function
getMemCache 1 1 -
getDB 1 1 -
getWrite 1 1 -
getWriteLog 1 1 -
3.3. Mô hình DSPN
Mô hình DSPN với hoạt động của hệ thống không khác với mô hình GSPN. Do 99,8% yêu cầu kiểm tra ở bộ nhớ đệm cần 9ms nên ở đây tác giả tiến hành thử ngiệm chuyển transition checkCache thành deterministic. Từ đó có giá trị độ trễ của transition này là 9ms.
Hình 13: Mô hình DSPN