AWS Case Study: Parse
Parse provides cloud-based backend services for mobile application developers. The San Francisco-based startup delivers a full stack of mobile services so that developers can focus on developing applications and leave the infrastructure to Parse. Launched in 2012, this fast-growing start-up provides server management for about 60,000 Android, iOS, and Windows mobile applications, which run on more than 200 million mobile devices.
Parse operates a number of high-throughput, I/O intensive MongoDB clusters and needed to improve scalability and speed. Parse handles user account management, data storage and disk caching for its customers and usage can fluctuate on a daily basis. Charity Majors, Site Reliability Engineer says, “If an application developed on Parse is featured on iTunes, traffic can triple or quadruple in a matter of hours. Our platform needs to be consistent and fast. If Parse has operational issues, then more than 50,000 mobile applications have operational issues. We don’t have the luxury of taking the platform down for 15 minutes to fix something.”
Why Amazon Web Services
For Parse, AWS is the only cloud provider fully featured enough to handle its requirements. “We were already looking for improvements to our MongoDB cluster. Amazon EBS Provisioned IOPS, which is designed to provide predictable, high performance for I/O intensive workloads, is a natural fit for our needs,” says Majors.
The Parse team is using striped 1000 Provisioned IOPS volumes for MongoDB clusters running on Amazon Elastic Compute Cloud (Amazon EC2) instances. The engineers use Elastic Load Balancing at the top of the stack to distribute connections to web servers, which connect to application servers that communicate with the databases. Figure 1 illustrates Parse’s environment.
Parse runs its MongoDB databases in replica sets that include one primary and two secondary databases. Parse uses Amazon Elastic Block Store (Amazon EBS) to create snapshots frequently for each MongoDB shard, which is then uploaded to an Amazon Simple Storage Service (Amazon S3) bucket. If necessary, Parse can bring up a new node in a matter of minutes using Amazon S3 and join it to a cluster.
“We stripe volumes for better performance but we’re not using RAID 10 anymore,” notes Majors. “If you’re using RAID 10 and the RAID array gets degraded, you have to remove the bad volume, add a new volume and build a new array. We’ve found that it’s actually faster for us to rebuild the volumes from Amazon S3 backups.”
Before moving to EBS Provisioned IOPS, Parse experienced disk spikes and measured end-to-end latency up to 400 milliseconds. Now, Majors estimates the average end-to-end application latency has dropped to less than 100 milliseconds. “Latency in our stack is almost completely flat,” she reports. “We’re not seeing periodic latency spikes due to MongoDB write locks or Amazon EBS events. We have scripts that warm up our databases by reading the most active collections into memory, but we don’t really need to use them with the Provisioned IOPS volumes. Memory warm-up time has been cut by over 80% and added latency time is miniscule.”
Parse also plans to use EBS Provisioned IOPS when it deploys its Cassandra cluster to production. “We don’t have the option of downtime or poor performance with our platform, says Majors. “Provisioned IOPS gives us consistency, reliability, and low latency. Anytime we need performance, we will use AWS and Provisioned IOPS.”
To learn more about how AWS can help your database storage needs, visit our Amazon Elastic Block Store (EBS) details page: http://aws.amazon.com/ebs/.