Cloud Storage FUSE로 AI 및 ML 워크로드 최적화

Last reviewed 2025-08-22 UTC

이 문서에서는 Cloud Storage FUSE를 사용하여 Google Kubernetes Engine(GKE)에서 AI 및 ML 워크로드의 성능을 최적화하는 방법을 보여주는 참조 아키텍처를 제공합니다.

이 문서의 주요 대상은 Google Cloud에서 AI 및 ML 워크로드를 위한 스토리지를 설계, 프로비저닝, 관리하는 설계자와 기술 실무자를 포함합니다. 이 문서에서는 사용자가 ML 수명 주기, 프로세스, 기능을 이해하고 있다고 가정합니다.

Cloud Storage FUSE는 Cloud Storage 버킷을 로컬 파일 시스템으로 마운트할 수 있는 오픈소스 FUSE 어댑터입니다. 이 구성을 사용하면 애플리케이션이 표준 파일 시스템 시맨틱스를 사용하여 클라우드 기반 스토리지 버킷과 원활하게 상호작용할 수 있습니다. Cloud Storage FUSE를 사용하면 Cloud Storage의 확장성과 비용 효율성을 활용할 수 있습니다.

아키텍처

성능, 가용성, 재해 복구(DR)에 대한 요구사항에 따라 Google Cloud에서 AI 및 ML 워크로드를 실행하기 위해 다음 Google Cloud배포 원형 중 하나를 선택할 수 있습니다.

  • 리전별: 애플리케이션이 단일Google Cloud 리전 내에서 독립적으로 실행됩니다. 이 배포 원형은 미션 크리티컬하지는 않지만 영역 중단에 대해 견고성이 필요한 애플리케이션에 권장됩니다
  • 멀티 리전: 애플리케이션이 두 개 이상의 Google Cloud 리전에 걸쳐 독립적으로 실행되며, 활성-활성 또는 활성-수동 모드로 운영될 수 있습니다. 이 배포 원형은 DR 시나리오를 지원하는 데 이상적입니다. 리전 중단 및 재해에 대한 복원력이 필요한 미션 크리티컬 애플리케이션에 이 배포 원형을 사용하는 것이 좋습니다. 이중 또는 멀티 리전 배포는 리소스를 더 가까운 위치에서 제공할 수 있어 지연 시간을 줄이고 처리량을 개선할 수 있습니다.

선택한 배포 원형은 아키텍처에 필요한 Google Cloud 제품 및 기능에 영향을 줍니다. 멀티 리전 아키텍처는 Anywhere Cache를 사용하여 네트워크 대역폭을 늘리고 리전 버킷에 비해 지연 시간이 짧은 영역 캐시 적중을 제공합니다. Anywhere Cache는 일반적으로 모든 워크로드에 권장되며 멀티 리전 버킷과 함께 사용하면 데이터 전송 요금이 발생하지 않습니다. 워크로드에 Anywhere Cache가 적합한지 평가하려면 Anywhere Cache 추천자를 사용하여 데이터 사용량과 스토리지를 분석하세요.

다음 탭에서는 리전 및 멀티 리전 배포 원형의 참조 아키텍처를 제공합니다.

리전

다음 다이어그램은 Cloud Storage FUSE를 사용하여 모델 학습 및 모델 서빙 워크플로의 성능을 최적화하는 샘플 리전 아키텍처를 보여줍니다.

Cloud Storage FUSE를 사용하여 AI 및 ML 워크로드를 최적화하는 리전 아키텍처입니다.

이 아키텍처에는 다음 구성요소가 포함됩니다.

  • GKE 클러스터: GKE는 AI 및 ML 모델 학습과 서빙 프로세스가 실행되는 컴퓨팅 노드를 관리합니다. GKE는 컨트롤 플레인, 노드, 모든 시스템 구성요소를 비롯한 Kubernetes 클러스터의 기본 인프라를 관리합니다.
  • Kubernetes 스케줄러: GKE 컨트롤 플레인은 워크로드를 예약하고 워크로드의 수명 주기, 확장, 업그레이드를 관리합니다. 다이어그램에는 표시되지 않았지만, Kubernetes 노드 에이전트(kubelet)는 컨트롤 플레인과 통신합니다. kubelet 에이전트는 GKE 노드에 예약된 컨테이너를 시작하고 실행합니다. 스케줄러에 대한 자세한 내용은 GKE의 AI/ML 조정을 참조하세요.
  • 가상 프라이빗 클라우드 (VPC) 네트워크: 아키텍처의 모든 Google Cloud리소스는 단일 VPC 네트워크를 사용합니다. 요구사항에 따라 여러 네트워크를 사용하는 아키텍처를 빌드할 수 있습니다. Cloud Storage FUSE용 VPC 네트워크 구성에 대한 자세한 내용은 여러 VPC 네트워크 생성 여부 결정을 참조하세요.
  • Cloud Load Balancing: 이 아키텍처에서 Cloud Load Balancing은 애플리케이션 사용자의 들어오는 추론 요청을 GKE 클러스터의 제공 컨테이너에 효율적으로 분산합니다. 자세한 내용은 GKE 부하 분산 이해하기를 참조하세요.
  • 그래픽 처리 장치(GPU) 또는 Tensor Processing Unit(TPU): GPU와 TPU는 AI 및 ML 워크로드의 성능을 향상시키는 특수 머신 가속기입니다. 적절한 프로세서 유형을 선택하는 방법에 대한 자세한 내용은 이 문서 뒷부분의 가속기 옵션을 참조하세요.
  • Cloud Storage: Cloud Storage는 AI 및 ML 워크로드를 위한 영구적이고 확장 가능하며 비용 효율적인 스토리지를 제공합니다. Cloud Storage는 원시 학습 데이터 세트, 모델 체크포인트, 최종 학습된 모델을 위한 중앙 저장소 역할을 합니다.
  • 파일 캐시가 사용 설정된 Cloud Storage FUSE: Cloud Storage FUSE를 사용하면 Cloud Storage 버킷을 로컬 파일 시스템으로 마운트할 수 있습니다. Cloud Storage FUSE의 파일 캐시는 Cloud Storage 버킷에서 자주 액세스하는 파일을 저장하는 로컬 머신의 디렉터리입니다. Cloud Storage FUSE CSI 드라이버는 Cloud Storage FUSE 및 Kubernetes API의 통합을 관리하여 Cloud Storage 버킷을 볼륨으로 사용합니다.

다음 섹션에서는 아키텍처의 학습 및 서빙 워크로드의 워크플로에 대해 설명합니다.

멀티 리전

다음 다이어그램은 Cloud Storage FUSE와 Anywhere Cache를 사용하여 모델 학습 및 모델 서빙 워크플로의 성능을 최적화하는 샘플 멀티 리전 아키텍처를 보여줍니다.

Cloud Storage FUSE를 사용하여 AI 및 ML 워크로드를 최적화하는 멀티 리전 아키텍처입니다.

이 아키텍처에는 다음 구성요소가 포함됩니다.

  • GKE 클러스터: GKE는 AI 및 ML 모델 학습과 서빙 프로세스가 실행되는 컴퓨팅 노드를 관리합니다. GKE는 컨트롤 플레인, 노드, 모든 시스템 구성요소를 비롯한 Kubernetes 클러스터의 기본 인프라를 관리합니다.
  • Kubernetes 스케줄러: GKE 컨트롤 플레인은 워크로드를 예약하고 워크로드의 수명 주기, 확장, 업그레이드를 관리합니다. 다이어그램에는 표시되지 않았지만, Kubernetes 노드 에이전트(kubelet)는 컨트롤 플레인과 통신합니다. kubelet 에이전트는 GKE 노드에 예약된 컨테이너를 시작하고 실행합니다. 스케줄러에 대한 자세한 내용은 GKE의 AI/ML 조정을 참조하세요.
  • 가상 프라이빗 클라우드 (VPC) 네트워크: 아키텍처의 모든 Google Cloud리소스는 단일 VPC 네트워크를 사용합니다. 요구사항에 따라 여러 네트워크를 사용하는 아키텍처를 빌드할 수 있습니다. Cloud Storage FUSE용 VPC 네트워크 구성에 대한 자세한 내용은 여러 VPC 네트워크 생성 여부 결정을 참조하세요.
  • Cloud DNS: 멀티 리전 아키텍처에서 Cloud DNS는 애니캐스트 라우팅을 통해 최적의 성능과 가용성을 보장하기 위해 트래픽을 부하 분산기로 안내합니다. 요청은 자동으로 가장 가까운 위치로 라우팅되며, 이로 인해 지연 시간이 줄어들고 사용자에게 제공되는 권한 있는 이름 조회 성능이 향상됩니다. 일반적인 원칙과 권장사항에 관한 자세한 내용은 Cloud DNS 권장사항을 참조하세요.
  • Cloud Load Balancing: 이 아키텍처에서 Cloud Load Balancing은 애플리케이션 사용자로부터 들어오는 추론 요청을 GKE 클러스터의 서빙 컨테이너로 효율적으로 분산합니다. 자세한 내용은 GKE 부하 분산 이해하기를 참조하세요.
  • 그래픽 처리 장치(GPU) 또는 Tensor Processing Unit(TPU): GPU와 TPU는 AI 및 ML 워크로드의 성능을 향상시키는 특수 머신 가속기입니다. 적절한 프로세서 유형을 선택하는 방법에 대한 자세한 내용은 이 문서 뒷부분의 가속기 옵션을 참조하세요.
  • Cloud Storage: Cloud Storage는 AI 및 ML 워크로드를 위한 영구적이고 확장 가능하며 비용 효율적인 스토리지를 제공합니다. Cloud Storage는 원시 학습 데이터 세트, 모델 체크포인트, 최종 학습된 모델을 위한 중앙 저장소 역할을 합니다.
  • Cloud Storage FUSE: Cloud Storage FUSE를 사용하면 Cloud Storage 버킷을 로컬 파일 시스템으로 마운트할 수 있습니다. 다이어그램에는 표시되지 않았지만 Cloud Storage FUSE CSI 드라이버는 Cloud Storage 버킷을 볼륨으로 사용할 수 있도록 Cloud Storage FUSE와 Kubernetes API의 통합을 관리합니다.
  • Anywhere Cache: Anywhere Cache는 Cloud Storage 버킷을 위해 최대 1PiB의 SSD 기반의 영역별 읽기 전용 캐시를 제공하는 Cloud Storage 기능입니다. 학습 및 서빙 과정에서 Anywhere Cache는 캐시 용량과 대역폭을 확장하여 읽기 지연 시간을 줄이고 2TB/s를 초과하는 처리량을 달성하도록 지원합니다. 멀티 리전 버킷과 결합하면 Anywhere Cache를 여러 영역과 여러 리전에서 사용할 수 있습니다. 지원되는 리전 및 영역에 대한 자세한 내용은 지원되는 위치를 참고하세요.

다음 섹션에서는 아키텍처의 학습 및 서빙 워크로드의 워크플로에 대해 설명합니다.

학습 워크로드

앞서 설명한 아키텍처에서 모델 학습 중 데이터 흐름의 단계는 다음과 같습니다.

  1. Cloud Storage에 학습 데이터 로드: 학습 데이터는 계층적 네임스페이스가 사용 설정된 Cloud Storage 버킷에 업로드됩니다. Cloud Storage는 확장 가능한 중앙 저장소 역할을 합니다.
  2. 학습 데이터를 로드하고 GKE에서 학습 작업 실행: GKE 포드에 마운트된 Cloud Storage 버킷을 통해 학습 애플리케이션은 FUSE 인터페이스를 사용하여 학습 데이터를 효율적으로 로드하고 액세스할 수 있습니다. GKE 노드는 마운트된 파일 캐시를 데이터 소스로 사용하여 모델 학습 프로세스를 실행합니다. 학습 애플리케이션은 모델 학습에 필요한 복잡한 계산을 수행하기 위해 머신 가속기에 학습 데이터를 지속적으로 공급합니다. 워크로드 요구사항에 따라 GPU 또는 TPU를 사용할 수 있습니다. 적절한 프로세서 유형을 선택하는 방법에 대한 자세한 내용은 이 문서 뒷부분의 가속기 옵션을 참조하세요.
  3. 체크포인트 및 모델 저장/복원:

    • 체크포인트 또는 모델 저장: 학습 중에는 별도의 Cloud Storage 버킷에 비동기적으로 자주 체크포인트를 저장합니다. 체크포인트는 정의한 측정항목 또는 간격에 따라 모델 상태를 캡처합니다.
    • 체크포인트 또는 모델 복원: 학습 워크로드에서 체크포인트 또는 모델 데이터를 복원해야 하는 경우 Cloud Storage에서 복원할 애셋을 찾아야 합니다. 복원된 체크포인트 또는 모델을 사용하여 학습을 재개하거나, 파라미터를 미세 조정하거나, 검증 세트에서 성능을 평가할 수 있습니다.

서빙 워크로드

앞서 설명한 아키텍처에서 모델 서빙 중 데이터 흐름의 단계는 다음과 같습니다.

  1. 모델 로드: 학습이 완료되면 포드가 병렬 다운로드가 사용 설정된 Cloud Storage FUSE를 사용하여 학습된 모델을 로드합니다. 병렬 다운로드는 Cloud Storage에서 모델의 여러 부분을 병렬로 가져와 모델 로드 속도를 가속화합니다. 모델 로드 시간을 크게 줄이기 위해 이 과정에서는 캐시 디렉터리를 미리 가져오기 버퍼로 사용합니다.
  2. 추론 요청: 애플리케이션 사용자가 Cloud Load Balancing 서비스를 통해 AI 및 ML 애플리케이션에서 추론 요청을 전송합니다. Cloud Load Balancing은 들어오는 요청을 GKE 클러스터의 서빙 컨테이너 전반에 분산합니다. 이 분산 처리는 특정 컨테이너에 과부하가 걸리지 않도록 하며, 요청이 효율적으로 처리되도록 보장합니다.
  3. 대답 제공: 노드가 요청을 처리하고 예측을 생성합니다. 서빙 컨테이너는 응답을 Cloud Load Balancing을 통해 다시 전달하고, 이후 애플리케이션 사용자에게 응답이 반환됩니다

사용 제품

참조 아키텍처에는 다음과 같은 Google Cloud 제품이 사용됩니다.

  • Google Kubernetes Engine(GKE): Google 인프라를 사용하여 컨테이너화된 애플리케이션을 대규모로 배포 및 운영하는 데 사용할 수 있는 Kubernetes 서비스입니다.
  • Cloud Storage: 다양한 데이터 유형에 적합한 저비용, 무제한 객체 스토어입니다. Google Cloud내부 및 외부에서 데이터에 액세스할 수 있고 중복성을 위해 여러 위치에 복제됩니다.
  • 가상 프라이빗 클라우드(VPC): Google Cloud 워크로드에 확장 가능한 전역 네트워킹 기능을 제공하는 가상 시스템입니다. VPC에는 VPC 네트워크 피어링, Private Service Connect, 비공개 서비스 액세스, 공유 VPC가 포함됩니다.
  • Cloud Load Balancing: 확장 가능한 고성능 전역 및 리전 부하 분산기 포트폴리오입니다.
  • Cloud DNS: Google의 전 세계 네트워크를 기반으로 복원력이 우수하고 지연 시간이 짧은 DNS 서비스를 제공하는 서비스입니다.

사용 사례

대규모 스토리지 용량과 고성능 파일 액세스가 필요한 AI 및 ML 워크로드의 경우 Cloud Storage FUSE를 중심으로 구축된 아키텍처를 사용하는 것이 좋습니다. 적절히 계획하면 이러한 아키텍처를 통해 1TB/s를 초과하는 처리량을 달성할 수 있습니다. 또한 Cloud Storage FUSE를 사용하면 AI 및 ML 워크플로의 모든 단계에 대해 단일 정보 소스 역할을 하는 중앙 스토리지 저장소를 활용할 수 있습니다. 이 접근 방식은 규모나 크기에 관계없이 모든 워크로드에 사용할 수 있습니다.

이러한 워크로드의 경우 Cloud Storage FUSE는 다음과 같은 이점을 제공합니다.

  • 간소화된 데이터 액세스: Connector for PyTorch, JAX, TensorFlow 같은 AI 및 ML 프레임워크를 통해 학습 데이터와 체크포인트에 액세스할 수 있습니다. AI 및 ML 프레임워크를 통한 데이터 액세스로 인해 코드 리팩터링이 필요하지 않습니다.
  • 가속화된 시작 속도: Cloud Storage FUSE를 사용하여 Cloud Storage의 데이터에 직접 액세스함으로써 대규모 데이터 세트를 컴퓨팅 리소스로 다운로드할 필요가 없습니다. 이렇게 데이터에 직접 액세스하여 작업 시작 시간이 빨라집니다.
  • 비용 효율성: Cloud Storage의 고유한 확장성과 비용 효율성을 활용하여 비용을 최적화할 수 있습니다.

Cloud Storage FUSE는 50MB 미만의 파일이 포함된 워크로드나 임의 I/O 및 메타데이터 액세스에 1밀리초 미만의 지연 시간이 필요한 지연 시간에 민감한 워크로드에는 적합하지 않습니다.

데이터 집약적인 학습이나 체크포인트 및 다시 시작 워크로드의 경우 I/O 집약적인 학습 단계에서는 다른 스토리지 대안을 고려해야 합니다.

설계 대안

다음 섹션에서는 Google Cloud에서 AI 및 ML 애플리케이션에 대해 고려할 수 있는 대안 설계 접근 방식을 보여줍니다.

플랫폼 대안

모델 학습 및 서빙 워크플로를 GKE에서 호스팅하는 대신 Compute EngineSlurm을 고려할 수 있습니다. Slurm은 구성 가능성이 높고 오픈소스로 제공되는 워크로드 및 리소스 관리자입니다. Compute Engine과 Slurm을 함께 사용하는 것은 대규모 모델 학습과 시뮬레이션에 특히 적합합니다. 독점적인 AI 및 ML 지식 재산(IP)을 확장 가능한 환경에 통합하면서, 특수 워크로드 성능을 최적화할 수 있는 유연성과 제어 기능이 필요하다면 Compute Engine과 함께 Slurm을 사용하는 것이 좋습니다. Compute Engine과 Slurm 사용 방법에 대한 자세한 내용은 Slurm을 사용하여 HPC 클러스터 배포를 참조하세요.

Compute Engine에서는 가상 머신(VM)을 프로비저닝하고 관리할 수 있으며, 이를 통해 인스턴스 유형, 스토리지, 네트워킹을 세부적으로 제어할 수 있습니다. 특정 VM 머신 유형 선택을 포함해 인프라를 정확한 요구사항에 맞게 조정할 수 있습니다 Compute Engine에서 Cloud Storage FUSE 명령줄 옵션을 사용하는 방법에 대한 자세한 내용은 gcsfuse CLICloud Storage FUSE 구성 파일을 참조하세요. 또한 AI 및 ML 워크로드의 성능을 향상시키기 위해 가속기 최적화 머신 계열을 사용할 수도 있습니다. Compute Engine에서 제공되는 머신 유형 제품군에 대한 자세한 내용은 머신 계열 리소스 및 비교 가이드를 참조하세요.

Slurm은 AI 및 ML 워크로드를 관리하기 위한 강력한 옵션을 제공하며, 컴퓨팅 리소스의 구성과 관리를 직접 제어할 수 있습니다. 이 방식을 사용하려면 Slurm 관리 및 Linux 시스템 관리에 대한 전문 지식이 필요합니다.

가속기 옵션

머신 가속기는 AI 및 ML 워크로드에 필요한 연산을 속도를 높이도록 설계된 특수 프로세서입니다. GPU 또는 TPU 중에서 선택할 수 있습니다.

  • GPU 가속기는 그래픽 렌더링, 딥 러닝 학습, 과학 컴퓨팅 등 다양한 작업에서 뛰어난 성능을 제공합니다. Google Cloud 는 다양한 성능과 가격대에 맞는 광범위한 GPU 옵션을 제공합니다. GPU에는 종종 각 머신 구성에 로컬 SSD를 포함하며, 이 SSD는 Cloud Storage FUSE의 캐시 디렉터리로 사용할 수 있습니다. GPU 모델과 가격에 대한 자세한 내용은 GPU 가격 책정을 참조하세요.
  • TPU는 대규모 AI 모델의 학습과 추론에 최적화된 커스텀 설계된 AI 가속기입니다. 챗봇, 코드 생성, 미디어 콘텐츠 생성, 합성 음성, 비전 서비스, 추천 엔진, 맞춤설정 모델 등 다양한 사용 사례에 적합합니다. TPU 모델과 가격 책정에 대한 자세한 내용은 TPU 가격 책정을 참조하세요.

스토리지 대안

Cloud Storage FUSE는 Cloud Storage의 확장성과 비용 효율성을 활용할 수 있는 편리한 파일 시스템을 제공합니다. 하지만 Cloud Storage FUSE는 작은 파일 읽기에 짧은 지연 시간이 요구되는 워크로드나 완전한 POSIX 호환 스토리지 솔루션이 필요한 워크로드에는 적합하지 않습니다. 이러한 사용 사례의 경우 다음과 같은 스토리지 대안을 고려하는 것이 좋습니다.

  • Google Cloud Managed Lustre: DDN의 EXAScaler Lustre를 기반으로 하는 완전 Google Cloud관리형 영구 병렬 파일 시스템 (PFS)입니다. Managed Lustre는 AI 워크로드 학습 및 체크포인트에 권장되는 기본 솔루션입니다. Lustre 또는 기타 PFS 솔루션에서 기존 워크로드를 마이그레이션하는 데 특히 효과적입니다. 체크포인트 생성 중에 성능을 높이려면 관리형 Lustre를 사용하여 Anywhere Cache로 Cloud Storage FUSE를 보강하는 것이 좋습니다. 자세한 내용은 Google Cloud Managed Lustre로 AI 및 ML 워크로드 최적화를 참고하세요.
  • Connector for PyTorch: Cloud Storage의 오픈소스 제품으로, PyTorch를 사용하는 워크로드에 적합합니다. Connector for PyTorch는 Cloud Storage 버킷에서 데이터를 직접 스트리밍하여 학습 워크로드를 최적화하며, 중간 스토리지가 필요하지 않습니다. 이러한 직접 액세스와 최적화를 통해 데이터 로딩, 학습, 체크포인트 작업에서 Cloud Storage에 대한 직접 API 호출보다 훨씬 뛰어난 성능을 제공합니다.

일부 AI 및 ML 워크로드에서는 대안 스토리지 옵션이 성능상의 이점을 제공할 수 있지만, 지연 시간, 처리량, 스토리지 용량에 대한 요구사항을 평가하는 것이 중요합니다.

AI 및 ML 워크로드용 스토리지 옵션을 종합적으로 비교한 내용은 Google Cloud에서 AI 및 ML 워크로드를 위한 스토리지 설계를 참조하세요.

설계 고려사항

이 섹션에서는 보안, 안정성, 비용, 성능 측면에서 Cloud Storage FUSE를 구성할 때의 권장사항과 설계 고려사항을 안내합니다. 여기서 제시하는 권장사항은 모두를 망라한 것은 아니지만, Cloud Storage FUSE를 환경에서 최대한 활용하는 데 필요한 핵심 고려사항을 다룹니다. 특정 요구사항과 워크로드 특성에 따라 추가적인 구성 옵션과 균형점을 고려해야 할 수도 있습니다.

다음 설계 권장사항은 GKE에서 Cloud Storage FUSE를 배포하는 방식을 최적화할 수 있는 구성을 강조합니다. 대부분의 Cloud Storage FUSE 옵션은 마운트 옵션으로 구성됩니다. Cloud Storage FUSE 명령줄 옵션 및 사용 방법에 대한 자세한 내용은 gcsfuse CLIGKE 성능을 위한 Cloud Storage FUSE CSI 드라이버 최적화를 참조하세요.

Google Cloud에서 AI 및 ML 워크로드와 관련된 아키텍처 원칙 및 권장사항에 대한 개요는 Well-Architected Framework의 AI 및 ML 관점을 참조하세요.

보안, 개인 정보 보호, 규정 준수

이 섹션에서는 Google Cloud 에서 보안, 개인 정보 보호, 규정 준수 요구사항을 충족하는 AI 및 ML 워크로드에 대한 고려사항을 설명합니다.

GKE 고려사항

Autopilot 모드의 작업에서는 GKE가 클러스터를 사전 구성하고 보안 권장사항에 따라 노드를 관리하므로 워크로드별 보안에 집중할 수 있습니다. 자세한 내용은 다음을 참조하세요.

GKE에서 실행되는 애플리케이션의 액세스 제어를 강화하려면 IAP(Identity-Aware Proxy)를 사용하면 됩니다. IAP는 GKE 인그레스 리소스와 통합되며 올바른 Identity and Access Management(IAM) 역할을 가진 인증된 사용자만 애플리케이션에 액세스할 수 있도록 합니다. 자세한 내용은 GKE에 IAP 사용 설정을 참조하세요.

기본적으로 GKE의 데이터는 Google-owned and Google-managed encryption keys를 사용하여 저장 상태전송 중 상태 모두 암호화됩니다. 민감한 정보에 대한 추가 보안 계층으로서 Cloud Key Management Service(Cloud KMS)에서 사용자가 소유하고 관리하는 키를 사용하여 애플리케이션 계층의 데이터를 암호화할 수 있습니다. 자세한 내용은 애플리케이션 계층의 보안 비밀 암호화를 참조하세요.

표준 GKE 클러스터를 사용하는 경우 다음과 같은 추가 데이터 암호화 기능을 사용할 수 있습니다.

Cloud Storage 고려사항

기본적으로 Cloud Storage에 저장되는 데이터는 Google-owned and Google-managed encryption keys를 사용하여 암호화됩니다. 필요한 경우 고객 관리 암호화 키(CMEK) 또는 고객 제공 암호화 키(CSEK) 같은 외부 관리 방법을 사용하여 직접 관리하는 자체 키로 데이터를 암호화할 수 있습니다. 자세한 내용은 데이터 암호화 옵션을 참조하세요.

Cloud Storage는 버킷과 객체에 액세스할 수 있는 권한을 사용자에게 부여하기 위해 IAM 및 액세스 제어 목록(ACL)의 두 가지 방법을 지원합니다. 대부분의 경우 버킷 및 프로젝트 수준에서 권한을 부여할 수 있는 IAM을 사용하는 것이 좋습니다. 자세한 내용은 액세스 제어 개요를 참조하세요.

Cloud Storage를 통해 로드하는 학습 데이터에는 민감한 정보가 포함될 수 있습니다. 이러한 데이터를 보호하기 위해서는 Sensitive Data Protection을 사용하여 데이터를 검색, 분류, 익명화할 수 있습니다. 학습 워크로드와 서빙 워크로드를 분리하려면 모델과 체크포인트를 별도의 Cloud Storage 버킷에 저장하세요. 이렇게 분리하면 서빙 중 학습 데이터 세트의 민감한 정보가 실수로 노출되는 것을 방지할 수 있습니다. 자세한 내용은 Cloud Storage에 Sensitive Data Protection 사용을 참조하세요.

데이터 상주 요구사항이 있는 경우 Cloud Storage를 사용해 해당 요구사항을 충족할 수 있습니다. 데이터는 사용자가 지정한 리전 내에 저장 또는 복제됩니다.

Cloud Storage FUSE 고려사항

캐싱을 사용 설정하면 Cloud Storage FUSE는 지정한 디렉터리 내에 Cloud Storage 버킷의 지속성 있는 파일을 암호화되지 않은 형식으로 저장합니다. Cloud Storage는 해당 디렉터리에 액세스할 수 있는 모든 사용자나 프로세스에 모든 파일을 노출합니다. 이러한 위험을 완화하고 보안을 강화하기 위해 FUSE 커널 계층은 파일 시스템 액세스를 시스템을 마운트한 사용자로 제한합니다 이 제한은 아이노드 권한이 더 허용적인 경우에도 루트 사용자를 포함한 다른 사용자들의 액세스를 거부합니다.

하지만 기본 액세스 제한보다 우선 적용되어야 하는 사용 사례도 있습니다. 예를 들어 여러 노드가 Cloud Storage에 저장된 체크포인트에 액세스하고 이를 공유해야 하는 분산 AI 및 ML 학습 워크로드에서는 더 광범위한 액세스 권한이 필요할 수 있습니다. 이러한 경우 -o allow_other 옵션을 사용하여 기본 제한보다 우선 적용되도록 수 있습니다. 하지만 파일에 대한 액세스를 확대하면 승인되지 않은 사용자에게 데이터가 노출될 가능성이 있습니다. 따라서 이 옵션을 사용할 때는 주의해야 합니다.

기본적으로 Cloud Storage FUSE 파일 시스템의 모든 아이노드는 파일 시스템을 마운트한 사용자에게 소유권이 부여됩니다. 이러한 기본값이 많은 경우에 적합할 수 있지만 포드에 대해 보안 컨텍스트를 맞춤설정할 수도 있습니다. 보안 컨텍스트 맞춤설정에 대한 자세한 내용은 보안 및 권한을 참조하세요.

기타 보안 고려사항

AI 및 ML 워크로드와 관련된 보안 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 보안을 참조하세요.

안정성

안정적인 동작을 보장하기 위해 Cloud Storage FUSE는 잠재적인 중단을 처리하고 데이터 일관성을 유지하기 위해 자동 재시도 기능을 포함합니다. 실패한 요청은 Cloud Storage로 지수 백오프 방식으로 자동 재시도됩니다. 지수 백오프는 재시도 간의 시간을 점진적으로 늘려가는 방식입니다. 이러한 기본 제공 메커니즘은 애플리케이션이 일시적인 네트워크 문제나 Cloud Storage의 임시적인 가용성 저하를 극복하는 데 도움이 됩니다.

Cloud Storage FUSE는 많은 장점을 제공하지만 다음 사항을 고려해야 합니다.

  • 동시 쓰기: 여러 사용자가 파일을 수정하려고 하면 마지막 쓰기 우선 작업이 우선 적용되고 이전의 모든 쓰기 작업은 손실됩니다. 데이터 무결성을 유지하려면 하나의 객체에 대해 어느 시점이든 하나의 소스만 이를 수정하도록 하는 것이 좋습니다.
  • 캐시 지속성: 버킷을 마운트 해제하거나 다시 시작하면 캐시는 유지되지 않습니다. 잠재적인 보안 문제를 방지하기 위해 버킷을 마운트 해제하거나 다시 시작한 후에는 반드시 파일 캐시 디렉터리를 수동으로 삭제해야 합니다.
  • 프로세스별 캐시: Cloud Storage FUSE는 효율적인 병렬 처리를 위한 동시 액세스를 지원하지만 캐시는 각 Cloud Storage FUSE 프로세스에 특정됩니다. 따라서 동일하거나 다른 머신에서 실행되는 여러 Cloud Storage FUSE 프로세스가 동일한 캐시 디렉터리를 사용해서는 안 됩니다.

기타 안정성 고려사항

AI 및 ML 워크로드와 관련된 안정성 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 안정성을 참조하세요.

비용 최적화

이 섹션에서는 Google Cloud에서 AI 및 ML 워크플로를 설정하고 운영할 때 비용을 최적화할 수 있게 도와주는 가이드를 제공합니다.

GKE 고려사항

Autopilot 모드에서 GKE는 워크로드 요구사항에 따라 클러스터 인프라의 효율성을 최적화합니다. 비용을 제어하기 위해 리소스 사용량을 지속적으로 모니터링하거나 용량을 관리할 필요가 없습니다.

Autopilot 클러스터의 CPU, 메모리, 임시 스토리지 사용량을 예측할 수 있다면 약정 사용 할인을 받을 수 있습니다. 애플리케이션 실행 비용을 줄이려면 GKE 노드에 스팟 VM을 사용하면 됩니다. 스팟 VM은 표준 VM보다 가격이 저렴하지만 가용성이 보장되지 않습니다.

효율적인 관리를 통해 비용과 성능 최적화를 위해 동적 워크로드 스케줄러를 사용하세요. 동적 워크로드 스케줄러는 리소스 관리 및 작업 스케줄러로, AI 및 ML 리소스에 대한 액세스를 개선합니다. 동적 워크로드 스케줄러는 모든 가속기를 동시에 예약하고, 사전에 정의된 가속기 용량 관리 정책과 함께 비사용 시간에 실행될 수 있습니다. 전략적으로 작업을 예약함으로써, 동적 워크로드 스케줄러는 가속기 활용도를 극대화하고 유휴 시간을 줄이며, 궁극적으로 클라우드 비용을 최적화하는 데 도움이 됩니다.

비용 최적화 가이드에 대한 자세한 내용은 GKE에서 비용 최적화된 Kubernetes 애플리케이션 실행 권장사항을 참조하세요.

Cloud Storage 고려사항

AI 및 ML 워크로드의 스토리지 요구사항은 동적으로 변할 수 있습니다. 예를 들어 학습 데이터에는 상당한 스토리지 용량이 필요할 수 있지만 서빙 단계에서는 주로 모델 데이터와 체크포인트를 저장하기 때문에 용량 요구가 줄어듭니다. 비용을 제어하기 위해서는 객체 수명 주기 관리자동 클래스를 사용 설정하는 것이 좋습니다.

객체 수명 주기 관리를 사용하면 사용자가 설정한 규칙에 따라 오래되거나 사용하지 않는 데이터를 더 저렴한 스토리지 클래스로 자동 이동하거나, 심지어 삭제할 수도 있습니다.

자동 클래스 기능은 데이터 액세스 패턴에 따라 데이터를 스토리지 클래스 간에 자동으로 이동시킵니다. 이 기능은 성능과 비용 간의 최적 균형을 보장합니다.

Cloud Storage FUSE 고려사항

FUSE 활동으로 인해 발생하는 스토리지, 메타데이터 작업, 네트워크 트래픽에는 표준 Cloud Storage 요금이 적용됩니다. Cloud Storage FUSE 자체 사용에는 추가 비용이 발생하지 않습니다. 일반적인 Cloud Storage FUSE 작업과 Cloud Storage 작업에 대한 매핑 방법에 대한 자세한 내용은 작업 매핑을 참조하세요.

캐시 디렉터리 비용을 최적화하려면 프로비저닝된 기존 머신 용량(예: 로컬 SSD, 영구 디스크, 임시 파일 시스템용 인메모리 데이터)을 활용할 수 있습니다. 기존 머신 용량을 활용하면 추가 스토리지 리소스에 대한 요금을 피할 수 있습니다. 또한 캐시 적중을 최대화하면 로컬에서 제공되는 데이터에는 작업 요금이나 데이터 전송 요금이 발생하지 않으므로 Cloud Storage 비용을 크게 절감할 수 있습니다.

요금에 대한 자세한 내용은 Cloud Storage 가격 책정을 참조하세요.

기타 비용 고려사항

AI 및 ML 워크로드와 관련된 비용 최적화 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 비용 최적화를 참조하세요.

성능 최적화

Cloud Storage FUSE는 AI 및 ML 워크로드를 위해 Cloud Storage 데이터에 효율적으로 액세스할 수 있도록 설계되었습니다. 하지만 메타데이터 요청이 빈번하면 특히 대규모 클러스터에서 성능이 저하될 수 있습니다. 성능 개선에 대한 자세한 내용은 GKE 성능을 위한 Cloud Storage FUSE CSI 드라이버 최적화성능 조정 권장사항을 참고하세요.

성능을 최적화하려면 다음 구성을 고려하세요.

  • 계층적 네임스페이스 사용 설정: 데이터 액세스 및 조직을 개선하려면 계층적 네임스페이스가 사용 설정된 Cloud Storage 버킷을 만드세요. 계층적 네임스페이스를 사용하면 데이터를 파일 시스템 구조로 구성할 수 있어, 성능 향상, 일관성 보장, AI 및 ML 워크로드 관리 단순화에 도움이 됩니다. 계층적 네임스페이스는 더 높은 초기 QPS와 빠른 원자적 디렉터리 이름 변경을 지원합니다.
  • 파일 캐싱 사용 설정: 파일 캐싱은 로컬 노드 디렉터리를 활용해 자주 읽는 파일을 캐시에 저장하여 학습 데이터의 반복 액세스를 가속화합니다. 반복되는 읽기 요청을 캐시에서 처리하면 지연 시간이 줄어들고 Cloud Storage로의 작업 요청도 최소화됩니다. 로컬 SSD가 있는 GPU 머신 유형에서는 로컬 SSD 디렉터리가 자동으로 사용됩니다. TPU와 같이 로컬 SSD가 포함되지 않은 머신 유형에서는 /tmpfs와 같은 RAM 디스크 디렉터리를 사용할 수 있습니다.

    파일 캐시를 사용 설정하려면 다음 마운트 옵션을 사용하세요.

    • 사용 가능한 파일 캐시 값을 캐시 용량 한도로 설정하려면 file-cache:max-size-mb:-1로 설정하세요.
    • 메타데이터 캐시의 TTL(수명)을 무제한으로 설정하고, 최대 용량에 도달했을 때 가장 최근에 사용되지 않은 항목(LRU)부터 제거되도록 하려면 metadata-cache:ttl-secs:-1로 설정하세요.
  • 메타데이터 캐시 값 증가시키기: Cloud Storage FUSE에는 메타데이터 조회 관련 작업의 성능을 향상시키는 두 가지 형태의 메타데이터 캐시(stat 캐시type 캐시)가 있습니다.

    메타데이터 캐시 값을 늘리려면 다음 마운트 옵션을 설정하세요.

    • 사용 가능한 stat 캐시 값을 캐시 용량 한도로 설정하려면 metadata-cache:stat-cache-max-size-mb:-1로 설정합니다.
    • 사용 가능한 type 캐시 값을 용량 한도로 설정하려면 metadata-cache:type-cache-max-size-mb:-1로 설정합니다.
    • 기본값 60초로 만료되는 캐시된 메타데이터 항목이 만료되지 않도록 하려면 metadata-cache:ttl-secs:-1로 설정합니다. 단 무제한 값은 읽기 전용 볼륨과 대용량 메모리 구성을 가진 노드에서만 사용해야 합니다.
  • 메타데이터 캐시 자동 입력: 메타데이터 미리 가져오기 기능을 사용하면 Cloud Storage FUSE CSI 드라이버가 Cloud Storage 버킷의 객체에 대한 관련 메타데이터를 Cloud Storage FUSE 캐시에 미리 로드할 수 있습니다. 이 방식은 Cloud Storage에 대한 호출을 줄여주며, AI 및 ML 학습 워크로드와 같이 특히 파일이 많은 대규모 데이터 세트에 액세스하는 애플리케이션에 유용합니다.

    메타데이터 캐시를 자동 입력하려면 해당 볼륨에 대해 메타데이터 미리 가져오기를 사용 설정하세요. 볼륨 속성 gcsfuseMetadataPrefetchOnMounttrue로 설정합니다. 워크로드 중단을 방지하려면 사이드카 리소스를 구성하여 gke-gcsfuse-metadata-prefetch 사이드카의 메모리 한도를 늘리는 것이 좋습니다.

  • 목록 캐싱 사용 설정: 이 기능은 디렉터리와 파일의 나열 작업을 최적화합니다. 목록 캐싱은 전체 디렉터리를 반복적으로 액세스하고 나열하는 경우가 많은 AI 및 ML 학습 워크로드에서 특히 유용합니다. 목록 캐싱을 사용하면 디렉터리 목록을 컴퓨터 메모리에 반복적으로 불러올 필요가 줄어들어 학습 프로세스를 매우 효율적으로 만들 수 있습니다.

    목록 캐싱을 사용 설정하고 커널 목록 캐시 항목이 만료되지 않도록 하려면 마운트 옵션 file-system:kernel-list-cache-ttl-secs:-1로 설정하세요.

  • 병렬 다운로드 사용 설정: 병렬 다운로드는 여러 청크를 동시에 가져와 모델의 초기 로딩 속도를 가속화합니다. 병렬 다운로드를 사용 설정하면 모델 로딩 시간이 단축되고 서빙 단계에서 응답성이 향상됩니다.

    병렬 다운로드를 사용 설정하려면 파일 캐시를 사용 설정하고 마운트 옵션 file-cache:enable-parallel-downloads:true로 설정하세요.

  • GKE 사이드카 한도 증가: 리소스 제약에 의해 성능이 저하되지 않도록 CPU 및 메모리 소비와 같은 사이드카 컨테이너 리소스에 대한 한도를 구성하세요. 로컬 SSD 캐시를 사용하는 경우 ephemeral-storage-limit를 무제한으로 설정하는 것이 좋습니다. 이 설정을 사용하면 Cloud Storage FUSE가 사용 가능한 로컬 SSD 스토리지를 최대한 활용해 캐싱 성능을 향상시킬 수 있습니다.

  • 읽기 전용 마운트: 학습 워크로드는 일반적으로 데이터 읽기만 필요하므로, 마운트 지점을 읽기 전용으로 구성하면 최적의 성능을 얻을 수 있습니다. 특히 파일 캐싱을 사용할 때 효과적입니다. 이 구성은 대규모 클러스터에서 최적화 효과를 극대화하고 잠재적인 데이터 불일치 문제를 방지하는 데에도 도움이 됩니다.

기타 성능 고려사항

AI 및 ML 워크로드와 관련된 성능 최적화 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 성능 최적화를 참조하세요.

다음 단계

참여자

저자: 사만다 헤 | 테크니컬 라이터

기타 참여자: