AWS 클라우드 기반의 HPC 클러스터는 어떤 서비스들로 구성될까?

온프레미스 환경에서 HPC 클러스터를 구성하기 위해서는 서버, 스토리지, 네트워크와 같은 여러 하드웨어 장비들 및 소프트웨어들이 필요합니다. 마찬가지로 AWS 클라우드 환경에서 HPC 클러스터를 구성하기 위해서는 여러가지 AWS 서비스들을 조합해서 사용합니다. 이번 블로그에서는 ‘HPC on AWS’를 구성하는 개별 AWS 서비스들에 대해 소개하도록 하겠습니다.

‘HPC on AWS’를 구성하는AWS 서비스

‘HPC on AWS’는 단일 서비스가 아니라, 그림1과 같이 다양한 AWS 서비스들을 조합해서 구성해야 합니다. 즉 AWS 콘솔에서 몇 번의 클릭만으로 HPC 클러스터를 구성할 수는 없고, 여러 서비스들을 필요에 따라 조합해서 구성해야 합니다. 클러스터를 구성하는 모든 요소들은 코드 형태로 정의되기 때문에, 손쉽게 생성, 변경, 삭제가 가능합니다. ‘HPC on AWS’는 그림1과 같이 크게 3개의 스택으로 구성됩니다. 맨 하단의 레이어는 HPC 클러스터를 구성하는데 필수적인 인프라 서비스들로 구성이 됩니다. 중간 레이어는 이러한 클러스터를 관리하는 서비스들로 구성됩니다. 맨 상단에 있는 레이어는 엔지니어링 시뮬레이션에서 필수적이라 할 수 있는 시각화 작업을 구성하는 레이어로 구성됩니다. 필요에 따라서는 여기에 없는 AWS 서비스들도 연동하여 사용하는 것도 물론 가능합니다. 또한 클러스터를 구성하기 위해 그림1에 있는 서비스들을 반드시 모두 사용할 필요도 없습니다.

그림 1. ‘HPC on AWS’ 스택

지금부터는 이러한 레이어에 속하는 개별 서비스들에 대해 좀 더 자세히 설명하도록 하겠습니다.

AWS의 가상 서버, EC2 인스턴스

우선 그림1의 하단 맨 왼쪽에 있는 컴퓨트(compute) 서비스부터 소개하도록 하겠습니다. AWS에서 제공하는 일종의 가상 서버인 EC2 인스턴스는 AWS의 핵심 서비스로, 2006년 업계 최초로 클라우드 서비스를 선보인 이후 여러 진화를 거듭해 왔습니다. 그림2에서 확인할 수 있는 것처럼, EC2 인스턴스는 CPU 클럭 스피드, 메모리 및 디스크 용량, 네트워크의 속도면에서 비약적인 성능 향상을 거듭해 왔습니다. 현재 사용하고 계시는 서버 및 워크스테이션과 비교해 보신다면, AWS에서 제공하는 서버 하드웨어의 스펙이 얼마나 고사양인지를 쉽게 확인할 수 있습니다.

그림 2. AWS가 제공하는 서버의 최신 사양 스펙

현재 AWS에서는 약 750개 이상의 EC2 인스턴스를 제공하고 있으며, 코어가 상대적으로 많은 EC2 인스턴스, 코어당 메모리가 16GB 이상으로 메모리 용량에 특화된 EC2 인스턴스 등 다양한 타입의 EC2 인스턴스가 존재합니다. 2022년부터는 HPC에 특화된 전용 인스턴스(Hpc7g, Hpc7a, Hpc6id, Hpc6a)도 출시하고 있습니다. 또한 이러한 EC2인스턴스들은 x86 기반의 1)인텔, 2) AMD 기반이거나, 3) 그래비톤(Graviton)이라고 불리우는 AWS에서 ARM 기반으로 자체 개발한 EC2 인스턴스 형태로 제공됩니다. GPU가 탑재된 인공 지능을 위한 EC2 인스턴스도 물론 제공되므로, 분산 트레이닝을 위해 AWS 클라우드를 충분히 고려할 수 있습니다. 따라서 AWS에서는 워크로드에 최적화 될 수 있는 다양한 EC2 인스턴스 옵션을 사용할 수 있습니다.

 코드 형태로 사용하고자 하는 EC2 인스턴스를 선택하며, HPC 클러스터 운영 중에 신규 EC2 인스턴스가 런치(lauch)되거나 다른 EC2 인스턴스를 사용하고자 할 경우에도 손쉽게 변경이 가능하기 때문에, 항상 워크로드에 최적화된 HPC 클러스터를 구성할 수 있습니다.

AWS의 노드간 고속 인터커넥트 기술, EFA

노드간 빈번한 통신이 필수적인 ‘tightly coupled’ 아키텍처 기반의 HPC 클러스터를 구성하기 위해서는, 노드간 고속 연결을 보장하는 인터커넥트(interconnect) 기술이 필수적입니다. 온프레미스 환경에서는 보통 이러한 고속 연결을 위해, 기가비트 이더넷(Gigabit ethernet)이나 인피니밴드(Infiniband) 사용이 일반적입니다. 그러나 AWS에서는 이러한 기존의 인터커넥트 기술이 AWS 클라우드 데이터센터에서는 최적화 될 수 없다는 결론을 내리고, SRD(Scalable Reliable Datagram)라고 불리우는 인터커넥트 프로토콜을 자체 개발하여 이를 EFA(Elastic Fabric Adaptor) 인터페이스에 탑재하였습니다. EFA는 NIC(Network Interface Card) 카드와 유사한 개념을 가지는 EC2 인스턴스를 위한 일종의 고속 네트워크 전용 어댑터입니다. 사용하려는 EC2 인스턴스의 EFA 지원 여부는, 다음의 Amazon Elastic Compute Cloud 웹 페이지의 지원되는 인스턴스 유형에서 확인하시기 바랍니다.

EFA를 탑재한 EC2 인스턴스를 사용하여 클러스터를 구성할 경우, 그림3의 오른쪽과 같이 MPI(Message Passing Interface) 또는 NCCL(NVIDIA Collective Communication Library)이 OS를 우회하여 EFA 디바이스와 직접 연결되기 때문에 높은 네트워크 대역폭을 보장합니다. 따라서 CFD(Computational Fluid Dynamics)와 같은 ‘tightly coupled’ 아키텍처를 요구하는 엔지니어링 시뮬레이션이나 분산 트레이닝 환경을 구축하기 위해 HPC 클러스터 구축을 고려 중 이라면, EFA가 탑재된 EC2 인스턴스의 선택은 필수입니다. 현재 AWS에서는 2024년 6월 현재, 약 120개의 EC2 인스턴스에서 EFA를 지원하고 있습니다. EFA와 관련된 보다 자세한 내용이 궁금하시다면 ‘‘AWS 고성능 컴퓨팅 네트워크, 1부: AWS가 제공하는 고속 네트워크 인터페이스, EFA(Elastic Fabric Adaptor)’ 또는 ‘A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC’ 를 참고하시기 바랍니다.

그림 3. 전통적인 HPC SW스택과 EFA가 탑재된 AWS HPC SW 스택간 비교

만약 노드간 고속 통신이 필요 없는 EDA(Electronic Design Automation)나 몬테카를로 시뮬레이션과 같은 ‘loosely coupled’ 아키텍처 구성이 요구된다면, EFA 사용은 요구되지 않습니다. 이런 경우는 상황에 따라 일반적인 EC2 인스턴스의 네트워크 인터페이스인 ENI(Elastic Network Interface)나 ENA(Elastic Network Adaptor)의 사용도 무방합니다. 내가 사용하려는 EC2 인스턴스에 어떤 네트워크 인터페이스가 사용되는지 확인하려면, ‘Amazon Elastic Compute Cloud’ 에서 ‘네트워크 인터페이스 세부 정보 보기’ 항목을 참고하시기 바랍니다.

AWS가 제공하는 스토리지 기술

스토리지는 HPC 클러스터를 구성하는 매우 중요한 인프라 자원입니다. 때에 따라 스토리지의 I/O가 전체 클러스터 성능에 매우 큰 영향을 끼칠 수 있습니다. HPC 클러스터의 규모 및 용도에 따라 일반적으로 다음과 같은 AWS의 다양한 스토리지 서비스를 추천합니다. 물론 상황에 따라 여기서 소개하는 스토리지 서비스 이외의 다른 스토리지 서비스 사용도 가능합니다.

• Amazon EFS: AWS에서 제공하는 리눅스 기반의 완전 관리형 공유 스토리지 서비스 입니다. 온프레미스 환경의 NAS 스토리지를 의미하며, 클러스터의 규모가 크지 않고, 고속의 병렬처리가 요구되지 않는 경우 사용을 권장합니다.
• Amazon FSx for NetApp ONTAP: 온프레미스 환경에서 사용되는 NetApp ONTAP을 AWS 환경에서 구현한 완전 관리형 공유 스토리지 입니다. Amazon FSx for NetApp ONTAP은 스루풋(throughput) 보다는 작은 파일의 IO에 최적화되어 있어, 일반적으로 반도체 EDA 인더스트리에서 많이 사용합니다.
• Amazon FSx for Lustre: AWS가 제공하는 완전 관리형의 러스터(Lustre) 파일 시스템입니다. 러스터는 Top100의 슈퍼컴퓨터의 약 80%에서 사용될 정도로, 전 세계에서 가장 많이 사용되는 병렬 파일시스템 중 하나입니다. 러스터 파일시스템은 오픈 소스라는 장점이 존재하나 구축 및 유지보수가 매우 어려운 파일 시스템 중에 하나입니다. 이러한 파일시스템을 AWS 환경에서 완전 관리형 서비스로 사용할 수 있기 때문에, 병렬 파일 시스템에 대한 전문성이 부족하더라도, 손쉽게 고성능의 병렬 파일시스템에 대한 접근이 용이합니다.

그림 4. Amazon FSx for Lustre의 주요 특징

이 중에서 반드시 주목해야 하는 스토리지는 FSx for Lustre 입니다. 특히 ‘tightly coupled’ 아키텍처에서 클러스터를 구성하는 다수의 노드가 고속으로 데이터를 공유 스토리지에 읽고/쓰기 위해서는 병렬 파일시스템의 사용은 필수 입니다. FSx for Lustre는 그림4와 같이 크게 4가지 특징을 가지고 있습니다.

• 압도적인 성능을 제공하며 기본적으로 스토리지 용량에 비례하도록 설계되어 있습니다.
• 수십만개 이상의 코어에서 동시에 파일 시스템에 접속할 수 있을 정도의 높은 병렬성을 제공합니다.
• HDD 또는 SSD로 구성이 가능하기 때문에, 비용 효율적으로 병렬 파일시스템을 구축할 수 있습니다.
• 마지막으로, 스크래치(scratch) 및 퍼시스턴트(persistent)라는 두가지 디플로이먼트(deployment) 옵션을 제공합니다. 병렬 파일시스템에 대한 높은 가용성이 요구되며 데이터를 러스터 파일 시스템에 장기간 보관을 원한다면 퍼시스턴트 모드를 선택하고, 그렇지 않으면 스크래치 모드 옵션을 선택함으로써 역시 비용 효율적으로 스토리지 시스템을 구축할 수 있습니다.

일반적으로 엔지니어링 시뮬레이션 이후에는 대용량 파일이 생성되는 경우가 빈번합니다. 이러한 대용량 데이터를 AWS의 오브젝트 스토리지인 아마존 S3(Simple Storage Service)와 연동함으로써 데이터 저장에 대한 비용 절감을 유도할 수 있습니다. 아마존 S3는 FSx for Lustre와 연동되어 사용될 수 있습니다. 경우에 따라서는 아마존S3에 저장된 데이터를 AWS의 데이터 분석 또는 머신러닝 서비스와 연동하여 시뮬레이션 결과 데이터로부터 인사이트를 얻을 수도 있습니다.

코드 기반으로 클러스터 구성을 가능하게 하는 AWS 패러랠클러스터(ParallelCluster)

지금까지 ‘HPC on AWS’ 를 구성하는 3개의 스택 중, 맨 하단에 있는 인프라 서비스들에 대해 설명 하였습니다. 레고 블록을 이용해서 자동차를 조립한다고 가정해 보면, 여러가지 레고 블록 중에서 자동차를 만들기 위해 필요한 블록들만 선택해서 자동차를 구현합니다. 마찬가지로 AWS 에서도 그림5의 왼쪽과 같이 HPC 클러스터를 구성하기 위해 다양한 옵션들이 존재하는데, 이 중에서 특정 HPC 클러스터를 구성하기 위해 필요한 요소들만 선택하여 그림6의 중간에서 볼 수 있는 것처럼 이러한 요소들을 코드 형태로 정의하게 됩니다. 예를 들어, CFD 해석을 위해 HPC 클러스터를 AWS 클라우드 환경에서 구축해 본다고 가정해 보겠습니다. 이 때 사용되는 서비스가 바로 AWS 패러랠클러스터(ParallCluster)입니다. 바로 이 서비스를 이용하여 YAML 파일 형태로 원하는 클러스터를 정의합니다.

그림 5. 아마존 패러랠클러스터를 이용한 HPC 클러스터의 구현 방법

그림5 중간의 스크립트 내용 중, 붉은색으로 표시된 중요한 내용에 대해서 간단하게 살펴보겠습니다. 우선 클러스터를 구성하는 노드는 코어 수에 특화된 c5n.18xlarge 인스턴스가 선택되었고, 클러스터 헤드 노드로는 보다 저렴한 인스턴스인 c4.4xlarge가 선택되었습니다. c5n.18xlarge 인스턴스는 기본적으로 EFA를 지원합니다. 따라서 클러스터를 구성하는 노드간 고속 통신을 위해, 앞서 설명한 EFA를 사용하겠다고 정의하였습니다. 스토리지 역시 코드 형태로 정의되어 있는데, 39.6TB의 FSx for Lustre를 사용하겠다고 정의하였으며, 이 스토리지를 아마존 S3의 sangman 이라고 하는 버킷(bucket)과 연동하겠다고 선언하였습니다. 마지막으로 클라우드에서 엔지니어링 시뮬레이션의 시각화 작업을 수행하기 위하여 NICE DCV를 사용하겠다고 선언하였습니다.

이렇게 코드 형태로 정의되어 있는 HPC 클러스터를 AWS 패러랠클러스터 명령어를 이용하며 실행시키면, 실제 인프라의 생성은 AWS의 IaaS(Infra as a Service)서비스인 AWS 클라우드포메이션(CloudFormation)이 담당하게 됩니다. 그림5의 오른쪽이, 입력된 코드 정보를 이용하여 CFD 시뮬레이션을 위해 실제 생성된 HPC 클러스터를 보여주고 있습니다. 따라서 기본적으로 AWS 클라우드 환경에서 HPC 클러스터를 구성하고자 한다면 AWS 패러랠클러스터의 사용은 필수입니다.

AWS의 웹 포털 서비스, NICE 엔진프레임(EnginFrame)

생성된 HPC 클러스터에 리눅스 명령어를 통해 접근하는 것도 가능하지만, 웹 포털을 통해 접근하는 것도 가능합니다. AWS에서 제공하는 NICE 엔진프레임(EnginFrame)이 바로 웹 포털 기능을 제공하는 서비스입니다. 사용자들은 그림6과 같이 사용자명과 패스워드를 이용하여 웹 포털에 접근하게 되며, 웹 포털을 통해 1) 시뮬레이션 잡(job)을 제출할 수 있고, 2) 제출된 잡이 정상적으로 동작하는지 모니터링도 가능하며, 3) 시뮬레이션 결과에 대한 시각화 작업 역시 수행할 수 있습니다. 관리자 입장에서도 웹 포털을 통해 전체 HPC 클러스터 사용자에 대한 관리 뿐만 아니라, 클러스터를 구성하고 있는 리소스에 대한 모니터링까지 가능하게 됩니다.

그림 6. NICE 엔진프레임을 이용한 엔지니어링 시뮬레이션 수행 방법

그림7은 NICE 엔진프레임을 중심으로 한 AWS 기반의 CAE/CAD 워크로드에 대한 아키텍처 개념도 입니다. 하단의 그림과 같이, 엔지니어링 시뮬레이션 뿐만 아니라 CAD 작업이 필요한 사용자는 원격에서도 NICE 엔진프레임을 통해 AWS 클라우드 기반의 클러스터에 접근이 가능하게 됩니다. 웹 포털 뒤의 백엔드(backend)에는 HPC 클러스터 뿐만 아니라 상황에 따라 CAD 환경까지 연동이 가능하게 됩니다. 또한 이러한 인프라 환경은 코드 기반으로 구성되므로 상황에 따라 변경 및 삭제가 유연합니다. NICE 엔진프레임과 관련되어 더 자세한 정보가 궁금하시다면, ‘NICE EnginFrame을 활용한 AWS 클라우드 기반의 CAE/CAD 통합 R&D 시스템 구현’ 기술 블로그를 확인하시기 바랍니다.

그림 7. NICE 엔진프레임을 중심으로 한 AWS의 ‘CAE/CAD on AWS’ 개념도

컨테이너 기반의 AWS 스케쥴러, AWS 배치(Batch)

소개해드린 AWS 패러랠클러스터는 온프레미스 환경의 전통적 방식의 HPC 클러스터를 Lift & Shift 방식으로 AWS 클라우드 환경으로 마이그레이션 할 경우 매우 유용하게 사용할 수 있는 도구입니다. 일반적으로 HPC 클러스터를 구성할 때 기본적으로 고려하는 방식이기도 합니다. 그러나 때에 따라서는 이러한 방식 보다는 개발자 친화적인 HPC 환경이 필요한 경우도 있습니다. 만약, 사용자가 컨테이너 환경에 익숙하고 사용하는 애플리케이션이 컨테이너화 되어 있다면, AWS 배치(Batch)의 사용이 권장됩니다. AWS 배치는 컨테이너 기반의 완전 관리형 잡 스케쥴러입니다. 대표적으로 금융권의 몬테카를로 시뮬레이션이나 헬스케어 인더스터리에서 많이 사용되는 그리드 컴퓨팅(Grid computing)과 같이 노드간 고속 통신이 필요 없는 경우가 대표적으로 AWS 배치가 적용될 수 있는 분야입니다. 어느 경우에 아마존 패러릴클러스터를 사용할지 아니면 AWS 배치를 사용하는 것이 적절한지 판단이 어렵다면 다음의 블로그가 해결책을 제시할 수 있습니다.

AWS에서 제공하는 원격 스트리밍 프로토콜, NICE DCV

마지막으로, 앞서 소개한 ‘HPC on AWS’ 스택의 최상단에 위치하는 서비스가 바로 NICE DCV 입니다. 이름 때문에 AWS의 서비스가 아닌 걸로 오해하는 분들이 계시는데, AWS에서 제공하는 원격 스트리밍 프로토콜 서비스입니다. AWS에서 2016년에 이탈리아의 HPC 및 비쥬얼라이제이션(visualization) 전문 회사인 NICE를 인수함으로써, 앞서 언급한 NICE 엔진프레임과 함께 AWS의 공식 서비스가 되었습니다.

앞서 설명한 것처럼, AWS 패러랠클러스터에 한 줄 정도 NICE DCV 사용에 대한 내용을 추가하면 헤드 노드에 NICE DCV가 설치되며, 이를 이용하여 그림8 처럼 컴퓨팅 작업 전의 시각화 작업이나, 계산 결과에 대한 시각화 작업을 클라우드에서 수행할 수 있습니다. 그리하여 그 수행된 결과에 대한 그래픽 화면, 즉 픽셀 데이터만을 TLS 프로토콜로 암호화 하여, PC 또는 워크스테이션을 이용하여 사용자가 화면을 원격에서 전달 받을 수 있습니다. 또한 변화하는 픽셀만 전송하므로 네트워크 대역폭도 절약할 수 있습니다.

기존 온프레미스 환경에서는 시각화 작업을 수행하기 위해 파일을 빈번하게 HPC 클러스터에 업로드 또는 다운로드 작업이 필요하였으나, NICE DCV를 사용하여 클라우드에서 시각화 작업을 수행하게 되면 모든 그래픽 처리가 클라우드에서 수행되므로 빈번한 파일 이동이 필요 없다는 점에서 사용자 편의성도 몰라보게 개선됩니다.

그림 8. NICE DCV를 이용한 엔지니어링 시뮬레이션에서의 시각화 작업

맺음말

이 블로그에서는 AWS 클라우드의 네이티브 HPC 솔루션인 ‘HPC on AWS’를 구성하는 구성 요소들에 대해 알아보았습니다. ‘HPC on AWS’는 단일 서비스가 아니며, 3개의 레이어로 구성된 다양한 AWS 서비스들의 집합체라는 사실을 꼭 기억할 필요가 있습니다. 또한 이러한 여러 서비스들을 AWS 패러랠클러스터를 이용하여 코드 형태로 정의하여 사용자가 원하는 형태로 클러스터를 커스터마이징 할 수 있다는 점이, 온프레미스 환경의 HPC 뿐만 아니라 다른 HPC SaaS 솔루션과 차별되는 가장 큰 차이점이라 할 수 있습니다.