스토리지 옵션

Compute Engine은 VM 인스턴스에 대해 여러 스토리지 옵션을 제공합니다. 다음 스토리지 옵션은 각각 고유한 가격과 성능 특성을 가지고 있습니다.

Persistent Disk 볼륨은 고성능 중복 네트워크 스토리지를 제공합니다. 각 Persistent Disk 볼륨은 수백 개의 물리적 디스크 간에 스트라이프로 구성됩니다.
- 기본적으로 VM은 영역별 영구 디스크를 사용하고 us-west1-c와 같이 단일 영역 내에 있는 볼륨에 데이터를 저장합니다.
- 또한 2개 영역에 배치된 디스크 간에 데이터를 동기적으로 복제하고 영역이 사용 불가능할 때 보호 기능을 제공하는 리전별 영구 디스크를 만들 수 있습니다.
하이퍼디스크 볼륨은 동적으로 크기를 조정할 수 있는 볼륨 및 구성 가능한 성능과 함께 Compute Engine에 대해 가장 빠른 중복 네트워크 스토리지를 제공합니다.
로컬 SSD는 VM과 동일한 서버에 직접 연결되는 물리적 드라이브입니다. 더 나은 성능을 제공할 수 있지만 일시적입니다.
또한 VM에 Cloud Storage 버킷 및 Filestore를 사용할 수 있습니다.

각 스토리지 옵션마다 고유한 가격 및 성능 특성이 있습니다. 비용 비교는 디스크 가격 책정을 참조하세요. 어떤 옵션을 사용해야 할지 잘 모르겠다면 인스턴스에 영구 디스크를 추가하는 것이 가장 일반적인 솔루션입니다.

소개

기본적으로, 각 Compute Engine 인스턴스에는 운영체제가 포함된 단일 부팅 디스크가 있습니다. 부팅 디스크 데이터는 일반적으로 Persistent Disk(PD) 볼륨에 저장됩니다. 애플리케이션에 추가 스토리지 공간이 필요하면 다음 스토리지 볼륨 중 하나 이상을 인스턴스에 프로비저닝할 수 있습니다.

각 스토리지 옵션에 대해 자세히 알아보려면 다음 표를 검토하세요.

	영역 표준 PD	리전 표준 PD	영역 균형 있는 PD	리전 균형 있는 PD	영역 SSD PD	리전 SSD PD	영역 익스트림 PD	하이퍼디스크 익스트림	로컬 SSD	Cloud Storage 버킷
스토리지 유형	효율적이고 안정적인 블록 스토리지	리전의 두 영역에 동기식으로 복제되는 효율적이고 안정적인 블록 스토리지	비용 효율적이고 안정적인 블록 스토리지	리전의 두 영역에 동기식으로 복제되는 비용 효율적이고 안정적인 블록 스토리지	빠르고 안정적인 블록 스토리지	리전의 두 영역에 동기식으로 복제되는 빠르고 안정적인 블록 스토리지	IOPS를 맞춤설정할 수 있는 최고 성능의 Persistent Disk 블록 스토리지 옵션	IOPS를 맞춤설정할 수 있는 가장 빠른 블록 스토리지 옵션	고성능 로컬 블록 스토리지	저렴한 객체 스토리지
디스크당 최소 용량	10GiB	200GiB	10GiB	10GiB	10GiB	10GiB	500GiB	64GiB	375GiB	해당 사항 없음
디스크당 최대 용량	64TiB	64TiB	64TiB	64TiB	64TiB	64TiB	64TiB	64TiB	375GiB	해당 사항 없음
용량 증가	1GiB	1GiB	1GiB	1GiB	1GiB	1GiB	1GiB	1GiB	머신 유형에 따라 다름^†	해당 사항 없음
인스턴스당 최대 용량	257TiB^*	257TiB^*	257TiB^*	257TiB^*	257TiB^*	257TiB^*	257TiB^*	257TiB^*	9TiB	거의 무한
액세스 범위	영역	영역	영역	영역	영역	영역	영역	영역	인스턴스	전체
데이터 중복	영역	멀티 영역	영역	멀티 영역	영역	멀티 영역	영역	영역	아니요	리전, 이중 리전 또는 멀티 리전
저장 데이터 암호화	예	예	예	예	예	예	예	예	예	예
커스텀 암호화 키	예	예	예	예	예	예	예	예	아니요	예
사용 안내	표준 영구 디스크 추가	리전 표준 영구 디스크 추가	균형 있는 영구 디스크 추가	리전 균형 있는 영구 디스크 추가	SSD 영구 디스크 추가	리전 SSD 영구 디스크 추가	익스트림 영구 디스크 추가	하이퍼디스크 추가	로컬 SSD 추가	버킷 연결

^* 64TB보다 큰 논리적 볼륨을 만들려는 경우 논리적 볼륨 크기가 성능에 미치는 영향을 검토하세요.

^† 로컬 SSD의 용량 증가는 각 머신 유형에 따라 달라지는 VM별로 허용되는 SSD 디스크(파티션) 수에 따라 달라집니다. 자세한 내용은 로컬 SSD 및 머신 유형을 참조하세요.

앞의 표에 나열된 스토리지 옵션 외에도 Google Cloud는 인스턴스에 대해 다음 스토리지 서비스를 제공합니다.

파일 서비스: Compute Engine에서 파일 서버 또는 분산 파일 시스템을 만들어서 NFSv3 및 SMB3 기능이 포함된 네트워크 파일 시스템으로 사용할 수 있습니다.
RAM 디스크: VM 인스턴스 메모리 내에서 RAM 디스크를 마운트하여 지연 시간이 낮고 처리량이 높은 블록 스토리지 볼륨을 만들 수 있습니다.

블록 스토리지 리소스마다 성능 특성이 다릅니다. VM 인스턴스에 올바른 블록 스토리지 유형을 결정할 때는 스토리지 크기 및 성능 요구사항을 고려해야 합니다.

각 디스크 유형의 성능 한도는 다음을 참조하세요.

멀티 작성자 모드에서 만들어진 영구 디스크에는 특정 IOPS 및 처리량 한도가 적용됩니다. 자세한 내용은 멀티 작성자 모드에서 영구 디스크 성능을 참조하세요.

영구 디스크

영구 디스크는 데스크톱 또는 서버의 물리적 디스크와 같이 인스턴스에서 액세스할 수 있는 내구성이 있는 네트워크 스토리지 기기입니다. 각 영구 디스크의 데이터는 여러 물리적 디스크에 분산됩니다. Compute Engine은 중복을 보장하고 성능을 최적화하기 위해 물리적 디스크 및 데이터 분산을 관리합니다.

영구 디스크는 가상 머신(VM) 인스턴스와는 별개의 위치에 존재하므로 인스턴스를 삭제한 후에도 영구 디스크를 분리하거나 이동하여 데이터를 보존할 수 있습니다. 영구 디스크 성능은 크기에 따라 자동으로 확장되므로 기존 영구 디스크의 크기를 조절하거나 인스턴스에 영구 디스크를 추가하여 성능 및 저장공간 요구사항을 충족할 수 있습니다.

영구 디스크 유형

영구 디스크를 구성할 때 다음 디스크 유형 중 하나를 선택할 수 있습니다.

표준 영구 디스크(pd-standard)
- 순차 I/O를 주로 사용하는 대용량 데이터 처리 워크로드에 적합
- 표준 하드 디스크 드라이브(HDD)에서 지원
균형 있는 영구 디스크(pd-balanced)
- 성능(pd-ssd) 영구 디스크의 대안
- 성능과 비용 간의 균형. 대용량 VM을 제외한 대부분의 VM 형태에서 이러한 디스크의 최대 IOPS는 SSD 영구 디스크와 같고 1GB당 IOPS는 낮습니다. 이 디스크 유형은 대부분의 범용 애플리케이션에 적합한 성능 수준을 표준 영구 디스크와 성능(pd-ssd) 영구 디스크 사이의 가격으로 제공합니다.
- 솔리드 스테이트 드라이브(SSD)에서 지원합니다.
성능(SSD) 영구 디스크(pd-ssd)
- 표준 영구 디스크보다 짧은 지연 시간과 더 많은 IOPS가 필요한 엔터프라이즈 애플리케이션 및 고성능 데이터베이스에 적합합니다.
- 한 자릿수의 밀리초 지연 시간으로 설계되었습니다. 관찰된 지연 시간은 애플리케이션에 따라 다릅니다.
- 솔리드 스테이트 드라이브(SSD)에서 지원합니다.
익스트림 영구 디스크(pd-extreme)
- 임의 액세스 워크로드와 일괄 처리량 모두에 고성능을 일관되게 제공합니다.
- Oracle 또는 SAP HANA와 같은 고급 데이터베이스 워크로드를 위해 설계되었습니다.
- 대상 IOPS 프로비저닝할 수 있습니다.
- 솔리드 스테이트 드라이브(SSD)에서 지원합니다.
- 제한된 수의 머신 유형으로 사용할 수 있습니다.

Google Cloud 콘솔에서 디스크를 만드는 경우 기본 디스크 유형은 pd-balanced입니다. gcloud CLI 또는 Compute Engine API를 사용하여 디스크를 만드는 경우 기본 디스크 유형은 pd-standard입니다.

머신 유형 지원에 대한 자세한 내용은 다음을 참조하세요.

영구 디스크의 내구성

디스크 내구성은 Google 데이터 센터에서 하드웨어 오류, 치명적인 이벤트가 발생할 가능성, 격리 방식, 엔지니어링 프로세스에 대한 가정과 함께 각 디스크 유형에 사용되는 내부 인코딩을 고려해서 일반적인 기간 동안 일반적인 디스크를 사용할 때 기본적으로 데이터 손실이 발생할 가능성을 나타냅니다. 영구 디스크 데이터 손실 이벤트는 발생할 가능성이 매우 낮으며, 지금까지 하드웨어 조정 오류, 소프트웨어 버그 또는 이 둘의 조합의 결과로 발생했습니다. Google은 또한 산업 전반에서 자동 데이터 손상이 발생할 위험을 완화하기 위해 많은 조치를 취하고 있습니다 고객의 실수로 인한 디스크 삭제와 같은 Google Cloud 고객의 작업자 오류는 영구 디스크 내구성의 범위에서 벗어납니다.

내부 데이터 인코딩과 복제로 인해 리전 영구 디스크에서 데이터 손실이 발생할 위험이 매우 적습니다. 리전 영구 디스크는 영역 영구 디스크보다 두 배 더 많은 복제본을 제공하고 동일한 리전의 두 영역 사이에 복제본을 분산하므로 고가용성을 제공하고 전체 데이터 센터가 손실되어 복구할 수 없는 경우(발생 가능성은 희박) 재해 복구에 사용될 수 있습니다. 장기 중단 중에 기본 영역을 사용할 수 없게 되면 두 번째 영역의 추가 복제본에 즉시 액세스할 수 있습니다.

내구성은 각 디스크 유형의 집계에 포함되며 재정적으로 지원되는 서비스수준계약(SLA)을 나타내지 않습니다.

다음 표는 각 디스크 유형의 설계에 대한 내구성을 보여줍니다. 99.999% 내구성은 디스크 1,000개를 디스크 하나가 손실되지 않고 수백 년 동안 사용할 수 있다는 의미입니다.

영역별 표준 영구 디스크	영역별 균형 있는 영구 디스크	영역별 SSD 영구 디스크	영역별 익스트림 영구 디스크	리전별 표준 영구 디스크	리전별로 균형 있는 영구 디스크	리전별 SSD 영구 디스크
99.99%보다 좋음	99.999%보다 좋음	99.999%보다 좋음	99.9999%보다 좋음	99.999%보다 좋음	99.9999%보다 좋음	99.9999%보다 좋음

영역 영구 디스크

사용 편의성

Compute Engine에서 디스크 관리 작업을 대부분 처리하므로 사용자가 파티션 나누기, 중복 디스크 배열, 하위 볼륨 관리를 수행할 필요가 없습니다. 일반적으로 더 큰 논리 볼륨을 만들 필요는 없지만 원하는 경우 보조 연결 영구 디스크 용량을 인스턴스당 257TB로 확장하고 이 방식을 영구 디스크에 적용할 수 있습니다. 파티션 테이블이 없는 단일 파일 시스템으로 영구 디스크를 포맷하면 시간을 절약하고 최고의 성능을 얻을 수 있습니다.

데이터를 여러 개의 고유한 볼륨으로 분리해야 하는 경우 기존 디스크를 여러 파티션으로 나누는 대신 추가 디스크를 생성합니다.

영구 디스크에 추가 공간이 필요하면 파티션을 다시 나누고 포맷하는 대신 디스크 크기를 조절합니다.

성능

영구 디스크 성능은 예측 가능하여 인스턴스에서 프로비저닝된 vCPU의 제한에 도달할 때까지 프로비저닝된 용량을 따라 선형적으로 확장됩니다. 성능 확장 제한과 최적화에 대한 자세한 내용은 성능 요구사항을 충족하도록 디스크 구성을 참조하세요.

표준 영구 디스크는 순차 읽기/쓰기 작업을 처리하는 데 효율적이고 경제적이지만 고속 무작위 초당 입출력 작업(IOPS)을 처리하는 데는 최적화되어 있지 않습니다. 앱에서 높은 속도의 무작위 IOPS가 필요한 경우 SSD 또는 익스트림 영구 디스크를 사용하세요. SSD 영구 디스크는 한 자릿수의 밀리초 지연 시간을 위해 설계되었습니다. 확인된 지연 시간은 애플리케이션에 따라 다릅니다.

Compute Engine은 영구 디스크의 성능과 확장을 자동으로 최적화합니다. 최적의 성능을 얻기 위해 디스크를 여러 개 스트라이프하거나 미리 가동하지 않아도 됩니다. 추가 디스크 공간이나 더 높은 성능이 필요한 경우 디스크 크기를 조절하고 vCPU를 더 추가하여 저장공간, 처리량, IOPS를 더 늘릴 수 있습니다. 영구 디스크 성능은 인스턴스에 연결된 총 영구 디스크 용량 및 인스턴스에 있는 vCPU 수를 기반으로 합니다.

부팅 기기일 때는 표준 영구 디스크를 사용해 비용을 줄일 수 있습니다. 기본적인 부팅 및 패키지 관리 사용 사례에서는 작은 용량인 10GB 영구 디스크로도 충분할 수 있습니다. 하지만 부팅 기기를 더욱 포괄적으로 사용할 수 있는 일관된 성능을 보장하려면 균형 있는 영구 디스크를 부팅 디스크로 사용합니다.

각 영구 디스크 쓰기 작업은 인스턴스의 누적 네트워크 이그레스 트래픽에 영향을 줍니다. 즉, 영구 디스크 쓰기 작업이 인스턴스의 네트워크 이그레스 상한으로 제한됩니다.

신뢰성

영구 디스크에는 장비 고장 시 데이터를 보호하고, 데이터 센터 유지보수 이벤트를 통해 데이터 가용성을 보장하는 중복 기능이 내장되어 있습니다. 모든 영구 디스크 작업에 대해 체크섬이 계산되므로 현재 읽고 있는 데이터가 사용자가 기록한 데이터임을 보장할 수 있습니다.

또한 영구 디스크 스냅샷을 생성하여 사용자 오류로 인한 데이터 손실을 방지할 수 있습니다. 스냅샷은 증분적이며 실행 중인 인스턴스에 연결된 디스크를 스냅샷으로 작성할 경우에도 몇 분이면 생성됩니다.

멀티 작성자 모드

최대 2개의 N2 VM에 SSD 영구 디스크를 멀티 작성자 모드로 동시에 연결하여 두 VM에서 모두 디스크를 읽고 쓸 수 있습니다. 멀티 작성자 모드의 영구 디스크는 공유 블록 스토리지 기능을 제공하고 분산된 네트워크 파일 시스템(NFS) 및 비슷한 고가용성 서비스를 빌드하기 위한 인프라 기초를 제공합니다. 하지만 멀티 작성자 모드의 영구 디스크는 GlusterFS 또는 GFS2와 같은 특별한 파일 시스템이 필요합니다. EXT4, XFS, NTFS와 같은 많은 파일 시스템은 공유 블록 스토리지와 함께 사용하도록 설계되지 않았습니다. VM 간에 영구 디스크를 공유할 때의 권장사항은 권장사항을 참조하세요. 완전 관리형 파일 스토리지가 필요하면 Compute Engine VM에 Filestore 파일 공유를 마운트할 수 있습니다.

새 영구 디스크에 멀티 작성자 모드를 사용 설정하려면 새 영구 디스크를 만들고 gcloud CLI에서 --multi-writer 플래그를 지정하거나 Compute Engine API에서 multiWriter 속성을 지정합니다. 자세한 내용은 VM 간 영구 디스크 공유를 참조하세요.

영구 디스크 암호화

Compute Engine은 데이터가 인스턴스 외부에서 영구 디스크 저장공간으로 이동하기 전에 데이터를 자동으로 암호화합니다. 각 영구 디스크는 시스템 정의 키 또는 고객 제공 키를 사용하여 암호화된 상태로 유지됩니다. Google은 사용자가 제어하지 않는 방식으로 영구 디스크 데이터를 여러 물리적 디스크에 분산시킵니다.

영구 디스크를 삭제하면 Google은 데이터를 복구할 수 없도록 암호화 키를 삭제합니다. 이 프로세스는 되돌릴 수 없습니다.

데이터를 암호화하는 데 사용되는 암호화 키를 제어하려면 자체 암호화 키를 사용하여 디스크를 생성하세요.

제한사항

다른 프로젝트의 인스턴스에 영구 디스크를 연결할 수 없습니다.
균형 있는 영구 디스크를 최대 10개의 VM 인스턴스에 읽기 전용 모드로 연결할 수 있습니다.
vCPU가 최소 1개 있는 커스텀 머신 유형 또는 사전 정의된 머신 유형의 경우 영구 디스크를 최대 128개까지 연결할 수 있습니다.
각 영구 디스크의 용량은 최대 64TB까지 가능하므로 대용량의 논리 볼륨을 생성하기 위해 다수의 디스크 배열을 관리할 필요가 없습니다. 각 인스턴스는 제한된 양의 총 영구 디스크 공간과 제한된 수의 개별 영구 디스크에만 연결할 수 있습니다. 사전 정의된 머신 유형 및 커스텀 머신 유형에는 동일한 영구 디스크 제한이 적용됩니다.
대부분의 인스턴스에는 영구 디스크를 최대 128개까지 그리고 총 영구 디스크 공간을 최대 257TB까지 연결할 수 있습니다. 인스턴스의 총 영구 디스크 공간에는 부팅 영구 디스크 크기가 포함됩니다.
공유 코어 머신 유형은 16개의 영구 디스크 및 총 3TB의 총 영구 디스크 공간으로 제한됩니다.
64TB보다 큰 논리 볼륨을 만들려면 특별한 고려가 필요합니다. 더 큰 논리 볼륨의 성능에 대한 자세한 내용은 논리 볼륨 크기를 참조하세요.

리전 영구 디스크

리전 영구 디스크의 스토리지 품질은 영역 영구 디스크와 유사합니다. 그러나 리전 영구 디스크는 내구성 있는 스토리지를 제공하고 동일한 리전의 두 영역 간 데이터 복제를 지원합니다.

Compute Engine에서 강력한 시스템을 설계하고 있거나 고가용성 서비스를 설계하고 있다면 스냅샷을 사용하여 데이터를 백업하는 등의 다른 권장사항과 함께 리전 영구 디스크를 사용하세요. 또한 리전 영구 디스크는 리전 관리형 인스턴스 그룹과 함께 사용하도록 설계되었습니다.

드물게 영역 장애가 발생하는 경우 일반적으로 --force-attach 플래그를 사용하여 리전 영구 디스크에서 실행 중인 워크로드를 다른 영역으로 장애 조치할 수 있습니다. --force-attach 플래그를 사용하면 디스크를 사용할 수 없어 원래 VM에서 분리할 수 없는 리전 영구 디스크도 대기 VM 인스턴스에 연결할 수 있습니다. 자세한 내용은 리전 영구 디스크 장애 조치를 참조하세요. 영역 영구 디스크는 인스턴스에 강제로 연결할 수 없습니다.

성능

리전 영구 디스크는 영구 디스크 스냅샷을 사용할 때와 비교 시 더 낮은 복구 지점 목표(RPO)와 복구 시간 목표(RTO)가 필요한 워크로드용으로 설계되었습니다.

리전 영구 디스크는 쓰기 성능이 여러 영역의 데이터 중복보다 중요하지 않은 경우에 사용할 수 있는 옵션입니다.

영역 영구 디스크와 마찬가지로 리전 영구 디스크도 vCPU의 수를 늘리면 인스턴스에서 IOPS 및 처리량 성능을 향상시킬 수 있습니다. 이 제한 및 기타 제한에 대한 자세한 내용은 성능 요구사항을 충족하도록 디스크 구성을 참조하세요.

추가 디스크 공간이나 더 높은 성능이 필요한 경우 리전 디스크 크기를 조절하여 추가 저장소 공간, 처리량, IOPS를 추가할 수 있습니다.

신뢰성

Compute Engine은 사용자가 디스크를 생성하면 선택한 영역으로 리전 영구 디스크의 데이터를 복제합니다. 중복을 보장하기 위해 각 복제본의 데이터는 영역 내의 여러 물리적 머신에 분산됩니다.

영역 영구 디스크와 마찬가지로 영구 디스크의 스냅샷 만들기로 사용자 오류로 인한 데이터 손실을 방지할 수 있습니다. 스냅샷은 증분적이며 실행 중인 인스턴스에 연결된 디스크를 스냅샷으로 작성할 경우에도 몇 분이면 생성됩니다.

제한사항

리전 PD는 E2, N1, N2, N2D 머신 유형 VM에서만 지원됩니다.
리전 영구 디스크를 부팅 디스크로 사용할 수 없습니다.
리전별로 균형 있는 영구 디스크를 최대 10개의 VM 인스턴스에 읽기 전용 모드로 연결할 수 있습니다.
스냅샷에서 리전 영구 디스크를 만들 수 있지만 이미지에서는 만들 수 없습니다.
리전 표준 영구 디스크 최소 크기는 200 GB입니다.
리전 영구 디스크 크기 조절은 크기 증가만 지원합니다.
리전 영구 디스크는 영역 영구 디스크와 다르게 작동합니다. 자세한 내용은 블록 스토리지 성능을 참조하세요.

하이퍼디스크

Compute Engine을 위한 Google Cloud 하이퍼디스크 익스트림은 사용 가능한 가장 빠른 블록 스토리지를 제공합니다. 가장 높은 처리량과 IOPS가 필요한 하이엔드 워크로드에 적합합니다.

하이퍼디스크 익스트림 볼륨을 사용하면 워크로드에 대해 용량과 IOPS를 독립적으로 조정할 수 있습니다. 스토리지 크기와 성능이 인스턴스 유형 및 크기와 분리되어 유연성이 더 뛰어납니다.

하이퍼디스크 익스트림 볼륨은 Persistent Disk와 비슷하게 생성 및 관리되지만 프로비저닝된 IOPS 수준을 설정하고 값을 언제나 변경할 수 있는 추가 기능이 있습니다. 익스트림 Persistent Disk에서 하이퍼디스크 익스트림 볼륨으로 직접 마이그레이션할 수는 없습니다. 대신 스냅샷을 만들고 이 스냅샷을 새로운 하이퍼디스크 익스트림 볼륨에 복원할 수 있습니다.

하이퍼디스크에 대한 자세한 내용은 하이퍼디스크 정보를 참조하세요.

하이퍼디스크 암호화

Compute Engine은 하이퍼디스크 볼륨에 쓰기를 수행할 때 데이터를 자동으로 암호화합니다.

하이퍼디스크의 데이터 지속성

디스크 내구성은 일반적인 기간 및 일반적인 디스크를 기준으로 기본적인 데이터 손실 가능성을 나타냅니다. 내구성은 다음과 같이 하드웨어 오류에 대한 일련의 가정을 통해 계산됩니다.

치명적인 이벤트 가능성
격리 방식
Google 데이터 센터의 엔지니어링 프로세스
각 디스크 유형에 사용되는 내부 인코딩

하이퍼디스크 익스트림은 99.9999%가 넘는 내구성을 제공합니다.

로컬 SSD

로컬 SSD는 VM 인스턴스를 호스팅하는 서버에 물리적으로 연결됩니다. 로컬 SSD는 표준 영구 디스크 또는 SSD 영구 디스크보다 처리량이 높고 지연 시간이 짧습니다. 로컬 SSD에 저장한 데이터는 인스턴스가 중지 또는 삭제될 때까지만 유지됩니다. 각 로컬 SSD의 크기는 375GB지만 최대 24개의 로컬 SSD 파티션을 연결하여 인스턴스당 총 9TB로 확대할 수 있습니다.

고속 스크래치 디스크 또는 캐시가 필요하지만 인스턴스 메모리를 사용하지 않으려면 로컬 SSD로 인스턴스를 만듭니다.

로컬 SSD로 인스턴스 생성

성능

로컬 SSD는 매우 높은 IOPS와 낮은 지연 시간을 제공하도록 설계되었습니다. 영구 디스크와 달리 사용자가 로컬 SSD의 스트라이핑을 직접 관리해야 합니다. 여러 로컬 SSD 파티션을 단일 논리 볼륨으로 결합하여 인스턴스당 최고 로컬 SSD 성능을 얻거나 로컬 SSD 파티션을 개별적으로 포맷합니다.

로컬 SSD 성능은 선택한 인터페이스에 따라 달라집니다. SCSI 및 NVMe 인터페이스를 통해 로컬 SSD를 사용할 수 있습니다.

다음 표에서는 NVMe를 사용하여 로컬 SSD 용량 및 예상 성능을 대략적으로 설명합니다. N1 머신 유형으로 최대 성능 한도에 도달하려면 vCPU를 32개 이상 사용합니다. N2 및 N2D 머신 유형의 최대 성능 한도에 도달하려면 vCPU를 24개 이상 사용합니다.

저장공간	파티션
		읽기	쓰기	읽기	쓰기
3TB	8	680,000	360,000	2,650	1,400
6TB	16	1,600,000	800,000	6,240	3,120
9TB	24	2,400,000	1,200,000	9,360	4,680

자세한 내용은 로컬 SSD 성능 및 로컬 SSD 성능 최적화를 참조하세요.

로컬 SSD 암호화

Compute Engine은 데이터가 로컬 SSD 저장공간에 작성되면 데이터를 자동으로 암호화합니다. 로컬 SSD에서는 고객 제공 암호화 키를 사용할 수 없습니다.

로컬 SSD의 데이터 지속성

로컬 SSD 데이터 지속성을 읽고 로컬 SSD 데이터를 보존하는 이벤트와 로컬 SSD 데이터를 복구할 수 없는 이벤트를 알아보세요.

일반 제한사항

6TB 또는 9TB의 로컬 SSD 공간에 대해 16개 또는 24개의 로컬 SSD 파티션이 있는 인스턴스를 만들 수 있습니다. N1, N2, N2D 및 커스텀 머신 유형의 인스턴스에서 사용할 수 있습니다. 최대 IOPS 한도에 도달하려면 vCPU가 32개 이상인 VM 인스턴스를 사용합니다.
공유 코어 머신 유형의 인스턴스에서는 로컬 SSD 파티션을 연결할 수 없습니다.
E2, Tau T2D, Tau T2A, M2 머신 유형에는 로컬 SSD를 연결할 수 없습니다.

로컬 SSD 및 머신 유형

달리 명시되지 않은 한 Compute Engine에서 사용 가능한 대부분의 머신 유형에 로컬 SSD를 연결할 수 있습니다. 하지만 각 머신 유형에 따라 연결할 수 있는 로컬 SSD 수에 제약이 따릅니다.

N1 머신 유형	VM 인스턴스당 허용되는 로컬 SSD 파티션 수
모든 N1 머신 유형	1~8개, 16개 또는 24개
N2 머신 유형
vCPU가 2개~10개인 머신 유형	1, 2, 4, 8, 16 또는 24
vCPU가 12개~20개인 머신 유형	2, 4, 8, 16 또는 24
vCPU가 22개~40개인 머신 유형	4, 8, 16 또는 24
vCPU가 42개~80개인 머신 유형	8, 16 또는 24
vCPU가 82개~128개인 머신 유형	16 또는 24
N2D 머신 유형
vCPU가 2개~16개인 머신 유형	1, 2, 4, 8, 16 또는 24
vCPU가 32개 또는 48개인 머신 유형	2, 4, 8, 16 또는 24
vCPU가 64개 또는 80개인 머신 유형	4, 8, 16 또는 24
vCPU가 96개~224개인 머신 유형	8, 16 또는 24
C2 머신 유형
vCPU가 4개 또는 8개인 머신 유형	1개, 2개, 4개 또는 8개
vCPU가 16개인 머신 유형	2개, 4개 또는 8개
vCPU가 30개인 머신 유형	4개 또는 8개
vCPU가 60개인 머신 유형	8
C2D 머신 유형
vCPU가 2개~16개인 머신 유형	1, 2, 4, 8
vCPU가 32개인 머신 유형	2, 4, 8
vCPU가 56개인 머신 유형	4, 8
vCPU가 112개인 머신 유형	8
A2 머신 유형
`a2-highgpu-1g`	1개, 2개, 4개 또는 8개
`a2-highgpu-2g`	2개, 4개 또는 8개
`a2-highgpu-4g`	4개 또는 8개
`a2-highgpu-8g` 또는 `a2-megagpu-16g`	8
M1 머신 유형
`m1-ultramem-40`	사용 불가능
`m1-ultramem-80`	사용 불가능
`m1-megamem-96`	1개~8개
`m1-ultramem-160`	사용 불가능
M3 머신 유형
`m3-ultramem-32`	4, 8
`m3-megamem-64`	4, 8
`m3-ultramem-64`	4, 8
`m3-megamem-128`	8
`m3-ultramem-128`	8
E2, Tau T2D, Tau T2A, M2 머신 유형	이러한 머신 유형은 로컬 SSD 드라이브를 지원하지 않습니다.

로컬 SSD 및 선점형 VM 인스턴스

로컬 SSD로 선점형 VM 인스턴스를 시작할 수 있으며, Compute Engine에서는 로컬 SSD 사용료에 Spot 가격을 청구합니다. 선점형 인스턴스에 연결된 로컬 SSD는 일반 로컬 SSD처럼 작동하고, 동일한 데이터 지속성 특성을 유지하며, 인스턴스 수명 기간 동안 연결된 상태로 유지됩니다.

인스턴스가 실행 후 1분 이내에 선점되는 경우 Compute Engine은 로컬 SSD에 대한 비용을 청구하지 않습니다.

로컬 SSD에 대한 자세한 내용은 로컬 SSD 추가를 참조하세요.

약정 사용 할인으로 로컬 SSD 예약

특정 영역에서 로컬 SSD 리소스를 예약하려면 영역 리소스 예약을 참조하세요. 로컬 SSD의 약정 사용 가격을 적용하려면 예약이 필요합니다.

Cloud Storage 버킷

Cloud Storage 버킷은 VM 인스턴스에 가장 적합한 유연성과 내구성을 갖춘 확장 가능한 스토리지 옵션입니다. 앱에서 영구 디스크와 로컬 SSD의 낮은 지연 시간이 필요하지 않은 경우 Cloud Storage 버킷에 데이터를 저장할 수 있습니다.

대기 시간과 처리량이 중요하지 않은 경우와 여러 인스턴스 또는 영역 간에 데이터를 쉽게 공유해야 하는 경우 인스턴스를 Cloud Storage 버킷에 연결합니다.

성능

Cloud Storage 버킷의 성능은 선택한 스토리지 클래스 및 인스턴스와 관련된 버킷의 위치에 따라 달라집니다.

사용자의 인스턴스와 동일한 위치에서 사용된 표준 스토리지 클래스는 영구 디스크와 맞먹는 성능을 제공하지만 지연 시간이 길고 일관성 있는 처리량 특성이 떨어집니다. 멀티 리전 위치에서 사용된 표준 스토리지 클래스는 대규모 멀티 리전 위치 내에 있는 둘 이상의 리전에 데이터를 중복 저장합니다.

Nearline 및 Coldline 스토리지 클래스는 기본적으로 장기간 데이터 보관을 위한 것입니다. 표준 스토리지 클래스와 달리 이 보관 클래스는 저장 기간이 가장 짧고 읽기 요금이 가장 낮습니다. 따라서 자주 액세스하지 않는 데이터의 장기 스토리지로 적합합니다.

신뢰성

모든 Cloud Storage 버킷에는 장비 고장 시 데이터를 보호하고, 데이터 센터 유지보수 이벤트를 통해 데이터 가용성을 보장하는 중복 기능이 내장되어 있습니다. 모든 Cloud Storage 작업에 대해 체크섬이 계산되므로 현재 읽고 있는 데이터가 사용자가 기록한 데이터임을 보장할 수 있습니다.

유연성

영구 디스크와 달리 Cloud Storage 버킷은 인스턴스가 있는 영역으로 제한되지 않습니다. 또한 여러 인스턴스에서 버킷으로 데이터를 동시에 읽고 쓸 수 있습니다. 예를 들어 여러 영역의 영구 디스크에 데이터를 복제하지 않고 동일한 버킷에 데이터를 읽고 쓰도록 여러 영역에서 인스턴스를 구성할 수 있습니다.

Cloud Storage 암호화

Compute Engine은 데이터가 인스턴스 외부에서 Cloud Storage 버킷으로 이동하기 전에 해당 데이터를 자동으로 암호화합니다. 버킷에 쓰기 전에 인스턴스의 파일을 암호화할 필요가 없습니다.

영구 디스크와 마찬가지로 자체 암호화 키로 버킷을 암호화할 수 있습니다.

Cloud Storage 버킷에서 데이터 읽기 및 쓰기

gsutil 명령줄 도구 또는 Cloud Storage API를 사용하여 Cloud Storage 버킷에서 파일을 읽고 씁니다.

gsutil

기본적으로 gsutil 명령줄 도구는 공개 이미지가 사용되는 대부분의 VM에 설치됩니다. VM에 gsutil 명령줄 도구가 없으면 gsutil을 Google Cloud CLI의 일부로 설치할 수 있습니다.

인스턴스에 연결합니다.
1. Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.
  VM 인스턴스로 이동
2. 가상 머신 인스턴스 목록에서 연결할 인스턴스 행의 SSH를 클릭합니다.
이전에 이 인스턴스에서 gsutil을 사용한 적이 없는 경우 gcloud CLI를 사용하여 사용자 인증 정보를 설정합니다.
```
gcloud init
```
Cloud Storage 범위가 있는 서비스 계정을 사용하도록 인스턴스를 구성한 경우에는 이 단계를 건너뛰어도 됩니다.
gsutil 도구를 사용하여 버킷을 만들고, 버킷에 데이터를 쓰고, 이 버킷에서 데이터를 읽습니다. 특정 버킷에서 데이터를 읽거나 쓰려면 버킷에 대한 액세스 권한이 있어야 합니다. 또는 공개적으로 액세스할 수 있는 버킷에서 데이터를 읽을 수 있습니다.

원하는 경우 Cloud Storage에 데이터를 스트리밍할 수도 있습니다.

API

Cloud Storage 범위가 있는 서비스 계정을 사용하도록 인스턴스를 구성한 경우 Cloud Storage API를 사용하여 Cloud Storage 버킷에서 데이터를 읽고 쓸 수 있습니다.

인스턴스에 연결합니다.
1. Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.
  VM 인스턴스로 이동
2. 가상 머신 인스턴스 목록에서 연결할 인스턴스 행의 SSH를 클릭합니다.
원하는 언어의 클라이언트 라이브러리를 설치 및 구성합니다.
필요한 경우 삽입 코드 샘플을 따라 인스턴스에서 Cloud Storage 버킷을 만듭니다.
데이터 쓰기 및 데이터 읽기 삽입 코드 샘플을 따라 Cloud Storage 버킷에서 파일을 읽거나 쓰는 코드를 앱에 포함합니다.

다음 단계

직접 사용해 보기

Google Cloud를 처음 사용하는 경우 계정을 만들어 실제 시나리오에서 Compute Engine의 성능을 평가할 수 있습니다. 신규 고객에게는 워크로드를 실행, 테스트, 배포할 수 있는 무료 크레딧 $300가 제공됩니다.

Compute Engine 무료로 사용해 보기