A Beginner's Guide To Scaling To 11 Million+ Users On Amazon's AWS

  • 0

    La guia completa aquí

    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?



    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.

    In Review

    Use a multi-AZ infrastructure for reliability.

    Make use of self-scaling services like ELB, S3, SQS, SNS, DynamoDB, etc.

    Build in redundancy at every level. Scalability and redundancy are not two separate concepts, you can often do both at the same time.

    Start with a traditional relational SQL database.

    Cache data both inside and outside your infrastructure.

    Use automation tools in your infrastructure.

    Make sure you have good metrics/monitoring/logging in place. Make sure you are finding out what your customers experience with your application.

    Split tiers into individual services (SOA) so they can scale and fail independently of each other.

    Use Auto Scaling once you’re ready for it.

    Don’t reinvent the wheel, use a managed service instead of coding your own, unless it’s absolutely necessary.

    Move to NoSQL if and when it makes sense

Has perdido la conexión. Reconectando a Éxodo.