AWS re:Invent 2013 Recap


Published on

A recap of some of the most interesting things learned from the AWS re:Invent 2013 Conference. Easily the most intense and educational conference I've ever attended.

Published in: Technology
1 Like
  • Be the first to comment

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

No notes for slide
  • Some of these aren’t available on the re:Invent site so I’ve linked to them wherever they could be found (slideshare/youtube)
  • AWS re:Invent 2013 Recap

    1. 1. AWS re:Invent 2013 Recap A harrowing tale of heroic geeks embarking on a never ending quest for knowledge and a steak dinner
    2. 2. Putting things in perspective • Basics of application constraints • Address them with software architecture • THEN re:Invent – how these tools solve those problems
    3. 3. Server Constraints • Performance – Processor (super fast) – RAM (super fast) – Disk I/O • Standard Hard Disk (super slow) • SSD (moderately slow, but no seek time) – Bandwidth / Network (fast) • Disk Space • Disk Reliability
    4. 4. Better Living through Architecture • Efficient Code and Queries – Lower Processor Usage – Reduce disk I/O – Minimize RAM footprint • Caching – Reduce disk I/O – Avoid reprocessing the same code/query – Avoid calling and waiting for responses from the same external services – Increase RAM usage • Background Processes and Queues – Reduce disk I/O – This is a low priority and can wait until other resources aren’t occupied – Predictable processing (no such thing as an overloaded queue) • Throughput Optimization – Reduce disk I/O – Reduce bandwidth usage – Optimized images: use less disk space, bandwidth – Query only what you need: minimize bandwidth between database and application server GOAL: Minimize Disk I/O
    5. 5. Response Time Limits • 0.1 second – Limit for having the user feel that the system is reacting instantaneously – No special feedback is necessary except to display the result • 1.0 second – About the limit for the user's flow of thought to stay uninterrupted – User will notice the delay – No special feedback is necessary during delays > 0.1s but < 1.0s – User does lose the feeling of operating directly on the data. • 10 seconds – About the limit for keeping the user's attention focused on the dialogue – Users will want to perform other tasks while waiting – Should be given feedback indicating expected completion – Feedback during the delay is more important for variable response times
    6. 6. Anatomy of a Web Request
    7. 7. Better Living through “Cloud” • Content Delivery Networks (CDN) • Geographic DNS / Routing • Dynamic Server Capacity • Dynamic Load Balancing • Unlimited Storage • Redundant Storage • Scalable Bandwidth Limitations • Scalable Disk I/O
    8. 8. Reduce Lookup Time Geographic DNS
    9. 9. Remove Unnecessary Requests CDN • Combine & Minify JS and CSS files to limit requests • Use public CDNs for common libraries to leverage browser cache (ex - jQuery via Google) • Removes library from your rolled JS which shrinks the download on redeploy • Use Image Sprites to minimize requests for multiple images
    10. 10. Remove Server Stress Dynamic Server Capacity Dynamic Load Balancing Unlimited Storage Redundant Storage Scalable Disk I/O Distributed Caching The server request is the bottleneck preventing all other page loads from triggering
    11. 11. AWS Overview What is AWS? with Mark B.
    12. 12. AWS Overview US West (Oregon) EU (Ireland) Asia Pacific (Tokyo) US West (N. California) South America (Sao Paulo) US East (Virginia) AWS GovCloud (US) Asia Pacific (Sydney) Regions Asia Pacific (Singapore)
    13. 13. AWS Overview US West (Oregon) EU (Ireland) Asia Pacific (Tokyo) US West (N. California) US East (Virginia) AWS GovCloud (US) Asia Pacific (Sydney) Availability Zones Asia Pacific (Singapore) South America (Sao Paulo)
    14. 14. AWS Overview Edge Locations
    15. 15. AWS Overview Compute Storage & Content Delivery AWS Global Infrastructure Database App Services Deployment & Administration Networking Amazon CloudWatch AWS IAM AWS CloudFormation AWS Elastic Beanstalk AWS Data Pipeline AWS OpsWorks Amazon CloudSearch Amazon SQS Amazon SNS Amazon Elastic Transcoder Amazon SWF Amazon SES Amazon DynamoDB Amazon RDS Amazon ElastiCache Amazon RedShift AWS Storage Gateway Amazon S3 Amazon Glacier Amazon CloudFrontAmazon EC2 Amazon EMR Amazon VPC Amazon Route 53 AWS Direct Connect
    16. 16. AWS Infrastructure • S3/Glacier – Cloud File Storage • Cloudfront – CDN • Heroku – PaaS Built on top of AWS • RDS – Multi-AZ MySQL (plus read replica) • EC2 – Virtual Compute Resources • Route 53 / ELB – DNS and Load Balancing • Elasticache – Memcached – DB Caching • Cloud Search – People/Group Search • Cloud Watch – Monitoring/Metrics
    17. 17. NOW…TO AWS RE:INVENT 2013! Viva Las Vegas
    18. 18. So what exactly is re:Invent?
    19. 19. Major News from Amazon
    20. 20. Tons of Sessions
    21. 21. Hands on Labs • Chances to experiment • Variable complexity • Lots to choose from
    22. 22. Vendors…so many vendors • Demoing and answering questions about their products • AWS Marketplace – License software on your own instances • Hosted services using AWS cloud – Use their APIs • Services for managing AWS via AWS APIs
    23. 23. And SWAG…lots of We get T-shirts They get your e-mail address
    24. 24. YES…YES WE DID So did we learn anything?
    25. 25. Quick Hits • New at Amazon – RDS for PostgreSQL *huge applause* – DynamoDB • NoSQL as a service • Across availability zones – Virtual Desktops – AppStream • Stream graphic intensive apps to mobile devices – Kinesis • Drink from the real time data firehose • Notables already there – Redshift • Data warehouse • Interface mirrors Postgres – Glacier • Dirt cheap long term storage • In house appliance to mimic/replace tape • Auto-backup from S3 – MySQL RDS adds streaming read replicas across availability zones
    26. 26. Scaling for the 1st 10 Million No Users – start small • What does your app do? • Do everything on one server > 100 Users • Start infrastructure separation • Web and Database > 1K Users • Start setting up redundancy • Multiple webs in different zones • Elastic load balancing across webs • Multi AZ database > 10K Users • Use more redundancy • Lots of caching – DB and session caching (Memcached/Elasticache) – Static assets to CDN – Use online storage for most things (S3) > 500K Users • Service Oriented Architecture – “Move services into their own tiers of modules. Treat each of these as 100% separate piece of infrastructure and scale independently.” – Loose coupling, using messaging as a buffer (SQS) > 5M Users • Typical to run into issues on DB write master • Consider sharding and/or other DB technologies – PostgreSQL XC – MongoDB – DynamoDB Musts at ALL levels • Good monitoring, metrics and logging tools Things that are helpful on most levels • Auto scaling – increase/decrease your resources as load requires
    27. 27. Dynamic CDN? • Cloudfront CDN speeds up dynamic content – Geographic SSL endpoint – Use a single keep-alive – Hold fewer connections due to consistent user bandwidth • Connections to your server are always Tier 1 • Cloudfront handles the longer download times
    28. 28. SOA w/ SQS + SNS • SOA = Service Oriented Architecture • SNS = Simple Notification Service • SQS = Simple Queue Service • Each service has a queue • Each service has a notification service • The queues subscribe to whatever notifications that particular service cares about • A job processes the messages in the queue
    29. 29. Automating Media Flows Ingest – Fast file transfers • Companies: • Aspera (used by Netflix) • Attunity Cloudbeam • Signiant • Open Source: Tsunami UDP Process • Elastic Transcoder • Reduced Redundancy Storage (S3) • Backup with Glacier • Select a Thumbnail • Extract several samples • Ask Mechanical Turk to choose • Turks are people too Deliver • Save in Database • Add to CloudSearch index • Serve with Application • Streamed via Cloudfront CDN Amazon Services used… • S3 • Glacier • RDS/DynamoDB • Elastic Transcoder • Simple Workflow (SWF) • Mechanical Turk • EC2 • Cloudfront • CloudSearch
    30. 30. Big Data Analytics • Amazon Redshift – Analytic, Indexless Database – Huge Queries, Fast – Load data, process data, kill instance – Query interface mirrors PostgreSQL • Amazon Elastic Map Reduce (EMR) / Hadoop – Mortar Framework, pig, and lipstick (for pig) • Track timing on each piece of each job • Visually breakdown how the job is working • Identify time constraints / bottlenecks • Schedule cluster lifetime • Keeps historical operations data after cluster destroyed • Store results in Dynamo/Mongo instead of S3 • JasperSoft – Open source Business Intelligence (BI) – Available in AWS Marketplace – Works with almost any backend • Hadoop, EMR, Redshift, PostgreSQL
    31. 31. Amazon Kinesis Overview • Streaming map/reduce • Routes incoming data by type to ensure appropriate processing • Auto-provision instances to handle streaming load • Allows failover for several seconds for streaming data • Integrates with DynamoDB to store incoming results • Uses Java to implement the processing logic Use Case: Twitter Firehose …from the movie UHF…funny movie  And yes that guy is Kramer from Seinfeld
    32. 32. MONyog • Monitors MySQL • Makes recommendations based on – Current configuration – Best practices • Sort of like an auto-tune for MySQL
    33. 33. Hybrid Cloud Eucalyptus • Open source Amazon infrastructure • Develop and deploy against Amazon APIs in your own datacenter • Portable automation code VPN • Setup Virtual Private Cloud (VPC) within Amazon network • Setup dedicated VPN connection between our datacenter and Amazon datacenters
    34. 34. Controlling the Flood • DynamoDB – Fast write NoSQL database – Provisioned by preselecting throughput level • Reads/writes per second – When you go over…tough • Simple Queue Service – Auto-scaling queuing system – Handles high load fast-writes – When writes fail due to throughput threshold, stick them in the queue – Have a background worker keep trying to write to DynamoDB until throughput is available
    35. 35. Key Lesson: Automate Everything • 1 server…configure manually • 2 servers…configure each one…maybe • > 2 servers…automate or pray – Puppet: Cross platform provisioning automation • Yes, even Windows – Vagrant: Excellent tool for using production virtual machines in development environments • Also great for experimenting with Puppet
    36. 36. Key Lesson: AWS does not mean best • Amazon provides a lot of tools…not all of them are perfect • Amazon tools are usually better integrated • Elastic Beanstalk was heavily made fun of by PRESENTERS for its weaknesses • Systems that have standard APIs are more portable…for example – Elasticache is Memcached and Redis – Elastic Map Reduce is Hadoop – EC2 instances are just virtual servers running an OS • Many infrastructure vendors within AWS datacenters • A lot of services are extremely easy to configure compared to paying somebody else a markup to do it for you – Offload the complexity
    37. 37. Key Lesson: Load Test & Monitor • You cannot know your bottlenecks until your application is under stress • You cannot know your bottlenecks unless you are monitoring your infrastructure
    38. 38. Research it Yourself Find MOST presentations Some are missing. There was an amazing session from Loggly that is not present. Update: Here it is…
    39. 39. Recommended Presentations • Coding Tips you should know before distributing your HTML5 Web App on Mobile – • Automated Media Workflows in the Cloud – • Dynamic Content Acceleration using Cloudfront and Route53 – • Controlling the Flood: Massive Message Processing with SQS and DynamoDB – • Building Scalable Windows and .NET Apps – • 7 use cases in 7 minutes: The Power of Workflow Automation – • Professional Grade Cloud for your Hybrid IT needs – • Scaling for your first 10 million users – • Drinking Our Own Champagne: How w00t, an Amazon subsidiary, uses AWS – • Building a Scalable Digital Asset Management Platform (PBS) – • Instrumenting Your App Stack in a Dynamically Scaling Environment – • Intrusion Detection in the Cloud –
    40. 40. And about that steak dinner • 7 hungry men wandered the entire Las Vegas strip for 3 hours (give or take 2 hours) trying to make a decision on where to eat a steak… • The quest finally ended at… Wolfgang Puck at the MGM Grand
    41. 41. Credits • My incredible team at ACS Technologies, Inc. • Presenters at re:Invent 2013