Xây dựng hệ thống giám sát (Monitoring) tập trung cho workload trên Cloud

Bài viết đến từ anh Lê Văn Tám – Senior Cloud Engineer

Cloud Architect team @Techcombank

Bối cảnh:

Ở Techcombank, bộ phận Dịch vụ Hạ tầng (ITO – Infrastructure Services) đang vận hành rất nhiều ứng dụng (application) khác nhau để phục vụ người dùng nội bộ và khách hàng bên ngoài như quản lý nợ (Debt Management), tra cứu tín dụng (ICS), tra cứu và thu hộ thuế nhà nước (TCS), quản lý đặt chỗ (QMS)…

Theo chiến lược chuyển đổi số theo định hướng “Cloud First”, Techcombank đã thực hiện di dời (migrate) được gần 30 ứng dụng (application) từ on-prems lên cloud từ giữa năm 2021 tới nay. Việc di dời thành công các ứng dụng đã bước đầu đã chứng minh được lợi ích của chiến lược “Cloud first”.

Tuy nhiên, trong quá trình chuyển đổi “nóng” đó, Techcombank nói chung và đội ngũ ITO nói riêng cũng gặp phải một số vấn đề do chưa đủ nguồn lực để triển khai, đặc biệt là vấn đề giám sát (monitor) các ứng dụng này. Thời điểm đó, mỗi ứng dụng phải thực hiện một giải pháp giám sát riêng, việc này dẫn tới khá nhiều khó khăn trong việc vận hành một số lượng lớn các ứng dụng như: có quá nhiều kênh thông tin cảnh báo, các cảnh báo chưa được tường minh và rõ ràng về nội dung; chưa có màn hình giám sát tập trung… 

Từ những hạn chế đó, trong năm 2023, Techcombank đã tiến hành triển khai dự án Cloud Centralize Monitoring: tập trung và chuẩn hóa việc giám sát toàn bộ các ứng dụng trên cloud. Nhân sự tham gia dự án này là các chuyên gia đã có nhiều kinh nghiệm triển khai các công cụ giám sát on-prems, các nhân sự Cloud có chuyên môn cao, nhân sự “cứng” từ mảng database administration (DBA) và từ bộ phận an ninh thông tin.

Ngay từ đầu tháng 1, team centralize monitor được thành lập và tiến hành nghiên cứu các giải pháp, và rất nhiều phương án đã được đưa ra.

Phương án 1: Sử dụng dịch vụ AWS CloudWatch Cross-account Observability

Trong cách này, chúng ta sẽ có một AWS account gọi là “monitoring account” và được liên kết với nhiều AWS account khác gọi là “source accounts”.

Monitoring account là AWS account tập trung có thể quan sát và tương tác với các dữ liệu monitor được tạo ra bởi các “source accounts”. Một “source account” là 1 AWS account riêng lẻ, nơi dữ liệu giám sát (monitor) được tạo ra và các dữ liệu này sẽ được chia sẻ (share) với “monitor account”. Các dữ liệu “share” này bao gồm:

• CloudWatch Metric
• CloudWatch Log
• AWS X-Ray trace

Phương án thiết kế này có ưu điểm:

• Tận dụng được “source data” là những dữ liệu giám sát có sẵn trong giai đoạn migration
• Team sẽ thiết lập AWS monitor account, lấy dữ liệu từ các “source account” và tạo ra các monitor dashboard và các alarm/alert tương ứng.

Như vậy,  đây là giải pháp đơn giản, chỉ là được nâng cấp (enhanced) từ nguồn dữ liệu có sẵn, cần ít thời gian và nguồn lực để triển khai.

Tuy nhiên, phương án này cũng có một vài điểm hạn chế:

• Dữ liệu monitor metric/log nằm tại các “source accounts” rải rác ở nhiều nơi.
• CloudWatch Log chưa phải là công cụ lưu trữ và phân tích log tối ưu nhất.
• Mỗi ứng dụng sử dụng các agent monitor riêng (CloudWatch agent, Telegraf…), các monitor metrics chưa được chuẩn hoá. 

Phương án 2: Sử dụng bộ công cụ Centralize Monitor mới (dựa trên opensource tools) như InfluxDB, Opensearch, Grafana

Trong phương án này, nhóm chuyên gia sẽ đưa ra tiêu chuẩn cấu hình giám sát (monitor ở từng bước

• Về  centralized tool: 
  • InfluxDB (“receive monitor metric”): là công cụ tập trung toàn bộ chỉ số (metrics) của 30 ứng dụng (application) đã được di dời lên cloud.
  • Opensearch (“receive log”): là công cụ tập trung toàn bộ log của 30 ứng dụng (application) đã được di dời lên cloud.
  • Grafana: là 1 công cụ tập trung để tạo ra các màn hình giám sát (Monitoring dashboard) cho toàn bộ 30 ứng dụng. Tại đây người dùng cuối (đội CloudOps, AppOps, Security…) sẽ theo dõi tình trạng sức khỏe cũng như như trạng thái của từng ứng dụng (app có online không, các chỉ số về memory, CPU, ổ đĩa, lượng yêu cầu…) Khi một chỉ số bất kì vượt ngưỡng (được quy định từ trước), công cụ này sẽ gửi cảnh báo (alert) tới các bộ phận liên quan qua email, hoặc qua kênh Microsoft Teams. 

• Về agent thu thập metric/log:
  • Telegraf: thu thập monitor metric từ các máy chủ (EC2) hoặc cụm EKS rồi gửi data này về InfluxDB với các chỉ số được đưa ra ngay từ đầu như CPU Usage, Memory Usage, Disk Usage… với quy ước đặt tên metric chuẩn, chung cho toàn bộ 30 ứng dụng.
  • Fluentbit: thu thập application log từ các máy chủ (EC2) hoặc cụm EKS rồi gửi data này về Opensearch.
  • CloudWatch metric stream: thu thập montior metric từ các dịch vụ AWS khác (Load Balancer, RDS, SNS, S3…) rồi gửi data về InfluxDB (thông qua Lambda function).
  • CloudWatch Log subscription filter: thu thập log từ các dịch vụ AWS khác (RDS, Redis,…) rồi gửi data về Opensearch (thông qua Lambda function).

Như vậy, với cấu hình như trên, phương án này cũng có các ưu điểm, nhược điểm như sau:

Ưu điểm:

• Cách lấy metric monitor/log được thống nhất cho toàn bộ 30 ứng dụng
• Dữ liệu montior/log đã được lọc tại nguồn, chỉ những dữ liệu cần thiết được stream tới các centralized tool, sẽ giúp tiết kiệm chi phí lưu trữ và phân tích dữ liệu. Đây có thể coi là “kho dữ liệu sạch”, là cơ sở để chúng ta có thể phân tích, điều tra, khắc phục các sự cố cũng như giúp chúng ta có thể nghiên cứu để đưa ra các giải pháp tối ưu hơn về mặt performance/giảm chi phí cho từng ứng dụng trong tương lai.

Nhược điểm: 

• Việc cấu hình lại toàn bộ monitoring tool chain (bao gồm xử lý dữ liệu từ nguồn, stream về centralized tool) cho cả 30 ứng dụng sẽ tốn nhiều thời gian và công sức thực hiện. Tuy nhiên với những ưu điểm của giải pháp này thì nhược điểm này hoàn toàn chấp nhận được. 

Sau khi có 2 phương án, team đã trình ý tưởng để lấy ý kiến và phê duyệt từ các Giám đốc khối và Solution Architecture team, và quyết định chọn phương án số 2 để đưa vào triển khai. 

Từ tháng 3, team bắt đầu triển khai môi trường kiểm thử (UAT), bắt tay xây dựng Centralized Monitor: Xin mở tài khoản AWS cho dự án, tạo các máy chủ EC2, cài đặt InfluxDB, Opensearch cluster, Grafana. Việc cài đặt InfluxDB và Grafana tương đối dễ dàng, còn cài đặt Opensearch cluster thì khó khăn hơn vì độ phức tạp của nó. 

Sau khi Centralized Monitor “thành hình”, team bắt đầu tiến hành cài đặt “stream” metics/log từ các application đầu tiên về Centralized Monitor này. Việc cấu hình các agent như Telegraf/FluentBit khá đơn giản, còn việc stream native AWS metrics/log thì khó khăn hơn, vì phải yêu cầu viết code Lambda function. Với sự làm việc khẩn trương của các thành viên, cuối tháng 4, ba ứng dụng đầu tiên đã tích hợp với Centralized  Monitor, đánh dấu bước phát triển mới trong nỗ lực hoàn thiện bức tranh Cloud của toàn hàng.

Thuộc dự án “Inside GemTechnology“ do TopDev hợp tác cùng Techcombank triển khai, chuỗi nội dung thuần “Tech” độc quyền được chia sẻ bởi đội ngũ chuyên gia Công nghệ & Dữ liệu tại Techcombank sẽ được cập nhật liên tục tại chuyên mục Tech Blog | Techcombank Careers x TopDev. Cùng theo dõi & gặp gỡ các chuyên gia bạn nhé!

Các cơ hội việc làm tại Techcombank

Senior Cloud Engineer

Quận Hoàn Kiếm, Hà Nội

Ngân Hàng

Đăng nhập để xem mức lương

DevOpsAWSCloud

Ứng tuyển

Bài viết liên quan

Triển khai Cloud tại Digital Banking: Đâu là yếu tố để đảm bảo chuyển đổi thành công?

Công nghệ Đám mây (Cloud) đã trở thành một phần không thể thiếu trong các nền tảng lớn hiện nay. Với vai trò ngày càng quan trọng và phức tạp, điện toán đám mây đặc biệt được chú trọng trong lĩnh vực tài chính. Không nằm ngoài cuộc chơi, các ngân hàng lớn tại Việt Nam cũng đang tiến hành quá trình chuyển đổi số cho toàn bộ hệ thống của mình. Chị Elizabeth Nguyễn, một Quản lý Dự án Cao Cấp - Dự án Cloud tại Techcombank, sẽ mang tới những chia sẻ giúp chúng ta hiểu được tầm quan trọng của công nghệ Cloud trong công cuộc chuyển đổi số của lĩnh vực tài chính ngân hàng. Dịch vụ Cloud giải quyết gì cho bài toán kinh doanh (business) nói chung & bài toán nghiệp vụ ngân hàng (banking) nói riêng?  Một trong những lý do quan trọng nhất cho việc chuyển đổi sang Cloud của Techcombank là [...]

Lập TrìnhTechcombank

Chi tiết