# Concerto: Dynamic Processor Scaling for Distributed Data Systems with Replication
###### Abstract
Motivated by this observation, this paper presents a novel DVFS algorithm called Concerto, which scales down the processor speed for replicas while having the processors in the master run at full speed. Modern processors manufactured by Intel, AMD, and ARM are equipped with the DVFS feature that enables the control of the processor speed within a certain range while using less power [13; 14; 15]. When the data service nodes are deployed in distributed data systems, Concerto sets the processor affinity separately for the master and the replica and throttles down the processor frequency for replicas. Considering that the number of replicas is typically twice more than the number of masters, CPU scaling down for replicas can lead to significant savings in power consumption. Although Concerto appears to be straightforward conceptually, implementing it in practical systems and making an effective use of it are not without challenges. As a case study, we integrated Concerto into Redis, which is one of the most popular distributed in-memory NoSQL systems [6], though, when doing this, we face two major challenges. First, scaling down the processor speed of the replicas undesirably impairs the read performance associated with the replicas. Modern distributed data systems generally allow data reads from replicas to ensure proper load balancing, short latency, and high availability. As read requests are synchronous with users, it is unavoidable for the user-perceived latency to increase under Concerto. Second, the processing slowdown in replicas can increase the replication lag in distributed data systems. The replication lag refers to the time taken for the data changes of the master to be reflected in the replica. This synchronization delay \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Data System** & \begin{tabular}{c} **Number of** \\ **Master** \\ \end{tabular} & \
\begin{tabular}{c} **Number of** \\ **Replica** \\ \end{tabular} &
\begin{tabular}{c} **Operation to** \\ **Replica** \\ \end{tabular} & **Replication** \\ \hline Redis [6] & Single & Multiple & read & Async \\ MongoDB [7] & Single & Multiple & - & Async \\ HDFS [10] & Single & Multiple & read & Sync(1) Async(N-1) \\ Ceph [11] & Single & Multiple & - & Async \\ Cassandra [8] & Multiple & Multiple & read/write & Async \\ Dynamo [12] & Multiple & Multiple & read/write & Async \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Replication in distributed systems. aggravates the staleness of the replicas, leading to greater data losses in the failure of the master. We overcome these challenges as follows. To avoid unintended delays in the read latency, Concerto decouples the read and write path in Redis and processes them separately at the different cores, specifically processing reads at the high frequency and writes at the low frequency. Redis is natively designed with a single thread, making it challenging to realize the concurrent execution of reads and writes with it. We achieve this goal by identifying the part that takes a long time but has no dependency with writes in the read path and then offloading it to a different thread running at high speed. This compromise is disadvantageous in terms of energy savings, but it can prevent performance problems when using Concerto. Second, with regard to the replication lag, our in-depth analysis reveals that the scaling down of the processor in the replica has little impact on the replication lag. The master, responsible for several jobs to maintain data over the distributed environment, such as data propagation and/or replica synchronization, takes longer to process a write request than the replica. This performance gap allows room for the replica to operate at the lower speed without increasing the risk of a data loss in a failure. We implemented the Concerto architecture in Redis 6.0.1. Performance evaluation with micro- and real-world benchmarks show that Concerto reduces the energy consumption of data systems by 32% on average and up to 51%, with a performance penalty of 3% compared to when it is not used.