YG Tech Blog

왜 하이브리드 스케줄링이 필요한가 현대의 HPC와 AI 인프라는 단일 워크로드만 다루지 않습니다. 연구 부문에서는 MPI 기반 HPC Job이 돌아가고, AI 부문에서는 딥러닝 학습과 추론이 Kubernetes 기반 MLOps 워크플로우 위에서 운영됩니다. 이러한 환경에서 스케줄링 시스템을 이원화하면, 자원이 비효율적으로 분리되고 관리 복잡도가 급격히 증가합니다. 따라서 Slurm과 Kubernetes를 연계하는 하이브리드 Scheduling이 필요합니다. Slurm은 HPC Job 관리에 강점을 가지고, Kubernetes는 컨테이너화된 ML/서비스 워크로드 관리에 강점을 가집니다. 이를 조합하면 자원 활용률을 극대화하고, 사용자 경험을 단일화할 수 있습니다. Slurm과 Kubernetes의 역할 ..

GPU 메모리 관리가 중요한 이유 GPU 클러스터 운영에서 가장 흔히 발생하는 오류 중 하나는 Out-of-Memory(OOM) 에러입니다. 학습(Job)이나 추론(Job)이 GPU 메모리를 초과해서 사용하려 하면 Job이 강제 종료되거나 성능이 급격히 저하됩니다. 특히 대규모 모델 학습에서는 GPU 메모리 한계가 시스템 안정성에 직접적으로 영향을 주며, 추론 환경에서는 Latency 증가로 이어집니다. 따라서 GPU 스케줄링은 단순히 GPU 개수만 고려하는 것이 아니라 GPU 메모리 사용량까지 고려해야 효율적이고 안정적인 운영이 가능합니다. 이를 GPU Memory-Aware Scheduling이라고 부릅니다. GPU Memory-Aware Scheduling의 개념 GPU Memory-Aware S..

왜 Gang Scheduling이 필요한가 HPC와 대규모 GPU 클러스터에서는 단일 Job이 수십~수천 개의 노드와 GPU를 동시에 필요로 합니다. 특히 딥러닝 분산 학습(예: Transformer 기반 모델)이나 MPI(Message Passing Interface) 기반 과학 계산에서는 Job이 모든 프로세스가 동시에 시작하지 않으면 정상적으로 진행되지 않습니다. 한 노드에서만 리소스가 준비되고 다른 노드가 대기하면 전체 Job이 지연되거나 Deadlock 상태에 빠집니다. 이 문제를 해결하기 위해 Gang Scheduling과 Co-Scheduling 기법이 사용됩니다. 두 방식 모두 “여러 태스크를 하나의 그룹(Gang)으로 묶어 동시에 실행”하도록 하는 전략이지만, 접근 방식과 목적에는 차이가..

AI 인프라는 수십~수백 개의 GPU 노드로 구성된 대규모 클러스터에서 운영됩니다.이렇게 커진 인프라를 사람이 일일이 컨트롤할 수는 없습니다. 그래서 등장한 것이 바로 Cluster Manager, 즉 클러스터 운영의 두뇌입니다. 이번 글에서는 GPU 인프라의 스케줄링, 상태 모니터링, 리소스 배분을 담당하는대표적인 Cluster Manager의 개념과 종류, 실무 적용 방식까지 정리해봅니다. ✅ Cluster Manager란?항목설명정의다수의 노드와 GPU 자원을 통합적으로 관리하는 컨트롤 시스템기능노드 상태 확인, Job 스케줄링, 리소스 할당, 장애 감지목적GPU 자원 낭비 최소화 + 효율적 배치 + 자동화된 운영 ✅ 대표적인 Cluster Manager 종류이름환경특징Kubernetes컨테이너 기..

AI 인프라에서 GPU는 아주 비싼 자원입니다.그래서 어떤 노드에 어떤 워크로드를 배치할지는 비용과 성능에 매우 큰 영향을 미칩니다. 특히 Kubernetes 기반 환경에서는단순히 “돌아만 가는” 것이 아니라,자원의 물리적 위치와 상호 작용을 고려한 배치 전략이 필요합니다. 이번 글에서는 이를 가능하게 하는 Node Affinity / Anti-Affinity 개념을 정리해봅니다. ✅ 기본 개념 요약용어설명Node Affinity특정 노드에 “붙도록” 배치 (선호 또는 강제)Node Anti-Affinity특정 노드를 “피해서” 배치Pod Affinity / Anti-Affinity특정 Pod와 “같이” 또는 “떨어져서” 배치 ✅ Node Affinity의 예시affinity: nodeAffinity:..

AI 워크로드는 다음과 같은 특징이 있습니다: GPU를 쓰는 동안에는 매우 집중적으로 사용하지만끝나면 한동안 아무것도 안 함 (idle)처리량은 시점마다 급격히 변동 이런 환경에서 고정된 GPU 노드 수로 클러스터를 운영한다면? 자원 낭비비용 증가GPU 부족 시 대기 발생 따라서 AI 인프라에서는GPU-aware AutoScaler를 통해 GPU 사용량 기반으로Pod이나 노드를 자동으로 축소/확대하는 구조가 필수입니다. ✅ AutoScaler란?종류설명Horizontal Pod Autoscaler (HPA)Pod 개수를 CPU/GPU 사용률 기준으로 자동 조정Vertical Pod Autoscaler (VPA)Pod에 할당된 리소스 (limit/request)를 자동 조정Cluster Autoscaler..

👋 왜 이 주제가 중요한가? 머신러닝 워크로드가 커지고 복잡해질수록, 단순히 학습 스크립트를 실행하는 것만으로는 부족해집니다.대규모 모델 학습 환경을 안정적으로 운영하려면 다음과 같은 기능들이 오케스트레이션 플랫폼 레벨에서 기본적으로 제공되어야 합니다: 자동화 (Automation)스케일링 (Scaling)모니터링 및 관찰성 (Observability) 이번 글에서는 Slurm과 Kubernetes가 이러한 요구사항에 어떻게 대응하는지 비교해보겠습니다. 🔁 1. 자동화 – 반복 작업을 줄이고 일관성 확보하기 ✅ Kubernetes: 자동화를 위한 도구 생태계 Manifest(YAML) 기반 선언형 인프라Helm, ArgoCD 등과 연계하여 GitOps 자동 배포 가능Kubeflow, MLflow ..

👋 이 글의 목적 대규모 ML 모델을 학습하는 과정에서 가장 중요한 요소 중 하나는 **“장애 대응”과 “비용 최적화”**입니다.GPU 서버는 값비싸고, 또 종종 예기치 않게 실패하며, 한번 실패하면 모든 학습 결과가 날아갈 수 있습니다. 이번 글에서는 Slurm과 Kubernetes가 이런 상황에서 어떻게 다르게 접근하고, 어떤 구조가 어떤 문제에 더 유리한지 비교해봅니다. 💥 GPU 서버는 왜 자주 실패하는가? 📌 이유 1: GPU 밀집형 서버 구조 일반적인 GPU 서버는 1대당 4~8개의 GPU를 탑재합니다.이는 곧 하나의 하드웨어 장애가 여러 GPU를 동시에 무력화시킬 수 있음을 의미합니다. 📌 이유 2: 장시간 고부하 연산 대규모 모델 학습은 보통 수 시간에서 수 일에 걸쳐 실행됩니..

🧠 왜 오케스트레이션이 중요한가? 대규모 ML 학습은 단순히 하나의 스크립트를 실행하는 문제가 아닙니다. 다음과 같은 요소들이 복합적으로 얽혀 있습니다: 수십 개의 GPU 자원 스케줄링분산 학습을 위한 노드 간 통신체크포인팅과 장애 대응클러스터 자원의 모니터링 및 자동화리소스 낭비 없이 고성능을 끌어내는 최적화 이러한 요구사항을 수작업으로 관리하는 것은 사실상 불가능하며,결국 자동화된 오케스트레이션 플랫폼 없이는 효율적이고 신뢰성 있는 ML 운영이 어려워집니다. 🧩 Slurm vs Kubernetes – 개요 🔷 Slurm: HPC의 전통 강자 원래는 슈퍼컴퓨터 및 연구기관의 배치 스케줄러로 시작현재도 Top500 슈퍼컴퓨터의 절반 이상이 Slurm 사용GPU, CPU, 메모리 등 정적인 리소스..

이 글에서는 쿠버네티스 Secret을 활용하여 MinIO의 민감한 자격 증명 정보를 안전하게 관리하는 방법에 대해 알아보겠습니다. 보안 모범 사례와 함께 실제 구현 방법을 상세히 설명합니다.📌 쿠버네티스 Secret 개념 이해하기✅ Secret이란 무엇인가?Secret은 비밀번호, API 키, 인증서와 같은 민감한 정보를 저장하기 위한 쿠버네티스 리소스입니다. ConfigMap과 유사하지만 보안에 중점을 둔 리소스입니다.▶️ Secret의 주요 특징:민감 데이터를 저장하도록 설계됨Base64 인코딩으로 저장 (암호화는 아님)etcd에 저장될 때 암호화 가능 (추가 구성 필요)메모리에만 마운트 가능 (tmpfs)Pod 간 공유 제한 가능apiVersion: v1 # 핵심 ..