AWS Study Group

Chuỗi bài về hành trình thích ứng Kiến trúc Cloud-Native: Bài #6 – Cải thiện khả năng hiển thị chi phí và tái kiến trúc để tối ưu hóa chi phí

Sau khi chúng tôi cải thiện tình hình bảo mật của mình trong blog thứ 5 của loạt bài này, chúng tôi phát hiện ra rằng chi phí hoạt động đang tăng cao hơn doanh thu một cách không tương xứng. Điều này là do số lượng người dùng đã tăng hơn 10 lần trên nền tảng thương mại điện tử của chúng tôi.

Để giải quyết vấn đề này, chúng tôi đã tạo một kế hoạch để hiểu rõ hơn về mức chi tiêu dịch vụ AWS của chúng tôi và xác định các khoản tiết kiệm chi phí. Trong bài đăng này, Phần 6, chúng tôi sẽ hướng dẫn cho bạn cách chúng tôi cải thiện khả năng hiển thị chi phí, sắp xếp lại để tối ưu hóa chi phí và áp dụng các biện pháp kiểm soát chi phí để khuyến khích đổi mới đồng thời đảm bảo lợi tức đầu tư được cải thiện.

Xác định các khu vực để cải thiện chi phí với Cost Explorer

Bằng cách sử dụng AWS Cost Explorer, chúng tôi đã xác định các lĩnh vực sau để cải thiện:

  • Cải thiện khả năng hiển thị chi phí và thiết lập văn hóa FinOps:
    • Cung cấp thông tin chi tiết về khả năng hiển thị và chi phí cho các tài nguyên không được gắn thẻ
    • Cung cấp khả năng hiển thị chi phí vào các tài nguyên AWS được chia sẻ
    • Hiểu rõ hơn về tỷ suất lợi nhuận gộp
  • Sử dụng Service Control Policies (SCPs) để kiểm soát chi phí
  • Tối ưu hóa chi phí truyền dữ liệu
  • Giảm chi phí lưu trữ:
    • Cập nhật các đối tượng để sử dụng lớp lưu trữ S3 phù hợp với chi phí
    • Sử dụng Amazon EBS gp3 volumes
  • Tối ưu hóa chi phí tính toán
    • Điều chỉnh tài nguyên không có hiệu quả và tài nguyên chưa được sử dụng
    • Di chuyển sang các phiên bản Graviton2 thế hệ mới nhất

Các phần sau cung cấp thêm thông tin về các phương pháp chúng tôi đã sử dụng để cải thiện những lĩnh vực này.

Cải thiện khả năng hiển thị chi phí và thiết lập văn hóa FinOps

Cung cấp thông tin chi tiết về khả năng hiển thị và chi phí cho các tài nguyên không được gắn thẻ (tag)

Để cải thiện văn hóa FinOps của tổ chức chúng tôi và giúp các nhóm hiểu rõ hơn về chi phí của họ, chúng tôi cần một công cụ để cung cấp khả năng hiển thị các tài nguyên chưa được gắn thẻ và cho phép các nhóm kỹ sư thực hiện các hành động về tối ưu hóa chi phí.

Chúng tôi đã sử dụng CloudZero để tự động hóa việc phân loại chi tiêu của mình trên tất cả các tài khoản AWS và cung cấp cho nhóm của chúng tôi khả năng xem thông tin chi tiết về chi phí. Nó nhập siêu dữ liệu từ các tài nguyên AWS cùng với các thẻ AWS, giúp phân bổ chi phí cho các danh mục khác nhau dễ dàng hơn.

Cung cấp khả năng hiển thị chi phí vào các tài nguyên AWS được chia sẻ

Chúng tôi đã tạo các Dimensions như Development, Test, và Production trong CloudZero để dễ dàng nhóm chi phí theo môi trường. Chúng tôi cũng đã xác định các quy tắc trong CostFormation  để giúp chúng tôi hiểu chi phí của việc chạy một tính năng mới bằng cách chia nhỏ chi phí bằng cách sử dụng các quy tắc.

Hiểu về tỷ suất lợi nhuận gộp

Để hiểu rõ hơn về việc các hóa đơn AWS của chúng tôi tăng lên có liên quan như thế nào đến việc mang lại nhiều giá trị hơn cho khách hàng, chúng tôi đã sử dụng hướng dẫn trong Unit Metric – The Touchstone of your IT Planning and Evaluation để xác định động lực thúc đẩy nhu cầu (trong trường hợp của chúng tôi là số lượng đơn đặt hàng). Bằng cách đánh giá số lượng đơn đặt hàng so với chi tiêu AWS, chúng tôi đã có được thông tin chi tiết có giá trị về KPI chi phí, chẳng hạn như giá mỗi đơn hàng, giúp chúng tôi hiểu rõ hơn về tỷ suất lợi nhuận gộp cho doanh nghiệp của mình.

Sử dụng Service Control Policies để kiểm soát chi phí

Theo hướng dẫn trong bài blog Control developer account costs with AWS budgets, chúng tôi đã áp dụng SCP để kiểm soát chi phí và kiểm soát các dịch vụ AWS, tài nguyên và các hành động API cá nhân mà người dùng và vai trò trong mỗi tài khoản thành viên của đơn vị tổ chức có thể truy cập.

Như thể hiện trong Hình 1, chúng tôi đã áp dụng các SCP kiểm soát chi phí sau:

  • SCP-3 trên Sandbox OU ngăn chặn việc sửa đổi cài đặt thanh toán và giới hạn các loại  EC2 instance được phép chỉ cho phép các cá thể mục đích chung lên đến 4xl.
  • SCP-2 trên Workload SDLC OU từ chối quyền truy cập vào các cá thể EC2 lớn hơn 4xl. AWS Budgets sẽ gửi cảnh báo đến kênh Slack khi chi tiêu vượt quá ngưỡng đã xác định.
  • SCP-1 trên Workload PROD OU từ chối quyền truy cập vào bất kỳ hoạt động nào bên ngoài các AWS Regions được chỉ định và ngăn tài khoản thành viên rời khỏi tổ chức.

Hình 1. Áp dụng SCP trên các môi trường khác nhau để kiểm soát chi phí

Tối ưu hóa chi phí truyền dữ liệu

Truyền dữ liệu đại diện cho một danh mục chính của chi phí AWS tổng thể trong báo cáo Cost Explorer của chúng tôi, vì vậy chúng tôi đã sử dụng CloudZero’s Networking Sub-category Dimension để có thông tin chi tiết về AWS outbound, Intra-Region (Availability Zone (AZ) đến AZ), cổng NAT và S3 chi phí đầu ra.

Để có thêm thông tin chi tiết, chúng tôi cũng thiết lập trang tổng quan Data Transfer dashboard với Amazon QuickSight bằng cách sử dụng hướng dẫn trong AWS Well-Architected Cost Optimization lab. Nó cho chúng tôi thấy phí Public IP cho các ứng dụng, phí cổng NAT cho lưu lượng truy cập giữa Amazon EC2 và Amazon S3 trong cùng một Region, truyền dữ liệu giữa các AZ cho môi trường Development và Test và truyền dữ liệu xuyên AZ cho cổng NAT.

Hình 2 cho thấy cách chúng tôi sử dụng Amazon S3 Gateway endpoints (đường liên tục) thay vì S3 public endpoint (đường chấm) để giảm phí cổng NAT. Đối với môi trường Development và Test của chúng tôi, chúng tôi đã tạo các phân vùng ứng dụng-cơ sở dữ liệu để giảm việc truyền dữ liệu giữa các AZ.

Hình 2. Phí truyền dữ liệu qua các dịch vụ AZ và AWS

Giảm chi phí lưu trữ

Cập nhật các đối tượng để sử dụng lớp lưu trữ S3 với chi phí phù hợp

Trong bài đánh giá của chúng tôi về báo cáo Cost Explorer, chúng tôi nhận thấy rằng tất cả các đối tượng được lưu trữ bằng cách sử dụng lớp lưu trữ Chuẩn trong Amazon S3. Để cập nhật điều này, chúng tôi đã sử dụng hướng dẫn từ Amazon S3 cost optimization for predictable and dynamic access patterns blog post để xác định các mẫu truy cập dữ liệu có thể dự đoán bằng Amazon S3 Storage Lens.

Số lượng yêu cầu GET, byte tải xuống và tốc độ truy xuất cho các tiền tố Amazon S3 đã cho chúng tôi biết tần suất truy cập tập dữ liệu trong một khoảng thời gian và khi nào một tập dữ liệu không được truy cập thường xuyên. 40% đối tượng của chúng tôi trên Amazon S3 có kiểu truy cập dữ liệu động. Việc lưu trữ dữ liệu này trong S3 Standard-Infrequent Access có thể dẫn đến phí truy xuất không cần thiết, vì vậy chúng tôi đã chuyển đổi các đối tượng mẫu truy cập dữ liệu động sang Amazon S3 Intelligent-Tiering và các ứng dụng cập nhật để chọn S3 Intelligent-Tier khi tải lên các đối tượng đó. Đối với các đối tượng được truy cập không thường xuyên, chúng tôi đã tạo các chính sách vòng đời của Amazon S3 để tự động chuyển đổi các đối tượng sang các lớp lưu trữ Amazon S3 Standard-Infrequent Access, Amazon S3 One Zone-Infrequent Access, and/or Amazon S3 Glacier storage classes.

Sử dụng Amazon EBS gp3

Sử dụng hướng dẫn từ re:Invent talk on Optimizing resource efficiency with AWS Compute Optimizer, chúng tôi đã xác định các khối lượng EBS được cung cấp quá mức hơn 30%. AWS Compute Optimizer  đã tự động phân tích các mẫu và chỉ số sử dụng như VolumeReadBytes VolumeWriteBytes, VolumeReadOps và VolumeWriteOps cho tất cả các khối lượng EBS trong tài khoản AWS của chúng tôi để đưa ra các đề xuất về việc di chuyển từ khối lượng gp2 sang gp3.

Ở bài blog migrate your Amazon EBS volumes from gp2 to gp3, nó giúp chúng tôi xác định thông lượng cơ sở và các yêu cầu IOPS cho khối lượng công việc của chúng tôi, tính toán tiết kiệm chi phí bằng cách sử dụng máy tính tiết kiệm chi phí và cung cấp các bước để chuyển sang gp3.

Optimize compute costs

Điều chỉnh tài nguyên không hiệu quả và tài nguyên chưa được sử dụng

Việc triển khai Instance Scheduler on AWS đã giúp chúng tôi tối ưu hóa chi phí hơn nữa các tài nguyên của Amazon EC2 và  Amazon Relational Database Service (Amazon RDS) trong môi trường Development, Test, and Pre-production. Bằng cách này, chúng tôi chỉ trả tiền cho 40-60 giờ mỗi tuần thay vì toàn bộ 168 giờ trong một tuần, tiết kiệm 64-76% chi phí.

Di chuyển sang các phiên bản Graviton2 thế hệ mới nhất

Khi lưu lượng người dùng tăng lên, các yêu cầu về thông lượng ứng dụng thay đổi đáng kể, dẫn đến chi phí tính toán cao hơn. Chúng tôi đã chuyển sang thế hệ mới nhất của phiên bản Graviton2 với bộ nhớ và CPU tương tự, nhằm đạt được hiệu suất cao hơn với chi phí giảm. Chúng tôi đã cập nhật Amazon RDS on Graviton 2, Amazon ElasticCache to Graviton2, và Amazon OpenSearch on Graviton2 để tiết kiệm chi phí thấp. Bảng sau đây cho thấy sự so sánh về chi phí sau khi chúng tôi chuyển sang các phiên bản Graviton.

Dịch vụPhiên bản trướcChi phí theo yêu cầu (mỗi giờ) ở Mỹ-Đông-1Phiên bản mớiChi phí theo yêu cầu (mỗi giờ) ở Mỹ-Đông-1Tiết kiệm chi phí
Amazon RDS (PostgreSQL)r5.4xlarge1.008r6g.4xlarge0.806420.00%
Amazon ElasticCachecache.r5.2xlarge0.862cache.r6g.xlarge0.41152.32%
Amazon OpenSearch (data nodes)r5.xlarge.search0.372r6g.xlarge.search0.3359.95%

Sau đó, chúng tôi đã thử nghiệm các ứng dụng dựa trên Java của mình để chạy trên bộ xử lý arm64 bằng cách sử dụng hướng dẫn trên báo cáo chính thức về Graviton GitHub và AWS Graviton2 for Independent Software Vendors whitepaper. Chúng tôi đã tiến hành các thử nghiệm chức năng và phi chức năng trên ứng dụng để đảm bảo rằng ứng dụng cung cấp trải nghiệm giống nhau cho người dùng với hiệu suất được cải thiện.

Load testing để tối ưu hóa chi phí

Chúng tôi đã bao gồm load testing trong CI/CD pipeline để tránh cung cấp quá mức và xác định các điểm nghẽn về tài nguyên trước khi ứng dụng của chúng tôi đi vào sản xuất. Để thực hiện việc này, chúng tôi đã sử dụng Serverless Artillery workshop để thiết lập môi trường load testing trong một tài khoản AWS riêng biệt. Là một phần của load testing đó, chúng tôi có thể mô phỏng lưu lượng sản xuất ở quy mô yêu cầu với chi phí giảm hơn nhiều so với việc sử dụng các phiên bản EC2.

Kết luận

Trong bài đăng trên blog này, chúng tôi đã thảo luận về cách quan sát trong Cost Explorer, điều đó đã giúp chúng tôi xác định các cải tiến để quản lý và tối ưu hóa chi phí. Chúng tôi đã nói về cách bạn có được khả năng hiển thị chi phí tốt hơn bằng cách sử dụng CloudZero và áp dụng các biện pháp kiểm soát chi phí bằng cách sử dụng SCP. Chúng tôi cũng đã nói về cách bạn có thể tiết kiệm chi phí truyền dữ liệu, chi phí lưu trữ và chi phí tính toán với nỗ lực thấp.

Các blog khác trong loạt bài này

Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.

←
→

Leave a comment