Assessing and modeling the GHG emissions of software applications and services, toward a "carbon free" by-design approach

The impact of the ICT sector on the environment is constantly increasing, driven in particular by application sectors such as generative artificial intelligence and cryptocurrencies, which are intrinsically very energy intensive. For this reason, there is a need to reduce ICT-related emissions. The emergence of the cloud paradigm has helped to reduce impacts as it has led to the growth of hyperscale data centers where the concentration of infrastructures has helped to achieve ever greater energy efficiencies. But for some time now, the development of IoT infrastructure and the pervasiveness of TLC (think of the spread of 5G telephone networks) has led to a proliferation of EDGE installations. These installations, being small in size, do not have the possibility of increasing efficiency using consolidation; therefore, to reduce energy consumption, they must also seriously consider the energy efficiency of the software. The hyperscale data centers base their success in reducing their energy footprint on efficiency due to their size and have a business model that doesn't allow the modification of applications, which are managed remotely by their clients. On the other hand, EDGE processing centers, built around the user's needs, can consider software efficiency in the same way as they are doing with infrastructure, and obtain significant reductions in emissions not because they are large, but because they are widespread. For these reasons, the reference environment for this research is cloud installations similar to those used in the EDGE paradigm, based on virtualization or orchestration. Considering this environment, this research has studied how to facilitate the non-functional requirement of software energy efficiency. In order to do this, it has studied how the software stimulates energy consumption. The aim is to indicate to those involved in coordinating software development in which direction to focus their efforts. And with the additional aim of providing indications to enable them to estimate the results obtained. All this means being able to have a simplified model of a server's electricity consumption in order to grasp and optimize the aspects of the software that mainly contribute to determining consumption, so as to allow those involved in coordinating development to have clear indications on how to direct it. At the same time, these aspects must allow for the disaggregation of consumption, given that in these environments many different applications share the use of the same server. With these clear indications in mind, we set about studying previous work to know the state of the art. In doing so, we started by examining the studies on consumption in large data centers, studies whose accuracy is stimulated by the size of the problem, by virtue of the fact that even small percentage improvements correspond to macroscopic effects. What emerged is that there are two very promising approaches: the first is the B+A model, the second is the additive model. With the B+A model, energy consumption is divided into two parts: base energy, which is needed just to keep the devices on, and active energy, which depends on the activities of the computer applications hosted by the server. The additive model examines consumption by dividing it among the various subsystems that make up a server. Using these models, it becomes clear that, in the EDGE environment, a major part of software optimization is linked to the reduction of active power. This is because the reduction of base power can only occur by increasing the number of applications sharing the same server, which is the basic principle of consolidation used in hyperscale data centers. Unfortunately, the paradigm on which EDGE data centers are based does not allow for the accumulation of a growing number of applications, so the only viable way to optimize the base power is to right-size the infrastructure itself. The state-of-the-art analysis continued by examining a significant series of works in which the energy consumption due to the use of IT applications was measured, observing how most of them use the RAPL (Running Average Power Limit) registers present on most CPUs for the measurements, and reporting the energy consumed by the CPU and RAM. Most of these studies operate in environments where the applications have full use of the computer and therefore do not operate disaggregation. As proof of how challenging the disaggregation of consumption can be, one study stands out above all that, in order to disaggregate, duplicates the physical infrastructure, disaggregating by the difference between the consumption measurements of the two different systems, only one of which hosts the application under measurement. The research part starts from what has been seen in the state of the art, that is, the use of the CPU as the most important driver for active power, with also a necessary verification of the use of RAM, Disk and network. In the first phase of the research, which took place in a virtualized environment, it was decided to use Virtual Machines to disaggregate consumption. In fact, by creating a virtual machine and housing all and only the software components of an application in it, it is possible to use the percentage of use of the virtual CPU of the virtual machine to consider only the effects of the application under examination. The tests conducted have allowed us to confirm that in the environment used (small server without advanced features such as frequency scaling, and with VMware ESXi virtualizer) the active power is proportional to the percentage of use of the virtual CPU seen, that is, by the virtual machine. The same tests also indicate a need for caution when there are multiple virtual machines active on the server at the same time because in these cases the measurement of the virtual CPU usage is overestimated. In these cases, we lose the possibility of making an indirect measurement of active power through the virtual CPU usage value. But since the proportionality between the virtual CPU usage values and the active power remains, we can state that the percentage of efficiency measured through the percentage of virtual CPU usage corresponds to the same percentage of active power reduction. The tests have allowed us to determine that I/O operations, both on the network and on disk, have no effect on active power but only on base power. With this, the optimization of an application can be reduced to the reduction of CPU usage, as far as power is concerned, while as far as I/O operation time is concerned, errors must be considered, especially in accessing data via databases, as they can extend execution times and therefore dramatically increase the basic energy used. In the continuation of the research, carried out in an orchestrated environment with Kubernetes, we found ourselves in a completely different situation, as there was no virtualization but, unlike the previous environment, there was access to the data of the RAPL registers and therefore of the - global - consumption of the CPU and RAM. The first tests confirmed the availability of the RAPL metrics and, through these, confirmed that the power relative to RAM is constant and can therefore be included in the base power. Combining this result with what was seen regarding I/O operations, further confirmation was obtained that the active power is linked to the use of the CPU. Before taking further measurements, we analyzed the problem of the dispersion of the measurement values, which had already emerged in the virtualized environment. Also based on what we have seen in the literature, we have verified that the dispersion of values can be described as the sum of two values: one stable, which characterizes the phenomenon studied (percentage of CPU use, electrical power) and one approximately stochastic, therefore with a null average value, which considers the discontinuity of the operations that take place inside a server. By simply taking several measurements and calculating the standard deviation, we were able to evaluate the magnitude of the problem. And by suitably varying a measurement parameter, integration time, we were able to increase its precision. Both these results are important because efficiency measurements always involve a measurement of the difference between values measured before and after an efficiency operation, and an estimate or, even better, an increase in precision are very important for validating and improving the measurement results. In the orchestrated environment, in order to measure the effects of an application, we tried to define a quantity other than the percentage of CPU usage or RAPL registers, so as to have values that depended only on the application under test and not on everything that operates on the server. In the first phase, this was found by using the speed of execution of the calculation cycles carried out by the program developed to perform the tests (a quantity called MCCS - Mega Computing Cycles per Second). With this indicator, the effects of frequency scaling or governors (programs that vary the clock frequency in a manner consistent with the operational needs of the server) were verified. What happened is that the speed of execution of the calculation cycles and the active power remain substantially proportional to each other both when the computational load varies and when the governor used varies, with some exceptions: the governors that ensure the greatest computing power exhibit a non-linearity that makes them less energy efficient at about “half performance”, just as there is a more efficient one that exhibits a specular behavior being, at half performance, more efficient. The important thing is that, in an orchestrated environment, the information relating to the set governor, as well as the clock frequency in use, are accessible, and therefore there is a way to take measurements. Operating in an orchestrated environment, measurements were taken inside a pod, a processing unit controlled by the orchestrator, to understand the effects on energy efficiency, operating two different series of measurements using all possible governors. Two different sets of results were obtained, each internally consistent, but with a marked difference between the two. This means that there are settings that can make a difference. These differences can be recognized and measured precisely because the measurements made in this research are replicable. By operating from within a pod it is possible to run the test program which, in turn, can access the necessary information. Also, from inside a pod, the effect on energy efficiency of CPU capping was evaluated, which allows a limit to be placed on CPU usage, verifying that there are none. This allows the active power caused by an application to be limited without side effects other than slowing down operations. The last activity carried out was to identify and verify a way to measure the operations carried out by an application. This was found in the use of the perf stat command. The tests carried out made it possible to verify that there is proportionality between the speed of execution of the calculation cycles and the number of GIPS (Giga Instructions Per Second) measured, which therefore becomes the usable measurement for the indirect measurement of active power. In this phase, by comparing the ratio between MCCS and GIPS inside and outside a pod, it was possible to evaluate the cost in terms of energy efficiency of operating from inside a pod. This can be replicated, although it requires administrative access to the server hosting the pod and allows measurements to be made on the energy efficiency of the orchestrated infrastructure. In conclusion, this research has defined how to disaggregate the energy consumption induced by the software by performing indirect measurements of the active power induced by an application, using two different strategies in virtualized and orchestrated EDGE environments. The simplicity of these measurements can help those involved in software development to evaluate and improve their energy impact. Further results include the definition of methods to evaluate the accuracy of the measurements and the efficiency of the orchestrator implementation.