Giải pháp multi-tenancy
XXX là một startup mới nổi ở Sillicon Valley. Sản phẩm của công ty được nhiều doanh nghiệp ưu chuộng nhờ khả năng bảo mật cao. Ban đầu công ty vẫn cung cấp sản phẩm theo cách truyền thống. Tức là khi có một khách hàng mới, gọi là 1 tenant, đội SRE sẽ provison một infra structure trên cloud AWS bao gồm (VPC, Server EC2, EBS, Database …) cho riêng khách hàng đó, rồi deploy ứng dụng lên infra đó. Mỗi tenant được launch sẽ có domain riêng kiểu như (tenant1.xxx.com, tenant2.xxx.com), một db riêng và một instance của software. Mọi thứ đều hoàn toàn độc lập.
Tùy vào độ lớn của từng tenants infrastructure sẽ có một số điều chỉnh cho phù hợp. Ví dụ tenant nhỏ, ít user thì sử dụng 1 server all-in-one duy nhất. Tức là application, database, services deploy toàn bộ trong 1 server để giảm cost. Còn tenant lớn, nhiều users, infra phát triển thành cụm cluster server topology, các service như hbase, mongo, elk, sẽ được deploy trên các server riêng đã giảm load cho hệ thống
Việc provisioning infra được thực hiện hoàn toàn tự động theo 1 flow trong vòng 2 tiếng
Jira ticket approved 🡪 Jenkins pipeline trigger 🡪 provisioning infra 🡪 deploy app
- Tốn chi phí, mỗi một khách hàng on-board là phải deploy một infra riêng biệt. Ước tính một năm chi phí về cloud computing lên tới 3M $
- Khả năng scaling, do infra là fix cứng 1 server hoặc 1 cụm server, khi khách hàng grown up, server bị quá tải. Phải update lại infra
- Effort bảo trì, nhiều khách hàng nhiều infra nên đội ngũ SRE engineer mât rất nhiều effort cho việc maintained, xử lý issue request từ khách hàng cho từng infra khác nhau
- Upgrade application tốn kém khả nhiều thời gian và có downtime, nguyên nhân mỗi khi update application thì phải deploy lại luôn cả phần persistent layer (phần ít khi thay đổi)
Giải pháp
Nhận thấy kiến trúc single tenant có nhiều nhược điểm, đội SRE đã quyết định thử nghiệm kiến trúc multi-tenancy để giảm chi phí. Một project được đặt biệt danh là Kronos để thực hiện
Các việc cần làm là
Chuyển đổi toàn bộ phần backend từ monolithic sang kiến trúc microservice, containerized thành docker image để có thể deploy từ server truyền thống sang nền tảng K8S, ECS có khả năng autoscale tốt hơn
Các service như hbase, mongo, elk chạy ở tầng persistence sẽ được dùng chung cho mọi tenant
Chuyển đổi infra từ EC2, Cluster sang K8S và ECS
Phần persistent layer sẽ được deploy lên server EC2 để sử dụng chung cho toàn bộ tenant. Các tenant là nơi đeploy ứng dung các microservice business logic. Microservice được build thành docker và deploy lên ECS nên leverage được khả năng autoscaling.
Cách làm này đem lại khá nhiều ưu điểm
- Chi phí đã giảm đi tới 30% do phần persistent layer được chuyển sang dùng chung
- Autoscaling vì đã chuyển từ server truyền thống sang ECS
- Việc upgrade thực hiện nhanh hơn vì mỗi khi upgrade thì chỉ cần upgrade phần microservice trên ECS, các service deploy độc lập nên hạn chế downtime
Tuy nhiên, một khó khăn mà đội dự án gặp phải đó là phần database.
- Vì tenant dùng chung database nên làm sao có thể đảm bảo data của từng tenant phải isolation và security
- Nhiều tenant nên dữ liệu tăng lên rất nhanh, phải autoscaling như thế nào
Đội dự án quyết định sử dụng mongo atlas Cloud-hosted MongoDB service on AWS thay vì tự deploy trên EC2, do thế mạnh về scaling, auto healing
Một database maestro chung được tạo chuyên để quản lý danh sách tenant như id, user, role, và mỗi tenant sẽ có 1 database riêng deploy trong mongo atlas cluster. Mỗi db có credential riêng và rotate 3 tháng một lần, đảm bảo service của tenant A không thể truy cập vào database của tenant B
Sau khi giải pháp multi-tenancy được đưa vào thử nghiệm, kết quả trong 1 năm đạt hiểu quả khá tốt khi cost đã giảm được tới 30%
Bài toán về cost được các lãnh đạo hết sức quan tâm, sau khi kí được deal với GCP, công ty XXX được phía Google offer một mức giá rẻ hơn cho với AWS lên tới 30%, cam kết sử dụng dịch vụ trong vòng 5 năm.
Một bài toán đặt ra đối với đội SRE, cần migrate toàn bộ infra hiện tại trên AWS sang GCP.
Đó đọc các phần tiếp theo
No comments:
Post a Comment