본문 바로가기
CSP (Cloud Service Provider)/GCP

[GCP] Cloud Storage와 lifecycle

by BTC_오은영석사 2023. 10. 12.

베하~

안녕하세요 오은영석사와 금쪽이가 돌아왔습니다. 그동안 잘 지내셨나요??

하루하루 쌀쌀해져가는 날씨에 감기 조심하시길 바랍니다!

 

오늘의 주제는 무엇일까요?! 바로 Cloud Storage와 lifecycle에 대해 알아보겠습니다!!

 


Cloud Storage 란?

Cloud Storage는 디지털 데이터가 외부 위치의 서버에 저장되는 컴퓨터 데이터 스토리지 모드입니다.

서버는 인프라에 저장된 데이터의 호스팅, 관리, 보안을 담당하는 타사 제공업체에서 관리합니다.

공급업체는 공개 또는 비공개 인터넷 연결을 통해 서버의 데이터에 항상 액세스할 수 있도록 합니다.

Cloud Storage를 사용하면 조직이 데이터를 저장, 액세스, 유지보수할 수 있으므로 자체 데이터 센터를 소유 및 운영할 필요가 없이 비용 모델이 자본 지출 모델에서 운영 모델로 전환됩니다.

Cloud Storage는 확장 가능하므로 조직에서 필요에 따라 데이터 공간을 확장하거나 줄일 수 있습니다. 

 

Cloud Storage 종류

  • Public
조직이 다른 회사에서도 사용하는 서비스 제공업체의 데이터 센터에 데이터를 저장하는 모델입니다. 퍼블릭 Cloud Storage의 데이터는 여러 리전에 분산되어 있으며 구독 또는 사용한 만큼만 지불하는 방식으로 제공되는 경우가 많습니다. 퍼블릭 Cloud Storage는 '탄력적'인 것으로 간주되므로 조직의 필요에 따라 저장된 데이터를 확장하거나 축소할 수 있습니다. 
  • Private
조직이 자체 서버 및 데이터 센터를 활용하여 자체 네트워크 내에 데이터를 저장하는 모델입니다. 또는 조직은 클라우드 서비스 제공업체를 통해 다른 조직에서 공유하지 않는 전용 서버 및 비공개 연결을 제공할 수 있습니다. 프라이빗 클라우드는 일반적으로 데이터에 대한 더 세부적인 제어가 필요하고 엄격한 규정 준수 및 보안 요구사항이 있는 조직에서 활용합니다.
  • Hybrid
프라이빗 클라우드와 퍼블릭 클라우드 스토리지 모델을 혼합한 모델입니다. 하이브리드 클라우드 스토리지 모델은 조직에서 어느 데이터를 어느 클라우드에 저장할지 결정할 수 있게 해줍니다. 민감한 정보 및 엄격한 규정 준수 요구사항을 충족해야 하는 데이터는 프라이빗 클라우드에, 덜 민감한 정보는 퍼블릭 클라우드에 저장될 수 있습니다. 하이브리드 클라우드 스토리지 모델에는 일반적으로 두 클라우드를 통합하기 위한 조정 레이어가 있습니다. 하이브리드 클라우드는 유연성을 제공하며 필요에 따라 조직이 퍼블릭 클라우드로 확장할 수 있게 해줍니다.   
  • Multicloud
조직에서 클라우드 서비스 제공업체(퍼블릭 또는 프라이빗) 2곳 이상에서 제공하는 2개 이상의 클라우드 모델을 설정하는 모델입니다. 하나의 클라우드 공급업체가 특정 독점 앱을 제공하거나, 조직이 데이터를 특정 국가에 저장해야 하거나, 여러 팀에서 다양한 클라우드에 대한 교육을 받거나, 조직에서 서비스 제공업체의 서비스수준계약에 명시되지 않은 다른 요구사항을 처리해야 경우, 조직에서 멀티 클라우드 모델을 선택할 수 있습니다. 멀티 클라우드 모델은 조직에 유연성과 중복성을 제공합니다. 

 

Cloud Storage 이점

총 소유 비용

- Cloud Storage를 사용하면 조직이 자본 지출 모델에서 운영 지출 모델로 이전할 수 있으므로 예산과 리소스를 빠르게 조정할 수 있습니다.

탄력성

- Cloud Storage는 탄력성과 확장성이 뛰어나므로 조직의 필요에 따라 수직 확장 또는 축소 할 수 있습니다. 

유연성

- Cloud Storage는 조직의 데이터 저장 및 액세스, 리소스 배포 및 예산 책정, IT 인프라 설계 방법에 대한 유연성을 제공합니다.  

보안

- 대부분의 클라우드 제공업체는 데이터 센터의 물리적 보안, 소프트웨어 및 애플리케이션 수준의 최첨단 보안 등 강력한 보안을 제공합니다. 

중복

- 중복은 퍼블릭 클라우드의 고유한 특성이며, 조직이 비즈니스 연속성을 유지하면서 재해로부터 복구할 수 있게 해줍니다.

 

Cloud Storage Lifecycle

클라우드 스토리지 라이프사이클은 데이터가 생성되고 저장된 후, 유지보수, 보관, 삭제 등의 과정을 거쳐 데이터의 생애주기를 관리하는 것을 말합니다. 설정에 따라 데이터를 삭제 및 유지보수가 가능합니다.

 

Cloud Storage Lifecycle 구성

각 수명 주기 관리 구성에는 규칙 집합이 포함되어 있습니다. 각 규칙에는 하나의 작업과 하나 이상의 조건이 포함되어 있습니다.

  • 규칙의 작업을 수행하려면 객체가 규칙에 지정된 모든 조건과 일치해야 합니다.
  • 같은 작업이 포함된 여러 규칙을 지정하면 객체가 어떤 규칙의 조건이든 일치하기만 하면 객체에서 작업이 수행됩니다.
  • 객체를 가장 저렴한 저장 데이터 가격이 책정된 스토리지 클래스로 전환하는 SetStorageClass 작업이 우선합니다.여러 규칙의 조건이 단일 객체에 대해 동시에 충족되는 경우 Cloud Storage는 다음 고려사항에 따라 오직 하나의 규칙과 관련된 작업을 수행합니다.
  • Delete 작업이 모든 SetStorageClass 작업에 우선합니다.
예를 들어 age 조건을 10일에서 20일로 변경하면 최대 24시간까지는 이전 구성을 기준으로 인해 11일 된 객체가 객체 수명 주기 관리에 의해 삭제될 수 있습니다.

 

Lifecycle actions

  • Delete
객체가 수명 주기 규칙에 지정된 모든 조건을 충족하면 Delete 작업이 객체를 삭제합니다.
예외 - 객체 버전 관리가 사용 설정된 버킷에서 객체의 라이브 버전을 삭제하면 현재 외 버전이 되고, 현재 외 버전을 삭제하면 해당 버전이 영구적으로 삭제됩니다. 
객체에 객체 보존 조치가 적용되어 있거나 아직 충족되지 않은 보관 정책이 설정된 경우에는 객체에 Delete 작업이 적용되지 않습니다. 객체에 대해 Delete 작업의 조건이 충족된 상태로 유지되는 한 객체 보관 조치를 삭제하고 보관 정책이 충족된 후 Delete 작업이 수행됩니다.
  • SetStorageClass
객체가 수명 주기 규칙에 지정된 모든 조건을 충족할 때 객체의 스토리지 클래스를 변경하고 객체의 수정 시간을 업데이트합니다.
  • AbortIncompleteMultipartUpload
미완료 멀티파트 업로드를 중단하고 멀티파트 업로드가 수명 주기 규칙에 지정된 조건을 충족할 때 연관된 부분을 삭제합니다.

 

Lifecycle conditions

  • age
리소스가 지정된 경과 기간(일수)에 도달하는 경우에 충족됩니다.경과 기간은 리소스 생성 시부터 측정됩니다.
객체의 경우 생성 시간은 업로드가 완료될 때와 같이 객체가 버킷에 성공적으로 기록된 시간입니다.
객체 사용 기간은 현재 외 버전이 되는 객체의 영향을 받지 않습니다.
멀티파트 업로드의 경우 생성 시간은 업로드가 시작된 시간입니다.
  • createdBefore
객체가 UTC 기준으로 지정된 날짜의 자정 이전에 생성된 경우에 충족됩니다.
  • customTimeBefore
날짜 부분이 이 조건에 지정된 날짜보다 이전이면 customTimeBefore 조건이 충족됩니다.
이 조건은 YYYY-MM-DD 날짜 형식을 사용하여 설정됩니다. 
customTimeBefore는 Custom-Time 메타데이터가 설정되지 않은 객체에 충족되지 않습니다.
  • daysSinceCustomTime
객체의 Custom-Time 메타데이터 필드에 날짜 및 시간이 지정된 이후 특정 일수가 경과하면 daysSinceCustomTime 조건이 충족됩니다.
예를 들어 객체의 Custom-Time이 2020-05-16T10:00:00Z이고 daysSinceCustomTime 조건이 10일인 경우 해당 조건은 2020/05/26 10:00 UTC부터 객체에 충족됩니다.
  • daysSinceNoncurrentTime
일반적으로 객체 버전 관리와 관련해서만 사용됩니다.
라이브 버전이 삭제되거나 대체되어 객체가 이전 버전 상태가 된 후 지정된 기간(일)이 경과하면 조건이 충족됩니다.
예를 들어 객체가 2020/07/08 15:00 UTC에 이전 버전 상태가 되고 daysSinceNoncurrentTime 조건이 10일인 경우에는 2020/07/18 15:00 UTC부터 객체에 대한 조건이 충족됩니다.
  • isLive
일반적으로 객체 버전 관리와 관련해서만 사용됩니다. 
false로 설정하면 객체의 모든 이전 버전에서 이 조건이 충족됩니다. 
true로 설정하면 서비스 중인 객체 버전에서 이 조건이 충족됩니다.
버전 관리를 사용하지 않는 경우 isLive가 true일 때 모든 객체가 서비스 중인 버전으로 간주됩니다.
  • matchesStorageClass
버킷의 객체가 지정된 스토리지 클래스로 저장된 경우에 충족됩니다. 
matchesStorageClass에 대해 STANDARD, NEARLINE, COLDLINE, ARCHIVE, MULTI_REGIONAL, REGIONAL, DURABLE_REDUCED_AVAILABILITY 값을 사용할 수 있습니다.
  • matchesPrefix and matchesSuffix
matchesPrefix 및 matchesSuffix 조건은 객체 이름의 시작 또는 끝이 지정된 프리픽스 또는 서픽스와 정확하게 일치(대소문자 구분)할 때 충족됩니다.
여러 문자열은 목록으로 지정할 수 있습니다(예: "matchesSuffix": [".jpg", ".png"]).matchesPrefix를 사용할 때는 대부분의 요청 경로에서 객체 이름 앞에 나오는 /를 포함하지 마세요.
  • noncurrentTimeBefore
일반적으로 객체 버전 관리와 관련해서만 사용됩니다. 조건에 지정된 날짜 이전에 이전 버전 상태가 된 객체에 대한 조건이 충족됩니다.
이 조건은 YYYY-MM-DD 날짜 형식을 사용하여 설정됩니다. 
noncurrentTimeBefore는 라이브 객체 조건을 만족하지 않습니다.
  • numNewerVersions
일반적으로 객체 버전 관리와 관련해서만 사용됩니다.
이 조건의 값이 N으로 설정되면, 객체 버전보다 최신인 버전이 N개 이상(서비스 중인 버전 포함) 이상인 경우 해당 객체 버전이 조건을 충족합니다.
서비스 중인 객체 버전의 경우, 최신 버전의 수는 0으로 간주됩니다.
가장 최근인 이전 버전의 경우, 최신 버전의 수는 1(서비스 중인 객체 버전이 없는 경우에는 0) 등으로 간주됩니다.

 

 


 

이렇게 이번 시간에는 Cloud Storage와 lifecycle에 대해 알아보았습니다.

유익한 시간이였나요?! lifecycle을 통해 버킷의 데이터들을 관리를 쉽게 할 수 있습니다.

그럼 다음시간에 만나요!! 베빠~!

 

출처

: https://cloud.google.com/learn/what-is-cloud-storage?hl=ko#section-2

: https://cloud.google.com/storage/docs/lifecycle?hl=ko

댓글