CloudFront BEST PRACTICES & ANTI-PATTERNS

CloudFront
BEST PRACTICES & ANTI-PATTERNS
Abhishek Tiwari
@abhishektiwari
http://abhishek-tiwari.com
Wednesday, 7 August 13

About me

About me
Solutions Architect

About me
Solutions Architect
Early AWS adopter (2007)

About me
Solutions Architect
Early AWS adopter (2007)
Built Cotton On Group’s AWS
Infrastructure (2012)

Agenda
CloudFront in a nutshell
CloudFront Best Practices/Anti-Patterns

CloudFront (CF)

CloudFront (CF)
Content Delivery Network

CloudFront (CF)
Serves Static and Dynamic Content

CloudFront (CF)
Global, Redundant, Scalable

CloudFront (CF)
Low Latency, High Bandwidth

CloudFront (CF)
Cost Effective: Transparent, PAYG, Price
Classes

CloudFront (CF)
Cost Effective: Transparent, PAYG, Price
Classes
NO Edge Side Includes (ESI)

CF Concepts

CF Concepts
Distribution

CF Concepts
Distribution
Delivery Method (Download or Streaming)

CF Concepts
Distribution
CNAME Aliases (1-10)

CF Concepts
Distribution
Origin Server/s (M:M)

CF Concepts
Distribution
Domain Name, Origin ID, Origin Protocol

CF Concepts
Distribution
Object/s (Object Path/Cache Key)

CF Concepts
Distribution
Cache Behavior/s (1-10, 1:1, Ordered)

CF Concepts
Distribution
Path Patterns, Origin ID, Viewer Protocol, Minimum TTL, Cookies/
Query String Forwarding

CF Concepts
Distribution
Edge Location (42+)

CF Concepts
Distribution
Edge Location (42+)
Viewer (GET, Range GET, HEAD Requests)

CF Concepts
http://mycontent.cloudfront.net/photos/profile.png
Cache Key: photos/profile.png (Same for HTTP/HTTPS)
Cache Key:
object path relative to origin + forwarded query string/cookies

CF Concepts
Dynamic Content
Cache Key:

CF Concepts
Dynamic Content
Static Content
Cache Key:

How it works
1. Client request file
2. If file in cache CF return file
Nearest Edge
Location
a. If file not in cache, CF request to origin
b. Origin returns file, status 200, cached in CF
1. Client request file
2. If file in cache CF return file
Nearest Edge
Location
a. If file in cache but expired, CF request to origin
b. Origin returns 304, CF keeps file in cache
Routing based on low latency/price class
Routing based on low latency/price class
Condition GET

Distribution

Distribution
Download Distribution

Distribution
Viewer Protocol HTTP/HTTPS

Distribution
Origin: S3 or Custom

Distribution
Cookies/Query String Forwarding

Distribution
Streaming Distribution

Distribution
Viewer Protocol: Adobe RTMP

Distribution
Origin: S3 only (No Custom)

Distribution
Origin: S3 only (No Custom)
Dynamic/Adoptive Streaming (Adjust
bit rate during playback)

Forward query string to origin

Multiple parameters, order/case sensitive

Order sensitive: Two objects in CF

http://d111111abcdef8.cloudfront.net/images/image.jpg?height=a&width=b

http://d111111abcdef8.cloudfront.net/images/image.jpg?width=b&height=a

Case sensitive: Two objects in CF

http://d111111abcdef8.cloudfront.net/images/image.jpg?type=png

http://d111111abcdef8.cloudfront.net/images/image.jpg?type=png
http://d111111abcdef8.cloudfront.net/images/image.jpg?type=PNG

Cookies Forwarding

Cookies Forwarding
Forwarded cookies (FC): NV pairs, not attributes

Cookies Forwarding
If choose to forward cookies to origin,

Cookies Forwarding
Can forward all cookies, OR

Cookies Forwarding
Only specified cookies

Cookies Forwarding
Object path+FC uniquely identify in CF

Cookies Forwarding
Object path+FC uniquely identify in CF
NV pair/Case sensitive

Origin
S3 Origin: Best for Static media content
(Image, Video, Audio)

Origin
Custom Origin: Best for Static application
content (JS, CSS, Fonts)

Origin
Custom Origin: Best for Static application
content (JS, CSS, Fonts)
Custom Origin: Best for Dynamic media
content (HTML, Thumbnails)

Make a note

Make a note
Eventual Consistency

Make a note
10 Origin Servers per CF Distribution

Make a note
10 Cache Behavior per CF Distribution

Make a note
10 CNAME per CF Distribution

Make a note
10 CNAME per CF Distribution
10 Cookies forwarded per Cache Behavior

Best Practices

Best Practices
Versioning

Best Practices
Versioning
Compression

Best Practices
Versioning
Compression
Domain Sharding

Best Practices
Versioning
Compression
Domain Sharding
Expiration

Best Practices
Versioning
Compression
Domain Sharding
Expiration
Bucket Organization

Best Practices
Versioning
Compression
Domain Sharding
Expiration
Bucket Organization
Logging

Best Practices
Versioning
Compression
Domain Sharding
Expiration
Bucket Organization
Logging
Performance Testing

Anti-Patterns
Cache Invalidation

Cache Invalidation

Cache Invalidation
Programmatic Cache Invalidation

Cache Invalidation
Cache Invalidation is expensive

Cache Invalidation
Unmanageable if you have object dependencies

Cache Invalidation
3 invalidation requests at any given time

Cache Invalidation
3 invalidation requests at any given time
Each invalidation request can included
maximum of 1000 files

Cache Invalidation
Invalidation takes time to propagate
across all edge locations (5-15 minutes)

Cache Invalidation
Deal breaker: browser cache

Cache Invalidation
Deal breaker: browser cache
Versioning is best way to avoid the
invalidation related issues

Versioning

Versioning
CF relies on Origin Servers for versioning

Versioning
S3 supports versioning

Versioning
S3 supports versioning
Version enabled Custom Origin

Versioning
Versioning using query strings

Versioning
File name plus query string with version /static/profile.png?versionID=123

Versioning
Versioning using content based hash key

Versioning
File name as unique key based on file content /static/712vds57tr18929812312enb.png

Versioning
Versioning using prefix/suffix

Versioning
File name with version prefix/suffix /static/profile_123.png

Versioning
File name with version prefix/suffix /static/profile_ 712vds57tr18929812312enb.png

Versioning
File name with version prefix/suffix /static/profile_ 712vds57tr18929812312enb.png
You can use a mixed versioning approach

CF supports versioning using query strings
forwarding

forwarding
Versioning enabled Origin (Custom/S3)

forwarding
For S3 Content

forwarding
For S3 Content
On object upload version enabled S3
bucket will return x-amz-version-id

forwarding
For S3 Content
profile.png

forwarding
For S3 Content
profile.png Upload to S3

forwarding
For S3 Content
profile.png Upload to S3 static/images/profile.png

forwarding
For S3 Content
profile.png Upload to S3 static/images/profile.png Return x-amz-version-id

forwarding
For S3 Content
profile.png Upload to S3 static/images/profile.png Return x-amz-version-id
static/images/profile.png?
versionId=644c69e148

Versionify Application content

Use Build Number or Hash of GIT/HG Head

photo.css, app.css, profile.css
photo.js, app.js, profile.js

Minify+Combine

Minify+Combine
main.css
main.js

Minify+Combine
main.css
main.js
Versionify

Minify+Combine
main.css
main.js
Versionify main.css?v=468df6b
main.js?v=468df6b

Versioning using content based
hash key

hash key
File name is an unique hash key
generated from file content (MD5)

hash key
For S3 content

hash key
For S3 content
Before uploading to S3 generate MD5 hash for
file

hash key
For S3 content
file
Use hash as file name to upload on S3

hash key
For S3 content
file
Avoid content duplication by comparing MD5
hashes

hash key
For S3 content
file
hashes
profile.jpg

hash key
For S3 content
file
hashes
profile.jpg MD5 Hash File Name

hash key
For S3 content
file
hashes
profile.jpg MD5 Hash File Name b723eh0f0df.png

hash key
For S3 content
file
hashes
profile.jpg MD5 Hash File Name b723eh0f0df.png Upload to S3

hash key
For S3 content
file
hashes
profile.jpg MD5 Hash File Name b723eh0f0df.png Upload to S3 static/images/b723eh0f0df.png

hash key
For application content use a pipeline

hash key
file names generated using MD5 hash
of file content

hash key
of file content

hash key
of file content
Minify+Combine

hash key
of file content
Minify+Combine
main.css
main.js

hash key
of file content
Minify+Combine
main.css
main.js
MD5 Hash File Name

hash key
of file content
Minify+Combine
main.css
main.js
MD5 Hash File Name
8972bw7dyf2h.css
67bfwu9hhuw.js

Compression

Compression
Compressed content is served faster
and uses less bandwidth

Compression
CF can serve both compressed and
uncompressed version of files

Compression
Depends on viewer or browser request

Compression
To receive compressed content browser must include Accept-Encoding: gzip in the request header

Compression
For compression CF relies on the custom
origin servers

Compression
For compression CF relies on the custom
origin servers
S3 does not perform the compression

Compression
S3 can store both gzip and non-gzip
versions of the file in the same bucket

Compression
When uploading gzip file to Amazon S3
set Content-Encoding to gzip

Compression
On-the-fly compression by custom
origin server (Nginx, Apache)

Compression
Compress: HTML, CSS, JS etc

Compression
Compress: HTML, CSS, JS etc
Compress Image: JPEG, WebP (Q= 0-100)

Expiration

Expiration
Use one/both of these

Expiration
On Origin server set Cache-Control
max-age header

Expiration
max-age header
In Cache Behavior set Minimum TTL

Expiration
max-age header
Date header/Age header (RFC 2616)

Expiration
max-age header
Date header/Age header (RFC 2616)
Avoid Expire header

Expiration
Browser cachability issues (known bug)

Expiration
Set Cache-Control max-age or Minimum
TTL very far future

Expiration
TTL very far future
Depending on request frequency,
CloudFront might remove the object
before its expiration

Expiration
TTL very far future
Default expiration 24hrs

Expiration
TTL very far future
Default expiration 24hrs
Objects are cached for max {Cache-Control
max-age directive, Cache Behavior Minimum TTL}

Domain Sharding

Domain Sharding
To increase client side performance

Domain Sharding
On average 100+ resources on an
ecommerce page

Domain Sharding
ecommerce page
Browsers limit the number of
simultaneous connections to one server

Domain Sharding
ecommerce page
Browsers limit the number of
simultaneous connections to one server
Hence limit the parallel download from
one server

Domain Sharding
Use two or more CNAME aliases to serve
the content from a CF distribution

Domain Sharding
Browser treat them as different servers

Domain Sharding
Sharding across 2 CNAME aliases will
double the parallel download (Best 2-3)

Domain Sharding
Sharding across 2 CNAME aliases will
double the parallel download (Best 2-3)
More than 4 CNAME will degrade browser
performance (high CPU and memory uses)

Domain Sharding
Use CF CNAME alias feature

Domain Sharding
Use Route 53 for CNAME Aliasing

Domain Sharding
Custom Wild Card SSL Certificate

Domain Sharding
Custom Wild Card SSL Certificate
On application side: enable CF sharding
logic (template compilation etc)

Domain Sharding

<a href="http://mysite.com/about"><img src="http://cf.mycloudfront.net/about.jpg" alt=""/></a>

<a href="http://mysite.com/blogs"><img src="http://cf.mycloudfront.net/blogs.jpg" alt=""/></a>

<a href="http://mysite.com/contact"><img src="http://cf.mycloudfront.net/cont.jpg" alt=""/></a>

<a href="http://mysite.com/about"><img src="http://cf1.mycloudfront.net/about.jpg" alt=""/></a>

<a href="http://mysite.com/blogs"><img src="http://cf2.mycloudfront.net/blogs.jpg" alt=""/></a>

<a href="http://mysite.com/contact"><img src="http://cf1.mycloudfront.net/cont.jpg" alt=""/></
a>

<a href="http://mysite.com/about"><img src="{{ CDN_DOMAINS }}/about.jpg" alt=""/></a>

<a href="http://mysite.com/blogs"><img src="{{ CDN_DOMAINS }}/blogs.jpg" alt=""/></a>

<a href="http://mysite.com/contact"><img src="{{ CDN_DOMAINS }}/cont.jpg" alt=""/></a>

<a href="http://mysite.com/about"><img src="http://mysite.com/about.jpg" alt=""/></a>

<a href="http://mysite.com/blogs"><img src="http://mysite.com/blogs.jpg" alt=""/></a>

<a href="http://mysite.com/contact"><img src="http://mysite.com/cont.jpg" alt=""/></a>

CDN with domain shardingCDN without domain sharding
HTML Template
Without CDN
Compiled OR
DOM Manipulation
Compiled OR
DOM Manipulation

Domain Sharding
Apply domain sharding only where it’s
needed most

Domain Sharding
needed most
Evenly distribute the resources amongst
the shards

Domain Sharding
needed most
the shards
Consider performance overhead due to
the DNS lookup and connection time

Domain Sharding
needed most
the shards
Consider performance overhead due to
the DNS lookup and connection time
Sharding may not be good for Mobile
Browsers (CPU, Battery Life)

Bucket Organisation

Bucket Organisation
Limited Cache Behavior per CF Distribution

Bucket Organisation
Plan your bucket organisation (object keys)

Bucket Organisation
Watch out for the upload paths

Bucket Organisation
/video/uploads/, /audio/uploads/, /images/uploads/ BAD

Bucket Organisation
/uploads/video/, /uploads/audio/, /uploads/image/ GOOD

Bucket Organisation
/uploads/video/, /uploads/audio/, /uploads/image/ GOOD
Use wild card patterns (/uploads/*)

Logging

Logging
Enable logging, store access log file to S3

Logging
One log file per distribution

Logging
Combine log files and analyze logs (EMR)

Logging
W3C extended log file format

Logging
Streaming log vs Download log

Logging
Streaming log vs Download log
Content Analytics: Popularity, Error etc

Performance Testing

Performance Testing
Tradition Load Testing not useful

Performance Testing
Same DNS request, same set of IPs

Performance Testing
Backbone Testing (Ideal Word)

Performance Testing
CDN Server → Backbone

Performance Testing
Last Mile (Real World, User Experience)

Performance Testing
CDN Server → Backbone → Device

Performance Testing
3rd party service (Gomez), application monitor

Performance Testing
Load Testing (Edge Location, Elastic IP Aware)

Performance Testing
Clients request from different geolocations

Performance Testing
Independent DNS request, different set of IPs

Performance Testing
Independent DNS request, different set of IPs
Distribute load across set of IPs

Thank You
Q & A

CloudFront BEST PRACTICES & ANTI-PATTERNS

Recommandé

Recommandé

Contenu connexe

Dernier

Dernier (20)

En vedette

En vedette (20)

CloudFront BEST PRACTICES & ANTI-PATTERNS