그리드 컴퓨팅: 가상조직(VO)이 이기종 자원을 하나로 묶는 방법

과학 실험 장비, 렌더팜, 금융 리스크 엔진처럼 한 기관이 감당하기 버거운 연산량을 처리해야 할 때, 그리드 컴퓨팅은 여러 기관·지역에 흩어진 자원을 가상조직(Virtual Organization, VO) 단위로 묶어 하나의 공용 자원 풀처럼 쓰게 한다. OGSA(Open Grid Services Architecture)를 지향하는 계층형 설계로 전송·인증·자원 협상·모니터링을 표준 프로토콜과 서비스로 분리해, 자원 공유를 극대화하고 공정한 스케줄링과 보안 경계를 지키면서 대규모 배치 처리의 처리량을 최적화하는 게 목표다. 유휴 자원 공용화와 큐 평준화로 자원 활용률이 20~~60%p 상승하고, 동일 인프라 대비 처리량이 1.3~~2.5배 증가하는 효과가 실제로 관측된다.

네 계층으로 나눠야 상호운용이 된다

Fabric 계층은 컴퓨트 노드·대용량 스토리지·네트워크·실험 장치와 Slurm·PBS·HTCondor 같은 로컬 스케줄러를 포함하는 물리·가상 자원 계층이다. 링크·드라이버·로컬 API를 제공해 상위 계층이 자원의 상태·용량·큐 정보를 추상화해 조회할 수 있게 한다.

Connectivity 계층은 통신과 인증을 담당한다. TLS 같은 전송, 인터넷 라우팅, 메시지 프로토콜, X.509 기반 mTLS·GSI 같은 상호 인증을 제공하고 무결성·기밀성·재전송 제어를 보장하며, 기관 경계를 넘을 때는 프록시나 연합 ID 토큰을 쓴다.

Resource 계층은 단일 자원 단위의 공유·보안·협상·초기화·모니터링·제어를 맡는다. SLA·우선순위에 따른 자원 사용 정책 협상, 작업 접수와 초기화, 실행 중 상태 수집, 취소·중단·재시작 제어가 여기 속한다.

Collective 계층은 자원 집합을 대상으로 한 상호작용을 정의한다. 크로스사이트 배치를 결정하는 메타스케줄링, 데이터·레플리카 카탈로그, MDS류 디스커버리, 페더레이션 정책, 글로벌 모니터링과 회복력 제어가 이 계층의 일이다.

잡 하나가 제출돼서 결과로 돌아오기까지

작업(Job)과 데이터, 정책이 입력되면 mTLS(X.509)로 인증하고 VO를 확인한 뒤, 자원 디스커버리로 용량·큐·정책을 조회하고 메타스케줄러가 매칭·협상·예약(Lease)한다. 이어서 입력 데이터·컨테이너를 배포하는 데이터 스테이징이 일어나고, 로컬 스케줄러가 실제로 실행하며 상태·로그를 모니터링한다. 성공하면 결과·로그를 다시 스테이징 아웃해 카탈로그에 등록하고, 실패하면 재시도 한도 안에서 대체 자원으로 재스케줄한다.

⤢✕

작업 ID와 제출 토큰으로 멱등성을 설계하고, 제출(예약)→스테이징→실행 승인을 단계적으로 커밋하며 실패하면 이전 단계로 롤백한다. 레플리카 카탈로그는 최종 커밋 시점에만 갱신한다. 시간 초과나 노드 실패에는 백오프 재시도와 정책 기반 대체 자원 선택으로 대응하고, 최대 재시도를 넘기면 실패를 전파하고 진단 로그를 남긴다. 이 재시도·대체 자원 자동화만으로 워크로드·정책에 따라 성공률 95%+ 달성이 가능하다.

그리드가 실제로 쓰이는 곳

대형 과학실험은 LHC·LIGO류 워크로드처럼 TB~PB급 데이터를 분산 필터링·시뮬레이션하는 데 그리드를 쓴다. 반도체 EDA·검증은 회로 시뮬레이션·타이밍 분석을 야간 그리드로 분산해 테이프아웃 일정을 단축한다. 미디어 렌더팜은 프레임·샷 단위로 분산 렌더링하며 우선순위·마감 기반 글로벌 큐를 운영하고, 금융 리스크·리밸런싱은 몬테카를로 VaR·XVA 계산을 데이터 근접성을 고려해 야간 배치로 돌린다. 재난·기상 예측은 영역을 분할해 수치해석 모델을 병렬화하고, 노드가 실패하면 서브도메인을 재할당해 회복성을 확보한다.

그리드 vs HPC 클러스터 vs 클라우드

항목	그리드	HPC 클러스터	클라우드
성능	대규모 배치 처리량 최적화, 이기종 혼재	단일 시설 내 낮은 지연, 고속 인터커넥트	인스턴스 기반 탄력 확장, 성능 가변
확장성	기관 간 페더레이션 확장 용이	시설 규모 한계 내 수직 확장	전지구적 수평 확장, 리전 제약
일관성	멱등 제출·카탈로그 커밋 기반 최종 일관성	스케줄러 중심 강한 일관성	서비스별 일관성 정책 상이
안정성	재시도·대체 스케줄링으로 고가용	인프라 단일 도메인 관리로 안정	제공자 SLA 기반, 영역별 차이
운영 편의	다기관 정책·보안 연동 복잡	단일 조직 운영 단순	API 중심 자동화 우수, 비용 가시성

Globus Toolkit 같은 구형 구성요소는 EOL 여부를 최신 정보로 확인해야 하고, 대안으로는 HTCondor·ARC·Slurm 연합·DIRAC, 데이터 쪽의 Rucio, GSI를 대체하는 OIDC 기반 인증 등이 쓰인다.

다기관 환경이라 보안·운영이 더 무겁다

신원·권한은 OIDC/OAuth2 기반 연합 ID와 짧은 수명의 프록시 토큰, VO 역할 기반 접근 제어로 관리한다. 이 방식은 키 인프라를 복잡하게 만드는 대신 기관 간 상호운용성을 끌어올린다.

데이터 무결성·근접성은 체크섬 검증과 레플리카 카탈로그 관리, 데이터-컴퓨트 공동 스케줄링으로 지킨다. 복제 비용이 늘어나는 대신 I/O 병목이 줄어드는 트레이드오프다. 스케줄링 정책은 공정성(Fair-Share)·마감(Deadline)·선점(Preemption)을 섞은 멀티큐 메타스케줄링을 쓰는데, 정책이 충돌할 위험과 전체 처리량 극대화가 맞바꿔진다. 크로스사이트 매칭과 정책 기반 선점을 제대로 운영하면 작업 대기시간을 30~70% 단축할 수 있다.

관측 가능성은 중앙 메트릭·로그 수집과 Submitted→Staging→Running→Succeeded/Failed로 표준화한 작업 수명주기 이벤트로 확보한다. 텔레메트리 오버헤드를 감수하는 대신 장애 MTTR을 줄이는 셈이다. 거버넌스·비용은 크레딧 기반 과금·쿼터와 클라우드 버스팅 상한으로 관리하는데, 정책 관리 부담이 늘어나는 대신 예산 예측 가능성이 올라간다. 공동 사용·페더레이션으로 온프렘 자원을 우선 쓰고 부족분만 클라우드로 버스트하는 방식은 비용을 25~50% 절감하는 효과로 이어진다.

HTCondor로 실제 잡을 던져보면

HTCondor 10.x, 공유 스토리지 또는 HTTP(S)로 입출력이 가능한 환경, 인증은 로컬(테스트용)이라는 전제에서 최소 구현은 이렇다.

작업 스크립트(example.sh):

#!/usr/bin/env bash
echo "hostname: $(hostname)"
python3 - <<'PY'
import time,random
time.sleep(random.randint(1,5))
print("OK")
PY

제출 파일(job.submit):

universe        = vanilla
executable      = example.sh
transfer_executable = True
output          = result.out
error           = result.err
log             = job.log
request_cpus    = 1
request_memory  = 1GB
+Deadline       = time() + 3600
queue 10

실행:

chmod +x example.sh
condor_submit job.submit
condor_q

동일 작업이 중복 제출되지 않도록 외부 작업 ID를 ClassAd에 라벨링해두는 게 좋고, OnExitRemove/OnExitHold 규칙으로 자동 재시도 정책을 걸 수 있다. 여러 풀을 연합(Federation)하려면 condor_annex나 Glidein 패턴으로 외부 자원을 흡수한다.