Using AWS Services to Go “All In” on AWS
•Als PPTX, PDF herunterladen•
3 gefällt mir•2,995 views
Notes on the "Using AWS Services to Go “All In” on AWS" presentation.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Using AWS Services to Go “All In” on AWS
Ähnlich wie Using AWS Services to Go “All In” on AWS (20)
Mehr von Amazon Web Services
Mehr von Amazon Web Services (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Using AWS Services to Go “All In” on AWS
- 1. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Using AWS Services to Go “All In” on AWS Q. Wade Billings, Sr. Director Global IT Shared Services, Instructure Chad Schmutzer, Solutions Architect, Amazon Web Services ©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 2. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Going “all in” on AWS During this session, we will walk through an all-in example architecture and learn how Instructure is using AWS in true all-in fashion.
- 3. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 INSTRUCTURE
- 4. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 0 100 200 300 400 500 600 700 800 900 1,000 1,100 1,200 1,300 1,400 1,500
- 5. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Built for scale Vector-scaling engine Peak concurrent user count: 216,100 Number of production clusters: 47 Number of servers online at peak: 1,700 Amazon EC2 Amazon VPCAmazon S3 Amazon RDSAmazon SES Amazon EMRAmazon Redshift
- 6. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 So you’ve decided to go all in on AWS
- 7. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 This is an excellent decision, but what does it really mean to go “all in?”
- 8. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Technically, this web app is “all in” • A single EC2 instance – with full stack on this host • web app • database • management • and so on… • A single Elastic IP address EC2 instance Elastic IP User
- 9. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Technically “all in,” but… • Will scale up to a certain point • No failover • No redundancy • Too many eggs in one basket EC2 instance Elastic IP User
- 10. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Technically “all in,” but… • Will scale up to a certain point • No failover • No redundancy • Too many eggs in one basket EC2 instance Elastic IP User
- 11. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Single instance = simple approach • Simplest approach • Can now leverage PIOPs • High I/O instances • High memory instances • High CPU instances • High storage instances • Easy to change instance sizes • Will hit an endpoint eventually c3.8xlarge m3.2xlarge t2.micro
- 12. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 “We’re gonna need a bigger box” • Simplest approach • Can now leverage PIOPs • High I/O instances • High memory instances • High CPU instances • High storage instances • Easy to change instance sizes • Will hit an endpoint eventually, and doesn’t take advantage of what AWS has to offer c3.8xlarge m3.2xlarge t2.micro
- 13. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 This is how the “very bad day” started • A single EC2 instance – With full stack on this host • Web app • Database • Management • And so on… • A single Elastic IP EC2 instance Elastic IP User
- 14. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 We can rebuild. We have the technology. We can make it better, faster, stronger.
- 15. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 First things first: the network Let’s lay the groundwork for going “all in” by using Amazon VPC virtual private cloud
- 16. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 What is Amazon VPC?
- 17. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 What is Amazon VPC? • A private, isolated section of the AWS cloud • A virtual network topology you can deploy and customize • Complete control of your networking
- 18. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Put simply, it is a virtual data center you can build and control on AWS!
- 19. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 • VPC • Your virtual data center on AWS • Block of IP addresses that define your network (typically, RFC 1918) • Can span multiple Availability Zones • Default VPCs VPC Availability Zone A Availability Zone B VPC CIDR: 10.1.0.0 /16
- 20. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 • Range of IP addresses in your VPC IP range • Lives inside an Availability Zone • Can provide security at the subnet or network level with ACLs • Can route at the subnet level • Default VPC subnets VPC subnet Subnet Availability Zone A Subnet Availability Zone B 10.1.1.0/24 10.1.10.0/24 VPC CIDR: 10.1.0.0 /16
- 21. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Instructure’s “cluster” architecture • SSD-backed EBS volumes • Multi-AZ VPCs
- 22. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Slowly taking eggs out of the basket… Next, let’s separate our single host into more than one: • web • database – Use Amazon RDS to make your life easier Web instance Elastic IP address RDS DB instance User
- 23. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Amazon RDS: Managed SQL in the cloud • simple and fast to deploy • handles repetitive management tasks • compatible with your applications • fast, predictable performance • simple and fast to scale • secure • cost-effective - And introducing Amazon Aurora
- 24. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Choose Multi-AZ for greater availability, durability • With Multi-AZ operation, your database is synchronously replicated to another Availability Zone in the same AWS region • Failover occurs automatically in response to the most important failure scenarios • Planned maintenance is applied first to backup
- 25. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Instructure’s “cluster” architecture • SSD-backed EBS volumes • Multi-AZ VPCs • Sharded PostgeSQL databases • Intelligent routing of SQL calls
- 26. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Now in preview: Amazon RDS for Aurora • Amazon Aurora: the relational database reinvented for the cloud – Up to five times better performance than MySQL – At a price point 1/10 of a commercial database – Designed for drop-in compatibility with MySQL 5.6 • Pay only for the storage you use • Runs in Amazon VPC; offers encryption at rest and in transit • Amazon RDS handles administrative tasks for Aurora
- 27. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Amazon Aurora: High availability by default • Your data is replicated 6 ways across 3 Availability Zones • Storage grows up to 64 TB seamlessly • Up to 15 Aurora replicas with instant crash recovery AZ 1 AZ 2 AZ 3 Virtualized, cross-AZ storage layer
- 28. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Head to the next level Next, let’s address our lack of failover and redundancy issues: • Load balancer • Another web instance – In another Availability Zone • RDS Multi-AZ web instance RDS DB Instance active (Multi-AZ) Availability Zone Availability Zone web instance RDS DB instance standby (Multi-AZ) Elastic Load Balancing user
- 29. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 • Create highly scalable applications • Distribute load across EC2 instances in multiple Availability Zones Feature Details Available Load balances across instances in multiple Availability Zones Health checks Automatically checks health of instances and takes them in or out of service Session stickiness Routes requests to the same instance Secure sockets layer Supports SSL offload from web and application servers with flexible cipher support Monitoring Publishes metrics to CloudWatch and can get logs of requests processed Elastic Load Balancing Elastic Load Balancing
- 30. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Instructure’s “cluster” architecture • SSD-backed EBS volumes • Multi-AZ VPCs • Sharded PostgeSQL databases • Intelligent routing of SQL calls • No single points of failure • Tight integration with ELB
- 31. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 This will take us pretty far, but we care about performance and efficiency, so let’s improve further
- 32. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 web instance RDS DB instance active (Multi-AZ) Availability Zone Elastic Load Balancing user Let’s lighten the load on our web and database instances: • Move static content from the web instance to Amazon S3 and Amazon CloudFront Shift some load around
- 33. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 web instance RDS DB instance active (Multi-AZ) Availability Zone Elastic Load Balancing Amazon S3 Amazon CloudFrontuser Let’s lighten the load on our web and database instances: • Move static content from the web instance to Amazon S3 and Amazon CloudFront Shift some load around
- 34. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Amazon S3 Amazon S3 is cloud storage for the Internet: • Object-based storage • 11 9s of durability • Good for things like the following: – Static assets ( css, js, images, videos ) – Backups – Logs – Ingest of files for processing • “Infinitely scalable” • Objects up to 5 TB in size • Can host static websites • Supports fine-grained permission control • Ties in well with CloudFront • Acts as a logging endpoint for S3, CloudFront, Billing and Cost Management, ELB, CloudTrail, and more • Supports encryption at transit and at rest • Reduced redundancy is 1/3 cheaper • Amazon Glacier for super long-term storage at 1/3 the cost of S3 Amazon S3
- 35. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Instructure’s “cluster” architecture • SSD-backed EBS volumes • Multi-AZ VPCs • Sharded PostgeSQL databases • Intelligent routing of SQL calls • No single points of failure • Tight integration with ELB • Heavy use of S3
- 36. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Amazon S3 Instructure uses S3 to store: - course data - student submissions - logs - database backups - performance metric data - application elements - CSS Amazon S3
- 37. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 CloudFront CloudFront is a web service for scalable content delivery: • Cache static content at the edge for faster delivery • Helps lower load on origin infrastructure • Dynamic and static content • Streaming video • Zone apex support • Custom SSL certificates • Low TTLs (as short as 0 seconds) • Lower costs for origin fetches (between S3, EC2, and CloudFront) • Optimized to work with EC2, S3, Elastic Load Balancing, and Route 53 ResponseTime ServerLoad Response Time Server Load Response Time Serve rLoad No CDN CDN for static content CDN for static and dynamic content 0 10 20 30 40 50 60 70 80 8:00 AM 9:00 AM 10:00 AM 11:00 AM 12:00 PM 1:00 PM 2:00 PM 3:00 PM 4:00 PM 5:00 PM 6:00 PM 7:00 PM 8:00 PM 9:00 PM Volumeofdata delivered(Gbps)
- 38. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Shift some load around Let’s lighten the load on our web and database instances: • Move static content from the web instance to Amazon S3 and Amazon CloudFront • Move session/state and DB caching to Amazon ElastiCache web instance RDS DB instance active (Multi-AZ) Availability Zone Elastic Load Balancing Amazon S3 Amazon CloudFront user
- 39. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Shift some load around Let’s lighten the load on our web and database instances: • Move static content from the web instance to Amazon S3 and Amazon CloudFront • Move session/state and database caching to Amazon ElastiCache web instance RDS DB instance active (Multi-AZ) Availability Zone Elastic Load Balancing Amazon S3 Amazon CloudFront user ElastiCache
- 40. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Amazon ElastiCache • Hosted Memcached and Redis – Speaks same API as traditional open source Memcached and Redis • Scale from one to many nodes • Self healing (replaces dead instance) • Very fast (single-digit millisecond speeds usually (or less)) • Local to a single Availability Zone for Memcache, with no persistence or replication • With Redis, can put a replica in a different Availability Zone with persistence • Use Auto Discovery to simplify growing and shrinking clusters without affecting your application
- 41. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Instructure’s “cluster” architecture • SSD-backed EBS volumes • Multi-AZ VPCs • Sharded PostgeSQL databases • Intelligent routing of SQL calls • No single points of failure • Tight integration with ELB • Heavy use of S3 • Redis caching layer
- 42. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Shift some load around Let’s lighten the load on our web and database instances: • Move static content from the web instance to Amazon S3 and Amazon CloudFront • Move session/state and database caching to ElastiCache • Move dynamic content from the load balancer to Amazon CloudFront web instance RDS DB instance active (Multi-AZ) Availability Zone Elastic Load Balancing Amazon S3 Amazon CloudFront user ElastiCache
- 43. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Shift some load around: Let’s lighten the load on our web and database instances: • Move static content from the web instance to Amazon S3 and Amazon CloudFront • Move session/state and DB caching to ElastiCache • Move dynamic content from the ELB to Amazon CloudFront web instance RDS DB instance active (Multi-AZ) Availability Zone Elastic Load Balancing Amazon S3 Amazon CloudFront user ElastiCache
- 44. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Now let’s add Route 53
- 45. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Add Route 53 Availability Zone Amazon Route 53 user Amazon S3 Amazon CloudFront Availability Zone Elastic Load Balancing RDS DB instance read replica web instance web instance web instance ElastiCache RDS DB instance read replica web instance web instance web instance ElastiCacheRDS DB instance standby (Multi-AZ) RDS DB instance active (Multi-AZ)
- 46. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Route 53 is a highly available and scalable cloud-based domain name service
- 47. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 What is highly available? The Route 53 SLA is 100% availability per month SLA details: https://aws.amazon.com/route53/sla/
- 48. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Route 53 features • Latency-based routing – Route end users to the AWS region that provides the lowest possible latency • Geo DNS – Route end users to an endpoint you specify based on the end users’ geographic location
- 49. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Route 53 features (continued) • Weighted round robin – Specify the frequency (“weights”) with which different DNS responses are returned to end users • DNS failover – Route your website visitors to an alternate location to avoid site outages
- 50. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Route 53 features (continued) • Health checks – Monitor the health and performance of your web resources • Private DNS for Amazon VPC – Manage custom domain names for your internal, non-public AWS resources • Domain registration
- 51. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Instructure’s “cluster” architecture • SSD-backed EBS volumes • Multi-AZ VPCs • Sharded PostgeSQL databases • Intelligent routing of SQL calls • No single points of failure • Tight integration with ELB • Heavy use of S3 • Redis caching layer • Asynchronous job service layer • Managed with enterprise CM
- 52. AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015 Thank You. This presentation will be loaded to SlideShare the week following the Symposium. http://www.slideshare.net/AmazonWebServices AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015
Hinweis der Redaktion
- Instructure makes software that makes people smarter
- We are built on the time tested and battle proven AWS cloud hosting platform. Upon this foundation, we built out our own innovative cloud scaling technology; the Vector Predictive Scaling Engine and the sharding of the PostgreSQL databases.
- This here is the most basic set up you would need to serve up a web application. We have Route53 for DNS, an EC2 instance running our webapp and database, and an Elastic IP attached to the EC2 instance so Route53 can direct traffic to us. Now in scaling this infrastructure, the only real option we have is to get a bigger EC2 instance…
- So while we could reach potentially a few hundred or few thousand users supported by this single instance, its not a long term play.
- So while we could reach potentially a few hundred or few thousand users supported by this single instance, its not a long term play.
- Scaling the one EC2 instance we have to a larger one is the most simple approach to start with. There are a lot of different AWS instance types to go with depending on your work load. Some have high I/O, CPU, Memory, or local storage. You can also make use of EBS-Optimized instances and Provisioned IOPs to help scale the storage for this instance quite a bit.
- The key concern here, is that you WILL hit an endpoint, where we just don’t have a bigger instance class out yet, and so scaling this way while it can get you over an initial hump, really isn’t going to get us very far.
- The date was August 20t, 2012, and it started out like any other day. But this day would be a turning point for Instructure as we learned a valuable lesson about having all of your technology stack on single instances. Turns out, this is a really bad idea, especially as the “thundering herd” of Fall Semester started logging on to register for courses. I was not at Instructure for our very bad day, but to this day, there are those still suffering from PTSD. http://blog.canvaslms.com/blog/bid/210688/A-Bad-Day-for-Canvas
- So while we could reach potentially a few hundred or few thousand users supported by this single instance, its not a long term play.
- A private space you can build apps and services on AWS Or maybe a set of software defined networking tools that allow you to define your own network footprint in the cloud
- With multiple physical datacenters underneath the covers
- VPC = Virtual Private Cloud This is your virtual data center on AWS You start by defining a CIDR Block of IPs that define your network (typically RFC 1918) ONE NOTE: A VPC is a virtual datacenter that can span multiple AZs or multiple AWS physical datacenters so it is an HA datacenter in a sense When you create a new account today, you automatically get what is called a Default VPC A default VPC is where any untargeted launches of EC2 instances will go. In other words, if you do not specify a VPC, your EC2 instances will go in the default VPC we created for you.
- A subnet is a range of IPs in your VPC IP range. You can divide up your overall VPC IP range into multiple subnets for different uses and purposes. A subnet lives inside an AZ Can provide security at the subnet or network level with ACLs Each subnet can also be routed differently Going back to default VPC, each default VPC will have a default subnet in each AZ with a route to the Internet GW (which we will discuss in the next slide) In this example…
- Today, we have 47 production clusters distributed across five AWS regions. These loosely coupled clusters make up the Canvas global platform and allow for load balancing and seamless migration of data from one cluster to another should hot spots form
- So for this scenario today, we’re going to go with RDS and MYSQL as our database engine.
- Amazon Relational Database Service (Amazon RDS) is a managed service that makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity, while managing time-consuming database administration tasks, freeing you up to focus on your applications and business. Amazon RDS gives you access to the capabilities of a familiar MySQL, Oracle, SQL Server, or PostgreSQL database. This means that the code, applications, and tools you already use today with your existing databases should work seamlessly with Amazon RDS. Amazon RDS automatically patches the database software and backs up your database, storing the backups for a user-defined retention period. You benefit from the flexibility of being able to scale the compute resources or storage capacity associated with your relational database instance via a single API call or few clicks of the AWS Management Console. In addition, Amazon RDS makes it easy to use replication to enhance database availability, improve data durability, or scale beyond the capacity constraints of a single database instance for read-heavy database workloads. As with all Amazon Web Services, there are no up-front investments required, and you pay only for the resources you use. A database instance is a virtual database server in the cloud,with the compute and storage resources you specify. You can create and delete DB Instances, define/refine infrastructure attributes of your DB Instance(s), and control access and security via the AWS Management Console, Amazon RDS APIs, and Command Line Tools. You can run one or more DB Instances, and each DB Instance can support one or more databases or database schemas, depending on engine type. DB Instances are simple to create, using either the AWS Management Console, Amazon RDS APIs, or Command Line Tools. To launch a DB Instance using the AWS Management Console, click "RDS," then the "Launch a DB Instance" button on the "Amazon RDS" tab. From there, you can specify the fundamental parameters for your DB instance: DB engine: MySQL, Oracle, Microsoft SQL Server, PostgreSQL (and, now in preview, Amazon Aurora) DB engine version (optional) License Model (optional) DB Instance type Amount of allocated storage (in GB) Whether your DB Instance should run as a Multi-AZ deployment Storage type DB Instance identifier Master user name Master user password You also have the ability to change your DB Instance’s backup retention policy, preferred backup window, and scheduled maintenance window. Alternatively, you can create your DB Instance using the CreateDBInstance API or rds-create-db-instance command. The automated backup feature of Amazon RDS enables point-in-time recovery of your DB Instance. You can initiate a point-in-time restore and specify any second during your retention period, up to the Latest Restorable Time. Amazon RDS provides backup storage up to 100% of your provisioned database storage at no additional charge. For example, if you have 10GB-months of provisioned database storage, we will provide up to 10GB-months of backup storage at no additional charge. Amazon RDS allows you to control if and when the relational database software powering your DB Instance is upgraded to new versions supported by Amazon RDS. This provides you with the flexibility to maintain compatibility with specific engine versions, test new versions with your application before deploying in production, and perform version upgrades on your own terms and timelines. We’ll explain Multi-AZ on the next slide.
- Amazon RDS Multi-AZ deployments provide enhanced availability and durability for Database (DB) Instances, making them a natural fit for production database workloads. When you provision a Multi-AZ DB Instance, Amazon RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different Availability Zone (AZ). Each AZ runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. In case of an infrastructure failure (for example, instance hardware failure, storage failure, or network disruption), Amazon RDS performs an automatic failover to the standby, so that you can resume database operations as soon as the failover is complete. Since the endpoint for your DB Instance remains the same after a failover, your application can resume database operation without the need for manual administrative intervention. Multi-AZ is available for all RDS engines. Because Multi-AZ minimizes the downtime impact of scheduled maintenance, it gives value even to deployments in which the app servers are in a single AZ. But it’s still best to have the instances spread across multiple Azs.
- Today, we have 47 production clusters distributed across five AWS regions. These loosely coupled clusters make up the Canvas global platform and allow for load balancing and seamless migration of data from one cluster to another should hot spots form
- Amazon Aurora is a MySQL-compatible relational database management system (RDBMS) that combines the speed and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases. Amazon Aurora provides up to five times better performance than MySQL at a price point one tenth that of a commercial RDBMS while delivering similar performance and availability. Amazon Aurora joins MySQL, Oracle, Microsoft SQL Server, and PostgreSQL as the fifth relational database engine available to customers through Amazon RDS. Amazon RDS handles routine database tasks such as provisioning, patching, backup, recovery, failure detection, and repair. Amazon Aurora uses SSL to secure data in transit and encrypts data at rest. If you choose to enable encryption of data at rest, all data written to Amazon Aurora storage will be encrypted as well as all backups stored in Amazon S3. There is no up-front commitment with Amazon RDS Aurora; you simply pay a monthly charge for each instance that you launch. And, when you’re finished with an Amazon Aurora DB Instance, you can easily delete it. You do not need to over-provision storage as a safety margin. You only pay for the storage you actually consume on an hourly basis.
- Each 10GB chunk of your database volume is replicated six ways, across three Availability Zones. Amazon Aurora storage is fault-tolerant, transparently handling the loss of up to two copies of data without affecting database write availability and up to three copies without affecting read availability. Amazon Aurora storage is also self-healing. Data blocks and disks are continuously scanned for errors and replaced automatically. Amazon Aurora will automatically grow the size of your database volume as your database storage needs grow. Your volume will grow in increments of 10 GB up to a maximum of 64 TB or a maximum volume size you define. You don't need to provision excess storage for your database to handle future growth. You can create Amazon Aurora Replicas and serve high-volume application read traffic from multiple instances, thereby increasing aggregate read throughput. Amazon Aurora Replicas share the same underlying storage as the source instance, lowering costs and avoiding the need to perform writes at the replica nodes. This frees up more processing power to serve read requests and reduces the replica lag time – often down to single digit milliseconds. You can create up to 15 Amazon Aurora Replicas per Amazon Aurora database. Aurora automatically and continuously backs up your data to Amazon S3.
- Next up we need to address the lack of failover and redundancy in our infrastructure. We’re going to do this by adding in another webapp instance, and enabling the Multi-AZ feature of RDS, which will give us a standby instance in a different AZ from the Primary. We’re also going to replace our EIP with an Elastic Load Balancer to share the load between our two web instances
- For those who aren’t familiar yet with ELB( Elastic Load Balancer ), it is a highly scalable load balancing service that you can put infront of tiers of your application where you have multiple instances that you want to share load across. ELB is a really great service, in that it does a lot for you without you having to do much. It will create a self-healing/self-scaling LB that can do things such as SSL termination, handle sticky Sessions, have multiple listeners. It will also do health checks back to the instances behind it, and puts a bunch of metrics into CloudWatch for you as well. This is a key service in building highly available infrastructures on AWS.
- Today, we have 47 production clusters distributed across five AWS regions. These loosely coupled clusters make up the Canvas global platform and allow for load balancing and seamless migration of data from one cluster to another should hot spots form
- but its not that efficient in both performance or cost, and since those are important too, let’s clean up this infrastructure a bit.
- The biggest things we can do, and these are incredibly important, is lighten up some of the work our webapp is doing, as well as make life easier for our database. We can start by moving any static assets from our webapp instances to S3, and then serving those objects via CloudFront. We can also move things like session information, and any other temporary application data to a memory based cache like one supported by ElastiCache or DynamoDB. We can also use this same cache to store some of our database query results which will help us from hitting the database too much.
- The biggest things we can do, and these are incredibly important, is lighten up some of the work our webapp is doing, as well as make life easier for our database. We can start by moving any static assets from our webapp instances to S3, and then serving those objects via CloudFront. We can also move things like session information, and any other temporary application data to a memory based cache like one supported by ElastiCache or DynamoDB. We can also use this same cache to store some of our database query results which will help us from hitting the database too much.
- Talk about S3
- Today, we have 47 production clusters distributed across five AWS regions. These loosely coupled clusters make up the Canvas global platform and allow for load balancing and seamless migration of data from one cluster to another should hot spots form
- Talk about S3
- Talk about CloudFront. Make sure to mention the two charts to the right. Static content will certainly speed up your site, but Static&Dynamic content is even better. The chart down below is showing data from a real customer who went from very little traffic, to a huge spike of over 60gigabits per second, without having to do anything on their side, or notify AWS at all.
- Serving our static assets through CloudFront is going to be a massive performance boost to our end-users, but CloudFront can do much more.
- Serving our static assets through CloudFront is going to be a massive performance boost to our end-users, but CloudFront can do much more.
- Talk about elasticache. Now supports Redis which is new! We could use Memcache/Redis as a place to store database query information for content that doesn’t change often, like our end-users’s name or email, or what is in their cart. We should try and do this as often as possible.
- Today, we have 47 production clusters distributed across five AWS regions. These loosely coupled clusters make up the Canvas global platform and allow for load balancing and seamless migration of data from one cluster to another should hot spots form
- Imagine for instance if you cached the search pages for highly requested queries. This could take load off your search, off your web application, your database, etc. So now we can see here that we’ve got CloudFront in front of both S3 and our ELB. Now that we’ve got that covered, lets move back to the session information, and database queries we can be caching as well.
- So let’s actually go and pump the entire site through CloudFront. This could allow us to cache all sorts of page content at the edge, and greatly speed up our site performance to our end users, while significantly lowering the load on our infrastructure.
- Read slide
- If we add in auto-scaling, our caching layer(both inside, and outside our infrastructure), and the read-replicas with MySQL, we can now handle a pretty serious load. This could potentially even get us into the millions of users by itself if continued to be scaled horizontally and vertically.
- Today, we have 47 production clusters distributed across five AWS regions. These loosely coupled clusters make up the Canvas global platform and allow for load balancing and seamless migration of data from one cluster to another should hot spots form