Amazon CloudFront là một mạng phân phối nội dung toàn cầu (CDN) giúp việc cung cấp các trang web, video, ứng dụng vàsdfsdfsdfsdAPI một cách an toàn và với tốc độ cao và độ trễ thấp trở nên dễ dàng. Bạn có thể sử dụng CloudFront để giảm độ trễ bằng cách gửi dữ liệu thông qua hơn 400 điểm hiện diện trên toàn cầu (Points of Presence – PoPs) và cải thiện bảo mật thông qua mã hóa dữ liệu, kiểm soát truy cập và khả năng chống lại các cuộc tấn công DDoS. Ngoài hiệu suất và bảo mật, CloudFront còn có thể được sử dụng để tối ưu hóa chi phí cho cơ sở hạ tầng AWS của bạn theo nhiều cách khác nhau. Trong bài viết này, chúng tôi sẽ giới thiệu nhiều tính năng và thực hành tốt liên quan đến CloudFront có thể giúp tối ưu hóa chi phí cho một số kiến trúc phổ biến mà thường được triển khai.

Sử dụng CloudFront cho mọi thứ – bao gồm nội dung động Giả sử bạn cung cấp nội dung động thông qua ứng dụng web hoặc API được lưu trữ trực tiếp từ một Elastic Load Balancer (ELB), các máy ảo Amazon Elastic Compute Cloud (Amazon EC2) hoặc một cụm container Amazon Elastic Container Service (Amazon ECS)/Amazon Elastic Kubernetes Service (Amazon EKS) đến người dùng trên Internet. Thay vì phục vụ nội dung được yêu cầu trực tiếp từ các tài nguyên này, bạn có thể định tuyến lưu lượng này thông qua CloudFront, được cấu hình để truyền nội dung mà không lưu trữ nó tại các địa điểm ngoại vi. Cách tiếp cận này cho phép bạn tận dụng gói Free Tier của CloudFront, cung cấp 1 TB băng thông truyền tải dữ liệu ra Internet miễn phí và 10 triệu yêu cầu HTTP hoặc HTTPS miễn phí mỗi tháng, từ đó giảm chi phí Truyền dữ liệu ra (Data Transfer Out – DTO) của bạn.

Nếu bạn đang sử dụng CDN của bên thứ ba khi lưu trữ ứng dụng của mình trên AWS, bạn nên nhận thức rằng điều này có thể là một mô hình không hiệu quả về chi phí trong việc truyền tải dữ liệu. Hãy hiểu vì sao – giả sử rằng bạn đang chạy một ứng dụng web được triển khai phổ biến sau các Application Load Balancers (ALB) trên AWS và sử dụng một CDN khác thay vì CloudFront. Bây giờ, giả sử ứng dụng của bạn đang phục vụ 10 TB dữ liệu cho người dùng của bạn mỗi tháng. Nếu bạn sử dụng CloudFront làm CDN của bạn, bạn sẽ chỉ phải trả chi phí truyền tải dữ liệu cho 9 TB bởi vì Gói Free Tier của CloudFront sẽ bao gồm 1 TB đầu tiên mỗi tháng. Ngoài ra, không có chi phí truyền tải dữ liệu cho dữ liệu được truyền tải giữa các máy chủ nguồn của bạn trên AWS, như ALB, AWS Elastic Beanstalk, Amazon Simple Storage Service (Amazon S3), đến các địa điểm ngoại vi. Tuy nhiên, nếu bạn sử dụng một CDN khác, bạn sẽ phải trả chi phí truyền tải dữ liệu cho 10 TB theo các kế hoạch giá của họ, cũng như phải chịu thêm chi phí truyền tải dữ liệu cho AWS cho dữ liệu được truyền tải từ máy chủ nguồn của bạn trên AWS đến các địa điểm ngoại vi của CDN khác.

Hình 1: Kiến trúc dòng dữ liệu cho mạng phân phối nội dung

Hạn chế việc phục vụ nội dung cho các vùng không mong muốn bằng cách sử dụng chế độ hạn chế địa lý của CloudFront Lưu lượng không mong muốn và độc hại có thể dẫn đến tải thêm cho tài nguyên của bạn, tiêu thụ băng thông và tăng chi phí của AWS của bạn. Hạn chế lưu lượng không mong muốn tại điểm biên trước khi nó ảnh hưởng đến các tài nguyên khác của bạn có thể giúp bạn tiết kiệm chi phí. Ví dụ, giả sử bạn không muốn lưu lượng từ các quốc gia cụ thể đến ứng dụng của bạn. Trong trường hợp đó, bạn có thể sử dụng tính năng hạn chế địa lý của CloudFront để hạn chế quyền truy cập vào tất cả các tệp liên quan đến một phân phối CloudFront ở mức quốc gia. Điều này có thể giảm lượng lưu lượng mà máy chủ nguồn của bạn phải xử lý. Do đó, bạn có thể điều chỉnh tài nguyên nguồn của mình một cách thích hợp, dẫn đến việc tiết kiệm chi phí.

Sử dụng các lớp giá của CloudFront như một chỉ số cho chiến lược vị trí biên CloudFront có các vị trí biên khắp nơi trên thế giới. Chi phí cho mỗi vị trí biên khác nhau, và do đó giá cả thay đổi tùy thuộc vào vị trí biên nào phục vụ các yêu cầu. Các lớp giá cho phép bạn giảm giá giao hàng bằng cách loại trừ các vị trí biên đắt hơn của CloudFront khỏi phân phối CloudFront của bạn. Do đó, cấu hình lớp giá dựa trên địa lý người dùng ứng dụng giúp giảm chi phí mà không gây ảnh hưởng đáng kể đến thời gian trễ.

Duyệt kiểm soát để giảm chi phí của việc ghi nhật ký CloudFront Bạn có thể muốn theo dõi các chỉ số phân phối nội dung của mình, mà bạn có thể nhận được thông qua các nhật ký CloudFront. Tuy nhiên, lưu ý rằng các nhật ký thời gian thực sẽ tính phí dựa trên số dòng nhật ký được tạo ra, dựa trên số lượng yêu cầu HTTP được phục vụ bởi phân phối CloudFront của bạn. Do đó, như một thực hành tốt, chúng tôi đề xuất đặt một số kiểm soát ngăn chặn vào việc giới hạn lưu lượng được phục vụ bởi phân phối CloudFront của bạn bằng các dịch vụ bảo mật như AWS Web Application Firewall (AWS WAF). Bạn cũng có thể giới hạn lượng nhật ký được tạo ra bằng ba cách sau:

• Chỉ định tỷ lệ yêu cầu bạn muốn ghi nhật ký
• Chọn ghi nhật ký chỉ cho các trường nhật ký cụ thể
• Kích hoạt nhật ký thời gian thực chỉ cho các hành vi lưu trữ CloudFront cụ thể

Bạn có thể cấu hình tất cả các điều này trong cài đặt nhật ký CloudFront như hình ảnh dưới đây.

Hình 3: Ghi nhật ký CloudFront

Tối ưu hóa tỷ lệ truy cập vào bộ đệm cho các nguồn gốc không phải là AWS CloudFront thường được sử dụng như một lớp phân phối nội dung cho các ứng dụng được lưu trữ ngoài môi trường AWS. Trong những trường hợp này, tối ưu hóa tỷ lệ truy cập vào bộ đệm có thể giúp tiết kiệm chi phí gửi yêu cầu gốc. Tỷ lệ truy cập vào bộ đệm là phần trăm tổng số yêu cầu mà được phục vụ từ nội dung được lưu trữ tại các vị trí ngoại vi. Tận dụng các chính sách bộ đệm tùy chỉnh của CloudFront để cải thiện tỷ lệ truy cập vào bộ đệm bằng cách kiểm soát khóa bộ đệm. Khóa bộ đệm là bộ xác định duy nhất cho mỗi đối tượng trong bộ đệm và nó xác định xem một yêu cầu từ trình xem có dẫn đến một truy cập vào bộ đệm hay không. Một truy cập vào bộ đệm xảy ra khi một yêu cầu từ trình xem tạo ra cùng một khóa bộ đệm như một yêu cầu trước đó, và đối tượng cho khóa bộ đệm đó có trong bộ đệm của vị trí ngoại vi và hợp lệ. Một cách để cải thiện tỷ lệ truy cập vào bộ đệm của bạn là bao gồm chỉ các giá trị cần thiết tối thiểu trong khóa bộ đệm. Tối ưu hóa tỷ lệ truy cập vào bộ đệm của bạn bằng cách hiểu rõ về khóa bộ đệm. Ngoài ra, CloudFront cung cấp một số chính sách bộ đệm được xác định trước, được gọi là chính sách quản lý, cho các trường hợp sử dụng phổ biến hoặc hỗ trợ tạo một chính sách bộ đệm tùy chỉnh cụ thể cho yêu cầu của ứng dụng.

Hình 4: Cài đặt khóa lưu trữ đệm CloudFront

Tận dụng hiệu quả khả năng lưu trữ dữ liệu nén của CloudFront CloudFront hỗ trợ tự nhiên việc yêu cầu và lưu trữ các đối tượng đã nén theo định dạng nén GZIP hoặc Brotli. CloudFront phục vụ các đối tượng đã nén khi trình duyệt web của người xem hoặc các ứng dụng khách khác hỗ trợ chúng và cho biết hỗ trợ đối tượng nén bằng tiêu đề Accept-Encoding HTTP. Nén đối tượng giúp giảm chi phí của bạn vì bạn chuyển ít dữ liệu từ máy chủ nguồn của bạn ra internet. Nếu một số loại tệp cụ thể không được hỗ trợ tự nhiên để nén tại CloudFront, bạn có thể nén các tệp này tại nguồn gốc của bạn và trả lại chúng dưới dạng đối tượng đã nén cho CloudFront. CloudFront phát hiện rằng đối tượng đã nén dựa trên sự có mặt của tiêu đề Content-Encoding và sẽ không nén đối tượng lại.

Hình 5: Bộ nhớ cache dữ liệu được nén của CloudFront

Tối ưu hóa chiến lược caching của CloudFront để giảm việc vô hiệu hóa cache Nếu bạn phải loại bỏ một tệp khỏi bộ nhớ cache tại các edge cache của CloudFront trước khi nó hết hạn, bạn có thể vô hiệu hóa tệp đó khỏi edge cache. Bạn sẽ phải trả phí cho các yêu cầu vô hiệu hóa ngoài số lượng đường dẫn đầu tiên 1.000 yêu cầu vô hiệu hóa mỗi tháng. Do đó, quan trọng để hiểu một số best practice chung để tiết kiệm chi phí cho việc vô hiệu hóa.

Chúng tôi đề xuất rằng bạn nên kiểm soát việc caching bằng cách sử dụng tiêu đề Cache-Control HTTP được gửi bởi nguồn gốc của bạn, nơi bạn có thể xác định thời gian một đối tượng được cache bằng cách đặt một thời gian sống (TTL). CloudFront tuân thủ các tiêu đề Cache-Control. Điều này có nghĩa là nếu một đối tượng có một tiêu đề Cache-Control trong phản hồi, thì CloudFront sẽ cache đối tượng tại vị trí edge trong khoảng thời gian được chỉ định trong chỉ thị Cache-Control max-age. Nếu không có tiêu đề Cache-Control, thì CloudFront sẽ cache đối tượng trong khoảng thời gian của TTL mặc định được chỉ định trong hành vi bộ nhớ cache áp dụng. Ngoài ra, bạn có thể xác định các giới hạn về thời gian tối thiểu và tối đa mà bất kỳ đối tượng nào được cache bởi CloudFront bằng cách sử dụng các trường Minimum TTL và Maximum TTL của hành vi bộ nhớ cache để bảo vệ khỏi việc đặt TTL ngắn hoặc dài quá mức không cố ý.

Nếu bạn phải loại bỏ một tệp khỏi bộ nhớ đệm Edge của CloudFront trước khi nó hết hạn, bạn có thể xem xét sử dụng phiên bản tệp để phục vụ một phiên bản khác của tệp có tên khác. Việc sử dụng phiên bản cho phép bạn kiểm soát tệp nào được yêu cầu ngay cả khi người dùng có phiên bản được đệm cục bộ hoặc đằng sau một proxy lưu trữ công ty. Nếu bạn vô hiệu hóa tệp, người dùng có thể tiếp tục thấy phiên bản cũ cho đến khi nó hết hạn khỏi các bộ nhớ đó. Phiên bản hóa ít tốn kém. Bạn vẫn phải trả tiền cho CloudFront để truyền tải phiên bản mới của các tệp đến các vị trí Edge trong trường hợp nguồn không phải AWS, nhưng bạn không phải trả tiền để vô hiệu hóa tệp. Để biết thêm thông tin, hãy xem Cập nhật các tệp hiện có bằng cách sử dụng tên tệp có phiên bản.

Xem xét sử dụng vô hiệu hóa đường dẫn đại diện () thay vì vô hiệu hóa từng tệp riêng lẻ. Bạn phải trả tiền cho mỗi đường dẫn vô hiệu hóa, tuy nhiên, một đường dẫn vô hiệu hóa có thể áp dụng cho một tệp duy nhất, chẳng hạn như (/images/logo.jpg) hoặc nhiều tệp (như /images/). Một đường dẫn mà bao gồm dấu * được tính là một đường dẫn, ngay cả khi nó gây ra việc vô hiệu hóa hàng ngàn tệp.

Tối ưu hóa chi phí thực hiện Lambda@Edge bằng cách đặt đúng kích thước thời gian chạy AWS Lambda Chi phí thực hiện Lambda@Edge cho khối công việc của bạn được xác định bởi ba yếu tố: số lần thực hiện, thời gian thực hiện của chức năng AWS Lambda và việc sử dụng bộ nhớ (kết hợp thành Gb/s). Lựa chọn thời gian chạy Lambda của bạn có tác động trực tiếp đến chi phí. Nói chung, ngôn ngữ được biên dịch chạy mã nhanh hơn so với ngôn ngữ thông dịch, nhưng chúng có thể mất thời gian để khởi động. Đối với các chức năng nhỏ với chức năng đơn giản, thường xuyên ngôn ngữ thông dịch phù hợp hơn để có thời gian thực hiện tổng nhanh nhất và do đó chi phí thấp nhất. Các chức năng sử dụng ngôn ngữ được biên dịch thường chạy nhanh hơn trong khối công việc có độ phức tạp tính toán lớn hơn hoặc khi bạn sử dụng Concurrency được cung cấp, vì vậy thời gian khởi động xảy ra trước khi yêu cầu thực hiện.

Kết luận Bài viết này giải thích một số phương pháp tốt nhất có thể giúp bạn tối ưu hóa chi phí cho một số kiến trúc phổ biến được triển khai trên AWS bằng cách tận dụng Amazon CloudFront. Sử dụng những tính năng này kết hợp với các tính năng khác có thể giúp bạn cải thiện hiệu suất của ứng dụng web sử dụng CloudFront.