# HPC Cloud Architecture to Reduce HPC Workflow Complexity in Containerized Environments
## 5 Evaluation
### Rapid Elasticity and Scalability  
Rapid elasticity and scalability mean that capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly up and inward commensurate with demand [20]. One important factor affecting rapid elasticity on our platform is the rapid movement of image files. When a user makes a job request for a resource with the required image, the system must quickly move the image created in Image  
\begin{table}
\begin{tabular}{l l l l} \hline \hline  & **Software** & **Version** & **Installed Node (in Figure 14)** \\ \hline Image Metadata Storage & MariaDB & 5.5.52 & Image Metadata Server \\ Job Metadata Storage & MongoDB & 2.6.12 & Job Metadata Server \\ Container Platform & Docker & 17.06-ce & Docker Container Platform, Docker Private Registry, \\  & Singularity & 2.2 & Image Manager Server \\ Batch Scheduler & PBSPro & 14.1.0 & Job Submit Server, Docker Container Platform, \\  & & Singularity Container Platform \\ Docker Container Scheduler & Kubernetes & 1.7.4 & Job Submit Server, Docker Container Platform \\ Overlay Network Solution & Calico & 2.3 & Job Submit Server, Docker Container Platform \\ Distributed Task Queue & Celery & 4.1 & Image Submit Server, Image Manager Server, Job Submit Server \\ Programming Language & Python & 2.7.5 & Image Submit Server, Image Manager Server, Job Submit Server \\ Message Broker & Redis- & 3.2.3 & Image Manger Server \\ User Command Line Tool (developed in Python) & PLSICLOUD & 1.0 & Image Submit Server, Job Submit Server \\ \hline \hline \end{tabular}
\end{table}
Table 3: Installed software information.  
Temporary Storage to the compute nodes. For Singularity, there are no considerations when transferring an image, which can be also run as a container. The problem is to deploy the Docker image. Since Docker has a layered image structure and is managed by the Docker engine, it must be compressed into a file to move to the compute nodes. Considering the file compression time, file transfer time, and file decompression time, this is very inefficient. To solve this problem, we built Docker Private Registry that can store images connected with the management network. We calculated the degree of time deduction with and without Docker Private Registry for handling a 1.39 GB image. With Docker Private Registry, it took 122 s, 20 s faster than without Docker Private Registry.  
For reducing the workload of creating images, we developed an auto-scaling scheduler with three workers implemented in a group for our platform. We applied this custom algorithm to compare the waiting time of each task with and without cases. With one worker, the second task must wait for the previous task until it is completed. The third task must wait for 2059 s, which is almost twice the first waiting time. For the fourth task in a queue, it will wait for 3083 s, requiring 6166 s in total as a waiting time. With this auto-scaling algorithm, three workers will work in parallel, so only 1080 s are needed for the fourth task; thus the total waiting time required is only 1200 s.