Dynamic Content Acceleration: Amazon CloudFront and Amazon Route 53 (ARC309) | AWS re:Invent 2013

9,547 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

Dynamic Content Acceleration: Amazon CloudFront and Amazon Route 53 (ARC309) | AWS re:Invent 2013

  1. 1. Dynamic Content Acceleration: Lightning-Fast Web Apps with Amazon CloudFront and Amazon Route 53 Kalyanaraman Prasad Parviz Deyhim November 13, 2013 © 2013 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.
  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
  8. 8. Why Performance Matters? 80% of user’s perceived latency comes from frontend
  9. 9. How do we Improve Performance ? A Typical Web Application Has … • Static or Re-Usable Content • • • High TTLs Low TTLs (Customized Content) Dynamic or Unique Content • Zero TTL
  10. 10. Static or Re-Usable Content Can be cached (High TTLs or Low TTLs)
  11. 11. Typical Architecture
  12. 12. Dynamic or Unique Content Cannot be cached - BUT affects 100% of your viewers!
  13. 13. Why Not…?
  14. 14. Why Don’t Customers Use a CDN for Dynamic Content? I don’t see the value - each request is unique and must go back to the origin web server. AND/OR I see the value, but my current CDN charges premium rates for dynamic content acceleration, with many additional fees. AND/OR Configuring a CDN for dynamic content acceleration requires expensive professional services and is not self-service.
  15. 15. 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!
  16. 16. Unique or Reusable Contents?
  17. 17. STATIC or REUSABLE A given content where the state of the content does NOT change for a given period of time t0 t1
  18. 18. DYNAMIC OR UNIQUE A given content where the state of the content changes as soon as it gets created t0 t1
  19. 19. Example
  20. 20. Example Index.jsp (dynamic) Images (static)
  21. 21. . sec
  22. 22. Page Load Time? . Sec
  23. 23. Improving Web Application Performance Accelerating static contents Accelerating dynamic contents
  24. 24. Brief Introduction to Waterfall Graphs
  25. 25. Waterfall Graphs • Most important tool for web-performance measurement • Most browsers provide waterfall graph plug-ins
  26. 26. What Happens? Typing the Address Browser renders
  27. 27. Understanding Waterfall Graphs TCP Connection Content Download DNS Lookup Time to First Byte
  28. 28. Understanding Waterfall Graphs Index.jsp
  29. 29. Optimizing Static Content
  30. 30. Optimizing Static Content Index.jsp Images, JS and CSS
  31. 31. Optimizing Static Content Index.jsp Optimize By Caching With Amazon CloudFront
  32. 32. Caching Origin Edge Location User Request A
  33. 33. Caching Origin Get Image Edge Location User Request A
  34. 34. Caching Get Image Origin Get Image Edge Location User Request A
  35. 35. Caching Get Image Origin Image Get Image Edge Location User Request A
  36. 36. Caching Get Image Origin Image Get Image Edge Location Image User Request A
  37. 37. Caching Origin Edge Location Get Image User Request B
  38. 38. Caching Origin Edge Location Image Get Image User Request B
  39. 39. Optimizing Static Content with Caching Brings content closer to the users
  40. 40. Optimizing Static Content with Caching Improves the experience and performance
  41. 41. Optimizing Static Content with Caching Offloads your infrastructure
  42. 42. Before Caching = 1.46sec
  43. 43. After Caching = 770ms
  44. 44. Are We Done?
  45. 45. NOT SO FAST GOAL: . sec
  46. 46. Cache As Much As You Can
  47. 47. How? I’m Caching All My Images, CSS and JS
  48. 48. Steps to Find Cachable Content 1. Collect web (W3C) logs from your web tier 2. Run a report on your logs (Amazon EMR, Amazon RDS, or Amazon Redshift) 3. Identify top N URLs
  49. 49. Steps to Find Cachable Content Example of query: Select count(url) count, url from logs_table Group by url sort by count;
  50. 50. Site Content
  51. 51. STATIC or REUSABLE A given content where the state of the content does NOT change for a given period of time t0 t1
  52. 52. Caching for Smaller Time Units • Goal: Find contents that can be cached for any given period of time • • Minutes • • Hours Seconds CloudFront can cache content for any period of time
  53. 53. Content with Query Strings 110 /factor/create_image?name=book1&size=10x10 Reusable?
  54. 54. Content with Query Strings • CloudFront can cache content with query strings • Every unique query string combination is a new object in CloudFront’s cache
  55. 55. API Calls 100 /api/GetBooks?category=math Reusable?
  56. 56. API Calls 80 /api/GetBooks?top=10 Reusable?
  57. 57. Caching for Smaller Time Units 1000 /api/GetBooks?top=10 • Imagine your have a read heavy API GETS Hit 100 or 1000 RPS • Offload your web-tier from handling 1000 RPS • Offload your load balancer: Elastic Load Balancing or any other LB • Provision less capacity and reduce cost
  58. 58. Base Page (First HTML page) 220 /index.jsp Reusable?
  59. 59. Optimizing Dynamic Content
  60. 60. Dynamic Content Index.jsp
  61. 61. Optimizing Dynamic Content Index.jsp
  62. 62. Can Dynamic Content Be Optimized? Dynamic content is not cachable Content proxied by CDN to the origin and back
  63. 63. Can Dynamic Content Be Optimized? Poke Origin Ok Poke Edge Location Poke Ok Poke User Request User Request
  64. 64. Can Dynamic Content Be Optimized? That adds latency? How to optimize dynamic content?
  65. 65. How to Optimize Dynamic Content? TCP Connection DNS Lookup Time to First Byte Content Download
  66. 66. How to Optimize Dynamic Delivery? Faster Response Time = Route 53 Reduced DNS Time + Keep-Alive Connections & SSL Termination Reduced Connection Time + Reduced First Byte Time Keep-Alive Connections TCP/IP Optimization Rute53 Route 53 + Reduced Content Download Time
  67. 67. After Caching/Before CloudFront Dynamic Acceleration = 770ms
  68. 68. How to Improve DNS Time? Index.jsp DNS Lookup
  69. 69. With Amazon Route 53 Route 53
  70. 70. Optimizing DNS Response Time • Amazon Route 53 managed DNS offering • Designed to be fast • Low latency DNS resolution • Global network of DNS servers • Queries routed to the nearest DNS server
  71. 71. Without Amazon Route 53
  72. 72. With Amazon Route 53
  73. 73. How to Improve TCP Connection and First Byte Time? TCP Connection Index.jsp
  74. 74. With CloudFront’s Keep-Alive Connections
  75. 75. TCP/IP Hand Shake • HTTP Runs on TCP/IP • TCP has the concept of TCP handshake • Every HTTP Connection has to complete TCP Handshake • TCP/IP Hand Shake Penalizes Dynamic Contents
  76. 76. Two Users without CloudFront SYN SYN-ACK 360ms ACK GET /index.jsp 2nd User SYN SYN-ACK 360ms ACK GET /index.jsp 90ms
  77. 77. Without CloudFront • Every user is new connection • More users = more TCP connections
  78. 78. Without Keep-Alive Connections • Puts load on your web servers: Memory/CPU
  79. 79. Without Keep-Alive Connections • Load on your web server increases the time to first byte Time to First Byte
  80. 80. Keep Alive Connections SYN SYN-ACK ACK 2nd Request GET /index.jsp GET /index.jsp
  81. 81. CloudFront Keep Alive SYN SYN SYN-ACK 360ms SYN-ACK ACK ACK GET /index.jsp 2nd User GET /index.jsp SYN SYN-ACK GET /index.jsp ACK 180ms GET /index.jsp 30ms 60ms
  82. 82. CloudFront Keep Alive • More users Without CloudFront With CloudFront More TCP connections 2 connections 1 connection • Offloads your web tier’s CPU/memory • Improves response time Without CloudFront With CloudFront 720 ms 540 ms
  83. 83. Test CPU Util. % Without CloudFront 20% With CloudFront 6%
  84. 84. How to Optimize My SSL Connections? TCP Connection Index.jsp
  85. 85. With CloudFront’s SSL Termination
  86. 86. SSL Optimization with CloudFront • CloudFront has the ability to support SSL traffic • Use CloudFront cert or bring your own • SSL traffic gets terminated at the closest CloudFront location
  87. 87. CloudFront SSL Optimization Benefits • 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 1000s of end-users SSL connections
  88. 88. SSL Optimization Patterns with CloudFront Two optimization patterns: 1. Half bridge SSL termination 2. Full bridge SSL termination
  89. 89. Half Bridge SSL Termination CloudFront HTTP
  90. 90. Half Bridge SSL Termination Benefits • Better performance by leveraging HTTP connections to origin CloudFront HTTP
  91. 91. Full Bridge SSL Termination HTTPs
  92. 92. How to Improve Content Download Time? Content Download Index.jsp
  93. 93. With Amazon CloudFront Slow-Start Optimization
  94. 94. TCP Slow Start Packet1 Packet 1 ACK Packet 2 Packet 3 Packet 3 ACK Packet 4 Packet 5 Packet 6 Packet 7
  95. 95. Slow-Start Optimization with CloudFront • CloudFront can optimize slow start • Slow start impacts new connections not the existing ones • CloudFront uses existing connections so users can skip slow start
  96. 96. Packet1 Packet 1 ACK Packet 2 Packet1 Packet 2 Packet 3 Packet 4 Packet 3 Packet 3 ACK Packet 4 Packet 5 Packet 6 Packet 7 Packet 4 ACK Packet 5 Packet 6 Packet 7 Packet 8 Packet 9
  97. 97. Performance Test 1: Without CloudFront
  98. 98. Performance Test 2: With CloudFront
  99. 99. Performance Results Test # Of Packets Response Time Per Request Response Time For 200 Requests Without CloudFront 2605 170 ms 33.876 ms With CloudFront 896 96 ms 19.24 ms
  100. 100. How to Optimize PUT/POST? TCP Connection Index.jsp
  101. 101. With Amazon CloudFront PUT/POST Verb Optimization
  102. 102. PUT/POST Optimization with CloudFront • CloudFront supports verbs: PUT, POST, DELETE, OPTIONS, and PATCH • Data won’t get cached • CloudFront proxies data to origin
  103. 103. PUT/POST Optimization with CloudFront • Dynamic content optimizations apply – Keep-alive connections – TCP slow-start optimization – Close proximity connection termination
  104. 104. PUT/POST Optimization with CloudFront • Optimizing form POSTs • Optimizing AJAX POST requests • Optimizing content upload – Uploading to Amazon S3
  105. 105. PUT/POST Optimization Test CloudFront
  106. 106. PUT/POST Optimization Test Uploading 10 MB data from an instance in US East region to US West region Avg. result: 5sec
  107. 107. PUT/POST Optimization Test CloudFront Uploading 10MB data from an instance in US East region to the closest CloudFront location Avg. result: 3.5sec
  108. 108. How to Improve Content Download Time Even More? Content Download Index.jsp
  109. 109. With Amazon Route 53 Latency-based Routing Route 53
  110. 110. Latency-based Routing (LBR) • Run multiple stacks of your application in different Amazon EC2 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 112
  111. 111. LBR Benefits • Better performance than running in a single region • Improved reliability relative to running in a single region • Easier implementation than traditional DNS solutions • Much lower prices than traditional DNS solutions 113
  112. 112. LBR For End-Users 114
  113. 113. LBR For End-Users 115
  114. 114. CloudFront and Route 53 • Use CloudFront for dynamic content optimization • Host your origin at multiple AWS locations (or data centers) – US – Europe
  115. 115. CloudFront and Route 53 • Create Origin DNS records in Route 53 for each location • Route 53 measures the latency between CloudFront and all configured origins • Route 53 resolves origin’s hostname to the closest location • Reduce content download time
  116. 116. LBR For End-Users 118
  117. 117. LBR For End-Users 119
  118. 118. Lower Latency with CloudFront and Route 53
  119. 119. Lower Latency with CloudFront and Route 53
  120. 120. Lower Latency with CloudFront and Route 53
  121. 121. Lower Latency with CloudFront and Route 53
  122. 122. Lower Latency with CloudFront and Route 53
  123. 123. Lower Latency with CloudFront and Route 53
  124. 124. Lower Latency with CloudFront and Route 53
  125. 125. After CloudFront Dynamic Content Optimization = 555 ms
  126. 126. Example: somecompany.com . sec
  127. 127. Design for Failure with CloudFront and Route 53 Route 53
  128. 128. Design for Failure Normal interaction: CloudFront 1. Users connect to CloudFront 1. CloudFront connects to Origin
  129. 129. Design for Failure • What happens if the origin fails to respond back to CloudFront? CloudFront
  130. 130. Design for Failure • With Amazon Route 53, you can health-check your origin
  131. 131. Design for Failure • Failures can be detected by Route 53 health checks CloudFront
  132. 132. Design for Failure • The traffic shifts to the healthy instances or load balancers instead CloudFront
  133. 133. Can mix health check and latency-based routing Can apply the same logic to multiregion deployments
  134. 134. Users get connected to the closest region if both regions are healthy
  135. 135. Route 53 detects failures via health checks
  136. 136. Users get connected to the healthy regions if the closest region is not passing the health check
  137. 137. Design for Failure: Caching • Caching improves performance • Can also improve availability • If your infrastructure is experiencing failure, CloudFront can serve cached content instead of 5xx,4xx and etc 148
  138. 138. Design for Failure: Caching • Going back to “cache as much as you can” • More caching = better availability 149
  139. 139. Design for Failure: Serve Cached Content Origin Edge Location User Request A
  140. 140. Design for Failure: Serve Cached Content Origin Get Image Edge Location User Request A
  141. 141. Design for Failure: Serve Cached Content Get Image Origin Get Image Edge Location User Request A
  142. 142. Design for Failure: Serve Cached Content Get Image Origin Image Get Image Edge Location User Request A
  143. 143. Design for Failure: Serve Cached Content Get Image Origin Image Get Image Edge Location Image User Request A
  144. 144. Design for Failure: Serve Cached Content Origin Edge Location Image User Request B
  145. 145. Design for Failure: Serve Cached Content Get Image Origin Edge Location Get Image User Request B
  146. 146. Design for Failure: Serve Cached Content Get Image Origin Edge Location Get Image User Request B
  147. 147. Design for Failure: Serve Cached Content Get Image Origin Edge Location Image Get Image User Request B
  148. 148. Summary • Accelerate all your content with CloudFront • Use CloudFront with Route 53 latency-based routing to improve your performance • Design for failure with CloudFront and Amazon Route 53
  149. 149. Customer Stories
  150. 150. Customer Story: Low TTLs
  151. 151. Customer Story: Query Strings
  152. 152. Customer Story: Cookies
  153. 153. Customer Story: POST/PUT “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
  154. 154. Customer Story: Custom SSL
  155. 155. Customer Story: Health Checks & 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.”
  156. 156. Please give us your feedback on this presentation ARC309 As a thank you, we will select prize winners daily for completed surveys!

×