이 문서에서는 GKE에서 지원하는 스토리지 옵션과 비즈니스 요구사항에 가장 적합한 옵션을 선택하기 위한 몇 가지 주요 고려사항을 알아봅니다. 선택에 적합한 머신 계열을 확인하려면 머신 시리즈 비교를 참조하세요.
GKE는 다음 스토리지 유형 및 통합을 지원합니다.
- Persistent Disk를 사용한 블록 스토리지
- Google Cloud Hyperdisk를 사용한 블록 스토리지
- Hyperdisk 스토리지 풀을 사용한 블록 스토리지
- 로컬 SSD를 사용한 임시 및 원시 블록 스토리지
- 파일 스토리지
- Cloud Storage FUSE를 사용한 객체 스토리지
- 관리형 데이터베이스
- 빌드 아티팩트
블록 스토리지(Persistent Disk)
Persistent Disk 볼륨은 데스크톱 또는 서버의 물리적 디스크와 같이 GKE 클러스터에서 액세스할 수 있는 Compute Engine에서 관리하는 내구성이 있는 네트워크 스토리지 기기입니다. 클러스터에 추가 저장공간이 필요한 경우 노드에 더 많은 Persistent Disk 볼륨을 연결하거나 기존 Persistent Disk 볼륨의 크기를 조절할 수 있습니다. GKE에서 Persistent Disk를 기반으로 동적으로 PersistentVolumes를 프로비저닝하도록 하거나 디스크를 수동으로 프로비저닝할 수 있습니다.
이 스토리지 옵션은 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가 충분한 성능을 제공하지 않는 성능이 중요한 애플리케이션의 경우 하이퍼디스크 익스트림 디스크를 사용합니다.
이 저장용량 옵션을 사용하려면 다음 리소스를 참고하세요.
- 사용 가능한 디스크 유형에 대한 자세한 내용은 Compute Engine 문서의 스토리지 옵션을 참고하세요.
- Compute Engine Persistent Disk CSI 드라이버는 GKE에서 Persistent Disk 스토리지를 사용하는 기본 방법입니다. 자세한 내용은 Compute Engine Persistent Disk CSI 드라이버 사용을 참고하세요.
블록 스토리지(Google Cloud Hyperdisk)
Hyperdisk 볼륨은 차세대 Google Cloud 블록 스토리지를 사용합니다. Hyperdisk 볼륨을 사용하면 워크로드에 맞게 블록 스토리지의 성능을 동적으로 조정할 수 있습니다. 애플리케이션에 대해 초당 입출력 작업 수(IOPS) 및 처리량을 독립적으로 구성하고 시간 경과에 따른 성능 니즈에 맞게 조정할 수 있습니다.
이 스토리지 옵션은 GKE Autopilot 및 Standard 클러스터에서 지원됩니다. Hyperdisk 볼륨은 리전별 가용성에 따른 영역별 리소스입니다. GKE의 Hyperdisk 스토리지는 영구적이므로 디스크에 저장된 데이터는 이를 사용하는 포드가 종료되더라도 지속됩니다.
Hyperdisk 스토리지를 사용하는 이유
IOPS 또는 처리량을 동적으로 조정하고 조정해야 하는 경우 Hyperdisk 스토리지를 사용하세요. Hyperdisk 볼륨은 일반적으로 단일 포드에 연결됩니다. 이 스토리지 옵션은 ReadWriteOnce
액세스 모드를 지원합니다. 가격 성능 요구에 따라 GKE에 다음 Hyperdisk 스토리지 옵션 중에서 선택할 수 있습니다.
- 하이퍼디스크 균형: 대부분의 워크로드에 가장 적합합니다. 이는 데이터베이스 및 웹 서버는 물론 대부분의 기업 및 비즈니스 라인 앱을 배포하는 데 적합한 옵션입니다.
- 하이퍼디스크 처리량: 비용 효율적인 높은 처리량에 최적화되어 있습니다. 이는 사용 사례가 수평 확장 분석(예: Hadoop 또는 Kafka), 백업 서버의 콜드 데이터 복원, 처리량 기준의 비용에 민감한 워크로드를 대상으로 하는 경우에 적합한 옵션입니다.
- 하이퍼디스크 익스트림: IOPS 성능에 최적화되어 있습니다. 이는 데이터베이스 관리 시스템과 같은 고성능 워크로드를 배포하는 경우에 적합한 옵션입니다.
- Hyperdisk ML: 모델 가중치를 빠르게 로드해야 하는 AI/ML 학습 및 추론 워크로드에 최적화되어 있습니다. 이 옵션을 사용하면 지연 시간 병목 현상으로 인한 GPU/TPU 리소스의 유휴 상태를 줄일 수 있습니다.
Hyperdisk 스토리지 옵션은 GKE Autopilot 및 Standard 클러스터에서 지원됩니다.
이 스토리지 옵션을 사용하려면 다음 리소스를 참고하세요.
- 개요는 GKE용 Hyperdisk 정보를 참조하세요.
- 최대 처리량 및 IOPS를 비롯한 디스크당 한도는 Compute Engine 문서의 디스크당 Hyperdisk 한도를 참조하세요.
- 클러스터에서 하이퍼디스크 처리량 및 익스트림 스토리지를 설정하고 사용하려면 Hyperdisk로 스토리지 성능 확장을 참조하세요.
블록 스토리지(Hyperdisk 스토리지 풀)
Hyperdisk Storage Pool은 GKE 클러스터의 디스크에서 사용할 수 있는 사전 프로비저닝된 스토리지 리소스(용량, 처리량, IOPS) 풀입니다. 스토리지 리소스는 스토리지 풀 내에서 만드는 모든 하이퍼디스크에 공유됩니다.
GKE Standard 클러스터에서는 Hyperdisk 부팅 디스크(운영체제용) 및 연결된 Hyperdisk(데이터 저장용)를 모두 스토리지 풀에 포함할 수 있습니다. GKE Autopilot 클러스터는 스토리지 풀에 연결된 하이퍼디스크만 지원합니다.
이 스토리지 옵션을 사용하려면 다음 리소스를 참조하세요.
- 개요는 하이퍼디스크 스토리지 풀 정보를 참조하세요.
- GKE 클러스터에서 Hyperdisk Storage Pool을 설정하려면 Hyperdisk Storage Pool로 스토리지 성능 및 비용 최적화를 참조하세요.
임시 및 원시 블록 스토리지(로컬 SSD)
로컬 SSD 디스크는 노드에 직접 연결되는 물리적 드라이브입니다. 더 나은 성능을 제공할 수 있지만 일시적입니다. 각 로컬 SSD 볼륨은 특정 노드에 연결됩니다. 볼륨을 다른 노드로 이동할 수 없습니다.
이 스토리지 옵션은 GKE Standard 클러스터에서 지원됩니다. 로컬 SSD에 대한 Autopilot 지원은 GKE 1.27 이상을 실행하는 클러스터 및 노드 풀에서 A2 Ultra A100 머신의 미리보기로 제공됩니다.
GKE의 로컬 SSD 스토리지로 지원되는 임시 스토리지는 포드의 수명 주기에 연결됩니다. 포드가 종료되면 해당 포드와 연결된 임시 스토리지도 삭제됩니다.
로컬 SSD를 사용하는 이유
데이터베이스와 실시간 분석을 위한 핫 캐싱 또는 지연 시간이 가장 짧은 플래시 최적화 임시 스토리지에 GKE 클러스터의 로컬 SSD 스토리지를 사용하는 것이 적합합니다. 로컬 SSD 스토리지는 AI/ML, 일괄 처리, 분석, 인메모리 데이터베이스 사용 사례에 대한 Cloud Storage 앞의 캐싱 레이어로 효과적일 수 있습니다.
이 스토리지 옵션을 사용하려면 다음 리소스를 참고하세요.
- 개요는 GKE용 로컬 SSD 스토리지 정보를 참조하세요.
- 클러스터의 로컬 SSD 스토리지를 emptyDir로 설정하고 사용하려면 로컬 SSD 지원 임시 스토리지 프로비저닝 및 사용을 참조하세요.
- 클러스터의 로컬 SSD 스토리지를 로컬 PersistentVolume 리소스로 설정하고 사용하려면 로컬 SSD 지원 원시 블록 스토리지 프로비저닝 및 사용을 참조하세요.
파일 스토리지
Filestore는 네트워크 파일 시스템(NFS) 액세스를 통해 구조화되지 않은 데이터를 위한 클라우드 기반 공유 파일 시스템을 제공합니다. Filestore 인스턴스는 Google Cloud에서 GKE 클러스터에 대한 ReadWriteMany
액세스 권한이 있는 내구성 있는 스토리지를 제공하는 파일 서버 역할을 합니다. Filestore 인스턴스는 호스트에서 분리되며 최소한의 수동 작업이 필요합니다. 볼륨을 연결하거나 분리할 인프라 작업이 없기 때문에 워크로드 장애 조치가 원활하게 이루어집니다.
이 스토리지 옵션은 GKE Autopilot 및 Standard 클러스터에서 지원됩니다. 엔터프라이즈 서비스 등급이 있는 Filestore 스토리지의 기본값은 리전별 가용성이고 다른 서비스 등급은 영역별 가용성입니다. GKE의 Filestore 스토리지는 영구적이므로 디스크에 저장된 데이터는 이를 사용하는 포드가 종료되더라도 지속됩니다.
Filestore 스토리지를 사용하는 이유
애플리케이션에 네트워크 파일 시스템(NFS) 액세스와 여러 리더 및 작성자가 필요한 경우 Filestore 스토리지를 사용합니다. 이 스토리지 옵션은 콘텐츠 관리 시스템, 애플리케이션 마이그레이션, 데이터 분석, 렌더링, 미디어 처리와 관련된 사용 사례에 적합합니다.
추가적인 비용 효율성을 위해 GKE용 Filestore Multishares를 사용하면 10GiB 이상의 Filestore 엔터프라이즈 등급 인스턴스를 최대 80 PersistentVolume과 공유할 수 있습니다.
이 스토리지 옵션을 사용하려면 다음 리소스를 참고하세요.
- 개요는 GKE용 Filestore 지원 정보를 참고하세요.
- Filestore CSI 드라이버는 GKE에서 Filestore 스토리지를 사용하는 기본 방법입니다. 자세한 내용은 Filestore CSI 드라이버로 Filestore 인스턴스에 액세스를 참조하세요.
- Filestore 다중 공유 안내는 GKE용 Filestore 다중 공유로 스토리지 최적화를 참고하세요.
객체 스토리지(Cloud Storage FUSE)
Cloud Storage는 바이너리 및 객체 데이터, blob, 비정형 데이터를 위한 객체 저장소입니다. Cloud Storage FUSE CSI 드라이버는 Cloud Storage FUSE와 Kubernetes API의 통합을 관리하여 기존 Cloud Storage 버킷을 볼륨으로 사용합니다. 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 Storage FUSE를 참고하세요.
- 클러스터에서 Google Cloud 버킷을 사용하려면 Cloud Storage CSI FUSE 드라이버로 Cloud Storage 버킷에 액세스를 참고하세요.
관리형 데이터베이스
Cloud SQL 또는 Spanner와 같은 관리형 데이터베이스는 운영 오버헤드를 줄이고 Google Cloud 인프라에 최적화되어 있습니다. 관리형 데이터베이스는 Kubernetes에 직접 배포하는 데이터베이스보다 유지보수 및 운영 노력이 적게 필요합니다.
관리형 데이터베이스를 사용하는 이유
Google Cloud 관리형 데이터베이스를 사용하면 GKE의 스테이트풀(Stateful) 워크로드가 영구 데이터에 액세스하고 백업, 패치, 확장과 같은 유지보수 작업을 자동화할 수 있습니다. 데이터베이스를 만들고 앱을 빌드하고 Google Cloud에서 자동으로 확장되도록 설정합니다. 하지만 이 경우에는 정확한 데이터베이스 버전, 확장 프로그램, 원하는 정확한 데이터베이스 사양에 대한 액세스 권한이 없을 수도 있습니다.
GKE는 다음을 포함하여 Google Cloud 관리형 데이터베이스 서비스와 연결하는 기능을 지원합니다.
Cloud SQL: 완전 관리형 MySQL, PostgreSQL, SQL Server 데이터베이스입니다. Google Kubernetes Engine에서 연결을 참고하세요.
Spanner: 높은 일관성과 가용성을 갖춘 수평 확장 가능한 관계형 데이터베이스입니다. GKE Autopilot 및 Cloud Spanner를 사용하여 앱 배포를 참조하세요.
Redis용 Memorystore: 완전 관리형 인메모리 데이터 스토어 서비스입니다. Google Kubernetes Engine 클러스터에서 Redis 인스턴스에 연결을 참조하세요.
이 스토리지 옵션을 사용하려면 다음 리소스를 참고하세요.
- Google Cloud 데이터베이스 옵션 설명
- 관리형 데이터베이스 또는 GKE에서 호스팅되는 컨테이너화된 데이터베이스 사용에 대한 고려사항은 GKE에서 데이터베이스 배포 계획을 참조하세요.
아티팩트 빌드(Artifact Registry)
Artifact Registry는 사용자가 빌드하고 배포하는 컨테이너 이미지, OS 패키지, 언어 패키지를 위한 저장소 관리자입니다.
Artifact Registry를 사용하는 이유
Artifact Registry는 비공개 컨테이너 이미지, Helm 차트, 기타 빌드 아티팩트를 저장하는 데 적합한 옵션입니다.
Artifact Registry Docker 저장소에서 GKE로 이미지를 가져오려면 Artifact Registry 문서의 Google Kubernetes Engine에 배포를 참고하세요.
다음 단계
- Google Cloud의 스토리지 옵션 지도 블로그 게시물 읽어보기
- 클라우드 워크로드에 최적화된 스토리지 전략을 설계합니다.
- GKE에서 Kubernetes 스토리지 추상화를 사용하는 방법(PersistentVolumes, StatefulSets)을 이해합니다.
- GKE와 통합할 수 있는 데이터 솔루션에 대해 알아보려면 GKE의 데이터 리소스 페이지를 참고하세요.