Dynamic Content Acceleration: Lightning Fast Web Apps with Amazon CloudFront and Amazon Route 53

1,109 views
1,000 views

Published on

Traditionally, content delivery networks (CDNs) were known to accelerate static content. Amazon CloudFront has come a long way and now supports delivery of entire websites that include dynamic and static content. In this session, we introduce you to CloudFront’s dynamic delivery features that help improve the performance, scalability, and availability of your website while helping you lower your costs. We talk about architectural patterns such as SSL termination, close proximity connection termination, origin offload with keep-alive connections, and last-mile latency improvement. Also learn how to take advantage of Amazon Route 53's health check, automatic failover, and latency-based routing to build highly available web apps on AWS.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,109
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
84
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Dynamic Content Acceleration: Lightning Fast Web Apps with Amazon CloudFront and Amazon Route 53

  1. 1. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Dynamic Content Acceleration Nihar Bihani, Amazon Web Services July 10, 2014
  2. 2. Fundamental Facts • Any web application must have… – Tight security – High availability – High performance
  3. 3. Why Does Availability Matter? • If your application is not available, your revenue loss is 100%. • Impact to customer loyalty and your brand image.
  4. 4. How AWS Helps? • Use Amazon Route 53 to health-check your origin webservers with automatic failover. • Use Amazon CloudFront to front your origins to reduce load on your origins. • Use Amazon CloudFront to customize your error pages. • Amazon CloudFront will automatically serve stale content when origin is unavailable.
  5. 5. Why Performance Matters? • Performance translates to… – Higher page views – Better customer experience – Higher conversion rates
  6. 6. Why Performance Matters?
  7. 7. Why Performance Matters? • Great amount of time and money spent improving back-end infrastructure performance. • 80% of user’s perceived latency comes from front-end.
  8. 8. How do we Improve Performance? • A typical web application has… – Static or Re-Usable content • High TTLs • Low TTLs (Customized Content) • Can be cached – Dynamic or Unique content • Zero TTL • Cannot be cached BUT affects 100% of your viewers!
  9. 9. Elastic Load Balancing Dynamic Content Amazon EC2 Static Content Amazon S3 Custom Origin OR OR Custom Origin www.example.com/*.php cdn.example.com/*.jpg Typical Architecture
  10. 10. Elastic Load Balancing Dynamic Content Amazon EC2 Static Content Amazon S3 Custom Origin OR OR Custom Origin *.php *.jpg Amazon CloudFront www.example.com Why Not?
  11. 11. Why Don’t Customers Use CDNs for Dynamic Content? I don’t see the value - each request is unique and must go back to the origin web server. I see the value, but my current CDN charges premium rates for dynamic content acceleration, with many additional fees. Configuring a CDN for dynamic content acceleration requires expensive professional services and is not self-service.
  12. 12. How Can Amazon CloudFront Help? • TCP/IP optimizations for the network path • Keep-Alive connections to reduce RTT • SSL termination close to viewers • POST/PUT upload optimizations • Latency based routing • Low prices; same as static content delivery!
  13. 13. Re-Usable or Unique Content? • Static or Re-Usable – A given content where the state of the content does NOT change for a given period of time. t 0 t 1
  14. 14. Re-Usable or Unique Content? • Dynamic or Unique – A given content where the state of the content changes as soon as it gets created. t 0 t 1
  15. 15. Example
  16. 16. Example Index.jsp (Dynamic) Images (Static)
  17. 17. Example . Sec
  18. 18. Page Load Time? . Sec
  19. 19. Improving Web Application Performance • Accelerating static content • Accelerating dynamic content
  20. 20. Brief Introduction to Waterfall Graphics • What happens? What happens in betweenTyping the address Browser renders
  21. 21. Waterfall Graphs • Most important tool in web performance measurement • Most browsers provide Waterfall Graph plugins
  22. 22. Understanding Waterfall Graphs TCP connection Content download DNS lookup Time to first byte
  23. 23. Understanding Waterfall Graphs
  24. 24. Understanding Waterfall Graphs index.jsp
  25. 25. Optimizing Static Content • Content is static: images, JS, CSS – It can be distributed to more than one user. – State of the object does not change: sec, minute, hours, etc. – Caching is a way to server static content to more than one user.
  26. 26. Amazon S3 Custom OR Optimizing Static Content with Caching User request A Edge location Origin
  27. 27. Amazon S3 Custom OR Optimizing Static Content with Caching User request A Edge location Origin Get image
  28. 28. Amazon S3 Custom OR Optimizing Static Content with Caching User request A Edge location Origin Get image Get image
  29. 29. Amazon S3 Custom OR Optimizing Static Content with Caching User request A Edge location Origin Get image Get image Image
  30. 30. Amazon S3 Custom OR Optimizing Static Content with Caching User request A Edge location Origin Get image Get image ImageImage
  31. 31. Amazon S3 Custom OR Optimizing Static Content with Caching User request B Edge location Origin
  32. 32. Amazon S3 Custom OR Optimizing Static Content with Caching User request B Edge location Origin Get image
  33. 33. Amazon S3 Custom OR Optimizing Static Content with Caching User request B Edge location Origin Get image Image
  34. 34. Optimizing Static Content with Caching • Bring content closer to the users • Improves the experience and performance • Offloads your infrastructure
  35. 35. Optimizing Static Content with Caching • Before caching = 1.46 seconds
  36. 36. Optimizing Static Content with Caching • After caching = 770 milliseconds
  37. 37. • Are we done? Not so fast! Goal is 0.5 seconds. Optimizing Static Content with Caching index.jsp
  38. 38. Optimizing Static Content with Caching • Cache as much as you can. • How? I’m caching all my images, CSS, and JS. • Find cacheable content. – Collect web (w3c) logs from your web-tier – Run a report on your logs (EMR, RDS, or Redshift) – Identify top N URLs
  39. 39. Optimizing Static Content with Caching • Steps to find cacheable content – Example query Select count(url) count, url from logs_table Group by url sort by count;
  40. 40. Optimizing Static Content with Caching • Report example
  41. 41. Re-Usable or Unique Content? • Static or Re-Usable – A given content where the state of the content does NOT change for a given period of time. t 0 t 1
  42. 42. Caching for Smaller Time Units • Goal: find content that can be cached for any given period of time. – Hours – Minutes – Seconds • CloudFront can cache content for any period of time.
  43. 43. Optimizing Static Content with Caching • Content with query strings • Reusable? • CloudFront can cache content with query strings. • Every unique query-string combination is a new object in CloudFront’s cache. 110 /factor/create_image?name=book1&size=10x10
  44. 44. Optimizing Static Content with Caching • API calls • Reusable? • CloudFront can cache content with query strings. • Every unique query-string combination is a new object in CloudFront’s cache. 100 /api/GetBooks?category=math
  45. 45. Caching for Smaller Time Units • Imagine your have a read heavy API GETS hit 100 or 1,000 RPS. • Offload your web-tier from handling 1,000 RPS. • Offload your load balancer; Elastic Load Balancing or any other LB. • Provision less capacity and reduce costs. 100 /api/GetBooks?category=math
  46. 46. Caching Personalized Content Just Launched! • Optionally configure CloudFront to forward request headers to your origin. • Enables caching for personalized content: • Mobile Device Detection • Geo Targeting • Multi-Site Hosting • Cross Origin Resource Sharing (CORS) • Protocol Detection
  47. 47. Base Page (First HTML Page) • Re-usable? 220 /index.jsp
  48. 48. Optimizing Dynamic Content index.jsp
  49. 49. Optimizing Dynamic Content index.jsp
  50. 50. Optimizing Dynamic Content • Can dynamic content be optimized? – Dynamic content is not cacheable. – Content can be “proxied” by CDN to the origin and back.
  51. 51. Amazon S3 Custom OR Optimizing Dynamic Content User request A Edge location Origin User request B
  52. 52. Amazon S3 Custom OR Optimizing Dynamic Content User request A Edge location Origin User request B
  53. 53. Amazon S3 Custom OR Optimizing Dynamic Content User request A Edge location Origin User request B Get
  54. 54. Amazon S3 Custom OR Optimizing Dynamic Content User request A Edge location Origin User request B Get Response
  55. 55. Amazon S3 Custom OR Optimizing Dynamic Content User request A Edge location Origin User request B Get Response
  56. 56. Amazon S3 Custom OR Optimizing Dynamic Content User request A Edge location Origin User request B
  57. 57. Amazon S3 Custom OR Optimizing Dynamic Content User request A Edge location Origin User request B
  58. 58. Amazon S3 Custom OR Optimizing Dynamic Content User request A Edge location Origin User request B Get
  59. 59. Amazon S3 Custom OR Optimizing Dynamic Content User request A Edge location Origin User request B Get Response
  60. 60. Amazon S3 Custom OR Optimizing Dynamic Content User request A Edge location Origin User request B Get Response
  61. 61. Optimizing Dynamic Content • Can dynamic content be optimized? – That adds latency? – How to optimize dynamic content? – Response time = ∑ Time (DNS + Connection + First Byte + Content Download) DNS lookup Content downloadTCP connection Time to first byte
  62. 62. Faster Response Time = Reduced DNS Time + Reduced Connection Time + Reduced First Byte Time + Reduced Content Download Time Optimizing Dynamic Content
  63. 63. Faster Response Time = Reduced DNS Time + Reduced Connection Time + Reduced First Byte Time + Reduced Content Download Time Optimizing Dynamic Content
  64. 64. Keep-Alive connections & SSL termination Faster Response Time = Reduced DNS Time + Reduced Connection Time + Reduced First Byte Time + Reduced Content Download Time Optimizing Dynamic Content
  65. 65. Keep-Alive connections & SSL termination Faster Response Time = Reduced DNS Time + Reduced Connection Time + Reduced First Byte Time + Reduced Content Download Time Keep-Alive connections Optimizing Dynamic Content
  66. 66. Keep-Alive connections & SSL termination Faster Response Time = Reduced DNS Time + Reduced Connection Time + Reduced First Byte Time + Reduced Content Download Time Keep-Alive connections TCP/IP optimization Optimizing Dynamic Content
  67. 67. Optimizing Dynamic Content • After caching/before CloudFront dynamic acceleration = 770 milliseconds
  68. 68. • How to optimize DNS response time? – with Route 53 Optimizing DNS Response Time DNS lookup
  69. 69. • Amazon Route 53 managed DNS offering • Designed for high availability • Low latency DNS resolution • Global network of DNS servers • Queries routed to nearest DNS server Optimizing DNS Response Time
  70. 70. Without Route 53
  71. 71. With Route 53
  72. 72. • How to optimize TCP connections? – with CloudFront Keep Alive connections. Optimizing TCP Connections and First Byte TCP connection Amazon CloudFront Keep-Alive Connections
  73. 73. • TCP/IP handshake – HTTP runs on TCP/IP – TCP has the concept of TCP handshake – Every HTTP connection has to complete TCP handshake – TCP/IP handshake penalizes dynamic content Optimizing TCP Connections
  74. 74. Two Users without CloudFront 90ms Region
  75. 75. Two Users without CloudFront SYN 90ms Region
  76. 76. Two Users without CloudFront SYN SYN-ACK 90ms Region
  77. 77. Two Users without CloudFront SYN SYN-ACK ACK GET /index.jsp 90ms Region
  78. 78. Two Users without CloudFront 360ms SYN SYN-ACK ACK GET /index.jsp 90ms Region
  79. 79. Two Users without CloudFront 360ms SYN SYN-ACK ACK GET /index.jsp SYN 90ms Region
  80. 80. Two Users without CloudFront 360ms SYN SYN-ACK ACK GET /index.jsp SYN SYN-ACK 90ms Region
  81. 81. Two Users without CloudFront 360ms SYN SYN-ACK ACK GET /index.jsp SYN SYN-ACK ACK GET /index.jsp 90ms Region 360ms
  82. 82. • Every user is a new connection. • More users = more TCP connections. Without CloudFront Region
  83. 83. • Every user is a new connection. • More users = more TCP connections. Without CloudFront Region
  84. 84. • Every user is a new connection. • More users = more TCP connections. Without CloudFront Region
  85. 85. • Every user is a new connection. • More users = more TCP connections. Without CloudFront Region
  86. 86. • Without Keep-Alive connections – Puts load on memory/CPU – Puts load on your web servers – Load on your web servers, increases the time to first byte. Optimizing TCP Connections
  87. 87. Two Users with CloudFront Keep-Alive SYN 60ms30ms Region
  88. 88. Two Users with CloudFront Keep-Alive SYN SYN-ACK 60ms30ms Region
  89. 89. Two Users with CloudFront Keep-Alive SYN SYN-ACK ACK GET /index.jsp 60ms30ms Region
  90. 90. Two Users with CloudFront Keep-Alive SYN SYN-ACK ACK GET /index.jsp SYN 60ms30ms Region
  91. 91. Two Users with CloudFront Keep-Alive SYN SYN-ACK ACK GET /index.jsp SYN SYN-ACK 60ms30ms Region
  92. 92. Two Users with CloudFront Keep-Alive 360ms SYN SYN-ACK ACK GET /index.jsp SYN SYN-ACK ACK GET /index.jsp 60ms30ms Region
  93. 93. Two Users with CloudFront Keep-Alive 360ms SYN SYN-ACK ACK GET /index.jsp SYN SYN-ACK ACK GET /index.jsp 60ms SYN 30ms Region
  94. 94. Two Users with CloudFront Keep-Alive 360ms SYN SYN-ACK ACK GET /index.jsp SYN SYN-ACK ACK GET /index.jsp 60ms SYN SYN-ACK 30ms Region
  95. 95. Two Users with CloudFront Keep-Alive 360ms SYN SYN-ACK ACK GET /index.jsp SYN SYN-ACK ACK GET /index.jsp 60ms SYN SYN-ACK ACK GET /index.jsp 30ms Region GET /index.jsp 180ms
  96. 96. • CloudFront Keep-Alive connections – More users does not have to equal more TCP connections – Without CloudFront two users equal two connections – With CloudFront two users equal one connection – Offloads your web tier’s CPU/memory – Improves response time – Without CloudFront two users equal 720ms – With CloudFront two users equal 540ms Optimizing TCP Connections
  97. 97. Optimizing TCP Connections Test CPU Util. % Without CloudFront 20% With CloudFront 6%
  98. 98. • How to optimize SSL connections? – with CloudFront SSL termination. Optimizing SSL Connections TCP connection Amazon CloudFront SSL termination
  99. 99. • CloudFront has the ability to support SSL traffic. • Use CloudFront cert or bring your own. • SSL traffic gets terminated at the closet CloudFront location. Optimizing SSL Connections
  100. 100. • Taking advantage of Keep-Alive connections – SSL introduces additional TCP handshake packets. – Keep-Alive eliminates additional SSL TCP handshake packets – Offloading your infrastructure from terminating 1,000s of end-users SSL connections. Optimizing SSL Connections
  101. 101. • Two optimization patterns: – Half bridge SSL termination – Full bridge SSL termination SSL Optimization Patterns with CloudFront
  102. 102. Half Bridge SSL Termination CloudFront HTTP • Better performance by leveraging HTTP connections to origin Region
  103. 103. Full Bridge SSL Termination CloudFront HTTPS Region
  104. 104. • How to optimize content download time? – with CloudFront Slow Start Optimization Optimizing Content Download Content download Amazon CloudFront Slow Start optimization
  105. 105. TCP Slow Start
  106. 106. TCP Slow Start Packet 1
  107. 107. TCP Slow Start Packet 1 Packet 1 ACK
  108. 108. TCP Slow Start Packet 1 Packet 1 ACK Packet 2 Packet 3
  109. 109. TCP Slow Start Packet 1 Packet 1 ACK Packet 2 Packet 3 Packet 3 ACK
  110. 110. TCP Slow Start Packet 1 Packet 1 ACK Packet 2 Packet 3 Packet 3 ACK Packet 4 Packet 5 Packet 6
  111. 111. • CloudFront can optimize slow start for new connections. • CloudFront uses existing connections so users can skip slow start. • Users benefit from TCP window optimized with an existing connection. • More packets transferred in a single round trip. Optimizing Content Download
  112. 112. TCP Slow Start Region
  113. 113. TCP Slow Start Packet 1 Packet 1 ACK Region
  114. 114. TCP Slow Start Packet 1 Packet 1 ACK Packet 2 Packet 3 Region
  115. 115. TCP Slow Start Packet 1 Packet 1 ACK Packet 2 Packet 3 Packet 3 ACK Region
  116. 116. TCP Slow Start Packet 1 Packet 1 ACK Packet 2 Packet 3 Packet 3 ACK Packet 4 Packet 5 Packet 6 Region
  117. 117. TCP Slow Start Packet 1 Packet 1 ACK Packet 2 Packet 3 Packet 3 ACK Packet 4 Packet 5 Packet 6 Packet 1 Packet 2 Packet 3 Packet 4 Region
  118. 118. TCP Slow Start Packet 1 Packet 1 ACK Packet 2 Packet 3 Packet 3 ACK Packet 4 Packet 5 Packet 6 Packet 1 Packet 2 Packet 3 Packet 4 Packet 4 ACK Packet 5 Packet 6 Packet 7 Region
  119. 119. • Without CloudFront • With CloudFront Performance Tests Oregon Virginia Oregon Virginia
  120. 120. Performance Tests Results Test # Of Packets Response Time Per Request Response Time For 200 Requests Without CloudFront 2605 170 ms 33.876 s With CloudFront 896 96 ms 19.24 s
  121. 121. • How to optimize content PUT/POST? – with CloudFront PUT/POST Verb optimization Optimizing PUT/POST TCP connection Amazon CloudFront PUT/POST Verb optimization
  122. 122. • CloudFront can support verbs: PUT, POST, DELETE, OPTIONS, and PATCH. • Data won’t get cached. • CloudFront can proxy data to origin. Optimizing PUT/POST
  123. 123. • Dynamic content optimizations apply – Keep-Alive connections – TCP Slow Start optimization – Close proximity connection termination Optimizing PUT/POST
  124. 124. • Optimizing form POSTs • Optimizing AJAX POST requests • Optimizing content upload – Uploading to Amazon S3 Optimizing PUT/POST
  125. 125. Optimizing PUT/POST Performance Tests Oregon Virginia Upload
  126. 126. Optimizing PUT/POST Performance Tests Oregon Virginia Upload • Uploading 10MB data from an instance in US East region to US West region: average result is 5 seconds.
  127. 127. Optimizing PUT/POST Performance Tests Oregon Virginia • Uploading 10MB data from an instance in US East region to closest CloudFront location: average result is 3.5 seconds.
  128. 128. • How to optimize content download even more? – with Route 53 Optimizing Content Download – Even More! Content download
  129. 129. • Latency Based Routing (LBR) • Run multiple stacks of your application in different AWS regions around the world. • Create LBR records for each location and tag the location with GEO information. • Route 53 will route end users to the endpoint that provides the lowest latency. Optimizing Content Download – Even More!
  130. 130. • LBR Benefits – Better performance than running instances in single region. – Improved reliability relative to running in a single region. – Easier implementation than traditional DNS solutions. – Much lower prices than traditional DNS solutions. Optimizing Content Download – Even More!
  131. 131. Optimizing Content Download – Even More!
  132. 132. Optimizing Content Download – Even More!
  133. 133. • Use CloudFront for dynamic content optimization • Host your origin at multiple AWS locations (or data centers) – US – Europe Optimizing Content Download – Even More!
  134. 134. • Create origin DNS records in Route 53 at each location. • Route 53 measures the latency between CloudFront and all configured origins. • Route 53 resolves origin’s hostname to the closest location. • Reduce download time. Optimizing Content Download – Even More!
  135. 135. Optimizing Content Download – Even More!
  136. 136. Optimizing Content Download – Even More!
  137. 137. Lower Latency with CloudFront & Route 53
  138. 138. Lower Latency with CloudFront & Route 53
  139. 139. Lower Latency with CloudFront & Route 53
  140. 140. Lower Latency with CloudFront & Route 53
  141. 141. Lower Latency with CloudFront & Route 53
  142. 142. Lower Latency with CloudFront & Route 53
  143. 143. Lower Latency with CloudFront & Route 53
  144. 144. Lower Latency with CloudFront & Route 53
  145. 145. Lower Latency with CloudFront & Route 53
  146. 146. Lower Latency with CloudFront & Route 53
  147. 147. Lower Latency with CloudFront & Route 53
  148. 148. Lower Latency with CloudFront & Route 53
  149. 149. Lower Latency with CloudFront & Route 53
  150. 150. • Optimization equals 55 milliseconds Optimizing Content Download – Even More!
  151. 151. • CloudFront & Route 53 • Normal interaction – Users connect to CloudFront – CloudFront connects to origin Design For Failure CloudFront Region
  152. 152. • What happens if the origin fails to respond to CloudFront? Design For Failure CloudFront Region
  153. 153. • Failures can be detected by Route 53 health checks. Design For Failure Region Health checks
  154. 154. • The traffic shifts to the healthy instances or load balancers. Design For Failure Region CloudFront Health checks
  155. 155. • Can mix health checks and LBR. • Can apply the same logic to multi-region deployments. • Users get connected to the closest region if both regions are healthy. • Route 53 detects failures via health checks. • Users get connected to the healthy region if the closest region is not passing the health check. Design For Failure Region
  156. 156. Design For Failure R e g i o n 2 CloudFront Health checksHealth checks R e g i o n 1
  157. 157. • Caching improves performance. • Caching can also improve availability. • If your infrastructure is experiencing failure, CloudFront can server cached content instead of 5xx, 4xx, etc. Design For Failure Region
  158. 158. Amazon S3 Custom OR Design for Failure User request A Edge location Origin
  159. 159. Amazon S3 Custom OR Design for Failure User request A Edge location Origin Get image
  160. 160. Amazon S3 Custom OR Design for Failure User request A Edge location Origin Get image Get image
  161. 161. Amazon S3 Custom OR Design for Failure User request A Edge location Origin Get image Get image Image
  162. 162. Amazon S3 Custom OR Design for Failure User request A Edge location Origin Get image Get image ImageImage
  163. 163. Amazon S3 Custom OR Design for Failure User request B Edge location Origin
  164. 164. Amazon S3 Custom OR Design for Failure User request B Edge location Origin Get image
  165. 165. Amazon S3 Custom OR Design for Failure User request A Edge location Origin Get image Get image
  166. 166. Amazon S3 Custom OR Design for Failure User request A Edge location Origin Get image Get image
  167. 167. Amazon S3 Custom OR Design for Failure User request A Edge location Origin Get image Get image Image
  168. 168. • Accelerate all your content with CloudFront. • Use CloudFront with Route 53 LBR to improve your performance. • Design for failure with CloudFront and Route 53. Summary Region
  169. 169. Customer Stories • Low TTLs
  170. 170. Customer Stories • Query Strings
  171. 171. Customer Stories • Cookies
  172. 172. • PUT/POST – “We are excited to use CloudFront's new POST, PUT, PATCH, and DELETE capabilities to accelerate our RESTful APIs on Amazon EC2. With these new HTTP methods we can now take advantage of CloudFront’s global footprint and optimized connections back to our origin servers in AWS. Routing our customers’ API requests via a CloudFront edge location near them will help improve their experience by minimizing packet loss and upload latency. This will help provide a streamlined experience for our customers.” Ilan Rabinovitch, Tech Lead, Site Reliability Engineering Customer Stories Region
  173. 173. • Custom SSL Customer Stories Region
  174. 174. • Health Checks and Failover – “Amazon Route 53’s DNS Failover feature provides high availability across our multiple AWS regions and gives us the ability to offload our origins.” Customer Stories Region
  175. 175. • AWS Free Usage Tier • 50 GB CloudFront Data Transfer per Month • 2,000,000 HTTP/HTTPS Requests per Month • Learn More: http://aws.amazon.com/free/ • Office Hours with CloudFront Engineers • July 30th, 2014 • 10 – 11am (PST) • Register Here: http://aws.amazon.com/cloudfront/ Get Started with CloudFront Region

×