[논문]Comparative Analysis of Container for High Performance Computing

Lee, Jaeryun; Chae, Yunchang; Tak, Byungchul

doi:10.9708/jksci.2020.25.09.011

[국내논문] Comparative Analysis of Container for High Performance Computing 원문보기

韓國컴퓨터情報學會論文誌 = Journal of the Korea Society of Computer and Information, v.25 no.9, 2020년, pp.11 - 20

Lee, Jaeryun (School of Computer Science and Engineering, Kyungpook National University) , Chae, Yunchang (School of Computer Science and Engineering, Kyungpook National University) , Tak, Byungchul (School of Computer Science and Engineering, Kyungpook National University)

초록
AI-Helper

이 논문에서는 HPC 환경에서 컨테이너의 사용 가능성을 탐구하고 적절한 PMI 라이브러리를 선택하는 기준을 실험을 통해 제안한다. HPC 환경에서 컨테이너 기술의 필요성이 대두되고 있지만 Docker 컨테이너 경우 잠재적인 보안 문제가 있어 HPC 환경에 적합하지 않다는 문제가 있다. 이러한 문제를 해결하기 위해 여러 HPC 컨테이너들이 등장하였지만, 서로 다른 특징들 따른 성능 차이가 발생할 수 있다. 그리하여 본 논문에서는 각 HPC 컨테이너 및 Docker 컨테이너 사이의 성능 차이를 NAS Parallel Benchmark 실험을 통해 측정하고 PMI 라이브러리의 종류에 따른 성능 변화를 확인해보았다. 그 결과 HPC 컨테이너와 Docker 컨테이너는 거의 네이티브와 유사한 성능을 보이거나 경우에 따라 오히려 나은 성능이 관측되었다. 또한 PMI 라이브러리 간의 비교에서는 PMIx가 PMI-2에 비해 모든 조건에서 뛰어난 것은 아닌 것으로 관측된 것을 확인할 수 있었다.

Abstract ▼ AI-Helper

In this paper, we propose the possibility of using containers in the HPC ecosystem and the criteria for selecting a proper PMI library. Although demand for container has been growing rapidly in the HPC ecosystem, Docker container which is the most widely used has a potential security problem and is not suitable for the HPC. Therefore, several HPC containers have appeared to solve this problem and the chance of performance differences also emerged. For this reason, we measured the performance difference between each HPC container and Docker container through NAS Parallel Benchmark experiment and checked the effect of the type of PMI library. As a result, the HPC container and the Docker container showed almost the same performance as native, or in some cases, rather better performance was observed. In the result of comparison between PMI libraries showed that PMIx was not superior to PMI-2 in all conditions.

Keyword

표/그림 (13)

그림 Fig. 1. Diagram of MPI applications workflow in container
그림 Fig. 2. Diagram of the experiment system and its Slurm service association
그림 Fig. 3. Comparison chart of NPB execution times on different container within type of benchmark
표 Table 1. Table of container NPB execution Time
그림 Fig. 4. Comparison chart of container load times on different container within type of benchmark
그림 Fig. 5. Comparison chart of memory usages on different container within type of benchmark
표 Table 2. Table of container load times
표 Table 3. Table of memory usages
그림 Fig. 6. Comparison chart of NPB execution times on different PMI library
그림 Fig. 7. Comparison chart of Slurm Job + Container INIT within type of container
표 Table 4. Comparison chart of Benchmark Excution times two different PMI libraries within type of benchmark and container
표 Table 5. Comparison table of with Slurm Job + Container INIT times on different PMI libraries
그림 Fig. 8. Comparison chart of average memory usages on different PMI library

AI 본문요약
AI-Helper

* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.

문제 정의

[14]는 Docker 컨테이너가 HPC 환경에 완벽하게 적용되기에는 MPI 지원. 로컬 디스크에 대한 의존성, 호스트 리소스에 대한 접근, 사용자 인증 등 추가적인 문제들이 남아있는 것으로 판단하고 이러한 문제를 해결하기 위한 디자인된 Docker API 플러그인 세트를 소개하였다.
하지만 해당 논문에서Docker 컨테이너의 경우 별도의 오버레이 네트워크를 구성하여 실험이 진행되었기 때문에 타 컨테이너 환경 대비 낮은 성능을 보였다. 따라서 본 논문의 연구에서는 오버레이 네트워크의 사용으로 발생하는 오버헤드를 감소시키기 위하여 Docker 컨테이너에서 호스트의 네트워크를 직접 사용하도록 옵션을 적용하여 비교 대상 HPC 컨테이너들과 유사한 네트워크 환경으로 설정하여 실험을 진행하였다.

제안 방법

그러므로 특히 변화에 민감한 HPC 환경에서 사용되는 기술들은 보안성뿐만 아니라 성능 측면에서도 여러 조사를 통해 기술에 대한 심도 있는 이해가 필요하다. 따라서 본 연구에서는 NPB(NAS Parallel Benchmark)에서 지원하는 MPI(Message Passing Interface) 벤치마크를 사용하여 HPC 컨테이너(Singularity, Charliecloud, Shifter)와 Docker 컨테이너 그리고 네이티브(Native)에서의 수행시간, 메모리 등을 측정하여 분석하였다. 추가로 Slurm workload manager와 같은 RM(Resource Manager)에서 MPI 어플리케이션을 수행하는 프로세스들을 관리하기 위한 통신 인터페이스로 사용되는 PMI(Process Management Interface) 라이브러리 종류에 따라 성능 차이가 발생할 수 있다고 판단하여 PMI-2[5]와 PMIx[6] 두 종류의 라이브러리를 모두 측정하여 이를 성능 측정 변수로 지정하였다.
따라서 본 연구에서는 NPB(NAS Parallel Benchmark)에서 지원하는 MPI(Message Passing Interface) 벤치마크를 사용하여 HPC 컨테이너(Singularity, Charliecloud, Shifter)와 Docker 컨테이너 그리고 네이티브(Native)에서의 수행시간, 메모리 등을 측정하여 분석하였다. 추가로 Slurm workload manager와 같은 RM(Resource Manager)에서 MPI 어플리케이션을 수행하는 프로세스들을 관리하기 위한 통신 인터페이스로 사용되는 PMI(Process Management Interface) 라이브러리 종류에 따라 성능 차이가 발생할 수 있다고 판단하여 PMI-2[5]와 PMIx[6] 두 종류의 라이브러리를 모두 측정하여 이를 성능 측정 변수로 지정하였다.
Shifter는 HPC 환경의 사용자에게 큰 규모의 작업을 효율적이면서도 안전하게 컨테이너 기술을 사용할 수 있도록 하는 것을 목적으로 하여 NERSC(National Energy Research Scientific Computing Center)에서 개발한 오픈소스 컨테이너 런타임이다. HPC 컨테이너의 목적으로 개발된 만큼 보안성 및 기존 HPC 환경의 RM과 호환성, MPI 지원을 고려하여 설계되었다.
그들은 컨테이너 도입의 기준에 대해 컨테이너에서 수행되는 벤치마크의 수행시간을 주 평가요소로 삼고 네트워크 성능을 평가하기 위한 IMB(Intel MPI Benchmark) 벤치마크와 HPC 시스템에서 MPI 어플리케이션이 수행되는 성능을 파악하기 위한 HPCG 벤치마크를 컨테이너 안에서 실행하여 그 결과를 분석했다. 하지만 특정 라이브러리 함수의 성능을 측정하는 HPCG와 같은 벤치마크보다 더 다각화된 특징을 지닌 어플리케이션을 대상으로 하는 실험이 이루어질 필요가 있다고 판단하여, 본 실험에서는 NPB를 사용하였으며, MPI 라이브러리의 비교 뿐 아니라 MPI 어플리케이션에서 준필수적 요소인 PMI 라이브러리의 종류별 성능 차이에 대한 연구도 필요할 것으로 판단되어 PMI-2와 PMIx를 사용하여 실험을 수행하고 결과를 비교해보았다.
[16]는 기존 선행연구들에서는 HPC 환경에서 실제 상업용으로 배포되고 있는 코드를 컨테이너 내에서 실행한 성능 비교 연구가 부족하다고 판단하여, 생물학 분야에서 사용되고 있는 시뮬레이션 시스템을 Docker, Singularity, Shifter의 컨테이너 환경에서 수행하여 성능 비교를 진행하였다. 해당 연구에서는 Singularity가 가장 최선의 솔루션으로 선택되었고, 이에 따라 Singularity의 확장성(scalability)에 대해 보다 추가적으로 분석이 진행되었다. 하지만 해당 논문에서Docker 컨테이너의 경우 별도의 오버레이 네트워크를 구성하여 실험이 진행되었기 때문에 타 컨테이너 환경 대비 낮은 성능을 보였다.
[17]은 Singularity, Charliecloud, Shifter 세 가지의 HPC 컨테이너 간의 성능 비교 실험을 진행하였다. 평가는 단일노드에 로드된 컨테이너에서 CPU 성능, 메모리 성능, 어플리케이션 성능, 컨테이너화로 인한 메모리 추가 사용량을 측정하고 HPC 컨테이너 기술별 차이점에 대해서 분석한 결과를 도출하였다. 해당 연구에서는 HPC 컨테이너 기술들 간에 성능 비교를 수행하였지만 가장 보편적으로 사용되고 있는 Docker 컨테이너와의 성능 비교는 이루어지지 않았다.
실험을 위해 9개의 PC에 1대의 컨트롤러 노드와 8대의 컴퓨트 노드로 역할을 할당하여 실험을 진행하였으며 컨트롤러 노드는 컴퓨트 노드에게 작업 시작 명령 전달 및 결과 기록 작업만 하고 모든 벤치마크 수행은 컴퓨트 노드에서만 진행된다. 각 PC는 CPU로 intel i7-4770 3.
02 버전의 OpenMPI를 사용하였다. 그리고 MPI 작업을 하는 프로세스를 관리하기 위한 PMI 라이브러리를 사용하였는데, PMI 라이브러리의 종류별 성능 비교를 위해 Slurm 패키지에 포함되어 있는 Slurm PMI-2와 3.1 버전의 PMIx를 사용하였다. 마지막으로 3.
1 버전의 PMIx를 사용하였다. 마지막으로 3.4 버전의 NAS parallel benchmark에 포함된 NPB-MPI 벤치마크 어플리케이션을 사용하여 성능 측정에 사용하였다.
반면 Docker의 경우 Slurm 워크로드 매니저로부터 공식적인 지원을 받지 못하여 호스트에서 구축된 Slurm 클러스터가 Docker 컨테이너에 직접적으로 실행 명령을 내리지 못한다. 이를 해결하기 위해 호스트의 Slurm 프로세스를 사용하는 대신 Docker 컨테이너에 slurmctld와 slurmd를 설치하여 하나의 클러스터로 만들어 사용하였다. 그 결과 다른 컨테이너에서 벤치마크가 실행되는 방법과 동일하게 컨트롤러 노드에 위치한 Docker 컨테이너 내부의 slurmctld을 통해 컴퓨트 노드의 Docker 컨테이너 내부에 있는 slurmd로 벤치마크를 실행 명령을 내려 Docker 컨테이너 내부에서 벤치마크를 실행할 수 있게 되었다.
그 결과 다른 컨테이너에서 벤치마크가 실행되는 방법과 동일하게 컨트롤러 노드에 위치한 Docker 컨테이너 내부의 slurmctld을 통해 컴퓨트 노드의 Docker 컨테이너 내부에 있는 slurmd로 벤치마크를 실행 명령을 내려 Docker 컨테이너 내부에서 벤치마크를 실행할 수 있게 되었다. 또한 Docker의 경우 타 컨테이너들과 마찬가지로 네트워크 오버헤드를 줄이기 위해 별도의 Overlay 네트워크 구성을 하지 않고 Host 네트워크를 사용하도록 설정하여 실험을 진행하였다,
성능 측정을 위한 NPB 벤치마크는 모든 MPI 벤치마크 종류별로 B 클래스, C 클래스, D 클래스의 워크로드를 갖도록 설정하고 각 컨테이너에서 직접 컴파일하였다. srun 명령어를 통해 Slurm 클러스터에 MPI 벤치마크 작업을 분배할 때 벤치마크를 병렬적으로 수행하는 프로세스들은 srun의 ntask 옵션의 값만큼 생성이 되며, 모든 컴퓨트 노드에 1개씩 순차적으로 할당하도록 설정하였다.
성능 측정을 위한 NPB 벤치마크는 모든 MPI 벤치마크 종류별로 B 클래스, C 클래스, D 클래스의 워크로드를 갖도록 설정하고 각 컨테이너에서 직접 컴파일하였다. srun 명령어를 통해 Slurm 클러스터에 MPI 벤치마크 작업을 분배할 때 벤치마크를 병렬적으로 수행하는 프로세스들은 srun의 ntask 옵션의 값만큼 생성이 되며, 모든 컴퓨트 노드에 1개씩 순차적으로 할당하도록 설정하였다.
NPB 실험의 리소스 사용량은 Slurm 작업에서 사용된 리소스를 수집한 데이터를 SlurmDB 서비스로 mysql에 저장한 뒤 sacct 명령어를 통해 출력하여 사용했다. 실험결과를 저장한 파일에는 수행한 실험 대상과 조건을 포함하여 벤치마크를 수행하는데 걸린 시간, CPU 사용량, 메모리 사용량, 네트워크 사용량, 디스크 사용량, 전력 사용량을 기록하였다. 본 논문에서는 주로 벤치마크의 수행 시간 그리고 메모리 사용량과 관련된 메모리를 관찰하여 특징을 분석했지만, 추후 다른 메트릭도 분석할 계획이다.
1 Benchmark Execution Time”의 실험에서 벤치마크에서 발생하는 수행시간의 비중을 보다 줄이기 위해 워크로드를 A로 변경하고 나머지 조건은 동일한 실험을 진행하였다. 또한 MPI 초기화 작업 등의 컨테이너 초기화 시간과 관련이 없는 요소들을 제외하기 위하여 각 경우의 각 컨테이너의 수행시간에서 네이티브 수행시간 값을 제외한 뒤 평가하였다.
본 연구에서는 여러 HPC 컨테이너와 Docker 컨테이너 사이의 성능 차이와 PMI 라이브러리 간의 성능차이를 수행 시간과 컨테이너 초기화 시간 그리고 메모리 사용량을 기준으로 하여 비교실험을 진행하였다. 그 결과 HPC 컨테이너와 Docker 컨테이너의 환경에서 어플리케이션을 수행한 경우 모두 네이티브 환경과 유사한 수행결과를 보이거나 경우에 따라 오히려 네이티브보다 다소 빠른 수행시간 결과를 보였다.
첫째, 적은 프로세스 수가 사용된 환경에서는 PMI-2가 PMIx에 비해 좋은 성능을 보인다. 둘째, 적은 프로세스 수가 사용된 환경에서는 PMIx가 PMI-2에 비해 많은 메모리를 사용하였다. 따라서 모든 경우에서 PMI-2의 개선 버전인 PMIx를 사용하는 것은 권장되지 않고 사용되는 환경을 고려하여 PMI 라이브러리를 선별하여 채택할 것이 권장된다.

대상 데이터

본 실험은 리눅스 커널 3.10.0-1062.18.1을 사용하는 CentOS 7.7.1908 운영체제를 사용하는 9대의 PC를 19.05 버전의 Slurm 워크로드 매니저를 사용하여 하나의 클러스터로 만들어 진행되었다. 사용된 컨테이너는 4종으로 각각 19.
05 버전의 Slurm 워크로드 매니저를 사용하여 하나의 클러스터로 만들어 진행되었다. 사용된 컨테이너는 4종으로 각각 19.03.12 버전의 Docker, 3.5.2 버전의 Singularity, 0.14 버전의 Charliecloud, 18.03.0-1 버전의 Shifter로써 각 컨테이너 기술의 최신 버전을 사용하였다. MPI 어플리케이션을 컴파일하고 실행하는데 사용한 MPI 라이브러리는 4.
NPB 실험의 리소스 사용량은 Slurm 작업에서 사용된 리소스를 수집한 데이터를 SlurmDB 서비스로 mysql에 저장한 뒤 sacct 명령어를 통해 출력하여 사용했다. 실험결과를 저장한 파일에는 수행한 실험 대상과 조건을 포함하여 벤치마크를 수행하는데 걸린 시간, CPU 사용량, 메모리 사용량, 네트워크 사용량, 디스크 사용량, 전력 사용량을 기록하였다.

이론/모형

0-1 버전의 Shifter로써 각 컨테이너 기술의 최신 버전을 사용하였다. MPI 어플리케이션을 컴파일하고 실행하는데 사용한 MPI 라이브러리는 4.02 버전의 OpenMPI를 사용하였다. 그리고 MPI 작업을 하는 프로세스를 관리하기 위한 PMI 라이브러리를 사용하였는데, PMI 라이브러리의 종류별 성능 비교를 위해 Slurm 패키지에 포함되어 있는 Slurm PMI-2와 3.

성능/효과

컨테이너화 혹은 운영체제 수준의 가상화는 하나의 호스트 머신에서 리소스의 격리하여 호스트 시스템 구성설정과의 충돌 없이 어플리케이션에 특화된 새로운 시스템 환경을 구축할 수 있다는 장점으로 기술의 활용이 널리 확산되어 현재는 컴퓨팅 산업에서 빠질 수 없는 위치를 차지하고 있다. 그 중 컨테이너는 다른 호스트 OS에서 새로운 게스트 OS를 설치하여 새로운 시스템을 구축하는 방법인 가상머신과 다르게 리눅스 네임스페이스를 사용한 격리를 통해 호스트와 다른 독자적인 시스템 구성 설정을 만들어 사용하고 cgroup을 통해 호스트의 리소스를 분리하여 활용할 수 있는 특징으로 가상화로 인해 발생할 수 있는 비용을 줄였다. 또한 컨테이너를 사용하는 개발자는 운영체제, 시스템 라이브러리, 환경변수, 사용자 정의 라이브러리 및 어플리케이션을 컴파일하는 방법을 직접 정의하여 하나의 이미지로 만들어 사용한다.
실험결과 다음과 같은 현상들이 발견되었다. 첫째, HPC 컨테이너는 네이티브와 유사하거나 수행하는 어플리케이션에 따라 오히려 더 빠른 성능을 보이기도 한다. 둘째, 호스트 네트워크 사용 조건의 Docker 컨테이너와 HPC 컨테이너들은 대부분의 벤치마크에 대해 비슷한 성능을 보였다.
첫째, HPC 컨테이너는 네이티브와 유사하거나 수행하는 어플리케이션에 따라 오히려 더 빠른 성능을 보이기도 한다. 둘째, 호스트 네트워크 사용 조건의 Docker 컨테이너와 HPC 컨테이너들은 대부분의 벤치마크에 대해 비슷한 성능을 보였다. 셋째, PMIx와 PMI-2의 성능 비교 시 보다 적은 프로세스 수의 조건에서는 PMI-2의 성능이 높으며, 많은 프로세스 수의 조건에서는 PMIx의 성능이 높은 것으로 나타났다.
둘째, 호스트 네트워크 사용 조건의 Docker 컨테이너와 HPC 컨테이너들은 대부분의 벤치마크에 대해 비슷한 성능을 보였다. 셋째, PMIx와 PMI-2의 성능 비교 시 보다 적은 프로세스 수의 조건에서는 PMI-2의 성능이 높으며, 많은 프로세스 수의 조건에서는 PMIx의 성능이 높은 것으로 나타났다. 넷째, 적은 프로세스 수의 조건에서 PMIx의 메모리사용량이 PMI-2 보다 오히려 더 높은 수치가 나타났다.
셋째, PMIx와 PMI-2의 성능 비교 시 보다 적은 프로세스 수의 조건에서는 PMI-2의 성능이 높으며, 많은 프로세스 수의 조건에서는 PMIx의 성능이 높은 것으로 나타났다. 넷째, 적은 프로세스 수의 조건에서 PMIx의 메모리사용량이 PMI-2 보다 오히려 더 높은 수치가 나타났다.
대부분의 이슈들은 보안 패치를 통해 해결된 상태지만 루트 권한의 필요성은 잠재적인 위험성이 존재하기 때문에 높은 보안성이 요구되는 HPC 환경에 적합하지 않다. 둘째로 Docker가 기존 HPC 환경에 통합이 쉽지 않다는 것이다. HPC 환경은 대부분RM을 사용하여 클러스터의 리소스를 사용할 job에 할당하는 batch 시스템을 사용한다.
[13]은 Slurm과 같은 HPC 큐잉 시스템(≒RM)에서 Docker 컨테이너의 동작을 안전하게 실행할 수 있도록 개발된 secure wrapper인 Socker를 소개하였다. Socker는 HPC 환경에서 일반적으로 사용되는 Slurm과 같은 HPC 큐잉 시스템으로 Docker 컨테이너를 사용할 수 있도록 사용 사례를 통합 하였으며, 작업을 수행하는 컨테이너에서 내부의 루트 계정으로 작업을 하는 대신 작업을 제출한 유저의 계정으로 실행할 수 있도록 수정되었다, 그리고 HPC 큐잉 시스템에 의한Docker 컨테이너의 리소스 사용제한등 여러 기능들을 지원하여 Docker 컨테이너가 HPC 환경에 적합하게 동작할 수 있도록 하였다. 하지만 2018년 Jonathan Sparks et al.
이를 해결하기 위해 호스트의 Slurm 프로세스를 사용하는 대신 Docker 컨테이너에 slurmctld와 slurmd를 설치하여 하나의 클러스터로 만들어 사용하였다. 그 결과 다른 컨테이너에서 벤치마크가 실행되는 방법과 동일하게 컨트롤러 노드에 위치한 Docker 컨테이너 내부의 slurmctld을 통해 컴퓨트 노드의 Docker 컨테이너 내부에 있는 slurmd로 벤치마크를 실행 명령을 내려 Docker 컨테이너 내부에서 벤치마크를 실행할 수 있게 되었다. 또한 Docker의 경우 타 컨테이너들과 마찬가지로 네트워크 오버헤드를 줄이기 위해 별도의 Overlay 네트워크 구성을 하지 않고 Host 네트워크를 사용하도록 설정하여 실험을 진행하였다,
실험결과를 통해 알 수 있는 사실들은 다음과 같다. 첫째, 컨테이너에서의 어플리케이션 수행은 EP의 경우 네이티브 보다 최대 17.4% 빠른 수행시간이 나타났다. 각 컨테이너 별 성능적 특징에 비롯한 결과로 해석될 수 있는데, 특히 Shifter의 경우 컨테이너 공유 라이브러리를 모두 컨테이너 내부에 번들링하여 기존 대비 파일 엑세스에 대한 오버헤드를 줄이는 공유 라이브러리 번들링 특징때문에 네이티브보다 빠른 수행시간이 나타난 것으로 판단된다.
4% 빠른 수행시간이 나타났다. 각 컨테이너 별 성능적 특징에 비롯한 결과로 해석될 수 있는데, 특히 Shifter의 경우 컨테이너 공유 라이브러리를 모두 컨테이너 내부에 번들링하여 기존 대비 파일 엑세스에 대한 오버헤드를 줄이는 공유 라이브러리 번들링 특징때문에 네이티브보다 빠른 수행시간이 나타난 것으로 판단된다. 둘째, Docker 컨테이너는 대부분의 경우에서 HPC 컨테이너들이나 네이티브와 유사한 성능을 보였다.
각 컨테이너 별 성능적 특징에 비롯한 결과로 해석될 수 있는데, 특히 Shifter의 경우 컨테이너 공유 라이브러리를 모두 컨테이너 내부에 번들링하여 기존 대비 파일 엑세스에 대한 오버헤드를 줄이는 공유 라이브러리 번들링 특징때문에 네이티브보다 빠른 수행시간이 나타난 것으로 판단된다. 둘째, Docker 컨테이너는 대부분의 경우에서 HPC 컨테이너들이나 네이티브와 유사한 성능을 보였다. 실험결과에서 Docker 컨테이너는 매우 적은 수행시간으로 기록된 EP를 제외한 나머지 대부분의 경우에서 타 컨테이너들과 2.
둘째, Docker 컨테이너는 대부분의 경우에서 HPC 컨테이너들이나 네이티브와 유사한 성능을 보였다. 실험결과에서 Docker 컨테이너는 매우 적은 수행시간으로 기록된 EP를 제외한 나머지 대부분의 경우에서 타 컨테이너들과 2.58% 정도의 성능 차이를 보여 전체적으로 비슷한 성능이 기록되었다. 본 실험에서 사용된 Docker 컨테이너는 호스트 네트워크를 사용하도록 환경을 구성한 결과이며, Overlay 네트워크를 사용하는 등 네트워크 오버헤드가 있는 조건에서는 성능 차이가 발생할 수 있다.
58% 정도의 성능 차이를 보여 전체적으로 비슷한 성능이 기록되었다. 본 실험에서 사용된 Docker 컨테이너는 호스트 네트워크를 사용하도록 환경을 구성한 결과이며, Overlay 네트워크를 사용하는 등 네트워크 오버헤드가 있는 조건에서는 성능 차이가 발생할 수 있다.
Table. 2를 통해 Charliecloud의 경우 모든 벤치마크에 대해 컨테이너 로드타임이 대체로 0.01초 전후의 시간이 소요된 것을 확인할 수 있으며 다른 컨테이너들과 비교하여 가장 짧은 컨테이너 로드 타임을 보였다. 컨테이너 로드 타임이 가장 길었던 컨테이너인 Shifter는 최소값을 보인 Charliecloud와 비교하여 최대 49.
1 Benchmark Execution Time”과 동일한 조건에서의 실험 결과 중 각 컨테이너별 메모리 사용량을 나타낸다. 해당 결과는 각 컨테이너의 구현이나 아키텍처에 따라 메모리 사용량 차이가 나타났고 그 차이는 Singularity, Shifter, Docker, Charliecloud 순으로 많은 메모리를 사용하는 것으로 나타났다. Singularity는 MG 연산에서 최소 메모리 사용량을 보인 Charliecloud에 비해 50.
해당 결과는 각 컨테이너의 구현이나 아키텍처에 따라 메모리 사용량 차이가 나타났고 그 차이는 Singularity, Shifter, Docker, Charliecloud 순으로 많은 메모리를 사용하는 것으로 나타났다. Singularity는 MG 연산에서 최소 메모리 사용량을 보인 Charliecloud에 비해 50.4%를 많은 메모리를 사용하였으며, EP의 경우 반대로 모든 컨테이너의 메모리 사용량의 차이가 최대 2.3% 이내로 매우 유사한 수치가 관측되었다.
6은 프로세스 수에 따른 PMI-2와 PMIx 간의 MPI 어플리케이션 수행시간 비교를 나타내는 그림이다. 실험결과 보다 적은 프로세스 수의 환경(16개 프로세스)에서는 PMIx의 수행시간이 PMI-2의 수행시간에 비해 10.0% 느린 것으로 나타났으나 사용된 프로세스 수가 커짐(64 프로세스)에 따라 기존 결과와 달리 PMI-2의 수행시간이 PMIx에 비해 2% 느린 결과가 나타났다. 본 실험결과를 통해 사용된 프로세스 수가 적을 때는 PMIx보다 PMI-2가 더 나은 성능을 보이며 사용된 프로세스 수가 늘어남에 따라 PMIx가 더 높은 성능을 보인 것을 알 수 있다.
0% 느린 것으로 나타났으나 사용된 프로세스 수가 커짐(64 프로세스)에 따라 기존 결과와 달리 PMI-2의 수행시간이 PMIx에 비해 2% 느린 결과가 나타났다. 본 실험결과를 통해 사용된 프로세스 수가 적을 때는 PMIx보다 PMI-2가 더 나은 성능을 보이며 사용된 프로세스 수가 늘어남에 따라 PMIx가 더 높은 성능을 보인 것을 알 수 있다.
1 절의 어플리케이션 수행결과와 비슷한 양상의 결과가 나타났다. 더 적은 프로세스 수의 환경(16 프로세스)에서는 PMI-2의 수행시간이 PMIx에 비해 최대 5.1% 빠른 결과가 나타났으며, 사용된 프로세스 수가 커짐(64 프로세스)에 따라 전체적으로 PMIx가 PMI-2에 비해 더 적은 수행시간을 보이며 그 차이는 최대 11.5% 차이를 보였다. 따라서 어플리케이션 수행시간을 제외한 총 수행시간 결과에서도 PMIx는 사용된 프로세스의 수가 적으면 PMI-2와 성능 차이를 크게 보이지 않지만, 더 많은 수의 프로세스 수가 사용되면 PMIx에 비해 좋은 성능이 나타날 것으로 예측된다.
5% 차이를 보였다. 따라서 어플리케이션 수행시간을 제외한 총 수행시간 결과에서도 PMIx는 사용된 프로세스의 수가 적으면 PMI-2와 성능 차이를 크게 보이지 않지만, 더 많은 수의 프로세스 수가 사용되면 PMIx에 비해 좋은 성능이 나타날 것으로 예측된다.
1절의 실험과 동일한 실험의 결과로 메모리 사용량을 비교할 수 있다. 그 결과 기존 선행 연구들이 수백 개 이상의 프로세스를 사용한 결과와 달리 대부분의 경우에서 모두 PMIx의 메모리 사용량이 PMI-2의 사용량에 비해 최대 13.1% 많은 소모량을 보였다. 이는 PMIx의 기본적인 아키텍처에 따른 초기 메모리 사용량이 높기 때문에 발생한 현상이다.
본 연구에서는 여러 HPC 컨테이너와 Docker 컨테이너 사이의 성능 차이와 PMI 라이브러리 간의 성능차이를 수행 시간과 컨테이너 초기화 시간 그리고 메모리 사용량을 기준으로 하여 비교실험을 진행하였다. 그 결과 HPC 컨테이너와 Docker 컨테이너의 환경에서 어플리케이션을 수행한 경우 모두 네이티브 환경과 유사한 수행결과를 보이거나 경우에 따라 오히려 네이티브보다 다소 빠른 수행시간 결과를 보였다. 따라서 컨테이너 기술이 제공하는 이식성, 배포 용이성, 편의성 등 다양한 장점들과 함께 성능적인 측면이나 HPC와의 호환성까지 충족시키는 다양한 HPC 컨테이너를 채택하여 기존 HPC 환경에도 컨테이너 기술을 도입하는 것이 좋을 것으로 판단된다.
그 결과 HPC 컨테이너와 Docker 컨테이너의 환경에서 어플리케이션을 수행한 경우 모두 네이티브 환경과 유사한 수행결과를 보이거나 경우에 따라 오히려 네이티브보다 다소 빠른 수행시간 결과를 보였다. 따라서 컨테이너 기술이 제공하는 이식성, 배포 용이성, 편의성 등 다양한 장점들과 함께 성능적인 측면이나 HPC와의 호환성까지 충족시키는 다양한 HPC 컨테이너를 채택하여 기존 HPC 환경에도 컨테이너 기술을 도입하는 것이 좋을 것으로 판단된다.
함께 진행한 PMI 라이브러리 성능 비교실험 결과로 다음과 같은 사항들을 발견하였다. 첫째, 적은 프로세스 수가 사용된 환경에서는 PMI-2가 PMIx에 비해 좋은 성능을 보인다. 둘째, 적은 프로세스 수가 사용된 환경에서는 PMIx가 PMI-2에 비해 많은 메모리를 사용하였다.

후속연구

실험결과를 저장한 파일에는 수행한 실험 대상과 조건을 포함하여 벤치마크를 수행하는데 걸린 시간, CPU 사용량, 메모리 사용량, 네트워크 사용량, 디스크 사용량, 전력 사용량을 기록하였다. 본 논문에서는 주로 벤치마크의 수행 시간 그리고 메모리 사용량과 관련된 메모리를 관찰하여 특징을 분석했지만, 추후 다른 메트릭도 분석할 계획이다.
향후 연구 방향으로는 본 논문에서 사용된 NPB 외 I/O Intensive 특징을 보이는 벤치마크 등 다양한 벤치마크 어플리케이션을 사용하여 보다 다각화된 결과를 얻을 예정이며, PMI의 성능 차이를 파악하기 위해 더 많은 노드 및 쓰레드 수의 환경에서 작업할 예정이다.

질의응답

핵심어	질문	논문에서 추출한 답변
	컨테이너화 혹은 운영체제 수준의 가상화의 장점은 무엇인가?	컨테이너화 혹은 운영체제 수준의 가상화는 하나의 호스트 머신에서 리소스의 격리하여 호스트 시스템 구성설정과의 충돌 없이 어플리케이션에 특화된 새로운 시스템 환경을 구축할 수 있다는 장점으로 기술의 활용이 널리 확산되어 현재는 컴퓨팅 산업에서 빠질 수 없는 위치를 차지하고 있다. 그 중 컨테이너는 다른 호스트 OS에서 새로운 게스트 OS를 설치하여 새로운 시스템을 구축하는 방법인 가상머신과 다르게 리눅스 네임스페이스를 사용한 격리를 통해 호스트와 다른 독자적인 시스템 구성 설정을 만들어 사용하고 cgroup을 통해 호스트의 리소스를 분리하여 활용할 수 있는 특징으로 가상화로 인해 발생할 수 있는 비용을 줄였다.
	Docker란 무엇인가?	Docker는 상용 컨테이너 중 가장 흔히 사용되는 컨테이너 솔루션이다. 자체 개발한 LXC를 사용하며, 네임스페이스 및 cgroup 격리를 제공하는 자체 libcontainer 패키지도 사용하고 있다.
	HPC 환경에서 컨테이너 도입 시 가장 많이 거론되는 방법론은 무엇인가?	상용 컨테이너의 활용이 증가함에 따라 HPC 환경에서 컨테이너 도입의 필요성이 증가하면서 최근 상용 컨테이너의 문제점들을 해결하여 HPC 환경에서 사용할 수 있는 컨테이너 솔루션들이 등장했다. HPC 컨테이너들 중 가장 많이 거론되는 Singularity[2], Charliecloud[3], Shifter[4]는 서로 다른 방법론으로 Docker와 같은 기존 컨테이너 기술들의 보안 문제를 해결하는 것에 중점을 두고 개발되었으며 각 컨테이너 솔루션들의 제공자들은 향상된 보안에 대해 여러 문서를 통해 증명해왔다.

참고문헌 (17)

D.M. Jacobsen and R.S. Canon. "Contain this, unleashing docker for hpc," Proceedings of the Cray User Group, pp. 33-49, Apr. 2015.
G.M. Kurtzer, V. Sochat and M.W. Bauer. "Singularity: Scientific containers for mobility of compute," PloS one, Vol. 12, No. 5, e0177459, May. 2017. DOI: 10.1371/journal.pone.0177459

상세보기
R. Priedhorsky and T. Randles, "Charliecloud: unprivileged containers for user-defined software stacks in HPC," Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC 2017, pp. 1-10, Nov. 2017. DOI: 10.1145/3126908.3126925
L. Gerhardt, W. Bhimji, S. Cannon, M. Fasel, D. Jacobsen, M. Mustafa, J. Porter and V. Tsulaia, "Shifter: Containers for HPC," Journal of Physics: Conference Series, Vol. 898, No. 8, pp. 082021, Nov. 2017. DOI: 10.1088/1742-6596/898/8/082021

상세보기
P. Balaji, D. Buntians, D. Goodell, W. Gropp, J. Krishna, E. Lusk and R. Thakur, "PMI: A scalable parallel process-management interface for extreme-scale systems," European MPI Users' Group Meeting, pp. 31-41, Nov. 2010. DOI: 10.1007/978-3-642-15646-5_4
R.H. Castain, J. Hursey, A. Bouteille and D. Solt , "PMIx: process management for exascale environments," Parallel Computing, Vol. 79, pp. 9-29, Nov. 2018. DOI: 10.1016/j.parco.2018.08.002

상세보기
S. Chakraborty, H. Subramoni, J. Perkins and D.K. Panda, "SHMEMPMI -- Shared Memory Based PMI for Improved Performance and Scalability," 2016 16th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid), pp.60-69, May. 2016 DOI: 10.1109/CCGrid.2016.99
D.H. Bailey, E. Barszcz, J.T. Barton, D.S. Browning, R.L. Carter, L. Dagum, R.A. Fatoohi, P.O. Frederickson, T.A. Lasinski, R.S. Schreiber, H.D. Simon, V. Venkatakrishnan and S.K. Weeratunga, "The nas parallel benchmarks," International Journal of High Performance Computing Applications, VOL. 5, No. 3, pp. 63-73, Sep. 1991.
S. Soltesz, H. Potzl, M.E. Fiuczynski A., Bavier, and L. Peterson, "Container-based operating system virtualization: A scalable, high-performance alternative to hypervisors," ACM SIGOPS Operating Systems Review, p.p. 275-287, Mar. 2007. DOI: 10.1145/1272996.1273025
M.G. Xavier, M.V. Neves, F.D. Rossi, T.C. Ferreto, T. Lange and C.A.F De Rose, "Performance Evaluation of Container-Based Virtualization for High Performance Computing Environments," 2013 21st Euromicro International Conference on Parallel, Distributed, and Network-Based Processing, p.p. 233-240, February 2013. DOI: 10.1109/PDP.2013.41
W. Felter, A. Ferreira, R. Rajamony and J. Rubio, "An updated performance comparison of virtual machines and linux containers," 2015 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), p.p. 171-172, March 2015. DOI:10.1109/ISPASS.2015.7095802
M. de Bayser, and R. Cerqueira, "Integrating MPI with Docker for HPC", 2017 IEEE International Conference on Cloud Engineering (IC2E), p.p. 259-265, April 2017. DOI:10.1109/IC2E.2017.40
A. Azab, "Enabling Docker Containers for High-Performance and Many-Task Computing," 2017 IEEE International Conference on Cloud Engineering (IC2E), p.p. 279-285, April 2017. DOI:10.1109/IC2E.2017.52
J. Sparks, "Enabling Docker for HPC," Concurrency and computation, Vol. 31, No. 16, e5018, July 2018. DOI: 10.1002/cpe.5018
A.J. Younge, K. Pedretti, R.E. Grant and R. Brightwell, "A Tale of Two Systems Using Containers to Deploy HPC Applications on Supercomputers and Clouds," 2017 IEEE International Conference on Cloud Computing Technology and Science (CloudCom), p.p. 74-81, Dec. 2017. DOI: 10.1109/CloudCom.2017.40
O. Rudyy, M. Garcia-Gasulla, F. Mantovani, A. Santiago, R. Sirvent, and M. Vazquez, "Containers in hpc: A scalability and portability study in production biological simulations," 2019 IEEE International Parallel and Distributed Processing Symposium (IPDPS), p.p. 567-577, May 2019. DOI: 10.1109/IPDPS.2019.00066
A. Torrez, T. Randles and R. Priedhorsky, "HPC container runtimes have minimal or no performance impact," 2019 IEEE/ACM International Workshop on Containers and New Orchestration Paradigms for Isolated Environments in HPC (CANOPIE-HPC), pp.37-42, Nov. 2019 . DOI: 10.1109/CANOPIE-HPC49598.2019.00010

표제어: PCR

동의어: Packet Collision Rate

용어 설명 출처 목록 (6)

용어 설명: PCR은 세균 특이성이 있는 primer를 이용하여 적은 수의 세균이 있을지라도 쉽게 검출할 수 있는 유용한 방법이며, 이를 이용하여 구강 내 치면세균막이나 타액에서 직접 세균을 검출할 수 있게 되었다[8].

내보내기 구분	파일저장 인쇄 메일전송
구성항목	기본정보 상세정보 관리번호, 논문명, 저널/프로시딩명, 저자 , 발행년, 권, 호, 시작페이지, 끝페이지, 발행기관 관리번호, 논문명, 대등논문명, 저자 , 저널/프로시딩명, 발행기관, 발행년, 발행언어, 권, 호, 시작페이지, 끝페이지, ISBN, ISSN, 주제분야, 키워드, 초록(한글), 초록(영문), 저자(소속기관)
저장형식	Text(ASCII format) Excel format RefWorks Direct Export RIS format (for Reference Manager, ProCite, EndNote), Scholar's Aids, Mendeley
메일정보	받는사람 (필수) @ 보내는사람 (선택) @ 제목 내용 KISTI 검색결과 이메일 서비스
안내	총 건의 자료가 검색되었습니다. 다운받으실 자료의 인덱스를 입력하세요. (1-10,000) 검색결과의 순서대로 최대 10,000건 까지 다운로드가 가능합니다. 데이타가 많을 경우 속도가 느려질 수 있습니다.(최대 2~3분 소요) 다운로드 파일은 UTF-8 형태로 저장됩니다. 파일의 내용이 제대로 보이지 않을실 때는 웹브라우저 상단의 보기 -> 인코딩 -> 자동선택 여부를 확인하십시오. ~ Text(ASCII format) Excel format

연합인증