Scaling a shiny, new mobile app to support the throngs of users clamoring to get access is never easy. For some reason, it seems the scaling issue always crops up at the most inopportune time, like when you want to build more of the features the masses are begging for. But as the infrastructure starts to buckle under the collective load of your hockey stick growth, you have no choice. You must pull developers from their “real” jobs to try to save the hockey stick. Clearly, the best time to start thinking about scale is before you need it.
When you do start thinking seriously about scale, you’ll want to pay the most attention to your database; it’s the main bottleneck. But you will also want to make sure your app servers are up to the task. By keeping the following tips in mind, you can meet that hockey stick growth smoothly and naturally -- without turning your developers into a volunteer fire department.
All about that database
An application is only as good as the database architecture that powers it. It doesn’t matter if you’re running MySQL or this week’s hottest flavor of NoSQL -- your app is only as fast as the last read/write your database performed. With that in mind, keep your eye on a few factors when pushing that database as fast and as far as it can go.
Check your index usage. The biggest bang for your buck often comes in adding new indexes to your database. Profile your database and examine the slowest-running queries with a focus on those queries not using an index. This can be a key instruction manual to increasing response time. But be careful not to add too many indexes; that can hamper performance as well. There's a delicate balance.
Monitor database locks. Take a hard look at queries that place read/write locks on your database. Any time a query places a lock on a table, there is potential for a serious slowdown. Make sure the queries execute as quickly as possible.
Caching servers. If you’ve already done everything you can to optimize your queries, then it may be time to look at some caching servers such as Redis or Memcached. They can be particularly useful if you have queries returning data that doesn’t change often. Instead of your app hitting the database every time, your caching server can simply return the cached version while updating the cached data at set intervals (say, once every 30 seconds). This can lead to huge reductions in load if your users were performing the same query multiple times per second.
Throw more servers at the problem. If you’ve tried everything else, it may be time to add replica servers or even consider sharding (a method of partitioning the data in your database), depending on your data architecture. If your application doesn’t store a large amount of data per user in your database, then replication might be the way to go. Replication can distribute the query load of your servers across multiple machines, as each server will have a full copy of the data. If you are on the other side of the coin and run a data-heavy application, you should look at sharding when you first create your database. With sharding, it’s like you have one database spread across multiple servers, thus distributing the query load across those servers (called shards).
Once you’re done optimizing your database, that’s more than half the battle. Aim to keep your query response time consistently low, plan for capacity building, and make sure the hard disks you’re running on have high IOPS to ensure faster read/writes.
App servers of the world unite
Now that you’ve done the hard part, it’s time to talk about your application servers. For scaling purposes, you’ll probably want to have some way to distribute the load across them. You should consider using a load balancer or a proxy. A good example of this in action is the wonderful work being done on Nginx. If Nginx isn’t an option, consider a good, old-fashioned load balancer.
While you’re at it, in the “mobile first” world in which we live, it’s even more important to have your application return data to the client in a compressed format. Not every user will be viewing your application over a fast Wi-Fi connection; some may be using their cellphone’s data service. Making sure they get the information quickly with as little impact to their data plan as possible is becoming more and more important every day. The good news is that many proxies (like Nginx) and app servers will handle this for you automatically.
Expect the unexpected
Having paid the proper attention to your database and app servers, your mobile back end should be running better than ever. The only problem is that every so often you get an unexpected spike in traffic. That’s good for the business, but potentially horrible for your server infrastructure. If you are not ready for spikes, prepare for some of the most stressful hours you’ll ever experience at work.
The solution: Make sure you have a process in place to spin up new servers on demand. Consider having some servers in a powered-down state sitting there, waiting for the day when your traffic goes through the roof. Then all you’ll have to do is power them up and type in a couple of commands -- you’ll have extra database servers up and running with the most recent copy of the data. The same can be done with your application servers and proxy servers.
For those days when the demand is truly more than you could have ever dreamed of, make sure to have images of the latest virtual machines you've set up to run each of your servers. That way, you can easily spin up a new VM with the latest configuration and have it plugged in to your infrastructure in minutes, not hours.
Even if you’re able to accomplish only some of these items, scaling your mobile app will no longer be the fire drill it used to be.
Nishant Patel is CTO of built.io. Nishant brings 15 years of experience solving complex technology and cloud integration problems for large enterprises. Prior to founding built.io, Nishant was a Senior Architect at TIBCO Software. Nishant holds a bachelor's in Computer Science from Ohio State University. Follow him on Twitter: @Nishantsf.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to email@example.com.