Tăng cường hiệu suất website của bạn với Amazon CloudFront

Đối với các trang web hướng đến đối tượng là người tiêu dùng (đơn cử như các trang thương mại điện tử) tốc độ tải trang web ảnh hưởng trực tiếp đến trải nghiệm duyệt web của người dùng và sự thành công của doanh nghiệp. Nếu mất nhiều thời gian để tải, người dùng có thể bỏ qua trang web đó trước khi hoàn tất giao dịch mua sắm của họ, ảnh hưởng đến doanh thu của doanh nghiệp. Để tránh điều đó xảy ra, doanh nghiệp có thể sử dụng mạng phân phối nội dung (CDN) như Amazon CloudFront để cải thiện hiệu suất của trang web, giúp cung cấp dữ liệu, video, ứng dụng và API cho khách hàng trên toàn cầu một cách an toàn với độ trễ thấp và tốc độ truyền tải cao.  

Để cải thiện hiệu suất, chúng ta đơn giản chỉ việc thiết lập một “CloudFront distribution” để lưu lượng trang web của mình được phân phối qua mạng biên toàn cầu của CloudFront. Ngoài ra, CloudFront còn cung cấp nhiều tùy chọn để tối ưu hóa. Trong bài đăng này, chúng ta sẽ học cách tinh chỉnh hiệu suất trang web của mình tốt hơn nữa bằng cách tận dụng các tùy chọn có sẵn này trên CloudFront. 

Lợi ích từ CloudFront 

Amazon CloudFront có mạng lưới toàn cầu gồm các PoP (Points of Presence) và phần mềm thông minh để cung cấp nội dung cho người dùng trên toàn thế giới từ vị trí gần họ nhất hoặc có hiệu suất tốt nhất. Các thành phần của một trang web như HTML, hình ảnh, stylesheets và các tệp JavaScript được truyền đi từ các bản sao được “cache” tại các PoP. Đối với các phần không được “cache”, chẳng hạn như nội dung mới được cập nhật hoặc request động API, CloudFront tìm nạp chúng từ các orgin server (máy chủ gốc) của bạn với một đường dẫn nhanh và được tối ưu hóa nhờ hệ thống mạng của riêng AWS trên toàn cầu. Với việc hỗ trợ cho tất cả các phương thức HTTP bao gồm GET, PUT và POST, CloudFront có thể tăng tốc toàn bộ website của doanh nghiệp bạn.  

CloudFront liên tục triển khai các công nghệ mới trên các giao thức internet. Các tính năng như TLS session resumption, TCP fast open, OCSP stapling, S2N, and request collapsing được kích hoạt mặc định mà không yêu cầu bạn phải cấu hình thêm gì. Bên cạnh đó còn có một số tuỳ chọn về mặt tối ưu hoá mà bạn có thể quyết định có kích hoạt chúng hay không, như là: 

  1. Kích hoạt HTTP/2, và bạn sẽ không cần phải sử dụng domain sharding, một cách thức cũ để cải thiện tốc độ download, cũng như giảm được một số lượng lớn phân giải DNS cho người dùng của bạn.
  2. Kích hoạt HTTP to HTTPS redirection ngay tại biên giúp giảm độ trễ đến Origin (máy chủ gốc) của khách hàng. 
  3. Fine-tune Origin timeouts. CloudFront cho phép bạn cấu hình 2 loại timeout giúp tối ưu kết nối đến Origin. “Read timeout” định khoảng thời gian CloudFront chờ phản hồi từ Origin. Giá trị mặc định là 30 giây, nhưng nếu website của bạn có một số tác vụ cần xử lý lâu hơn ở backend, như là xử lý thanh toán của một đơn hàng, bạn cần cấu hình read timeout lớn hơn để người dùng có thể giao dịch thành công. “Keep-alive idle timeout” định khoảng thời gian tối đa mà CloudFront giữ một kết nối idle với Origin trước khi đóng kết nối. Giá trị mặc định của “keep-alive idle timeout” là 5 giây, nhưng bạn có thể cấu hình giá trị này lên tới 60 giây, nếu Origin của bạn hỗ trợ. Điều này đặc biệt hữu ích khi cung cấp nội dung động qua CloudFront vì mặc dù mọi request đều được chuyển tiếp đến Origin, bạn có thể tránh phải tạo kết nối mới mỗi khi cần.  

Xác định chiến lược caching của bạn 

Đối với các ứng dụng web, chúng ta có thể tận dụng việc kết hợp giữa CloudFront và các trình duyệt của người dùng để cache nội dung gần với người dùng của chúng ta hơn. Cách thông dụng nhất để kiểm soát việc cache này là thông qua Cache-Control HTTP header được gửi bởi Origin, nơi ta có thể định một đối tượng được cache trong bao lâu bằng cách thiết lập thông số TTL (time to live). 

Nếu một đối tượng có Cache-Control header ở trong gói tin phản hồi, CloudFront sẽ cache đối tượng đó tại PoP trong một khoảng thời gian đã định trong Cache-Control max-age. Nếu không có ache-Control header, CloudFront sẽ cache đối tượng đó trong một khoảng thời gian đã định trong mục cache behavior. Ngoài ra, ta có thể xác định ranh giới trong khoảng thời gian ít nhất và nhiều nhất cho bất kỳ đối tượng nào được cache bởi CloudFront bằng cách sử dụng trường Minimum TTL và Maximum TTL của mục cache behavior để bảo vệ khỏi việc vô tình đặt các TTL quá ngắn hoặc quá dài. 

Khuyến nghị của chúng tôi là sử dụng Cache-Control header làm phương thức chính để định hành vi caching mong muốn cho các đối tượng khác nhau của website bạn. Ví dụ như: 

  • Nếu giá trị của max-age trong Cache-Control header nằm giữa TTL tối thiểu và tối đa mà bạn cấu hình, CloudFront sẽ cache đối tượng đó trong khoảng thời gian đã định ở max-age. 
  • Nếu giá trị của max-age nhỏ hơn TTL tối thiểu, CloudFront sẽ cache đối tượng đó trong khoảng thời gian đã định ở TTL tối thiểu. 
  • Nếu giá trị của max-age lớn hơn TTL tối đa, CloudFront sẽ cache đối tượng đó trong khoảng thời gian đã định ở TTL tối đa. 

Để hiểu hơn cách xác định chiến lược caching hiệu quả cho mỗi website, chúng ta hãy cùng tham khảo dụ sau đây: 

Thông thường, một trang của website mua sắm trực tuyến sẽ có sự kết hợp của các thành phần tĩnh và động có thể thuộc một trong bốn danh mục chính, mỗi danh mục yêu cầu chính sách caching khác nhau đáp ứng các đặc tính riêng của nó: 

  1. Private cacheable content (nội dung riêng tư ít thay đổi), như là tên đăng nhập của người dùng. Dữ liệu này chỉ liên quan đến một người dùng và hiếm khi thay đổi, nên sẽ lý tưởng cho việc caching trong trình duyệt của người dùng chứ không phải trong CloudFront. Ví dụ nếu bạn muốn cache thông tin này trên trình duyệt của người dùng trong một giờ, bạn có thể gửi Cache-Control: private, max-age = 3600 header trong HTTP response. Các thông số đó chỉ thị rằng gói tin phản hồi này dành cho một người dùng duy nhất và không nên được cache bởi bất kỳ hệ thống CDN nào chẳng hạn như Amazon CloudFront. 
  2. Private dynamic content (nội dung riêng tư nhưng thường có sự thay đổi), chẳng hạn như số lượng mặt hàng trong giỏ hàng của người dùng. Dữ liệu này cũng chỉ liên quan đến từng người dùng, và nó có thể thay đổi trong suốt một phiên truy cập. Điều này có nghĩa là nó cũng không nên được caching. Bạn có thể tắt caching cho thông tin này trên cả trình duyệt và CloudFront bằng cách gửi Cache-Control: no-store header. 
  3. Shared static content (nội dung công khai tĩnh), chẳng hạn như hình ảnh sản phẩm trên trang chủ. Hình ảnh này sẽ được cung cấp cho nhiều người dùng và nó không thay đổi thường xuyên. Điều này làm cho nó lý tưởng để được caching ở CloudFront lẫn trình duyệt trong thời gian dài. Ví dụ nếu bạn muốn cache hình ảnh này trong một tuần, bạn có thể gửi một Cache-Control: public, max-age=604800 header trong gói tin phản hồi từ máy chủ gốc. Nếu Origin (máy chủ gốc) không trả về Cache-Control headers, bạn có thể tạo một cache behavior trên CloudFront tương ứng với đường dẫn URL của những hình ảnh đó và cấu hình TTL mặc định là 604800 giây (7 ngày). Khi bạn muốn hiển thị hình ảnh sản phẩm khác, chúng tôi khuyên bạn nên tạo ra các phiên bản URL khác. Ví dụ: nếu hình ảnh hiện tại được tham chiếu bởi đường dẫn /products/product-x-v1.jpg, hãy tạo hình ảnh mới với đường dẫn mới /products/product-x-v2.jpg và tham chiếu nó trong trang HTML của bạn. Điều này cho phép CloudFront biết rằng đối tượng đã thay đổi và do đó nó sẽ không truyền tải hình ảnh đã cache trước đó. 
  4. Shared mutable content (nội dung công khai động), chẳng hạn như HTML của trang chủ. Nội dung này được nhiều người dùng yêu cầu và có thể thay đổi theo thời gian, chẳng hạn như khi developer (nhà phát triển) phát hành một tính năng mới hoặc bạn thay đổi danh sách sản phẩm của mình. Tuỳ theo nhu cầu mà bạn có thể sử dụng các TTL khác nhau cho việc caching ở trình duyệt và CloudFront để cân bằng giữa tốc độ bạn muốn cập nhật nội dung cho người dùng và lưu lượng bạn muốn giảm tải từ Origin của mình. Ví dụ: bạn có thể sử dụng TTL = 0 cho bộ nhớ cache của trình duyệt, để buộc người dùng tải nội dung mới nhất từ CloudFront và đặt một TTL ngắn, chẳng hạn như 10 phút, để cache phiên bản mới nhất tại các PoP, và truyền tải đến cho người dùng của bạn.  

Chiến lược caching của bạn cũng cần tính đến cách cache các lỗi HTTP 4xx và 5xx từ Origin. Các lỗi này vẫn thỉnh thoảng xảy ra ở Origin, và CloudFront cung cấp cho bạn các tùy chọn để xử lý chúng một cách dễ dàng. Mặc định, khi Origin trả về mã trạng thái 4xx hoặc 5xx, CloudFront sẽ cache các phản hồi lỗi này trong 5 phút và sau khoảng thời gian đó, gửi yêu cầu tiếp theo đến Origin để xem sự cố đã được giải quyết hay chưa và đối tượng được yêu cầu hiện đã có sẵn chưa. Tuy nhiên, CloudFront cho phép bạn tùy chỉnh các TTL để cache các lỗi cụ thể trong những khoảng thời gian khác nhau. Ví dụ: bạn có thể cấu hình CloudFront để cache một số lỗi 5xx nhất định trong 10 giây thay vì mặc định là 5 phút. Lưu ý rằng khi CloudFront có một đối tượng được cache nhưng đã hết hạn, và việc lấy về đối tượng mới từ Origin trả về lỗi 5xx, thì CloudFront sẽ tiếp tục truyền tải đối tượng cũ đến người dùng, thay vì hiển thị lỗi. 

Nếu người dùng điều hướng đến một URL trên trang web của bạn mà họ không được phép truy cập hoặc không tồn tại, thay vì cung cấp cho họ các trang lỗi 403 hoặc 404, bạn có thể cung cấp cho họ một trang lỗi tùy chỉnh. Ví dụ như là một danh mục các mặt hàng phổ biến nhất trên trang web của bạn hoặc là những chú cún dễ thương có mã phản hồi 200 OK để giữ trải nghiệm tích cực với người dùng và quảng bá thương hiệu của bạn thay vì dựa vào trang lỗi mặc định của trình duyệt. Trang phản hồi này có thể được lưu trữ trên Amazon S3, để nó có thể được truyền tải cho người dùng ngay cả khi Origin không thể phản hồi. Điều này cung cấp một phương án dự phòng đơn giản và cải thiện tính khả dụng. 

Cải thiện tỉ lệ cache hit của bạn  

Khi tối ưu hiệu suất của website, mục đích cuối cùng của bạn là tối đa hóa lượng nội dung có thể được phân phối từ CloudFront cache càng lâu càng tốt. Đây được gọi là tỉ lệ cache hit. 

Măc định CloudFront tạo một cache key duy nhất cho mỗi đối tượng dựa trên đường dẫn và Accept-Encoding header của gói tin yêu cầu từ người dùng. Khi bạn cấu hình một CloudFront cache behavior để chuyển tiếp metadata của gói tin yêu cầu như là header, cookie hay chuỗi query, những dữ liệu này được thêm vào cache key. Điều này có nghĩa là Cloudfront tạo ra các cache key khác nhau cho mọi biến thể, và cache nó như là một đối tượng duy nhất. Biết được điều này, bạn có thể cải thiện việc caching cho nội dung trang web của mình trên CloudFront bằng cách làm theo các đề xuất sau: 

  1. Nếu bạn có các URL cụ thể riêng cho từng phản hồi khác nhau dựa trên header hay cookie hay query string, hãy tạo các cache behaivor riêng biệt trên CloudFront tương ứng với những URL này và cấu hình các giá trị được chuyển tiếp cho phù hợp. 
  2. Chỉ chuyển tiếp một whitelist gồm các header hoặc cookie hoặc query string cụ thể và thực sự quan trọng đối với Origin để truyền tải những nội dung khác nhau dựa trên các giá trị đó, thay vì chuyển tiếp tất cả. 
  3. Tận dụng các header được CloudFront gửi đến Origin. Ví dụ: nếu bạn cần biết thiết bị nào của người dùng để truyền tải nội dung thích hợp, bạn có thể xác định loại thiết bị đó bằng cách chuyển tiếp User-Agent header. Hoặc các custom header được cung cấp bởi CloudFront. 
  4. Khi bạn cần chuyển tiếp một giá trị có thể có nhiều biến thể, hãy cân nhắc chuẩn hóa các biến thể đó bằng Lambda@Edge. Lambda@Edge là một tính năng của Amazon CloudFront cho phép bạn chạy code ở gần hơn với người dùng của mình, giúp giảm độ trễ, cải thiện hiệu suất và cho phép bạn sửa đổi một cách lập trình hoá các gói tin yêu cầu (request) hay gói tin phản hồi (response) mà CloudFront xử lý. 

Kết luận  

Như vậy chúng ta đã thấy một số cách khác nhau để tối ưu hiệu suất website của bạn bằng cách sử dụng CloudFront. Thậm chí còn có nhiều cách mà bạn có thể làm ở mức ứng dụng để tối ưu tốc độ tải trang hơn nữa. Ví dụ: các kỹ thuật tối ưu ở front end bao gồm nén, thu nhỏ, tối ưu hóa hình ảnh và loại bỏ JavaScript chặn hiển thị. Một phương án khác là sử dụng Lambda@Edge để chạy một số ứng dụng về logic ngay tại vùng biên nhằm giảm độ trễ cho người dùng. 

Để đánh giá tác động của những thay đổi này đối với hiệu suất trang web của bạn, điều quan trọng là phải có dữ liệu đo lường. Lý tưởng nhất là bạn giám sát chính người dùng thực của doanh nghiệp bạn để đo lường hiệu suất như trải nghiệm người dùng. Ngoài ra, bạn có thể phân tích access log của CloudFront bằng Amazon Athena hoặc các công cụ phân tích HTTP server log khác mà để có thêm thông tin chi tiết về hiệu suất trang web của mình trong thời gian thực và thực hiện các tùy chỉnh khác nếu cần. 

Nguyễn Đức Phương – Solution Architecture – eCloudValley Việt Nam 

Nguồn: Amazon Web Service  

2022-01-27T21:02:09+00:00 2022/01/27 |Insights|