Escalando para sus primeros 10 millones de usuarios
•Download as PPTX, PDF•
0 likes•426 views
The document discusses strategies for scaling applications on AWS from 1 user to over 1 million users. It begins with hosting an application on a single EC2 instance, and progresses to introducing load balancing, separating databases onto RDS, read replicas, and sharding. It recommends services like S3, DynamoDB, ElastiCache to offload components. Automation with services like CloudFormation, CodeDeploy, and a SOA approach are suggested to scale independently. Migrating parts of the application to use specialized AWS databases and NoSQL options like DynamoDB is advised for very large user counts. The key is to leverage managed AWS services that scale automatically wherever possible.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Escalando para sus primeros 10 millones de usuarios
Similar to Escalando para sus primeros 10 millones de usuarios (20)
More from Amazon Web Services LATAM
More from Amazon Web Services LATAM (20)
Recently uploaded
Recently uploaded (20)
Escalando para sus primeros 10 millones de usuarios
- 1. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Alejandro Flores Solutions Architect, AWS NoLA Scaling Up to Your First Million Users1011 Experience Day Guadalajara
- 2. So how do we scale?
- 5. Now that’s a lot of things to read! This is NOT where we want to start!
- 6. TECHNICAL & BUSINESS SUPPORT Account Management Support Professional Services Solutions Architects Training & Certification Security & Pricing Reports Partner Ecosystem AWS MARKETPLACE Backup Big Data & HPC Business Apps Databases Development Industry Solutions Security APPLICATION SERVICES Queuing Notifications Search Orchestration Email ENTERPRISE APPS Virtual Desktops Storage Gateway Sharing & Collaboration Email & Calendaring Directories HYBRID CLOUD MANAGEMENT Backups Deployment Direct Connect Identity Federation Integrated Management SECURITY & MANAGEMENT Virtual Private Networks Identity & Access Encryption Keys Configuration Monitoring Dedicated INFRASTRUCTURE SERVICES Regions Availability Zones Compute Storage Databases SQL, NoSQL, Caching CDNNetworking PLATFORM SERVICES App Mobile & Web Front-end Functions Identity Data Store Real-time Development Containers Source Code Build Tools Deployment DevOps Mobile Sync Identity Push Notifications Mobile Analytics Mobile Backend Analytics Data Warehousing Hadoop Streaming Data Pipelines Machine Learning
- 7. AWS building blocks Inherently highly available and fault-tolerant services Highly available with the right architecture Amazon CloudFront Amazon Route 53 Amazon S3 Amazon DynamoDB Elastic Load Balancing Amazon EFS AWS Lambda Amazon SQS Amazon SNS Amazon SES Amazon SWF … Amazon EC2 Amazon EBS Amazon RDS Amazon VPC
- 8. So let’s start from…
- 9. 1 user You
- 10. 1 User • Amazon Route 53 for DNS • A single Elastic IP • A single Amazon EC2 instance • With full stack on this host • Web app • Database • Management • And so on… Amazon EC2 instance Elastic IP User Amazon Route 53
- 11. “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 c4.8xlarge m3.2xlarge t2.micro
- 12. “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 c4.8xlarge m3.2xlarge t2.micro
- 13. 1 User • We could potentially get to a few hundred to a few thousand depending on application complexity and traffic • No failover • No redundancy • Too many eggs in one basket EC2 Instance Elastic IP User Amazon Route 53
- 14. 1 User • We could potentially get to a few hundred to a few thousand depending on application complexity and traffic • No failover • No redundancy • Too many eggs in one basket EC2 Instance Elastic IP User Amazon Route 53
- 15. Users >1
- 16. Users > 1 First, let’s separate out our single host into more than one. • Web • Database Make use of a database service? Web Instance Database Instance Elastic IP User Amazon Route 53
- 17. Self-managed Fully managed Database server on Amazon EC2 Your choice of database running on Amazon EC2 Bring Your Own License (BYOL) Amazon DynamoDB Managed NoSQL database service using SSD storage Seamless scalability Zero administration Amazon RDS Microsoft SQL Server Oracle MySQL PostgreSQL MariaDB Amazon Aurora BYOL or license Included Amazon Redshift Massively parallel, petabyte-scale data warehouse service Fast, powerful, and easy to scale Database options
- 18. Users >100
- 19. Users >100 First, let’s separate out our single host into more than one: • Web • Database Use Amazon RDS to make your life easier Web instance Elastic IP RDS DB instance User Amazon Route 53
- 20. Users >1000
- 21. Users >1000 Next, let’s address our lack of failover and redundancy issues: Another web instance • In another Availability Zone RDS Multi-AZ Elastic Load Balancing (ELB) Web Instance RDS DB Instance Active (Multi-AZ) Availability Zone Availability Zone Web Instance RDS DB Instance Standby (Multi-AZ) ELB Balancer User Amazon Route 53
- 24. Users > 10,000s–100,000s RDS DB Instance Active (Multi-AZ) Availability Zone Availability Zone RDS DB Instance Standby (Multi-AZ) ELB Balancer RDS DB Instance Read Replica RDS DB Instance Read Replica RDS DB Instance Read Replica RDS DB Instance Read Replica Web Instance Web Instance Web Instance Web Instance Web Instance Web Instance Web Instance Web Instance Amazon Route 53User
- 25. What about performance and efficiency?
- 26. Lighten the Load
- 27. RDS DB Instance Active (Multi-AZ) Availability Zone ELB Balancer Amazon S3 Amazon CloudFront Amazon Route 53 User Shift some load around Web Instances • static content to Amazon S3 and Amazon CloudFront Move…
- 28. Shift some load around • static content to Amazon S3 and Amazon CloudFront Move… • session/state to Amazon DynamoDB • DB caching to Amazon ElastiCache RDS DB Instance Active (Multi-AZ) Availability Zone ELB Balancer Amazon S3 Amazon CloudFront Amazon Route 53 User ElastiCache DynamoDB Web Instances
- 29. Shift some load around Move… • static content to Amazon S3 and Amazon CloudFront • session/state to Amazon DynamoDB • DB caching to Amazon ElastiCache • dynamic content to Amazon CloudFront RDS DB Instance Active (Multi-AZ) Availability Zone ELB Balancer Amazon S3 Amazon CloudFrontUser ElastiCache DynamoDB Web Instances Amazon Route 53
- 30. = one user = 100,000 users= 1,000,000 users
- 31. Users >500,000
- 32. Users > 500,000+ Availability Zone Amazon Route 53 User Amazon S3 Amazon CloudFront Availability Zone ELB Balancer DynamoDB 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)
- 33. Users > 500,000+ Availability Zone Amazon Route 53 User Amazon S3 Amazon CloudFront Availability Zone ELB Balancer DynamoDB 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)
- 34. Use automation
- 35. AWS application management solutions Convenience Control Higher-level services Do it yourself AWS Elastic Beanstalk AWS OpsWorks AWS CloudFormation Amazon EC2
- 36. AWS CodeDeploy • Deploys your code to a “fleet” of EC2 instances • 1 – 10,000s of instances • Automatically schedules updates (multiple AZs) • Application and Deployment groups described in YAML-formatted files • Can reference Auto Scaling Groups • AWS Management Console, CLI, or APIs • Can be used with Chef recipes or Puppet scripts
- 37. Users >500,000+ • Monitoring, metrics, and logging • If you can’t build it internally, outsource it! (third-party SaaS) • What are customers saying? • Try to squeeze as much performance out of each service/component
- 39. There are further improvements to be made in breaking apart our web/app layer
- 40. SOA What does this mean?
- 42. Now that’s a lot of things to read! This is NOT where we want to start!
- 43. This is NOT where we want to start! This IS where we want to start! Now that’s a lot of things to read!
- 44. SOAing Move services into their own tiers. • Treat them separately and scale them independently. Amazon and AWS do this extensively! It offers flexibility and greater understanding of each component
- 45. Loose coupling + SOA = winning DON’T REINVENT THE WHEEL • Email • Queuing • Transcoding • Search • Databases • Monitoring • Metrics • Logging • Compute Amazon CloudSearch Amazon SQSAmazon SNS Amazon Elastic Transcoder Amazon SWFAmazon SES AWS Lambda
- 46. Loose coupling sets you free! The looser they're coupled, the bigger they scale • Independent components • Design everything as a black box • Decouple interactions • Favor services with built-in redundancy and scalability rather than building your own S3 Bucket Lambda Push: Event Notification DynamoDB Pull: DynamoDB Stream Amazon Kinesis Pull: DynamoDB Stream SQS messages Get Message Instance Put Message Instance Amazon SNS Topic Publish Notification Queue Is Subscribed to Topic
- 47. Users >1,000,000
- 48. Users >1 million+ RDS DB Instance Active (Multi-AZ) Availability Zone ELB Balancer RDS DB Instance Read Replica RDS DB Instance Read Replica Web Instance Web Instance Web Instance Web Instance Amazon Route 53 User Amazon S3 Amazon CloudFront DynamoDB Amazon SQS ElastiCache Worker Instance Worker Instance Amazon CloudWatch Internal App Instance Internal App Instance Amazon SES Lambda
- 49. The next big steps
- 51. Users >5 million - 10 million You’ll potentially start to run into issues with your database around contention on the write master. How can you solve it? • Federation—splitting into multiple DBs based on function • Sharding—splitting one dataset up across multiple hosts • Moving some functionality to other types of DBs (NoSQL, Graph)
- 52. Database federation • Split up databases by function/purpose • Harder to do cross-function queries • Essentially delays sharding/NoSQL • Won’t help with single huge functions/tables Forums DB Users DB Products DB
- 53. Sharded horizontal scaling • More complex at the application layer • No practical limit on scalability • Operation complexity/sophistication • Shard by function or key space • RDBMS or NoSQL User ShardID 002345 A 002346 B 002347 C 002348 B 002349 A CBA
- 54. Shifting functionality to NoSQL • Similar in a sense to federation • Again, think about the earlier points for when you need NoSQL vs. SQL • Leverage managed services like DynamoDB Some use cases: • Leaderboards/scoring • Rapid ingest of clickstream/log data • Temporary data needs (cart data) • “Hot” tables • Metadata/lookup tablesDynamoDB
- 55. A quick review
- 56. Putting all this together means we should now easily be able to handle 11+ million users!
- 57. To infinity...
- 58. User >11 million Iterating on top of the patterns seen here will get you up and over 100 million users
- 59. • More fine-tuning of your application • More SOA of features/functionality • Going from Multi-AZ to multi-region • Possibly start to build custom solutions • Deep analysis of your entire stack User >11 million
- 60. Next steps? READ! aws.amazon.com/documentation aws.amazon.com/architecture aws.amazon.com/start-ups START USING AWS: aws.amazon.com/free/
- 61. Ask for Help! forums.aws.amazon.com aws.amazon.com/premiumsupport/ Your Account Manager A Solutions Architect
- 62. Thank you!
Editor's Notes
- Scaling your application is a big topic, with lots of opinions, guides, and how-tos. …and it’s an iterative process. You don’t design for 11 million users from day one. If you are new to scaling on AWS, you might ask yourself this question: “So how do I scale?”
- Scaling your application is a big topic, with lots of opinions, guides, and how-tos. …and it’s an iterative process. You don’t design for 10 million users from day one. If you are new to scaling on AWS, you might ask yourself this question: “So how do I scale?”
- If you are like me, you’ll start where I usually start when I want to learn how to do something – using a search engine.
- If you are like me, you’ll start where I usually start when I want to learn how to do something – using a search engine. In this case I’ve gone and searched for “scaling on AWS” in my favorite search engine
- AWS has developed the broadest collection of services available from any cloud provider. Our approach to regions, availability zones, and POPs provides global coverage for high availability, low latency applications. Foundation services across compute, storage, security, and networking offer customers flexibility in their architecture. We have a full spectrum of options to meet most price-to-performance scenarios. We offer the capability for both managed and unmanaged database options. The offerings for Analytics and Application Services enable advanced data processing and workloads. AWS Redshift, our cloud-based data warehouse, is the fastest growing service in the history of AWS. Our management tools offer a lot of insight and flexibility to let you manage your AWS resources through either our tools or the management tools you’re already familiar with. Recent expansion into enterprise applications has been entirely driven by customer feedback on where they’d like us to deliver value.
- AWS has global, regional, and services that are local to an AZ or datacenter. Many of these global and regional services are inherently fault tolerant. Examples of Global services include Cloudfront, our CDN, and Route 53, our DNS Service. Both of these services use the Edge locations to distribute load closest to the user. We have many platform services that are regional in nature. Many of these regional services are inherently fault tolerant by nature. When building an app, it is always much easier to use a fault tolerant service than work at building your own fault tolerant service. Here are a couple of good examples. S3 replicates data around the region and provides 11 9s of data durability on objects. DynamoDB writes to at least 2 AZs before responding with a commit successful and it does this all in single digit milliseconds ELB allows you to load balance to EC2 instances both publically and privately in multiple Azs in a region and is self healing and scales organically with your traffic. SQS replicates your messages around the region and these messages can be reached by API endpoints in any of the Azs Lastly, there are many services that are specific to an AZ or datacenter. Many of these services can be deployed in patterns to make the architecture HA or FT but the services are not FT by default. EC2 can be run in multiple Azs – something we are going to talk about more
- So let’s get started at day one, user one…which is most likely you
- So let’s get started at day one, user one…which is most likely you
- This here is the most basic set up you would need to serve up a web application. Any user would first hit Route53 for DNS resolution. Behind the DNS service is an EC2 instance running our webapp and database on a single server, We will need to attach an Elastic IP so Route53 can direct traffic to our webstack at that IP Address with an A record. To scale this infrastructure, the only real option we have is to get a bigger EC2 instance…
- Vertically Scaling the one EC2 instance we have to a larger one is the most simple approach to start with and that is where we will begin. There are a lot of different AWS instance types to go with depending on your work load. We group common instances into instance families as they have the same characteristics. We have our instance family that has a linear CPU to Memory ratio such as the M3s. Some have high I/O such as our I2 instance, others are CPU optimized such as our C3 and C4 instances, Others are Memory optimized such as our R3 instances, and we have some that are IO or storage optimized such as our I2 or D2 instances. T2 Instances – CPU credits latest generation of General Purpose Instances M4 10xl 40 Cores R3.8xl = 244 GB of RAM Inside of each instance family are different sizes ranging from Micro in the T2 family to 8XL in many of the other families. This allows you to vertically scale inside the family that best supports your workload. You can also make use of EBS-Optimized instances and Provisioned IOPs to help scale the storage for this instance quite a bit.
- This is all great at the beginning, but 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 you very far.
- So while we could reach potentially a few hundred or few thousand users supported by this single instance, its not a long term play.
- We also have to consider some other issues with this architecture; No Failover, No redundancy, and too many eggs in one basket, since we have both the database and webapp on the same instance. We need to be more strategic and start to break apart our application for both scaling and redundancy reasons.
- The first thing we can do to address the issues of too many eggs in one basket is to split out our Webapp and Database into two instances. This gives us more flexibility in scaling these two tiers independently. And since we are breaking out the Database, this is a great time to think about maybe making use of a database services instead of managing the DB ourselves… So what options do we have?
- At AWS there are a lot of different options to running databases. One is to just install pretty much any database you can think of on an EC2 instance, and manage all of it yourself. If you are really comfortable doing DBA like activities, like backups, patching, security, tuning, this could be an option for you. Also, if you need something highly specialized or customized and need to manage the hardware to achieve this, again this might be for you. If not, then we have a few options that we think are a better idea: First is Amazon RDS, or Relational Database Service. With RDS you get a managed database instance of either MySQL, Oracle, Postgres or SQL Server, with features such as automated daily backups, simple scaling, patch management, snapshots and restores, High availability, and read replicas - depending on the engine you go with. We also have Aurora in Preview today. Amazon Aurora is a MySQL-compatible relational database that combines the speed and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases. Aurora provides up to five times better performance than MySQL at a price point one tenth that of a commercial relational databases while delivering similar performance and availability. Next up we have DynamoDB, a NoSQL database, built on top of SSDs. DynamoDB is based on the Dynamo whitepaper published by Amazon.com back in 2003. This whitepaper was considered the grandfather of most modern NoSQL databases like Cassandra. DynamoDB is kind of like a cousin of the original paper or an evolution of that whitepaper. One of the key concepts to DynamoDB is what we call “Zero Administration”. With DynamoDB the only knobs to tweak are the reads and writes per second you want the DB to be able to perform at. You set it, and it will give you that capacity with query responses averaging in single digit millisecond. We’ve had customers with loads such as half a million reads and writes per second without DynamoDB even blinking. Lastly, we have Amazon Redshift, a multi-petabyte-scale data warehouse service. Redshift is managed, massively parallel and you speak ANSI SQL to it over the wire. With Redshift, much like most AWS services, the idea is that you can start small, and scale as you need to, while only paying for what you are using. What this means is that you can start on a smaller single node with Redshift and scale your DW cluster as your workload requires. Redshift is also several times cheaper than most other dataware house providers.
- So for this scenario today and based upon our discussion, we’re going to go with RDS and MYSQL as our database engine.
- 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 Now we have an app that is a bit more scalable and has some fault tolerance built in as well.
- Scaling this both horizontally and vertically will get us pretty far. 10s to 100s of thousands.
- Explain architecture Route 53 to ELB ELB to web instances Master for writes and read replicas for reads Stack is fault tolerant and has scaled quite a bit from where we started. Most of you will get to this point and be pretty well off honestly. You can take this really far for most web applications. We could scale this out over another AZ maybe. Add in another tier of read replicas.
- but its not that efficient in both performance or cost, and since those are important too, let’s clean up this infrastructure a bit.
- As mentioned, we can start by moving any static assets from our webapp instances to S3, and then serve those objects via CloudFront. This would be all of your images, videos, css, javascript and any other heavy static content. These files can be served via an S3 origin (more on S3 in the next slide) and then globally cached and distributed via Cloudfront. This will take load off your webservers and allow you to reduce your footprint in that web tier.
- We can also move things like session information to a NoSQL db like DynamoDB or to a cache like Elasticache. For our scenario, we will use DynamoDB for this as there are easy connectors in many of the AWS SDKs We can also use Elasticache to store some of our common database query results which will prevent us from hitting the database too much. This should take load off of our DB tier. Removing session state from our web / app tier is also very key as it allows us to scale up and down without losing session information when this horizontal scaling happens. This is called making our tier “stateless”
- 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. But this is a monolith. All of the application logic is running on each server. Can we make this better? We will dive into this topic after another short discussion.
- 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. But this is a monolith. All of the application logic is running on each server. Can we make this better? We will dive into this topic after another short discussion.
- You need to think about making deployments easy and very repeatable. To do this, you will need to add automation to your deployments. There are tools to automate deployment of AWS resources There are other tools that manage deployment of your software and configuration of an instance Lastly, you will want to monitor your application and analyze what users are doing on your application. This can be done with metrics, logs, and analytics. Managing your infrastructure will become an ever increasing important part of your time. Use tools to automate repetitive tasks: Tools to manage AWS resources Tools to manage software and configuration on your instances Automated data analysis of logs and user actions
- AWS provides a lot of tools to choose from in this area and we will discuss a few. Elastic Beanstalk is easiest to start with, but offers less control. EB allows you to not worry about managing the infrastructure for your application. You simply deploy your app such as a Ruby app, in a Ruby container, and EB takes care of scaling it and managing it. Opsworks allows you to manage the lifecycle of your application in layers with Chef recipes. We have out of the box recipes for managing many different types of layers and you can write custom chef recipes to manage any layers we don’t support. Cloudformation is infrastructure as code. It is a template based tool with its own language, so a bit of a learning curve, but very very powerful. You define json templates that define what infrastructure you want to build out and any relationships that exist between your infrastructure. Lastly you could do all this manually, but at scale its nearly impossible without a huge team. Recently we also introduced a number of services for storing your code, deploying your code, and managing continuous delivery and release automation. These services are called Code Commit, Code Deploy, and Code Pipeline. I would take a look at these as well.
- CodeDeploy, CodeCommit, CodePipeline ( Source code management, Continuous Integration) Deploys your released code to a "fleet" of EC2 instances Accommodate fleets that range in size from one instance all the way up to tens of thousands of instances Automatically schedules updates across multiple Availability Zones in order to maintain high availability during the deployment Application and Deployment groups described in YAML-formatted files Deployment groups identify EC2 instances by tags & can also reference Auto Scaling Groups Managed via AWS Management Console, CLI or APIs Can be used in conjunction with Chef recipes or Puppet scripts
- So now we are at a load of greater than 500K users At this point users you could start running into issues with speed and performance of your application. You will want to make sure you application is properly instrumented and you are monitoring, gathering metrics and performing log collection. There are many providers out there offering solutions in this space. AWS has tools such as CloudWatch, and there are many other choices out there that integrate well with AWS. Also listen to your customers. Send out a survey…gather feedback from super users, etc. Your users probably know best what works and what doesn’t perform well. Remember your goal is to squeeze as much performance out of every tier as possible, and without instrumenting your app, it is very hard to tell how you are performing. Speed and Performance have monitoring, metrics, and logging in place If you can’t build it internally, outsource it! (Third-party SaaS) Pay attention to what customers are saying works well vs. what doesn’t, and use this direction Try to squeeze as much performance out of each service/component
- Here are some examples. Host Level metrics are great for deep diving on problems, but aggregate level metrics will be more valuable as a bigger picture of what is going on with your infrastructure. Log analysis is also very much needed, and incredibly powerful to have in your infrastructure. Don’t skimp on it. Log everything centrally. Here is an example of logging with CW Logs but there are many other solutions out there from third party providers as well. Lastly we have external site metrics. Its amazing how many people don’t think about this last one here. You need to understand how your site is performing from the view of your end users. This graph appears to be one from Pingdom, but you might also do this with tools such as New Relic which can also dig into Application performance monitoring. ( top two are from CloudWatch, bottom left is from CW Logs, bottom right is Pingdom)
- We still are in a position where we have a very monolithic application where all logic and functionality is running on the webserver. We have a single webapp tier doing all of our application workload. While that works for some sites and applications, for many it doesn’t. Which brings us on to our next topic…
- SOA, what does this mean? I will tell you what it doesn’t mean first…Sons of Anarchy! At least not in this presentation. It does mean Service Oriented Architecture and hopefully that is what you expected.
- If you are like me, you’ll start where I usually start when I want to learn how to do something – using a search engine. In this case I’ve gone and searched for “scaling on AWS” in my favorite search engine
- If you are like me, you’ll start where I usually start when I want to learn how to do something – using a search engine. In this case I’ve gone and searched for “scaling on AWS” in my favorite search engine
- So with SOA, you want to move different services your application into different tiers or modules. From there, you can treat them as separate pieces of your infrastructure that you can scale and make them fault tolerant separately. Amazon.com and AWS have hundreds of services under the hood that represent the sites and services you see. It’s a core principle in application/service development at Amazon.
- AWS has quite a few services that can solve key functionality areas in your application. Combining loose coupling, SOA, and prebuilt services, can also really have some huge advantages. Instead of writing all these mini services yourself, try and leverage already existing services and applications, especially when you are starting out. DON’T REINVENT THE WHEEL! For example, at AWS we have services to help you with Email, Queues, Transcoding, Search, Databases, and Monitoring and Metrics. Lean on other 3rd parties for more. Loose coupling different tiers of your architecture and using SOA gives you the ability to move quickly
- When services are loosley coupled, they can scale and be made fault tolerant independently of each other. The looser that services are coupled the larger they can scale So remember: Design everything as a black box Build separate services instead of something that is tightly interacting with something else Uses common interfaces or common APIs between the components And remember to favor services with built-in redundancy and scalability rather than building your own; such as the two examples provided below
- This diagram is missing the 2nd (and maybe third) AZ, but we’ve only got so much room on the slide. But we can see we’ve added in some internal pools for different tasks perhaps. Maybe we’re using SQS for something, and have SES for sending our out bound email. We may have Lambda catching events or items from S3 and DynamoDB and processing them. We are using caching for the database and have built stateless tiers for our web and app tiers Again our users will still talk to Route53, and then to CloudFront to get to our site and our content hosted back by our ELB and S3.
- So what are the next big steps we need to think about?
- When we start getting into the 5M user plus range, we may start seeing database contention issues on writes to the Master We are going to drill into a couple of techniques to solve these types of issues, and those include Federation and Sharding
- Database Federation is where we break up the database by function. In our example, we have broken out the Forums DB from the User DB from the Products DB Of course, cross functional queries are harder to do and you may need to do your joins at the application layer for these types of queries This will reduce our database footprint for a while and the great thing is, this does prevent you from having to shard until much further down the line. This isn’t going to help for single large tables; for this we will need to shard.
- Sharding is where we break up that single large database into multiple DBs. We might need to do this because of database or table size or potentially for high write IOPs as well. Here is an example of us breaking up a database with a large table into 3 databases. Above we show where each userID is located, but the easiest way to describe how this would work would be to use the example of all users with A-H go into one DB, and I – M go in another, and N – Z go into the third DB. Typically this is done by key space and your application has to be aware of where to read from, update and write to for a particular record. ORM support can help here. This does create operation complexity so if you can federate first, do that. This can be done with SQL or NoSQL, and DynamoDB does this for you under the covers on the backend as your data size increases and the reads / writes per second scale.
- OK so maybe now we are thinking of NoSQL. Implementing this would be similar to implementing federation. I would no longer have relationships via the tables, so I would need to query any of my tables and join them through code. Think about all of the earlier reasons to use NoSQL. Are you there yet? Maybe. Leveraging a hosted service like DynamoDB would be a good idea as it will save you time and manpower. Go through common use cases.
- Read slide
- Read slide
- And beyond
- Read slide
- A couple of things to think about for going beyond 10 million users: More fine-tuning of your application; pay attention to your metrics and monitoring; pay attention to your users More SOA of features/functionality and breaking out individual services into their own tiers or modules Going from Multi-AZ to multi-region might make sense with use of LBR in Route 53 which will send a user to the nearest region based on latency Possibly start to build custom solutions; canned solutions may not work for your particular reqs anymore Do a deep analysis of your entire stack and do what makes sense
- Read slide
- Read slide