Tác giả: Andreas Gehrig, Kevin Nash và Philippe Wanner
Ngày phát hành: 26 MAR 2025
Chuyên mục: Amazon API Gateway, Amazon DynamoDB, Amazon Route 53, Amazon Simple Storage Service (S3), Architecture, AWS Cloud Financial Management, AWS Lambda, AWS WAF, Migration, Serverless, Thought Leadership

dacadoo là một công ty công nghệ toàn cầu có trụ sở tại Thụy Sĩ, chuyên phát triển các giải pháp tương tác sức khỏe kỹ thuật số và định lượng rủi ro sức khỏe. Các sản phẩm của họ bao gồm một nền tảng tương tác sức khỏe kỹ thuật số dựa trên phần mềm dưới dạng dịch vụ (SaaS) sử dụng khoa học hành vi, AI và gamification để giúp người dùng cuối cải thiện kết quả sức khỏe của họ.

Công ty đã bắt tay vào hành trình hiện đại hóa một API để định lượng dữ liệu sức khỏe và lối sống cùng với một risk engine để tính toán xác suất tử vong và bệnh tật dựa trên dữ liệu nghiên cứu khoa học trong nhiều năm.

Để chuyển đổi một dịch vụ API dựa trên máy ảo thành một giải pháp tính toán điểm sức khỏe và rủi ro có khả năng mở rộng, dự phòng toàn cầu, dacadoo đã chọn công nghệ Amazon Web Services (AWS). Dịch vụ này xử lý dữ liệu sức khỏe cực kỳ nhạy cảm từ cơ sở khách hàng toàn cầu và phải tuân thủ các quy định của khu vực.

Kết quả là giảm 78% chi phí và nỗ lực bảo trì hạ tầng dưới một giờ mỗi năm, cho phép dacadoo cung cấp và vận hành nhiều hạ tầng AWS hơn mà không cần mở rộng đội ngũ kỹ sư độ tin cậy trang web (SRE) của mình, nhờ mức độ tự động hóa cao và tư duy linh hoạt.

Trong bài viết này, chúng tôi sẽ hướng dẫn từng bước về hành trình của dacadoo trong việc áp dụng các dịch vụ được quản lý, đồng thời nêu bật các quyết định kiến trúc của họ.

Bối cảnh

Kiến trúc giải pháp đã trải qua hành trình ba giai đoạn:

1. Giai đoạn ươm mầm – Máy ảo đơn lẻ tại chỗ với khả năng khôi phục sau thảm họa (DR) ở Thụy Sĩ
2. Toàn cầu và có khả năng mở rộng – Nhiều cluster Kubernetes toàn cầu
3. Vận hành xuất sắc – Hoàn toàn serverless và dự phòng địa lý trên AWS

Giai đoạn 1: Giai đoạn ươm mầm với máy ảo

Sau nhiều năm nghiên cứu và phát triển khoa học, dịch vụ đã được ra mắt, chạy trên một máy ảo đơn lẻ tại chỗ sử dụng công nghệ hypervisor để cung cấp khả năng khôi phục sau thảm họa (DR). Tuy nhiên, nó không có khả năng high availability (HA) và yêu cầu khôi phục thủ công.

Ứng dụng phục vụ các yêu cầu API và cơ sở dữ liệu NoSQL đều chạy trên cùng một máy chủ. Triển khai phần mềm và bảo trì hệ điều hành được thực hiện thủ công bằng Secure Shell (SSH) – một thiết lập tự động hóa thấp điển hình cũng bao gồm thời gian ngừng hoạt động.

Sơ đồ kiến trúc sau đây cho thấy một máy ảo bao gồm ứng dụng nguyên khối và cơ sở dữ liệu của nó.

Hình 1: Kiến trúc nguyên khối

Thách thức

Một máy ảo đơn lẻ nhanh chóng được thiết lập và vận hành không tốn kém, nhưng nó có những hạn chế đáng kể. API sức khỏe chỉ khả dụng ở Thụy Sĩ, bảo trì hạ tầng được thực hiện thủ công và triển khai phần mềm cũng được xử lý thủ công. Ngoài ra, sao lưu cơ sở dữ liệu được thực hiện bằng snapshot máy ảo, chỉ giám sát thời gian hoạt động và thử nghiệm được tiến hành trên máy trạm của nhà phát triển.

Giai đoạn 2: Toàn cầu và có khả năng mở rộng với Kubernetes

Vào thời điểm đó, dacadoo đã đưa ra quyết định chiến lược đầu tư mạnh vào Kubernetes để quản lý các tải công việc được container hóa trên quy mô toàn cầu. Là một phần của việc triển khai công nghệ này, dịch vụ điểm sức khỏe và rủi ro đã được di chuyển sang Kubernetes.

Do cơ sở khách hàng phân tán về mặt địa lý và yêu cầu độ trễ thấp, ba cluster Kubernetes đã được triển khai, mỗi cluster trên một lục địa. Cơ sở dữ liệu NoSQL được lưu trữ gần với tải công việc để giảm độ trễ dịch vụ và giữ cho nỗ lực di chuyển ở mức thấp.

Để giảm bảo trì vận hành, cơ sở dữ liệu NoSQL đã được tích hợp dưới dạng dịch vụ SaaS và việc giám sát được tập trung hóa bằng cách sử dụng Datadog.

Toàn bộ hạ tầng đám mây được cấp phát độc quyền bằng Terraform, bao gồm cluster Kubernetes, cơ sở dữ liệu NoSQL và tích hợp với GitLab và Datadog.

dacadoo đã container hóa dịch vụ API và sử dụng các pipeline continuous integration và continuous deployment (CI/CD) của GitLab để triển khai nhiều môi trường và cluster trên một hyperscaler toàn cầu.

Nhìn lại, đây là một dự án hiện đại hóa replatform điển hình từ máy ảo sang Kubernetes, với mức độ tự động hóa cao và cách tiếp cận ưu tiên SaaS.

Sơ đồ sau đây là kiến trúc cho giải pháp container với cơ sở dữ liệu NoSQL được quản lý.

Hình 2: Kiến trúc container

Thách thức

Dịch vụ phải đối mặt với một số thách thức, bao gồm chi phí tăng lên từ việc triển khai ba cluster Kubernetes khu vực trên ba môi trường, dẫn đến 27 node cluster và các chi phí bổ sung từ việc quản lý các instance SaaS cơ sở dữ liệu NoSQL cho mỗi cluster. Sự phức tạp của các pipeline CI/CD cho việc triển khai đa môi trường, đa cluster làm tăng thêm khó khăn. Cần có nỗ lực vận hành đáng kể để giữ cho hạ tầng và các thành phần Kubernetes luôn được cập nhật.

Giai đoạn 3: Vận hành xuất sắc với serverless

Kiến trúc dựa trên Kubernetes đã đáp ứng các yêu cầu, nhưng một số tính năng trong backlog dịch vụ API của dacadoo cần phù hợp hơn với kiến trúc ứng dụng vào thời điểm đó.

Đây là thời điểm thích hợp để có cái nhìn tổng thể về kiến trúc hạ tầng và phần mềm, đồng thời tái cấu trúc giải pháp theo các công nghệ và best practice mới nhất của AWS, một biên giới tiếp theo cho đội ngũ kỹ thuật của dacadoo.

Yêu cầu giải pháp

Các yêu cầu để tái cấu trúc giải pháp như sau:

• Giữ nguyên chức năng của API
• Giới hạn xử lý dữ liệu trong một Region đã chọn để tuân thủ luật bảo vệ dữ liệu địa phương
• Tránh các chu kỳ vá lỗi hàng tuần bằng cách chỉ sử dụng các dịch vụ serverless được quản lý
• Giảm chi phí bằng cách chọn các dịch vụ với mô hình thanh toán pay-as-you-go
• Ủy quyền xác thực cho một dịch vụ chuyên dụng
• Sử dụng một framework web đã được thiết lập với hệ sinh thái mở rộng

Tái cấu trúc ứng dụng

Dịch vụ API có hai thành phần: một cổng thông tin dành cho nhà phát triển và API tính toán điểm sức khỏe và rủi ro. Cơ sở dữ liệu chỉ cần thiết cho các API key, tham số thuật toán, hạn ngạch và số liệu thống kê sử dụng. Dữ liệu sức khỏe được xử lý theo khu vực bởi lớp tính toán nhưng không được lưu trữ vĩnh viễn, mở ra cơ hội cho một cơ sở dữ liệu phân tán: Amazon DynamoDB global tables là lựa chọn hoàn hảo cho giải pháp. Các thao tác ghi được phân phối đến tất cả các Region được kết nối, trong khi các thao tác đọc là cục bộ, cung cấp độ trễ thấp để tuân thủ các thỏa thuận mức dịch vụ (SLA) của dacadoo.

Cổng thông tin dành cho nhà phát triển là một giao diện người dùng web với tài liệu API và các tính năng quản lý API key. AWS Lambda là một lựa chọn tuyệt vời vì nó tự động mở rộng quy mô và có mô hình thanh toán theo yêu cầu.

API sức khỏe và rủi ro sử dụng các thuật toán được triển khai bằng ngôn ngữ lập trình C cho các mô phỏng cường độ tính toán, bùng nổ ngắn. Các lệnh gọi này được bao bọc bởi một REST API sử dụng framework FastAPI của Python. Những đặc điểm này làm cho AWS Lambda trở thành một lựa chọn rất phù hợp.

Kiến trúc serverless

Các yêu cầu HTTP được định tuyến đến các hàm Lambda bằng cách sử dụng Amazon API Gateway với AWS WAF để bảo vệ khỏi các yêu cầu và tấn công độc hại. Các tài sản tĩnh được phục vụ từ một bucket Amazon Simple Storage Service (Amazon S3) thông qua API Gateway. Các tính năng bổ sung của Amazon CloudFront không cần thiết, và Amazon S3 giúp giảm độ phức tạp.

Amazon Route 53 cung cấp một tính năng mạnh mẽ được gọi là latency-based routing, cho phép nó định tuyến các truy vấn DNS đến endpoint cung cấp độ trễ thấp nhất cho người yêu cầu.

Tính năng này cung cấp high availability theo Region cho người dùng API mà không yêu cầu vị trí xử lý dữ liệu. Ngoài ra, người dùng có thể gọi các endpoint cụ thể theo Region để đảm bảo các yêu cầu được xử lý trong Region mong muốn.

Ủy quyền API dựa trên HTTP header và được thực hiện trong ứng dụng với dữ liệu được lưu trữ trong Amazon DynamoDB.

Sơ đồ sau đây là kiến trúc cho một giải pháp serverless hoàn toàn dự phòng địa lý.

Hình 3: Kiến trúc serverless

Với đội ngũ SRE của dacadoo thành thạo Python, họ đã chọn Pulumi vì các tính năng nâng cao của nó như các cấu trúc điều khiển luồng ngôn ngữ lập trình, khả năng cấu hình mạnh mẽ và hỗ trợ đa đám mây.

Đối với continuous integration, GitLab CI biên dịch thư viện thuật toán, kiểm tra các ứng dụng FastAPI và đóng gói mọi thứ. Việc triển khai ứng dụng chỉ là một bản cập nhật của AWS Lambda, một quy trình làm việc đơn giản và đáng tin cậy.

Tóm tắt

Giải pháp đã phát triển từ một thiết lập hạ tầng được quản lý, nơi khách hàng chịu trách nhiệm chính, sang một kiến trúc dịch vụ được quản lý của AWS.

Việc cấp phát hạ tầng đã phát triển từ các quy trình thủ công, dễ xảy ra lỗi sang các quy trình làm việc mạnh mẽ dựa trên code trong Pulumi. Đội ngũ SRE cần nâng cao kỹ năng kỹ thuật phần mềm của họ để áp dụng Pulumi, chuyển đổi từ các phương pháp tiếp cận dựa trên cấu hình sang thiết kế và duy trì cơ sở code hạ tầng bằng Python hướng đối tượng. Đây là một phần trong khoản đầu tư của dacadoo vào đội ngũ SRE và các nỗ lực hiện đại hóa rộng hơn. Kiến trúc serverless đã tạo điều kiện cho văn hóa kỹ thuật GitOps tập trung vào năng suất.

Sự chuyển đổi đã tối đa hóa khả năng mở rộng và tính sẵn sàng đồng thời giảm chi phí và nỗ lực vận hành:

Máy ảo

• Khả năng mở rộng: Thấp
• Tính sẵn sàng: Nỗ lực tốt nhất
• Chi phí hạ tầng: Thấp
• Nỗ lực bảo trì: Cao

Kubernetes

• Khả năng mở rộng: Cao
• Tính sẵn sàng: 99.95%
• Chi phí hạ tầng: Cao
• Nỗ lực bảo trì: Trung bình

Serverless

• Khả năng mở rộng: Rất cao
• Tính sẵn sàng: 99.999% (với khả năng chuyển đổi dự phòng sang một AWS Region khác)
• Chi phí hạ tầng: Thấp
• Nỗ lực bảo trì: Rất thấp

Khả năng dự phòng toàn cầu nâng cao tính sẵn sàng lên mức ấn tượng 99.999% trong khi vẫn giữ chi phí thấp.

Kết luận

Việc di chuyển từ máy ảo sang Kubernetes và cuối cùng là AWS Lambda thể hiện sự tiến bộ của kỹ thuật đám mây hướng tới hiệu quả và khả năng mở rộng nâng cao.

Mỗi bước trong hành trình này đã giảm độ phức tạp trong việc quản lý tài nguyên đồng thời tăng tính linh hoạt và tự động hóa. Việc chuyển đổi dịch vụ API của dacadoo sang kiến trúc serverless hoàn toàn, dự phòng địa lý không chỉ nâng cao nền tảng mà còn nâng cao kỹ năng của các kỹ sư, duy trì một đội ngũ SRE tinh gọn và giữ chi phí hạ tầng ở mức thấp. Bắt đầu với giải pháp serverless AWS của riêng bạn.

---

Về tác giả

Andreas Gehrig

Andreas Gehrig là Kiến trúc sư Đám mây thực chiến tại dacadoo, có trụ sở tại Zurich, Thụy Sĩ. Với nền tảng kỹ thuật phần mềm, anh chuyên tận dụng các công nghệ AWS để thiết kế và xây dựng các giải pháp cloud-native cho các ứng dụng và phân tích.

Kevin Nash

Kevin Nash là Kiến trúc sư Giải pháp Cấp cao tại Amazon Web Services (AWS), có trụ sở tại Thụy Sĩ. Với nền tảng về các hệ thống phân tán và nhiều năm kinh nghiệm xây dựng giải pháp cho khách hàng. Anh đam mê công nghệ, tìm hiểu cách các hệ thống hoạt động và giúp khách hàng đưa giải pháp của họ lên Đám mây.

Philippe Wanner

Philippe Wanner là Kiến trúc sư Giải pháp Chuyên gia Cấp cao tại AWS. Vai trò của anh là truyền bá các best practice về di chuyển và hiện đại hóa cho các tổ chức lớn. Trọng tâm hiện tại của anh là trong một lĩnh vực đa ngành xoay quanh các hệ thống phân tán, kiến trúc serverless và chuyển đổi kinh doanh.