Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Oh No, You Have to Scale!

Oh No, You Have to Scale!

Given at Geekend 2014, this is my introduction to scaling web applications for a semi-technical audience.

Kevin Lawver

November 17, 2014
Tweet

More Decks by Kevin Lawver

Other Decks in Technology

Transcript

  1. Oh No, You
    Have to Scale!
    Kevin Lawver
    Geekend 2014
    @kplawver

    View Slide

  2. Hi, I’m Kevin

    View Slide

  3. I build web things,
    and help scale them.

    View Slide

  4. Your Server, Right Now
    Hi!

    View Slide

  5. Poor little thing…

    View Slide

  6. It’s all alone, trying to
    do everything.

    View Slide

  7. Just like you.

    View Slide

  8. The Problems
    • As your data grows, query speed decreases.
    • As your app grows, it gets more complex.
    • As complexity grows, so do the number of
    dependencies.
    • As traffic grows, all of those problems end up
    getting worse.

    View Slide

  9. Problem: Your
    database hates you.

    View Slide

  10. It will eventually try to
    hurt you.

    View Slide

  11. When you least expect
    it.

    View Slide

  12. Index it.
    Indexes help keep your “hot” queries fast and allows you to keep your app performing well as your data grows.
    What do you index? Anything you query or sort on!
    If you query and sort on different columns in a query, they should be in a compound index!
    As your data grows, your queries need to get simpler!

    View Slide

  13. Protect it.
    Use memcached, varnish, etc. Put a protective wall of cache around your data. Let your database work hard on things other layers can’t do (writes). Let the other layers
    handle reads.

    View Slide

  14. Multiply it.
    Use read secondaries to scale reads.

    Most apps are read-heavy. Take advantage of that.

    View Slide

  15. Problem: Complexity

    View Slide

  16. As your app grows, it
    does more.

    View Slide

  17. Which means more
    complexity in the code.

    View Slide

  18. Don’t make your users
    pay for complexity!
    Users are impatient! Requests should be less than 100ms in most cases!

    View Slide

  19. Push hard things to
    the background.
    Don’t make your users wait for things that are slow! Set up a job queue and do hard things in the background!

    Use reporting as example - pre-generate reports instead of making users wait for them and generating them when they’re requested!

    Document stores like MongoDB are GREAT for reporting.

    View Slide

  20. Do as little in a
    request as possible.
    Pre-process things that are difficult to generate or things that aren’t time sensitive.

    See if you can get to one query per request! It’s hard, but that should be the goal.

    View Slide

  21. Again, cache
    everything you can!
    You can cache pieces of your page in memcached or varnish. It’s awesome.

    View Slide

  22. Problem:
    Dependencies

    View Slide

  23. Think in services
    Think about every piece of your app as a service. What are the interfaces? What does it require? What happens when it fails? We’ll get to that…

    View Slide

  24. Not everything needs
    a hammer.
    Use the right tool for the job. Is your data relational? Use a relational database! Want to do search? Don’t do it in your relational database! There are search engines for
    search!

    Take the time to explore your options - and seek out people who’ve done it before and ask them their opinion.

    View Slide

  25. Be a little paranoid.
    It pays to be a little paranoid - if you use an API, what happens when it goes down? How will your app react? Test it and find out, and then protect yourself from it. Your
    customers don’t care if your app being down is your fault or not - they’ll blame you!

    View Slide

  26. Think a couple steps
    ahead
    Ask yourself: “what will I do when this breaks?” “what are some other ways to do this?”

    Think about how things will scale - but don’t get caught up future-proofing things. Your primary job is to get things done. Just keep an eye out for problem spots and fix
    them before they stop everything in its tracks.

    View Slide

  27. Understand Your
    App’s Performance!
    Use tools like Scout or NewRelic to instrument your app so you can spot trouble areas before they cause outages!

    View Slide

  28. Problem: Scale

    View Slide

  29. Go horizontal.
    Get away from a single server. Think of your dependencies as services and treat them as external, even if they’re not. It will make it easier to split things up later on.

    View Slide

  30. Think of your app as a
    cake.

    View Slide

  31. Load Balancer
    Application
    Cache
    Database
    ETC…

    View Slide

  32. Every layer should be
    able to scale
    independently.

    View Slide

  33. And if they can’t, find a
    new way to do that job.

    View Slide

  34. Example

    View Slide

  35. Load Balancer Load Balancer
    App Server App Server App Server
    Cache Cache
    Database Database Database

    View Slide

  36. Your system should
    expand at any layer.

    View Slide

  37. Make more cake!
    Invest in operations. Find people who love to keep things working. Hire them. Support them. Love them.

    View Slide

  38. The Future

    View Slide

  39. Services
    I know, you’re probably sick of this, but really, they’re super important and will only get more important.

    View Slide

  40. Browsers doing more
    work.
    Start looking at ways to cache data in the browser instead of on the server. Give your users the appearance of performance! Look at local storage for assets, and even
    the new built-in database options! Lots of fun stuff going on in browsers now!

    View Slide

  41. Containers
    (you know, Docker)
    Everyone’s talking about Docker - and containers in general - as a way to make virtualization more efficient. Worth keeping an eye on, but feels too early to jump on for
    mission-critical stuff where your data is important (great for app servers, bad for database servers).

    View Slide

  42. Everyone wants to
    lock you into their box.
    Beware vendor lock-in and closed-source solutions! Build everything in your app as an interface or API so you can replace the underlying implementation when you need
    to.

    Default to open source, even if you start out with a SaaS platform!

    View Slide

  43. More Reading…

    View Slide

  44. The Pragmatic
    Programmer
    Technology-agnostic, easy to read primer on professional software development and how to become an awesome developer - especially the stuff on Orthogonality!

    View Slide

  45. 12factor.net
    A great place to start when you’re building an app for best practices!

    View Slide

  46. reactivemanifesto.org
    Great set of goals for designing systems.

    View Slide

  47. Today from 2-4!
    Here!
    Play games made by
    kids!

    View Slide

  48. Questions?
    • @kplawver
    • kevinlawver.com
    [email protected]

    View Slide

  49. Thank you!

    View Slide