10 Mẹo bạn có thể tối ưu chi phí sử dụng AWS Cloud

Triết lý cốt lõi của AWS nói riêng hay các nền tảng đám mây khác như Google đó chính là sử dụng tới đâu trả tiền tới đó (Pay as you go) so với truyền thống là mua phần cứng / phần mềm theo sizing ở mức trần (mua tối đa sử dụng không phải lúc nào cũng tối đa). Hơn hết, business thay đổi biến động từng ngày, sự đáp ứng của dịch vụ cntt theo cách truyền thống là không đáp ứng kịp. Đây là một trong những lý do doanh nghiệp chuyển đổi lên cloud để việc chuyển đổi được nhanh chóng, tự động hơn.

Nhưng không phải chuyển đổi lên Cloud nào cũng dễ dàng và gặp sự thuận lợi ngay từ ban đầu. Trong các best practice luôn cần phải có Executive Support, IT team và thậm chí Business team cần có cloud adoption, có tư tưởng Cloud First trong hành động. Trong các dự án chuyển đổi cloud càng phải đặc biệt chú ý về việc này vì có thể tạo các negative impression không tốt.

Việc chuyển đổi một dịch vụ, ứng dụng lên cloud phát sinh chi phí cao có thể nằm trong một những nguyên nhân sau (hoặc kết hợp):

  1. Lift And Shift Story – Chiến lược chuyển đổi chưa tận dụng sức mạnh của các dịch vụ AWS / Cloud khác. Ví dụ bạn chỉ chuyển đổi đơn giản lift and shift thì chi phí lúc ban đầu có thể sẽ cao hơn nếu ứng dụng bạn chạy 24/7, bạn phải mua thêm đường Direct Connect (DX) để kết nối on-premises đến AWS Cloud. Personally, Về lâu dài việc chuyển đổi Cloud nên có tầm nhìn tổng thể, top-down model, việc sử dụng các kiến trúc lai sẽ khó tận dụng hoàn toàn sức mạnh của native cloud. Chuyển đổi cloud cần là một chiến lược dài hơi, chuyển đổi từ từ, hướng đến sử dụng các dịch vụ native thông qua định hướng rearchitect / refactor.
  2. Cloud Knowledge Adoption – Các dịch vụ AWS rất hay ho và trưởng thành để sử dụng. Việc sử dụng cần có kiến thức kinh nghiệm để chọn các kiến trúc đúng, triển khai đúng đắn để tránh phải đau khổ khi “méo, sao cái này chạy đắt vậy?”, “Sao thấy cái này rẻ lắm mà, giờ chạy ra thế này…” tựu chung lại bạn không hiểu mình đang làm cái gì, tạo ra cái gì chỉ hiểu là nó chạy được còn bản chất nó đang acquire những dịch vụ nào thì cũng chưa rõ. Bạn cần nắm rõ về architect, cần hiểu rõ về pricing catalog, pricing factors… Personally, mình nghĩ là các bạn nên trang bị đủ kiến thức, thử chạy lab trước ở một scale vừa phải trong thời gian 1-2 tháng để xem 1-2 cycle tính giá của AWS thế nào. Và tốt nhất là bạn nên có sự tư vấn của một đơn vị chuyển đổi cloud để đảm bảo mọi thứ được smoothly nhất có thể.
  3. Well Architected – AWS có một Well Architected Framework rất hay và một trong những giá trị nó đem lại là tối ưu chi phí (Cost Optimization) khi đã đưa vào vận hành. Ở điểm này doanh nghiệp có thể cần một đơn vị tư vấn hoặc đội DevOps đủ mạnh để tối ưu. Ngoài ra, Architect luôn cần được review để xem tối ưu hơn. VD: gần đây mình có sử dụng AWS Lambda để xử lý các batch và thấy rằng mỗi batch này số lượng records rất biến động (Có thể vài nghìn records, có cái lên tới cả 100 nghìn records) nếu mình chỉ cứng nhắc sử dụng 1 lambda cấp phát 512MB RAM (mặc định 128MB) thôi thì sẽ lãng phí / thiếu năng lực xử lý trong một số trường hợp. Mình làm lại và chọn một Lambda router để chọn các Lambda xử lý to hay nhỏ tùy theo khối lượng công việc. Lambda sinh ra để làm các dịch vụ serverless mạnh mẽ, ảo diệu, với các hệ thống lớn Lambda có thể được gọi hàng triệu lần / ngày, bù lại Lambda cũng khá là rẻ ^^ Tóm cái váy lại là, công nghệ luôn luôn có thể cải tiến tốt hơn nữa, là người làm công nghệ luôn luôn tìm cách tối ưu tạo ra kết quả tốt hơn với chi phí rẻ hơn.

Ok, lan man khá nhiều rồi, phần tiếp theo Gà sẽ chia sẻ những kinh nghiệm bản thân mình học được cũng như vấp phải khi sử dụng các dịch vụ của AWS, hi vọng giúp ích cho các bạn trong lúc bắt đầu với AWS Cloud.

1/ Luôn phải bật Cost & Usage Report

AWS cung cấp rất nhiều công cụ cảnh báo về cost và nó sẽ giúp bạn gởi các cảnh báo khi gần tới định mức theo cấu hình. Có thể báo theo dạng forecast. Đây là việc mình luôn làm khi mới tạo một tài khoản AWS và add credit card.

Để truy xuất bạn vào: My Account / Cost & Usage Report

Ý nghĩa là khi bạn dùng đến hạn mức nào đó (giả sử 100$) hệ thống sẽ báo bạn trước bao nhiêu % (Giả sử 80%).

Đây là một việc rất đơn giản nhưng quan trọng, đầu tiên mình chủ quan ko làm nó và tiêu tốn của mình 700$ trong vòng 1 tuần ở một dịch vụ mà mình ko hề aware về nó. Ruột đau như cắt, nước mắt đầm đìa.

2/ Tận dụng tối đa AWS Free Tier

AWS offer có 3 loại free:

  1. Always free là các dịch vụ được miễn phí trọn đời theo một hạn mức nào đó. Ví dụ Amazon Lambda có 1 triệu lần gọi một tháng, 25 Read và Write capacity.
  2. 12 Months Free: các dịch vụ được free theo năm ví dụ EC2, S3…
  3. Trial là các dịch vụ mới đưa ra dùng thử.

Một số dịch vụ free trọn đời khá ngon lành như Lambda, Dynamo DB (một dạng NoSQL) bạn nên tìm cách tận dụng tối ưu chúng. Tham khảo thêm: https://aws.amazon.com/free

Free Tier thông thường ở scale nhỏ. Nếu doanh nghiệp bạn nhu cầu lớn hơn có thể dùng free tier cho môi trường dev, hay kiểm thử các tính năng trước khi lựa chọn vào kiến trúc enterprise. Với các doanh nghiệp vừa và nhỏ, nếu cân nhắc có thể free tier phù hợp nhu cầu (bèo nhất cũng được 1 năm miễn phí nếu biết cách sử dụng và dịch vụ phù hợp nhu cầu).

3/ Sử dụng thành thạo AWS Cost Explorer

AWS Cost Explorer là một công cụ nằm trong phần My Account luôn, bạn nên nghía qua nó. Nói chung các giao diện quản trị của AWS dễ dùng nếu bạn có kiến thức một chút về IT. Ở phần Cost & Usage Report trên bạn chỉ xem được tổng tiền thông qua report hàng ngày. Còn chi tiết số tiền đó tiêu dùng thế nào bạn sẽ cần vào AWS Cost Explorer.

Ví dụ: Cost & Usage Report bạn dùng hết $10. Thì bạn vào trong AWS Cost Explorer để xem chi tiết thì thấy $10 này là gồm có $4 EC2, $2 S3 và $4 Amazcon Connect chẳng hạn.

Điểm mạnh của AWS Cost Explorer ngoài xem chi phí theo AWS services, AWS Account, nó còn hỗ trợ theo dạng tag. Vd: Bạn tạo một tài nguyên bạn có thể đánh dấu tag vào tài nguyên đó (dạng thẻ metadata). VD: Bạn có thể đánh dấu tag theo environment (env: dev or env: production), đánh dấu tag theo người tạo (author: iga), đánh dấu tag theo phòng ban (dept: PMO)…

Sau khi đánh dấu tag, bạn có thể xem chi phí theo các tag này từ đó có những chính sách hay cải tiến phù hợp tiết kiệm chi phí.

Mình khuyên khi mới bắt đầu xây dựng hệ thống nên nghĩ về plan đánh tag một cách thông minh và toàn diện, sau này phân hoạch tài nguyên và tối ưu chi phí cũng sẽ dễ dàng.

Một số giới hạn AWS Resource Tag Limits:

  1. Tối đa: 40 tags
  2. Unique (Không trùng tên)
  3. Single Value (Mỗi tag chỉ có 1 value, không có dạng array)
  4. Maximum key length: 128

Với AWS Cost Explorer bạn có thể xem chi phí theo resource level. VD bạn có thể xem chi phí trên từng EC2 instance ID hết bao nhiêu tiền… Hay bạn có thể xem Top các tài nguyên sử dụng nhiều nhất hệ thống, từ đó tối ưu hóa chi phí hơn.

Ví dụ: bạn thấy hệ thống web của công ty lúc nào cũng dùng tối thiểu 4 instances (2 web, 2 DB), cao điểm thì có thể lên tới 6 máy chủ theo cơ chế Auto Scaling. Lúc này bạn có thể xác định mua 04 EC2 instances với dạng là Reserved, thay vì lúc nào cũng dùng On-demand sẽ đắt đỏ. Khi mua Reseved bạn có thể tiết kiệm tới 72% tùy thuộc Instance Family mà bạn dùng và số năm mua Up-front.

4/ Xác định tần suất các EC2 chạy => Mua Reserved, On-demand, hay Spot

Điều này đơn giản nhưng các bạn IT đừng lười, xác định base-line mình cần bao nhiêu EC2, loại EC2 gì (instance family), tần suất sử dụng trong tuần / trong tháng thế nào. Từ đó có chiến lược mua Reserved.

Các ứng dụng có biến động mới sử dụng dạng On-demand (thường chi phí ko rẻ).

Với các ứng dụng background, không có tính bắtt buộc giả sử dụng batch job, cron job, ETL bạn có thể kết hợp sử dụng với Spot instance với giá bid thấp.

Personally, mình thời gian đầu còn hay dùng EC2 do một số đặc thù có thể có ở khách hàng, về lâu dài mình ko còn sử dụng EC2 mà chuyển sang các kiến trúc dựa trên server-less. Đây cũng là một lesson learns để tiết kiệm chi phí doanh nghiệp.

Ở phía ngược lại, có một số ứng dụng chạy sẽ không tiêu tốn nhiều tài nguyên, mình có thể giảm EC2 instance để kiếm con nào phù hợp rẻ hơn. VD mấy cái website thông tin bèo bèo ngày dăm ba nghìn lượt truy cập thì mình có thể sử dụng t2micro vừa miễn phí, vừa đạt được yêu cầu.

5/ Xác định các volume EBS có tần suất sử dụng thấp

Tương tự thế ko phải EC2 gắn với EBS nào cũng sử dụng hết công năng (IOPS và Storage size). Tham khảo thêm AWS Trusted Advisor Best Practice. Việc giảm dung lượng EBS cũng giúp phần giảm dung lượng snapshot khi bạn dùng Data LifeCycle Manager.

6/ S3 Lifecycle Policy 

S3 có rất nhiều tier với mục đích lưu trữ khác nhau, từ Standard, Infrequency Access (IA), Intelligent Tiering, One-Zone, Glacier… Bạn nên ngó qua cách sử dụng một số ý tưởng sau:

  1. S3 Analytics – Phân tích các data pattern theo khung 30 ngày hoặc lâu hơn.
  2. Sử dụng S3 Infrequency Access cho các dữ liệu lâu hơn 30 ngày
  3. Sử dụng Intelligent Tiering tự động phân tích và move các dữ liệu giữa các tier phù hợp.
  4. Thiết lập Lifecycle Policy cho dữ liệu.

7/ Redshift / RDS Utilization check

Kiểm tra các RDS hay Redshift có tần suất sử dụng ít. Bạn có thể tham khảo Amazon Trusted Advisor hay Redshift Cluster Check để định danh cluster nào không có connection kết nối trong 1 tuần gần nhất, hoặc theo CPU Utilization.

8/ Không phải cái gì cũng dùng Dynamo được

Dynamo là AWS Property nên cá nhân mình thấy AWS rất đề cao dịch vụ này và mình thấy nó tốt thật. Nếu như nghĩ Dynamo là NoSQL thì có thể bạn sẽ bị nhầm vì khi đi vào triển khai Dynamo mình đã gặp một số vấn đề mà ứng dụng mình triển khai ko phù hợp. Ví dụ mặc định mỗi table trong Dynamod bạn sẽ thiết lập 02 khóa (Partition Key và Sort Key) sau này mình query thì cũng chỉ trên 02 khóa này, nếu mình muốn query trên các field khác thì mình phải dùng đến Global Secondary Indexes, và điều này bạn phải trả thêm tiền từ mỗi lần Read or White trên khóa đó.

Giới hạn của Global Secondary Indexes cho mỗi table là 20 khóa cũng là một giới hạn hơi thốn. Dynamo phù hợp với các dịch vụ mà tỷ lệ đọc gấp nhiều lần ghi và việc query là GetAll thì chi phí và hiệu năng sẽ rất tốt.

Trong trường hợp Dynamo thực sự fit với nhu cầu sử dụng của bạn cũng cần phải xem năng lực đọc ghi (Write capacity và Read capacity) cần thiết thế nào cho ứng dụng của bạn. Bạn có thể xem thông số này trong CloudWatch và Autoscaling theo nhu cầu sử dụng để tối ưu chi phí thông qua việc pay-per-request.

9/ Xóa các Idle Load Balancers

Thói quen ban đầu của mình là cứ tạo ra rồi để đó khiến cho chi phí tiềm ẩn rất cao. Mà có thể cuối tháng mới ngỡ ra thì đã muộn. Mặc định bạn có thể tạo 50 Application Load Balancers or Network LB / Region, 20 Classic Load Balancers / Region. Nếu bạn không xóa các ELB ít sử dụng hoặc gộp lại thì có thể phát sinh một khoản chi phí không nhỏ.

Đối với các ứng dụng facing internet, đặc biệt web, bạn có thể cân nhắc kết hợp với CloudFront để tối ưu chi phí và tốc độ.

10/ Sử dụng Compute Saving Plans

Compute Saving Plans có thể ứng dụng cho các EC2 instance theo family, size, AZ, Region, OS, tenancy, và cũng ứng dụng cho Fargate, Lambda. Sử dụng 1 năm với No-Upfront có thể tiết kiệm tới 54% khi so với On-demand.

Khi lựa chọn Compute Saving Plans, tất cả các sử dụng liên quan compute sẽ được tiết kiệm ở giá discounted, mọi việc xài vượt sẽ tính theo On-demand.

 

Kết luận

Bạn hãy học và sử dụng, bắt đầu với free-tier trước, cũng phải trải qua vài lần “ngu” thì mới khôn ra được. Hy vọng trên đây là một số thứ mình học và trải nghiệm được. Mong nhận được chia sẻ thêm từ các bạn sử dụng AWS nhé.

igà

 

Topics #aws #cloudfront #dynamo #free tier #lambda #rds #redshift