Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

(ARC206) Architecting Reactive Applications on AWS | AWS re:Invent 2014

3,769 views

Published on

Application requirements have changed dramatically in recent years, requiring millisecond or even microsecond response times and 100 percent uptime. This change has led to a new wave of andquot;reactive applicationsandquot; with architectures that are event-driven, scalable, resilient, and responsive. In this session, we present the blueprint for building reactive applications on AWS. We compare reactive architecture to the classic n-tier architecture and discuss how it is cost-efficient and easy to implement using AWS. Next, we walk through how to design, build, deploy, and run reactive applications in the AWS cloud, delivering highly responsive user experiences with a real-time feel. This architecture uses Amazon EC2 instances to implement server push to broadcast events to application clients; AWS messaging (Amazon SQS/SNS); Amazon SWF to decouple system components; Amazon DynamoDB to minimize contention; and Elastic Load Balancing, Auto Scaling, Availability Zones, Amazon VPC, and Amazon Route 53 to make reactive applications scalable and resilient.

Published in: Technology

(ARC206) Architecting Reactive Applications on AWS | AWS re:Invent 2014

  1. 1. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in partwithout the express consent of Amazon.com, Inc. November 13, 2014 | Las Vegas, NV ARC 206ArchitectingReactive Applications on AWS Atul Shukla, USEReady Revanth Talari, USEReady
  2. 2. Agenda •N-tier architecture and its limitations •What is a Reactive Application •Reactive Application architecture •AWS for Reactive Applications •Build a Reactive Application
  3. 3. Demo N-Tier App PopEvent
  4. 4. N-tier architecture Front-end server Internal API Internal API API Poll Poll Database Storage Queries Synchronous User waits for update
  5. 5. N-tier architecture •Synchronous communication •Blocking –Lower throughput –Hardware under-utilization and higher costs •Tightly coupled –Location dependent –Difficult to extend and maintain •Blocking •Pull-based
  6. 6. Application requirements have changed
  7. 7. Application requirements have changed Petabytes of data
  8. 8. Application requirements have changed Petabytes of data 100% uptime
  9. 9. Application requirements have changed Sub seconds response time Petabytes of data 100% uptime
  10. 10. Change is inevitable •Users –Demands richer experiences –Expects super fast response time •Applications –Need to scale-on-demand –Always-On –Real-time •Business –Need to react to these changing requirements
  11. 11. Traditional Style of applications cannot deliver on these requirements any longer
  12. 12. Responsive Elastic Resilient Message-driven Reactive Applications
  13. 13. Demo Reactive App http://popevent.elasticbeanstalk.com PopEvent
  14. 14. Responsive Application pushes updates to client in real time Responsive Elastic Resilient Message-driven
  15. 15. Elastic Scales out and inas demand varies Responsive Elastic Resilient Message-driven
  16. 16. Elastic Scales out and inas demand varies Responsive Elastic Resilient Message-driven
  17. 17. Responsive Elastic Resilient Message-driven Resilient Survives failure of individual components
  18. 18. Responsive Elastic Resilient Message-driven Resilient Survives failure of individual components
  19. 19. Responsive Elastic Resilient Message-driven Resilient Survives failure of individual components
  20. 20. Messagedriven Loosely coupled, message-driven components Responsive Elastic Resilient Message-driven
  21. 21. Responsive Elastic Resilient Message-driven Transition •Synchronous •Tightly coupled •Blocking •Pull-based N-Tier Reactive N-tier to Reactive
  22. 22. N-tier to Reactive Internal API Internal API API Poll Poll Database Storage Queries Synchronous User waits for update Front-end server
  23. 23. N-tier to Reactive Front-end server Internal API Internal API API Database Storage Queries Synchronous User waits for update Push Push/Broadcast
  24. 24. N-tier to Reactive Front-end server Internal API Internal API Database Storage Queries Synchronous User waits for update Push Push/Broadcast Message handlers
  25. 25. N-tier to Reactive Front-end server Internal API Internal API Database Storage Queries Synchronous User waits for update Push Push/Broadcast Message handlers Queue messages
  26. 26. N-tier to Reactive Front-end server Internal API Internal API Database Storage Queries Asynchronous User waits for update Push Push/Broadcast Message handlers Queue messages
  27. 27. Reactive architecture •Asynchronous message passing •Non-blocking –Higher throughput –Effective hardware utilization and lower costs •Loosely coupled –Location independent –Easy to extend and maintain •Push-based
  28. 28. AWS for Reactive Applications •Responsive –Amazon EC2 (Websocket Server) –Amazon SNS •Elastic –Elastic Load Balancing –Auto Scaling –Elastic Beanstalk –Amazon DynamoDB •Resilient –Availability Zones –Amazon Route 53 –Auto Scaling –Amazon VPC –DynamoDB •Message Driven –Amazon SQS –Amazon SWF
  29. 29. Let's build a reactive application Goals •React to Users •React to Requests •React to Load •React to Failures PopEvent
  30. 30. Reacting to users Responsive Elastic Resilient Message-driven
  31. 31. messageTopic WebSocket Server (EC2) Subscribe/Notify HTML5 Clients SNS Responsive Elastic Resilient Message-driven
  32. 32. messageTopic WebSocket Server (EC2) HTML5 Clients WebSocket Server (EC2) Subscribe/Notify SNS Responsive Elastic Resilient Message-driven
  33. 33. Amazon SNS -Overview •Publish-subscribe model •Scalable, robust way to implement push •Topics •Broadcast messages Responsive Elastic Resilient Message-driven
  34. 34. WebSocket -overview •HTML5 Technology •Full-duplex communication over TCP Responsive Elastic Resilient Message-driven
  35. 35. SockJS -overview •Wrapper library over WebSocket •Available for both clients and server •SockJS library -https://github.com/sockjs –Client side –sockjs-client –Server Side –sockjs-node Responsive Elastic Resilient Message-driven
  36. 36. Server –Subscribe to Amazon SNS topic
  37. 37. Server –Define endpoints
  38. 38. Server –Create SockJS server
  39. 39. Client –Connect to SockJS server
  40. 40. Server –handle client connection
  41. 41. Client–Send Message to SockJS server http://popevent.elasticbeanstalk.com
  42. 42. Server -Broadcast to clients
  43. 43. Responsive Elastic Resilient Message-driven messageTopic WebSocket Server (EC2) Subscribe/Notify HTML5 Clients SNS Done!!
  44. 44. Responsive Elastic Resilient Message-driven
  45. 45. Reacting to requests Responsive Elastic Resilient Message-driven
  46. 46. Amazon SQS -overview Responsive Elastic Resilient Message-driven •Enables loose coupling •Enables location independent components •Designed to provide high durability •At least once delivery •Timeouts to manage failure
  47. 47. Message to Tasks –Amazon SWF Responsive Elastic Resilient Message-driven •Task based programming models •Run application workflows •Asynchronous invocation •Coordinate distributed application processing •Ordered execution of application steps •At most once delivery •Reliable and auditable
  48. 48. DynamoDB-overview Responsive Elastic Resilient Message-driven •Fully managed cloud NoSQLdatabase •Seamless Scaling •Highly Available •Flexible data models( key-value/document )
  49. 49. messageTopic WebSocket Server (EC2) Subscribe/Notify HTML5 Clients Message Worker 1. Receive Message DynamoDB saveMessage computePopular calcPop Worker 4.QueueMessage 1. Get Message SQS SQS SNS Responsive Elastic Resilient Message-driven
  50. 50. Data Model Responsive Elastic Resilient Message-driven •Tables –Message •messageId(String) –Primary Hash Key •timeCreated(Number) –Primary Range Key –likeCounter •messageId(String) –Primary Hash Key •dislikeCount(Number) •likeCount(Number)
  51. 51. Key 1 Key 2 Key 3 Server 1 Server 2 Server 3 Server4 Server 5 Use unique keys to increase throughput
  52. 52. Hotkey -likeCounter
  53. 53. Responsive Elastic Resilient Message-driven
  54. 54. Elastic Beanstalk -overview •Fast and Simple way to deploy apps •Makes development process productive •Provides Auto Scaling and Elastic Load Balancing out of the box •Complete resource control •Free!! Pay only for resources used
  55. 55. Demo Deploying with Elastic Beanstalk PopEvent
  56. 56. Making WebSocket work Select TCP
  57. 57. Making WebSocket work Select None
  58. 58. Reacting to load—elastic Responsive Elastic Resilient Message-driven
  59. 59. Auto Scaling -Overview •Scale-out and scale-in •Works seamlessly with Amazon CloudWatch •Define Auto Scaling groups •Enables fault tolerance •Enables high availability
  60. 60. Elastic Load Balancing -Overview •Distribute the load automatically •Works seamlessly with Auto Scaling groups •Cross-zone load balancing •Perform health checks
  61. 61. Reacting to load—elastic •Auto Scaling •Elastic Load Balancing •Configure in Elastic Beanstalk
  62. 62. Auto Scaling
  63. 63. Auto Scaling –contd.
  64. 64. Elastic Load Balancing -Config
  65. 65. Elastic Load Balancing -Config
  66. 66. Elastic Load Balancing Users Load Balancer EC2 Instances with Auto Scaling
  67. 67. messageTopic WebSocket Servers(EC2) Subscribe/Notify Message Worker 1. Receive Message DynamoDB saveMessage computePopular 4.QueueMessage 1. Get Message SQS SQS SNS calcPop Worker Load Balancer Users
  68. 68. Reacting to failures—resilient Responsive Elastic Resilient Message-driven
  69. 69. Reacting to failures—Level 1 •Avoiding single points of failures •Auto Scaling and Elastic Load Balancing in a single Availability Zone. •Configure minimum number of instances Responsive Elastic Resilient Message-driven
  70. 70. Users Load Balancer EC2 Instances with Auto Scaling Reacting to failures—Level 1
  71. 71. Reacting to failures—Level 2 Users Load Balancer EC2 Instances with Auto Scaling. Secured with Amazon VPC
  72. 72. Reacting to failures—Level 3 •Auto Scaling and Elastic Load Balancing across regions •Configure minimum number of instances in each zone in each region •Configure DNS entries in Amazon Route 53 Responsive Elastic Resilient Message-driven
  73. 73. Amazon Route 53
  74. 74. Across regions –Amazon Route 53 Region 1 Region 2 Based on a routing policy Amazon Route 53
  75. 75. Multi AZ and Multi region messageTopic WebSocket Servers(EC2) Subscribe/Notify Message Worker 1. Receive Message DynamoDB saveMessage computePopular 4.QueueMessage 1. Get Message SQS SQS SNS calcPop Worker Load Balancer Users
  76. 76. Multi AZ and Multi region Users AZ1 AZ2 AZ1 AZ2 Region 1 Region 2
  77. 77. Demo Reacting to failures—resilient
  78. 78. Responsive Elastic Resilient Message-driven
  79. 79. Responsive Elastic Resilient Message-driven Reactive Applications
  80. 80. Thank You!
  81. 81. Please give us your feedback on this session. Complete session evaluations and earn re:Invent swag. ARC206 http://bit.ly/awsevals

×