2019.09.23

'AWS는 만능이 아니야'··· EBS 데이터 백업 방법

W. Curtis Preston | Network World
최근 발생한 아마존의 정전으로 인해 몇몇 고객의 계정에 저장된 실무 데이터가 소실되는 사고가 있었다. 이는 어김 없이 클라우드를 반대하는 지적으로 이어졌다. 그러나 실상은 고객의 데이터 소실이 클라우드와 전혀 관계가 없다는 것이다. 자신이 이용 중인 스토리지를 제대로 파악하지 못하고 백업하지 않은 고객에 전적으로 책임이 있다.
 
ⓒ Getty Images Bank

노동절 주말 동안 AWS US-East-1 지역에 있는 서비스 구역 중 하나에서 정전이 발생했다. 보조 발전기가 가동됐지만, 알려지지 않은 이유로 작동이 금방 멈췄다. 고객의 일래스틱 블록 스토어(Elastic Block Store, EBS)는 복수의 서버에 복제되지만, 이번 정전은 여러 서버에 영향을 주었다. EBS에 저장된 데이터 대부분은 무사했거나 정전 후 간단히 복구할 수 있었다. 그러나 0.5%의 데이터는 복구할 수 없었다. 0.5%에 속한 고객은 EBS 데이터의 백업을 가지고 있지 않았고, 실제로 데이터를 소실했다.

IT를 아웃소싱 할 수 있다는 주장이 많지만 IT에 대한 책임까지 아웃소싱 할 수는 없다. 회사의 중요한 데이터를 저장하는데 다른 회사의 서비스를 이용할 계획이라면 해당 서비스가 어떻게 작용하는지 이해해야 한다. 서비스 회사가 제공하는 네이티브 보호 툴이 무엇인지, 그리고 (더 중요하게도!) 서비스 회사가 제공하지 않는 보호는 무엇인지 정도는 알고 있어야 한다. 여기서는 아마존의 일래스틱 블록 스토어를 살펴보고 저장된 데이터를 백업하는 방법을 살펴보자.

EBS 작동 방식
EBS(Elastic Block Store)는 기본적으로 클라우드 내의 지극히 안정적인 가상 하드 드라이브이다. EBS를 단순히 매우 멋진 하드 드라이브로 생각한다면, 이를 보호하기 위해 무엇을 해야 할 지 즉시 분명해진다. 문제는 클라우드 스토리지가 무엇이든 자동으로 보호될 것이라고 생각하는 사람이 많다는 것이다. 이는 전혀 사실이 아니다. 최근의 아마존 정전 사태가 이를 잘 설명해준다. 고객은 자신의 통제 밖에 있는 사고로 인해 데이터를 소실했다.  

EBS 볼륨은 서비스 지역 내의(특정 지리적 위치) 여러 서버 간의 복제에 의해 보호된다. 이는 데이터센터의 RAID 어레이에서 얻을 수 있는 것과 기본적으로 동일한 블록-수준 복제다. RAID 보호 스토리지와 마찬가지로 논리적 손상 역시 무엇이든 복제된다. 그러면 해당 EBS 볼륨 상에 보관된 모든 데이터가 훼손되든지 삭제된다. 여기서 '논리적 손상'은 여러 이유로 발생할 수 있다. 예를 들어 인간 오류(디렉터리를 무심코 삭제), 소프트웨어 에러(버그), 순간적인 전력 급등 같은 것이다. 이게 RAID 어레이를 백업하는 이유이고, 이용자가 EBS 볼륨을 백업해야 하는 이유이다. 

아마존은 EBS 제품 설명에서 실패율을 0.1~0.2%로 설명했다. 1,000개의 볼륨이 있다면 1년에 1개 또는 2개의 볼륨이 소실된다는 의미다. 이는 개별 하드 드라이브보다 대략 10배 우수한 수치지만 볼륨이 수천 개에 이른다면 사소한 것이 아니다. 이어 볼륨을 보호하는 스냅샷 서비스를 제공한다고 서술했다. EBS 스냅샷으로 EBS 볼륨을 보호한다는 것이다. 
 
EBS 스냅샷이란
EBS 스냅샷은 특정 시간에 찍은 볼륨의 이미지 사본이다. 이는 스토리지 분야에 쓰이는 스냅샷이라는 용어와 의미가 크게 다르다. 최초의 스냅샷, 즉 이미지 사본은 전체 백업이고, 이후의 스냅샷은 블록-수준의 점증적 백업이다. 이 이미지는 S3에서 하나의 객체로 저장되지만, S3에서 볼 수는 없다. 보존하고 싶은 데이터를 생성하는 중요한 애플리케이션이 EC2를 이용한다면, 어떤 데이터 볼륨이든 모두 백업돼야 하고 EBS 스냅샷은 이를 위한 손쉽고 자동화된 방식이다.  

EBS 스냅샷에 관한 베스트 프랙티스를 보면, ‘모든 낡은 것이 다시 새로워진다’라는 문구가 있다. EBS는 볼륨의 이미지 수준 사본이므로, 스냅샷을 생성하는 동안 볼륨이 변경돼서는 안 된다. 따라서 해당 볼륨을 이용하는 모든 인스턴스를 중지해 백업 중에 데이터를 기록하지 않도록 해야 한다.

그러나 이는 대부분의 사람에게 현실적으로 가능하지 않다. 따라서 스냅샷을 생성하는 중에 볼륨에 쓰기를 임시적으로 정지하는 VM내의 명령을 실행하는 것이 가장 좋은 방법이다. 또는 VM이 윈도우를 실행 중이라면 윈도우의 VSS서비스와 통합하는 것 역시 가능하다. 이용자가 볼륨 수준의 스냅샷을 생성하기 전에 윈도우가 먼저 애플리케이션-컨시스턴트 스냅샷을 생성하는 방식이다. 윈도우를 실행 중이 아니라면 사전 및 사후 스크립팅이 스냅샷을 찍는 동안 데이터 무결성을 보장할 수 있는 유일한 방법이다.

스냅샷에 관해 한가지 주의해야 할 것은 추가 비용이 든다는 점이다. 따라서 EBS 데이터를 백업하기 위해 스냅샷을 생성하는 과정의 일부로, 특정 기한이 지난 스냅샷을 자동으로 제거하도록 설정해야 S3 비용을 줄일 수 있다. 이를 위한 한가지 방법은 아마존 데이터 라이프사이클 매니저를 이용하는 것이다. 태그를 이용해 각 스냅샷을 식별하고, 생성 시 스냅샷의 전체 라이프사이클을 구체적으로 지정할 수 있다. 예를 들어 이를 얼마나 오래 보존할 것인가를 설정하는 식이다. 

무료 및 상용 서드-파티 툴도 있다. 아마존이 별도의 설치나 구성 없이 제공하는 기능에 추가해 다른 기능까지 쓸 수 있다. 예를 들어 상용 툴을 이용하면 EBS 스냅샷을 다른 지역이나 다른 계정으로 자동 복사할 수 있어, 해커가 이용자 계정으로 액세스하는 것을 막을 수 있다.  

EBS는 아마존 웹 서비스에서 블록 스토리지를 위한 주요 선택지다. 그러나 이는 마법이 아니고, 해를 입을 수 있는 모든 것을 자동으로 보호하지 않는다. AWS가 제공하는 백업 서비스를 활용한다면 최악의 사태가 일어나더라도 손쉽게 복구할 수 있다. ciokr@idg.co.kr



2019.09.23

'AWS는 만능이 아니야'··· EBS 데이터 백업 방법

W. Curtis Preston | Network World
최근 발생한 아마존의 정전으로 인해 몇몇 고객의 계정에 저장된 실무 데이터가 소실되는 사고가 있었다. 이는 어김 없이 클라우드를 반대하는 지적으로 이어졌다. 그러나 실상은 고객의 데이터 소실이 클라우드와 전혀 관계가 없다는 것이다. 자신이 이용 중인 스토리지를 제대로 파악하지 못하고 백업하지 않은 고객에 전적으로 책임이 있다.
 
ⓒ Getty Images Bank

노동절 주말 동안 AWS US-East-1 지역에 있는 서비스 구역 중 하나에서 정전이 발생했다. 보조 발전기가 가동됐지만, 알려지지 않은 이유로 작동이 금방 멈췄다. 고객의 일래스틱 블록 스토어(Elastic Block Store, EBS)는 복수의 서버에 복제되지만, 이번 정전은 여러 서버에 영향을 주었다. EBS에 저장된 데이터 대부분은 무사했거나 정전 후 간단히 복구할 수 있었다. 그러나 0.5%의 데이터는 복구할 수 없었다. 0.5%에 속한 고객은 EBS 데이터의 백업을 가지고 있지 않았고, 실제로 데이터를 소실했다.

IT를 아웃소싱 할 수 있다는 주장이 많지만 IT에 대한 책임까지 아웃소싱 할 수는 없다. 회사의 중요한 데이터를 저장하는데 다른 회사의 서비스를 이용할 계획이라면 해당 서비스가 어떻게 작용하는지 이해해야 한다. 서비스 회사가 제공하는 네이티브 보호 툴이 무엇인지, 그리고 (더 중요하게도!) 서비스 회사가 제공하지 않는 보호는 무엇인지 정도는 알고 있어야 한다. 여기서는 아마존의 일래스틱 블록 스토어를 살펴보고 저장된 데이터를 백업하는 방법을 살펴보자.

EBS 작동 방식
EBS(Elastic Block Store)는 기본적으로 클라우드 내의 지극히 안정적인 가상 하드 드라이브이다. EBS를 단순히 매우 멋진 하드 드라이브로 생각한다면, 이를 보호하기 위해 무엇을 해야 할 지 즉시 분명해진다. 문제는 클라우드 스토리지가 무엇이든 자동으로 보호될 것이라고 생각하는 사람이 많다는 것이다. 이는 전혀 사실이 아니다. 최근의 아마존 정전 사태가 이를 잘 설명해준다. 고객은 자신의 통제 밖에 있는 사고로 인해 데이터를 소실했다.  

EBS 볼륨은 서비스 지역 내의(특정 지리적 위치) 여러 서버 간의 복제에 의해 보호된다. 이는 데이터센터의 RAID 어레이에서 얻을 수 있는 것과 기본적으로 동일한 블록-수준 복제다. RAID 보호 스토리지와 마찬가지로 논리적 손상 역시 무엇이든 복제된다. 그러면 해당 EBS 볼륨 상에 보관된 모든 데이터가 훼손되든지 삭제된다. 여기서 '논리적 손상'은 여러 이유로 발생할 수 있다. 예를 들어 인간 오류(디렉터리를 무심코 삭제), 소프트웨어 에러(버그), 순간적인 전력 급등 같은 것이다. 이게 RAID 어레이를 백업하는 이유이고, 이용자가 EBS 볼륨을 백업해야 하는 이유이다. 

아마존은 EBS 제품 설명에서 실패율을 0.1~0.2%로 설명했다. 1,000개의 볼륨이 있다면 1년에 1개 또는 2개의 볼륨이 소실된다는 의미다. 이는 개별 하드 드라이브보다 대략 10배 우수한 수치지만 볼륨이 수천 개에 이른다면 사소한 것이 아니다. 이어 볼륨을 보호하는 스냅샷 서비스를 제공한다고 서술했다. EBS 스냅샷으로 EBS 볼륨을 보호한다는 것이다. 
 
EBS 스냅샷이란
EBS 스냅샷은 특정 시간에 찍은 볼륨의 이미지 사본이다. 이는 스토리지 분야에 쓰이는 스냅샷이라는 용어와 의미가 크게 다르다. 최초의 스냅샷, 즉 이미지 사본은 전체 백업이고, 이후의 스냅샷은 블록-수준의 점증적 백업이다. 이 이미지는 S3에서 하나의 객체로 저장되지만, S3에서 볼 수는 없다. 보존하고 싶은 데이터를 생성하는 중요한 애플리케이션이 EC2를 이용한다면, 어떤 데이터 볼륨이든 모두 백업돼야 하고 EBS 스냅샷은 이를 위한 손쉽고 자동화된 방식이다.  

EBS 스냅샷에 관한 베스트 프랙티스를 보면, ‘모든 낡은 것이 다시 새로워진다’라는 문구가 있다. EBS는 볼륨의 이미지 수준 사본이므로, 스냅샷을 생성하는 동안 볼륨이 변경돼서는 안 된다. 따라서 해당 볼륨을 이용하는 모든 인스턴스를 중지해 백업 중에 데이터를 기록하지 않도록 해야 한다.

그러나 이는 대부분의 사람에게 현실적으로 가능하지 않다. 따라서 스냅샷을 생성하는 중에 볼륨에 쓰기를 임시적으로 정지하는 VM내의 명령을 실행하는 것이 가장 좋은 방법이다. 또는 VM이 윈도우를 실행 중이라면 윈도우의 VSS서비스와 통합하는 것 역시 가능하다. 이용자가 볼륨 수준의 스냅샷을 생성하기 전에 윈도우가 먼저 애플리케이션-컨시스턴트 스냅샷을 생성하는 방식이다. 윈도우를 실행 중이 아니라면 사전 및 사후 스크립팅이 스냅샷을 찍는 동안 데이터 무결성을 보장할 수 있는 유일한 방법이다.

스냅샷에 관해 한가지 주의해야 할 것은 추가 비용이 든다는 점이다. 따라서 EBS 데이터를 백업하기 위해 스냅샷을 생성하는 과정의 일부로, 특정 기한이 지난 스냅샷을 자동으로 제거하도록 설정해야 S3 비용을 줄일 수 있다. 이를 위한 한가지 방법은 아마존 데이터 라이프사이클 매니저를 이용하는 것이다. 태그를 이용해 각 스냅샷을 식별하고, 생성 시 스냅샷의 전체 라이프사이클을 구체적으로 지정할 수 있다. 예를 들어 이를 얼마나 오래 보존할 것인가를 설정하는 식이다. 

무료 및 상용 서드-파티 툴도 있다. 아마존이 별도의 설치나 구성 없이 제공하는 기능에 추가해 다른 기능까지 쓸 수 있다. 예를 들어 상용 툴을 이용하면 EBS 스냅샷을 다른 지역이나 다른 계정으로 자동 복사할 수 있어, 해커가 이용자 계정으로 액세스하는 것을 막을 수 있다.  

EBS는 아마존 웹 서비스에서 블록 스토리지를 위한 주요 선택지다. 그러나 이는 마법이 아니고, 해를 입을 수 있는 모든 것을 자동으로 보호하지 않는다. AWS가 제공하는 백업 서비스를 활용한다면 최악의 사태가 일어나더라도 손쉽게 복구할 수 있다. ciokr@idg.co.kr

X