[HPC/GPU 클러스터 운영 Scheduling Deep Dive 4편] Job Dependency·Workflow Scheduling 심화 – Airflow/Kubeflow 통합

 

Job Dependency 관리의 필요성

 

HPC 및 GPU 클러스터에서는 단일 Job이 독립적으로 실행되는 경우보다, 여러 Job이 순차적 또는 병렬적으로 연결된 Workflow로 실행되는 경우가 훨씬 많습니다. 예를 들어 딥러닝 학습 파이프라인은 데이터 전처리 → 모델 학습 → 평가 → 배포 단계로 이어집니다. 이때 전처리가 끝나기 전에 학습 Job이 시작되면 실패하거나 잘못된 결과가 발생합니다.

 

따라서 운영자는 Job 간 의존성(Dependency)을 정의하고, 이를 기반으로 Workflow Scheduling을 설계해야 합니다. 이는 단순 스케줄링을 넘어, 전체 AI/HPC 워크플로우를 안정적으로 실행하는 핵심 요소입니다.

 

---

 

Slurm에서의 Job Dependency

 

Slurm은 기본적으로 --dependency 옵션을 통해 Job 간 의존성을 정의할 수 있습니다. 이를 활용하면 Job이 특정 Job의 성공, 실패, 완료 여부에 따라 실행되도록 제어할 수 있습니다.

# 전처리 Job 제출
jid1=$(sbatch preprocess.sh | awk '{print $4}')

# 전처리 Job이 성공하면 학습 Job 실행
sbatch --dependency=afterok:$jid1 train.sh

의존성 유형은 after, afterok, afternotok, afterany 등이 있으며, Job 종료 상태에 따라 후속 Job 실행 여부를 유연하게 조정할 수 있습니다. HPC 환경에서는 이 기능만으로도 상당수 Workflow 제어가 가능합니다.

 

---

 

Workflow Scheduler와의 통합 필요성

 

Slurm의 Job Dependency만으로는 복잡한 워크플로우(수십 단계 이상의 DAG: Directed Acyclic Graph)를 다루기 어렵습니다. 데이터 파이프라인, AI 학습, 모델 서빙까지 아우르는 워크로드를 다루려면 Workflow Orchestrator와의 통합이 필요합니다. 대표적인 툴이 Apache Airflow와 Kubeflow Pipelines입니다.

 

---

 

Airflow와 HPC의 결합

 

Airflow는 DAG 기반 Workflow Orchestrator로, Python DSL을 통해 태스크 간 의존성을 명확히 표현할 수 있습니다. HPC 환경에서는 Airflow Operator를 사용하여 Slurm Job을 호출하는 방식으로 통합합니다.

from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime

with DAG('hpc_pipeline', start_date=datetime(2024, 1, 1)) as dag:
    preprocess = BashOperator(
        task_id='preprocess',
        bash_command='sbatch preprocess.sh'
    )

    train = BashOperator(
        task_id='train',
        bash_command='sbatch --dependency=afterok:{{ ti.xcom_pull(task_ids="preprocess") }} train.sh'
    )

    preprocess >> train

이 방식은 HPC 클러스터의 Slurm 큐와 Airflow의 DAG 엔진을 결합하여, 엔드투엔드 워크플로우를 관리할 수 있게 합니다.

 

---

 

Kubeflow Pipelines와 AI Workflow

 

Kubernetes 기반 AI 워크로드에서는 **Kubeflow Pipelines(KFP)**가 사실상 표준입니다. KFP는 각 단계를 컨테이너화된 컴포넌트로 정의하고, 파이프라인 DSL로 Workflow를 구성합니다.

 

예를 들어 데이터 준비 → 학습 → 모델 평가 → 서빙 단계를 Kubeflow에서 정의하면, 각 단계가 쿠버네티스 Pod로 실행되며, 스케줄러는 Gang Scheduling/Backfilling 같은 정책과 연계할 수 있습니다.

@dsl.pipeline(name="training-pipeline")
def pipeline():
    preprocess = dsl.ContainerOp(
        name="preprocess",
        image="preprocess:latest"
    )
    train = dsl.ContainerOp(
        name="train",
        image="trainer:latest"
    )
    evaluate = dsl.ContainerOp(
        name="evaluate",
        image="evaluator:latest"
    )
    preprocess >> train >> evaluate

이 방식은 특히 클라우드 GPUaaS 환경에서 강력하며, MLOps와도 자연스럽게 연결됩니다.

 

---

 

실제 적용 사례

 

• 금융권 리스크 분석: Slurm 기반 HPC 클러스터에서 Airflow를 활용해 시뮬레이션 Job 간 순서를 관리하고, 수백 개의 결과를 병렬 처리 후 최종 리포트를 생성합니다.
• 제약 연구소 신약 개발: Kubeflow Pipelines를 통해 데이터 수집, 분자 모델링, GPU 기반 학습, 결과 검증을 자동화하여 연구 생산성을 대폭 향상시킵니다.
• AI 스타트업: 모델 실험을 대규모로 실행하면서 Airflow와 Kubeflow를 혼합 적용, 실험 관리와 프로덕션 학습 파이프라인을 분리 운영합니다.

 

---

 

장점과 단점

 

장점

 

• Job 의존성을 명확히 정의하여 워크플로우 안정성을 보장합니다.
• Airflow/Kubeflow와의 통합으로 End-to-End 파이프라인 관리가 가능합니다.
• 재현성(Reproducibility)과 자동화 수준이 높아집니다.

 

단점

 

• 추가적인 툴 운영 부담이 있습니다 (Airflow Scheduler, Kubeflow Controller 등).
• DAG 설계 복잡도가 커지면 관리 비용이 늘어납니다.
• HPC 전통 사용자에게는 학습 곡선이 존재합니다.

 

---

 

실무 팁과 주의사항

 

1. 단계별로 Dependency 관리
2. 단순 의존성은 Slurm --dependency로 처리하고, 복잡한 DAG는 Airflow/Kubeflow에 맡기는 하이브리드 전략이 효과적입니다.
3. 모니터링 연계
4. Airflow는 로그 기반, Kubeflow는 메트릭 기반 모니터링을 제공합니다. Prometheus/Grafana와 통합하면 더욱 효과적입니다.
5. 워크로드 성격에 맞는 툴 선택
6. 데이터 엔지니어링 중심이면 Airflow, AI/ML 중심이면 Kubeflow가 적합합니다.
7. Failover 전략 수립
8. Job 실패 시 재시도, 알림, 우회 실행 전략을 반드시 설정해야 운영 효율이 높아집니다.

 

---

 

정리하며

 

Job Dependency와 Workflow Scheduling은 단일 Job 운영을 넘어 전체 파이프라인의 성공을 좌우하는 핵심 역량입니다. Slurm의 기본 Dependency 기능은 단순하지만 강력하고, Airflow/Kubeflow와 결합하면 엔드투엔드 워크플로우를 안정적으로 운영할 수 있습니다. HPC와 AI 인프라가 융합되는 시대에는 이러한 Workflow Orchestration 역량이 운영 효율성과 생산성을 크게 끌어올리는 열쇠가 됩니다.