Nghiên cứu và phát triển phương pháp truy vết phân tích và đánh giá luồng dịch vụ trong môi trường điện toán đám mây

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
--------------------------------------Nguyễn Trọng Vĩnh

NGHIÊN CỨU VÀ PHÁT TRIỂN PHƯƠNG PHÁP TRUY VẾT, PHÂN
TÍCH VÀ ĐÁNH GIÁ LUỒNG DỊCH VỤ
TRONG MƠI TRƯỜNG ĐIỆN TỐN ĐÁM MÂY

Chun ngành: Hệ thống thơng tin

LUẬN VĂN THẠC SĨ KHOA HỌC
HỆ THỐNG THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC
Tiến sĩ Nguyễn Bình Minh

Hà Nội – Năm 2019


MỤC LỤC
MỤC LỤC ...................................................................................................................... 2
LỜI CẢM ƠN ................................................................................................................. 3
LỜI CAM ĐOAN ........................................................................................................... 4
TĨM TẮT....................................................................................................................... 5
DANH MỤC CÁC THUẬT NGỮ CHÍNH ................................................................... 7
DANH MỤC CÁC BẢNG ............................................................................................. 8
DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ ........................................................................ 9
I.
PHẦN MỞ ĐẦU .................................................................................................. 10
1 Lý do chọn đề tài ................................................................................................ 10
2 Hiểu biết về lĩnh vực nghiên cứu đã lựa chọn .................................................... 11

3 Mục đích, đối tượng, phạm vi nghiên cứu của luận văn .................................... 11
3.1
Ý nghĩa khoa học...................................................................................... 12
3.2
Ứng dụng thực tiễn ................................................................................... 12
4 Tóm tắt cơ đọng các luận điểm cơ bản và đóng góp mới của tác giả ................ 12
5 Phương pháp nghiên cứu .................................................................................... 12
5.1
Lý thuyết .................................................................................................. 12
5.2
Mô phỏng ................................................................................................. 13
5.3
Thực nghiệm ............................................................................................ 13
II. NỘI DUNG .......................................................................................................... 14
1 Cơ sở lý thuyết ................................................................................................... 14
1.1
Kiến trúc phần mềm truyền thống – monolithic ...................................... 14
1.2
Kiến trúc phần mềm hướng dịch vụ – microservices .............................. 16
1.3
Quan sát – Observability .......................................................................... 19
2 Các nghiên cứu liên quan ................................................................................... 25
3 Mơ hình dữ liệu đề xuất ..................................................................................... 27
3.1
Hướng tiếp cận ......................................................................................... 27
3.2
Mơ hình dữ liệu ........................................................................................ 29
3.3
Tích hợp dữ liệu và thơng tin từ log, metrics và trace ............................. 30
3.4

Biểu diễn dữ liệu từ các nguồn, đặc tính của mơ hình dữ liệu ................. 31
4 Thử nghiệm và đánh giá ..................................................................................... 34
4.1
Kịch bản chính ......................................................................................... 34
4.2
Mơ hình thử nghiệm tổng quan ................................................................ 34
4.3
Mơ hình triển khai thực tế ........................................................................ 35
4.4
Kết quả thu được ...................................................................................... 38
4.5
Đánh giá ................................................................................................... 41
III. KẾT LUẬN .......................................................................................................... 42
1 Những kết luận mới ............................................................................................ 42
2 Đóng góp mới và kiến nghị về sử dụng kết quả nghiên cứu của luận văn......... 42
3 Hướng phát triển và hoàn thiện kết quả trong tương lai .................................... 42
IV. DANH MỤC CÁC TÀI LIỆU THAM KHẢO ................................................... 44
V. CHỈ MỤC............................................................................................................. 45


LỜI CẢM ƠN
Trong quá trình học tập, nghiên cứu và thực hiện luận văn Thạc sỹ khoa học này,
tôi đã nhận được nhiều sự chỉ dẫn và tham vấn. Xin được gửi lời cảm ơn chân thành
đến các thày, cô giảng viên cùng các cán bộ hỗ trợ giảng dạy thuộc trường Đại học Bách
khoa Hà Nội, đặc biệt là các thày, cô giảng viên trong Viện Công nghệ Thông tin và
Truyền thông. Đồng thời, tôi xin gửi lời cảm ơn đến Tiến sĩ Nguyễn Bình Minh là người
hướng dẫn trực tiếp cho luận văn thạc sỹ của tôi.
Cùng với đó, tơi xin gửi lời cảm ơn đến các học viên cùng khóa học đã có những
chia sẻ, phản biện q báu giúp tơi có cái nhìn nhiều chiều hơn về đề tài mình đang
nghiên cứu.

Bên cạnh đó, sự hỗ trợ nhiệt tình đến từ các đồng nghiệp (đến từ cơng ty Fujitsu
Việt Nam và Tập đồn Cơng nghiệp - Viễn thông Quân đội Viettel) của tôi trong hai
năm vừa qua là một sự hỗ trợ lớn, nhờ có sự hỗ trợ của các đồng nghiệp mà tơi đã có
thể có tài nguyên và các ứng dụng thực tế để áp dụng phần nghiên cứu của mình.
Ngồi ra, tơi cũng xin được cảm ơn cộng đồng Open Infrastructure (trước đây là
VietOpenStack) tại Việt Nam khi đã dẫn dắt được sự phát triện của điện toán đám mây
tại Việt Nam trong những năm gần đây. Nhờ đó mà tơi đã có cơ hội được gặp gỡ và
thảo luận với nhiều người có kiến thức khoa học cũng như ứng dụng thực tế liên quan
đến cloud computing tại Việt Nam.
Cuối cùng, gia đình là một yếu tố khơng thể kể đến trong q trình tơi nghiên cứu
và hồn thiện luận văn này. Xin gửi lời cảm ơn chân thành đến các thành viên trong gia
đình đã hỗ trợ và động viên tinh thần cho tôi trong gần hai năm vừa qua.

Hà Nội, tháng 04 năm 2019.

3


LỜI CAM ĐOAN
Tôi – Nguyễn Trọng Vĩnh – cam kết luận văn này là cơng trình nghiên cứu của
bản thân tơi dưới sự hướng dẫn của Tiến sĩ Nguyễn Bình Minh.
Các kết quả nghiên cứu được nêu trong luân vặn là trung thực, khơng sao chép
của bất cứ cơng trình đã được cơng bố nào khác. Tất cả các trích dẫn đều được tham
chiếu và ghi chú rõ ràng.
Hà Nội, tháng 04 năm 2019
Xác nhận của người hướng dẫn

Tác giả luận văn

Tiến sĩ Nguyễn Bình Minh

Nguyễn Trọng Vĩnh

4


TÓM TẮT
Hiện nay, với sự phát triển và ứng dụng mạnh mẽ của hạ tầng cơng nghệ thơng
tin, điện tốn đám mây đang dần trở thành một yêu cầu tất yếu của các doanh nghiệp có
quy mơ vừa trở lên đến lớn (như các nhà mạng, nhà cung cấp dịch vụ hạ tầng công nghệ
thông tin). Hạ tầng công nghệ thông tin phát triển đồng nghĩa với ứng dụng chạy trên
hạ tầng đó cũng được cởi trói và phát triển mạnh mẽ hơn nhằm tận dụng tối đa lợi thế
mà hạ tầng đó mang lại.
Trước đây, ứng dụng thường được thiết kế với kiến trúc monolithics (nguyên khối)
tất cả các thành phần phục vụ logic nghiệp vụ đều được phát triển và đóng gói đầy đủ
trong một bản để triển khai. Kiến trúc này rất đơn giản để phát triển, tuy nhiên, khi ứng
dụng trở nên lớn dần theo thời gian, để có thể phục vụ được nhiều người sử dụng, nhiều
chức năng thì kiến trúc này tỏ ra khơng còn phù hợp. Để tận dụng được sức mạnh, sự
mềm dẻo, tính linh hoạt của hạ tầng điện tốn đám mây, khái niệm ứng dụng cloudnative (Cloud Native Computing Foundation, 2019) ra đời. Trong đó, kiến trúc ứng
dụng microservices là một trong những tiêu chí giúp ứng dụng có thể sẵn sàng chạy trên
nền tảng điện toán đám mây hiệu quả.
Để đánh giá được mức độ hiệu quả và phù hợp với nền tảng điện tốn đám mây,
khơng thể khơng kể đến sự theo dõi (monitoring) và quan sát (observability).
Monitoring là một chủ đề đã được nói đến rất nhiều trước đây trong các cơng trình
nghiên cứu. Tuy nhiên, gần đây, observability lại là chủ đề đang dần được quan tâm
hơn. Đối với ứng dụng hiện nay, việc ghi nhật ký ứng dụng (log), đo đạc các thông số
của ứng dụng trong quá trình chạy (metrics) và truy vết luồng dịch vụ (trace) là các
công việc không thể thiếu, và chúng cũng không thể thay thế nhau. Log, metrics và trace
chính là ba trụ cột của Observability. Trước đây, với ứng dụng được phát triển theo kiến
trúc monolithic, log và metrics đã có thể cung cấp được phần nào các thơng tin giúp đội

ngũ phát triển và vận hành có thể xử lý các vấn đề xảy ra với hệ thống ứng dụng. Tuy
nhiên, với các ứng dụng cloud-native hiện nay, ứng dụng khơng cịn được phát triển
ngun khối, khơng còn được triển khai trên một đơn vị phần cứng mà là trên nhiều đơn
vị khác nhau về mặt logic, thậm chí là khác nhau về mặt địa lý. Từ sự phân tán này, nếu
chỉ có log và metrics thì các dữ liệu về toàn thể ứng dụng sẽ là rời rạc. Ngay cả khi đã
có các giải pháp thu thập và lưu trữ log, metrics một cách tập trung thì việc thiếu đi

5


thông tin về mối quan hệ giữa các dịch vụ nằm trong tổng thể ứng dụng cũng gây ra
khó khăn lớn cho đội ngũ phát triển và vận hành.
Do đó, nhu cầu thu thập và thiết lập mối tương quan giữa ba trụ cột của
observability trở nên cần thiết. Trong nghiên cứu này, cá nhân đưa ra đề xuất về một
mơ hình dữ liệu có thể thể hiện được tính tương quan từ ba nguồn dữ liệu riêng biệt kể
trên, và ứng dụng mơ hình dữ liệu này vào trong ứng dụng thực tế. Kết quả thu được từ
nghiên cứu của đề tài đã giúp đội ngũ phát triển và vận hành tối ưu hơn được thời gian
của mình.

6


DANH MỤC CÁC THUẬT NGỮ CHÍNH
STT
1
2
3
4
5
6

7
8
9
10
11
12
13
14
15
16

17
18

Thuật ngữ
Diễn giải
Open Infrastructure Hạ tầng được xây dựng bởi phần mềm, giải pháp mã
nguồn mở
cloud computing
Điện toán đám mây
monolithics
Kiến trúc phần mềm nguyên khối truyền thống
microservices
Kiến trúc phần mềm hướng dịch vụ, chia nhỏ các
thành phần của phần mềm thành nhiều dịch vụ nhỏ
cloud native
Công nghệ liên quan đến ứng dụng hiện đại, chạy
trên mơi trường điện tốn đám mây
monitoring
Giám sát ứng dụng, thường được thực hiện tự động

observability
Quan sát, thường có sự tương tác của con người
logging
Ghi nhật ký ứng dụng, hệ thống
metrics
Đo đạc các thông số của ứng dụng khi triển khai
tracing
Truy vết dịch vụ
distributed tracing Truy vết dịch vụ trong môi trường phân tán
bare metal
Máy thật, server vật lý
virtual machine
Máy ảo
container
Giải pháp ảo hóa dựa trên container
JVM
Java Virtual Machine – Máy ảo chạy mã Java
CI/CD
Continuous Integration/Continuous Delivery/
Continuous Deployment – Tích hợp liên tục/Chuyển
giao liên tục/Triển khai liên tục
DAG
Directed Acyclic Graph – Đồ thì có hương khơng có
chu trình
tree
Cây, đồ thị có hướng khơng có chu trình, mỗi nút
chỉ có duy nhất một nút là cha, riêng nút gốc khơng
có cha

7

DANH MỤC CÁC BẢNG
Bảng 1 Tổng hợp các nghiên cứu liên quan ................................................................. 26
Bảng 2 Biểu diễn mơ hình dữ liệu dưới mã JSON ....................................................... 32
Bảng 3 Một ví dụ cho mơ hình dữ liệu ......................................................................... 33

8


DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ
Hình 1 Một ứng dụng web truyền thống sử dụng kiến trúc nguyên khối (Richardson,
2018) ............................................................................................................................. 15
Hình 2 Ứng dụng được thiết kế theo mơ hình kiến trúc hướng dịch vụ (Richardson,
2018) ............................................................................................................................. 18
Hình 3 Các thành phần liên quan đến kiến trúc microservices (Richardson, 2018) .... 19
Hình 4 Biểu diễn kết quả ghi log của một hệ thống ..................................................... 21
Hình 5 Mức độ sử dụng bộ nhớ của JVM trong thời gian gần đây .............................. 23
Hình 6 Một trace với các thơng tin được thể hiện bằng hình ảnh ................................ 23
Hình 7 Luân chuyển metadata theo request qua các dịch vụ (Shkuro, 2019) .............. 25
Hình 8 Luồng gỡ rối, sửa lỗi ứng dụng tiêu biểu (Loki, 2018) .................................... 27
Hình 9 Mơ hình dữ liệu đề xuất, kết hợp thông tin từ metrics, log và trace ................ 29
Hình 10 Thu thập các nguồn dữ liệu và tích hợp vào mơ hình chung ......................... 31
Hình 11 Mơ hình thử nghiệm hệ thống tổng quan ....................................................... 34
Hình 12 Mơ hình triển khai thực tế để kiểm chứng...................................................... 35
Hình 13 Bên trong một máy ảo chạy dịch vụ microservices ........................................ 36
Hình 14 Mơ hình triển khai, liên kết giữa các dịch vụ của hệ thống ........................... 37
Hình 15 Thông tin liên quan đến log, metrics và trace thu được ................................. 39
Hình 16 Một request có lỗi liên quan đến timeout ....................................................... 40

9


I. PHẦN MỞ ĐẦU
1

Lý do chọn đề tài
Hiện nay, các hệ thống phân tán đang phát triển mạnh mẽ. Kèm theo đó, nhiều mơ

hình phân tán được phát triển và triển khai. Điều này xuất phát từ chính nhu cầu tính
tốn, xử lý thơng tin, dữ liệu trên quy mơ lớn của các hệ thống hoặc mở rộng dịch vụ ra
quy mơ lớn trên tồn cầu của các nhà cung cấp dịch vụ trực tuyến.
Tính phân tán là xu thế tất yếu của việc triển khai hệ thống phần mềm hiện nay.
Trong hệ thống có tính phân tán, các dịch vụ hoạt động tại nhiều nơi khác nhau. Về mặt
hạ tầng cho ứng dụng, sự khác nhau này có thể ở mức máy ảo (virtual machine), máy
thật (computer, bare metal). Về mặt địa lý, sự khác nhau này có thể ở mức địa phương
hay châu lục.
Trước đây, các ứng dụng công nghệ thông tin thường được phát triển và triển khai
theo kiến trúc nguyên khối (monolithic). Hiện nay, với xu thế tất yếu của việc triển khai
phân tán để tối ưu tốt hơn hiệu quả sử dụng tài nguyên trên hạ tầng điện tốn đám mây
thì kiến trúc monolithic trở nên khơng cịn phù hợp. Các ứng dụng được phát triển theo
hướng tối ưu được những lợi thế mà hạ tầng điện toán đám mây mang lại (cloud-native
applications) dần xuất hiện để khỏa lấp vào chỗ trống kể trên. Một trong những yếu tố
để thể hiện ứng dụng sẵn sàng và tối ưu khi chạy trên nền tảng điện toán đám mây đó
là kiến trúc ứng dụng hướng dịch vụ (microservices).
Để phát triển và vận hành ứng dụng, cho dù là theo kiến trúc monolithic hay
microservice thì chúng ta thường thực hiện ghi nhật ký ứng dụng (log), thu thập các dữ
liệu đo đạc được từ ứng dụng trong quá trình vận hành (metrics), và thực hiện truy vết
luồng dịch vụ (trace). Đối với hệ thống theo kiến trúc monolithic, thông thường, log và
metrics đã cung cấp được phần nào thơng tin phục vụ q trình phát triển và vận hành.

Tuy nhiên, đối với ứng dụng được phát triển theo kiến trúc microservices thì hai phần
trên là chưa đủ. Log và metrics có tính địa phương (local) tại nơi mà nguồn dữ liệu này
được sinh ra (log thì được ghi bởi ứng dụng, metrics thì được thu thập tại chính nơi mà
ứng dụng đang được triển khai). Hai nguồn dữ liệu này đã thiếu mất một thông tin quan
trọng là mối liên quan giữa các dịch vụ và luồng đi của dữ liệu trong hệ thống. Khi đó,
trace chính là một nguồn dữ liệu bổ trợ tốt cho việc phát triển và vận hành hệ thống ứng
dụng.
10


Các thơng tin được trích ra từ ba nguồn dữ liệu kể trên là có thể bao quát được hệ
thống ứng dụng. Tuy nhiên, trong quá trình phát triển và vận hành ứng dụng, các dữ
liệu trên được thu thập một cách rời rạc, được xử lý và hiển thị một cách rời rạc. Đó
chính là vấn đề lớn dành cho đội ngũ khi có một lỗi nào đó xảy ra trong hệ thống ứng
dụng của họ. Để tìm ra được nguyên nhân của lỗi đó, người vận hành cần phải tham
khảo các nguồn dữ liệu một cách riêng rẽ trước khi đưa ra quyết định xử lý tương ứng.
Do đó, nhu cầu thống nhất, tạo ra được mối tương quan giữa các nguồn dữ liệu trên là
cần thiết.
2

Hiểu biết về lĩnh vực nghiên cứu đã lựa chọn
Cá nhân đã được trang bị được kiến thức về các lĩnh vực liên quan hỗ trợ cho đề

tài bao gồm:
• Kiến thức về ứng dụng sẵn sàng cho nền tảng điện toán đám mây
• Kiến trúc phần mềm hướng dịch vụ (microservices)
• Kiến thức về thực hiện thu thập, xử lý, phân tích nhật ký ứng dụng (log)
• Thu thập, xử lý, phân tích các thơng số đo đạc được của ứng dụng trong
q trình vận hành, triển khai (metrics)
• Tham gia phát triển tính năng cho thư viện phục vụ truy vết luồng dịch vụ

(trace) trong các dự án của OpenStack Foundation
• Là thành viên phát triển chủ chốt trong thư viện OSProfiler – thư viện liên
quan đến distributed tracing
3

Mục đích, đối tượng, phạm vi nghiên cứu của luận văn
Đề xuất mơ hình dữ liệu cơ bản thể hiện mối tương quan giữa ba nguồn dữ liệu là

log, metrics và trace. Với mơ hình dữ liệu này, ứng dụng được triển khai phân tán trên
mơi trường, nền tảng điện tốn đám mây sẽ trở nên dễ dàng phát triển và vận hành hơn
nhờ có thơng tin tương quan giữa ba trụ cột của obervability.
Bên cạnh việc đề xuất hướng tiếp cận phù hợp. Kiểm chứng và thực nghiệm hướng
tiếp cận này cần phải được thực hiện trên hệ thống phân tán. Ứng dụng được lựa chọn
để thực hiện kiểm chứng các kết quả của đề tài là VSmart – một hệ thống ứng dụng nội
bộ của Viettel phục vụ quản lý công tác kỹ thuật.

11


3.1

Ý nghĩa khoa học
Đề xuất giải pháp cận phù hợp hơn hỗ trợ cho các hướng tiếp cận truyền thống

trong việc giải quyết bài tốn tìm ngun nhân phát sinh, gỡ rối vấn đề xảy ra trong hệ
thống phân tán chạy trên nền tảng điện toán đám mây.
3.2

Ứng dụng thực tiễn
Cài đặt và thử nghiệm trên ứng dụng thực tế VSmart tại Tổng công ty mạng lưới

Viettel. VSmart là ứng dụng nội bộ của Viettel phục vụ cho các nhân viên kỹ thuật
nhằm quản lý và thực hiện các công tác kỹ thuật liên quan đến hạ tầng mạng lưới viễn
thơng và cơng nghệ thơng tin.
4

Tóm tắt cơ đọng các luận điểm cơ bản và đóng góp mới của tác giả
Các nội dung chính được nghiên cứu trong phạm vi của đề tài bao gồm những

điểm như liệt kê dưới đây.
• Nghiên cứu các phương pháp truy vết luồng dịch vụ trong hệ thống phân
tán
• Nghiên cứu kết hợp với các thành tựu đã đạt được trong các chủ đề truyền
thống như sử dụng log (ghi nhật ký), metrics (giám sát các chỉ số của hệ
thống) cùng với trace (truy vết luồng dịch vụ) trong môi trường ứng dụng
được triển khai trên nền tảng điện tốn đám mây.
• Đưa ra được một mơ hình dữ liệu (data model) thống nhất ở mức cơ bản
dành cho hệ thống quan sát (observability) phục vụ cho nhu cầu quan sát
thực tế của người phát triển và vận hành hệ thống ứng dụng trên nền tảng
điện tốn đám mây.
• Ứng dụng được data model đã được nghiên cứu vào các ứng dụng đang
được triển khai thực tế và phục vụ hàng ngàn người sử dụng trong Viettel.
5
5.1

Phương pháp nghiên cứu
Lý thuyết
• Tổng hợp và phân tích dữ liệu
• Trợ giúp quyết định: hỗ trợ cho tiêu chí lấy mẫu cho tracing
• Kiến trúc phần mềm: nguyên khối và hướng dịch vụ

12


5.2

Mơ phỏng
• Sử dụng các nền tảng biểu diễn dữ liệu mã nguồn mở để hiển thị dashboard tương
ứng phục vụ cho nhu cầu quan sát.
• Đối với log, sử dụng các công nghệ Elasticsearch (lưu trữ log) – Fluentd (thu
thập log) – Kibana (hiển thị dữ liệu log)
• Đối với metrics, sử dụng Prometheus và các công cụ liên quan
• Đối với trace, sử dụng Jaeger Tracing

5.3

Thực nghiệm
• Thử nghiệm trên ứng dụng thiết kế theo kiến trúc microservices được triển khai
trên nền tảng điện toán đám mây dựa trên OpenStack
• Nghiên cứu, phát triển, cài đặt, triển khai và tổng hợp, báo cáo trên các ứng dụng
đang được triển khai tại Tổng công ty mạng lưới Viettel

13


II. NỘI DUNG
1

Cơ sở lý thuyết
Trong phần này, nghiên cứu xin trình bày các nội dung cơ bản liên quan đến cơ

sở lý thuyết trong quá trình thực hiện đề tài.
1.1

Kiến trúc phần mềm truyền thống – monolithic
Chỉ cách đây một vài năm, các ứng dụng web vẫn còn thường được xây dựng và

triển khai theo mơ hình kiến trúc nguyên khối truyền thống. Mọi thứ bao gồm phần
web, phần logic nghiệp vụ, phần giao tiếp với cơ sở dữ liệu, phần giao tiếp với các hệ
thống bên ngoài khác, … được xây dựng và triển khai thành một khối duy nhất. Mơ
hình này rất dễ dang để phát triển lúc ban đầu. Tuy nhiên, khi có nhu cầu mở rộng (theo
cả chiều dọc – thêm các tính năng mới, chiều ngang – bổ sung những máy chủ chạy ứng
dụng tương tự) thì mọi việc trở nên khó khăn.
Lấy ví dụ như Hình 1 ở dưới mơ tả về một ứng dụng web theo kiến trúc nguyên
khối. Ứng dụng này sử dụng Java để phát triển, sau đó đóng gói thành dạng file WAR
để triển khai vào trong Tomcat web container. File WAR này chứa đầy đủ hầu như tất
cả các thành phần của một ứng dụng web, từ giao diện ứng dụng, các dịch vụ kế toán,
kho vận, … Theo chiều từ trái sang phải, ứng dụng này có thể hiện sự giao tiếp giữa
trình duyệt của người dùng thơng qua một máy chủ và sau đó đến ứng dụng nguyên
khối và có tương tác với cơ sở dữ liệu.
Những đặc tính rất tốt của mơ hình kiến trúc này chính là:
• Dễ dàng phát triển, bởi các cơng cụ hỗ trợ việc phát triển rất thân thiện với
mô hình này
• Dễ dàng triển khai, tất cả những gì mà đội ngũ vận hành cần quan tâm khi
triển khai đó là đặt file WAR đó vào đúng chỗ
• Dễ dàng để có thể mở rộng ra theo chiều ngang, người vận hành chỉ cần
chạy nhiều bản sao của ứng dụng trên các đơn vị có cấu hình tương đồng

14

Hình 1 Một ứng dụng web truyền thống sử dụng kiến trúc nguyên khối (Richardson, 2018)

Tuy nhiên, khi ứng dụng trở nên lớn hơn, đội ngũ phát triển, vận hành trở nên lớn
hơn. Mơ hình kiến trúc này bộc lộ nhiều bất lợi. Những bất lợi này có thể kể đến như
dưới đây (Richardson, 2018):
• Thời gian triển khai mới khi có một phiên bản cập nhật là tốn thời gian,
thậm chí chỉ một thay đổi nhỏ trong mã nguồn cũng khiến cho toàn bộ ứng
dụng cần phải được triển khai lại từ đầu.
• Việc triển khai liên tục các bản cập nhật trở nên khó khăn do có quá nhiều
thành phần có thể bị tác động.
• Mở rộng ứng dụng chỉ đơn giản theo chiều ngang, khó mở rộng theo chiều
dọc vì các thành phần trong ứng dụng có thể có mối liên hệ chặt chẽ với
nhau.
• Việc tối ưu tài nguyên ứng dụng là một việc khó khăn. Trong ứng dụng, có
những thành phần rất ít được sử dụng, có những thành phần lại có nhu cầu
sử dụng cao. Mỗi khi mở rộng ứng dụng theo chiều ngang thì có thể tối ưng

15


hơn được các thành phần thường xuyên được sử dụng, tuy nhiên lại là một
sự lãng phí cho các thành phần ít được sử dụng.
• Do ứng dụng được phát triển một cách nguyên khối cho nên sai lầm chủ
quan của người lập trình khi để cho các thành phần trong ứng dụng có mối
liên hệ mật thiết với nhau mà không phân tách rõ ràng về mặt chức năng.
Điều này dẫn đến có một thành phần nhỏ thay đổi trong mã nguồn có thể
gây ra ảnh hưởng hàng loạt đến các thành phần khác.
1.2

Kiến trúc phần mềm hướng dịch vụ – microservices

Để đáp ứng được một số nhu cầu mà ứng dụng thiết kế theo kiến trúc nguyên khối

chưa thể đáp ứng được trong mơi trường điện tốn đám mây hiện nay, các ứng dụng sẵn
sàng cho nền tảng điện toán đám mây (cloud-native application) ra đời. Ứng dụng
cloud-native (Cloud Native Computing Foundation, 2019) được định nghĩa bao gồm
các khía cạnh, cơng nghệ như containers, service meshes, kiến trúc phần mềm hướng
dịch vụ microservices, immutable infrastructure và API được định nghĩa rõ ràng.
Trong khuôn khổ đề tài này, các phần nghiên cứu chủ u xoay quanh các khía
cạnh có liên quan đến phần mềm được thiết kế theo kiến trúc microservices. Theo
(Fowler, 2014) và (Shkuro, 2019) kiến trúc microservices vẫn chưa hề có một tiêu chuẩn
chung được cơng nhận hay thống nhất nào, tuy nhiên kiến trúc này thường có nhưng
đặc điểm như dưới đây:
• Ứng dụng được phân tách nhỏ thành các dịch vụ nhỏ hơn, nhỏ đến mức
dịch vụ đó có thể chỉ tập trung vào duy nhất một nhiệm vụ và làm thật tốt
ngiệm cụ đó.
• Các dịch vụ trong toàn thể ứng dụng thường giao tiếp với nhau qua một
giao thức nhất định, có thể dựa trên HTTP như REST, hay gRPC, ...
• Các dịch vụ được phân tách theo chiều hướng khả năng đáp ứng nghiệp vụ
chứ không phân tách thành từng tầng công nghệ như web đến back-end rồi
đến database.
• Các dịch vụ riêng biệt hồn tồn có thể được xây dựng sử dụng các cơng
nghệ khác nhau, miễn là có thể giao tiếp với nhau qua cùng một giao thức.
Không giống như kiến trúc truyền thống, trước khi bắt đầu một dự án,
chúng ta thường phải lựa chọn các công nghệ để thỏa mãn tất cả các yêu
16


cầu công việc nghiệp vụ sau này. Với microservices, ta chỉ cần chọn công
nghệ phù hợp nhất đối với nhu cầu nghiệp vụ của dịch vụ đó mà thơi.
• Mơ hình dữ liệu, cơ sở dữ liệu là riêng biệt đối với mỗi dịch vụ, nhằm làm

sao đáp ứng được nhu cầu xử tốt nhất, phù hợp nhất với dịch vụ đó.
• Hệ thống ứng dụng được xây dựng, phát hành và triển khai một cách tự
động. Mã nguồn ứng dụng được tự đơng kiểm tử, tích hợp liên tục và
chuyển giao liên tục (CI/CD).
• Ln đặt ứng dụng trong tình cảnh có thể gặp lỗi để tính tốn đến các
phương án sửa lỗi, dung lỗi một cách chủ động, tránh nút cổ chai trong ứng
dụng.
• Thiết kế ứng dụng được cập nhật và thay đổi nhanh chóng và phù hợp với
nhu cầu, khơng để cho một thành phần có cập nhật làm ảnh hưởng đến cách
thành phần khác trong tồn bộ ứng dụng. Điểm này chính là tính độc lập
của mỗi dịch vụ.
Có thể lấy một ví dụ như Hình 2 (Richardson, 2018) thì ứng dụng được thiết kế
thành nhiều dịch vụ nhỏ khác nhau. Mỗi dịch vụ đóng một vai trò riêng biệt theo các
yêu cầu nghiệp vụ. Các dịch vụ này giao tiếp với nhau qua một giao thức chung trong
trường hợp này là REST. Bên cạnh đó, mỗi ứng dụng thường có một cơ sở dữ liệu riêng
biệt được thiết kế sao cho phù hợp nhất với nhu cầu của ứng dụng, tránh để toàn hệ
thống phụ thuộc vào một cơ sở dữ liệu duy nhất. Ngồi ra, các ứng dụng và người dùng
có thể tương tác với nhau thông qua một API gateway (một dịch vụ đặc biệt có thể đóng
vai trị như dịch vụ chỉ đường, điều hướng luồng dữ liệu theo đúng hướng mong muốn).

17


Hình 2 Ứng dụng được thiết kế theo mơ hình kiến trúc hướng dịch vụ (Richardson, 2018)

Kiến trúc microservices hiện nay thường được định nghĩa gồm rất nhiều các thành
phần liên quan. Trước đây, ứng dụng thường chỉ bao gồm các phần xử lý logic nghiệp
vụ, giao diện người dùng, cơ sở dữ liệu. Tuy nhiên, với kiến trúc microservices thì chỉ
logic ứng dụng và các thành phần như trên là khơng đủ, bên cạnh các thành phần cơ bản
đó, có rất nhiều thành phần khác có liên quan như Hình 3 (Richardson, 2018). Trong

khn khổ nghiên cứu này, thành phần được cá nhân xoay quanh nhiều nhất chính là
observability (quan sát) mà ba trụ cột chính là log, metrics và tracing (Sridharan, 2018).

18


Phần tiếp theo của nghiên cứu xin được đề cập đến các trụ cột của observability.

Hình 3 Các thành phần liên quan đến kiến trúc microservices (Richardson, 2018)

1.3

Quan sát – Observability
Trước đây, obsevability thường được hiểu là những gì có thể quan sát được từ bên

ngoài và bên trong, cũng như các biểu hiện của hệ thống được xác định chỉ bởi nhìn vào
đầu vào và đầu ra của hệ thống. Tuy nhiên, định nghĩa này khá tối nghĩa, tại hội nghị
Observability Practioners 2018 (Cantrill, 2018), định nghĩa này đã được thay đổi theo
hướng ngắn gọn hơn. Khả năng quan sát (observability) của một ứng dụng phần mềm
là khả năng cho phép con người có thể đặt câu hỏi và trả lời nhận được câu trả lời từ hệ
thống. Khi đó, càng nhiều câu hỏi được trả lời bởi hệ thống, khả năng quan sát hệ thống
một cách kỹ càng lại càng tăng lên.
1.3.1

Các trụ cột của quan sát (observability)
Hiện nay, khả năng quan sát ứng dụng phần mềm thường được cho rằng bao gồm

ba thành tố nhỏ hơn đó là log, metrics và trace (Cantrill, 2018). Mỗi thành tố này lại đại
diện cho một khía cạnh khác nhau của hệ thống và không thể thay thế cho nhau.

19


1.3.2

Logging – Ghi nhật ký ứng dụng và hệ thống

1. Đặc tính của log
Log, hay nhật ký ứng dụng là một trong những dữ liệu quan trong và được tiếp
cận đầu tiên mỗi khi có một vấn đề gì xảy đến với hệ thống ứng dụng. Log có một số
đặc tính chính như:
• Có tính thời điểm: Log được sinh ra vào một thời điểm và thao tác tương
ứng nhất định của hệ thống, mỗi log đều gắn với một mốc thời gian nhất
định.
• Có tính địa phương: Log được sinh ra tại dịch vụ nào thì chỉ phản ánh thơng
tin của ứng dụng đó tại một thời điểm mà thơi.
2. Thu thập log
Tính địa phương của log là một trong những khó khăn đối với hệ thống phần mềm
được thiết kế theo kiến trúc phần mềm microservices. Mỗi khi có vấn đề gì xảy đến với
hệ thống, việc trích xuất thông tin từ nhật ký ứng dụng để tiến hành gỡ rối là một việc
mất thời gian. Người xử lý vấn đề cần phải có quyền tiếp cận, truy cập vào các máy
chủ/máy ảo/container chạy dịch vụ liên quan để trích xuất log của ứng dụng, sau đó mới
tiến hành điều tra vấn đề.
Để giải quyết vấn đề này, có nhiều giải pháp hướng tới thu thập log một các tập
trung và đẩy về một hệ thống lưu trữ tập trung nhằm dễ dàng tổng hợp và phân tích.
Việc thu thập các log này thường được hỗ trợ bởi các ứng dụng chuyên biệt cho chức
năng này và thường được gọi là log shipper. Một vài cái tên tiêu biểu có thể kể đến như:
Logstash, Fluentd, Filebeat, … Tuy nhiên, vẫn như đặc tích địa phương của log, cho dù
có được lưu trữ một cách tập trung thì các log này vẫn thể hiện các thông tin riêng rẽ
dành cho mỗi dịch vụ.

Tiến xa hơn một bước nữa, để có thể tạo ra mối tương quan giữa các log thu thập
được từ ứng dụng, có một số nghiên cứu và ứng dụng đã đưa thêm một thơng tin đó là
request ID (một mã định danh rằng log này được sinh ra bởi luồng dịch vụ nào). Điều
này là tốt, tuy nhiên, một vấn đề nữa xảy đến với log ứng dụng đến từ chính đặc tính
thứ nhất, tính thời điểm. Mỗi máy chủ/máy ảo chạy ứng dụng lại có một đồng hồ riêng,
các đồng hồ này có thể được đồng bộ với một đồng hồ trung tâm qua giao thức (VD:
NTP) tuy nhiên vẫn có những sai lệch về mặt thời gian có thể xảy ra. Do đó, chỉ một
20


mình log có thể là khơng đủ cho người quản trị hệ thống có thể gỡ rối được ứng dụng
một cách nhanh chóng và dễ dàng. Khi đó trace sẽ là là một bổ sung hữu ích (sẽ được
đề cập ở phần sau).
3. Phân tích log
Sau khi thu thập được log về một hệ thống tập trung, để có thể tiếp tục trích xuất
được những thơng tin quan trọng và có giá trị, đội phát triển thường đưa ra các thống
kê, phân tích của log thu thập được dựa trên các tiêu chí như số lượng, đặc điểm của
loại log, biểu đồ phân bố log, từ đó đưa ra được các biểu đồ và có những dự đốn dành
cho hệ thống trong tương lai.

Hình 4 Biểu diễn kết quả ghi log của một hệ thống

4. Lưu trữ log
Log sau khi được lưu trữ tập trung, các phương pháp lưu trữ log một cách hiệu
quả và tận dụng được sức mạnh phần cứng sẽ được triển khai. Ví dụ như lưu trữ log
trên nhiều node khác nhau, trong đó, các node có thể có hạ tầng và sức mạnh phần cứng
khác nhau. Hạ tầng tốt, tốc độ cao dành cho log có tần suất truy nhập nhiều và trong
thời gian gần. Hạ tầng có tốc độ chậm hơn dùng cho các tác vụ lưu trữ lâu dài, ít truy
xuất.

21


Metrics – Các thông số đo lường ứng dụng và hệ thống

1.3.3

1. Khái niệm về metrics
Metrics được hiểu là các thông số, thống kê, đo đạc về mặt con số được ghi nhận
từ ứng dụng ví dụ như counters, gauges, hay đo đạc thời gian.
2. Các trường thông tin của metrics
Metrics mang trong mình 04 trường thơng tin chính:
•
•
•
•

Timestamp: Thời điểm thu thập metric
Metric name: tên metric
Unit: Đơn vị đo
Datapoint: các thơng tin chi tiết hơn của metrics

3. Tính chu kỳ của việc thu thập các metrics
Metrics có tính chu kỳ khi mà thông thường, các thông số này chỉ được đo đạc sau
một khoảng thời gian nhất định, có thể là tính bằng giây, bằng phút thậm chí bằng giờ
đồng hồ. Do đó, việc thu thập các thơng tin liên quan đến metrics là tương đối tiết kiệm
tài nguyên.
Tuy nhiên, do tính chu kỳ của metrics, nếu có sự kiện bất thường xảy ra vào đúng
khoảng thời gian chờ để thu thập metrics tiếp theo thì các thơng số lấy từ metrics sẽ bỏ
qua mất các thông tin quan trọng ấy. Do đó, thơng thường metrics sẽ cho cái nhìn tổng

quan về hệ thống và đưa ra các cảnh báo sau một khoảng thời gian thu thập đủ lượng
metrics cần thiết.

22


Hình 5 Mức độ sử dụng bộ nhớ của JVM trong thời gian gần đây

1.3.4

Tracing – Truy vết luồng dịch vụ của ứng dụng
Ngày nay, việc triển khai các dịch vụ của ứng dụng một cách phân tán là một

phương án dường như là tất nhiên để đảm bảo tính an toàn của hệ thống, và tận dụng
sức mạnh phân tán đến từ nhiều máy tính khác nhau.
Tracing giúp đội ngũ phát triển và vận hành có cái nhìn tổng quan về hệ thống khi
nó thể hiện được tồn trình của luồng dữ liệu ứng dụng khi có một request được thực
hiện từ phía client.

Hình 6 Một trace với các thơng tin được thể hiện bằng hình ảnh

23


1. Black-box inference
Hướng tiếp cận đầu tiên dành cho tracing đến từ các thông tin được thu thập từ hệ
thống qua các kết quả, thể hiện của ứng dụng, sau đó từ các kết quả đó tìm ra mối tương
quan để đưa ra được các traces mong muốn. Phương pháp này có lợi thế là khơng cần
phải chỉnh sửa hay cập nhật bất kỳ phần logic nghiệp vụ nào, mà thường chỉ phải cài
thêm một agent để thu thập các thông tin đến từ ứng dụng. Tuy nhiên, khi hệ thống lớn

lên, dữ liệu ứng dụng đa dạng thì phương pháp này là một vấn đề không nhỏ khi đi tìm
mối tương quan từ những gì quan sát được. Một số nghiên cứu tiêu biểu có thể kể đến
như Mystery Machine. Hiện nay cũng có nhiều ứng dụng đang áp dụng kết quả của
hướng nghiên cứu này dành cho các sản phẩm thương mại. Một số sản phẩm có thể kể
đến như Elastic APM, Cisco AppDynamics, Dynatrace, Data Dog.
2. Schema-based
Với hướng tiếp cận này, hệ thống cần phải xây dựng được sẵn luồng dữ liệu đi
như thế nào từ trước khi áp dụng tracing. Lợi thế của hệ thống dạng này là dữ liệu, các
mối quan hệ, luồng dịch vụ rất rõ ràng và chuẩn vì nó đã được định nghĩa từ trước. Tuy
nhiên, khi hệ thống lớn lên, có sự thay đổi về cấu trúc và luồng dữ liệu, chúng ta cần
phải sửa lại tất cả các luồng, mô hình dữ liệu liên quan. Do đó, hướng tiếp cận này là
không phù hợp với các hệ thống được thiết kế theo kiến trúc microservices với sự thay
đổi liên tục.
3. Metadata propagation
Hướng tiếp cận này sẽ thực hiện gắn thêm metadata và lưu chuyển metadata đó
trong tồn bộ luồng dịch vụ, dựa vào metadata này, sau đó hệ thống tracing có thể thực
hiện xây dựng nên được đồ thị luồng dữ liệu. Đồ thị này có thể là một cây (tree) hoặc
một đồ thị có hướng khơng có chu trình (DAG) Tuy nhiên, một hạn chế của hướng tiếp
cận này đó là sẽ phải thực hiện sửa một chút logic nghiệp vụ của ứng dụng hiện tại thì
mới có thể gắn các metadata.

24


Hình 7 Luân chuyển metadata theo request qua các dịch vụ (Shkuro, 2019)

2

Các nghiên cứu liên quan
1. Google Dapper

Năm 2010, Google có cơng bố một nghiên cứu được ứng dụng chủ yếu trong nội

bộ công ty liên quan đến tracing. Tiêu đề nghiên cứu là “Dapper, a Large-Scale
Distributed Systems Tracing Infrastructure” (Sigelman, et al., 2010). Nghiên cứu này
chỉ ra rằng nhu cầu liên quan đến tracing thực sự đã có từ rất lâu, tuy nhiên cũng có
những hạn chế về mặt cơng nghệ tại thời điểm đó. Nghiên cứu tập trung xoay quanh
vấn đề tracing trong các ứng dụng nội tại của Google.
Từ khi nghiên cứu này được công bố, cấc công ty lớn khác cũng dựa vào tư tưởng
này để tiếp tục cài đặt và đưa ra những ứng dụng liên quan như Zipkin đến từ Twitter,
Lighstep (sản phẩm của tác giả chính của nghiên cứu trên, sau này tách ra mở một công
ty riêng để thực hiện thương mại hóa lĩnh vực này).
2. OpenTracing API
Vào năm 2016, các nhóm tác giả của các sản phẩm nêu trên đã ngồi lại với nhau
và thống nhất đưa ra một chuẩn chung dành cho tracing trên thế giới và lấy tên là
OpenTracing API. OpenTracing API sẽ giúp thống nhất mơ hình dữ liệu, mơ hình thiết
kế của các cơng cụ tracing. Hiện nay, dự án OpenTracing API đang được bảo trợ bởi
Cloud Native Computing Foundation.
Nhờ vào OpenTracing API mà các nhóm tác giả đã định nghĩa ra được một mơ
hình dữ liệu chuẩn cho tracing, mơ hình dữ liệu này có thể được mở rộng để thêm một
số trường thông tin khác mà người sử dụng, nhà phát triển mong muốn.

25