We are a team from Orange, and we develop a platform called VaaS (for Voice as a Service). Our platform provides web APIs to easily create voice services like voice notification or interactive voice response application.
We joined the digital sustainable challenge with the idea of deploying digital sobriety in our day-to-day agile project, by setting up a continuous improvement loop on the energy footprint of our product.
Continuous improvement means continuous measurement…so we started by considering the question of the measure, and discovered that measuring the energy consumption of software was anything but obvious ! We have thus concentrated our efforts on the creation of a test bench to measure the energy consumption of our platform, that could be easily integrated in our CI/CD process.
Tools
First of all, we checked existing energy measurement tools. As hosting infrastructures currently offer little or no such tool support, we choose to use the PowerAPI toolkit, a software defined power meter, created by researchers at INRIA.
PowerAPI is a “software-defined power meter” that can estimate the power consumption of software in real-time, by extrapolating hardware performance counters exposed by the processor. PowerAPI offers the capability of measuring the power consumption of software running on a single machine, on a cluster of machines, or inside docker containers.
Then, we deployed PowerAPI on our test platform. As our product was already “docker ready”, we used the docker capabilities of PowerAPI to collect energy consumption data for all the containers of our infrastructure. We focused on measuring the consumption of a typical use case : sending a voice notification. We used our existing endurance tests that send message notifications at a given rate during a given time period. We run such tests at different rates while collecting the energy consumption during each test run.
In order to validate the approach, we compared the measures of the overall platform consumption delivered by PowerAPI with the measures delivered by a physical power meter. The comparison showed congruent results, thus making us confident on the pertinence of using the software defined power- meter for our test bench.
Measures and analysis
We used the measures produced by the test bench to analyze how the consumption evolves as the load increases and how it is distributes among the different containers.
Figure 1 shows the energy consumption of the different components measured with PowerAPI during a test run that issues an api call for a voice notification at a rate of 6 calls per second.
The analysis of this measures allowed us to identify the most consuming components : the two telephony servers whose consumption is depicted in green. On the other hand, the servers exposing the rest API, whose consumption is depicted in yellow, have a much lower consumption. Thus, the efforts for improving the energy efficiency should on the telephony component.
We also considered how energy consumption of a single call evolves as platform load increases. As the green curve in figure 2 shows, when the platform handles more calls the consumption of each call in joules [1] decreases up to a point when the platforms gets overloaded. At this point the failure rate (shown by red curve) starts to raise, causing the consumption by succeeding to raise as well.
We conclude that the optimum platform load from the consumption point of view is just before errors start to appear (the lowest point in the green curve). This suggests another direction for energy efficiency improvement, which is to increase the number of calls the platform can handle (without increasing its resources ! )
Further steps
The test bench can now be integrated in to our agile process cycle for two purposes :
- verify that the consumption does not increase throughout the evolution of product.
- validate the effectiveness of the optimization efforts.
Thanks to the measurements, we now have an order of magnitude of the energy consumption of a use case in our platform. A further step is to complete this measure with the cost of the use case beyond the core platform, integrating the costs of data transfers between the API users and the platform as well as the cost of the telephone calls on the mobile / fix network. The end to en measure would allow to calculate an ‘energy tag’ for our API, and to determine whether there are other areas of energy efficiency improvement to address.
[1] One joule is defined by work required to produce one watt of power for one second. For example, it represents the amount of electricity required to light a 1 W LED for 1 s.
