Cẩm nang giúp bạn kiểm soát hiệu quả chi phí khi sử dụng AWS Managed Services

Trong hai thập kỷ gần đây, các công ty càng lúc càng chuộng cung cấp phân bổ tài nguyên, hạ tầng theo nhu cầu và hoạt động. Xu hướng đó đang đi lên cùng với sự phát triển các dịch vụ được AWS quản lý – AWS managed services.

Bắt đầu với bộ nhớ, tiếp theo là máy chủ ảo, bộ nhớ của máy chủ ảo. Và cuối cùng là mô hình ‘Pay As You Go’ trên đám mây, nơi bạn có thể sử dụng lượng tài nguyên theo nhu cầu và chỉ thanh toán cho những gì bạn đã dùng. Điều này đưa chúng ta đến kỷ nguyên với các dịch vụ đám mây được quản lí chặt chẽ.

Ngày nay, các dịch vụ đám mây cung cấp cho khách hàng khả năng linh hoạt cao chỉ trả cho những gì sử dụng. Nhưng nhu cầu lớn sẽ đi kèm với con số hóa đơn tương ứng. Khi mới vừa bắt đầu, chúng ta thường được các nhà cung cấp dịch vụ vẽ ra một viễn cảnh sẽ giúp tiết kiệm rất nhiều chi phí đầu tư Capex (capital expenditure). Rõ ràng đó là đề xuất tuyệt vời cho các công ty khởi nghiệp, khi mục tiêu của các công ty này là đạt được nhanh nhất các mục tiêu phát triển với chi phí tài nguyên và nhân lực thấp nhất. Nhưng sau cùng, những chi phí này rồi sẽ sớm vượt quá giới hạn ngân sách khi quy mô công ty càng lúc càng lớn.

Do đó, khi công ty càng phát triển, việc liệt kê và tính toán các chi phí tiềm ẩn cho các dịch vụ đám mây càng trở nên quan trọng.

Thêm nữa, bạn cũng cần hiểu các tình huống có thể xảy ra khi hạ tầng không còn được kiểm soát chi phí hoặc không thể đáp ứng được nhu cầu công việc của bạn. Dưới đây là một số dịch vụ được quản lý đầy đủ phổ biến nhất mà các nhà cung cấp dịch vụ đám mây cung cấp ngày nay:

1. Cơ sở dữ liệu được quản lý như Aurora Serverless và DynamoDB.
2. Serverless (Function as a services, API Gateway, ..).
3. Các giải pháp phân tích được quản lí (MSK, EMR,…).
4. Các hạ tầng được quản lí (như AWS Fargate và AWS Batch).

Tại bài viết này, chúng tôi sẽ đề cập đến một số dịch vụ quản lý AWS phổ biến và thông tin về các trường hợp ứng dụng thường gặp cũng như chi phí tiềm ẩn của dành cho các công ty đang phát triển. Tôi sẽ trình bày các hướng dẫn để các khách hàng yêu cầu các công ty dịch vụ đám mây ước tính cấu trúc hệ thống. Cũng như lường trước được một số chi phí tiềm ẩn phổ biến.

1.DynamoDB

DynamoDB (DDB) là một dịch vụ quản lý cơ sở dữ liệu độc quyền, hoàn toàn sử dụng NoSQL có hỗ trợ giá trị khóa và cấu trúc dữ liệu tài liệu. Được cung cấp như một phần của gói dịch vụ AWS.

Trong đa số trường hợp, việc triển khai và mở rộng một cơ sở dữ liệu mới yêu cầu bạn phải  sắp xếp và tái cấu trúc các phần cứng và phần mềm chính. AWS DynamoDB sẽ giúp bạn loại bỏ rào cản này bằng cách tự động điều chỉnh dung lượng. Để đáp ứng yêu cầu từ khối lượng công việc và hỗ trợ chia nhỏ dữ liệu khi mô hình kinh doanh của bạn được mở rộng. Bên cạnh đó, vì sao chép dữ liệu qua ba vùng trong AWS Region, nên khả năng sẵn sàng và mức độ an toàn dữ liệu cũng cao hơn.

Hàng nghìn công ty sử dụng DDB làm cơ sở dữ liệu chính của họ, bao gồm cả Amazon.com. DDB là một trong những dịch vụ dữ liệu NoSQL được quản lý hoàn toàn đầu tiên được xây dựng trên đám mây. Để hỗ trợ cho các ứng dụng đám mây với độ trễ chỉ tính bằng mili giây. DDB cũng cung cấp các ứng dụng đồng bộ toàn cầu giúp bạn nhân bản bảng dữ liệu sang nhiều khu vực. Nhằm phục vụ tốt hơn cho nhu cầu của các khách hàng ở xung quanh bạn.

Mặc dù DDB là một dịch vụ dữ liệu NoSQL được AWS quản lý, nhưng bạn cần biết một số hạn chế về tính năng sau đây để đảm bảo rằng chi phí của bạn sẽ luôn hiệu quả theo thời gian. Dưới đây là một số mẹo cần phải ghi nhớ:

1. Sử dụng S3 và để lưu trữ các tài liệu lớn hơn 400KB:

   Kích thước tài liệu trong DDB được giới hạn ở 400KB. Vì vậy bạn sẽ cần sử dụng S3 để lưu trữ các tài liệu lớn hơn giới hạn đó.

2. Hiểu chi phí sử dụng GSI và LSI:

   Việc sao chép dữ liệu trong Global Secondary Indexes (GSI) và Local Secondary Indexes (LSI), có thể gây tốn kém một khoảng lớn. Điều này xảy ra mỗi khi bạn cập nhật dữ liệu bởi vì khi đó, các bản sao của bạn cũng phải được cập nhật theo. Và khi đó, bạn phải trả thêm chi phí sao chép dữ liệu.

3. Không thể áp dụng điều khoản DDB cho các bản sao Global Table:

   Global Tables được xây dựng dựa trên nền tảng của Amazon DynamoDB toàn cầu, đem đến cho bạn dịch vụ được quản lý hoàn toàn, nhiều vùng và nhiều cơ sở dữ liệu đang hoạt động đồng thời. Giúp tăng nhanh hiệu suất đọc và ghi nhanh không chỉ hệ thống cục bộ mà còn mở rộng trên toàn cầu. Giải pháp này là lý tưởng để khắc phục thảm họa. Nhưng thật không may, bản sao Global Table không thể áp dụng cho DDB. Do vậy, việc sử dụng Global Table sẽ không được giảm giá.

4. Đảm bảo rằng bạn hiểu khối lượng công việc của mình trước khi sử dụng DDB:

   Dự đoán khối lượng công việc của bạn (hoặc kiểm tra nhanh được điều đó trong vài ngày) có thể giúp bạn tiết kiệm tới 50% hiệu suất Đọc và Ghi (WCU và RCU) khi bạn mở rộng quy mô với DDB. Các khoản tiết kiệm này là do bản chất của việc trích lập dự phòng DDB. DDB cung cấp hai lựa chọn: Theo nhu cầu hoặc Tự động mở rộng. Phương án theo nhu cầu đem đến hiệu suất cao nhất, nhưng điều này, tất nhiên kèm theo mức giá cao hơn. Bên cạnh đó, phương án Tự động mở rộng sẽ rẻ hơn nhưng đồng thời nó chỉ cho phép bạn mở rộng dung lượng trần bốn lần mỗi ngày, điều này có thể dẫn đến việc trả tiền cho dung lượng mà bạn không sử dụng. Ngoài ra, tính năng Tự động mở rộng sẽ không đáp ứng được các nhu cầu cao đột ngột, khiến cho hệ thống của bạn trở nên chậm chạp và bị động. Tuy nhiên, bằng cách nắm rõ nhu cầu công việc của mình, bạn có thể tận dụng lợi thế giảm giá từ tính năng tự động mở rộng so với tính năng theo nhu cầu.

5. Sử dụng DAX để tăng Hiệu suất DynamoDB:

   Người dùng DynamoDB có thể tận dụng DAX, một giải pháp Managed ElastiCache, để cải thiện số lần đọc. Nhưng như mọi khi, bạn chỉ nên sử dụng nó sau khi đã tối ưu hóa các yêu cầu của mình, nếu không, nó sẽ còn đắt hơn bình thường. Một tùy chọn mà AWS đề xuất là sử dụng song song, đòi hỏi phải chia nhỏ các yêu cầu thành các yêu cầu nhỏ hơn.

2.Amazon Aurora

Amazon Aurora (Aurora) là một dịch vụ cơ sở dữ liệu quan hệ được quản lý hoàn toàn, tương thích với MySQL và PostgreSQL. Amazon đã xây dựng công cụ Aurora cách đây bảy năm để xử lý một trong những điểm nghẽn lớn nhất trong hiệu suất lưu trữ các dữ liệu quan hệ. Công cụ Aurora tách biệt hai chức năng tính toán và lưu trữ. Với Aurora, AWS có thể quản lý bộ nhớ cho cả IOPS và dung lượng – một tính năng rất hữu ích. Nhưng thật không may, nó khiến bạn rất khó dự đoán chi phí sẽ phát sinh trong tương lai từ các cụm cơ sở dữ liệu của mình.

Bởi vì Aurora có kiến ​​trúc rất khác so với các EBS bình thường, việc đọc dữ liệu trên một cơ sở dữ liệu không tương đương trên các tập EBS. Do đó, khi bạn bắt đầu sử dụng Aurora, bạn không thể dự đoán được chỉ số đọc / IOPS sẽ như thế nào, gây khó khăn cho việc ước tính giá trị hóa đơn. Cách tốt nhất để ước tính IOPS là chạy POC trên Aurora và đo số lượng IOPS. Bằng cách này, bạn sẽ hiểu rõ hơn về chi phí tiềm ẩn có thể xảy ra.

Amazon Aurora cũng cung cấp dịch vụ Serverless (Version 2) cung cấp hệ thống quản lí cho cơ sở dữ liệu PostgreSQL và MySQL Relational. Nền móng của Aurora Serverless là nhận được các tính toán và lưu trữ được AWS quản lý. Điều này có ý nghĩa nếu bạn muốn bắt đầu với một với kinh phí nhỏ và phát triển khi nhu cầu của bạn tăng lên, bạn phải tập trung vào việc xây dựng các ứng dụng thay vì cơ sở hạ tầng. Mặc dù sử dụng Aurora có rất nhiều lợi ích, cả Aurora và Aurora Serverless đều có một số nhược điểm sau đây:

1. Sử dụng Aurora Serverless rất tốn kém trừ khi bạn có kế hoạch sử dụng cho các khối lượng công việc không yêu cầu chạy vào cuối tuần. Nếu bạn đang có kế hoạch vận hành cơ sở dữ liệu của mình 24/7, việc sử dụng Aurora hoặc RDS sẽ có hiệu quả cao hơn.
2. Không có quyền truy cập root. Điều này đúng với cả RDS và Aurora. Trong một số trường hợp, bạn sẽ cần quyền truy cập root để kết nối với cơ sở dữ liệu của mình. Nhưng rất tiếc, điều này không thể đạt được với các cụm Aurora. Điều này có thể ảnh hưởng đến khả năng hiển thị và phân tích nguyên nhân gốc rễ.

3.AWS Fargate

AWS Fargate là một nền tảng Serverless chỉ yêu cầu bạn phải trả tiền theo phương thức pay-as-you-go. Điều đó cho phép bạn tập trung vào việc xây dựng ứng dụng mà không cần phải bận tâm đến việc quản lý máy chủ.

AWS Fargate tương thích với cả ECS (Amazon Elastic Container Service) và Amazon EKS (Amazon Elastic Kubernetes Service). AWS Fargate là một máy chủ ảo để triển khai và quản lý containers mà không cần bất kỳ cơ sở hạ tầng cơ bản nào. Fargate giúp bạn dễ dàng mở rộng quy mô ứng dụng của mình bằng cách khởi chạy hàng chục đến hàng chục nghìn containers chỉ trong vài giây.

Mặc dù điều này nghe có vẻ tuyệt vời, Fargate có một số hạn chế mà bạn cần lưu ý:

1. Khi vận hành Theo nhu cầu, bạn có thể thấy Fargate rất tốn kém. Để giải quyết vấn đề này, bạn có thể mua các Gói tiết kiệm để vẫn xử lí được công việc với chi phí phù hợp.
2. Với Fargate, bạn không cần phải quan tâm đến bất kì thông số kỹ thuật nào của cơ sở hạ tầng. Điều này có nghĩa là bạn chỉ cần bộ nhớ và CPU. Kết quả là, hiệu suất thường tốt hơn với EC2. Tuy nhiên, một số khách hàng sẽ thấy hạn chế này là yếu tố cản trở việc áp dụng Fargate.

Khắc phục sự cố Fargate khá phức tạp. Vì bạn không có tầm nhìn đầy đủ về cơ sở hạ tầng, bạn có thể gặp khó khăn trong việc tìm ra nguyên nhân gốc rễ của các vấn đề về hiệu suất, điều này có nghĩa là bạn có thể cần liên hệ với bộ phận hỗ trợ AWS để khắc phục các vấn đề nếu chúng phát sinh. Ngoài ra, vì bạn không có quyền truy cập vào các containers, hãy đảm bảo bạn đã xuất mọi thứ xung quanh môi trường được triển khai (tức là chỉ số, nhật ký, v.v.) được giám sát và ghi nhận trên CloudWatch.

4.Lời kết

Sử dụng các dịch vụ được quản lý hoàn toàn đem lại ưu điểm vượt trội cho các startup khi mà họ thiếu tất cả các nguồn lực để phát triển. Nhưng bạn cần lưu ý rằng, khi đạt đến một mức quy mô nhất định, các giải pháp này thường sẽ trở nên rất tốn kém hoặc khó bảo trì. Khi đó, để quay lại kiến ​​trúc lại cơ sở hạ tầng của mình, điều đó gần như là không thể trong bối cảnh cả hệ thống của bạn đã vận hành bài bản.

Tuy nhiên, việc triển khai cơ sở hạ tầng riêng sẽ đòi hỏi nhiều giờ kỹ thuật xung quanh việc triển khai, cập nhật, vá lỗi, giám sát bảo mật và hơn thế nữa. Điều này sẽ khiến tổ chức của bạn tốn kém cả thời gian cũng như tiền lương cho kỹ sư. Các dịch vụ được quản lý sẽ loại bỏ, hoặc ít nhất, giảm đáng kể những gánh nặng này và cho phép các kỹ sư tập trung vào các nhiệm vụ quan trọng khác của họ.

Bằng cách lập kế hoạch trước và tính đến tất cả các vấn đề này trước khi triển khai các dịch vụ quản lý, bạn sẽ được trang bị các kiến thức để tận dụng các dịch vụ này và giảm đáng kể các nhiệm vụ cho các kỹ sư trong nhiều năm tới.

Cho dù bạn có chọn sử dụng các dịch vụ được AWS quản lý hay không. ạn chắc chắn có thể hưởng lợi từ việc tự động hóa nhiều hơn. Tìm hiểu cách Renovisor có thể giúp bạn tự động hóa quản lý đám mây để bạn có thể tiết kiệm đến 60% chi phí EC2 và EBS.