Sqs and loose coupling


Published on

Amazon AWS Simple Queue Service and loose component coupling

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Sqs and loose coupling

  1. 1. SQS & Loose Coupling By Sandip Chaudhari Director, Beacon Edutech http://beaconedutech.com
  2. 2. About Myself •  13+ years of professional experience in Software Industry •  Former CTO @ Krossover •  Director @ Beacon Edutech •  Panel Speaker in New York @ NYTech on Benefits of Cloud for Video and Image: https://www.nytech.org/events/cloud-video-image •  Blog: http://hashbulb.com •  Twitter: @sandipchaudhari •  Email: sandipchaudhari@gmail.com
  3. 3. Queue?
  4. 4. Fun Water Queue
  5. 5. What is SQS? •  Amazon Simple Queue Service is a fast, reliable, scalable and fully managed queue service •  Amazon SQS enables asynchronous message-based communication between distributed components of an application
  6. 6. SQS – What it can do? •  Amazon AWS SQS page: •  SQS makes it simple and cost-effective to decouple the components of a cloud application •  You can use SQS to transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be always available •  With SQS, you can offload the administrative burden of operating and scaling a highly available messaging cluster, while paying a low price for only what you use.
  7. 7. SQS – Major Features •  Redundant Infrastructure •  Multiple writers and readers •  Configurable settings per queue •  Variable message size (up to 256 KB) •  Access Control •  Delay Queues
  8. 8. SQS – Message Visibility Timeout
  9. 9. SQS – Message Visibility Timeout •  The visibility timeout clock starts ticking once Amazon SQS returns the message •  During that time, the component processes and deletes the message •  But what happens if the component fails before deleting the message? •  If your system doesn't call DeleteMessage for that message before the visibility timeout expires, the message again becomes visible to the ReceiveMessage calls placed by the components in your system and it will be received again •  If a message should only be received once, your system should delete it within the duration of the visibility timeout •  Each queue starts with a default setting of 30 seconds for the visibility timeout
  10. 10. SQS Message Lifecycle
  11. 11. SQS Message Lifecycle •  Messages that are stored in Amazon SQS have a lifecycle that is easy to manage but ensures that all messages are processed. 1.  2.  3.  4.  A system that needs to send a message will find an Amazon SQS queue, and use SendMessage to add a new message to it A different system that processes messages needs more messages to process, so it calls ReceiveMessage, and this message is returned Once a message has been returned by ReceiveMessage, it will not be returned by any other ReceiveMessage until the visibility timeout has passed. This keeps multiple computers from processing the same message at once. If the system that processes messages successfully finishes working with this message, it calls DeleteMessage, which removes the message from the queue so no one else will ever process it. If this system fails to process the message, then it will be read by another ReceiveMessage call as soon as the visibility timeout passes
  12. 12. SQS – Long Polling •  Benefit of long polling with Amazon SQS is the reduction of the number of empty responses, when there are no messages available to return, in reply to a ReceiveMessage request sent to an Amazon SQS queue •  Long polling allows the Amazon SQS service to wait until a message is available in the queue before sending a response •  So unless the connection times out, the response to the ReceiveMessage request will contain at least one of the available messages (if any) and up to the maximum number requested in the ReceiveMessage call
  13. 13. SQS – Delay Queues
  14. 14. SQS – Delay Queues •  Delay queues allow you to postpone the delivery of new messages in a queue for a specific number of seconds •  If you create a delay queue, any message that you send to that queue will be invisible to consumers for the duration of the delay period •  You can use CreateQueue to create a delay queue by setting the DelaySeconds attribute to any value between 0 and 900 (15 minutes) •  You can also turn an existing queue into a delay queue by using SetQueueAttributes to set the queue's DelaySeconds attribute
  15. 15. SQS Pricing
  16. 16. Components
  17. 17. Loose – Tight Coupling
  18. 18. Loose – Tight Coupling
  19. 19. Loose Coupling •  What if the whole leg was a single bone? •  Stiff and rigid? •  Or the joins in the leg bones were NOT looselycoupled?
  20. 20. Thinking…
  21. 21. Components and Loose Coupling
  22. 22. SQS and Loose Coupling
  23. 23. SQS – Common Design Patterns •  Work Queues: Decouple components of a distributed application that may not all process the same amount of work simultaneously •  Buffer and Batch Operations: Add scalability and reliability to your architecture, and smooth out temporary volume spikes without losing messages or increasing latency •  Request Offloading: Move slow operations off of interactive request paths by enqueing the request •  Fanout: Combine SQS with Simple Notification Service (SNS) to send identical copies of a message to multiple queues in parallel for simultaneous processing
  24. 24. Scalability – Cloud Scalability
  25. 25. Concurrency and Load Sharing •  Simultaneous access to SQS complements concurrency •  Concurrent writes and reads promote load sharing •  Sharing load across machines / nodes opens the door to scalability
  26. 26. Sync versus Async •  SQS offers completely asynchronous communication •  Source component can literally send and forget. It can immediately proceed to further processing without delay or wait for response •  Visibility timeout assures managed concurrency •  Visibility timeout ensures fail safety - each message is processed, even on failures. As long as the message is processed before retention expiry (14 days)
  27. 27. Typical Use Cases •  Photo Processing - Instagram •  Number crunching and analytics for reporting •  Offline reports generation •  Video encoding - Krossover •  Email and SMS bulk messaging
  28. 28. Case Study – Krossover Video Processing •  Burst loads – large simultaneous, concurrent uploads •  Video codec encoding is heavy processing •  Large and heavy video processing load demands load sharing •  Group of video encoding machines (upto 50) concurrently access the uploaded video-load queue •  Once video-load-message is read, the individual machine encodes the video before the message visibility timeout (set to 8 hours) •  Multiple such simultaneous encoding processes run on each machine (upto 8)
  29. 29. Questions ?