ParallelCluster 잘 쓰고 있는데, 왜 AWS PCS인가(1부) — 관리형 Slurm의 가치와 비용 구조

HPC 클러스터를 AWS 환경에서 운영해 온 고객이라면, 거의 대부분 AWS ParallelCluster를 사용해 왔을 것입니다. 오픈소스이기 때문에 무료이며, 원하는 대로 변경할 수 있는 강력한 클러스터 운영 플랫폼입니다. 그런데 실제로 장기간 운영하다 보면 반복해서 부딪히는 지점이 있습니다. ParallelCluster 버전을 올리려면 클러스터를 다시 만들어야 하고, 헤드 노드가 죽으면 사용자가 직접 복구해야 하고, OS와 스케줄러 패치를 적용하려면 며칠씩 돌고 있는 시뮬레이션 작업을 멈춰야 합니다.

AWS Parallel Computing Service(PCS)는 이 지점을 겨냥한 관리형 서비스입니다. 2024년도에 처음 출시되었고, 2026년 7월에는 서울 리전에도 출시되었습니다. 핵심은 단순합니다 — ParallelCluster에서 사용하던 Slurm, OS, 애플리케이션은 그대로 두고 스케줄러 운영만 AWS가 맡습니다. 현재 AWS는 HPC 클러스터 운영 플랫폼으로 ParallelCluster보다 PCS에 무게를 두고 기능을 확장하고 있습니다.

이 글은 두 부류의 독자를 위한 것입니다. 하나는 AWS에서 HPC 클러스터를 새로 설계하며 어떤 플랫폼으로 시작할지 고민하는 분, 다른 하나는 이미 AWS ParallelCluster로 클러스터를 운영하며 개선 지점을 찾고 있는 분입니다.

결론부터 말씀드리면, 대부분의 신규 워크로드에는 AWS PCS(Parallel Computing Service)를 우선 검토하시길 권합니다. 관리형 Slurm 기반이라 클러스터의 제어 영역을 AWS가 운영해 주고, 그만큼 운영 부담이 줄기 때문입니다. 다만 “무조건 PCS”는 아닙니다. PCS는 EC2 요금 위에 컨트롤러 요금과 노드 관리 요금이 더해지므로, 비용에 민감하거나 특정 커스터마이징이 필요한 경우에는 ParallelCluster가 더 맞을 수 있습니다. 그 판단 기준은 본문에서 함께 짚겠습니다. 이미 ParallelCluster를 쓰고 계신다면, 기존 환경은 그대로 둔 채 PCS 클러스터를 나란히 두고 일부 워크로드로 소규모부터 검증한 뒤 점진적으로 전환하는 방식(이른바 blue/green)을 권합니다.

이 글(1부)은 그 근거를 (1) PCS란 무엇인가, (2) 왜 PCS인가, (3) 요금 구조 순서로 설명합니다. 워크로드별 적용, 여러 작업 큐를 하나의 클러스터로 통합하는 멀티 큐 구성, ParallelCluster에서 옮기는 실전 방법과 도입 사례는 2부에서 다룹니다.

시리즈 블로그 보기

• ParallelCluster 잘 쓰고 있는데, 왜 AWS PCS인가? (1부) — 관리형 Slurm의 가치와 비용 구조
• ParallelCluster 잘 쓰고 있는데, 왜 AWS PCS인가? (2부) — 워크로드별 적용과 전환 실전 가이드

1. AWS PCS란 무엇인가?

한마디로 “관리형 Slurm 클러스터”입니다. Slurm은 HPC 클러스터에서 작업(job)을 대기시키고 서버에 배분하는 대표적인 스케줄러로, 엔지니어링 시뮬레이션 분야에서 20년 넘게 사용되고 있습니다. AWS에서는 기본적으로 HPC 스케줄러로 Slurm을 제공합니다. PCS는 이 Slurm의 컨트롤러를 AWS가 운영해 줍니다.

<표1. AWS PCS의 개념>

단독주택은 모든 것을 내 뜻대로 통제할 수 있다는 것이 가장 큰 장점입니다. 그러나 그 대가로 눈이 오면 눈을 치워야 하고, 집이 노후화될수록 생기는 문제도 모두 직접 해결해야 합니다. 쉬어야 할 주말이 집 관리에 쓰이는 일이 반복되면, 수수료를 내고 관리 업체에 맡기고 나는 본업과 휴식에 집중하고 싶어집니다. PCS가 바로 이 후자에 해당합니다. 집(컴퓨트 노드, OS, 애플리케이션)은 그대로 내 것이고, 관리(스케줄러 운영, 패치, 업그레이드)만 AWS에 맡기는 구조입니다.

중요한 점은 “관리형”이라고 해서 AWS 방식에 종속되거나 내 환경을 자유롭게 바꿀 수 없게 되는 것은 아니라는 점입니다. 컴퓨트 노드는 여전히 내 계정의 EC2이므로, 기존에 사용하던 OS 이미지, 상용 애플리케이션(Ansys, STAR-CCM+ 등), 라이선스 서버, EC2 구매 구조(Savings Plans, Reserved Instances, 용량 예약)를 그대로 유지합니다.

AWS HPC 클러스터 관리 도구의 진화

AWS의 HPC 클러스터 관리 도구는 세 단계를 거쳐 발전했습니다. 시작은 2015년 CfnCluster로, AWS 최초의 오픈소스 HPC 클러스터 관리 솔루션이자 초기 클라우드 HPC의 기반이었습니다. 2018년에는 이를 발전시킨 AWS ParallelCluster가 등장해 오픈소스로 완전한 제어권을 제공했고, 지금도 세밀한 제어가 필요한 고객들이 사용하고 있습니다. 그리고 2024년, 이 두 세대의 경험을 기반으로 완전 관리형 서비스인 PCS가 출시되었습니다. 관리형 HPC를 원하는 고객을 위해 설계됐으며, 서울 리전에는 2026년 7월 출시됐습니다.

이 흐름이 의미하는 바는 명확합니다. PCS는 ParallelCluster의 후속 세대이며, AWS는 새로운 기능과 개선을 PCS에 우선 반영하고 있습니다. ParallelCluster는 완전한 제어가 필요한 고객을 위해 계속 제공되지만, 앞으로의 발전 속도는 PCS가 앞섭니다.

<그림1. AWS HPC 클러스터 관리 도구의 진화 — CfnCluster에서 PCS까지>

PCS 아키텍처 — 두뇌는 AWS, 실행은 내 계정

PCS 클러스터는 그림2와 같이 두 개의 VPC에 걸쳐 있습니다. 스케줄링을 담당하는 Slurm 컨트롤러와 큐, Slurm accounting 데이터베이스는 AWS가 관리하는 서비스 VPC에 있고, 실제 계산을 수행하는 컴퓨트 노드 그룹과 로그인 노드는 고객 VPC에 있습니다. 여기서 그림2에 함께 그려진 ‘Slurm 컨트롤러’와 ‘PCS 컨트롤러’는 경쟁하는 두 개의 스케줄러가 아니라 한 덩어리로 보면 됩니다. 안쪽의 Slurm 컨트롤러(slurmctld)는 잡을 큐에 세우고 빈 자원을 보고 컴퓨트 노드에 배치하는, 오픈소스 Slurm의 스케줄링 두뇌입니다. 바깥의 PCS 컨트롤러는 AWS가 그 slurmctld를 대신 운영하기 위해 감싼 관리 계층으로, 컨트롤러의 프로비저닝과 패치, 버전 업그레이드, 장애 복구를 맡고 클러스터 가용성에 99.9% SLA를 제공합니다. 이 서비스 VPC는 고객이 직접 접근할 수 없습니다. 사용자는 고객 VPC의 로그인 노드에 SSH로 접속해 평소처럼 sbatch(작업을 큐에 제출하는 Slurm 명령)로 작업을 제출하고, 그 명령은 ENI를 통해 관리형 Slurm 컨트롤러로 전달됩니다. 스토리지(FSx, EFS, S3 등), 라이선스 서버, 디렉터리 서비스 같은 외부 리소스는 고객 VPC에 그대로 두고 연결합니다. 온프레미스 환경에서 VPN이나 AWS Direct Connect로 연결해 기존 로그인 노드를 그대로 쓰는 구성도 가능합니다(컴퓨트 노드 그룹 밖의 외부 로그인 노드 기능으로, 지원되는 Slurm 버전 조건은 공식 문서를 확인하세요).

<그림2. PCS 아키텍처 — 관리형 서비스 VPC(컨트롤러와 큐)와 고객 VPC(컴퓨트 노드, 스토리지, 라이선스 서버)>

스케줄러는 무슨 일을 하나?

PCS는 관리형 Slurm 클러스터라고 했습니다. 스케줄러 개념이 낯선 분을 위해 Slurm 기준으로 간단히 정리합니다.

연구원들이 작성한 작업은 우선적으로 큐에서 대기하게 됩니다. 큐에 쌓인 작업을 실제 노드에 배정하는 역할은 누가 할까요? 바로 스케줄러입니다. 사용자는 작업이 어느 서버에서 실행되는지 신경 쓸 필요 없이 sbatch나 srun(대화형 실행) 같은 명령으로 작업을 제출하기만 하면 됩니다. 그러면 작업은 큐에 쌓이고, 스케줄러가 우선순위와 비어 있는 노드를 보고 알맞은 서버에 자동으로 배치한 뒤, 작업이 끝나면 자원을 회수해 다음 작업에 씁니다. 우선순위 정책이나 팀별 자원 배분(fair-share) 같은 세부 동작은 기존 Slurm과 동일합니다. PCS에서 달라지는 것은 클러스터의 관제탑에 해당하는 이 스케줄러를 AWS가 대신 운영한다는 점이며, 가동률에 대해 월 99.9%의 서비스 수준 계약(SLA)을 제공합니다.

<그림3. 스케줄러 개념: 작업 제출에서 실행까지>

PCS를 사용하는 세 가지 방법 — Console, API/SDK, CLI

PCS는 Console, API/SDK, CLI 등 여러 방식으로 사용할 수 있습니다. 고객은 자신의 기술 선호도, 기존 워크플로, 자동화 요구에 가장 잘 맞는 방식을 선택할 수 있어 효율성과 유연성이 높아집니다. 단, API/SDK와 CLI도 결국 관리형 서비스(AWS PCS) API를 호출하는 방식입니다. 인터페이스가 ParallelCluster와 비슷해 보여도, Slurm 컨트롤러 운영은 여전히 AWS가 맡습니다.

<그림4. 하나의 PCS, 세 가지 사용 방식 (Console, API/SDK, CLI)>

2. 왜 PCS인가?

PCS는 ParallelCluster 사용 고객의 피드백에서 출발했습니다. 오픈소스로 자유롭게 수정할 수 있는 장점은 분명하지만, 관리형 서비스가 필요하다는 고객들의 요구가 있었고 오픈소스 툴킷만으로는 구현하기 어려운 영역이 있었습니다. 대표적으로 다음 두 가지입니다.

• ParallelCluster는 실행 중인 클러스터의 버전을 in-place(제자리)로 올릴 수 없습니다. 새 버전에 추가된 기능을 쓰거나 최신 Slurm을 사용하려면(Slurm 버전이 ParallelCluster 버전에 고정 번들되어 있습니다), 헤드 노드를 포함해 새 버전으로 클러스터를 새로 만들고 워크로드를 옮긴 뒤 기존 클러스터를 삭제해야 합니다.
• 헤드 노드(스케줄러) 장애 복구를 고객이 직접 해야 합니다. 필드에서 고객으로부터 가장 자주 받는 질문 중 하나입니다.

<표2. PCS가 제공하는 두 가지 핵심 가치>

가장 실질적인 차이 — 작업이 멈추지 않는다

CFD/CAE 해석이나 대규모 모델 학습은 며칠에서 몇 주가 걸리기도 합니다. 그 사이 OS, 보안, 스케줄러 소프트웨어 업데이트가 불가피하게 발생하기도 합니다. 직접 운영하는 ParallelCluster 환경에서는 스케줄러(헤드 노드) 패치나 Slurm 버전 업그레이드를 위해 클러스터를 비우고 중단하거나 새로 만들어야 하며, 경우에 따라 몇 주간 실행 중이던 계산을 처음부터 다시 시작해야 하는 상황도 생깁니다. PCS는 이러한 업데이트를 두 갈래로 나눠 처리합니다.

• 스케줄러: 내 서버와 분리된 AWS 관리 영역에 있어 AWS가 처리합니다. 보안 패치와 마이너 업데이트는 자동 적용되며 실행 중이던 작업에 영향이 없습니다(패치 순간 신규 작업 제출만 잠깐 대기). 메이저 업그레이드도 클러스터 재생성 없이 in-place로 진행되며 실행 중인 작업은 계속됩니다.
• 컴퓨트 노드: 롤링 교체 방식입니다. 실행 중이던 작업은 기존 이미지에서 끝까지 완료하고, 새 작업만 새 이미지에서 시작합니다. OS 패치, MPI, 드라이버, 라이브러리(GPU 환경에서는 GPU 드라이버, CUDA, EFA) 갱신도 작업을 멈추지 않고 반영됩니다. 달리는 차를 세우지 않고, 부품을 교체하는 것에 가깝습니다.

실제 사례로, 2026년 2월 Munge 보안 취약점(CVE-2026-25506)이 공개됐을 때 PCS 환경에서는 컨트롤러가 AWS에 의해 자동 패치되었고, 노드는 고객이 AMI를 롤링으로 갱신해 실행 중이던 작업에 영향이 없었습니다. 또한 Shell은 사내 HPC 환경을 PCS로 이전해 클러스터 관리 노력을 75% 줄였다고 re:Invent 2025에서 공유했습니다. 스케줄러 운영이라는 반복 업무가 사라진 만큼, 엔지니어가 해석과 같은 연구 본업에 집중할 시간이 늘어난다는 의미입니다.

<표3. 운영 부담 비교 — 업그레이드, 패치, 실행 작업 연속성 관점>

참고로 용어부터 정리하겠습니다. Slurm은 HPC 작업을 관리하는 하나의 소프트웨어이지만, 실제로는 두 부분으로 나뉘어 돌아갑니다. 하나는 작업을 큐에 대기시키고 어느 서버에서 실행할지 정하는 ‘두뇌’ 역할의 컨트롤러(slurmctld)이고, 다른 하나는 각 계산 서버에서 그 지시를 받아 실제 작업을 실행하는 노드 쪽 프로그램(slurmd)입니다. 여기서 컴퓨트 노드란 실제 계산을 수행하는 서버를 말합니다. PCS에서는 컨트롤러(slurmctld)를 AWS가 대신 운영하고, 노드 쪽(slurmd)은 고객의 컴퓨트 노드에 설치되며 각 노드의 이미지(AMI)에 담깁니다. 즉 ‘컨트롤러 버전’과 ‘노드의 Slurm 버전’은 서로 다른 프로그램이 아니라, 같은 Slurm이 컨트롤러와 노드에 각각 설치된 것의 버전을 가리킵니다.

실행 중인 작업을 멈추지 않고 Slurm 버전을 올리는 롤링(무중단) 업그레이드에는 두 가지 조건이 있습니다. 첫째, 각 노드에 PCS 에이전트가 1.4.0 이상 설치돼 있어야 합니다. PCS 에이전트는 노드를 컨트롤러에 등록해 클러스터에 합류시키는 소프트웨어이며, 이 에이전트와 맞는 Slurm이 담긴 AMI는 고객이 빌드합니다. 둘째, 노드 쪽 Slurm(slurmd) 버전이 컨트롤러 쪽 Slurm(slurmctld) 버전과 너무 벌어지면 안 됩니다. 컨트롤러는 자기 버전과 바로 앞 두 개 버전까지의 노드만 받아주기 때문입니다. 예를 들어 컨트롤러가 25.11인데 노드가 23.11이면 너무 오래돼 클러스터에 붙지 못합니다. 그래서 컨트롤러를 새 버전으로 올릴 때는 노드 AMI의 Slurm도 호환되는 버전으로 함께 갱신해야 합니다. 참고로 SPANK 플러그인을 쓰는 클러스터라면 Slurm 26.05 이상으로 올릴 때 롤링이 지원됩니다. SPANK는 Slurm을 직접 수정하지 않고 작업 실행 과정에 원하는 기능을 끼워 넣는 확장 장치로, 컨테이너 실행용 pyxis가 대표적입니다.

3. 요금은 어떻게 구성되나?

PCS는 유료 서비스입니다. 무료인 ParallelCluster에서 마이그레이션할지 판단하려면 과금 구조부터 정리해야 합니다. 아래 그림5는 PCS 비용 구조를 한눈에 정리한 것입니다.

<그림5. PCS 비용 구조, 서울 리전 기준>

첫째는 EC2 컴퓨트 비용입니다. 이는 고객 계정의 EC2 요금이며 기존 Savings Plans, Reserved Instances, 용량 예약, 할인이 그대로 적용됩니다. 보통 총액에서 가장 큰 부분입니다. 이 비용은 PCS 관리비와 별개이며, 스토리지(FSx, S3 등)와 데이터 전송 요금도 별도로 청구됩니다. 클러스터 구축에 사용되는 비용이기에 AWS ParallelCluster 사용 때와 동일한 비용 구조입니다.

둘째는 PCS 관리비입니다. 다음 세 요소로 구성되며, 모두 분 단위로 올림 과금됩니다.

• 컨트롤러 요금 — PCS 클러스터 구성 때, 클러스터 컨트롤러 사이즈 선택을 요청 받습니다. 시간당 고정 요금이며, 컨트롤러 크기에 따라 달라집니다(각 리전별 Slurm 컨트롤러 사이즈에 따른 컨트롤러 요금은 위의 PCS 비용 구조 링크를 참고하시기 바랍니다).
• 노드 관리 요금 — 노드 그룹에서 실행되는 EC2 인스턴스(컴퓨트 노드)마다 시간당 부과되며, Standard와 Advanced 두 등급으로 나뉩니다(그림5 참고).
• (옵션) Slurm Accounting — 사용하면 컨트롤러 크기별 시간당 사용 요금과 GB-월 단위 저장 요금이 추가됩니다. 쓰지 않으면 부과되지 않습니다.

비용은 태그로 추적할 수 있습니다. PCS 리소스에 태그를 붙이면 AWS Cost Explorer에서 클러스터별, 노드 그룹별로 비용을 분해해 볼 수 있습니다.

예시로 감 잡기

PCS 요금이 실제로 얼마나 나오는지, AWS 공식 단가(아시아 태평양, 서울 리전)를 적용한 20노드 규모의 예시 두 가지로 살펴보겠습니다. 아래 금액은 모두 PCS 관리 요금이며, EC2 컴퓨트와 스토리지 등 실제 리소스 비용은 별도로 더해집니다. 표시 금액은 본 글 작성 시점 기준이며 요금은 변동될 수 있습니다. (단가 출처: AWS PCS 요금 페이지 https://aws.amazon.com/pcs/pricing/)

예시 1 — 상시 가동(Always On) 클러스터

CFD 해석 같은 워크로드로 20노드(전부 CPU, Standard 티어) 클러스터를 한 달 내내 24시간 가동한다고 가정합니다. 20노드에는 Small 컨트롤러(최대 32노드)가 적합하고, Slurm Accounting(작업 사용량 집계)을 켜서 평균 10GB의 사용량 데이터를 저장합니다. 한 달 요금은 다음과 같습니다.

• 컨트롤러 요금: $0.7381/시간 × 24시간 × 30일 = $531.43
• 노드 관리 요금: 20노드 × $0.1014/노드/시간 × 24시간 × 30일 = $1,460.16
• Accounting 사용 요금: $0.2154/시간 × 24시간 × 30일 = $155.09
• Accounting 스토리지 요금: $1.0264/GB/월 × 10GB = $10.26
• 월 합계 = $2,156.94 (컨트롤러 + 노드 관리 + Accounting 사용 + Accounting 스토리지)

예시 2 — 간헐적(스파이키) 일일 워크로드

같은 20노드(전부 CPU, Standard 티어)를 간헐적으로, 매주 5일 하루 2시간씩만 돌린다고 가정합니다. Small 컨트롤러를 선택하고 Slurm Accounting은 켜지 않으며, 컨트롤러(컨트롤 플레인)는 한 달 내내 유지됩니다. 한 달 요금은 다음과 같습니다.

• 컨트롤러 요금: $0.7381/시간 × 24시간 × 30일 = $531.43
• 노드 관리 요금: 20노드 × $0.1014/노드/시간 × 2시간 × 5일 × 4주 = $81.12
• 월 합계 = $612.55 (컨트롤러 + 노드 관리)

두 예시를 비교하면 PCS 관리비의 구조가 드러납니다. 상시 가동에서는 노드 관리 요금($1,460)이 컨트롤러 고정비($531)보다 크지만, 간헐적 가동에서는 노드 관리가 $81로 줄면서 컨트롤러 고정비($531)가 관리비의 대부분(약 87%)을 차지합니다.

이는 컨트롤러 요금의 성격 때문입니다. 컨트롤러 요금은 잡 실행량이 아니라 “클러스터가 존재하는 시간”에 대해 부과됩니다. PCS 클러스터가 ACTIVE 상태로 떠 있는 동안 시간당(분 단위 올림) 과금되며, 노드가 몇 대 돌든, 잡이 돌든 안 돌든 무관합니다. 따라서 규모가 작거나 가동률이 낮을수록 이 고정비의 비중은 커집니다.

비용 최적화의 핵심은 두 가지입니다. 첫째, 인스턴스 수와 작업 수에 맞는 가장 작은 컨트롤러(여기선 Small)를 선택합니다. 둘째, 필요 없을 때는 클러스터를 삭제해 컨트롤러 고정비 자체를 멈춥니다.

다만 이 관리 요금은 절대적인 금액이 아니며, 대안과 비교해서 살펴봐야 합니다. 스케줄러를 직접 운영하려면 컨트롤러(컨트롤 플레인)를 구축하고, 보안 패치와 버전 업그레이드를 따라가고, 장애에 대응하는 전문 엔지니어의 시간이 꾸준히 발생합니다. 게다가 스케줄러 설정 오류나 컨트롤러 장애로 값비싼 HPC 및 GPU 노드가 유휴 상태에 놓이면, 며칠 치 손실만으로도 한 달 관리 요금을 넘어설 수 있습니다.

그래서 무료인 AWS ParallelCluster와 비교할 때도 ‘유료 대 무료’가 아니라, 인건비와 중단 손실, SLA(월 99.9% 가동률)와 지원 체계까지 포함한 총소유비용(TCO)으로 판단하는 것이 정확합니다. PCS 관리 요금은 이렇게 변동이 크고 예측하기 어려운 운영 비용을, 사용량에 비례하는 예측 가능한 요금으로 바꿔 주는 값입니다.

맺음말 — 1부를 마치며

1부에서는 AWS PCS가 무엇인지(관리형 Slurm), 왜 등장했는지(ParallelCluster의 운영 부담), 그리고 요금이 어떻게 구성되는지를 살펴봤습니다. 핵심은 하나입니다. PCS는 “동일한 Slurm 스케줄러를 그대로 사용하면서 스케줄러 운영 부담만 AWS에 넘긴다”는 분명한 지점을 제공하고, 그 대가로 예측 가능한 관리 요금을 지불하는 구조입니다. 이 요금은 절대 금액이 아니라 인건비, 중단 손실, SLA를 포함한 총소유비용(TCO) 관점에서 볼 때 판단이 달라집니다.

그렇다면 내 워크로드에는 실제로 무엇이 달라질까요? 2부에서는 CFD/CAE와 분산 트레이닝(ML) 같은 워크로드별 관점, 하나의 클러스터에서 여러 큐를 함께 운영하는 멀티 큐, 이미 ParallelCluster를 쓰는 분들을 위한 전환 실전 가이드, 그리고 실제 도입 사례(Shell, Toyota)를 다룹니다.