Google EKM Performance Summary

We have tested ten environments to capture performance metrics for the CipherTrust Cloud Key Manager (CCKM) Google External Key Manager (EKM) integration. The below results demonstrate the effects of deployment choices on throughput for EKM endpoint wrap operations. This can help you plan your CipherTrust Manager deployment to meet your performance needs for Google EKM.

There is a Google requirement that wrap and unwrap requests must be completed within 150 ms, so results are presented to show the throughput possible before meeting that threshold.

Actual performance numbers in your environment can be different. The results can vary based on factors such as how and where the CipherTrust Manager is deployed, CipherTrust Manager resources, the location of clients, the network connectivity, and how the traffic is load-balanced.

Tested Environments

All environments used an open source k6.io tool as the REST client, run from a Debian virtual machine. The Virtual Machine was hosted on Google Cloud Platform in us central 1a zone with 8 vCPUs of 64 GB memory, and 50 GB memory disk.

The following CipherTrust Manager deployments were tested:

• Google Cloud Platform deployments:

  • Single CipherTrust Manager with 4 CPUs and 16 GB RAM.

  • Single CipherTrust Manager with 8 CPUs and 64 GB RAM.

  • Two clustered CipherTrust Manager nodes with a load balancer, each with 4 CPUs and 16 GB RAM.

  • Two clustered CipherTrust Manager nodes with a load balancer, each with 8 CPUs and 64 GB RAM.

• AWS Cloud deployments:

  • Single CipherTrust Manager with 4 CPUs and 16 GB RAM.

  • Single CipherTrust Manager with 8 CPUs and 64 GB RAM.

• Azure Cloud deployments:

  • Single CipherTrust Manager with 4 CPUs and 16 GB RAM.

  • Single CipherTrust Manager with 8 CPUs and 64 GB RAM.

• Single on-premises physical appliance, model CipherTrust Manager k470. See hardware specifications for memory and CPU values.

• Single Virtual CipherTrust Manager k170v deployed in ESXi private cloud, with 4 CPUs, 16 GB RAM, and 50 GB HDD.

CipherTrust Managers were deployed as geographically close to the k6.io client as possible, to avoid potential network latencies which can occur when crossing geographic regions.In your EKM deployment, we similarly recommend deploying the Virtual CipherTrust Manager instance geographically close to one of the Google Cloud KMS regions where you intend to set up the Google Cloud KMS Key Ring.

Network Requirements

The following ports were opened to ensure CipherTrust Manager/CCKM communication:

Test Process

The test consisted of starting a given number of virtual users to perform wrap operations on the EKM endpoint. Each user simulated a separate thread.

Total test duration was 40 seconds for each reading. The test was divided into the following increments:

• Ramp-up time was 5 seconds. Virtual users were started.

• Test duration was 30 seconds for each reading. Virtual users make wrap requests during that time.

• Ramp-down time was 5 seconds. Virtual users were stopped until there were zero active virtual users.

Repeating the Test in Your Environment

We have published the scripts used with k6.io on Github, for you to repeat the tests in your own environments as desired.

Google Cloud Deployment Results

For each environment, we chart operations per second against response time (within 90% of the operations). The Google threshold of 150 ms is shown.

GCP Single Node Low Memory

This setup includes a single node with 4 CPUs and 16 GB memory.

GCP Single Node High Memory

This setup includes a single node with 8 CPUs and 64 GB memory.

GCP Two Node Cluster Low Memory

This setup includes two clustered CipherTrust Manager nodes with a load balancer, each with 4 CPUs and 16 GB RAM.

GCP Two Node Cluster High Memory

This setup includes two clustered CipherTrust Manager nodes with a load balancer, each with 8 CPUs and 64 GB RAM.

Google Cloud Environment Comparisons

The Google Cloud environments can be compared on the basis of adding memory, adding CPU, and adding an additional node.

Cluster Comparisons

Memory Comparisons

AWS Cloud Deployment Results

For each environment, we chart operations per second against response time (within 90% of the operations). The Google threshold of 150 ms is shown.

AWS Cloud Low Memory

This setup includes a single node with 4 CPUs and 16 GB memory.

AWS Cloud High Memory

This setup includes a single node with 8 CPUs and 64 GB memory.

AWS Comparison

The effect of adding memory and CPUs cores can be compared on this cloud platform.

Azure Cloud Deployment Results

For each environment, we chart operations per second against response time (within 90% of the operations). The Google threshold of 150 ms is shown.

Azure Cloud Low Memory

This setup includes a single node with 4 CPUs and 16 GB memory.

Azure Cloud High Memory

This setup includes a single node with 8 CPUs and 64 GB memory.

Azure Cloud Comparison

The effect of adding memory and CPUs cores can be compared on this cloud platform.

On-Premises Deployment Results

For each environment, we chart operations per second against response time (within 90% of the operations). The Google threshold of 150 ms is shown.

Physical Appliance

This setup includes a single on-premises physical appliance, model CipherTrust Manager k470. See hardware specifications for memory and CPU values.

Virtual CipherTrust Manager on Private ESXi Server

Single Virtual CipherTrust Manager k170v deployed in ESXi private cloud, with 4 CPUs, 16 GB RAM, and 50 GB HDD.

Conclusion

Adding a second load balanced node scales performance approximately linearly. A larger performance increase was observed from adding CPU and RAM in each cloud environment.