아래 글은 먼저 Google Cloud 블로그의 H4D 소개 글을 기준으로 핵심 사실을 뽑아 정리한 뒤, 실제로 구성할 때 필요한 설정 단계를 가이드 문서 형태로 재구성한 것입니다. (H4D는 글/문서 기준으로 프리뷰 기능이 포함되어 있어, 운영 적용 전 사전 검증을 권장드립니다.)
1) H4D가 “지금” 필요한 상황 정리
H4D는 Google Cloud에서 HPC(예: 제조/CFD, 날씨 예측, EDA, 생명과학)처럼 노드 간 통신이 잦고, 메모리 대역폭과 CPU 성능이 중요한 워크로드를 겨냥한 VM입니다. 블로그 기준으로 H4D는 5세대 AMD EPYC 기반이며, Cloud RDMA(200Gbps) + Titanium 오프로딩을 결합해 확장(스케일 아웃) 시 병목을 줄이는 쪽으로 설계되었습니다.
성능 수치는 워크로드마다 달라서 “무조건 빠르다”로 단정하긴 어렵습니다. 다만 공개된 벤치마크 기준으로는 OSS-HPL/STREAM 및 여러 HPC 앱에서 C2D/C3D 대비 향상이 제시되어 있습니다. (이 수치들은 Google의 측정/게시 값이므로, 본인 워크로드로 반드시 재현 테스트가 필요합니다.)
2) 사전 준비 체크리스트
리전/존 제약 확인
H4D는 소개 글 기준으로 us-central1-a(Iowa), europe-west4-b(Netherlands)에서 우선 제공됩니다(추가 리전은 진행 중). 먼저 내가 원하는 데이터 위치/지연/규정 요건을 만족하는지 확인합니다.
머신 특성 이해
공식 문서에 따르면 H4D는 192 vCPU, 최대 1,488GB 메모리 구성이며, 로컬 SSD 및 Cloud RDMA 구성이 가능합니다. 또한 H4D는 SMT가 비활성화되어 있고, 오버커밋이 없도록 설계되어 “성능 일관성”을 우선합니다.
용량(Quota/Reservation) 이슈
HPC는 한 번에 큰 덩어리로 띄우는 경우가 많아서, “만들려는데 안 만들어지는” 일이 자주 납니다. H4D Slurm 튜토리얼에서도 192 vCPU H4D 2대에 대한 예약 용량 블록 요청을 시작 단계로 명시합니다. 계획이 확정되어 있다면, 최소한 쿼터/예약 가능 여부부터 먼저 확인하는 편이 안전합니다.
3) RDMA 네트워크 구성 원칙
H4D에서 RDMA를 쓰려면 네트워크가 일반 VPC 구성과 다릅니다. 핵심만 정리하면 다음과 같습니다.
RDMA는 “전용 VPC 네트워크 프로필”을 사용
RDMA 네트워크 프로필로 만든 VPC는 저지연/고대역폭 RDMA 통신을 제공하도록 설계되어 있습니다. 그리고 H4D는 Falcon VPC 네트워크(IRDMA NIC) 조합으로 분류됩니다.
존(Zone) 종속이 강함
RDMA 네트워크 프로필이 붙은 VPC는 특정 존에 종속됩니다. 즉, 그 VPC를 쓰는 인스턴스는 반드시 같은 존에 만들어야 합니다. (멀티존 분산 같은 패턴과 잘 안 맞을 수 있습니다.)
MTU는 8896 권장
RDMA 네트워크 프로필 VPC는 최적 성능을 위해 MTU 8896을 권장합니다. gcloud/API로 만들면 기본이 8896이고, 콘솔로 만들면 직접 8896으로 맞추라고 안내합니다.
4) Cloud RDMA 인스턴스 생성 방법 핵심
Compute Engine 문서 기준으로, RDMA 인스턴스는 “VM 생성 시점”에 요구 조건이 있습니다.
NIC를 최소 2개 구성
Cloud RDMA를 쓰려면 네트워크 인터페이스(NIC)를 2개 이상 붙여야 합니다.
- NIC #1: RDMA 네트워크 프로필이 있는 VPC에 붙는 IRDMA NIC
- NIC #2: 일반 트래픽/관리용으로 GVNIC을 사용하는 NIC
이 구조를 만족해야 RDMA 지원 구성이 됩니다.
운영에서 흔한 패턴은 “GVNIC NIC로 SSH/패키지 설치/모니터링/스토리지 접근”을 하고, “IRDMA NIC는 MPI/노드 간 통신 전용”으로 분리하는 방식입니다. (이건 구성 관점의 권장 패턴이고, 실제 라우팅/방화벽/보안 정책은 조직 기준에 맞춰 조정하셔야 합니다.)
5) Slurm 기반으로 클러스터 형태로 올리는 절차
단일 VM으로도 테스트는 가능하지만, H4D의 장점은 보통 멀티 노드 확장에서 체감됩니다. Google Cloud는 H4D + RDMA 기반 Slurm 클러스터를 Cluster Toolkit + Terraform 흐름으로 안내합니다.
튜토리얼 흐름을 요약하면:
- 프로젝트 권한/환경변수 준비
- Terraform 모듈 보관용 Cloud Storage 버킷 준비
- Cluster Toolkit 설정
- Slurm 배포용 YAML 작성
- 청사진(blueprint)으로 Slurm 클러스터 프로비저닝
- 클러스터 접속 후 잡 실행
또한 스토리지로는 Filestore를 예시로 들고, 할당량/최소 용량 같은 전제 조건도 명시합니다.
제가 이 글을 “실제로 해본 것처럼” 더 현실적으로 쓰고 싶을 때 보통 이렇게 진행합니다(재현 가능한 체크 포인트 중심):
- 먼저 2노드로 최소 구성: RDMA NIC 구성과 MPI 통신만 검증
- 그다음 파일시스템 추가: Filestore/병렬 FS를 붙이고 IO 병목 확인
- 마지막에 노드 수 확장: 8/16/32 노드로 strong scaling 체크
이 순서로 가면, 문제 발생 시 원인(네트워크/RDMA/스토리지/스케줄러)을 분리해서 잡기 좋습니다. (단, 이 “진행 순서”는 일반적인 실무 팁이고, 제품의 공식 보장 동작을 의미하진 않습니다.)
6) 검증 방법
H4D 소개 글에서도 OSS-HPL, STREAM Triad 같은 벤치마크를 언급합니다. 따라서 검증도 비슷한 축으로 가져가면 비교가 편합니다.
- 단일 노드 성능 확인: 코어 고정(pin), NUMA 고려 후 HPL/STREAM
- 멀티 노드 통신 확인: MPI ping-pong / allreduce류 마이크로벤치 + 실제 앱 짧은 케이스
- RDMA 효과 확인: 동일 노드 수에서 TCP 대비 RDMA로 시간 차이를 비교
특히 블로그는 RDMA(Falcon)로 TCP 대비 속도 향상 예시를 제시하므로, 본인 워크로드에서도 “TCP vs RDMA” A/B 비교를 최소 1회는 해보는 게 좋습니다.
7) 마무리
정리하면, H4D는 “큰 코어 수 + 높은 메모리 대역폭 + RDMA 기반 확장”이 필요한 HPC에 맞춘 설계이고, 구성에서 가장 중요한 포인트는 (1) 제공 존 확인, (2) RDMA 네트워크 프로필 VPC, (3) NIC 2개(IRDMA+GVNIC) 조건입니다.