인코어드의 AWS HPC 환경에서 WRF 실행하기 [1부: HPC 전용 인스턴스 선택과 비용 최적화]

신재생 에너지 전문기업 인코어드는 HPC 시뮬레이션으로 재생에너지 발전량 예측에 필요한 고해상도 기상예측과 다양한 기상 시나리오를 생성하고, 이를 기반으로 발전량을 사전에 예측합니다. 이 예측 결과는 전력시장 입찰량 산정, 실시간 출력 제어, 정산 및 임밸런스(예측 발전량과 실제 발전량의 차이) 관리까지 전력거래 프로세스 전반의 핵심 입력 자료로 활용됩니다. 이러한 업무를 위해서는 최소 15분 단위, 1,000m(1km) 해상도의 고정밀 기상 시뮬레이션이 필수입니다.

인코어드는 이 기상 시뮬레이션을 오픈소스 기상 모델인 WRF(Weather Research and Forecasting)로 수행하며, 온프레미스 클러스터 없이 AWS의 HPC 전용 인스턴스 위에서 운영하고 있습니다. 그 과정에서 흥미로운 현상을 발견했습니다. 동일한 AWS HPC 인스턴스에서 MPI 프로세스와 OpenMP 스레드의 비율, 그리고 노드 수를 바꿔가며 측정한 결과, 노드 수와 비율을 모두 포함한 전체 설정 사이에서 실행 시간이 최대 21%까지 차이가 났습니다(가장 느린 2노드 96:2 122.52분 대비 가장 빠른 3노드 24:8 97.25분). 노드 수를 고정하고 비율만 바꿨을 때의 순수한 효과는 3노드 기준 약 4%(64:3 101.14분 → 24:8 97.25분)였습니다. 특히 3노드에서는 같은 자원을 쓰면서도 MPI 비중을 높일수록 더 빠를 것이라는 직관과 반대로 오히려 느려지는 현상이 나타났습니다. 저희는 이 원인을 AWS EFA(Elastic Fabric Adapter)의 패킷 분석으로 규명하면서, CPU 사용률이 높다고 해서 반드시 효율이 좋은 것은 아니라는 교훈을 얻었습니다.

이 글은 인코어드가 동일한 WRF 워크로드를 세 종류의 AWS HPC 전용 인스턴스에서 실행하며 얻은 결과를 정리한 2부작 시리즈의 첫 번째 글입니다. 1부의 질문은 하나입니다. 어느 HPC 전용 인스턴스를, 몇 노드로 골라야 목표 시간을 만족하면서 비용을 최소화할 수 있는가? 위 두 번째 문단에서 언급한 MPI/OpenMP 비율과 EFA 튜닝의 원인 분석은 2편에서 본격적으로 다룹니다.

결론을 먼저 한 줄로 말씀드리면, 시간당 단가가 낮은 인스턴스를 많이 쓰는 것이 반드시 비용 효율적인 것은 아니었습니다. 이번 실험에서는 노드당 단가가 가장 높은 hpc8a가 노드당 단가가 낮은 hpc6a를 충분히 대체했고, 정작 가장 저렴했던 것은 노드당 단가가 가장 낮으면서 실행 시간도 가장 짧아, 목표 시간 안에 작업을 끝내는 총비용이 최소였던 hpc7g 10노드 구성이었습니다. 즉, 인스턴스 선택은 시간당 단가가 아니라 작업을 목표 시간 안에 끝내는 데 들어가는 총비용으로 판단해야 합니다.

이 글은 온프레미스 환경에서 AWS로 HPC 워크로드를 이전하려는 아키텍트와 비용 의사결정자, 그리고 자신의 예산과 목표 시간에 맞는 HPC 인스턴스 선택 기준이 필요한 분을 위한 글입니다. 이어지는 본문에서는 인코어드가 왜 AWS HPC 전용 인스턴스를 사용하는지, 그리고 hpc7g, hpc6a, hpc8a 세 인스턴스를 실측 시간과 비용으로 어떻게 비교했는지를 순서대로 설명합니다.

시리즈 블로그 보기

• 인코어드의 AWS HPC 환경에서 WRF 실행하기 [1부: HPC 전용 인스턴스 선택과 비용 최적화]
• 인코어드의 AWS HPC 환경에서 WRF 실행하기 [2부: MPI/OpenMP 하이브리드 병렬화 튜닝 심층 분석]

1. 인코어드 소개

인코어드(Encored)는 AI와 IoT 기술을 기반으로 재생에너지 자원의 전력거래를 지원하는 에너지 AI 플랫폼 기업입니다. 자체 개발한 iDERMS(integrated Distributed Energy Resource Management System) 플랫폼을 통해 VPP(Virtual Power Plant), 직접 PPA(Power Purchase Agreement), EMS/MG 등 재생에너지 전력거래 전반에 필요한 예측, 제어, 입찰, 정산 솔루션을 통합 제공합니다. 특히 자체 고해상도 기상예보와 AI 알고리즘을 기반으로 재생에너지 발전량 예측부터 실시간 출력 제어, 입찰 최적화, 24시간 운영관제까지 연결된 통합 서비스를 제공합니다. 인코어드는 다수의 발전공기업과 재생에너지 사업자를 대상으로 검증된 운영 경험을 보유하고 있으며, 재생에너지 입찰제도 확대와 직접 PPA 시장 성장에 따라 전력거래 운영 플랫폼 기업으로 성장하고 있습니다.

2. 재생에너지 연구에서 HPC 시뮬레이션이 필요한 이유

인코어드에게 발전량 예측의 정확도는 전력거래 정산과 직결됩니다. 한국 전력시장은 익일(D+1)/실시간 발전량을 15분~1시간 단위로 예측해 입찰하도록 요구하며, 예측 오차가 클수록 임밸런스 페널티가 급증합니다. 따라서 발전량을 얼마나 정밀하게 예측하느냐가 곧 사업 성과로 이어집니다.

문제는 기상청이 제공하는 예보만으로는 이 정밀도를 확보하기 어렵다는 점입니다. 기상청 예보는 보통 5~10km 해상도로 제공되어, 산악 지형이나 해안선 근처 풍력단지의 국지적 바람 변화를 포착하기 어렵습니다. 재생에너지 발전량은 광역 기상 조건만으로 결정되지 않고, 좁은 지역의 난류, 지형 효과, 시간 분해능이 모두 영향을 미치기 때문입니다.

특히 풍력 발전량 예측에서는 다음 세 가지가 중요합니다.

• 난류모수화(turbulence parameterization): 좁은 산골짜기나 건물 밀집 지역에서 발생하는 와류와 난류는 저해상도 모델로 포착할 수 없습니다.
• 지형 효과: 경사면, 해안선, 건물 배치에 따라 바람 방향과 속도가 급변합니다.
• 시간 분해능: 풍속의 변화에 따른 발전량의 급격한 변화나 15분 단위 실시간 입찰에 대응하기 위해서는 시뮬레이션 타임스텝도 조밀해져야 합니다.

이를 해결하기 위해 인코어드는 WRF 같은 물리 기반 모델을 사용합니다. 다만 1,000m(1km) 해상도로 며칠 치 시나리오를 생성하려면 수백에서 수천 코어 규모의 병렬 HPC 클러스터가 필요하며, 이것이 재생에너지 발전량 예측에 HPC 시뮬레이션이 필수적인 이유입니다.

3. 왜 AWS 클라우드 기반의 HPC 클러스터인가?

온프레미스 환경의 HPC 클러스터는 초기 투자 비용이 크고, 예측 수요 변동에 유연하게 대응하기 어렵습니다. 반면 AWS 클라우드 기반 HPC 환경은 다음과 같은 이점을 제공합니다.

• 탄력적 스케일링: 태풍, 한파 등 긴급 상황에서 다수 기상 시나리오를 동시에 병렬 실행하도록 즉시 확장할 수 있습니다.
• 네트워크 성능: 고성능 인터커넥트 기술인 EFA로 온프레미스의 인피니밴드(InfiniBand)에 준하는 저지연, 고대역폭 통신을 지원합니다.
• 비용 최적화: 사용한 시간만큼만 과금하는 Amazon EC2 On-Demand 요금을 기본으로, Amazon EC2 예약 인스턴스나 Amazon EC2 Savings Plans 등 워크로드에 맞는 요금 옵션을 선택할 수 있습니다.

하지만 클라우드 HPC를 효과적으로 활용하려면 MPI:OpenMP 비율, EFA 패킷 튜닝, 인스턴스 타입 선택 등 세밀한 최적화가 필수입니다. 다음 섹션에서는 이러한 최적화 과정을 실측 데이터와 함께 단계별로 풀어냅니다.

4. AWS HPC 전용 인스턴스 소개

이번 테스트에 사용한 hpc7g, hpc6a, hpc8a 모두 AWS의 HPC 전용 인스턴스입니다. 범용 컴퓨트 인스턴스(c8a, c7g, c6a 등)와 구분되는 몇 가지 특징이 WRF 같은 긴밀 결합(tightly-coupled) MPI 워크로드에 유리하게 작용합니다.

첫째, 하이퍼스레딩(SMT, Simultaneous Multithreading)이 비활성화되어 있습니다. 범용 인스턴스는 일반적으로 물리 코어 하나당 2개의 스레드(vCPU)를 제공하지만, HPC 전용 인스턴스는 1 물리 코어 = 1 vCPU로 제공됩니다. 예를 들어 hpc6a.48xlarge는 96 vCPU가 모두 물리 코어이며, 동일 세대 범용 인스턴스인 c6a.48xlarge(192 vCPU = 96코어 × 2스레드)와 대비됩니다. WRF처럼 연산 집약적이고 캐시 및 메모리 대역폭에 민감한 워크로드는 스레드를 공유하면 오히려 성능이 저하되는 경우가 많아, AWS Well-Architected HPC Lens에서도 하이퍼스레딩 비활성화를 권장합니다.

둘째, 고성능 EFA 네트워크를 기본적으로 제공합니다. EFA 대역폭은 인스턴스별로 hpc6a 100Gbps, hpc7g 200Gbps, hpc8a 300Gbps로 차이가 있으며, 범용 인스턴스보다 훨씬 높은 대역폭과 낮은 지연 시간을 제공합니다. WRF는 매 타임스텝마다 인접 격자 간 데이터를 교환(halo exchange)하므로, MPI rank 수가 늘어날수록 네트워크 성능이 전체 실행 시간을 좌우합니다.

셋째, Amazon EC2 Spot 인스턴스는 지원하지 않지만 코어당 비용이 가장 저렴합니다. HPC 전용 인스턴스는 중단 가능성이 있는 Spot을 제공하지 않는 대신, 유사한 컴퓨트 최적화 x86 인스턴스 대비 최대 70% 낮은 코어당 단가로 제공됩니다. 시간당 절대 단가는 높아 보일 수 있으나, 하이퍼스레딩 비활성화로 vCPU 하나하나가 온전한 물리 코어이고 통신 병목이 적기 때문에, 실제 워크로드 완료 시간 기준의 비용 효율은 범용 인스턴스보다 우수합니다.

이러한 특징 덕분에 인코어드는 동일한 WRF 시뮬레이션을 세 가지 HPC 전용 인스턴스에서 실행하며, 프로세서 아키텍처(ARM vs AMD)와 세대별 성능, 비용 트레이드오프를 비교할 수 있었습니다. 그리고 인코어드는 현재 테스트 단계를 넘어 실제 재생에너지 발전량 예측 프로덕션 환경에서도 이미 HPC 전용 인스턴스를 활용하여 클러스터를 운영하고 있습니다. 즉, 이번 블로그에서 소개하는 최적화 방법은 일회성 벤치마크가 아니라, 전력시장 입찰과 임밸런스 관리를 위한 실제 운영 워크로드에 적용되어 검증된 구성입니다.

5. 테스트 배경 및 결과 개요

인코어드는 그동안 hpc7g와 hpc6a 인스턴스로 HPC 클러스터를 운영해 왔습니다. 그런데 2026년 hpc8a 인스턴스가 새롭게 출시되면서, 이 신규 인스턴스가 기존에 사용해 온 인스턴스(hpc7g, hpc6a) 대비 가성비가 있는지 확인할 필요가 생겼습니다.

이번 실험은 바로 이 질문에 답하기 위한 것입니다. 동일한 WRF 워크로드를 세 종류의 AWS HPC 전용 인스턴스(hpc7g.16xlarge, hpc6a.48xlarge, hpc8a.96xlarge)에서 실행하며, 인코어드가 자체적으로 설정한 내부 목표 시간을 만족하면서 비용을 최소화하는 설정을 찾는 것을 목표로 진행했습니다. 신규 인스턴스인 hpc8a를 중심 평가 대상으로 두고 노드 수(2~3노드)와 MPI:OpenMP 비율(96:2 ~ 24:8)을 다양하게 바꿔가며 측정했으며, 기존에 사용해 온 hpc7g와 hpc6a는 성능, 비용 기준선(Control)으로 삼았습니다.

핵심 결론은 다음과 같은 세 가지입니다.

같은 노드 수에서 MPI:OpenMP 비율만 바꿨을 때의 실행 시간 차이는 3노드 기준 약 4%였고, 최적 구간은 24:8에서 48:4 사이였습니다. – 3노드에서는 같은 인스턴스, 같은 코어 수를 쓰더라도 MPI 비중을 높이면 CPU 사용률은 올라가지만 실행 시간은 오히려 늘어, 64:3(101.14분)보다 24:8(97.25분)이 약 4% 빨랐습니다. 다만 이 경향이 모든 노드 수에서 단조적으로 나타나지는 않았습니다. 2노드에서는 48:4(112.69분)가 24:8(117.23분)보다 빨랐기 때문에, 최적 구간은 24:8에서 48:4(MPI:OpenMP 약 3:1에서 12:1) 사이로 보는 것이 데이터에 부합합니다. 한편 hpc8a에서는 2노드로는 어떤 설정으로도 목표 시간을 달성하지 못했고, 3노드 24:8 구성(평균 97.25분)에서 시간, 비용, 안정성이 모두 가장 우수했습니다.

MPI rank를 늘리면 더 빨라질 것 같지만, 실제로는 더 느려졌습니다. – 직관적으로 생각하면 MPI rank 수를 늘릴수록 개별 rank가 담당하는 계산 범위가 줄어들어 더 빠를 것처럼 보입니다. 하지만 실제로는 정반대였습니다. rank를 잘게 쪼갤수록 통신 메시지가 작아지고 개수가 폭증했으며(예: tx_pkts +84.6%), 메시지당 지연(latency) 누적이 전체 실행 시간을 끌어올렸습니다. 원인은 대역폭이 아니라 EFA 패킷 빈도였습니다. 이는 CPU 사용률만 보고 성능을 판단해서는 안 된다는 교훈을 줍니다. 겉보기에는 바쁘게 돌아가는 것처럼 보여도, 실제로는 네트워크 대기 시간이 누적되고 있을 수 있습니다.

노드 단가가 싸다고 무조건 많이 쓰는 것이 정답은 아닙니다. – 가성비 관점에서 hpc8a는 hpc6a를 충분히 대체할 수 있었으나, WRF 수행 효율과 비용 모두에서 1위를 기록한 hpc7g를 대체하기는 어려웠습니다. 단순히 시간당 비용만 비교할 게 아니라, 실제 작업 완료까지 걸리는 총 시간과 총 비용을 함께 고려해야 합니다. 노드당 단가가 낮아도 많은 노드를 써야 한다면 총비용이 오히려 증가할 수 있습니다.

이하 본문에서는 각 결론의 근거를 데이터와 함께 정리하여 소개하도록 하겠습니다.

6. 인스턴스별 성능 및 비용 비교 (hpc7g / hpc6a / hpc8a)

본격적인 비교에 앞서, 이 결과를 어떻게 해석해야 하는지 먼저 짚고 넘어가겠습니다. 세 종류의 AWS HPC 전용 인스턴스 스펙(spec.)을 표1에서 비교했습니다. 실험의 중심은 hpc8a.96xlarge이며, hpc7g.16xlarge와 hpc6a.48xlarge는 기존에 사용해 온 구성의 성능 기준선(Control) 역할을 합니다.

세 인스턴스는 서로 다른 세대와 아키텍처를 대표합니다. hpc7g는 Arm 기반 Graviton3E로 시간당 단가가 가장 낮고, hpc6a는 3세대 AMD EPYC 기반으로 세 인스턴스 중 가장 이전 세대이며 EFA 대역폭도 100Gbps로 가장 낮습니다. hpc8a는 5세대 AMD EPYC 기반의 최신 세대로, 코어 수(192), 메모리(768GiB), EFA 대역폭(300Gbps) 모두 가장 높습니다.

표1을 보면 인스턴스마다 사용된 노드 수와 총 vCPU 수가 다릅니다. hpc7g는 10노드, hpc6a는 15노드, hpc8a는 2~3노드로 테스트했습니다. 이는 실험 설계의 오류가 아니라, 각 인스턴스에서 WRF를 실제 운영 가능한 방식으로 실행하기 위한 의도된 구성입니다.

표1. 비교 대상 AWS HPC 전용 인스턴스 스펙 (hpc8a, hpc7g, hpc6a)

이번 비교는 코어 수를 맞춰 겨루는 벤치마크가 아닙니다. hpc7g와 hpc6a는 인코어드가 기존에 사용해 온 기준 구성이고, hpc8a는 이를 대체할 후보로서 노드 수와 MPI:OpenMP 비율을 바꿔가며 최적 설정을 탐색한 대상입니다. 목표는 동일한 WRF 문제를 목표 시간 안에 완료하면서 총비용을 최소화하는 구성을 찾는 것입니다. 따라서 총 코어 수를 인위적으로 맞추기보다, 각 구성의 완료 시간과 총비용을 함께 비교했습니다.

또한 WRF는 코어를 늘린다고 무한히 빨라지는 워크로드가 아닙니다. 이번 테스트의 모 도메인 d01은 120×152 격자로 구성되어 있으며, 이 크기에서는 계산에 사용할 수 있는 MPI rank 수가 최대 180개로 제한됩니다. 따라서 노드를 늘려 MPI rank만 계속 증가시키기는 어렵고, 늘어난 코어를 OpenMP thread로 묶어 활용하는 방식이 필요합니다. 이 때문에 총 코어 수 자체보다, 제한된 병렬화 상한 안에서 MPI rank와 OpenMP thread를 어떻게 배치하느냐가 성능에 큰 영향을 줍니다.

다만 한 가지 전제를 분명히 해둘 필요가 있습니다. 이번 실험에서 얻은 구체적인 수치, 즉 최대 180개 MPI rank 상한, 이번 테스트에서 가장 빨랐던 24:8~48:4 구간, 그리고 같은 노드 수에서 비율만 바꿨을 때 나타난 3노드 기준 약 4%의 실행 시간 차이는 모두 인코어드가 사용하는 모 도메인 d01의 크기에 크게 의존합니다. 도메인 크기, 격자 해상도, 네스팅 구성이 다른 WRF 워크로드에서는 병렬화 상한과 효율적인 MPI:OpenMP 비율이 달라질 수 있습니다. 따라서 이 블로그의 수치를 그대로 적용하기보다는, 각자의 도메인 구성에 맞춰 MPI:OpenMP 비율을 바꿔가며 실행 시간과 통신량을 함께 측정하는 접근 방식으로 이해하는 것이 적절합니다.

이러한 배경을 염두에 두고 보면, 이번 구성에서 hpc6a가 15노드, 총 1,440 vCPU를 투입하고도 목표 시간을 초과했으며 총비용도 가장 높게 나타난 이유를 이해할 수 있습니다. 병렬화 상한을 넘어 자원을 추가해도 실행 시간이 선형적으로 줄어들지 않는 반면, 노드 수가 늘어난 만큼 비용은 증가하기 때문입니다.

6.1 인스턴스별 노드 수가 다른 이유

앞서 언급한 것처럼 이번 테스트에서는 인스턴스별 노드 구성 수가 서로 다릅니다. 이는 동일한 노드 수를 맞추기 위한 구성이 아니라, 각 인스턴스의 노드당 코어 수와 WRF의 MPI:OpenMP 구성을 맞춰 실제 운영 가능한 후보 구성을 만든 결과입니다.

WRF 워크로드에서는 도메인을 몇 개의 MPI rank로 나눌지, 각 MPI rank 안에서 OpenMP thread를 몇 개 사용할지, 그리고 노드당 코어를 얼마나 효율적으로 채울지가 함께 성능에 영향을 줍니다. 따라서 이번 테스트에서는 인스턴스별로 노드당 코어 수와 MPI:OpenMP 비율을 함께 고려해 구성을 잡았습니다.

표2. 인스턴스 타입별 MPI/OpenMP 병렬 구성 및 노드 수

예를 들어, hpc6a.48xlarge는 노드당 96코어를 제공합니다. 이번 테스트에서는 노드당 12개의 MPI rank를 실행하고, 각 rank에 8개의 OpenMP thread를 할당했습니다. 이렇게 하면 12 MPI rank × 8 OpenMP thread = 96개 thread가 되어 노드당 96코어를 계산 자원 배치 관점에서 모두 활용할 수 있습니다. 또한 d01 모 도메인에서 계산에 사용할 수 있는 MPI rank 상한이 180개였기 때문에, 180개의 rank를 노드당 12개씩 배치하면 총 15개 노드가 필요합니다. 즉 hpc6a 15노드 구성은 180개의 계산 MPI rank 상한을 채우면서, 노드당 96코어를 최대한 활용하기 위한 구성으로 볼 수 있습니다.

hpc7g.16xlarge는 노드당 64코어를 제공합니다. hpc7g 구성에서는 노드당 8개의 MPI rank와 rank당 8개의 OpenMP thread를 사용하면 8 × 8 = 64개 thread가 되어 노드당 코어 수와 잘 맞습니다. 10개 노드를 사용하면 전체 640코어 규모의 구성이 되며, 이는 인코어드가 기존에 사용해 온 구성 가운데 목표 실행 시간과 비용을 만족한 기준 구성으로 해석할 수 있습니다.

반면 hpc8a는 노드당 192코어를 제공하기 때문에 더 적은 노드 수로도 큰 계산 자원을 구성할 수 있습니다. 예를 들어 hpc8a 3노드에서 노드당 24개의 MPI rank와 rank당 8개의 OpenMP thread를 사용하면 24 × 8 = 192개 thread가 되어 노드당 코어 수를 채울 수 있고, 전체로는 72 MPI rank와 576개 코어 구성이 됩니다. hpc8a 2노드도 같은 방식으로 384코어 규모의 후보 구성을 만들 수 있습니다.

다만 hpc8a처럼 노드당 코어 수가 많은 인스턴스에서는 MPI rank를 무작정 늘리면 d01 모 도메인의 계산 rank 상한에 가까워지거나 이를 초과할 수 있습니다. 이 경우 일부 rank가 계산이 아닌 I/O quilting 등에 사용되거나, 패치 크기가 작아져 통신 부담이 커질 수 있습니다. 따라서 hpc8a 테스트의 핵심은 적은 노드 수에서 코어를 채우는 것뿐 아니라, MPI rank 수와 OpenMP thread 수의 균형을 조정해 WRF의 도메인 분해 특성에 맞는 구성을 찾는 것이었습니다.

따라서 이번 비교는 단순한 동일 노드 수 벤치마크가 아니라, 각 인스턴스의 노드당 코어 수와 WRF 병렬화 구조를 고려한 운영 후보 구성 간 비교입니다. 특히 hpc6a 15노드는 180개 계산 MPI rank 상한과 노드당 96코어 구성이 맞아떨어진 사례이고, hpc8a는 더 적은 노드 수에서 192코어를 MPI rank와 OpenMP thread로 어떻게 나눌지가 성능을 좌우한 사례입니다.

6.2 기준 실험 (Control)

기준 구성 가운데 hpc7g 10노드가 시간 및 비용 모두 양호했고, hpc6a 15노드는 100분을 넘기면서 비용도 가장 높았습니다.

표3. 기준 실험(Control): hpc7g와 hpc6a 구성별 실행 시간과 비용

표3의 nproc_x×y는 전체 MPI 프로세스 수가 아니라, 계산(compute)에 할당된 MPI 프로세스를 2차원으로 나눈 분해 격자입니다. WRF에서 전체 MPI 랭크 수는 nproc_x × nproc_y + nio_groups × nio_tasks_per_group으로 정해지며, I/O quilting 서버로 분리된 랭크는 계산 분해에 포함되지 않습니다. CTRL-1(hpc7g 10노드)은 노드당 8랭크씩 총 80랭크를 띄웠지만 이 가운데 16랭크(nio_groups=2, nio_tasks_per_group=8)를 비동기 I/O 서버로 분리했기 때문에, 계산에 투입된 랭크는 64개이고 분해 격자는 8×8이 됩니다. WRF는 nio_tasks_per_group이 nproc_y 이하이면서 nproc_y를 정확히 나누는 구성을 권장하는데, 이 설정은 nproc_y=8, nio_tasks_per_group=8로 그 조건도 만족합니다. 반면 CTRL-2(hpc6a 15노드)는 quilting 없이 180랭크를 모두 계산에 사용했기 때문에, 노드 수 × 노드당 랭크 수(15 × 12 = 180)가 곧 분해 격자의 곱(12×15)과 일치합니다.

hpc6a 15노드는 총 1,440개의 코어를 투입하고도 wall time이 100분을 넘겼습니다(103.83분). 여기서 두 가지 사실이 동시에 드러납니다. 첫째, 노드를 많이 투입한다고 빨라지지 않습니다. 이 워크로드는 MPI 병렬화가 최대 180 프로세스로 제한되기 때문에, 그 이상 규모를 늘려도 성능이 비례해 개선되지 않습니다. 둘째, AWS는 노드 단위로 과금하므로 노드 수를 늘리면 총비용이 그대로 비례해 증가합니다. 결국 성능 향상 없이 비용만 늘어나는 결과로 이어졌습니다.

참고로 표3의 총 비용은 각 설정을 1회 실행할 때의 온디맨드 컴퓨트 비용으로, 노드 수 × 시간당 단가 × 실행 시간으로 계산했습니다. 단가는 해당 인스턴스를 제공하는 리전 기준이며 스토리지와 데이터 전송 비용은 제외했습니다.

6.3 hpc8a 실험 결과 (2 & 3노드)

2노드 구성은 어떤 설정으로도 목표 시간을 넘겼고, 3노드에서는 24:8이 가장 빨랐습니다. 다만 2노드에서는 48:4가 가장 빨라, 최적 구간은 24:8~48:4로 보는 것이 적절합니다.

아래 hpc8a 결과는 반복 측정 평균값 기준입니다. 반복 횟수(reps)는 설정마다 다른데, 목표 시간 경계에 걸린 3n_64x3만 판별을 위해 4회, 마진이 충분한 나머지 3노드 설정은 3회씩 측정했습니다.

표4의 Group 열은 각 실험 구성을 [노드 수]n_[노드당 MPI 프로세스]x[프로세스당 OpenMP 스레드] 형식으로 표기한 것입니다. 예를 들어 3n_24x8은 노드 3개에서 노드당 24개의 MPI 프로세스를 띄우고, 각 프로세스에 8개의 OpenMP 스레드를 할당한 구성입니다. hpc8a는 노드당 192 vCPU이므로, 노드당 MPI 프로세스 수와 스레드 수의 곱이 항상 192가 되도록 맞췄습니다(24×8, 48×4, 64×3, 96×2). 즉 동일한 하드웨어를 MPI와 OpenMP로 어떻게 나누는지만 달리한 비교입니다. 이때 nproc_x×y 열은 WRF가 계산 영역을 가로 nproc_x개, 세로 nproc_y개로 나눈 격자 분할을 나타내며, 그 곱이 전체 MPI 프로세스 수가 됩니다. 도메인 분해가 어떻게 이뤄지고 왜 상한이 생기는지는 후속편에서 자세히 설명합니다.

각 구성의 전체 MPI 프로세스 수는 노드 수와 노드당 프로세스 수의 곱으로 정해집니다. 3n_24x8(72개), 2n_48x4(96개), 3n_48x4(144개)는 d01의 분해 상한인 180 이내라 그대로 실행되지만, 3n_64x3과 2n_96x2는 총 192개를 요청해 180 상한을 초과하므로 실제 분해는 12×15=180으로 제한됩니다. 초과분 처리 원리는 다음 블로그에서 상세히 다룰 예정입니다.

표4. hpc8a 인스턴스의 노드 수와 MPI:OpenMP 비율에 따른 실행 시간, 비용, 목표 시간 충족 여부

목표 시간을 만족한 후보 중 3n_24x8이 wall time도 가장 짧고 비용도 가장 낮으며, 안정성(std 0.03분)에서도 우위였습니다. 차선인 3n_48x4와의 비용 차이는 run당 $0.34에 불과했습니다. 같은 3노드 안에서 비율만 바꿨을 때의 차이는 64:3(101.14분) 대비 24:8(97.25분) 약 4%였습니다. 반면 2노드에서는 48:4(112.69분)가 24:8(117.23분)보다 빨라, MPI 비중을 낮출수록 실행 시간이 단조적으로 줄어드는 경향은 3노드에서만 관찰되었습니다. 따라서 최적 구간은 24:8 단일 설정이 아니라 24:8~48:4 구간으로 보는 것이 데이터에 부합합니다.

6.4 비용 구조: 노드당 단가가 저렴하다 ≠ 총비용이 싸다

가성비 관점에서 hpc8a는 hpc6a를 대체할 수 있지만, WRF 수행 효율과 비용 1위인 hpc7g를 대체하기는 어렵습니다. 그 내용에 대해 표5에서 설명하고 있습니다.

표5. 구성별 총비용 순위 비교 (목표 시간 충족 여부 포함)

비용만 보면 hpc7g 10노드($25.53)가 1위입니다. 노드당 단가가 $1.68/hr로 가장 낮은 데다 wall time도 90.99분으로 가장 빠릅니다. WRF 수행 효율과 비용을 함께 고려하면 hpc7g가 최선이며, 이 자리를 hpc8a가 대체하기는 어려운 것으로 판명되었습니다.

반면 hpc6a 15노드는 $74.75로 hpc8a 3노드($38.51)의 약 2배이고, wall time도 더 깁니다. 노드당 단가($2.88/hr)는 hpc8a($7.92/hr)보다 낮지만, 같은 작업을 끝내기 위해 15노드를 동원해야 하므로 총비용이 오히려 높아집니다. 즉 노드당 단가가 저렴하다고 총비용이 절감되지는 않습니다. 가성비 관점에서 hpc8a는 hpc6a를 충분히 대체할 수 있으며, 노드 수를 15 → 3으로 줄이면서 비용을 약 절반 수준으로 낮출 수 있는 것으로 파악되었습니다.

6.5 Spot 인스턴스를 사용하지 않은 이유

WRF 워크로드를 수행할 때 1순위 기준은 안정성입니다. 제한된 시간 안에 원하는 예보 데이터를 반드시 산출하는 것이 목표이기 때문입니다.

Spot 인스턴스는 단가가 상대적으로 낮다는 장점이 있지만, 실행 도중 노드 할당이 회수(중단)될 수 있는 위험이 있습니다. 더욱이 WRF는 tightly-coupled MPI 워크로드라 노드 하나만 회수돼도 전체 run이 실패합니다. 체크포인트에서 다시 Spot 노드를 확보해 이어서 수행한다 해도, 재할당 대기와 재개에 드는 시간 손실은 무시할 수 없습니다. 매일 반복되는 실시간 운영에서 이러한 중단 리스크는 받아들이기 어렵습니다.

따라서 본 실험과 운영은 모두 On-Demand 기준으로 진행했으며, 또한 실험에 사용된 HPC 전용 인스턴스는 Spot 형태로 제공되지 않습니다.

다만 이는 WRF처럼 중단을 허용할 수 없는 워크로드에 해당하는 이야기입니다. 만약 체크포인트 기반 재시작이 저렴하거나, 다수 시나리오를 독립적으로 돌려 일부 실패를 감내할 수 있는 워크로드라면, Spot을 활용하는 편이 비용 면에서 훨씬 유리할 수 있습니다.

이 경우 한 가지 고려할 만한 선택지는, HPC 전용 인스턴스 대신 Spot을 지원하는 최신 세대 컴퓨트 최적화(‘c’ 계열) 인스턴스를 사용하는 것입니다. HPC 전용 인스턴스는 코어당 On-Demand 단가가 가장 낮은 대신 Spot을 제공하지 않지만, ‘c’ 타입 인스턴스는 Spot을 통해 On-Demand 대비 큰 폭의 할인을 받을 수 있습니다. 따라서 워크로드가 중단에 견딜 수 있다면, HPC 전용 인스턴스의 낮은 On-Demand 단가와 ‘c’ 타입 인스턴스의 Spot 할인 폭을 비교해 더 저렴한 쪽을 택하는 접근이 가능합니다. 다만 이때도 MPI 통신 성능이 중요한 워크로드라면 해당 ‘c’ 타입 인스턴스가 EFA를 지원하는지 반드시 확인해야 합니다.

맺음말

1부에서는 WRF 워크로드를 AWS HPC 전용 인스턴스에서 실행할 때, 어떤 인스턴스를 몇 노드로 선택해야 목표 시간을 만족하면서 총비용을 낮출 수 있는지 살펴봤습니다. 핵심 교훈은 두 가지입니다.

첫째, 인스턴스 선택은 시간당 단가가 아니라 작업 완료 시간과 총비용을 함께 기준으로 판단해야 합니다. 본 실험에서는 hpc7g 10노드 구성이 실행 시간과 비용 측면에서 가장 좋은 결과를 보였습니다. 노드당 단가가 낮은 인스턴스라도 목표 시간을 맞추기 위해 더 많은 노드를 사용해야 한다면 총비용은 오히려 증가할 수 있습니다. 따라서 비용은 시간당 단가가 아니라 목표 시간 내 완료까지의 총비용이라는 관점에서 봐야 합니다.

둘째, hpc8a는 hpc6a를 대체할 가능성을 보였지만, hpc7g를 대체하기에는 비용 효율 측면에서 충분하지 않았습니다. hpc8a 3노드 구성은 hpc6a 15노드보다 더 짧은 시간과 낮은 비용으로 목표 시간을 만족했지만, hpc7g 10노드 구성보다는 총비용이 높았습니다. 따라서 이번 워크로드에서는 hpc7g가 가장 경제적인 운영 구성이었고, hpc8a는 hpc6a 구성을 대체할 수 있는 후보로 해석하는 것이 적절합니다. 다만 이 결과는 인코어드의 WRF 워크로드와 본 실험 조건(도메인, 해상도, MPI:OpenMP 구성 등)에 한정된 것으로, 워크로드 특성이나 문제 규모가 달라지면 hpc8a가 더 유리한 경우도 충분히 있을 수 있습니다. 따라서 인스턴스 간 우열은 일반화하기보다 워크로드별 벤치마크를 통해 판단하는 것이 안전합니다.

중요한 질문이 하나 남습니다. hpc8a는 노드당 192개의 코어를 제공하지만, WRF는 코어 수를 늘린다고 항상 선형적으로 빨라지는 워크로드가 아닙니다. 실제로 hpc8a 테스트에서는 동일한 타입의 인스턴스를 사용하더라도 노드 수와 MPI:OpenMP 구성에 따라 실행 시간이 달라져, 노드 수와 비율을 모두 포함한 전체 설정 사이에서 최대 21%(2노드 96:2 122.52분 → 3노드 24:8 97.25분)의 차이가 났습니다. 같은 노드 수에서 비율만 바꿨을 때의 차이는 3노드 기준 약 4%(64:3 101.14분 → 24:8 97.25분)였고, 3노드 구성 안에서도 24:8, 48:4, 64:3의 결과가 서로 달랐습니다. 즉 hpc8a를 효율적으로 사용하려면 단순히 몇 노드를 쓸지만 결정하는 것으로는 충분하지 않고, 각 노드 안에서 MPI rank와 OpenMP thread를 어떻게 배치할지도 함께 고려해야 합니다.

이어지는 2부에서는 이 질문을 다룹니다. hpc8a에서 MPI rank를 많이 늘렸을 때 왜 오히려 실행 시간이 길어졌는지, d01 모 도메인의 MPI 분해 상한이 어떻게 성능을 제한했는지, 그리고 EFA 패킷 분석을 통해 작은 패킷 증가와 통신 오버헤드가 어떻게 드러났는지 살펴보겠습니다. 이를 통해 WRF 같은 tightly-coupled MPI 워크로드에서 코어 수, MPI rank 수, OpenMP thread 수, 네트워크 통신량을 함께 보고 최적 구성을 찾는 방법을 설명하겠습니다.