ĐẠI HỌC QUỐC GIA TP. HCM
TRƯỜNG ĐẠI HỌC BÁCH KHOA
--------------------
PHAN ĐÌNH KHÁNH
HỆ THỐNG ĐỀ XUẤT TÀI NGUYÊN KUBERNETES
Chuyên ngành: Khoa Học Máy Tính
Mã số: 8480101
LUẬN VĂN THẠC SĨ
TP. HỒ CHÍ MINH, tháng 07 năm 2023
CƠNG TRÌNH ĐƯỢC HỒN THÀNH TẠI
TRƯỜNG ĐẠI HỌC BÁCH KHOA -ĐHQG -HCM
Cán bộ hướng dẫn khoa học: PGS.TS. Thoại Nam
Cán bộ chấm nhận xét 1: TS. Nguyễn Lê Duy Lai
Cán bộ chấm nhận xét 2: PGS.TS. Trần Công Hùng
Luận văn thạc sĩ được bảo vệ tại Trường Đại học Bách Khoa, ĐHQG Tp. HCM
ngày 13 tháng 07 năm 2023.
Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm:
1. PGS.TS. Trần Văn Hoài
- Chủ tịch hội đồng
2. TS. Lê Thành Sách
- Thư ký
3. TS. Nguyễn Lê Duy Lai
- Phản biện 1
4. PGS.TS. Trần Công Hùng - Phản biện 2
5. PGS.TS. Lê Trung Quân
- Uỷ viên
Xác nhận của Chủ tịch Hội đồng đánh giá LV và Trưởng Khoa quản lý chuyên
ngành sau khi luận văn đã được sửa chữa (nếu có).
CHỦ TỊCH HỘI ĐỒNG
TRƯỞNG KHOA
KHOA HỌC VÀ KỸ THUẬT MÁY TÍNH
ĐẠI HỌC QUỐC GIA TP.HCM
CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
TRƯỜNG ĐẠI HỌC BÁCH KHOA
Độc lập - Tự do - Hạnh phúc
NHIỆM VỤ LUẬN VĂN THẠC SĨ
Họ tên học viên : Phan Đình Khánh
MSHV : 2070412
Ngày, tháng, năm sinh : 06/11/1995
Nơi sinh : Đắk Nông
Chuyên ngành : Khoa Học Máy Tính
Mã số : 8480101
I. TÊN ĐỀ TÀI : Hệ Thống Đề Xuất Tài Nguyên Kubernetes / Kubernetes Resource
Recommandation System
II. NHIỆM VỤ VÀ NỘI DUNG : Lựa chọn phương án thu thập và xử lý dữ liệu. Sử dụng
mơ hình học máy để dự đoán tài nguyên liên quan đến số lượng truy cập (requests), CPU
và Memory vào hệ thống. Xây dựng mơ hình thu thập dữ liệu và điều khiển tài nguyên
cho ứng dụng chạy trong Kubernetes và Amazon Web Service nhằm mục đích đánh giá
cơ sở lý thuyết và tính hiệu quả của mơ hình dự đốn.
III. NGÀY GIAO NHIỆM VỤ : 06/02/2023
IV. NGÀY HOÀN THÀNH NHIỆM VỤ : 11/06/2023
V. CÁN BỘ HƯỚNG DẪN : PGS.TS. Thoại Nam
Tp. HCM, ngày tháng năm 2023
CÁN BỘ HƯỚNG DẪN
HỘI ĐỒNG NGÀNH
(Họ tên và chữ ký)
(Họ tên và chữ ký)
TRƯỞNG KHOA KHOA HỌC VÀ KỸ THUẬT MÁY TÍNH
(Họ tên và chữ ký)
i
LỜI CÁM ƠN
Đầu tiên em xin chân thành cám ơn đến thầy PGS.TS Thoại Nam. Thầy đã cho em cơ
hội được tham gia và tìm hiểu đề tài. Quan trọng hơn hết em xin cám ơn thầy đã định hướng
phạm vi nghiên cứu, hướng dẫn và đưa ra những đóng góp, gợi ý q giá để em có thể
hồn thành luận văn tốt nghiệp và có cơ hội được nâng cao kiến thức khơng chỉ trong q
trình học tập mà cịn giúp ích cho cơng việc.
Em xin gởi lời cám ơn đến kỹ sư Hạ Xn Kỳ vì những góp ý và giúp đỡ tận tình của
bạn, về các vấn đề liên quan đến cơ sở lý thuyết và giải thuật học máy cũng như các phương
án xử lý dữ liệu đầu vào, trong suốt quá trình thực hiện đề tài luận văn.
Cuối cùng xin cám ơn gia đình đặc biệt vợ người đã đồng hành, luôn động viên và tạo
điều kiện tốt nhất để em có thêm động lực để hồn thành tốt luận văn tốt nghiệp.
TP. HỒ CHÍ MINH, tháng 07 năm 2023
ii
TĨM TẮT LUẬN VĂN
Hiện nay, mơi trường điện tốn đám mây đang được sử dụng phổ biến cho các ứng dụng
web [1]. Trong môi trường này, Kubernetes (EKS, GKE, v.v...) được sử dụng để chạy ứng
dụng và cung cấp khả năng tự động phân bổ tài nguyên CPU và Memory dựa trên nhu cầu
của ứng dụng. Phương pháp được áp dụng là reactive autoscaling, trong đó một bộ điều
khiển sẽ điều chỉnh việc cung cấp tài nguyên bằng cách tăng hoặc giảm chúng dựa trên các
ngưỡng đã được thiết lập trước đó và theo các luật đã được định sẵn.
Luận văn đã xây dựng mơ hình dự đốn dựa trên Kubernetes và chạy trên nền tảng
Amazon Web Service. Mơ hình này có khả năng chủ động phân bổ tài nguyên cho các ứng
dụng chạy trong các container, được gọi là proactive autoscaler, và sử dụng mơ hình học
sâu (Bi-directional Long Short-term Memory) để thực hiện dự đoán. Luận văn tập trung
vào việc xây dựng mơ hình Bi-LSTM để dự đốn lưu lượng truy cập đến hệ thống trong
một khoảng thời gian tiếp theo. Mơ hình sử dụng Prometheus và Istio Service Mesh để thu
thập dữ liệu và mô phỏng, nhằm hỗ trợ q trình dự đốn và kiểm thử.
Luận văn đã tiến hành đánh giá sự khác biệt khi sử dụng mơ hình proactive autoscaler
(sử dụng Bi-LSTM) so với phương pháp reactive autoscaler truyền thống. Ngoài ra, luận
văn cũng đã thành cơng trong việc xây dựng một mơ hình kết hợp giữa phương pháp truyền
thống, phương pháp sử dụng Bi-LSTM và phương pháp toán học, nhằm tăng cường hiệu
quả của mơ hình dự đốn.
Qua phân tích và so sánh kết quả dự đốn và kết quả thực tế giữa tính toán lý thuyết và
thực nghiệm, nhận thấy phương pháp proactive autoscaler sử dụng Bi-LSTM đạt hiệu suất
dự đoán tốt hơn so với phương pháp reactive autoscaling. Phương pháp proactive
autoscaler có khả năng dự đốn đạt tỷ lệ chính xác 57%, trong khi phương pháp reactive
autoscaling chỉ đạt tỷ lệ 43%. Đáng chú ý, việc sử dụng mơ hình kết hợp giữa các phương
pháp truyền thống và phương pháp sử dụng Bi-LSTM cải thiện hiệu suất của q trình dự
đốn và điều khiển tài nguyên CPU và Memory. Luận văn cũng cung cấp một hệ thống và
giải pháp mô phỏng, nhằm thu thập dữ liệu để hỗ trợ cho các nghiên cứu tương lai tập trung
vào việc nghiên cứu sâu hơn về mơ hình dự đốn. Hệ thống và giải pháp này mang lại
những kết quả đáng chú ý, và từ những kết quả này, luận văn đề xuất các hướng phát triển
tiếp theo cho đề tài nghiên cứu này.
iii
ABSTRACT
Currently, cloud computing environment is widely used for web applications [1]. In this
environment, Kubernetes (EKS, GKE, etc.) is used to run applications and provides
automatic allocation of CPU and Memory resources based on application demands. The
applied method is reactive autoscaling, where a controller adjusts resource provisioning by
increasing or decreasing them according to pre-established thresholds and predefined rules.
The thesis developed a prediction model based on Kubernetes and deployed on the
Amazon Web Services platform. This model, known as proactive autoscaler, has the
capability to dynamically allocate resources to applications running in containers. It utilizes
a deep learning model called Bi-directional Long Short-term Memory (Bi-LSTM) for
making predictions. The thesis focuses on building the Bi-LSTM model to predict the
incoming traffic to the system within a future time window. Prometheus and Istio Service
Mesh are employed to collect data and simulate scenarios, supporting the prediction
process and testing.
Furthermore, the thesis evaluated the difference between using the proactive autoscaler
(using Bi-LSTM) and the traditional reactive autoscaling approach. Additionally, it
successfully constructed a combined model that incorporates the traditional method, the
Bi-LSTM method, and mathematical techniques to enhance the effectiveness of the
prediction model.
Through analysis and comparison of the predicted results with the actual outcomes,
considering both theoretical calculations and experimental data, it was observed that the
proactive autoscaling method using Bi-LSTM achieved better prediction performance than
the reactive autoscaling method. The proactive autoscaler demonstrated an accuracy rate
of 57%, while the reactive autoscaling method achieved only 43%. Notably, the utilization
of a combined model incorporating traditional methods and the Bi-LSTM approach
improved the performance of both prediction and resource control processes, specifically
CPU and Memory resources. The thesis also provided a system and simulation solution for
data collection, which can support future research endeavors focused on further exploring
prediction models. The system and solution yielded significant results, and based on these
findings, the thesis proposes future directions for the advancement of this research topic.
iv
LỜI CAM ĐOAN
Luận văn thạc sĩ “Hệ Thống Đề Xuất Tài Nguyên Kubernetes” là kết quả quá trình học
tập và nghiên cứu dưới sự hướng dẫn của giáo viên hướng dẫn: PGS.TS. Thoại Nam. Ngồi
ra, khơng có bất cứ sự sao chép của người khác. Đề tài, nội dung báo cáo luận văn là sản
phẩm mà em đã nỗ lực nghiên cứu trong quá trình học tập tại trường. Các số liệu, kết quả
trình bày trong báo cáo được thu thập từ mơ hình hệ thống là trung thực, khơng có sự sao
chép từ các cơng trình nghiên cứu khác.
TP. HỒ CHÍ MINH, tháng 07 năm 2023
Họ tên và chữ ký
v
MỤC LỤC
NHIỆM VỤ LUẬN VĂN THẠC SĨ ...................................................................................................... i
LỜI CÁM ƠN ........................................................................................................................................ ii
TÓM TẮT LUẬN VĂN ....................................................................................................................... iii
ABSTRACT .......................................................................................................................................... iv
LỜI CAM ĐOAN ...................................................................................................................................v
TỪ VIẾT TẮT ..................................................................................................................................... vii
CHƯƠNG 1: PHẠM VI ĐỀ TÀI......................................................................................................1
1.1 Tổng quan ...................................................................................................................................1
1.2 Sơ lược về tình hình nghiên cứu .................................................................................................2
1.2.1 Phương pháp reactive ........................................................................................................2
1.2.2 Phương pháp proactive......................................................................................................4
1.3 Bài toán nghiên cứu....................................................................................................................6
1.4 Bố cục luận văn ..........................................................................................................................7
CHƯƠNG 2:
LỰA CHỌN PHƯƠNG ÁN .......................................................................................8
2.1 Lựa chọn mơ hình dự đốn tải của hệ thống ..............................................................................8
2.1.1 Mơ hình ARIMA:..............................................................................................................8
2.1.2 Mơ hình LSTM: ................................................................................................................9
2.1.3 Mơ hình Bi-LSTM: .........................................................................................................10
2.1.4 Kết luận ...........................................................................................................................11
2.2 Lựa chọn phương pháp thu thập và đo đạc dữ liệu ..................................................................11
2.2.1 Thu thập log data và metrics sử dụng AWS Cloudwatch ...............................................14
2.2.2 Thu thập log data và metrics sử dụng Prometheus..........................................................15
2.2.3 Thu thập log data và metrics sủ dụng ElasticSearch .......................................................16
2.2.4 Kết luận ...........................................................................................................................17
2.3 Lựa chọn phương án điều khiển hệ thống ................................................................................18
2.4 Lựa chọn kiểu dữ liệu đầu vào để điều khiển hệ thống ............................................................19
CHƯƠNG 3:
THU THẬP DỮ LIỆU VÀ XỬ LÝ DỮ LIỆU ĐẦU VÀO ....................................21
3.1 Xây dựng mơ hình thu thập dữ liệu World Cup dataset ...........................................................21
3.1.1 Tiền xử lý dữ liệu đầu vào ..............................................................................................29
3.1.2 Xây dựng features cho số lượng trận đấu diễn ra trong interval time .............................33
3.1.3 Phân tích dữ liệu sau khi đã tổng hợp .............................................................................34
3.2 Xác định mối tương quan giữa các tham số đầu vào ...............................................................42
3.3 Kết luận ....................................................................................................................................51
CHƯƠNG 4:
MƠ HÌNH LSTM VÀ BI-LSTM ............................................................................52
4.1 Tính số tham số trong mơ hình Bi-LSTM .................................................................................53
4.2 Training mơ hình Bi-LSTM ......................................................................................................56
4.3 Xây dựng hệ thống kiểm thử mơ hình Bi-LSTM .......................................................................61
CHƯƠNG 5: ĐÁNH GIÁ KẾT QUẢ HỆ THỐNG ĐỀ XUẤT TÀI NGUYÊN.........................89
CHƯƠNG 6: NHẬN XÉT VÀ KẾT LUẬN.................................................................................104
TÀI LIỆU THAM KHẢO .................................................................................................................106
PHẦN LÝ LỊCH TRÍCH NGANG ...................................................................................................107
vi
TỪ VIẾT TẮT
Từ viết tắt
Mô tả
CPU
Bộ xử lý
Memory
Bộ nhớ
LSTM
Long Short-Term Memory
BI-LSTM
Bi-directional Long Short-Term Memory
ARIMA
Autoregressive Integrated Moving Average
OS
Hệ điều hành
OS kernel
Nhân hệ điều hành
HPA
Horizontal Pod Autoscaler
RPPS
Resource Prediction and Provisiong Scheme
PCA
Principal Component Analysis
SLAs
Service-Level Agreements
AR
Autoregression
MA
Moving Average
RNN
Recurrent Neural Network
API
Application Programming Interface
AWS
Amazon Web Service
YACE
Yet Another CloudWatch Exporter
ILM
Index lifecycle management
RMSE
Root-mean-square deviation
MAE
Mean Absolute Error
vii
CHƯƠNG 1: PHẠM VI ĐỀ TÀI
1.1 Tổng quan
Trong môi trường Cloud Computing, cơng nghệ ảo hố 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 hố 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 hố 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 hố 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ự đố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ự đố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ự đố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… .
1
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ự
đố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.
1.2 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ự đố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.
1.2.1 Phương pháp reactive
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à
2
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 tố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 tốn tài ngun 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.
3
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.
Ngồi mơ hình ARIMA cho mục đích dự đố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.
1.2.2 Phương pháp proactive
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ó
4
ư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.
Paper
Virtualization
Monitored
Metrics
Method
Technology
Nhat-Minh Dang Quang et al,
2021, [1]
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
CPU
Proactive
Bi-LSTM
Xuehai Tang et al., 2018, [12] Container
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ự đốn tài ngun 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 tố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ự
đố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ự đố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 Bidirection 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ử
5
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ự đố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ự đố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ự đốn thấp hơn so với các mơ hình như ARIMA, LSTM, và RNN.
Hiện nay, hầu hết các phương án thực tế đang dựa trên mơ hình reactive và sử dụng các
điều kiện để kích hoạt q trình scaling của hệ thống. Mặc dù phương pháp này dễ tiếp cận
và dễ thực hiện, nhưng nó cho thấy một số giới hạn khi tải của hệ thống có biên độ biến
động cao và nó chỉ phản hồi khi mà hệ thống đang phải chịu tải đạt đến ngưỡng cần phản
ứng lại. Điều đó dẫn đến rủi ro khi hệ thống chưa kịp đáp ứng và phân bổ tài nguyên đáp
ứng yêu cầu hiện tại. Từ những giới hạn đó, một cách khắc phục để tăng thêm độ chính
xác của việc phản hồi là thay đổi ngưỡng kích hoạt scaling. Tuy nhiên phương án này sẽ
gây nên dư thừa tài nguyên cung cấp cho containers, dẫn đến lãng phí tài ngun. Các
phương án proactive sử dụng các mơ hình như AR, MA, ARMA v.v.... được sử dụng để
dự đoán tải trong tương lai tuy nhiên, những kỹ thuật này đưa ra kết quả chậm so với nhu
cầu cung cấp tải động.
1.3 Bài tố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 tố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
q trình dự đốn tài ngun 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ì tồ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.
6
-
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 tốn đám mây (AWS) và trong Kubernetes (EKS).
1.4 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à BiLSTM, đồ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 q 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ự đố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.
7
CHƯƠNG 2: LỰA CHỌN PHƯƠNG ÁN
2.1 Lựa chọn mơ hình dự đố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ự
đố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ự đốn: ARIMA, LSTM và Bi-LSTM từ đó có thể lựa chọn được phương án phù
hợp.
2.1.1 Mơ hình ARIMA:
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:
𝐴𝑅 (𝑝) = ∅0 + ∅1 𝑥𝑡−1 + ⋯ + ∅𝑝 𝑥𝑡−𝑝
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ự đố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:
𝐸 (𝜖𝑡 ) = 0 (1)
𝜎(𝜖𝑡 ) = 𝛼 (2)
{
𝜌(𝜖𝑡 , 𝜖𝑡−𝑠 ) = 0, ∀𝑠 ≤ 𝑡 (3)
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.
8
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ự đốn của mơ hình ARIMA chậm. Ngồi ra độ chính xác của mơ
hình cũng sẽ giảm xuống trong trường hợp dự đốn trên nhiều bước thời gian.
2.1.2 Mơ hình LSTM:
Mơ hình LSTM dựa trên mơ hình RNN (recurrent neural network) phục vụ cho q 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ự đố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 q 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 q 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 q trình xử lý trước đó. Sau đó kết quả của phép nhân sẽ đi qua
một hàm Tanh.
9
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
tốn thơng tin dạng chuỗi.
2.1.3 Mơ hình Bi-LSTM:
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à q trình đưa dữ liệu
từ tính tốn trước đó tới tính tố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. Ngồi ra, cũng vì dữ
liệu được phân tích theo hai chiều nên việc tính tốn cũng như dự đốn sẽ chính xác
10
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.
Bởi vì Bi-LSTM xử lý thơng tin theo hai chiều, do đó các thơng tin khơng được sử dụng
bởi mơ hình LSTM sẽ được xử lý bởi Bi-LSTM dẫn đến tăng tính chính xác của mơ hình
dự đốn. Ngồi ra, các nghiên cứu trước đó sử dụng và đánh giá các mơ hình cũng nhận
định rằng mơ hình Bi-LSTM có kết quả dự đốn tốt hơn.
Hình 8: Mơ hình hoạt động của Bi-LSTM.
Ở Hình 8 ta thấy rằng mơ hình Bi-LSTM sẽ có hai lớp Forward Layer và Backward
Layer. Trong đó chiều của hai lớp ngày là ngược nhau nhưng lại sử dụng chung dữ liệu
đầu vào.
2.1.4 Kết luận
Từ những phân tích về các model học máy, mơ hình Bi-LSTM cho thấy được khả năng
xử lý dữ liệu theo thời gian và sử dụng dữ liệu trong quá khứ với dữ liệu đầu vào có thể
khơng tuyến tính, và chuỗi dữ liệu có độ dài thay đổi.
Do đó, Bi-LSTM được lựa chọn và sử dụng cho q trình dự đốn số lượng lưu lượng
truy cập mà hệ thống sẽ cần phải xử lý trong tương lai.
2.2 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 tố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
tố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 qt một
ứng dụng chạy trong Kubernetes như sau:
11
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.
12
Hình 10: Mơ hình thu thập dữ liệu nhằm phục vụ cho q 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 q trình dự đố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 q trình
train model và q trình dự đố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 ngun 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 ngun 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 q
trình dự đốn.
13
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 tố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.
14
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ụ ngồ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.
15
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 q trình dự đố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 đề. Ngồ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ữ.
16