AWS PCS(Parallel Computing Service)로 로그인 노드, 작업 노드를 구축하고 자동 스케일링까지 검증해봤습니다.
안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번에는 AWS PCS(Parallel Computing Service)로 로그인 노드, 작업 노드를 구축하고 자동 스케일링까지 검증해봤습니다.
AWS PCS란
Slurm 기반의 완전관리형 HPC 클러스터 서비스입니다. 사용자가 직접 Slurm 컨트롤러를 구축·운영할 필요 없이, AWS가 컨트롤러를 관리해주고 사용자는 계산 노드(컴퓨트 노드)만 자신의 계정에 둡니다. 잡이 없을 때는 노드를 0대로 줄이고, 잡이 들어오면 자동으로 노드를 띄우는 구조입니다.
PCS는 몇 개의 AZ가 필요한가
콘솔에서 클러스터 생성 화면을 열어보면, 네트워킹 섹션의 서브넷 항목이 단일 선택 방식으로 되어 있었습니다.
다만 이후 컴퓨팅 노드 그룹을 만드는 단계에서는 여러 서브넷(여러 AZ)을 지정할 수 있는 옵션이 별도로 있었습니다. 즉 컨트롤러는 단일 AZ, 컴퓨트 노드는 필요시 Multi-AZ로 확장 가능한 구조입니다.
Step 1. PCS 클러스터 생성
클러스터 세부 정보
| 항목 | 설정값 | 비고 |
|---|---|---|
| 클러스터 이름 | test-cluster | 임의 지정 |
| 스케줄러 | Slurm 25.11 | PCS는 Slurm 전용 |
| 컨트롤러 크기 | Small（최대 32노드, 256잡） | 검증용으로 충분 |
스케줄러 구성
| 항목 | 설정값 | 비고 |
|---|---|---|
| 스케일 다운 유휴 시간 | 10분 | 검증용으로 짧게 설정 |
| 선택 유형 파라미터 | CR_CPU | CPU 기준 스케줄링. 메모리 집약적 워크로드라면 CR_CPU_Memory 검토 필요 |
| Prolog / Epilog | 비워둠 | 선택 사항, 지금은 불필요 |
| REST API | 비활성화 | 콘솔에서 직접 검증하는 단계라 불필요 |
| 어카운팅 | 비활성화 | 추가 요금 발생하는 기능, 검증 단계에서는 불필요 |
네트워킹
| 항목 | 설정값 |
|---|---|
| 네트워크 유형 | IPv4 |
| VPC | 기존 검증용 VPC |
| 서브넷 | Private 서브넷 1개 |
| 보안 그룹 | Quick create (자동 생성, pcs-cluster-N) |
Step 2. EC2 시작 템플릿 생성
컴퓨팅 노드 그룹은 EC2를 자동으로 생성/삭제하는데, 어떤 스펙으로 생성할지는 EC2 시작 템플릿을 미리 만들어서 지정해야 합니다.
주요 설정
| 항목 | 설정값 | 비고 |
|---|---|---|
| 서브넷 / 가용 영역 | 시작 템플릿에 포함하지 않음 | PCS 노드 그룹 설정에서 별도 지정 |
| 보안 그룹 | Step 1에서 자동 생성된 pcs-cluster-N | 필수 |
| 볼륨 | 기본값 유지, 종료 시 삭제 = 예 | 임시 노드라 삭제 설정 중요 |
| IAM 인스턴스 프로파일 | SSM 접속용 역할 | Session Manager 접속에 필요 |
Step 3. 컴퓨팅 노드 그룹 생성 (계산용)
| 항목 | 설정값 |
|---|---|
| IAM 인스턴스 프로파일 | 기본 프로파일 생성 (PCS 클러스터 가입 권한 자동 부여) |
| 서브넷 | Step 1과 동일한 서브넷 1개 |
| 인스턴스 유형 | t3.micro |
| 최소 인스턴스 수 | 0 |
| 최대 인스턴스 수 | 2 |
| AMI ID | (아래 문제 참고) |
| 용량 구매 옵션 | On-Demand |
| 노드 수명 주기 작업 | 비워둠 |
※ 최소 인스턴스 수를 0으로 설정하는 것이 "잡이 없으면 노드가 완전히 사라지는" 요구사항을 실현하는 핵심 설정입니다.
막혔던 문제: 일반 AMI로는 부트스트랩이 실패한다
처음에는 시작 템플릿에 일반 Amazon Linux 2023 AMI를 그대로 지정해서 노드 그룹을 만들었습니다. 로그인 노드에 접속해서 확인해보니
sinfo
sh: sinfo: command not found
Slurm 명령어 자체가 설치되어 있지 않았습니다. 부트스트랩 로그를 확인해봤습니다.
sudo cat /var/log/amazon/pcs/bootstrap.log
/usr/bin/cloud-init-per: line 63: /opt/aws/pcs/bin/pcs_bootstrap_init.sh: No such file or directory
PCS가 노드를 설정하기 위해 실행하려는 부트스트랩 스크립트 자체가 AMI 안에 없었던 것이 원인이었습니다. PCS는 아무 AMI나 쓸 수 있는 게 아니라, PCS 전용 부트스트랩 스크립트가 포함된 AMI를 사용해야 합니다.
AWS CLI로 우리 클러스터의 Slurm 버전(25.11)에 맞는 샘플 AMI를 검색했습니다.
aws ec2 describe-images --region ap-northeast-1 --owners amazon \
--filters 'Name=name,Values=aws-pcs-sample_ami-*' \
'Name=state,Values=available' \
--query 'sort_by(Images, &CreationDate)[].[Name,ImageId,CreationDate]' \
--output table
시작 템플릿에서 AMI의 경우 검색된 AMI로 지정하여 재생성했습니다.
이후 부트스트랩 로그를 다시 확인하니 정상적으로 진행됐습니다.
Step 4. 대기열(Queue) 생성
| 항목 | 설정값 |
|---|---|
| 대기열 이름 | queue-1 |
| 연결할 컴퓨팅 노드 그룹 | Step 3에서 만든 노드 그룹 |
※ 컴퓨팅 노드 그룹은 "Active" 상태가 되어야 대기열에 연결할 수 있습니다.
Step 5. 로그인 노드 그룹 생성
사용자가 실제로 접속해서 잡을 제출할 노드입니다. 별도의 "로그인 노드 생성" 메뉴가 있는 게 아니라, 컴퓨팅 노드 그룹 생성 화면을 다시 사용하되 설정값을 다르게 지정합니다.
| 항목 | 계산용 노드 그룹 | 로그인 노드 그룹 |
|---|---|---|
| 최소/최대 인스턴스 | 0 / 2 | 1 / 1 (항상 켜져 있어야 함) |
| 대기열 연결 | 연결함 | 연결하지 않음 |
| AMI | PCS 샘플 AMI | PCS 샘플 AMI (동일) |
Step 6. 로그인 노드 접속 및 클러스터 상태 확인
로그인 노드 그룹이 Active 상태가 된 후, EC2 콘솔에서 해당 인스턴스를 찾아 SSM Session Manager로 접속했습니다. Slurm 클라이언트 명령어가 PATH에 잡혀 있지 않아 절대 경로로 실행했습니다.
find / -name "sinfo" 2>/dev/null
/opt/aws/pcs/scheduler/slurm-25.11/bin/sinfo
/opt/aws/pcs/scheduler/slurm-25.11/bin/sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
queue up infinite 2 idle~ node-group-1-[1-2]
대기열과 노드 2대가 정상적으로 인식되었습니다. idle~의 물결표(~)는 노드가 아직 실제로 기동되지 않은 절전 상태임을 의미합니다.
Step 7. 실제 잡 제출 검증
/opt/aws/pcs/scheduler/slurm-25.11/bin/srun -p queue-1 --nodes=1 hostname
잡을 제출하자 곧바로 응답이 오지 않고 잠시 대기 상태가 되었습니다. 이는 노드가 0대인 상태에서 잡이 들어오면 PCS가 실시간으로 EC2를 새로 기동하고, 부트스트랩(Slurm 설치 및 클러스터 등록)까지 마친 뒤 잡을 실행하기 때문입니다.
몇 분 후 결과가 반환되었습니다.
ip-xx-x-xxx-xx.ap-northeast-1.compute.internal
EC2 콘솔에서도 이 시점에 새로운 인스턴스가 자동으로 생성된 것을 확인했습니다. 잡이 끝난 뒤 설정한 유휴 시간(10분)이 지나자, EC2 콘솔에서 해당 인스턴스가 자동으로 종료된 것을 확인했습니다.
마무리
이번 검증을 통해 AWS PCS에서 Slurm 기반 HPC 환경을 구성하고, 로그인 노드에서 잡을 제출하면 필요한 계산 노드가 자동으로 생성되는 과정을 확인했습니다.
특히 컴퓨팅 노드의 최소 수를 0으로 설정하고, 유휴 시간을 기준으로 스케일 다운하도록 구성하면 잡이 없을 때는 EC2 비용을 줄이고, 잡이 들어왔을 때만 필요한 만큼 노드를 기동하는 구조를 쉽게 구현할 수 있었습니다.
구성 과정에서 일반 Amazon Linux 2023 AMI를 사용했을 때 PCS 부트스트랩에 실패했던 것처럼, PCS에서는 Slurm 버전에 맞는 PCS용 AMI를 사용하는 것이 중요했습니다. 또한 로그인 노드와 계산용 노드 그룹을 분리하고, 계산용 노드 그룹만 대기열에 연결함으로써 역할을 구분할 수 있었습니다.
이번 테스트에서는 t3.micro 1대를 동적으로 생성하는 간단한 환경으로 검증했지만, 실제 HPC 환경에서는 여러 인스턴스 타입과 Multi-AZ 구성을 활용해 더 큰 규모의 워크로드를 처리할 수 있습니다.
결과적으로 AWS PCS를 사용하면 Slurm 클러스터의 컨트롤러 운영 부담은 AWS에 맡기면서, 필요한 계산 자원만 동적으로 확장·축소하는 HPC 환경을 비교적 간단하게 구축할 수 있었습니다.
