GKE 클러스터용 스토리지 개요

이 문서에서는 GKE가 지원하는 스토리지 옵션과 비즈니스 요구사항에 가장 적합한 옵션을 선택하기 위한 몇 가지 주요 고려사항을 설명합니다.

GKE는 다음 스토리지 유형과 통합을 지원합니다.

블록 스토리지(Persistent Disk)

Persistent Disk 볼륨은 데스크톱 또는 서버의 물리적 디스크와 같이 GKE 클러스터에서 액세스할 수 있는 Compute Engine에서 관리하는 내구성이 있는 네트워크 스토리지 기기입니다. 클러스터에 추가 저장공간이 필요한 경우 노드에 더 많은 Persistent Disk 볼륨을 연결하거나 기존 Persistent Disk 볼륨의 크기를 조절할 수 있습니다. GKE가 Persistent Disk에서 지원하는 PersistentVolume을 동적으로 프로비저닝하거나 사용자가 수동으로 디스크를 프로비저닝할 수 있습니다.

이 스토리지 옵션은 GKE Autopilot 및 Standard 클러스터에서 지원됩니다.

기본적으로 Persistent Disk 볼륨은 영역별 리소스입니다(리전 내 단일 영역에 유지됨). 리전 Persistent Disk 볼륨을 만들 수 있습니다(동일한 리전의 두 영역 간에 유지됨). Persistent Disk 볼륨을 여러 노드에 동시에 읽기 전용으로 연결할 수도 있습니다. 이는 영역 및 리전 Persistent Disk 볼륨 모두에서 지원됩니다.

GKE의 Persistent Disk 스토리지는 영구적이므로 디스크에 저장된 데이터는 이를 사용하는 포드가 종료되더라도 지속됩니다.

Persistent Disk 스토리지를 사용하는 이유

클러스터에서 가용성이 높고 내구성이 뛰어난 고성능 블록 스토리지에 액세스해야 하는 경우 Persistent Disk 스토리지를 사용하세요. Persistent Disk 볼륨은 일반적으로 단일 포드에 연결됩니다. 이 스토리지 옵션은 ReadWriteOnce 액세스 모드를 지원합니다. GKE는 다음을 포함하여 다양한 지연 시간과 성능 옵션으로 Persistent Disk 볼륨을 구성할 수 있는 지원을 제공합니다.

  • 균형 있는 영구 디스크: 표준 엔터프라이즈 애플리케이션에 적합합니다. 이 옵션은 성능과 비용의 균형을 제공합니다. 솔리드 스테이트 드라이브(SSD)에서 지원합니다. 이 옵션은 GKE 1.24 이상을 실행하는 클러스터 및 노드에서 동적 볼륨 프로비저닝을 위한 기본 옵션입니다.
  • 성능 영구 디스크: 수평 확장 분석, 데이터베이스, 영구 캐싱에 적합합니다. 이 옵션은 성능에 민감한 워크로드에 적합합니다. 솔리드 스테이트 드라이브(SSD)에서 지원합니다.
  • 표준 영구 디스크: 빅데이터, 대규모 컴퓨팅 워크로드에 적합합니다. 이 옵션은 가장 비용 효율적인 디스크 유형입니다. 표준 하드 디스크 드라이브(HDD)에서 지원합니다.
  • 익스트림 영구 디스크: SAP HANA 및 Oracle과 같은 엔터프라이즈 애플리케이션에 적합합니다. 이 옵션은 대규모 인메모리 데이터베이스의 요구사항을 충족하는 최고의 성능을 제공합니다. 솔리드 스테이트 드라이브(SSD)에서 지원합니다. Persistent Disk가 충분한 성능을 제공하지 않는 성능에 중요한 애플리케이션의 경우 Hyperdisk Extreme 디스크를 사용하세요.

이 스토리지 옵션을 사용하려면 다음 리소스를 참조하세요.

블록 스토리지(Google Cloud Hyperdisk)

Hyperdisk 볼륨은 차세대 Google Cloud 블록 스토리지를 사용합니다. Hyperdisk 볼륨을 사용하면 워크로드에 맞게 블록 스토리지의 성능을 동적으로 조정할 수 있습니다. 애플리케이션에 대해 초당 입출력 작업 수(IOPS) 및 처리량을 독립적으로 구성하고 시간 경과에 따른 성능 니즈에 맞게 조정할 수 있습니다.

이 스토리지 옵션은 GKE Autopilot 및 Standard 클러스터에서 지원됩니다. Hyperdisk 볼륨은 리전별 가용성에 따른 영역별 리소스입니다. GKE의 Hyperdisk 스토리지는 영구적이므로 디스크에 저장된 데이터는 이를 사용하는 포드가 종료되더라도 지속됩니다.

Hyperdisk 스토리지를 사용하는 이유

IOPS 또는 처리량을 동적으로 조정하고 조정해야 하는 경우 Hyperdisk 스토리지를 사용하세요. Hyperdisk 볼륨은 일반적으로 단일 포드에 연결됩니다. 이 스토리지 옵션은 ReadWriteOnce 액세스 모드를 지원합니다. 가격 성능 요구에 따라 GKE에 다음 Hyperdisk 스토리지 옵션 중에서 선택할 수 있습니다.

  • Hyperdisk 처리량: 최대 3GB/s의 처리량(128KB IO 크기 이상)과 함께 비용 효율적인 높은 처리량에 최적화되어 있습니다. 이는 사용 사례가 수평 확장 분석(예: Hadoop 또는 Kafka), 백업 서버의 콜드 데이터 복원, 처리량 기준의 비용에 민감한 워크로드를 대상으로 하는 경우에 적합한 옵션입니다. 이 스토리지 옵션은 GKE Autopilot 및 Standard 클러스터에서 지원됩니다.
  • Hyperdisk Extreme: 320,000개를 초과하는 프로비저닝된 IOPS 및 4.8GB/s를 초과하는 처리량으로 IOPS 성능에 최적화되어 있습니다. 이는 데이터베이스 관리 시스템과 같은 고성능 워크로드를 배포하는 경우에 적합한 옵션입니다. 이 스토리지 옵션은 Standard 클러스터에서만 지원됩니다.

이 스토리지 옵션을 사용하려면 다음 리소스를 참조하세요.

임시 및 원시 블록 스토리지(로컬 SSD)

로컬 SSD 디스크는 노드에 직접 연결된 물리적 드라이브입니다. 더 나은 성능을 제공할 수 있지만 일시적입니다. 각 로컬 SSD 볼륨은 특정 노드에 연결됩니다. 볼륨을 다른 노드로 이동할 수 없습니다.

이 스토리지 옵션은 GKE Standard 클러스터에서 지원됩니다. 로컬 SSD의 Autopilot 지원은 A2 Ultra A100 머신, GKE 1.27 이상을 실행하는 클러스터 및 노드 풀에서 미리보기로 제공됩니다.

GKE의 로컬 SSD 스토리지에서 지원되는 임시 스토리지는 포드의 수명 주기와 관련이 있습니다. 포드가 종료되면 포드와 연결된 임시 스토리지도 삭제됩니다.

로컬 SSD를 사용하는 이유

데이터베이스와 실시간 분석을 위한 핫 캐싱 또는 지연 시간이 가장 짧은 플래시 최적화 임시 스토리지에 GKE 클러스터의 로컬 SSD 스토리지를 사용하는 것이 적합합니다. 로컬 SSD 스토리지는 AI/ML, 일괄 처리, 분석, 인메모리 데이터베이스 사용 사례에 대한 Cloud Storage 앞의 캐싱 레이어로 효과적일 수 있습니다.

이 스토리지 옵션을 사용하려면 다음 리소스를 참조하세요.

파일 스토리지

Filestore는 네트워크 파일 시스템(NFS) 액세스를 통해 구조화되지 않은 데이터를 위한 클라우드 기반 공유 파일 시스템을 제공합니다. Filestore 인스턴스는 GKE 클러스터에 ReadWriteMany 액세스 권한이 있는 내구성 있는 스토리지를 제공하는 Google Cloud의 파일 서버 역할을 합니다. Filestore 인스턴스가 호스트에서 분리되며 최소한의 수동 작업이 필요합니다. 볼륨을 연결하거나 분리할 인프라 작업이 없기 때문에 워크로드 장애 조치가 원활하게 이루어집니다.

이 스토리지 옵션은 GKE Autopilot 및 Standard 클러스터에서 지원됩니다. 엔터프라이즈 서비스 등급이 있는 Filestore 스토리지의 기본값은 리전별 가용성이고 다른 서비스 등급은 영역별 가용성입니다. GKE의 Filestore 스토리지는 영구적이므로 디스크에 저장된 데이터는 이를 사용하는 포드가 종료되더라도 지속됩니다.

Filestore 스토리지를 사용하는 이유

애플리케이션에 네트워크 파일 시스템(NFS) 액세스와 여러 리더 및 작성자가 필요한 경우 Filestore 스토리지를 사용합니다. 이 스토리지 옵션은 콘텐츠 관리 시스템, 애플리케이션 마이그레이션, 데이터 분석, 렌더링, 미디어 처리와 관련된 사용 사례에 적합합니다.

비용 효율성을 높이기 위해 GKE용 Filestore 멀티 공유를 사용하면 10GiB 이상의 Filestore 엔터프라이즈 등급 인스턴스를 최대 80개의 PersistentVolume과 공유할 수 있습니다.

이 스토리지 옵션을 사용하려면 다음 리소스를 참조하세요.

객체 스토리지(Cloud Storage FUSE)

Cloud Storage는 바이너리 및 객체 데이터, blob, 구조화되지 않은 데이터를 위한 객체 저장소입니다. Cloud Storage FUSE CSI 드라이버는 기존 Cloud Storage 버킷을 볼륨으로 사용할 수 있도록 Cloud Storage FUSE와 Kubernetes API의 통합을 관리합니다. Cloud Storage FUSE CSI 드라이버를 사용하여 GKE 노드에 버킷을 파일 시스템으로 마운트할 수 있습니다.

Cloud Storage FUSE CSI 드라이버는 GKE Autopilot 및 Standard 클러스터에서 ReadWriteMany, ReadOnlyMany, ReadWriteOnce 액세스 모드를 지원합니다. Cloud Storage 객체에는 리전별 가용성이 있습니다. GKE의 Cloud Storage 데이터는 영구적입니다. 즉, 버킷에 저장된 데이터는 이를 사용하는 포드가 종료되더라도 지속됩니다.

Cloud Storage FUSE를 사용하는 이유

Cloud Storage FUSE 옵션은 이동성을 위해 Cloud Storage 앞에 파일 시맨틱스가 필요한 경우에 적합합니다. Cloud Storage FUSE는 머신러닝(ML) 학습 및 모델 데이터를 Cloud Storage의 객체로 저장하고 액세스하려는 개발자가 일반적으로 선택합니다.

이 스토리지 옵션을 사용하려면 다음 리소스를 참조하세요.

관리형 데이터베이스

Cloud SQL 또는 Spanner와 같은 관리형 데이터베이스는 운영 오버헤드를 줄이고 Google Cloud 인프라에 최적화되어 있습니다. 관리형 데이터베이스는 Kubernetes에 직접 배포하는 데이터베이스보다 유지보수 및 운영 노력이 적게 필요합니다.

관리형 데이터베이스를 사용하는 이유

Google Cloud 관리형 데이터베이스를 사용하면 GKE의 스테이트풀(Stateful) 워크로드가 영구 데이터에 액세스하면서 백업, 패치, 확장과 같은 유지보수 작업을 자동화할 수 있습니다. 데이터베이스를 만들고 앱을 빌드하고 Google Cloud에서 자동으로 확장되도록 설정합니다. 하지만 이 경우에는 정확한 데이터베이스 버전, 확장 프로그램, 원하는 정확한 데이터베이스 사양에 대한 액세스 권한이 없을 수도 있습니다.

GKE는 다음을 포함한 Google Cloud 관리형 데이터베이스 서비스와의 연결을 지원합니다.

이 스토리지 옵션을 사용하려면 다음 리소스를 참조하세요.

아티팩트 빌드(Artifact Registry)

Artifact Registry는 빌드 및 배포하는 컨테이너 이미지, OS 패키지, 언어 패키지의 저장소 관리자입니다.

Artifact Registry를 사용하는 이유

Artifact Registry는 비공개 컨테이너 이미지, Helm 차트, 기타 빌드 아티팩트를 저장하는 데 적합한 옵션입니다.

Artifact Registry Docker 저장소에서 GKE로 이미지를 가져오려면 Artifact Registry 문서의 Google Kubernetes Engine에 배포를 참조하세요.

다음 단계