Luận văn thạc sĩ Khoa học máy tính: Hệ thống đề xuất tài nguyên Kubernetes

PHẠM VI ĐỀ TÀI

Tổng quan

Trong môi trường Cloud Computing, công nghệ ảo hoá container được biết đến với hệ thống phân cấp ảo hoá ở mức hệ điều hành (OS) Công nghệ ảo hoá này sẽ thực hiện việc tạo ra các containers và đóng gói các ứng dụng sử dụng chung hệ điều hành (OS kernal) Một trong những giải pháp của container là Docker cho phép khởi động ứng dụng trong thời gian ngắn hơn rất nhiều so với việc chạy một ứng dụng trên công nghệ ảo hoá truyền thống Với sự linh hoạt và thời gian từ lúc khởi động đến lúc ứng dụng sẵn sàng để chạy ngắn đã mang lại những lợi thế dáng kể trong khả năng mở rộng và phục hồi (scalability and resilience) của hệ thống từ đó tăng hiệu quả trong việc đáp ứng nguồn tài nguyên cho hệ thống [2] [3]

Hình 1: Cách hoạt động của Virtualization và Containers

Với sự phát triển mạnh của công nghệ ảo hoá và khả năng chạy một ứng dụng nhanh chóng, các ứng dụng ngày nay có thể được triển khai trên nhiều containers và các containers sẽ đảm nhiệm một công việc tương tự nhau Do đó, việc dự đoán được tải mà các containers tiêu thụ đóng vai trò rất quan trọng nhằm đảm bảo được các tiêu chí liên quan đến doanh nghiệp Service-Level Agreements (SLAs) [4] Thực tế, việc xác định được đúng nguồn tài nguyên cần cấp cho hệ thống sẽ giúp cho việc sử dụng tài nguyên hiệu quả mà vẫn đảm bảo hiệu suất của ứng dụng (application performance) và ảnh hưởng trực tiếp đến chi phí vận hành của hệ thống

Tuy nhiên, việc dự đoán chính xác được tải mà containers cần để ứng dụng vận hành tốt là một thách thức lớn bởi vì yêu cầu phải xác định được loại thông tin đầu vào để xác định được tải (metrics) hiện tại và khả năng dự đoán dựa trên nhưng giá trị đầu vào đó

Với các hệ thống giám sát sẽ cung cấp một lượng lớn thông tin hữu ích trong việc hiểu rõ hơn hiệu suất và dự đoán được tải mà hệ thống đó tiêu thụ Tuy nhiên, những thông tin đó cũng gây nên khó khăn trong việc lựa chọn thông tin nào là hữu ích và không hữu ích

Ví dụ, lượng requests tới một ứng dụng nào đó trong một khoảng thời gian nhất định ảnh hưởng đến network Input and Output trong khi memory ảnh hưởng bởi truy xuất tới database v.v…

2 Hiện nay đã có các công trình nghiên cứu tải của máy chủ chạy các chương trình dựa trên dữ liệu theo thời gian (time series-based) như mô hình ARIMA (moving avarage, autoregressive, autoregresive integrated moving-average [4-6] hoặc machine learning algorithms model như Hidden Markov Model [7-9] Những mô hình này làm việc tốt với một số loại tải có dạng (patterns) như tài nguyên tiêu thụ trong quá khứ Tuy nhiên, khi tải của hệ thống có sự biến động, những model này không giải quyết được với trường hợp kiểu dữ liệu đầu vào phức tạp Do đó, các mô hình Long Short-Term Memory (LSTM) neural networks trở nên hữu ích với các kiểu tải phi tuyến tính Mô hình Long Short-Term Memory sử dụng hàm phi tuyến tính để có thể làm việc tốt với các kiểu dữ liệu mới (new patterns) có sự biến động khó xác định Tuy nhiên, mô hình LSTM sẽ khó có được một dự đoán tối ưu vì nó xử lý dữ liệu theo một chiều nên dữ liệu có thể bị bỏ sót, ảnh hưởng đến độ chính xác.

Sơ lược về tình hình nghiên cứu

Hiện nay đã có các công trình nghiên cứu liên quan đến những vấn đề scaling application bằng cách phân tích các dữ liệu theo thời gian thực trên các hệ thống điện toán đám mây Việc phân tích dữ liệu theo thời gian có rất nhiều ứng dụng trong các lĩnh vực khác nhau như dự báo động đất, các vấn đề liên quan đến tài chính, dự báo thời tiết Các ứng dụng này sử dụng các dữ liệu trong quá khứ và dữ liệu quan sát được nhằm mục đích dự đoán một giá trị trong tương lai Một trong những ví dụ trong việc sử dụng dữ liệu theo thời gian là tài nguyên tiêu thụ của hệ thống theo thời gian liên quan đến CPU hay Memory, hoặc số lượng lưu lượng requests tới một hệ thống trong một khoảng thời gian một phút

Al-Dhuraibi et al [5] đã đề xuất một kiến trúc ELASTICDOCKER sử dụng phương pháp “reactive”, dựa trên ngưỡng được xét ban đầu và các quy luật được đặt ra từ trước để có thể thực hiện việc scaling Luận văn đã xây dựng mô hình nhằm mục đích scale hệ thống theo hướng tăng thêm tài nguyên cho hệ thống hiện tại thay vì cung cấp thêm các containers để giải quyết luồng xử lý dữ liệu

Hình 2: Sự khác nhau giữa Vertical Scaling và Horizontal Scaling

Kiến trúc ELASTICDOCKER scale hệ thống theo phương pháp vertical scaling cho cả CPU cores và Memory Một trong những nhược điểm của phương pháp vertical scaling là

3 việc giới hạn về tài nguyên của hệ thống bởi vì khi một container chạy, nó sẽ chỉ hoạt động trên một host và khi scaling container đó bằng cách thay đổi số lượng CPU core hay Memory sẽ gặp phải trường hợp giá trị đó đạt giá trị cho phép của host Tuy nhiên, ELASTICDOCKER đã nhận thấy được điều đó và thực hiện việc chuyển đổi container sang host khác có nguồn tài nguyên đáp ứng được yêu cầu tại thời điểm tính toán Kiến trúc ELASTICDOKER đã đạt được một số kết quả nhất định trong việc cân bằng chi phí vận hành hệ thống và trải nghiệm của người dùng

Horizontal Pod Autoscaler (HPA) [6] được xây dựng bởi Kubernetes là một kiến trúc điều khiển lặp sử dụng reactive scaling và sử dụng phương pháp tiếp cận Horizontal Scaling Phương pháp này sẽ tạo ra các Kubernetes pods, đơn vị nhỏ nhất trong Kubernetes phục vụ cho việc chạy các ứng dụng containers, dựa trên CPU hiện tại của hệ thống và dựa vào các luật được xác định từ trước, HPA sẽ cung cấp thêm hay giảm bớt dựa trên dữ liệu hiện tại Ví dụ, nếu CPU của một deployment trong Kubernetes đạt ngưỡng 80% thì số lượng Kubernetes Pods sẽ tăng lên 1.5 lần, ngược lại nếu CPU tiêu thụ đạt mức set 20% thì số lượng Kubernetes Pods sẽ giảm xuống 1.5 lần Mục đích của cách tiếp cận này là đảm bảo rằng CPU tiêu thụ của hệ thống sẽ luôn nằm trong ngưỡng mong muốn

Zhang et al [7] đã đề xuất kiến trúc sử dụng cách tiếp cận reactive cho các hệ thống hybrid cloud, phương pháp này phù hợp với các hệ thống chạy song song trên hai môi trường public cloud và môi trường private-owned data centers (legacy) Kiến trúc này cho phép liên kết giữa cơ sở hạ tầng cũ và hạ tầng trên đám mây Điểm quan trọng của phương án này là khả năng tính toán tài nguyên bằng cách phát hiện được các kiểu dữ liệu một cách nhanh chóng từ hai môi trường dựa trên mức độ phổ biến của dữ liệu Phương pháp này phân bổ ứng dụng dựa trên mức độ tiêu thụ tài nguyên base load và traspassing load Trong đó, base load là kiểu dữ liệu có độ biến động không nhiều việc biến động của tài nguyên tiêu thụ cũng chậm và mượt (hệ thống được triển khai trên môi trường data-center), traspassing load nhắm đến các loại ứng dụng tiêu thụ tài nguyên nhiều và có sự biến động mạnh (hệ thống được triển khai trên môi trường cloud tận dụng dặc tính linh hoạt – elastic) Luận văn cũng đã kết hợp giải thuật Autoregressive Integrated Moving Average (ARIMA) và Fourier Transfer

Hình 3: Kiến trúc của mô hình hybrid cloud

Hình 4: Các thành phần mô hình Workload factoring

Ngoài mô hình ARIMA cho mục đích dự đoán đối với dữ liệu đầu vào theo thời gian còn có các mô hình khác như autoregression (AR), moving average (MA), autogregressive moving average (ARIMA)

Mặc dù các mô hình giải thuật theo hướng cách tiếp cận reactive mang đến những kết quả đáng kể, nhưng mô hình cũng tồn tại một số giới hạn bởi vì việc phân bổ tài nguyên xảy ra khi mà sự kiện đã xảy ra Ví dụ, tại thời điểm lưu lượng truy cập vào trang web nhiều dẫn đến CPU tăng lên 90%, tại thời điểm này hệ thống sử dụng phương pháp reactive mới bắt đầu phần tích Điều đó có nghĩa là hệ thống sẽ cần một khoảng thời gian để có thể điều chỉnh nguồn tài nguyên cung cấp cho hệ thống Thông thường, đối với các hệ thống reactive khó phù hợp với các hệ thống có lưu lượng truy cập hoặc tài nguyên tiêu thụ ít

Từ những điểm giới hạn của phương pháp tiếp cận reactive, phương pháp proactive sẽ dựa trên những dữ liệu trong quá khứ kết hợp với các giải thuật hồi quy hoặc neural network để có thể dự đoán được tài nguyên cần cung cấp cho hệ thống trong tương lai gần

Li and Xia [8] đã đề xuất một mô hình tự động điều chỉnh tài nguyên cung cấp cho hệ thống trên đám mây Resource Prediction and Provisiong Scheme (RPPS), mô hình này có thể scale các ứng dụng web trong môi trường hybrid cloud RPPS sử dụng mô hình ARIMA để phân tích CPU tiêu thụ bởi hệ thống trong quá khứ và dự đoán tài nguyên tiêu thụ trong tương lại từ đó có thể cung cấp tài nguyên cần thiết Phương pháp này được đánh giá có

5 ưu điểm hơn so với phương pháp HPA được phát triển bởi Kubernetes và phù hợp với tải biến động

Nhat-Minh Dang Quang et al,

Container Requests rate Proactive Bi-LSTM

Zhang et al, 2021, [9] VM Requests rate Reactive ARIMA Al-Dhuraibi et al, 2017, [5] Container CPU, Memory Reactive Rule-based

HPA (opensource) Container CPU Reactive Rule-based

Li and Xia, 2012, [8] Container CPU Proactive ARIMA Prachimutita et al., 2018, [10] VM Requests rate Proactive ANN, RNN Imdoukh et al., 2019 [11] Container Requests rate Proactive LSTM

Xuehai Tang et al., 2018, [12] Container CPU Proactive Bi-LSTM

Bảng 1: Tổng quan các công trình nghiên cứu liên quan đến các phương pháp autoscaling

Việc sử dụng ARIMA như giải thuật với mục đích dự đoán tài nguyên tiêu thụ cũng được Rodrigo sử dụng, tuy nhiên, dữ liệu đầu vào của mô hình này là số lượng truy cập HTTP Mô hình này cung cấp độ chính xác là 91% đối với dữ liệu có sự biến động thấp và có xu hướng kém chính xác khi dữ liệu đầu vào biến động mạnh

Prachimutita et al [10] đã đề xuất một mô hình autoscaling sử dụng mô hình Artificial Neural Network (ANN) và Recurrent Neural Network (RNN) để dự đoán tài nguyên tiêu thụ trong tương lai Dựa trên những giá trị tính toán được, dữ liệu đó sẽ được chuyển đổi thành thông số CPU và Memory cần để cung cấp cho hệ thống Hiệu suất của hệ thống được đánh giá dựa trên tập dữ liệu WorldCup năm 1998

Imdoukh et al [11] in đề xuất môt mô hình học máy cho kiến trúc autoscaling Việc dự đoán tài nguyên tiêu thụ cần cho hệ thống sử dụng mô hình Long Short-Term Memory (LSTM) và thí nghiệm cũng được xác định với tập dữ liệu mẫu là 1998 World Cup website Luận văn cũng đã so sánh kết quả thực nghiệm đó với các mô hình dự đoán khác nhau như mô hình ARIMA và ANN Kết quả của quá trình thực nghiệm và so sánh chỉ ra rằng mô hình LSTM có độ chính xác thấp hơn so với mô hình ARIMA nhưng tốc độ dự đoán nhanh hơn 530 đến 600 lần trong một bước dự đoán

Tang et al [12] đã đề xuất phương án dự đoán tài nguyên dựa trên tiếp cận mô hình Bi- direction Long Short-Term Memory (Bi-LSTM) Mô hình này sử dụng dữ liệu đầu vào là dữ liệu CPU tiêu thụ của hệ thống trong quá khứ Luận văn cũng so sánh kết quả thử

6 nghiệm của Bi-LSTM và các mô hình khác như ARIMA và LSTM, kết quả so sánh cho thấy Bi-LSTM có khả năng dự đoán với sai số thấp hơn so với hai mô hình còn lại

Ming Yan et al [9] đề xuất một mô hình có sự kết hợp cả hai cách tiếp cận là reactive và proactive cho các hệ thống chạy bên trong Kubernetes Cách tiếp cận này sử dụng mô hình Bi-LSTM để có thể dự đoán tải thông qua tài nguyên tiêu thụ CPU và Memory của cả host và bản thân containers, từ đó có thể dự đoán được tài nguyên cần cung cấp trong tương lai Bi-LSTM kết hợp phương pháp học tăng cường (online reinforcement learning) với mô hình reactive để đạt được kết quả mong đợi Luận văn cũng đánh giá được mô hình sử dụng Bi-LSTM không chỉ đáp ứng được các Service Legal Agrement (SLA) mà còn có sai số dự đoán thấp hơn so với các mô hình như ARIMA, LSTM, và RNN

Bài toán nghiên cứu

Nghiên cứu mô hình học sâu có khả năng xử lý với dữ liệu đầu vào là loại dữ liệu theo thời gian (time-series data), xác định cơ chế hoạt động và yêu cầu cần thiết trong việc xây dựng hệ thống gợi ý nguồn tài nguyên cần cung cấp cho các ứng dụng Các ứng dụng được đóng gói trong containers và chạy trong môi trường điện toán đám mây (cloud computing)

Mô hình sử dụng Kubernetes như một cụm quản lý tài nguyên (container orchestrator) Trong giới hạn luận văn cũng như giới hạn về thời gian, luận văn chỉ tập trung giải quyết các bài toán sau:

- Tiền xử lý dữ liệu: xác định mô hình xử lý dữ liệu đầu vào và giảm số chiều của dữ liệu bằng cách loại bỏ những dữ liệu không liên quan, nhiễu Những loại dữ liệu có chung kiểu (pattern) sẽ được phân loại và loại bỏ các dữ liệu không đóng góp trong quá trình dự đoán tài nguyên cần thiết cho hệ thống Nhằm đảm bảo được việc học máy sẽ dựa trên dữ liệu hữu ích thay vì toàn bộ dữ liệu

- Tìm hiểu các giải thuật dự đoán tài nguyên cần sử dụng: neural network đối với dữ liệu đầu vào theo thời gian và biến động phi tuyến

- Mô hình thu thập dữ liệu và điều khiển: đánh giá tính hiệu quả của việc thu thập dữ liệu và điều khiển tài nguyên cho các containers được triển khai trên môi trường điện toán đám mây (AWS) và trong Kubernetes (EKS).

Bố cục luận văn

Luận văn được chia thành chín chương, trong đó:

- Chương 1: Phụ lục hình ảnh và bảng

- Chương 2: Từ viết tắt và ý nghĩa

- Chương 3: Tổng quan sơ lược về luận văn tốt nghiệp Phân tích đánh giá các công trình nghiên cứu đã có của các tác giả liên quan đến luận văn tốt nghiệp, nêu lên những vấn đề còn tồn tại và vấn đề mà luận văn tập trung nghiên cứu

- Chương 4: Đề xuất các phương án liên quan đến mô hình học máy, phương án thu thập xử lý dữ liệu và phương pháp điều khiển cũng như kiểu dữ liệu đầu vào cho bộ điều khiển Từ đó, lựa chọn phương án phù hợp để thực hiện trong luận văn

- Chương 5: Thu thập và xử lý dữ liệu đầu vào, phương án tổng hợp, chuyển đổi và xử lý dữ liệu nhiễu của tập dữ liệu đầu vào Ngoài ra, Chương 5 cũng tập trung vào việc xác định và đánh giá mối tương quan giữa các dữ liệu đầu vào

- Chương 6: Nghiên cứu tập trung vào phân tích cấu trúc của mô hình LSTM và Bi- LSTM, đồng thời đánh giá mối quan hệ giữa chúng dựa trên các thông số liên quan, cấu trúc mạng và dữ liệu đầu vào Trong Chương 6, cũng đã đi vào chi tiết về các thông số được sử dụng trong quá trình huấn luyện mô hình Bi-LSTM

- Chương 7: Tập trung vào đo đạc thực nghiệm mô hình dự đoán trên các khoảng thời gian nhất định trong tập dữ liệu dataset Ngoài ra, Chương 7 cũng so sánh tính hiệu quả của mô hình sử dụng phương pháp truyền thống (reactive autoscaler), phương pháp sử dụng Bi-LSTM và phương pháp kết hợp Từ đó đưa ra được nhận xét về hiệu xuất của từng mô hình

- Chương 8: Từ những phân tích đánh giá và thực nghiệm Chương 8 đưa ra những nhận xét về tính hiệu quả của mô hình Chương 8 cũng chỉ ra những gì mà luận văn đã đạt được và hướng phát triển trong tương lai

- Chương 9: Tài liệu tham khảo

LỰA CHỌN PHƯƠNG ÁN

Lựa chọn mô hình dự đoán tải của hệ thống

Như đã trình bày trong phần tổng quan, hiện nay có nhiều mô hình dự đoán tải cho hệ thống được đề xuất và được chia làm hai phần chính: reactive và proactive Trong khi phương án tiếp cận reactive đề cập đến các giải pháp như HPA và ELASTICDOCKER thì phương pháp tiếp cận proactive sử dụng các giải thuật ARIMA, RNN, LSTM, Bi-LSTM, etc

Phương án reactive có thể dễ dàng trong việc tiếp cận cũng như cách thức thực hiện Tuy nhiên, vẫn có những điểm bất lợi liên quan đến khả năng đáp ứng của hệ thống đối với các ứng dụng yêu cầu tải biến động

Do đó, phương pháp proactive hứa hẹn sẽ cho phép xây dựng các mô hình phù hợp với các kiểu dữ liệu phi tuyến hoặc biên độ giao động cao Mặc dù có rất nhiều mô hình dự đoán liên quan đến phương án tiếp cận proactive, luận văn chỉ đề xuất phân tích ba mô hình dự đoán: ARIMA, LSTM và Bi-LSTM từ đó có thể lựa chọn được phương án phù hợp

Mô hình ARIMA, Autoregressive Integrated Moving Average, có sự liên quan đến chuỗi thời gian và sự tương quan giữa giá trị trong quá khứ đến giá trị hiện tại Mức độ tương quan càng lớn khi chuỗi càng gần đến thời điểm hiện tại Do đó, mô hình ARIMA sẽ tìm cách đưa vào các biến trễ nhằm tạo ra một mô hình dự báo tốt hơn ARIMA là mô hình biểu diễn phương trình hồi quy tuyến tính đa biến của các biến đầu vào:

Auto Regressive: Thành phần tự hồi quy tập hợp các độ trễ của biến hiện tại Độ trễ bậc p là giá trị lùi về quá khứ p bước thời gian của chuỗi Độ trễ dài hoặc ngắn trong quá trình AR phụ thuộc vào tham số trễ p Quá trình hồi quy với độ trễ bậc p của chuỗi 𝑥 𝑡 được biểu diễn như sau:

Moving Regressive: Quá trình trung bình trượt được hiểu là quá trình dịch chuyển hoặc thay đổi giá trị trung bình của một chuỗi theo thời gian Do chuỗi được giả định là dừng nên quá trình thay đổi trung bình dường như là một chuỗi nhiễu trắng (một thành phần ngẫu nhiên thể hiện cho yếu tố không thể dự đoán của mô hình và không có quy luật) Quá trình moving average sẽ tìm mối liên hệ về mặt tuyến tính giữa các phần tử ngẫu nhiên 𝜖 𝑡 (stochastic term) Chuỗi nhiễu trắng này phải thoả mãn tính chất:

Trong đó: (1) kỳ vọng của chuỗi bằng 0 để đảm bảo chuỗi dừng không có sự thay đổi về mặt trung bình theo thời gian (2) là phương sai của chuỗi không đổi

9 Các công trình nghiên cứu phân tích tính hiệu quả của ARIMA trong bài toán scaling cho thấy rằng tốc độ dự đoán của mô hình ARIMA chậm Ngoài ra độ chính xác của mô hình cũng sẽ giảm xuống trong trường hợp dự đoán trên nhiều bước thời gian

Mô hình LSTM dựa trên mô hình RNN (recurrent neural network) phục vụ cho quá trình xử lý thông tin dạng chuỗi RNN có thể mang thông tin đầu ra của các state trước đó tới state sau và ở state sau sẽ kết hợp tất cả các thông tin và dự đoán một đối tượng nào đó Trong mô hình RNN đối với các state càng xa thì nó sẽ càng bị vấn đề vanishing gradient và các hệ số không được cập nhật với các thông tin ở xa Do đó các thông tin ở xa sẽ không có ý nghĩa cho quá trình học do vinishing gradient (short-term memory)

Mô hình LSTM không chỉ hỗ trợ cho việc học và xử lý các thông tin ở gần mà nó còn có thể học và xử lý thông tin xa trong quá khứ Do đó, những thông tin quan trọng trong quá khứ sẽ được giữ lại

Hình 5: Mô hình hoạt động của mạng RNN

Hình 6: Mô hình hoạt động bên trong của một node RNN

Trong hình ở trên, đối với mạng RNN thì quá trình xử lý là một phép nhân đơn giản của input (xt) và kết quả của quá trình xử lý trước đó Sau đó kết quả của phép nhân sẽ đi qua một hàm Tanh

Hình 7: Mô hình hoạt động của LSTM

Mô hình Long short-term memory ở Hình 7 chỉ ra rằng có 2 cổng forget và output được thêm vào trong đó:

Forget gate: sẽ quyết định xem cần lấy bao nhiêu từ state trước

Output gate: quyết định xem cần lấy bao nhiêu từ cell state để trở thành output của hidden state

Input gate: sẽ quyết định lấy bao nhiêu từ input của state và hidden layer của layer trước đó

Mô hình LSTM có thể giải quyết được vấn đề vanishing gradient tốt hơn so với mô hình RNN Do đó, mô hình LSTM thường được dùng phổ biến hơn RNN cho các bài toán thông tin dạng chuỗi

Cả hai mô hình LSTM và mô hình Bi-LSTM đều dựa trên kiến trúc của Recurrent Neural Network thường được sử dụng cho các giải pháp liên quan đến xử lý ngôn ngữ tự nhiên như language modeling, text classification Nhìn chung cả hai mô hình LSTM và mô hình Bi-LSTM đều tương tự về cấu trúc Khác với mô hình LSTM nơi mà quá trình đưa dữ liệu từ tính toán trước đó tới tính toán tiếp theo sẽ diễn ra theo một chiều, mô hình Bi-LSTM là một recurrent neural network được sử dụng chủ yếu cho xử lý ngôn ngữ tự nhiên có thể sử dụng thông tin đầu vào theo hai chiều Bi-LSTM có nhiều lớp (layers) hơn so với mô hình LSTM vì yếu tố xử lý thông tin theo hai chiều và chúng ta có thể kết hợp kết quả đầu ra của các layer theo các cách: trung bình, tổng, nhân, etc

- Bi-LSTM sẽ thu nhận dữ liệu theo hai chiều, chiều tương lai và chiều về quá khứ, do cấu trúc của Bi-LSTM có hai lớp hồi quy xử lý dữ liệu đầu vào theo hai chiều ngược nhau Do đó, cho phép mô hình có thể học theo hai chiều độc lập

- Mô hình LSTM được thiết kế nhằm mục đích xử lý hiện tượng Vanishing Gradient thường xảy ra trong mô hình RNN Tuy nhiên, hiện tượng này vẫn diễn ra đối với long-term memory Bi-LSTM có khả năng giải quyết vấn đề đó một cách tốt hơn vì dữ liệu được thu thập và xử lý theo hai chiều cho phép nó trích xuất và giữ lại được thông tin quan trọng và hữu ích trong một chuỗi thời gian dài Ngoài ra, cũng vì dữ liệu được phân tích theo hai chiều nên việc tính toán cũng như dự đoán sẽ chính xác

11 hơn so với LSTM, đặc biệt đối với các bài toán liên quan đến dán nhãn dữ liệu theo thời gian

Lựa chọn phương pháp thu thập và đo đạc dữ liệu

Việc thu thập dữ liệu của hệ thống cho mô hình thực nghiệm được triển khai trong môi trường điện toán đám mây đòi hỏi các yếu tố:

- Khả năng tương thích của các mô hình thu thập dữ liệu

- Cấu trúc của dữ liệu thu thập và cách thức xử lý dữ liệu trước khi đưa vào để tính toán

Vì ứng dụng chạy trong các hệ thống khác nhau sẽ có kiến trúc khác nhau và phương án thu thập xử lý dữ liệu cũng khác nhau Do đó, luận văn đề xuất một mô hình tổng quát một ứng dụng chạy trong Kubernetes như sau:

Hình 9: Mô hình microservices chạy trong Kubernetes với Load Balancer Ở Hình 9, khi một requests từ phía máy khách vào một hệ thống thì nó sẽ đi qua một endpoint, endpoint đó có thể là một Proxy server (Load Balancer) hoặc một API gateway Requests sau đó sẽ re-direct tới backend nhằm xử lý dữ liệu và trả về phía client Tuy nhiên, dữ liệu đến backend sẽ được xử lý bởi các microservices và tùy vào từng bài toán cụ thể mà việc gọi qua lại giữa các hệ thống cũng như một hệ thống và bên thứ ba cũng sẽ khác nhau Do đó, việc quan sát và điều khiển nguồn tài nguyên cần cung cấp cho hệ thống vào từng microservices là điều cần thiết và đòi hỏi các công cụ cần thiết để thu thập dữ liệu Ngoài ra việc xác định đúng dữ liệu cần thu thập cũng như dữ liệu cần cho quá trình đưa ra kết luận là hết sức cần thiết

Hình 10: Mô hình thu thập dữ liệu nhằm phục vụ cho quá trình phân tích

AWS Load Balancer ở Hình 10 hoạt động như một Proxy Server, nhận dữ liệu từ phía client và điều hướng tới các backend servers AWS Load Balancer metrics sẽ chứa các loại metrics cần thiết cho quá trình dự đoán như: GrpcRequestsCount, HTTP_Redirect_Count, RequestsCount, ProcessedBytes

Vì ứng dụng chạy trong mô hình Kubernetes và chia thành các microservices, do đó một hệ thống sẽ có nhiều ứng dụng chạy đồng thời và có thể gọi qua lại lẫn nhau Và số lượng requests từ hệ thống này tới các hệ thống khác nhau cũng sẽ khác nhau Mặc dù Application Load Balancer trong trường hợp ở trên có thể cung cấp các metrics hữu ích cho quá trình train model và quá trình dự đoán, nhưng việc đo đạc dữ liệu tại một điểm (endpoint) ở proxy server hay api-gateway như hình sẽ không đảm bảo được hệ thống sẽ cung cấp đủ tài nguyên cho tất cả các microservices Ngoài ra, việc điều khiển ở proxy server có thể gây lãng phí tài nguyên khi lượng requests vào một hệ thống nhiều nhưng một microservices nào đó trong Kubernetes chỉ nhận lượng nhỏ traffic dẫn đến tài nguyên cung cấp cho chính microservice đó sẽ dư thừa Dẫn đến, mặc dù nó tiêu thụ rất ít tài nguyên nhưng vì việc thu thập dữ liệu và đo đạc tại điểm cuối dẫn đến vô tình đánh giá microservice này đang tiêu thụ nhiều tài nguyên (false positive)

Một phương án thay thế là thu thập dữ liệu của các microservices như một dữ liệu đầu vào cho quá trình đưa ra quyết định Phương án này đòi hỏi hệ thống cần có phương án lấy những metrics đó và lưu trữ dữ liệu dạng time series databse để có thể phục vụ cho quá trình dự đoán

Hình 11: Kiến trúc thu thập dữ liệu metrics từ các microservices và đẩy về Metric server

Hình 11 mô tả kiến trúc thu thập dữ liệu metrics từ các microservices và đẩy về Metric server Trong trường hợp này metric server hoạt động như một time series database lưu trữ dữ liệu time series Dữ liệu được thu thập và lưu trữ ở Metrics server sẽ được sử dụng bởi một Proactive Autoscaling để điều khiển quá trình scale của hệ thống, nhằm đáp ứng với tải được tính toán bởi mô hình học máy Bi-LSTM

Vì dữ liệu thu thập là dữ liệu dưới dạng time-series data, do đó cần lựa chọn một mô hình lưu trữ phù hợp với kiểu dữ liệu như vậy Luận văn đề xuất lựa chọn phương án trên ba mô hình ELK (ElasticSearch, Logstash, và Kibana), Prometheus và Cloudwatch của Amazon Webservice

2.2.1 Thu thập log data và metrics sử dụng AWS Cloudwatch

AWS Cloudwatch được biết đến như một công cụ giám sát và được phát triển bởi Amazon, với lợi thế tích hợp một cách dễ dàng với các dịch vụ khác trên đám mây có thể giúp cho việc thu thập dữ liệu diễn ra nhanh hơn Metrics liên quan đến lượng người dùng gửi yêu cầu tới hệ thống thông qua một AWS Load Balancer Metrics từ Load Balacner sau đó được đẩy đến AWS CloudWatch phục vụ cho việc lưu trữ hoặc tích hợp với các công cụ thứ ba

Hình 12: Mô hình hoạt động cũng như công dụng của AWS CloudWatch

AWS Cloudwatch tích hợp tốt đối với các dịch vụ cung cấp bởi AWS, tuy nhiên việc tích hợp các công cụ ngoài AWS vào CloudWatch sẽ khó khăn và đòi hòi ứng dụng phát triển đó phải tương thích với kiểu dữ liệu mà CloudWatch cung cấp

2.2.2 Thu thập log data và metrics sử dụng Prometheus

Prometheus là một công cụ monitor mã nguồn mở với cơ sở dữ liệu theo thời gian thực, trong đó time series database là database được lưu trữ theo các mốc thời gian Mỗi dữ liệu luôn được gắn với một mốc thời gian nhất định từ đó tạo ra một chuỗi dữ liệu theo thời gian Một trong những ưu điểm của Prometheus cung cấp API để các ứng dụng phát triển có thể kết nối và lấy dữ liệu cần thiết

Tuy nhiên, Prometheus là một Opensource software nên việc tích hợp với AWS Load Balancer sẽ trở nên khó khăn Không giống như AWS Cloudwatch, Amazon đã cung cấp các giải pháp để có thể đấy logs và metrics một cách dễ dàng Để có thể lấy metrics từ AWS Load Balancer chúng ta cần phải có giải pháp đẩy metrics qua một nơi trung gian trước khi đưa metric về Prometheus YACE (yet-another-cloudwatch-exporter) lấy metrics từ AWS Cloudwatch và chuyển đổi thành Prometheus format sau đó đấy tới Prometheus server

Hình 13: Mô hình thu thập dữ liệu từ AWS Load Balancer sử dụng Prometheus

Vì ứng dụng chạy trong Kubernetes là các microservices, để có thể thu thập được các metrics phục vụ cho quá trình dự đoán ứng dụng cần phải có khả năng đẩy các metrics đó tới Promertheus Prometheus cung cấp những công cụ để có thể thu thập dữ liệu từ các microservices chạy trong Kubernetes như số lượng http requests trên mỗi giây trên microservice, hay số lượng CPU and Memory mà hệ thống đang tiêu thụ để duy trì hoạt động của hệ thống Cơ chế của Promtheus là cứ một khoảng thời gian nhất định Prometheus sẽ gọi các microservces để thu thập metrics dựa trên các rules được cấu hình bởi người sử dụng Do đó để ứng dụng có thể cung cấp các metrics cần thiết thì việc sử dụng Istio là một giải pháp hiệu quả Ngoài ra, Istio cũng hữu ích trong việc tăng tính bảo mật cho việc giao tiếp giữa các microservices bởi vì nó sẽ đảm bảo rằng việc giao tiếp là HTTPS và dữ liệu trên đường truyền đã được mã hóa

Khi sử dụng Istio, nó sẽ thêm vào các Kubernetes pod một istio sidecar container, nó hoạt động như một proxy và cung cấp các metrics cần thiết liên quan đến số lượng requests tới một hệ thống cũng như số bytes mà hệ thống trả về cho máy khách

2.2.3 Thu thập log data và metrics sủ dụng ElasticSearch

ElasticSearch là một công cụ hỗi trợ cho việc tìm kiếm dữ liệu một cách nhanh chóng dựa trên Apache Lucene (near-realtime searching) Nó có khả năng phân tích dữ liệu và mở rộng theo chiều ngang và hỗi trợ khả năng search khi câu truy vấn có vấn đề Ngoài ra, Elasticsearch sử dụng tính năng ILM (Index lifecycle management) để di chuyển dữ liệu cũ tới nodes với chi phí tài nguyên thấp do đó làm tăng hiệu suất cũng như chi phí lưu trữ

17 Tuy nhiên, ElasticSearch phù hợp cho mục đích tìm kiếm dữ liệu thường không được sử dụng như một database chính để lưu trữ dữ liệu Khả năng đảm bảo tính toàn vẹn trong ElasticSearch sẽ khó vì nó không sử dụng database transaction nên việc mất mát dữ liệu là có thể xảy ra

Lựa chọn phương án điều khiển hệ thống

Do ứng dụng chạy dưới dạng microservices trong Kubernetes nên việc cung thấp thêm hay giảm bớt tài nguyên cho hệ thống có thể được thực hiện bằng:

- Tăng thêm số lượng CPU hoặc Memory cho chính máy chủ đang chạy ứng dụng (Vertical Autoscaling)

- Tăng thêm số lượng CPU hoặc Memory một cách gián tiếp thông qua việc tăng thêm số lượng Kubernetes Pods của microservices (Horizontal Autoscaling)

Việc cung cấp thêm tài nguyên cho chính máy chủ đang chạy ứng dụng gây khó khăn trong việc đảm bảo hệ thống vẫn hoạt động bình thường và không bị gián đoạn đặc biệt đối với các hệ thống mà tải biến động liên tục Bởi vì khi một ứng dụng đang chạy nếu bằng cách nào đó ứng dụng bị khởi động lại thì những process đang thực thi trên máy đó nhằm phục vụ cho một requests nhất định từ phía client có thể bị gián đoạn Để tránh các trường hợp này, cần phải xác định rõ đặc tính của ứng dụng và khả năng mà ứng dụng cần để đáp ứng xử lý requests là không vượt quá ngưỡng đáp ứng của nodes

Dữ liệu đầu vào được thu thập và đưa vào mô hình Bi-LSTM sau khi đã train để dự đoán được giá trị tiếp theo Dữ liệu sau khi đã tính toán sẽ được đưa vào bộ điều khiển HPA để so sánh với giá trị định trước để quyết định liệu có cần tăng thêm hay giảm đi số lượng replicas cần cung cấp cho hệ thống Cũng tương tự như phương pháp thay đổi tài nguyên cung cấp trên chính máy chủ mà ứng dụng đang hoạt động, việc tăng thêm hay giảm số lượng replicas không làm khởi động lại ứng dụng, tuy nhiên nếu ứng dụng scale down thì cần đảm bảo rằng:

- Những requests mới sẽ không điều hướng tới Kubernetes Pod sẽ bị xóa

- Những requests mà ứng dụng sẽ bị xóa đang xử lý dở cần phải được xử lý trước khi bị xóa hoàn toàn (graceful shutdown)

Hình 15: Mô hình HPA trong quá trình scale hệ thống

Từ nhưng phân tích ở trên thì Horizontal Pods Autoscaling (HPA) là lựa chọn phù hợp cho việc điều khiển phân bổ tài nguyên Ngoài ra HPA cũng cung cấp nhận các dữ liệu được thu thập từ một ứng dụng bất kỳ và dựa trên dữ liệu đó để quyết định tăng thêm hay giảm đi số replicas

Mặc dù Horizontal Pods Autoscaling là phương pháp tiếp cận truyền thống, nhưng điểm khác biệt là dữ liệu được đưa vào để phân tích là dữ liệu được dự đoán từ mô hình Bi-LSTM Do đó, chính dữ liệu sau khi tính toán và xử lý của HPA cũng chính là dữ liệu của tương lai.

Lựa chọn kiểu dữ liệu đầu vào để điều khiển hệ thống

Mỗi hệ thống sẽ có đặc tính tiêu thụ tài nguyên về CPU và Memmory khác nhau và không phải ứng dụng nào cũng đặt tiêu chí về CPU và Memmory cần cung cấp cho một hệ thống là ưu tiên hàng đầu Một số hệ thống yêu cầu quan trọng về khả năng phản hồi tới phía máy khách hoặc số lượng requests tới một hệ thống có khả năng chịu đựng được là bao nhiêu Khi đó, số lượng requests tới hệ thống trong một đơn vị thời gian là yếu tố cần thiết để quyết định cần cung cấp thêm tài nguyên cho hệ thống là bao nhiêu

Trong phạm vi luận văn, dữ liệu đầu vào là dữ liệu server log cũng là dữ liệu liên quan đến requests tới một hệ thống theo đơn vị thời gian Và một mô hình Bi-LSTM được sử dụng để dự đoán lượng tài nguyên cần tiêu thụ trong thời gian tiếp theo là bao nhiêu Và từ dữ liệu dự đoán đó sẽ quyết định liệu có cần cung cấp thêm hay giảm bớt tài nguyên cần cung cấp cho hệ thống

Một số mô hình ứng dụng chạy trong Kubernetes có thể được quan sát và điều khiển số lượng tài nguyên thông qua các controllers như: Horizontal Pod Autoscaler và Cluster Autoscaler Những dữ liệu đầu vào cần cung cấp cho HPA là metrics thu thâp được từ các microservices

Sử dụng CPU và Memmory của microservice để điều khiển quá trình scale của hệ thống:

- Vì dữ liệu đầu vào là dữ liệu HTTP requests, do đó nếu sử dụng scale hệ thống dựa trên CPU và Memmory đòi hỏi phải xây dựng một mối quan hệ giữa CPU, Memory và số lượng requests tới hệ thống

- Cần phải xây dựng một mô hình ứng dụng tiêu thụ CPU và Memory

- Sử dụng trực tiếp số lượng HTTP requests để điều khiển tài nguyên cần cung cấp cho hệ thống

- Phương án này sử dụng trực tiếp HTTP requests làm thông số đầu vào trong việc quyết định scaling của một microservices

- Một số hệ thống tiêu thụ nhiều Memory hoặc/và CPU có thể không phù hợp với phương án này

Việc sử dụng phương án HTTP requests như một dữ liệu đầu vào giảm được việc xây dựng mối quan hệ giữa CPU và Memory tương ứng với lượng requests đầu vào Tuy

20 nhiên, cần phải đảm bảo được ứng mới ngưỡng HTTP requests thì hệ thống vẫn đáp ứng được và tiếp tục hoạt động bình thường

Vì số phương án scale hệ thống để cung cấp tài nguyên nhằm đáp ứng yêu cầu xử lý của hệ thống sử dụng Horizontal Pod Autoscaling và tập dữ liệu được đưa vào trong quá trình học máy là liên quan đến số lượng HTTP requests cũng nhưng những thông số liên quan đến requests vào một hệ thống Do mô hình sẽ sử dụng HTTP requests như một dữ liệu để HPA quyết định tăng thêm hay giảm bớt số lượng replicas của một microservice cụ thể Thông số HTTP requests là thông số mà mô hình Bi-LSTM controller dự đoán

THU THẬP DỮ LIỆU VÀ XỬ LÝ DỮ LIỆU ĐẦU VÀO

Xây dựng mô hình thu thập dữ liệu World Cup dataset

Tập dữ liệu đầu vào có chứa những dữ liệu requests của World Cup năm 1998 từ 30 tháng 4 đến 26 tháng 7 năm 1998 Trong khoảng thời gian đó, số lượng requests mà website nhận được lên đến 1,352,804,107 requests

Dữ liệu thu thập ban đầu dưới dạng log format dẫn đến kích thước dữ liệu là rất lớn, do đó log file đã được chuyển thành dữ liệu dưới dạng binary format Format của dữ liệu: struct requests

{ uint32_t timestamp; uint32_t clientID; uint32_t objectID; uint32_t size; uint8_t method; uint8_t status; uint8_t type; uint8_t server;

- Timestamp: là thời gian của requests gửi đến server theo Epoch và được chuyển đổi thành GMT Trong quá trình trận đấu diễn ra, địa điểm diễn ra trận đấu là trước 2 tiếng GMT +2

- ClientID: một ID riêng biệt để phân biệt các máy khách khác nhau, mỗi client_id sẽ được xác định tương ứng với một địa chỉ IP của phía máy khách Tuy nhiên, để tránh nhiễu và không cần thiết do đó địa chỉ IP đã được chuyển đổi thành client_id

- ObjectID: ID riêng biệt nhằm xác định đường dẫn requestsed URL

- Size: số byte phản hồi từ server khi client thực hiện một requests

- Method: method được sử dụng bởi client (ví dụ: GET, POST, …)

- Status: có chứa hai thành phần HTTP version và status code phản hồi từ phía máy chủ

- Type: kiểu dữ liệu được requests từ phía client dữ liệu kiểu dữ liệu này được thể hiện ở các dạng khác nhau và có thể dưới dạng HTML, IMAGE, v.v… nhìn chung requests có hai dạng dưới dạng html hoặc dưới dạng requests động (DYNAMIC requests) Nếu requests kết thúc với ‘/’ thì nó được xem như một đường dẫn DIRECTORY

- Server: chỉ ra máy chủ nào đã xử lý requests đó Trong đó có 3 bits chỉ ra vị trí đặt server ví dụ như SANTA CLARA, PLANO, HERNDON, PARIS

Trong quá trình thu thập dữ liệu, có tổng cộng 33 máy chủ khác nhau tại bốn khu vực: Paris, France; Plano, Texas; Herndon, Virginia; và Santa Clara, California Tuy nhiên, không phải máy chủ nào cũng hoạt động toàn thời gian trong thời gian thu thập dữ liệu log Độ phân giải của dữ liệu thu thập được tính trên đơn vị giây và thời gian trên mỗi máy chủ được xác định với local time ở Pháp (GMT + 2) Số lượng requests là 1.352.804.107 từ website World Cup và trong 88 ngày từ ngày 10 tháng 4 năm 1998 đến ngày 26 tháng 7 năm 1998 Mặc dù không có dữ liệu nào đề cập đến số lượng requests không được Log, hệ thống luôn hoạt động toàn thời gian trong quá trình diễn ra World Cup

Xử lý dữ liệu ETL

Việc xử lý dữ liệu ETL là quá trình bao gồm Extract, Transform và Load Nó là quá trình được sử dụng cho data warehouse từ các nguồn dữ liệu đầu vào khác nhau Đối với dạng dữ liệu World Cup được chia ra làm 3 giai đoạn chính:

- Giai đoạn 1: quá trình trích xuất dữ liệu, nhằm mục đích trích xuất dữ liệu từ các nguồn khác nhau như transaction, spreadsheets hay flat file Quá trình này sẽ bao gồm quá trình đọc dữ liệu từ các hệ thống đầu vào và lưu trữ ở staging area Mục đích của việc lưu trữ dữ liệu để trích xuất ở staging area là vì việc xử lý tập dữ liệu dạng thô sẽ rủi ro và có thể bị vấn đề trong quá trình xử lý Do đó, dữ liệu thô không nên được lưu trữ ở trong data warehouse để tránh các rủi ro và rollback

- Giai đoạn 2: là giai đoạn chuyển đổi dữ liệu, dữ liệu đã được trích xuất sẽ được chuyển đổi thành các format phù hợp với việc tải lên data warehouse Trong giai đoạn này một tập các hàm và các rule được đặt ra nhằm mục đích chuyển đổi dữ liệu Quá trình này bao gồm:

▪ Chuyển đổi dữ liệu từ dạng binary sang dữ liệu dạng log format

▪ Làm sạch dữ liệu để loại bỏ các dữ liệu bị nhiễu và các dữ liệu không đồng bộ về kiểu

▪ Thêm các trường dữ liệu liên quan, đối với việc training cho dữ liệu cho World Cup sử dụng log file có thể là chưa đủ vì yếu tố liên quan đến thời điểm diễn ra trận đấu cũng ít nhiều ảnh hưởng trực tiếp đến số lượng requests tới một hệ thống chiếu phim

▪ Chuyển đổi dữ liệu thành kiểu dữ liệu khác, trong trường hợp này dữ liệu có thể được lưu trữ ở dạng CSV hoặc dưới dạng Apache

- Giai đoạn 3: dữ liệu sau khi đã chuyển đổi và thực hiện các kỹ thuật với tập dữ liệu sẽ được lưu ở một nơi lưu trữ (Data Warehouse)

Trong giai đoạn 2, bởi vì dữ liệu dataset được chia nhỏ và lưu dưới dạng binary sau đó nén với định dạng gz, do đó tập dữ liệu cần được chuyển đổi thành dạng log format và xử lý dữ liệu trước khi dữ liệu được đưa vào cho mục đích training model Tuy nhiên, vì lượng

23 dữ liệu sau khi giải nén và chuyển đổi dưới dạng log có kích thước rất lớn nên cần phải xây dựng một mô hình nhằm mục đích xử lý tập dữ liệu và lưu trữ dữ liệu

Hình 16: Mô hình xử lý dữ liệu ETL

Một máy chủ (EC2 instance) được sử dụng để xử lý dữ liệu dạng binary và đẩy lên data lake (Amazon S3) nhằm mục đích lưu trữ đồng thời cũng dễ dàng trong việc chuyển đổi dữ liệu giữa các trung tâm xử lý khác nhau Tuy nhiên, log file format có thể không phù hợp với training model trong machine learning bởi vì log file thường có format không theo cấu trúc và khó để parse dữ liệu, và có thể có chứa hỗn hợp của kết hợp giữa dạng số và không phải dạng số (a mixture of numeric and non-numeric data) Việc chuyển đổi log files sang định dạng có cấu trúc giống như CSV hoặc Apache Parquet là cần thiết trong việc chuẩn bị dữ liệu log cho quá trình training trong machine learning

24 Trong quá trình chuyển đổi log files sang một dạng có cấu trúc, chúng ta có thể thực hiện các hoạt động như: extract relevant features, clean the data, và xử lý các thông tin bị thiếu và không chính xác Ngoài ra log file format cũng yêu cầu việc lưu trữ cao và tài nguyên để xử lý dữ liệu Do đó, CSV, Apache Parquet hoặc Apache Avro có thể giúp việc nén và truy vấn dữ liệu một cách hiệu quả

Quá trình chuyển đổi dữ liệu sẽ thông qua các bước:

Bước 1: Làm sạch dữ liệu, vì dữ liệu là dữ liệu dạng server log do đó format dạng

Apache Log, mặc dù dữ liệu có thể cùng kiểu đối với các trường dữ liệu, một số hàng sẽ tồn tại các ký tự đặc biệt ‘-‘ trong log file, ví dụ:

Hình 17 Tập dữ liệu Apache Log chứa các dữ liệu lỗi

Xác định mối tương quan giữa các tham số đầu vào

Phân tích và xử lý dữ liệu đa chiều (hay còn gọi là dữ liệu không gian) là quá trình phân tích và xử lý dữ liệu có tính chất không chỉ có các đặc trưng dạng số mà còn bao gồm các thông tin không gian như vị trí, hướng, kích thước, màu sắc, v.v

Việc phân tích và xử lý dữ liệu đa chiều là cần thiết cho mô hình học máy vì nó cho phép mô hình có thể hiểu và sử dụng các thông tin không gian để đưa ra dự đoán chính xác hơn Ví dụ, trong ứng dụng nhận dạng khuôn mặt, các thông tin không gian như vị trí của các đặc trưng khuôn mặt (mắt, mũi, miệng) cũng có vai trò quan trọng trong việc xác định danh tính của người đó Nếu không có việc xử lý thông tin không gian này, mô hình sẽ không thể phân biệt các khuôn mặt với nhau một cách chính xác

Ngoài ra, phân tích và xử lý dữ liệu đa chiều cũng giúp giảm chiều dữ liệu (dimensionality reduction) để giảm thiểu sự phức tạp của mô hình và tăng tốc độ tính toán

Ví dụ, khi xử lý ảnh, các thuật toán như PCA, LDA, SVD, v.v… được sử dụng để giảm số lượng đặc trưng và giữ lại những đặc trưng quan trọng nhất cho mô hình

Phương pháp phân tích dữ liệu đa chiều (multivariate data analysis) có thể được sử dụng để đánh giá dữ liệu đầu vào của mô hình Bi-LSTM, dữ liệu time series data Bởi vì trong thực tế, dữ liệu thời gian thường liên quan đến nhiều biến độc lập (independent variables) và mô hình Bi-LSTM cũng có thể được sử dụng để dự đoán nhiều biến phụ thuộc (dependent variables) cùng lúc

Phương pháp phân tích dữ liệu đa chiều có thể giúp phân tích mối quan hệ giữa các biến độc lập và biến phụ thuộc, từ đó đưa ra các thông tin quan trọng để cải thiện hiệu suất của mô hình Bi-LSTM Các phương pháp phân tích dữ liệu đa chiều bao gồm phân tích thành phần chính (principal component analysis - PCA), phương pháp phân tích tương quan (correlation analysis), phân tích hồi quy (regression analysis), phân tích đường biên (boundary analysis) v.v…

Ví dụ, phương pháp phân tích thành phần chính (PCA) có thể được sử dụng để giảm chiều dữ liệu (dimensionality reduction) và loại bỏ các biến độc lập không quan trọng, từ đó giảm thiểu tình trạng quá khớp (overfitting) và tăng độ chính xác của mô hình Bi-LSTM Phân tích hồi quy có thể được sử dụng để tìm hiểu mối quan hệ giữa biến độc lập và biến phụ thuộc và đưa ra các thông tin quan trọng để cải thiện hiệu suất của mô hình Bi-LSTM Sau khi đã phân tích và lựa chọn các thông số đầu vào của mô hình Bi-LSTM, với tập dữ liệu như hình:

Hình 42: Dữ liệu đầu vào của mô hình Bi-LSTM

Phân tích dữ liệu PCA

Việc sử dụng phương pháp phân tích thành phần chính (PCA) đối với tập dữ liệu này giúp loại bỏ các biến độc lập và không quan trọng Ngoài ra cũng cho ta biết được mối quan hệ giữa các biến event_count, sum_bytes, và num_match_event Các yếu tố này được xác định dựa trên độ lớn phương sai của ba biến đầu vào Ngoài ra cột event_time sẽ không được sử dụng trong quá trình phân tích PCA do đó nó có thể được lược bỏ trước khi đưa vào tính toán

Hình 43: Dữ liệu mẫu sau khi đã loại bỏ thành phần event_time

Dữ liệu sau khi đã loại bỏ thành phần event_time sẽ chỉ còn lại 3 thành phần: event_count, sum_bytes, và num_match_events Sau đó dữ liệu sẽ chuyển đổi thành dạng ma trận và chuẩn hóa trước khi đưa vào tính toán thành phần chính

Sau khi phân tích và tính toán việc mô phỏng trên đồ thị 3 chiều và 2 chiều đối với PC1, PC2, và PC3 như hình bên dưới

Hình 44: Đồ thị biểu diễn phân tích thành phần chính

Từ đồ thị ở trên ta thấy rằng sự phân phố của dữ liệu theo 3 cụm Đặc biệt sư phân bố càng rõ rệt khi ta thể hiện mối quan hệ giữa PC1 và PC2 trên đồ thị Còn đối với mối quan hệ giữa PC1 và PC3, PC2 và PC3 có xu hướng phân cụm

Hình 45: Đồ thị biểu diện phần trăm của các thành phần chính

Từ Hình 45 ta nhận thấy rằng PC1 chiếm 80% trong khi đó PC2 chỉ chiếm mức khoảng 20% và PC3 chiếm mức rất thấp dưới 5% Tuy nhiên dựa vào đồ thị ở trên rất khó có thể biết được thông số ban đầu nào có đóng góp lớn cho PCA hay những thông số nào ảnh hưởng tới các thành phần chính Do đó chúng ta cần phải xác định được mối quan hệ của thành phần ban đầu tới từng PC

Hình 46: Mối quan hệ của thành phần ban đầu tới từng PC

- Đối với PC1 có mối quan hệ mật thiết với cả ba thành phần event_count, sum_bytes và num_match_event

- Đối với PC2 num_match_event dường như không đóng góp cho PC2 trong khi đó event_count và sum_bytes có sự đóng góp nhưng rất ít

- Đối với PC3 thì chỉ có sum_bytes và event_count đóng góp lớn hơn event_count

Và event_count dường như không có đóng góp cho event_count

Hình 47: Mối quan hệ giữa các thành phần và ảnh hưởng của các thành phần event_count, sum_bytes, và num_match_event ảnh hưởng như thế nào đến các thành phần chính PCA (PC1, PC2, PC3)

48 Đồ thị trên cho thấy được mối quan hệ giữa các thành phần và ảnh hưởng của các thành phần event_count, sum_bytes, và num_match_event ảnh hưởng như thế nào đến các thành phần chính PCA (PC1, PC2, PC3) Ngoài ra từ mô hình ở trên ta có thể nhận xét rằng số lượng requests tới một hệ thống có mối liên hệ mật thiết với tổng số bytes mà máy chủ trả về cho phía máy khách trong một phút Mặc dù số lượng trân đấu diễn ra trong một thời điểm nhất định không quá mật thiết với event_count và sum_bytes, nó cũng có xu hướng như hai thành phần còn lại vì chiều không vượt quá 90 độ giữa num_match_event và hai thành phần còn lại

Phân tích tương quan giúp cho việc đánh giá các đối tượng trong time series data Việc thực hiện đánh giá tương quan biến dữ liệu theo thời gian được thực hiện theo các phương pháp sau:

- Tính toán hệ số tương quan giữa các biến (correlation coefficient): để tính toán hệ số tương quan giữa hai biến có thể sử dụng phương pháp Pearson Correlation coefficient, một phương pháp được sử dụng để đo độ tương quan giữa hai biến

Kết luận

Sau khi xử lý dữ liệu ta sẽ thu được 4 trường dữ liệu: event_time, event_count, sum_bytes, và num_match_event Từ các phân tích dữ liệu đa chiều và tính mối tương quan giữa các giá trị đầu vào của mô hình Bi-LSTM, ta thấy được có sự tương quan mạnh giữa số lượng requests tới một hệ thống và số lượng bytes mà server trả về cho client trong một phút Ngoài ra, mặc dù không có sự tương quan mạnh giữa số lượng requests tới hệ thống và số lượng trận đấu diễn ra tại thời điểm đánh giá cũng như tổng số lượng bytes mà hệ thống trả về và số lượng trận đấu diễn ra, nhưng mối tương quan không tương phản nhau Do đó, 3 biến xem xét có thể được đưa vào tính toán mô hình Bi-LSTM

MÔ HÌNH LSTM VÀ BI-LSTM

Tính số tham số trong mô hình Bi-LSTM

Mô hình Bi-LSTM là sự kết hợp của hai LSTM với cách xử lý dữ liệu ngược nhau Việc xác định số tham số trong mô hình Bi-LSTM giúp cho người train model có thể biết được số dữ liệu cần phải đưa vào Để xác định được tham số đó chúng ta cần hiểu được cấu trúc và cách hoạt động của mô hình Bi-LSTM Do đó, việc đi sâu vào thành phần LSTM gate và gate functions là cần thiết Từ đó có cái nhìn tốt hơn về cách thức mô hình LSTM xử lý dữ liệu đầu vào theo trình tự hoặc theo thứ tự thời gian

Ngoài ra, trong các mô hình ANN, số lượng tham số là một trong những metrics quan trọng để biết được khả năng dự đoán của model cũng như độ phức tạp của model Nó cũng đóng vai trò quan trọng trong việc giải quyết các vấn đề overfitting và underfitting Một trong những cách để có thể giải quyết vấn đề này là điều chỉnh số lượng tham số trong mỗi layer của mô hình

Xác định số thông số trong một Neural Network:

Trong mô hình LSTM tồn tại 4 Dense Layers tương ứng với 4 gates

Hình 53: Mô hình mạng LSTM và các thành phần trong mạng

Từ Hình 53 ta thấy số lượng đầu vào là 3, số lượng hidden state là 30 và cấu trúc của một LSTM cell là:

- ℎ(𝑡 − 1) là giá trị của hidden state trước đó ở timestep t-1

- 𝑐(𝑡 − 1) là giá trị cell state trước đó ở timestep t-1

- 𝑥𝑡 là giá trị input của timestep hiện tại

Ta cũng thấy mô hình LSTM có 4 dense layers tương ứng:

Chiều của input and output được minh họa bằng những hình tròn, trong đó:

- Cell và hidden states có vectors với số chiều là 30 (LSTMoutputDimension = 30)

- Input là một vector có số chiều là 3 Giá trị này cũng được chỉ định bởi cấu hình mạng LSTM để quyết định có bao nhiêu chiều của input Các giá trị đầu vào trong chuỗi phải có chiều là như nhau

- Chiều của hidden cell và cell state vector là như nhau

- Tương tự, chiều của hidden cell và cell state tại thời điểm t-1 cũng như nhau

Mô hình cũng có thể được diễn tả một cách tổng quát hơn thông qua việc biểu diễn dưới dạng ma trận với các input và cell state:

Hình 54: Mạng LSTM được biểu diễn dưới dạng ma trận Đối với forget gate:

Hình 55: Mô hình LSTM biểu diễn các cổng (gates)

Như Hình 55, nếu số chiều input là 30:

- Có 30 giá trị hidden state

- Có 3 giá trị inputs tương ứng với 3 thuộc tính của requests

Do đó, tổng cộng ta sẽ có 33 số là input của một dense layer Output layers sẽ có 30 giá trị và phải tương ứng với số chiều của hidden layer Ta có thể tính toán được số lượng tham số trong dense layer là 1020:

(ℎ 𝑡−1 + 𝑥 𝑡 )ℎ 𝑡−1 + ℎ 𝑡−1 = (30 + 3) ∗ 30 + 30 = 1020 Ngoài ra, mô hình có tổng cộng 4 dense layers nên tổng số lượng tham số sẽ là

1020 𝑥 4 = 4080 Việc xác định số lượng parameters của mô hình LSTM cũng có thể được thực hiện thông qua các định nghĩa về mô hình LSTM Một cell trong LSTM sẽ có tổng cổng 4 cổng:

- 𝑥 𝑡 𝑅 𝑑 : số đơn vị đầu vào của mô hình LSTM

- 𝑖 𝑡 𝑅 ℎ : Input/update gate’s activation vector

- ℎ 𝑡 𝑅 ℎ : Hidden state vector/ output state vector of LSTM

- 𝑊𝑅 ℎ𝑥𝑑 , 𝑈𝑅 ℎ𝑥ℎ 𝑎𝑛𝑑 𝑏𝑅 ℎ : tham số weight matrices and bias vector cần được học trong quá trình training

Chúng ta có thể tính được kích thước của 𝑊, 𝑈 𝑣à 𝑏 thông qua:

Bởi vì output phải bằng với kích thước của hidden state nên các tham số:

Từ mô hình ở trên ta cũng xác định được timesteps (input length) của giá trị input sẽ không ảnh hưởng tới số lượng tham số cần phải tính toán.

Training mô hình Bi-LSTM

Như trình bày ở phần trên, mô hình Bi-LSTM được thực hiện với các tham số như sau: model.add(Bidirectional(LSTM(units8, return_sequences=True), input_shape=(sequence_length, 3))) model.add(Dropout(0.2)) model.add(Bidirectional(LSTM(units8)))

57 model.add(Dropout(0.2)) model.add(Dense(units=1)) model.compile(optimizer='adam', loss='mean_squared_error') early_stop = EarlyStopping(monitor='val_loss', mode='min',verbose=1, restore_best_weights=True, patience )

- Dòng 1: Mô hình LSTM sử dụng bidirectional để tạo Bi-LSTM Mô hình sử dụng giá trị đầu vào có 128 đơn vị và mỗi đơn vị là bước thời gian của chuỗi đầu vào Mô hình đầu vào sử dụng 3 dữ liệu (event_count, sum_bytes, num_match_event)

- Dòng 2 và 4: Mô hình Bi-LSTM được thêm vào một lớp ở giữa (Dropout) giúp giảm và ngăn chặn hiện tượng overfitting bằng cách loại bỏ một phần kết nối giữa các Nơ Ron trong quá trình huấn huyên Trong trường hợp này là 20% kết nối sẽ bị loại bỏ ngẫu nhiên trong quá trình huấn luyện

- Dòng 3: Một lớp Bi-LSTM khác được thêm vào nhưng không trả kết quả về dạng chuỗi mà chỉ trả kết quả cuối cùng

- Dòng 5: Đầu ra của quá trình dự đoán là 1 (Dense 1) đó là kết quả dự đoán event_count

- Dòng 6: Quá trình training Bi-LSTM sử dụng phương pháp Adam để tối ưu và hàm mất mát sử dụng mean_square_error, mô hình sẽ cố gắng tối ưu hoá dựa trên sai số bình phương trung bình

- Dòng 7: Mục đích của hàm là theo dõi và quyết định thời điểm dừng quá trình training, trong trường hợp này nó sẽ theo dõi giá trị “val_loss” Mô hình sẽ tiếp tục train thêm 20 vòng lặp nếu không tìm được giá trị tốt nhất nó sẽ trả về kết quá tốt nhất trước đó Việc này sẽ giúp giảm thời gian huấn luyện mà vẫn cho được kết quả tốt

Quá trình train model Bi-LSTM được thực hiện sử dụng Google Colab, sau khi huấn luyện mô hình Bi-LSTM, mô hình chạy được 92 epoches trong tổng số 100 epoches

Hình 56 Kết quả quá trình train mô hình Bi-LSTM

Hình 56 cho thấy quá trình huấn luyện lấy kết quả ở epoch 72 mặc dù đã chạy hết 92 epoches Do từ epoch 72 đến 92, mô hình không tìm được giá trị tối ưu hơn nên kết quả trả về là giá trị ở epoch 72

Hình 57 Đồ thị biểu diễn kết quả dự đoán và kết quả thực tế khi kiểm thử với dữ liệu validation Đồ thị biểu diễn kết quả giữa thực tế và dự đoán của tập test

Hình 58 Kết quả dự đoán trong một khoảng thời gian

Khi đánh giá độ chính xác của mô hình đối với dữ liệu theo thời gian thì phương pháp MAE (mean absolute error) được xem như một phương pháp phổ biến và thường đẽ sử dụng Tuy nhiên, phương pháp RMSE được tính bằng phương pháp căn bậc hai của bình phương sai số giữa giá trị dự đoán và giá trị thực tế điều đó cho thấy được mức độ tập trung của dữ liệu, trong khi MAE được tính dựa trên giá trị tuyệt đối sai số giữa giá trị đo và giá trị dự đoán Từ công thức xác định MAE và RMSE:

𝑛 Xác định trên tập dữ liệu ta có:

Tập dữ liệu MAE RMSE

Dữ liệu test 174.138 333.523 Để có thể đánh giá được mô hình là tốt tùy thuộc vào nhiều yếu tố liên quan đến lĩnh vực nghiên cứu Tuy nhiên, với tập dữ liệu với giá trị trong khoảng 0 đến 200000 thì giá trị = 2000 thì mới bắt đầu phản ứng lại Hình 102 thể hiện thời điểm số lượng Kubernetes pod tăng từ 2 lên 3 với sai số giữa kết quả dự đoán và kết quả thực tế được thể hiện ở hình 103

Hình 103: Kết quả đo đạc khi sử dụng phương pháp Bi-LSTM với giá trị thu thập

Hình 104: Kết quả đo đạc khi sử dụng phương pháp Bi-LSTM với giá trị dự đoán

Hình 105: Thời điểm sự kiện diễn ra khi sử dụng phương pháp Bi-LSTM

Hình 106: Sai số trung bình thong khoảng thời gian 5 phút

Hình dưới mô tả kết quả đo đạc được khi mô phỏng số lượng requests vào ứng dụng với số requests trong khoảng 20000 mỗi phút Hình 103 thể hiện kết quả thực tế tại thời điểm hệ thống bắt đầu tăng số lượng Kubernetes pods, và hình 104 thể hiện giá trị dự đoán tại thời điểm sự kiện xảy ra Ta nhận thấy rằng hệ thống cũng tiêu tốn 2 phút kể từ khi số lượng requests vào hệ thống >= 2000 thì mới bắt đầu phản ứng lại Hình 104 thể hiện thời điểm số lượng Kubernetes pod tăng từ 2 lên 3 với sai số giữa kết quả dự đoán và kết quả thực tế được thể hiện ở hình 105

Hình 107: Kết quả đo đạc khi sử dụng phương pháp truyền thống với giá trị thu thập

Hình 108: Kết quả đo đạc khi sử dụng phương pháp truyền thống với giá trị dự đoán

Hình 109: Thời điểm sự kiện diễn ra khi sử dụng phương pháp truyền thống

Hình 110: Sai số trung bình trong khoảng thời gian 5 phút sử dụng phương pháp truyền thống

Hình 111: Kết quả đo đạc khi sử dụng phương pháp kết hợp truyền thống và Bi-LSTM trước khi đạt mức 20000

Hình 112: Kết quả đo đạc khi sử dụng phương pháp kết hợp truyền thống và Bi-LSTM khi bắt đầu tăng tài nguyên

Hình 113: Thời điểm sự kiện diễn ra khi sử dụng phương pháp kết hợp truyền thống và Bi-LSTM

Hình 114: Sai số trung bình thong khoảng thời gian 5 phút đối với phương pháp kết hợp

Từ hình 107 đến hình 110 cho thấy, đối với mô hình kết hợp giữa hai phương pháp truyền thống và phương pháp sử dụng Bi-LSTM thì thời gian mà hệ thống bắt đầu tăng thêm tài nguyên khi số lượng requests > 20000 là 1 phút

Hình 115: Tổng quan sự biến thiên về thông số liên quan hệ thống khi kiểm thử với 3 trường hợp

Hình 111 cho thấy rằng, trong toàn thời gian đo đạc, tài nguyên tiêu thụ CPU và Memory vẫn nằm trong khoảng cho phép và dưới mức requests và limit của CPU và Memory Đánh giá thông số được đo đạc với dữ liệu từ năm 1998-06-17 16:01:00

Hình 117 thể hiện khoảng thời gian cần thiết từ khi số lượng requests vào hệ thống bắt đầu lớn hơn 60000 cho đến khi thực sự tăng số lượng requests vào hệ thống (từ 14:40:00 đến 14:45:00) khoảng 5 phút Phương pháp sử dụng trong trường hợp này là Bi-LSTM

Hình 120 thể hiện khoảng thời gian cần thiết từ khi số lượng requests vào hệ thống bắt đầu lớn hơn 60000 cho đến khi thực sự tăng số lượng requests vào hệ thống (từ 17:24:00 đến 17:28:00) khoảng 4 phút Phương pháp sử dụng trong trường hợp này là phương pháp truyền thống

Hình 123: Sai số trung bình trong khoảng thời gian 5 phút sử dụng phương Bi-Lstm

94 Hình 121-123 thể hiện khoảng thời gian cần thiết từ khi số lượng requests vào hệ thống bắt đầu lớn hơn 60000 cho đến khi thực sự tăng số lượng requests vào hệ thống (từ 17:56:00 đến 18:00:00) khoảng 4 phút Phương pháp sử dụng trong trường hợp này là phương pháp Bi-LSTM

Hình 124: Kết quả đo đạc khi sử dụng phương pháp Bi-LSTM trước khi lên 60000

Hình 125: Kết quả đo đạc khi sử dụng phương pháp Bi-LSTM với giá trị thu thập trigger scale

Hình 126: Thời điểm sự kiện diễn ra khi sử dụng phương pháp Bi-Lstm và truyền thống

Hình 127: Sai số trung bình trong khoảng thời gian 5 phút sử dụng phương kết hợp Bi-Lstm và truyền thống

Hình 124-127 thể hiện khoảng thời gian cần thiết từ khi số lượng requests vào hệ thống nhỏ hơn 60000 cho đến khi thực sự tăng số lượng requests vào hệ thống trong 1 phút 18:21:00 Phương pháp sử dụng trong trường hợp này là phương pháp kết hợp giữa phương pháp truyền thống và phương pháp sử dụng Bi-LSTM Đánh giá thông số được đo đạc với dữ liệu từ năm 1998-06-19 16:03:00

Hình 128-130 đánh giá kết quả phản ứng của hệ thống khi sử dụng phương pháp truyền thống Ta nhận thấy rằng trong toàn khoảng thời gian thì hệ thống không phản ứng với quá trình scale và số lượng Kubernetes Pod vẫn dừng ở mức 5

Hình 131: Kết quả đo đạc khi sử dụng phương pháp Bi-Lstm với giá trị thu thập

Hình 133: Thời điểm sự kiện diễn ra khi sử dụng phương pháp Bi-Lstm

Hình 131-133 thể hiện được khoảng thời gian từ lúc số lượng requests với hệ thống bắt đầu tăng trên 50000 và lúc hệ thống bắt đầu phản ứng là 2 phút từ 2023-05-29 00:35:00 đến 2023-05-29 00:37:00

Hình 134: Thời điểm sự kiện xảy ra với số lượng Kubernetes pod

Hình 135: Kết quả đo đạc sử dụng phương pháp kết hợp

Hình 136: Sai số trung bình trong khoảng thời gian 5 phút sử dụng phương pháp kết hợp

97 Hình 134-136 thể hiện được khoảng thời gian từ lúc số lượng requests với hệ thống bắt đầu tăng trên 50000 và lúc hệ thống bắt đầu phản ứng là 1 phút thời điểm 2023-05-29 00:58:00 Đánh giá thông số được đo đạc với dữ liệu từ năm 1998-06-10 20:51:00 đối với trường hợp giảm số lượng Kubernetes Pods

Hình 137: Phương pháp truyền thống thời điểm số Pod từ 8 bắt đầu giảm về 7

Hình 140: Phương pháp truyền thống số lượng requests tại thời điểm số pod từ 8 về 7

Hình 143: Phương pháp truyền thống sai số trung bình trong 5 phút tại thời điểm đánh giá

Hình dưới thể hiện kết quả đánh giá về khả năng giảm tài nguyên cho hệ thống khi sử dụng mô hình Bi-LSTM để đánh giá

Hình 144: Phương pháp Bi-LSTM thời điểm số Pod từ 8 bắt đầu giảm về 7

Hình 147: Phương pháp Bi-LSTM số lượng requests tại thời điểm số pod từ 8 về 7

Hình 150: Phương pháp Bi-LSTM sai số trung bình trong 5 phút tại thời điểm đánh giá

Hình 151: Phương pháp kết hợp thời điểm số Pod từ 8 bắt đầu giảm về 7

Hình 154: Phương pháp kết hợp số lượng requests tại thời điểm số pod từ 8 về 7

Hình 157: Phương pháp kết hợp sai số trung bình trong 5 phút tại thời điểm đánh giá

Hình 158: Tài nguyên tiêu thụ CPU trong toàn thời gian đánh giá

Hình 159: Tài nguyên tiêu thụ Memory trong toàn thời gian đánh giá

Từ các kết quả đo đạc ở trên cho thấy thông số đo đạc tại thời điểm 1998-06-10 20:51:00 trong quá khứ:

Phương pháp Khoảng thời gian số pod từ 8 về 7

Khoảng thời gian số pod từ 7 về 6

Bảng 4: Thông số đo đạc đánh giá hệ thống tại thời điểm 1998-06-10 20:51:00

Với phương pháp đo đạc như đề cập ở trên, luận văn thực hiện việc đo đạc trong các khoảng thời gian:

Hình 160: Kiểm thử khả năng scale với các khoảng thời gian khác nhau

Từ đồ thị trên cho ta thấy phương pháp kết hợp giữa mô hình truyền thống và mô hình sử dụng Bi-LSTM cho kết quả tốt hơn rất nhiều và khả năng phản ứng đối với sự thay đổi là trong một phút Ngoài ra, phương pháp sử dụng Bi-LSTM tuy không cho kết quả tối ưu

103 nhưng cũng đóng góp hiệu quả trong việc dự đoán và điều khiển Trong 7 lần kiểm thử thì số lần Bi-LSTM dự đoán sớm hơn 57%

NHẬN XÉT VÀ KẾT LUẬN

Luận văn đã xây dựng hệ thống sử dụng Kubernetes và Amazon Web Service Hệ thống này áp dụng phương pháp proactive autoscaler và sử dụng mô hình học máy Bi-LSTM để tính toán, dự đoán số lượng yêu cầu (requests) tới hệ thống trong khoảng thời gian tiếp theo Giá trị dự đoán sẽ được sử dụng để quyết định tài nguyên mà hệ thống cần cung cấp hay giảm bớt để duy trì tính ổn định của hệ thống Luận văn đã:

- Xác định tập dữ liệu đầu vào và xây dựng phương án xử lý dữ liệu nhiễu

- Xây dựng mô hình học máy sử dụng Bi-LSTM với dữ liệu đầu vào đã xử lý, để dự đoán giá trị trong thời gian một phút tiếp theo

- Mô hình thực nghiệm nhằm đo đạc, dự đoán số lượng yêu cầu (requests) vào hệ thống trong một phút tiếp theo Kết quả dự đoán được sử dụng để điều khiển tài nguyên CPU và Memory, đảm bảo hệ thống hoạt động ổn định khi số lưu lượng truy cập vào hệ thống biến đổi Đối với dữ liệu đầu vào, các kỹ thuật tiền xử lý dữ liệu được thực hiện Xác định mối tương quan giữa các dữ liệu đầu vào và loại bỏ các thành phần dữ liệu nhiễu Hơn nữa, mối tương quan của các dữ liệu đầu vào cũng được xây dựng dựa trên các kỹ thuật phân tích tương quan và phân tích thành phần chính Mô hình Bi-LSTM được sử dụng trong quá trình huấn luyện với tập dữ liệu đầu vào là World Cup 1998 Phân tích tính hiệu quả của quá trình training bằng cách đánh giá kết quả dự đoán và kết quả thực tế của tập dữ liệu test và validation set Dữ liệu từ ứng dụng chạy trong Kubernetes được thu thập bằng Prometheus và Istio Service Mesh Sau đó, bộ điều khiển tài nguyên CPU và Memory sử dụng dữ liệu này từ Prometheus làm dữ liệu đầu vào

Từ những kết quả thực nghiệm và kết quả đo đạc được từ mô hình mô phỏng, luận văn đưa ra các kết luận như sau:

- Mô hình sử dụng Bi-LSTM là một phương pháp đo quan trọng trong việc dự đoán tài nguyên cần cung cấp cho hệ thống Dù không được sử dụng trong quá trình điều khiển, nó vẫn mang lại xu hướng và giá trị dự đoán Điều này hỗ trợ người vận hành trong việc dự đoán hành vi của lưu lượng truy cập trong tương lai gần

- Kết hợp giữa phương pháp truyền thống, phương pháp sử dụng Bi-LSTM và áp dụng mô hình toán trong quá trình dự đoán đã cho thấy khả năng phản ứng nhanh hơn so với cả phương pháp truyền thống và phương pháp sử dụng Bi-LSTM độc lập Tuy nhiên, sự kết hợp giữa hai mô hình này có thể không giải quyết hoàn toàn các vấn đề liên quan đến chi phí

Luận văn chỉ sử dụng một tập dữ liệu đầu vào và tiến hành phân tích thực nghiệm trên tập dữ liệu đó Do vậy, mô hình dự đoán Bi-LSTM, sau khi được huấn luyện với các tham số cụ thể, có thể không phù hợp với kiểu dữ liệu khác Hơn nữa, thực nghiệm để đánh giá hiệu quả của mô hình dự đoán và bộ điều khiển chỉ được thực hiện trên các khoảng thời gian nhất định, dẫn đến độ tin cậy của kết quả đánh giá không cao

Trong quá trình thực hiện luận văn, hai hướng nghiên cứu phát triển được đề xuất:

- Chú trọng vào xây dựng mô hình học máy nhằm nâng cao độ chính xác trong việc dự đoán lưu lượng truy cập Đồng thời, việc thực nghiệm và đánh giá nên được thực hiện trên nhiều tập dữ liệu

- Mô hình dự đoán và điều khiển trong luận văn được thực hiện bằng cách sử dụng mô hình đã học Tuy nhiên, trong thực tế, dữ liệu huấn luyện có thể không còn chính xác với dữ liệu hiện tại Do đó, cần thiết phải có một phương pháp huấn luyện mô hình liên tục với tập dữ liệu mới Để thực hiện điều này, nghiên cứu về streaming data và xây dựng một mô hình thu thập dữ liệu theo thời gian thực và áp dụng phương pháp huấn luyện liên tục cho mô hình BI-LSTM sẽ được thực hiện

Tiêu đề	Hệ Thống Đề Xuất Tài Nguyên Kubernetes
Tác giả	Phan Đình Khánh
Người hướng dẫn	PGS.TS. Thoại Nam
Trường học	Đại học Quốc gia TP. HCM
Chuyên ngành	Khoa Học Máy Tính
Thể loại	Luận văn thạc sĩ
Năm xuất bản	2023
Thành phố	Hồ Chí Minh

Định dạng
Số trang	116
Dung lượng	4,39 MB