Performance is an important consideration when deploying MongoDB on AWS. From a hardware perspective, MongoDB performance on EC2 is gated primarily by two factors – RAM and disk speed. Typically (there are always exceptions), CPU should not be an issue, nor memory, as there are plenty of size options available (R3, I2, C3/C4) that offer a large amount of RAM. For more details on how to choose the right instance type, check my other blog post: How to choose the right EC2 Instance type
Historically, disk speed and latency have been a constant problem on Amazon EBS. However, Amazon Web Services now offers a couple options to help you with disk performance:
Provisioned IOPS Disks
In the provisioned IOPS model, you can specify at disk creation time the number of IOPS you would like your disk to support. The more IOPS you provision, the more throughput your disk will be able to handle. You can go all the way up to 4000 IOPS/disk! However, IOPS can get expensive at $0.065 per IOPS month. For example, if you provision 4000 IOPS for the disk, it will cost you $260/month for just the IOPS alone. This can add up quickly if you have multiple servers.
This is the best option for disk performance on Amazon AWS. Local SSD’s provide the best throughput and latency behavior of all AWS disk options. However, they’re called ‘local’ for a reason. If, for any reason, your virtual machine (VM) is stopped, the allocated local storage is released. So, the burden of data reliability is squarely on the user. Could you deploy two local SSD data stores in two different availability zones (AZ) and call it solved? Not quite. If AWS has a region-wide outage like it did in US-East a few years before, you should expect to lose your local SSD’s in all your AZ’s. For these reasons, local SSD instances should not be used as the primary data store for your data.
High-Performance MongoDB: 3-Node Replica Set
With these issues in mind, we are introducing our high-performance MongoDB configuration on AWS. The high-performance clusters use a hybrid of local SSD and EBS provisioned IOPS disk to achieve both high performance and high reliability. A typical configuration is deployed using a 3-node replica set.
- The Primary and the Secondary 1 use local SSD disks
- Secondary 2 uses EBS provisioned IOPS
High Performance MongoDB 3-Node Replica Set
What does this mean? Since the Primary and the Secondary 1 are running on local SSD, you get the best possible disk performance from your AWS machines. No more network-based EBS, just blazing fast local SSD. Reads and writes to your Primary and even the reads from the Secondary 1 will work at SSD speed. Secondary 2 uses EBS provisioned IOPS for the data disk and you can configure the amount of IOPS to configure for your cluster. This configuration provides complete safety for your data, even in the case where you use the local SSD disks. We’re currently offering four sizes – Large, XLarge, X2XLarge, X4XLarge. For more details refer to the Bring Your Own Cloud (BYOC) and Dedicated Clusters sections on our pricing page.
If you have a very high write workload, it’s possible that your EBS instance might not be able to keep up with your SSD instances. In this scenario, there are a few options available and our support team would be happy to walk you through them. All of our existing functionality, including backups, restores, clones, scaling, compact, etc. continue to work as usual. If you have further questions, please reach out to us at email@example.com.