Instaclustr has released support for a new AWS I3en instance type with our Apache Cassandra & Spark Managed Service.
I3en is the latest generation of AWS’s “Storage Optimised” family of EC2 instances designed to support I/O intensive workloads, backed by low-latency SSD. The i3en family of instances also are built upon the new generation of AWS nitro virtual machines which offer improved security with continuous monitoring of instances and dedicated hardware and software for different virtualized resources providing improved performance.
Instaclustr customers can now leverage these benefits with the release of the i3en.xlarge instance type, which provides 4 vCPUs, 32 GiB memory, and 2500 GB of locally attached SSD. As a comparison, the i3.2xlarge offers 8 vCPUs, 61 GiB memory and 1 x 1900 GB SSDs.
The increased local storage and higher performance virtualisation of the i3en.xl provides a significant cost advantage for many use cases. This advantage is particularly evident when used as a reserved instance and running in your AWS account where the i3en.xl offers the most cost effective storage of any of our offerings. To illustrate (AWS costs only):
- An r5.xlarge instance instance costs $1,298 per year and provides roughly equivalent compute capacity (cores and memory) to an i3en.xl
- An i3en.xlarge costs $2,517 per year but provides 2,500GB of storage for the $1,219 additional cost
This works out to a cost per GB of $0.041 per month – less than half the $0.1 per GB per month cost of GP2 EBS. The local SSD also provides better performance than EBS. Cassandra’s native replication of data across multiple instances deals with the issue of data on local SSDs getting lost when an instance fails and Instaclustr’s advanced node replace also helps to deal with some of the operational issues inherent while working with with local SSDs.
Benchmarking of I3en Instance Type
We conducted Cassandra benchmarking of the I3en.xlarge type and compared with the results of a I3.2xlarge cluster. This comparison isn’t exactly “apples to apples” with the i3.2xlarge having double the cores and memory, however it is still useful as a price/performance comparison to see how the two instances stack up.
Our testing procedure is:
- Insert data to fill disks to ~30% full.
- Wait for compactions to complete.
- Target median latency of 10ms.
- Run a sequence of tests comprising read, write and mixed read/write operations.
- Run the tests and measure the results including operations per second, pending compactions and median operation latency.
- Quorum consistency for all operations.
- We incrementally increase the thread count and re-run the tests until we have hit the target median latency and are under the allowable pending compactions
As with any generic benchmarking results, for different data models or application workload, the performance may vary from the benchmark. However, we have found this to be a reliable test for comparison of relative performance that will reflect in many practical use cases.
This benchmarking used Cassandra 3.11.4 and compared a 3-node i3.2xlarge cluster and a 3-node i3en.xlarge. Driving operations to the point where latency on each node was similar, 3-node i3en.xlarge cluster yielded 16,869 operations/sec compared to the i3.2xlarge which achieved 24,023. So, the i3en.xlarge provided roughly 70% of the performance of the larger sized and more expensive i3en.2xlarge cluster.
Although it has half the cores and memory, the performance of the i3en.xlarge be explained by an increase of clock speed on each core, as well as gains from AWS’s new Nitro virtualisation technology.
However, raw performance is only part of the equation for this node size; price and storage size also play a part in making the i3en.xlarge a more attractive offering.
Instaclustr offers i3en instances at a price commensurate with its performance in comparison to the i3.2xlarge, around 70% of the price. The other key factor is the disk size, with the i3en.xlarge having 30% more disk available compared to its more expensive counterpart.
This makes the i3en.xlarge an extremely attractive option for customers with a use case that has a lower throughput (ops/sec) to stored data requirement than that is provided by the i3.2xlarge (which has relatively more processing power per GB of data stored).
|AWS Instance type||Operation type||Operations/s||Median latency (ms)|
Table 1: Results summary
Note the target latency of 10ms is not always being reached due to the limitation of the stress tool and the high throughput of these instance types.
In order to assist customers in upgrading their Cassandra clusters from currently used instance types to i3en instance type nodes, Instaclustr technical operations team has built several tried and tested node replacement strategies to provide zero-downtime, non-disruptive migrations for our customers. Reach out to our support team if you are interested in i3en instances for your Cassandra cluster.
Also published on Medium.