2019.10.29

클라우드 오브젝트 스토리지, 꼭 백업해야 하나?

W. Curtis Preston | Network World
클라우드 블록-스토리지 서비스에 저장된 데이터는 제대로 백업하지 않으면 영원히 소실될 가능성이 있다. 오브젝트 스토리지가 블록 스토리지와 서로 얼마나 다르고, 얼마나 더 우수한 빌트-인 보호를 제공하는지 알아보자.  
 
ⓒGetty Images Bank

오브젝트 스토리지란 무엇인가? 
클라우드 사업자는 오브젝트 스토리지 서비스를 제공한다. 예를 들어 아마존의 심플 스토리지 서비스(Simple Storage Service, S3), 애저의 블롭 스토어, 구글의 클라우드 스토리지 같은 것들이다. 

오브젝트 스토리지 시스템은 계층적 디렉토리 및 서브디렉토리 구조가 없는 일종의 파일 시스템이라 할 수 있다. 파일 시스템은 파일을 식별하고 위치를 파악하는데 디렉토리 구조와 파일 이름의 조합을 이용하는 데 비해, 오브젝트 스토리지 시스템에 저장된 모든 오브젝트는 이의 콘텐츠에 따라 고유 식별자(Unique IDentifier, UID)가 주어진다.  

그때부터 UID는 오브젝트를 식별하고 회수하는 방법으로 사용된다. UID는 파일 콘텐츠를 SHA-1과 같은 암호 알고리즘을 통해 실행시킴으로써 생성된다(SHA-1이 어떻게 작용하는지 알려면 임의의 양의 텍스트를 삽입해 SHA-1 해시를 스스로 생성해보라). 파일이든, 블록이든, 파일이나 블록 집단이든, 또는 블록이나 파일의 부분이든, 어떤 항목이든 오브젝트로 저장될 수 있다. 

오브젝트 스토리지와 블록 스토리지 간의 큰 차이라면 오브젝트 스토리지에 저장된 모든 오브젝트는 최소한 3곳의 가용 구역으로 자동으로 복사된다는 점이다. 이는 자연재해 등으로 인해 2곳의 가용 구역이 파괴되더라도, 오브젝트 스토리지 시스템 내에 저장된 데이터가 계속 존재할 것이라는 의미다. 블록 스토리지는 일반적으로 한 가용 구역 내에만 복제되어, 한 번의 큰 정전만으로 데이터가 소실될 수 있다. 

복제가 이루어지는 방식 역시 매우 상이하다. 오브젝트 복제는 오브젝트 수준에서 이루어지는 반면, 클라우드 블록 스토리지 및 보편적 RAID 시스템은 블록 수준에서 복제가 이루어진다.  

또한 오브젝트는 절대로 변경되지 않는다. 오브젝트가 변경되어야 한다면 그냥 새 오브젝트로 저장될 뿐이다. 버전 분류가 지원된다면 이전 오브젝트 버전은 역사적 목적으로 저장된다. 

클라우드 사업자는 오브젝트 스토리지 서비스를 제공한다. 예컨대 아마존의 심플 스토리지 서비스, 애저의 블롭 스토어, 구글의 클라우드 스토리지 등이다. 이들 오브젝트 스토리지 시스템은 심지어 모든 가용 구역을 파괴하는 지역 재난까지 견딜 수 있도록 가설될 수 있다. 

아마존은 교차-지역 복제를 이용해 이를 실행하고, 이는 고객이 스스로 구성해야 한다. 마이크로소프트의 지역 중복 스토리지는 여러 지역을 아우르며 복제가 이루어지고, 구글은 같은 기능이라 할 수 있는 2중 지역 및 다중-지역 스토리지를 제공한다. 오브젝트-스토리지 시스템은 시스템 내의 버전 분류 기능과 조합되어 위 사업자들이 제공하는 어떤 블록 스토리지 시스템보다 데이터를 한층 탄력적으로 보존할 수 있다.  

블록 볼륨과 파일 시스템은 성능을 위주로 설계되었지만, 오브젝트 스토리지는 데이터 무결성에 가장 중요한 목표를 두고 설계되었다. 예를 들어, 언제든지 고유 식별자를 이용해 오브젝트의 일정 사본이 훼손되지 않았음을 확인할 수 있다. 시스템이 하는 일은 고유 식별자를 생성했던 프로세스를 통해 오브젝트를 재실행하는 것뿐이다. UID가 여전히 동일하다면 오브젝트의 콘텐츠는 변경되지 않은 것이다. 오브젝트의 콘텐츠가 품질 저하나 다른 이유로 변경되었다면 UID가 변경될 것이기 때문에 시스템은 이를 자동으로 인지한다. 그렇다면 다른 구역에 있는 무결한 사본을 회수해 오브젝트를 자동으로 수리할 수 있다. 필자가 아는 한, 어떤 블록 장치나 파일 시스템도 이 정도 수준의 데이터 무결성을 갖추고 있지는 않다.   

오브젝트 스토리지는 이른바 오픈-버킷 문제 때문에 많은 논란에 휩싸여왔다. 오픈-버킷 문제란 권한 관리가 부실한 버킷에 중요하고 민감한 데이터를 보존하는 것이다(버킷은 오브젝트를 저장해 놓은 매우 큰 컨테이너 정도로 생각하면 된다). 

대형 고객 데이터베이스들이 이 문제를 겪어왔다. 이는 주로 고객이 오브젝트 스토리지가 어떻게 작용하는지를 단순히 몰랐다는 사실에 기인한다. 오픈 버킷을 생성하는 것이 분명히 가능하고, 오브젝트로의 직접적인 링크를 제공함으로써 여러 사람에게 파일을 쉽게 유포할 수 있다. 그러나 오픈 버킷을 생성했다가 영업 비밀을 무심코 전세계에 노출해버릴 수도 있음을 유의해야 한다.   

베스트 프랙티스 준수 
선호하는 오브젝트 스토리지에 관한 베스트 프랙티스를 구글에서 검색하면 이를 적절히 처리하는데 필요한 자료를 얻을 수 있다. 예를 들어 아마존은 한 웹 페이지에서 퍼블릭-액세스 같은 기능을 차단하고, 모든 사람에 대한 권한을 재설정하는 등 여러 상식적인 제안을 내놓고 있다. 마이크로소프트도 베스트 프랙티스 웹 페이지가 있고, 구글도 있다. 또한 이를 지도하는 서드파티 글도 수없이 많다.  

한가지 상식적인 제안이라면 특정 애플리케이션에 필요한 접근방식을 식별한 후 해당 접근만 허용하고 나머지는 전부 차단하는 것이다. 애플리케이션이 오브젝트 스토리지 버킷에 전면적으로 접근하도록 허용하기는 훨씬 더 쉽지만, 필연적으로 보안 재난이 일어날 것이다. 아울러 필요 시 접근을 손쉽게 허용하고 취소할 수 있는 역할 기반 관리를 고려하라.  

오브젝트 스토리지는 백업이 필요한가? 
오브젝트 스토리지를 백업할지 결정하는 일은 블록 볼륨을 백업할지 결정하는 것처럼 단순하지 않다. 블록 볼륨과 다르게, 오브젝트 스토리지는 위해를 끼칠 수 있는 여러 원인을 방어하는 여러 보호 수준을 자동으로 포함한다. 예를 들어 선택적인 WORM(Write-Once-Read-Many) 보호 등이다. 교차-지역 복제 등 이용 가능한 모든 베스트 프랙티스를 준수한다면 데이터가 모두 소실되어 백업을 찾아야 할 일이 없을 것이다. 데이터 보호 전문가에게 의뢰한다면 견실한 전략을 수립할 수 있다. 

한편, 오브젝트 스토리지가 여전히 오류를 범할 수 있는 인간에 의해 작성되고 있다는 주장은 반박하기 쉽지 않다. 따라서 오브젝트 스토리지 내 데이터가 미션 크리티컬이라면 백업하는 것이 적절할 것이다. 

백업하는 방법은 여러 가지가 있다. 전혀 다른 차원의 서비스를 백업에 이용할 수도 있다. 예를 들어 AWS 글레이저 딥 아카이브, 애저 아카이브 스토리지, 구글 콜드라인 등이다. 이에 의해 오브젝트 데이터의 비상 시 사본을 유지할 수 있다. 데이터가 정말 중요하다면 이런 식으로 백업하는 것을 고려해야 한다. 또한 블록 스토리지에서와 마찬가지로 상이한 계정 및 지역이어야 한다.  
 
주의 깊게 사용할 것  
블록 볼륨은 백업해야 한다. 스스로 이들을 백업해야 한다. 블록 스토리지 스냅샷도 다른 지역 및 계정으로 복제해야 한다. 오브젝트 스토리지는 여러 가용 구역으로 복제가 자동으로 이루어지기 때문에, 한층 높은 수준의 탄력성을 제공한다. 그렇다고는 하지만 완벽이란 없기 때문에 정보를 참조하며 재량에 따라 결정을 내려야 한다. 

*W. Curtis Preston은 백업, 저장, 복구 전문가로서 1993년부터 이 분야에서 경력을 쌓았으며, 최근 클라우드 기반 데이터보호 업체인 드루바(Druva)에 합류했다. ciokr@idg.co.kr



2019.10.29

클라우드 오브젝트 스토리지, 꼭 백업해야 하나?

W. Curtis Preston | Network World
클라우드 블록-스토리지 서비스에 저장된 데이터는 제대로 백업하지 않으면 영원히 소실될 가능성이 있다. 오브젝트 스토리지가 블록 스토리지와 서로 얼마나 다르고, 얼마나 더 우수한 빌트-인 보호를 제공하는지 알아보자.  
 
ⓒGetty Images Bank

오브젝트 스토리지란 무엇인가? 
클라우드 사업자는 오브젝트 스토리지 서비스를 제공한다. 예를 들어 아마존의 심플 스토리지 서비스(Simple Storage Service, S3), 애저의 블롭 스토어, 구글의 클라우드 스토리지 같은 것들이다. 

오브젝트 스토리지 시스템은 계층적 디렉토리 및 서브디렉토리 구조가 없는 일종의 파일 시스템이라 할 수 있다. 파일 시스템은 파일을 식별하고 위치를 파악하는데 디렉토리 구조와 파일 이름의 조합을 이용하는 데 비해, 오브젝트 스토리지 시스템에 저장된 모든 오브젝트는 이의 콘텐츠에 따라 고유 식별자(Unique IDentifier, UID)가 주어진다.  

그때부터 UID는 오브젝트를 식별하고 회수하는 방법으로 사용된다. UID는 파일 콘텐츠를 SHA-1과 같은 암호 알고리즘을 통해 실행시킴으로써 생성된다(SHA-1이 어떻게 작용하는지 알려면 임의의 양의 텍스트를 삽입해 SHA-1 해시를 스스로 생성해보라). 파일이든, 블록이든, 파일이나 블록 집단이든, 또는 블록이나 파일의 부분이든, 어떤 항목이든 오브젝트로 저장될 수 있다. 

오브젝트 스토리지와 블록 스토리지 간의 큰 차이라면 오브젝트 스토리지에 저장된 모든 오브젝트는 최소한 3곳의 가용 구역으로 자동으로 복사된다는 점이다. 이는 자연재해 등으로 인해 2곳의 가용 구역이 파괴되더라도, 오브젝트 스토리지 시스템 내에 저장된 데이터가 계속 존재할 것이라는 의미다. 블록 스토리지는 일반적으로 한 가용 구역 내에만 복제되어, 한 번의 큰 정전만으로 데이터가 소실될 수 있다. 

복제가 이루어지는 방식 역시 매우 상이하다. 오브젝트 복제는 오브젝트 수준에서 이루어지는 반면, 클라우드 블록 스토리지 및 보편적 RAID 시스템은 블록 수준에서 복제가 이루어진다.  

또한 오브젝트는 절대로 변경되지 않는다. 오브젝트가 변경되어야 한다면 그냥 새 오브젝트로 저장될 뿐이다. 버전 분류가 지원된다면 이전 오브젝트 버전은 역사적 목적으로 저장된다. 

클라우드 사업자는 오브젝트 스토리지 서비스를 제공한다. 예컨대 아마존의 심플 스토리지 서비스, 애저의 블롭 스토어, 구글의 클라우드 스토리지 등이다. 이들 오브젝트 스토리지 시스템은 심지어 모든 가용 구역을 파괴하는 지역 재난까지 견딜 수 있도록 가설될 수 있다. 

아마존은 교차-지역 복제를 이용해 이를 실행하고, 이는 고객이 스스로 구성해야 한다. 마이크로소프트의 지역 중복 스토리지는 여러 지역을 아우르며 복제가 이루어지고, 구글은 같은 기능이라 할 수 있는 2중 지역 및 다중-지역 스토리지를 제공한다. 오브젝트-스토리지 시스템은 시스템 내의 버전 분류 기능과 조합되어 위 사업자들이 제공하는 어떤 블록 스토리지 시스템보다 데이터를 한층 탄력적으로 보존할 수 있다.  

블록 볼륨과 파일 시스템은 성능을 위주로 설계되었지만, 오브젝트 스토리지는 데이터 무결성에 가장 중요한 목표를 두고 설계되었다. 예를 들어, 언제든지 고유 식별자를 이용해 오브젝트의 일정 사본이 훼손되지 않았음을 확인할 수 있다. 시스템이 하는 일은 고유 식별자를 생성했던 프로세스를 통해 오브젝트를 재실행하는 것뿐이다. UID가 여전히 동일하다면 오브젝트의 콘텐츠는 변경되지 않은 것이다. 오브젝트의 콘텐츠가 품질 저하나 다른 이유로 변경되었다면 UID가 변경될 것이기 때문에 시스템은 이를 자동으로 인지한다. 그렇다면 다른 구역에 있는 무결한 사본을 회수해 오브젝트를 자동으로 수리할 수 있다. 필자가 아는 한, 어떤 블록 장치나 파일 시스템도 이 정도 수준의 데이터 무결성을 갖추고 있지는 않다.   

오브젝트 스토리지는 이른바 오픈-버킷 문제 때문에 많은 논란에 휩싸여왔다. 오픈-버킷 문제란 권한 관리가 부실한 버킷에 중요하고 민감한 데이터를 보존하는 것이다(버킷은 오브젝트를 저장해 놓은 매우 큰 컨테이너 정도로 생각하면 된다). 

대형 고객 데이터베이스들이 이 문제를 겪어왔다. 이는 주로 고객이 오브젝트 스토리지가 어떻게 작용하는지를 단순히 몰랐다는 사실에 기인한다. 오픈 버킷을 생성하는 것이 분명히 가능하고, 오브젝트로의 직접적인 링크를 제공함으로써 여러 사람에게 파일을 쉽게 유포할 수 있다. 그러나 오픈 버킷을 생성했다가 영업 비밀을 무심코 전세계에 노출해버릴 수도 있음을 유의해야 한다.   

베스트 프랙티스 준수 
선호하는 오브젝트 스토리지에 관한 베스트 프랙티스를 구글에서 검색하면 이를 적절히 처리하는데 필요한 자료를 얻을 수 있다. 예를 들어 아마존은 한 웹 페이지에서 퍼블릭-액세스 같은 기능을 차단하고, 모든 사람에 대한 권한을 재설정하는 등 여러 상식적인 제안을 내놓고 있다. 마이크로소프트도 베스트 프랙티스 웹 페이지가 있고, 구글도 있다. 또한 이를 지도하는 서드파티 글도 수없이 많다.  

한가지 상식적인 제안이라면 특정 애플리케이션에 필요한 접근방식을 식별한 후 해당 접근만 허용하고 나머지는 전부 차단하는 것이다. 애플리케이션이 오브젝트 스토리지 버킷에 전면적으로 접근하도록 허용하기는 훨씬 더 쉽지만, 필연적으로 보안 재난이 일어날 것이다. 아울러 필요 시 접근을 손쉽게 허용하고 취소할 수 있는 역할 기반 관리를 고려하라.  

오브젝트 스토리지는 백업이 필요한가? 
오브젝트 스토리지를 백업할지 결정하는 일은 블록 볼륨을 백업할지 결정하는 것처럼 단순하지 않다. 블록 볼륨과 다르게, 오브젝트 스토리지는 위해를 끼칠 수 있는 여러 원인을 방어하는 여러 보호 수준을 자동으로 포함한다. 예를 들어 선택적인 WORM(Write-Once-Read-Many) 보호 등이다. 교차-지역 복제 등 이용 가능한 모든 베스트 프랙티스를 준수한다면 데이터가 모두 소실되어 백업을 찾아야 할 일이 없을 것이다. 데이터 보호 전문가에게 의뢰한다면 견실한 전략을 수립할 수 있다. 

한편, 오브젝트 스토리지가 여전히 오류를 범할 수 있는 인간에 의해 작성되고 있다는 주장은 반박하기 쉽지 않다. 따라서 오브젝트 스토리지 내 데이터가 미션 크리티컬이라면 백업하는 것이 적절할 것이다. 

백업하는 방법은 여러 가지가 있다. 전혀 다른 차원의 서비스를 백업에 이용할 수도 있다. 예를 들어 AWS 글레이저 딥 아카이브, 애저 아카이브 스토리지, 구글 콜드라인 등이다. 이에 의해 오브젝트 데이터의 비상 시 사본을 유지할 수 있다. 데이터가 정말 중요하다면 이런 식으로 백업하는 것을 고려해야 한다. 또한 블록 스토리지에서와 마찬가지로 상이한 계정 및 지역이어야 한다.  
 
주의 깊게 사용할 것  
블록 볼륨은 백업해야 한다. 스스로 이들을 백업해야 한다. 블록 스토리지 스냅샷도 다른 지역 및 계정으로 복제해야 한다. 오브젝트 스토리지는 여러 가용 구역으로 복제가 자동으로 이루어지기 때문에, 한층 높은 수준의 탄력성을 제공한다. 그렇다고는 하지만 완벽이란 없기 때문에 정보를 참조하며 재량에 따라 결정을 내려야 한다. 

*W. Curtis Preston은 백업, 저장, 복구 전문가로서 1993년부터 이 분야에서 경력을 쌓았으며, 최근 클라우드 기반 데이터보호 업체인 드루바(Druva)에 합류했다. ciokr@idg.co.kr

X