【系统设计】从小公司到上亿用户公司的架构演变（A Beginner‘s Guide To Scaling To 11 Million+ Users On Amazon‘s AWS）总结笔记

1 User

In this scenario you are the only user and you want to get a website running.

Your architecture will look something like:

1 Run on a single instance, maybe a type t2.micro. Instance types comprise varying combinations of CPU, memory, storage, and networking capacity and give you the flexibility to choose the appropriate mix of resources for your applications.
2 The one instance would run the entire web stack, for example: web app, database, management, etc.
3 Use Amazon Route 53 for the DNS.
4 Attach a single Elastic IP address to the instance.

Users > 10

Method 1: Separate out a single host into multiple hosts

• One host for the web site.
• One host for the database. Run any database you want, but you are on the hook for the database administration.
• Using separate hosts allows the web site and the database to be scaled independently of each other. Perhaps your database will need a bigger machine than your web site, for example.

Method 2: Or instead of running your own database you could use a database service.

• Are you a database admin? Do your really want to worry about backups? High availability? Patches? Operating systems?
• A big advantage of using a service is you can have a multi Availability Zone database setup with a single click. You won’t have to worry about replication or any of that sort of thing. Your database will be highly available and reliable.

AWS能提供给你的：

• Amazon RDS (Relational Database Service). There are many options: Microsoft SQL Server, Oracle, MySQL, PostgreSQL, MariaDB, Amazon Aurora.
• Amazon DynamoDB. A NoSQL managed database.
• Amazon Redshift. A petabyte scale data warehouse system.
• Amazon Aurora.

策略：Start with a SQL database instead of a NoSQL database.

• The suggestion is to start with a SQL database.
• The technology is established.
• There’s lots of existing code, communities, support groups, books, and tools.
• You aren’t going to break a SQL database with your first 10 million users. Not even close. (unless your data is huge).
• Clear patterns to scalability.

问题：为啥我要When might you need start with a NoSQL database?
回答：当有以下情景的时候：

• If you need to store > 5 TB of data in year one or you have an
  incredibly data intensive workload.
• Your application has super low-latency requirements.
• You need really high throughput. You need to really tweak the IOs you are getting both on the reads and the writes.
• You don’t have any relational data.

Users > 100

• Use a separate host for the web tier.
• Store the database on Amazon RDS. It takes care of everything.
  That’s all. Nice and simple.

Users > 1000

As architected your application has availability issues. If the host for your web service fails then your web site goes down.

So you need another web instance in another Availability Zone. That’s OK because the latency between the AZs is in the low single digit milliseconds, almost like they right next to each other.

You also need to a slave database to RDS that runs in another AZ. If there’s a problem with the master your application will automatically switch over to the slave. There are no application changes necessary on the failover because your application always uses the same endpoint.

An Elastic Load Balancer (ELB) is added to the configuration to load balance users between your two web host instances in the two AZs.
（具体ELB是什么请参见本博主文章什么是Elastic Load Balancer (ELB)【AWS中的概念】）

Users > 10,000s - 100,000s

The previous configuration has 2 instances behind the ELB, in practice you can have 1000s of instances behind the ELB. This is horizontal scaling.

You’ll need to add more read replicas to the database, to RDS. This will take load off the write master.

Consider performance and efficiency by lightening the load off your web tier servers by moving some of the traffic elsewhere. Move static content in your web app to Amazon S3 and Amazon CloudFront. CloudFront is the Amazon’s CDN that stores your data in the 53 edge locations across the world.

You can also lighten the load by shifting session state off your web tier.

• Store the session state in ElastiCache or DynamoDB.
• This approach also sets your system up to support auto scaling in the future.

You can also lighten the load by caching data from your database into ElastiCache.

• Your database doesn’t need to handle all the gets for data. A cache can handle a lot of that work and leaves the database to handle more important traffic.

You can also lighten the load by shifting dynamic content to CloudFront.

• A lot of people know CloudFront can handle static content, like
  files, but it can also handle some dynamic content. This topic is not
  discussed further in the talk, but here’s a link.

Users > 500,000+

The addition from the previous configuration is auto scaling groups are added to the web tier. The auto scaling group includes the two AZs, but can expand to 3 AZs, up to as many as are in the same region. Instances can pop up in multiple AZs not just for scalability, but for availability.

The example has 3 web tier instances in each AZ, but it could be thousands of instances. You could say you want a minimum of 10 instances and a maximum of a 1000.

ElastiCache is used to offload popular reads from the database.

DynamoDB is used to offload Session data.

You need to add monitoring, metrics and logging.

• Host level metrics. Look at a single CPU instance within an
  autoscaling group and figure out what’s going wrong.
• Aggregate level metrics. Look at metrics on the Elastic Load Balancer to get feel for performance of the entire set of instances.
• Log analysis. Look at what the application is telling you using
  CloudWatch logs. CloudTrail helps you analyze and manage logs.
• External Site Performance. Know what your customers are seeing as end users. Use a service like New Relic or Pingdom.

You need to know what your customers are saying. Is their latency bad? Are they getting an error when they go to your web page?

Squeeze as much performance as you can from your configuration. Auto Scaling can help with that. You don’t want systems that are at 20% CPU utilization.

Users > 10,000,000+

As we get bigger we’ll hit issues in the data tier. You will potentially start to run into issues with your database around contention with the write master, which basically means you can only send so much write traffic to one server.

How do you solve it?

• Federation
• Sharding
• Moving some functionality to other types of DBs (NoSQL, graph, etc)

Federation - splitting into multiple DBs based on function

• For example, create a Forums Database, a User Database, a Products Database. You might have had these in a single database before, now spread them out.
• The different databases can be scaled independently of each other.
• The downsides: you can’t do cross database queries; it delays getting to the next strategy, which is sharding.

Sharding - splitting one dataset across multiple hosts

• More complex at the application layer, but there’s no practical limit
  on scalability.
• For example, in a Users Database ⅓ of the users might be sent to one shard, and the last third to another shard, and another shard to another third.

Moving some functionality to other types of DBs

• Start thinking about a NoSQL database.
• If you have data that doesn’t require complex joins, like say a
  leaderboard, rapid ingest of clickstream/log data, temporary data,
  hot tables, metadata/lookup tables, then consider moving it to a
  NoSQL database.
• This means they can be scaled independently of each other.

Users > 11 Million

Scaling is an iterative process. As you get bigger there’s always more you can do.

Fine tune your application.

More SOA of features/functionality.

Go from Multi-AZ to multi-region.

Start to build custom solutions to solve your particular problem that nobody has ever done before. If you need to serve a billion customers you may need custom solutions.

Deep analysis of your entire stack.

总结：
要注意的点：

1 Use a multi-AZ infrastructure for reliability.
2 Make use of self-scaling services like ELB, S3, SQS, SNS, DynamoDB, etc.
3 Build in redundancy at every level. Scalability and redundancy are not two separate concepts, you can often do both at the same time.
4 Start with a traditional relational SQL database.
5 Cache data both inside and outside your infrastructure.
6 Use automation tools in your infrastructure.
7 Make sure you have good metrics/monitoring/logging in place. Make sure you are finding out what your customers experience with your application.
8 Split tiers into individual services (SOA) so they can scale and fail independently of each other.
9 Use Auto Scaling once you’re ready for it.
10 Don’t reinvent the wheel, use a managed service instead of coding your own, unless it’s absolutely necessary.
11 Move to NoSQL if and when it makes sense.