Google Kubernetes Engine의 Managed Lustre 관련 5가지 권장사항

 * 본 아티클의 원문은 2025년 09월 20일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Kubernetes Engine(GKE)은 확장 가능한 AI 및 고성능 컴퓨팅(HPC) 워크로드를 조정하기 위한 강력한 플랫폼입니다. 하지만 클러스터가 커지고 작업이 더 데이터 집약적으로 변할수록 스토리지 I/O가 병목 현상이 될 수 있습니다. 이로 인해 강력한 GPU와 TPU가 데이터를 기다리느라 유휴 상태가 되어 비용이 증가하고 혁신이 둔화될 수 있습니다.

Google Cloud Managed Lustre는 이러한 문제를 해결하기 위해 설계되었습니다. 많은 온프레미스 HPC 환경에서 이미 병렬 파일 시스템을 사용하고 있으며, Managed Lustre를 사용하면 이러한 워크로드를 클라우드로 더 쉽게 가져올 수 있습니다. 관리형 컨테이너 스토리지 인터페이스(CSI) 드라이버를 통해 Managed Lustre는 GKE 운영과 완전히 통합됩니다.

고성능 병렬 파일 시스템으로의 이전을 최적화하면 첫날부터 투자 효과를 극대화할 수 있습니다. 

배포에 앞서 Managed Lustre를 사용해야 하는 경우와 Google Cloud Storage와 같은 다른 옵션을 사용해야 하는 경우를 알아두는 것이 좋습니다. 대부분의 AI 및 ML 워크로드에는 Managed Lustre가 권장되는 솔루션입니다. 학습 및 체크포인팅처럼 지연 시간이 1밀리초 미만으로 매우 짧고 작은 파일에 대해 높은 처리량을 요구하는 시나리오에서 탁월한 성능을 발휘하므로 고가의 가속기를 최대한 활용할 수 있습니다. 반면, 데이터 보관처리 또는 대용량 파일(50MB 초과)을 다루고 지연 시간에 민감하지 않은 워크로드의 경우 Cloud Storage FUSE와 Anywhere Cache 조합이 또 다른 선택지로 고려할 수 있습니다.

초기 고객들과의 협업과 Google Cloud팀의 경험을 바탕으로 GKE에서 Managed Lustre를 최대한 활용하기 위한 5가지 권장사항을 소개합니다.

1. 데이터 지역성을 고려한 설계

성능에 민감한 애플리케이션의 경우 컴퓨팅 리소스와 스토리지가 가능한 한 가까이 있어야 하며, 특정 리전 내 동일한 영역에 있는 것이 이상적입니다. 볼륨을 동적으로 프로비저닝할 때는 StorageClass의  volumeBindingMode 파라미터가 가장 중요한 도구입니다. 이를 WaitForFirstConsumer로 설정하는 것이 좋습니다. GKE는 기본적으로 WaitForFirstConsumer 바인딩 모드를 사용하는 Managed Lustre용 내장 StorageClass를 제공합니다.

생성된 YAML:

권장하는 이유: WaitForFirstConsumer를 사용하면 이를 필요로 하는 포드가 예약될 때까지 GKE가 Lustre 인스턴스의 프로비저닝을 지연하도록 지시합니다. 그러면 스케줄러는 포드의 토폴로지 제약 조건(즉, 예약된 영역)을 사용하여 정확히 동일한 영역에 Lustre 인스턴스를 만듭니다. 이렇게 하면 스토리지와 컴퓨팅이 동일한 위치에 배치되어 네트워크 지연 시간이 최소화됩니다.

2. 성능에 맞는 등급 선택

모든 고성능 워크로드가 동일한 것은 아닙니다. Managed Lustre는 여러 성능 등급(스토리지 1TiB당 읽기 및 쓰기 처리량(Mbps))을 제공하므로 성능 요구사항에 맞춰 비용을 제어할 수 있습니다.

• 1,000 및 500Mbps/TiB: I/O 대역폭이 주된 병목 현상인 파운데이션 모델 학습 또는 대규모 물리 시뮬레이션과 같이 처리량이 중요한 워크로드에 적합합니다.

• 250Mbps/TiB: 균형 잡힌 비용 효율적인 등급으로, 많은 일반적인 HPC 워크로드와 AI 추론 서빙, 데이터 집약적인 분석 파이프라인에 적합합니다.

• 125Mbps/TiB: 최대 처리량을 달성하는 것보다 대규모의 POSIX 규격 파일 시스템을 갖추는 것이 더 중요한 대용량 사용 사례에 가장 적합합니다. 또한 컨테이너화된 온프레미스 애플리케이션을 별도의 수정 없이 마이그레이션하는 데도 유용하므로 온프레미스 워크로드를 클라우드 스토리지로 더 쉽게 마이그레이션할 수 있습니다.

권장하는 이유: 무조건 최고 등급을 선택하는 것이 항상 비용 효율적인 전략은 아닙니다. 워크로드의 I/O 프로필을 분석하면 총소유비용을 크게 최적화할 수 있습니다.

3. 네트워킹 기반 구축

병렬 파일 시스템은 네트워크로 연결되는 리소스입니다. 네트워킹을 처음부터 올바르게 설정하면 문제 해결에 드는 시간을 줄일 수 있습니다. 프로비저닝하기 전에 문서의 설정 단계를 따라 VPC가 올바르게 구성되었는지 확인하세요. 이 과정은 문서에 자세히 설명된 아래 세 가지 주요 단계로 이루어져 있습니다.

1. 서비스 네트워킹을 사용 설정합니다.

2. VPC 피어링의 IP 범위를 만듭니다.

3. Lustre 네트워크 포트(TCP 988 또는 6988)에서 해당 범위의 트래픽을 허용하도록 방화벽 규칙을 만듭니다.

권장하는 이유: VPC당 한 번만 설정하면 되는 작업으로, GKE 노드가 Managed Lustre 서비스와 통신할 수 있도록 안전한 피어링 연결이 설정됩니다.

4. 단순성을 원한다면 동적 프로비저닝을, 장기 공유 데이터에는 정적 프로비저닝을 사용

Managed Lustre CSI 드라이버는 스토리지와 GKE 워크로드를 연결하는 두 가지 모드를 지원합니다.

• 동적 프로비저닝: 스토리지가 특정 워크로드나 애플리케이션의 수명 주기가 긴밀하게 연결되어 있는 경우 사용합니다. StorageClass와 PersistentVolumeClaim(PVC)을 정의하면 GKE가 자동으로 Lustre 인스턴스 수명 주기를 관리해 줍니다. 가장 간단하고 자동화된 접근방식입니다.

• 정적 프로비저닝: 장기 Lustre 인스턴스를 여러 GKE 클러스터와 작업 간에 공유해야 하는 경우에 사용합니다. Lustre 인스턴스를 한 번 만든 후 클러스터에서 마운트하기 위해 PersistentVolume(PV)과 PVC를 만듭니다. 이렇게 하면 스토리지 수명 주기가 단일 워크로드에서 분리됩니다.

권장하는 이유: 데이터 수명 주기를 고려하면 적절한 패턴을 선택하는 데 도움이 됩니다. 단순성을 위해 기본적으로 동적 프로비저닝을 사용하고, 파일 시스템을 조직 전체에서 지속적으로 공유되는 리소스로 취급해야 하는 경우에는 정적 프로비저닝을 선택하세요.

5. Kubernetes 작업으로 병렬 처리 설계

데이터 전처리 또는 일괄 추론과 같은 많은 AI 및 HPC 작업은 병렬 실행에 적합합니다. 하나의 대규모 포드를 실행하는 대신 Kubernetes 작업 리소스를 사용하여 작업을 여러 개의 작은 포드로 나누세요.

다음 패턴을 고려하세요.

1. Managed Lustre 인스턴스에 대해 단일 PersistentVolumeClaim을 만들어 클러스터에서 사용할 수 있도록 합니다.

2. 병렬 처리 수를 높게 설정한 Kubernetes 작업을 정의합니다(예: 100).

3. 작업에서 생성된 각 포드는 동일한 Lustre PVC를 마운트합니다.

4. 애플리케이션을 설계할 때 각 포드가 데이터의 서로 다른 하위 집합(예: 서로 다른 범위의 파일 또는 데이터 청크 처리)에서 작동하도록 만듭니다.

권장하는 이유: 이 패턴에서는 Lustre 인스턴스에 대해 단일 PVC를 만들고, 작업에서 생성된 각 포드가 동일한 PVC를 마운트하도록 합니다. 각 포드가 데이터의 서로 다른 하위 집합에서 작동하도록 애플리케이션을 설계하면 GKE 클러스터를 강력한 분산 데이터 처리 엔진으로 전환할 수 있습니다. GKE 작업 컨트롤러는 병렬 작업을 조정하는 역할을 하고 Managed Lustre는 고속 데이터 백본 역할을 함으로써, 대규모 집계 처리량을 달성할 수 있습니다.

지금 시작하기

GKE의 조정 기능과 Managed Lustre의 성능을 결합하면 진정으로 확장 가능하고 효율적인 AI 및 HPC 플랫폼을 빌드할 수 있습니다. 이 권장사항을 따르면 강력하면서도 효율적이고 비용 효과적이며 관리하기 쉬운 솔루션을 만들 수 있습니다.

시작할 준비가 되셨나요? Managed Lustre 문서를 살펴보고 지금 바로 첫 번째 인스턴스를 프로비저닝하세요.