![인코어드의 AWS HPC 환경에서 WRF 실행하기 [2부: MPI/OpenMP 하이브리드 병렬화 튜닝 심층 분석]](https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2026/11/04/Headline-Image-encored-wrf-hpc-part2.png)
데브옵스
인코어드의 AWS HPC 환경에서 WRF 실행하기 [2부: MPI/OpenMP 하이브리드 병렬화 튜닝 심층 분석]
두줄요약
AWS HPC에서 WRF의 MPI/OpenMP 비율을 조정해 통신 오버헤드를 분석했습니다. CPU 사용률보다 wall time과 EFA 패킷 지표를 함께 봐야 함을 확인했습니다.
문제 상황
- WRF 모 도메인 d01의 최소 패치 크기 제약에 따른 MPI 프로세스 최대 180개 제한
- hpc8a의 다수 코어를 순수 MPI로 활용하기 어려운 구조와 MPI/OpenMP 비율별 실행 시간 편차
- 높은 CPU 사용률과 긴 wall time이 함께 나타나는 busy-poll 기반 MPI 대기 현상
구조와 흐름
- MPI 프로세스 단위의 패치 분할과 OpenMP 스레드 단위의 타일 분할
- 중첩 도메인에서 격자 수가 적은 d01이 전체 MPI 병렬화 상한을 결정하는 구조
- 매 타임스텝 패치 간 halo 교환과 EFA 기반 경계 데이터 통신
성능/운영 포인트
- hpc8a 3노드에서 24:8 구성의 97.25분 실행 시간과 24:8~48:4 최적 구간
- MPI rank 증가 시 작은 패킷과 tx_pkts 증가, 통신 처리 오버헤드 및 step time 지연 누적
- CPU 사용률 대신 wall time, step time, EFA tx_pkts·tx_bytes·평균 패킷 크기 병행 분석
적용해볼 점
- 도메인 크기·해상도·nesting·출력 방식별 MPI/OpenMP 비율 직접 측정
- 패치 최소 크기와 halo 대 계산 비율을 고려한 rank 수 제한
- FSx for Lustre 처리량, 동일 AZ 배치, 필요한 노드 용량 사전 확보 검토

