Azure 전문가를 위한 Google Cloud: 스토리지

업데이트: 2019년 4월 24일

Microsoft Azure와 Google Cloud에서 제공하는 스토리지 서비스를 비교합니다. 이 문서에서는 다음 서비스 유형을 설명합니다.

  • 분산된 객체 스토리지 또는 데이터 객체를 저장할 수 있는 중복 키-값 저장소
  • 블록 스토리지 또는 가상 머신 인스턴스에 연결할 수 있는 가상 디스크 볼륨
  • 파일 스토리지 또는 네트워크에 연결된 파일 서버 기반 스토리지
  • 스토리지 영역 네트워크 또는 블록 수준의 스토리지 액세스를 제공하는 원격 스토리지
  • 쿨 스토리지 또는 데이터 백업을 보관하도록 설계된 스토리지 서비스
  • 아카이브 스토리지 또는 규정 준수나 분석 목적으로 아카이브 데이터를 보관하도록 디자인된 스토리지 서비스

데이터베이스 또는 메시지 큐는 이 문서에서 다루지 않습니다.

서비스 모델 비교

Microsoft Azure와 Google Cloud는 스토리지 서비스의 상위 수준 조직 및 구성에서 서로 다른 접근 방식을 취합니다. 하지만 실제로 스토리지 서비스 자체는 겉보기와 달리 비슷한 경우가 많습니다.

Microsoft Azure

Azure에서는 바이너리 객체(Blob), 데이터베이스, 메시지 큐를 비롯한 다양한 유형의 데이터를 스토리지 계정 내의 특정 서비스에 저장합니다. Azure를 사용하려면 스토리지 계정 수준에서 계정 유형, 디스크 유형, 중복 유형을 정의해야 합니다. 이러한 속성은 해당 계정 내의 모든 스토리지 서비스에 적용됩니다.

Azure 스토리지 계정은 general-purpose v1(GPv1), Blob 특정, general-purpose v2(GPv2)의 세 가지 유형으로 제공됩니다. GPv1 계정은 Azure의 모든 표준 스토리지 유형을 지원할 수 있으며, Blob 특정 계정은 Azure Blob Storage를 위한 고급 기능을 지원하도록 디자인되었습니다. GPv2 계정은 다른 두 계정 유형의 API와 기능을 지원합니다.

Blob 특정 계정은 HDD(하드 디스크 드라이브)에서만 실행되지만 두 가지 범용 계정 유형은 다시 HDD에서 실행되는 표준 스토리지 계정과 SSD(솔리드 스테이트 드라이브)에서 실행되는 프리미엄 스토리지 계정으로 나뉩니다. 후자의 계정 유형에서는 페이지 Blob만 지원됩니다.

새로운 Azure 스토리지 계정을 만들 때는 사용하려는 복제 수준을 선택합니다. Azure에서 제공되는 수준은 다음과 같습니다.

  • LRS(로컬 중복 스토리지)는 스토리지 계정이 포함된 데이터 센터 내에 데이터를 로컬로 복제합니다. 데이터는 세 번 복제됩니다.
  • ZRS(영역(zone) 중복 스토리지)는 최종 일관성을 사용해서 1개 또는 2개의 영역(zone)에 데이터를 복제합니다. LRS와 마찬가지로 데이터가 로컬로 세 번 복제됩니다. ZRS는 범용 스토리지 계정의 블록 Blob 스토리지로 제한됩니다.
  • GRS(지리 중복 스토리지)는 기본 리전과 여기에서 최소 160km 이상 떨어진 보조 리전에 데이터를 복제합니다. 데이터는 기본 리전에 세 번 복제된 후 보조 리전에서도 세 번 비동기적으로 복제됩니다.
  • RA-GRS(읽기 액세스 지리적 중복 스토리지)는 GRS와 동일하지만 보조 리전에 읽기 전용 보조 엔드포인트가 추가됩니다.

Google Cloud

Azure와 마찬가지로 Google Cloud는 유형별 서비스 내에 각 데이터 유형을 저장합니다. 하지만 Google Cloud에는 스토리지 계정과 같은 상위 조직 레이어가 없습니다. 대신 스토리지 리소스를 만들고 디스크 유형이나 중복 유형과 같은 리소스 속성을 서비스 수준에서 정의합니다.

분산 객체 스토리지의 경우 Google Cloud는 Azure Blob Storage의 블록 및 추가 Blob 스토리지와 비슷한 Cloud Storage를 제공합니다. 블록 스토리지의 경우 Google Cloud는 Azure VHD와 동일한 Compute Engine 영구 디스크를 제공합니다.

분산 객체 스토리지

분산 객체 스토리지의 경우 Azure는 Azure Blob Storage를 제공하고 Google Cloud는 Cloud Storage를 제공합니다.

Azure Blob Storage와 Cloud Storage는 비슷한 점이 많습니다. 두 서비스 모두, 개발자는 이름이 지정된 스토리지 단위에 바이너리 객체를 저장합니다. Azure Blob Storage에서는 이러한 바이너리 객체를 Blob이라고 부르고, 스토리지 단위를 컨테이너라고 부릅니다. Cloud Storage에서는 이러한 바이너리 객체를 객체라 하고 스토리지 단위를 버킷이라 합니다.

두 서비스 모두, 스토리지 단위 내의 각 바이너리 객체는 스토리지 단위 내의 고유 키로 식별되며, 각 객체에는 연관된 메타데이터 레코드가 포함됩니다. 이 메타데이터 레코드에는 객체 크기, 마지막 수정 날짜, 미디어 유형과 같은 정보가 포함됩니다. 적합한 권한이 있으면 이 메타데이터 중 일부를 보고 수정할 수 있습니다. 또한 필요에 따라 커스텀 메타데이터를 추가할 수도 있습니다.

컨테이너와 버킷 모두 키-값 저장소이지만, 각 저장소의 사용자 환경은 파일 시스템과 같진 않더라도 상당히 비슷합니다. 일반적으로 객체 키는 '/foo/bar.txt' 또는 '/foo/subdir/baz.txt'와 같은 경로입니다. Azure와 Cloud Storage 모두 파일 시스템과 비슷한 API를 제공합니다. 예를 들어 Azure Blob Storage의 List Blobs 메서드와 Cloud Storage의 list 메서드는 모두 Unix와 같은 파일 시스템의 ls -R과 달리 일반 프리픽스를 사용하여 모든 객체 키를 나열할 수 있습니다.

두 서비스는 가장 명확한 용도인 분산 객체 스토리지 외에도 정적 웹 콘텐츠 및 미디어를 호스팅하는 데 사용될 수 있습니다.

Azure Blob Storage와 Cloud Storage의 기능 및 용어는 다음과 같이 비교될 수 있습니다.

기능 Azure Blob Storage Cloud Storage
배포 단위 컨테이너 버킷
배포 식별자 계정 수준 고유 키 전역 고유 키
파일 시스템 에뮬레이션 제한됨 제한됨
객체 유형 블록 Blob, 추가 Blob, 페이지 Blob 객체
객체 메타데이터
객체 버전 관리 수동, 객체별 스냅샷 생성 버킷에 있는 모든 객체의 자동 버전 관리(사용하도록 설정되어야 함)
객체 수명 주기 관리 예(수명 주기 규칙 또는 Azure Automation 사용) 예(기본)
객체 변경 알림 예(Azure Event Grids 사용) 예(Pub/Sub 사용)
서비스 클래스 중복 수준: LRS, ZRS, GRS, RA-GRS
계층: Hot, Cool, Archive
Standard, Nearline, Coldline, Archive
배포 지역 영역 및 리전 리전 및 멀티 리전
중복

Blob 유형

Azure Blob Storage에서는 데이터를 블록 Blob, 추가 Blob 또는 페이지 Blob으로 저장합니다. Cloud Storage에서는 모든 데이터를 블록 Blob과 동일한 객체로 저장합니다. Google Cloud에서는 추가 Blob과 직접 비교할 수 있는 서비스 또는 객체 유형을 제공하지 않습니다. 하지만 Cloud Storage의 객체 조합 기능과 동시성 제어를 사용해서 추가 Blob과 비슷한 기능을 얻을 수 있습니다. 자세한 내용은 객체 조합 및 병렬 업로드를 참조하세요.

Azure와 달리 Google Cloud에서는 객체 스토리지 서비스 내에 디스크 볼륨을 페이지 Blob으로 저장하지 않습니다. 대신 디스크 볼륨은 Google Cloud의 Infrastructure-as-a-Service인 Compute Engine에 저장됩니다. 자세한 내용은 블록 스토리지를 참조하세요.

액세스 계층 및 복제

Azure Blob Storage의 유연성은 개발자가 만든 스토리지 계정의 유형 및 해당 계정에 대해 선택된 복제 옵션에 따라 달라집니다. GPv1 스토리지 계정을 사용하는 경우 Blob 스토리지에 대한 Azure의 기본 계층으로 제한됩니다. 하지만 Blob 특정 또는 GPv2 스토리지 계정을 사용하는 경우에는 Azure Blob Storage에 대해 핫, 쿨, 아카이브 액세스 계층 중에서 선택할 수 있습니다. 핫 계층은 자주 액세스되는 데이터용으로 디자인되었고, 쿨 계층은 가끔 액세스되는 데이터용으로 디자인되었고, 아카이브 계층은 데이터 아카이브용으로 디자인되었습니다. Azure Blob Storage 서비스의 복제 수준은 스토리지 계정의 복제 유형에 따라 결정됩니다.

반면에 Cloud Storage의 복제 유형은 해당 서비스 클래스에 내장되어 있습니다. 이러한 서비스 클래스와 Azure Blob Storage 액세스 계층 및 복제 유형은 다음과 같이 비교됩니다.

구성 Azure Google Cloud
자주 액세스하는 데이터와 지리적 중복 Azure Blob Storage(범용 또는 핫 계층)와 GRS 또는 RA-GRS 멀티 리전 또는 이중 리전의 표준 스토리지
자주 액세스하는 데이터와 리전 중복 Azure Blob Storage(범용)와 ZRS 리전의 표준 스토리지
자주 액세스하는 데이터와 로컬(데이터 센터) 중복 Azure Blob Storage(범용 또는 핫 계층)와 LRS 리전의 표준 스토리지*
가끔 액세스하는 데이터 Azure Blob Storage 쿨 계층 Cloud Storage Nearline 및 Cloud Storage Coldline
보관 데이터 Azure Blob Storage 보관 계층 Cloud Storage Archive

* 리전 중복은 Google Cloud에서 사용할 수 있는 가장 낮은 수준의 중복입니다.

객체 버전 관리

Azure와 Cloud Storage 모두, 저장된 객체의 버전을 관리하고, 고유한 버전 ID에 따라 제공된 키를 사용해서 객체의 고유 버전을 저장할 수 있습니다. 하지만 이 기능의 구현 방식은 서로 다릅니다.

Azure Blob Storage에서는 Blob에 대한 읽기 전용 스냅샷을 사용해서 버전 관리를 구현합니다. 파일을 프로그래매틱 방식으로 업로드하면 각 업로드 작업을 수행하기 전에 새 스냅샷을 만들 수 있습니다. Azure Blob Storage에서도 불필요한 스냅샷 생성을 방지하기 위한 액세스 조건을 지정할 수 있습니다.

반면에, Cloud Storage에서는 버킷 내의 모든 객체에 대해 자동 객체 버전 관리를 사용하도록 설정할 수 있습니다. 자동 버전 관리를 사용하도록 설정함으로써, Cloud Storage는 개발자가 객체를 수정할 때마다 객체의 새 버전을 자동으로 만듭니다. 이러한 접근 방식은 객체 버전 관리 과정을 간소화하지만, Azure의 접근 방식보다 유연성이 약간 낮습니다. 또한 객체의 각 버전이 총 저장 데이터에 추가되므로 스토리지 비용이 늘어날 수 있습니다. 이 문제는 Cloud Storage의 객체 수명 주기 관리를 사용해서 완화할 수 있습니다.

동시 실행 제어

Azure Blob Storage와 Cloud Storage에서는 각각 '마지막 쓰기 적용' 쓰기 전략이 기본적으로 사용됩니다. 이 전략은 순차적 쓰기의 경우에 적합하지만 동일한 객체에 대해 동시 쓰기를 수행할 경우 경합 조건이 발생할 수 있습니다. 이 문제를 완화하기 위해 두 서비스는 모두 동시 쓰기를 관리하기 위한 방법을 제공합니다.

Azure에서는 동시 쓰기를 낙관적 또는 비관적으로 관리할 수 있습니다.

  • 낙관적 접근 방식: GET 작업을 수행할 때 객체의 ETag 헤더를 검색한 후 쓰기를 시도할 때 이 ETag를 객체의 현재 ETag와 비교합니다. 태그가 일치하면 쓰기를 커밋합니다.
  • 비관적 접근 방식: 대상 객체를 임대하여 쓰기를 수행하는 동안 지정된 기간 동안 이를 잠급니다.

Cloud Storage에서는 낙관적 접근 방식을 사용합니다. 동시 쓰기를 관리하기 위해, 지정된 객체의 현재 세대 번호를 가져온 후, 스크립트 또는 애플리케이션이 쓰기를 시도할 때 해당 세대 번호와 비교합니다. 번호가 일치하면 쓰기를 커밋합니다. 그렇지 않으면 트랜잭션을 중단한 후 다시 시작합니다. 자세한 내용은 객체 버전 관리 및 동시 실행 제어를 참조하세요.

객체 수명 주기 관리

Azure Blob Storage 수명 주기 관리는 GPv2 및 Blob 스토리지 계정에 대한 규칙 기반 정책을 제공합니다. 이 정책을 사용하여 데이터를 해당 액세스 계층으로 전환하거나 데이터의 수명 주기가 종료될 때 만료시킬 수 있습니다. Azure 객체 수명 주기 관리 규칙은 기간에 기반한 데이터 보관처리 또는 삭제, 수집 시 데이터 보관처리, 기존 스냅샷 삭제와 같은 시나리오를 지원합니다.

Cloud Storage에서는 사용자가 지정한 수명 주기 정책에 따라 객체 삭제를 자동화할 수 있습니다. 자세한 내용은 객체 수명 주기 관리를 참조하세요.

Azure Blob Storage는 기본 수명 주기 관리 기능을 제공하지 않지만, Azure Automation을 사용해서 객체 삭제를 자동화할 수 있습니다.

객체 변경 알림

Azure와 Google Cloud 모두 객체가 수정될 때 개발자가 알림을 전송하고 수신할 수 있게 해주는 게시/구독 모델을 제공합니다. Azure Blob Storage에서는 Azure Event Grid를 사용해서 Blob Storage 이벤트를 추적하고 웹훅, Azure Function 또는 기타 엔드포인트에 이를 전송할 수 있습니다. 마찬가지로 Google Cloud는 Cloud Storage 버킷 내에서 객체가 생성, 삭제 또는 업데이트될 때 Pub/Sub 주제에 알림을 게시할 수 있는 Pub/Sub 알림을 제공합니다. 이러한 알림을 수신하려면 다른 애플리케이션 또는 서비스에서 이 Pub/Sub 주제를 구독하면 됩니다.

암호화

Azure는 Azure Storage Service Encryption(SSE)을 통해 저장 데이터 암호화를 지원합니다. 스토리지 계정 내의 모든 Blob 기반 스토리지는 인그레스 중에 AES256으로 암호화되고 이그레스 중에 복호화됩니다. 데이터를 이미 업로드한 후에 계정에 암호화를 사용 설정하면 데이터를 다시 쓰기 전까지는 데이터가 암호화되지 않습니다. 또한 Azure는 서버 측 암호화(SSE)용 고객 관리 암호화 키(CMEK)를 지원합니다. Azure Blob Storage 및 Azure Files용 SSE는 Azure Key Vault와 통합되어 있으므로 Key Vault를 사용하여 암호화 키를 관리할 수 있습니다.

마찬가지로 Cloud Storage를 포함하여 Google Cloud의 스토리지 서비스에 저장되는 모든 데이터는 저장 상태에서 AES256 또는 AES128로 자동 암호화됩니다. 또한 자체 암호화 키를 관리해야 하는 데이터를 위해 Google Cloud는 Cloud Key Management Service와 고객 제공 암호화 키(CSEK)를 사용하여 CMEK를 지원합니다. 자세한 내용은 Google Cloud Platform에서 저장 데이터 암호화를 참조하세요.

서비스수준계약

Microsoft와 Google 모두 업타임 서비스수준계약(SLA)을 제공하며 이러한 SLA가 충족되지 않을 경우 고객 계정에 보상을 제공하기 위한 정책이 있습니다. Microsoft의 Azure Blob Storage 관련 보증 및 정책은 Azure Storage SLA에 정의되어 있고, Google은 Cloud Storage SLA에서 Cloud Storage의 보증 및 정책을 정의합니다.

비용

Azure Blob Storage

Azure Blob Storage는 월간 저장 데이터 양, 스토리지 계정 유형, 복제 유형, 네트워크 송신에 따라 가격이 책정됩니다. 객체 스냅샷을 생성하면 객체의 실시간 버전과 같은 요율로 스냅샷에 비용이 부과됩니다. Azure Blob Storage에서도 공통 API 요청에 대한 비용을 부과합니다.

Cloud Storage 표준

Cloud Storage Standard 가격은 월별 저장 데이터 양과 네트워크 이그레스에 따라 책정됩니다. 객체 버전 관리가 사용하도록 설정된 버킷의 경우, 객체의 각 아카이브된 버전이 객체의 실시간 버전과 같은 요율로 비용이 부과됩니다. Cloud Storage Standard는 공통 API 요청에도 비용을 청구합니다.

블록 스토리지

Google Cloud와 Azure 모두 블록 스토리지 옵션을 제공합니다. Google Cloud는 Compute Engine의 일부인 영구 디스크 형태로 블록 스토리지를 제공합니다. Azure에서는 범용 스토리지 계정의 컨테이너에 저장되는 페이지 Blob의 형태로 블록 스토리지를 제공합니다. 두 플랫폼 모두 로컬로 연결된 SSD를 사용할 수 있는 옵션을 제공합니다.

서비스 모델 비교

Compute Engine 영구 디스크와 Azure VHD(가상 하드 디스크)는 저장 방식과 별도로, 대부분 매우 비슷합니다. Compute Engine과 Azure 모두 필요에 따라 디스크를 로컬로 연결할 수 있는 기능을 제공하지만, 두 경우 모두 디스크 볼륨은 네트워크에 연결된 형태입니다. 네트워크 연결 디스크는 로컬 연결 디스크보다 운영 지연 시간이 높고 처리량이 낮지만, 중복 기본 제공, 스냅샷 생성, 간편한 디스크 분리 및 재연결과 같은 많은 이점이 있습니다.

Azure VHD

Azure는 해당 VHD를 페이지 Blob으로 저장합니다. 페이지 Blob은 최대 8TB까지 가능하고, VHD는 최대 4TB까지 가능합니다. Azure 가상 머신(VM)은 동시에 연결할 수 있는 VHD 개수에 대해 머신 유형별 제한을 적용합니다.

각 VHD는 VHD가 연결되는 VM과 같은 리전의 스토리지 계정에 있어야 합니다. VHD의 지연 시간과 처리량은 스토리지 계정 유형 및 VM의 머신 유형에 따라 달라집니다.

  • Azure 표준 스토리지 계정은 표준 HDD에서 실행되며, 가끔 액세스되는 데이터 또는 대량 스토리지 사용 사례에 권장됩니다.
  • Azure 프리미엄 스토리지 계정은 SSD 드라이브에서 실행되며 I/O 사용량이 높은 작업에 권장됩니다. 프리미엄 스토리지 계층은 LRS 복제만 지원합니다. 프리미엄 스토리지 계층은 VHD만 사용할 수 있기 때문에, Azure가 관리하는 대신 개발자가 직접 자신의 디스크를 수동으로 관리하도록 선택한 경우에는 SSD로 지원되는 VHD에 맞게 별도의 스토리지 계정을 만들어야 할 수 있습니다. A0와 같은 일부 하위 계층 머신은 SSD로 지원되는 VHD가 지원되지 않습니다.

Azure 관리형 디스크를 사용하면 Azure VM에서 VHD를 사용할 수 있습니다. 이는 페이지 Blob, Blob 컨테이너, 스토리지 계정을 추상화한 것입니다. 관리형 디스크에는 네 가지 유형, 즉 초고성능 SSD, 프리미엄 SSD, 표준 SSD, 표준 HDD가 있습니다.

Compute Engine 영구 디스크

Google Cloud는 Compute Engine에 저장되는 영구 디스크 형태로 블록 스토리지를 제공합니다. 커스텀 머신 유형 또는 사전 정의된 머신 유형인 대부분의 Compute Engine VM 인스턴스에는 최대 128개의 영구 디스크를 연결할 수 있습니다. 공유 코어 머신 유형의 인스턴스에서는 영구 디스크가 최대 16개로 제한됩니다. VM 인스턴스별로 영구 디스크 스토리지를 최대 257TB까지 연결할 수 있고, 각 영구 디스크 크기는 최대 64TB까지 가능합니다. 영구 디스크는 HDD이거나 SSD일 수 있습니다. Azure와 마찬가지로, 디스크를 연결할 VM 인스턴스와 동일한 영역에서 디스크 볼륨을 만들어야 합니다.

Compute Engine과 Azure Storage의 영구 디스크는 다음과 같이 비교될 수 있습니다.

기능 Azure VHD Compute Engine 영구 디스크
볼륨 유형 표준 스토리지(HDD), 프리미엄 스토리지(SSD) 표준 영구 디스크(HDD), SSD 영구 디스크
관리 체계 비관리형 디스크, 관리형 디스크 해당 없음(프로젝트 수준에서 Google Cloud 관리형)
볼륨 연결 한 번에 인스턴스 한 개에만 연결 가능 읽기-쓰기 볼륨: 한 번에 인스턴스 한 개에만 연결 가능
읽기 전용 볼륨: 인스턴스 여러 개에 연결 가능
최대 볼륨 크기 4TiB 64TB
중복
스냅샷 생성
디스크 암호화 기본적으로 암호화됨 기본적으로 암호화됨

Compute Engine과 Azure의 로컬 연결 디스크는 다음과 같이 비교될 수 있습니다.

기능 Azure Compute Engine
서비스 이름 로컬 SSD 로컬 SSD
볼륨 연결 인스턴스 유형에 연결됨 모든 비공유 코어 인스턴스에 연결 가능
인스턴스별 연결 볼륨 인스턴스 유형에 따라 다름 최대 8
스토리지 용량 인스턴스 유형에 따라 다름 볼륨당 375GB
라이브 마이그레이션 아니요
중복 없음 없음

복제

Azure Storage의 경우, 머신 유형 및 스토리지 계정 유형에 따라 중복화를 위해 VHD를 복제할 수 있습니다. 데이터는 LRS(로컬 중복 스토리지)를 사용하여 스토리지 확장 장치 내에, ZRS(영역 중복 스토리지)를 사용하여 3개의 가용성 영역 전반에 또는 GRS(지리적 중복 스토리지)나 RA-GRS(읽기 액세스 지리적 중복 스토리지)를 사용하여 리전 전반에서 로컬에 복제할 수 있습니다.

단일 Compute Engine 리전 내에서 Compute Engine 영구 디스크를 복제할 수 있습니다. Compute Engine에서 견고한 시스템을 설계하려는 경우 여러 영역의 리소스에서 고가용성을 유지할 수 있는 리전 영구 디스크를 사용하는 것이 좋습니다. 리전 영구 디스크는 애플리케이션 수준의 복제가 필요 없는 작업 부하에서 동기식 복제를 제공합니다.

각 서비스는 내구성 향상을 위해 복제를 제공하지만, 이 기능은 사용자 또는 애플리케이션 오류로 인한 데이터 손상 또는 사고로 인한 삭제로부터 데이터를 보호하지 않습니다. 중요한 데이터를 보호하기 위해서는 데이터 백업 및 디스크 스냅샷을 정기적으로 수행해야 합니다.

볼륨 연결 및 분리

디스크 볼륨을 만든 후 VM에 연결할 수 있습니다. Azure VM 인스턴스와 Compute Engine VM 인스턴스는 서로 비슷하게 작동합니다. 그러면 VM 인스턴스에서 다른 블록 기기와 같이 디스크 볼륨을 마운트하고 포맷할 수 있습니다. 마찬가지로 다른 인스턴스에 다시 연결할 수 있도록 한 인스턴스에서 볼륨을 마운트 해제하고 분리할 수 있습니다.

Azure VHD는 한 번에 하나의 VM에만 연결할 수 있습니다. Compute Engine 영구 디스크도 읽기/쓰기 모드에서는 동일한 제한이 적용됩니다. 하지만 읽기 전용 모드의 영구 디스크는 동시에 여러 인스턴스에 연결할 수 있습니다.

볼륨 백업

Compute Engine과 Azure 모두 디스크 볼륨의 스냅샷을 캡처하고 저장할 수 있습니다. 이러한 스냅샷은 나중에 새 볼륨을 만드는 데 사용할 수 있습니다.

Compute Engine 영구 디스크와 Azure 관리되지 않는 디스크는 모두 다양한 스냅샷을 지원합니다. 초기 스냅샷은 볼륨의 전체 복사본을 만들고, 이후 스냅샷은 이전 스냅샷에서 변경된 블록만 복사합니다. 다양한 스냅샷이 여러 개 생성된 후에는 또 다시 전체 스냅샷이 생성되고, 이러한 주기가 반복됩니다.

Azure 관리되는 디스크는 현재까지 다양한 스냅샷을 지원하지 않습니다. 대신 각 스냅샷은 디스크 볼륨의 전체 복사본을 만듭니다. API 지원을 통해 증분 스냅샷을 지원하지만 증분 스냅샷은 기본적으로 제공되지 않습니다.

Azure는 또한 백업 및 복원 작업을 자동화하는 데 도움이 되는 Azure Backup 및 Azure Recovery Service를 제공합니다. Google Cloud는 이러한 서비스에 해당하는 서비스를 제공하지 않습니다.

볼륨 성능

Compute Engine 영구 디스크와 Azure VHD 모두 디스크 성능은 다음과 같은 여러 요소에 따라 달라집니다.

  • 볼륨 유형: 각 서비스는 몇 가지 서로 다른 볼륨 유형을 제공합니다. 각 유형은 고유한 성능 특성 및 제한을 갖습니다.
  • 사용 가능한 대역폭: 네트워크 연결 볼륨의 처리량은 연결된 Compute Engine 또는 Azure VM에서 사용 가능한 네트워크 대역폭에 따라 달라집니다.

이 섹션에서는 각 서비스의 추가적인 성능 세부정보를 설명합니다.

Azure VHD

Azure VM 유형은 다양한 네트워크 성능을 제공합니다. 코어 수가 적은 VM 유형은 특정 VHD 디스크 유형에 대해 알려진 최대 IOPS 또는 처리량을 달성하기 위한 네트워크 성능이 충분하지 않을 수 있습니다. 자세한 내용은 VM에 대한 고성능 프리미엄 스토리지 및 관리되는 디스크를 참조하세요.

Compute Engine 영구 디스크

Compute Engine은 코어별 기준으로 처리량을 할당합니다. 가상 CPU 코오별 네트워크 송신 속도는 2Gbps이고, 단일 가상 머신 인스턴스에서 이론적으로 가능한 최대 속도는 16Gbps입니다. Compute Engine은 데이터 중복 계수가 3.3x이므로, 각 논리적 쓰기는 실제로 3.3회의 쓰기에 해당하는 네트워크 대역폭이 필요합니다. 따라서 코어 수가 적은 머신 유형은 특정 영구 디스크 유형에 대해 알려진 최대 IOPS 또는 처리량을 달성하기 위한 네트워크 성능이 충분하지 않을 수 있습니다. 자세한 내용은 네트워크 송신 제한을 참조하세요.

각 Compute Engine 디스크 유형에서 사용 가능한 총 I/O는 지정된 인스턴스에 연결된 볼륨의 총 크기와 관련이 있습니다. 예를 들어 한 인스턴스에 2.5TB 표준 영구 디스크가 2개 연결된 경우, 사용 가능한 총 I/O의 읽기 IOPS는 3000이고 쓰기 IOPS는 7500이 됩니다.

로컬 연결 디스크

표준 네트워크 연결 블록 스토리지 외에도 Azure와 Compute Engine에서는 인스턴스를 실행하는 물리적 머신에 로컬로 연결된 SSD를 사용할 수 있습니다. 두 환경 모두, 이러한 디스크를 로컬 SSD라고 부릅니다. 로컬 SSD는 네트워크 연결 블록 스토리지보다 빠른 전송 속도를 제공합니다. 하지만 네트워크 연결 블록 스토리지와 달리 이러한 디스크는 데이터 지속성을 보장하지 않으며, 고유한 다양한 스냅샷 기능을 사용한 스냅샷 작성이 지원되지 않습니다.

Azure에서 로컬 SSD의 크기와 가용성은 사용 중인 머신 유형과 직접적으로 관련됩니다. 로컬 SSD 크기는 최소 16GB이며 최대 6TB까지 가능합니다. A 시리즈와 같은 일부 머신 유형에는 로컬 SSD가 포함되지 않습니다.

Compute Engine에서는 f1-micro 및 g1-small과 같은 공유 코어 유형을 제외하고 거의 모든 머신 유형에 로컬 SSD를 연결할 수 있습니다. 로컬 SSD는 디스크당 375GB로 크기가 고정되어 있으며, 단일 인스턴스에 최대 8개(총 3TB)까지 연결할 수 있습니다.

Compute Engine은 호스트 머신이 유지보수를 위해 작동 중지될 때까지 로컬 SSD를 자동으로 문제 없이 이전합니다. 자세한 내용은 실시간 이전을 참조하세요.

비용

Azure에서 디스크 볼륨은 월간 사용량(GB)에 따라 비용이 부과됩니다. 로컬 SSD 비용은 VM 가격에 포함되어 있습니다.

Compute Engine 영구 디스크 및 디스크 스냅샷도 월간 사용량(GB)에 따라 비용이 부과됩니다. 로컬 SSD는 머신 비용에 관계없이 비용이 부과됩니다. 자세한 내용은 로컬 SSD 가격 책정을 참조하세요.

파일 스토리지

파일 서버 기반 워크로드의 경우 Azure는 분산 SMB 기반 파일 서버 서비스인 Azure Files를 제공합니다.

Google Cloud는 파일 시스템 인터페이스와 데이터용 공유 파일 시스템이 필요한 애플리케이션에 관리형 파일 스토리지 서비스인 Filestore를 제공합니다. Filestore는 관리형 네트워크 연결 스토리지(NAS)를 Compute Engine과 Google Kubernetes Engine(GKE) 인스턴스에서 간편하게 사용할 수 있는 기본 환경을 제공합니다.

스토리지 영역 네트워크(SAN)

SAN 작업 부하의 경우, Azure는 Microsoft의 고유 SAN 어플라이언스인 StorSimple과의 통합을 제공합니다. 구조적으로 StorSimple은 온프레미스 StorSimple SAN과 온프레미스 SAN의 동작을 복제하는 가상 클라우드 기반 어플라이언스로 구성됩니다.

Google Cloud에서는 영구 디스크를 사용하여 SAN이 필요한 워크로드를 지원할 수 있습니다. SAN 환경에서 사용되는 영구 디스크는 논리 단위 번호(LUN) 기기를 통해 액세스하는 논리적 디스크 볼륨과 동일하며 비슷한 방식으로 프로비저닝될 수 있습니다. LUN 기반 논리 디스크 볼륨과 마찬가지로, 단일 VM 인스턴스에 여러 개의 영구 디스크를 마운트할 수 있습니다. 또한 여러 VM 인스턴스에 단일 읽기 전용 영구 디스크를 마운트할 수도 있습니다. 자세한 내용은 데이터 센터 전문가를 위한 Google Cloud Platform: 스토리지를 참조하세요.

쿨 스토리지

Google Cloud와 Azure는 각각 정기적인 액세스가 필요 없는 데이터에 쿨 스토리지 옵션을 제공합니다. Cloud Storage는 Cloud Storage Nearline과 Cloud Storage Coldline이라고 하는 추가 클래스를 제공하고 Azure Blob Storage는 추가 쿨 계층을 제공합니다.

지연 시간

두 서비스 모두 밀리초 단위의 첫 바이트 소요 시간을 갖고 있습니다.

복제

Azure Blob Storage의 쿨 계층을 사용할 때, 데이터가 복제되는 방법은 스토리지 계정의 복제 유형에 따라 달라집니다. Cloud Storage Nearline 또는 Cloud Storage Coldline을 사용할 경우 데이터 복제 방식은 데이터를 저장하는 위치 유형에 따라 다릅니다.

스토리지 기간

Blob 특정 스토리지 계정을 사용하는 경우 Azure Blob Storage의 쿨 계층은 최소 스토리지 기간이 없습니다. GPv2 스토리지 계정의 경우 Azure Blob Storage의 쿨 계층은 각 Blob에 대해 최소 30일의 스토리지 기간을 갖습니다. 최소 스토리지 기간이 종료되기 전에 Blob을 삭제하거나 덮어쓰면 추가 비용이 발생합니다.

Cloud Storage Nearline의 최소 스토리지 기간은 데이터 객체마다 30일인 반면 Cloud Storage Coldline의 최소 스토리지 기간은 데이터 객체마다 90일입니다. GPv2 계정 내에서 사용할 때의 Azure Blob Storage의 쿨 계층과 마찬가지로, 최소 스토리지 기간이 종료되기 전에 데이터 객체를 삭제하거나 덮어쓰면 추가 비용이 발생합니다.

비용

Azure Blob Storage의 쿨 계층

Azure Blob Storage의 쿨 계층은 월간 저장 데이터 양, 스토리지 계정 유형, 복제 유형, 네트워크 이그레스에 따라 가격이 책정됩니다. Azure Cool Blob Storage에서도 공통 API 요청, 데이터 쓰기, 데이터 검색에 대해 비용을 부과합니다.

Cloud Storage Nearline 및 Cloud Storage Coldline

Cloud Storage Nearline과 Cloud Storage Coldline의 가격은 월별 저장 데이터 양과 네트워크 이그레스에 따라 책정됩니다. 최소 스토리지 기간 전에 데이터를 삭제하거나 수정하면 남은 기간에 대한 비용이 부과됩니다. 예를 들어 Cloud Storage Nearline에 객체를 저장하고 5일 후에 삭제하면 이 객체의 남은 스토리지 기간인 25일에 대한 비용이 부과됩니다. Cloud Storage Nearline과 Cloud Storage Coldline에서는 또한 일반 API 요청과 데이터 검색에 대한 비용도 청구됩니다.

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

아카이브 스토리지

GCP와 Azure는 각각 아카이브 스토리지 옵션을 제공합니다. Cloud Storage는 Cloud Storage Archive라고 하는 추가 클래스를 제공하고 Azure Blob Storage는 추가적인 보관 계층을 제공합니다.

지연 시간

Cloud Storage Archive에는 첫 바이트 소요 시간(밀리초 단위)이 있습니다. Azure Blob Storage의 아카이브 계층은 15시간 이하의 첫 바이트 소요 시간을 갖고 있습니다.

복제

Azure Blob Storage의 아카이브 계층을 사용할 때 데이터가 복제되는 방법은 스토리지 계정의 복제 유형에 따라 달라집니다. Cloud Storage Archive를 사용할 경우 데이터 복제 방식은 데이터를 저장하는 위치 유형에 따라 다릅니다.

스토리지 기간

Azure Blob Storage의 아카이브 계층은 각 Blob에 대해 최소 180일의 스토리지 기간을 갖습니다. 최소 스토리지 기간이 종료되기 전에 Blob을 삭제하거나 덮어쓰면 추가 비용이 발생합니다.

Cloud Storage Archive의 스토리지 기간은 데이터 객체마다 최소 365일입니다. Azure Blob Storage의 아카이브 계층과 마찬가지로, 최소 스토리지 기간이 종료되기 전에 데이터 객체를 삭제하거나 덮어쓰면 추가 비용이 발생합니다.

비용

Azure Blob Storage의 아카이브 계층

Azure Blob Storage의 아카이브 계층은 월간 저장 데이터 양, 스토리지 계정 유형, 복제 유형, 네트워크 송신에 따라 가격이 책정됩니다. 최소 스토리지 기간 전에 데이터를 삭제하거나 수정하면 남은 기간에 대한 비용이 부과됩니다. 예를 들어 Blob을 저장한지 5일 후에 Blob을 삭제하면 해당 Blob에 대해 남은 기간인 175일에 대한 비용이 부과됩니다. 또한 Blob 스냅샷을 생성하면 Blob의 실시간 버전과 같은 요율로 스냅샷에 비용이 부과됩니다.

또한 Azure Blob Storage의 보관 계층에서도 일반 API 요청에 대한 비용이 청구됩니다.

Cloud Storage Archive

Cloud Storage Archive의 가격은 월별 저장 데이터 양 및 네트워크 이그레스에 따라 책정됩니다. 최소 스토리지 기간 전에 데이터를 삭제하거나 수정하면 남은 기간에 대한 비용이 부과됩니다. 예를 들어 객체를 저장하고 5일 후에 객체를 삭제하면 해당 객체의 남은 스토리지 기간인 360일에 대한 비용이 부과됩니다. Cloud Storage Archive에서는 또한 일반 API 요청과 데이터 검색에 대한 비용도 청구됩니다.

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

다음 단계

Azure 전문가를 위한 다른 Google Cloud 문서를 확인하세요.