AWS Glacier는 뭐지? - AWS S3 와 Glacier 장단점 비교

AWS Glacier?

  Glacier는  아카이브 백업 데이터를 주 목적으로 하는 스토리지 서비스이다. 얼핏 보면 S3와 비슷한 것 같지만 서비스 목적이 다르다. Glacier 라는 뜻 자체가 "빙하" 인것 만 봐도 이 서비스가 무엇을 위한 것인지 느낌이 오는 사람도 있을 것이다. 본격 레알 cold data를 위한 서비스

 어떤 경우에 사용하면 좋을까?

 보통 서비스를 운영할 때, 해당 서비스의 데이터들을 일정 주기로 어딘가에 백업을 하게 된다. 아주 예전에는 주로 마그네틱 테이프에 저장하고 이 테잎을 어딘가에 차곡차곡 쌓아 놓곤 했다. 그리곤 이 데이터는 굳이 찾아 볼 일은 없다. 하지만 이 데이터를 찾아보는 순간이 찾아 온다면, 그건 굉장히 안타까운 경우일 것이다. 서비스가 완전히 무너져 눈물의 복구를 시도할때.. 먼지 쌓여 있는 테이프를 꺼내며.. 제발 이 테잎이 데이터를 제대로 읽어와 무사히 복구가 되기를 기도하는 경우를 상상해 볼 수 있다. 

 Glacier는 바로 이러한 경우에 유용하게 사용될 서비스이다. 테이프 백업 처럼 어딘가에 데이터를 저장해 놓지만, 무슨일이 있기 전까지 절대 열어 볼 일은 없는.. 하지만 어딘가에 확실히 저장되어 있어야 하는 빙하의 얼음과 같은 cold data 들 말이다. 

이러한 백업 데이터에게 가장 필요한 점은 바로 "안정성" 과 "가격" 일 것이다.

백업을 하기 위한 설비 구입 비용은 최소화 하면서 반 영구적으로 안전하게 저장하는 방법 말이다. 이러한 것을 해소 시켜줄 서비스가 바로 Glacier 이다. 

Glacier 의 장단점 과 S3 비교

먼저 장점 부터 살펴 보자. 

Glacier는 아카이브 백업을 위한 초기 투자 비용이 들지 않으며, 저장한 만큼 비용을 지불한다. 이는 기존의 S3와 동일하다.

그러나 Glacier는 S3보다 더욱 저렴한 가격에 제공된다는 장점이 있다.

단순 데이터 저장 가격만 비교해 보면, 

서울 Region 기준으로  Glacier는 S3 대비 약 1/3 수준이다. ( S3 표준 GB당 월 $0.0314 / Glaicer $0.010 )

매우 놀라운 가격이 아닐 수 없다. 

게다가 이런 저렴한 가격임에도 불구하고 Glacier는 S3와 동일한 내구성인 99.999999999 % 를 보장한다.

즉, 위에서 언급 했던 두가지 특징인, 아카이브 백업 데이터를 위한 "안정성"과 "가격" 이라는 측면에서는 Glacier가 최적 임에 틀림 없다. 

추가적인 장점으로 언급될 만한 부분은

AWS의 서비스 답게 AWS의 다른 서비스와의 연계가 매우 손쉽게 가능하다는 점이다. 

IAM을 통한 Resource 에 대한 권한 설정이 detail하게 가능하며,

Cloudtrail을 통해 어떤 user가 언제 아카이브 데이터에 접근했는지 Audit 로깅도 가능하다. 

또한 S3와 연계를 통해, S3에서 자동으로 Glacier로 아카이브 되도록 손쉽게 설정이 가능하여 비용 절감 효과를 가져오도록 만든 점도 장점이다. 

S3와 Glacier의 연동은 다음 링크를 통해 자세히 알아보자. 

( AWS S3에서 Glacier로 자동 백업 )

그러나 Glacier는 단점도 명확하다. 

첫째로, Glacier에 저장된 데이터는 마음대로 검색이 불가능하다. 

Glacier는 데이터의 "사용"이 아니라 "저장"이 주 목적이기 때문이다. 

검색의 경우, 매달 Glacier에 저장된 용량의 최대 5% 에 대한 검색만 무료로 허용되며 이 용량도 일단위로 나뉘어 할당되어 진다. 

예를 들어 특정한 시점에 Glacier에 저장된 용량이 10TB였다면, 그날 무료로 검색이 가능한 용량은 (10TB X 0.05) / 30일 = 16.66GB가 되는 것이다. (한달은 30일로 계산된다)

만약 무료 검색 가능 용량을 초과할 경우에는 GB당 0.01 USD 가 추가 청구 된다. 

대규모 검색의 경우 복잡한 계산 과정이 들어가는데 자세한 내용은 Glacier 관련 FAQ 페이지를 확인해 보자. ( Glacier FAQ바로가기 )

둘째로, Glacier에 올라간 데이터는 마음대로 삭제가 불가능하다.  

앞에서 언급했듯, Glacier의 주목적은 아카이브 데이터에 대한 저장이며, 이것은 기본적으로 몇 달 또는 몇 년간 저장되는 것을 전제로 설계한 서비스이기 때문이다.

기본적인 삭제에 대한 전제 조건은 3개월 이상 저장하였을 경우이다. 

즉, 3개월 이전에 조기 삭제한 경우 이에 따른 비용이 청구 된다. (3개월이 지나면 삭제는 무료)

서울 Region의 경우를 예로 들어보자. 

서울의 경우 데이터 보관 가격은 1GB당 0.010 USD 이다. 

만약 1개월을 저장 후 데이터를 삭제한 경우에는 3개월이라는 최소 시점보다 2개월을 앞당겨 삭제하였으므로

GB당 0.010 X 2개월 치인 0.020 USD의 패널티 금액을 지불하게 된다. 

그러므로 Glacier는 장기간 데이터를 저장하는 경우에 유리한 것이다. 

셋째로, Glacier에 데이터를 업로드하거나 검색하는 경우 따로 UI를 제공해 주지는 않는다는 점이다. 

물론 AWS Management console을 통해 Vault ( S3의 Bucket과 동일한 Glacier의 기본 단위 ) 에 대한 기본적인 설정은 가능하다. 

하지만 데이터 업로드는 API를 통해서만 가능하다. 

하지만 가장 아쉬운 점은 마지막으로 언급할 Retrieval에 대한 점이다. 

 

Glacier의 아쉬움 - 데이터 복구 Retrieval

만약 Glacier에 저장된 아카이브 데이터를 이용해 데이터를 복구해야 하는 경우는 어떨까.

아카이브 된 데이터를 가져와 다운로드 하는 작업인 Retrieval 을 하는데 약 3~5시간의 시간이 필요하다고 한다. 

필자가 생각하기에 이 서비스의 가장 아쉬운 점은 바로 이 부분이다. 

만약 AWS의 이야기대로 Glacier의 주요 타겟이 아카이브 데이터 저장 용도라고 한다면, 

이 데이터를 다운로드 받는 케이스가 대부분 긴급 장애 상황일 경우라는 것도 충분히 고려 되었어야 할 것이다.  

그런데 긴급하게 아카이브 데이터를 다운 받아야 할 상황에서 엔지니어에게 3~5시간의 기다림은 굉장히 속이 타들어가는 시간이 될 것이고, 이 것은 굉장히 Risk가 있는 조건임에 틀림 없다. 

따라서 이러한 복구 프로세스를 생각해 볼때 Glacier만 사용하는 것이 아니라 최근 백업 데이터는 먼저 S3에 저장하도록 하고

오래된 백업 데이터는 자동으로 Glacier로 옮기도록 설계하는게 필요할 것이다.  

마치며

Glacier는 데이터를 백업하고 저장하는데 그 목적을 두고 만든 서비스인 만큼, 그 목적에 충실한 서비스 임에 틀림 없다. 

아카이브 데이터가 가장 필요로 하는 가격과 안정성 측면을 두고 볼 때 이만한 서비스는 없기 때문이다. 

그러나 데이터 복구에 대한 실시간성을 보장해 주지 않는다는 측면은 아쉬움으로 남으며, 이를 고려해서 도입하는데 고민이 필요할 것으로 보인다.  

추가적인 현실들을 더 고려해 본다면, 

  1. 서버가 EC2의 경우는 상관 없겠지만, 만약 로컬 IDC에 존재하는 서버의 아카이브 데이터를 Glacier로 보내려면? 

     외부와 통신을 위해 각 서버마다 외부와의 통신을 허락할 것인가..

     이 부분은 AWS Storage Gateway의 VTL(Virtual Tape Library) 타입을 검토해 본다면 어느정도 해결 될 수 있을 것으로 보인다. 

     근데 AWS Storage Gateway가 뭐임?

  2. 아카이브 데이터를 클라우드와 같은 외부에 저장하는데에 대한 불안감. 

      결국 IAM가 Cloudtrail을 통한 철저한 권한 통제와 로깅 설정만이 답일 것 같다. 아님 쓰지마 

 

[참고]

• https://aws.amazon.com/ko/glacier/details/
• https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/object-archival.html
• https://aws.amazon.com/ko/glacier/faqs/
• https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/object-archival.html