AWS

EBS 백업 자동화를 손쉽게 – Data Lifecycle Manager 소개

여기서 다루는 내용

· AWS 환경의 스토리지 백업
· 백업 자동화를 구현하는 여러가지 방법
· Data Lifecycle Manager 살펴보기


스토리지 백업? 누구를? 어떻게?


안녕하십니까, GS네오텍 최준승입니다.

오늘은 AWS 新상 중 “단순하지만 쓸모 있는” 팁 하나를 소개해 드리려고 합니다.

주제는 EBS 볼륨 백업에 관한 내용인데요.
AWS 관리 콘솔을 열어 스토리지 항목을 한번 봅시다.


※ EC2에 마운트해서 사용하는 EBS, 고가용성/고내구성의 객체스토리지인 S3, 공유 파일시스템인 EFS 등이 있다

AWS에서는 이렇게 여러 종류의 스토리지 서비스를 각기 특성에 맞게 제공하고 있는데요.

이 중 S3는 별도의 백업이 필요 없어 보입니다.
객체 스토리지의 특성 중 하나가 내부 복제고. 이때문에 데이터가 유실될 확률이 극히 낮기 때문입니다.
물론 다른 리전에 Replication 설정을 할 수도 있지만. 단순 백업이 목적이라고 보긴 어렵습니다. 다른 용도도 있겠죠.

EFS 서비스도 나름 AZ에 걸쳐 내부 복제를 한다고는 설명서에 써있는데요.
반드시 백업이 필요하다면 다른 EFS로 백업하는 예제가 Cloudformation 템플릿 형태로 나와있습니다. 필요하면 쓰세요.

마지막은 블록 스토리지인 EBS 볼륨입니다.
EBS도 AZ내에서 내부적으로 복제(?)한다고는 하는데. 결국 스냅샷을 통한 백업을 권장하고 있습니다.
가상화 환경이니 방법도 아주 쉽습니다. 볼륨을 선택하고 “Create Snapshot”하면 끝이죠. 그럼 곧 스냅샷이 완성됩니다.

문제는 이걸 주기적으로 반복해야 한다는 점입니다.

이 귀찮은 작업을 어떻게 해야 할까요?


주기적 백업을 위한 여러가지 방법, 그리고 DLM의 등장


먼저 백업 자동화에는 어떤 선행 과정이 필요한지부터 생각해 봅시다.

  • 우선 백업 대상 볼륨을 식별하는 기준이 필요하구요
  • 스냅샷을 생성하는 시간과 주기 정보도 있어야 하구요
  • 스냅샷을 백만년동안 보관할게 아니라면 적절한 삭제 정책도 있어야 할겁니다
  • 마지막으로 생성한 스냅샷 객체에 붙힐 이름표까지 정해놓으면 완벽하겠네요

위의 것들이 정해졌다면? 만들면 됩니다.
막말로 백업 대상 목록을 만들어 AWSCLI로 스냅샷 생성&삭제 스크립트를 하나 짜놓고. cronjob을 돌려도 됩니다.
하지만 귀찮기 때문에. 스크립트는 Lambda로 대체하고 cronjob은 Cloudwatch events에 연동하기도 하고. 방법이야 많죠.

그래서 여러분도 한번 구글링해보시면 수많은 스냅샷 자동화 방법이 나열되어 있습니다.
github에 람다 코드가 올라와 있거나. AWS CloudFormation 템플릿도 있고. 심지어 솔루션도 있습니다.

하지만 이 모든것이 애머존 철학에 맞게 API를 싸바싸바해서 사용자가 구현한 것이지요.
그래서 좀 불편하고. 좀 믿음도 안가고. 결국 잘 돌아가는지 확인도 해야 하고. 귀찮고. 돈도 조금 드는것 같고..
“그냥 애머존 니네가 API 하나 빼서 만들어 주면 안될까??” 해서 나온 것이

바로 오늘 소개드릴 DLM – Data Lifecycle Manager 입니다.


DLM을 들여다보자


DLM은 언제 나왔냐구요? `18년 7월에 나왔습니다. 그리고 서울 리전에는? `18년 8월에 나왔구요.

어디 있냐구요? API는 찾아보시면 나오구요. AWS 관리 콘솔에서 찾으신다면 바로 여기 있지요.


※ [AWS Management Console] ▷ [EC2] ▷ [Elastic Block Store] ▷ [Lifecycle Manager]

워낙 간단하기 때문에 한번 들어가서 보시면 이해가 될텐데요. 간단히 정리하면 다음과 같습니다.

  • 지정한 태그 기반으로 백업 볼륨을 식별
  • 백업 주기 설정(12h/24h), 유지하는 스냅샷 개수 설정
  • 백업 주기에 따라 주기적으로 스냅샷을 생성하며, 볼륨 단위로 설정한 스냅샷 개수를 초과하면 오래된 객체부터 자동 삭제
  • 생성된 스냅샷 태그 설정, 정책 Enable/Disable 변경 가능

백문이 불여일견이니 한번 정책을 만들어 봅시다!

  • 태그 키가 “Backup”이고 값이 “yes”인 볼륨을 대상으로 스냅샷을 만든다
  • 시작 시점은 9시(UTC), 스냅샷 주기는 12시간 간격

  • 각 볼륨별로 최근 7개의 스냅샷만 보관하며
  • 생성된 스냅샷 객체에는 키 “Name” 값이 “snap-auto”인 태그를 붙여준다

하루를 기다려 보았습니다.

예상대로 12시간 간격으로 스냅샷이 잘 만들어지고 있네요. (참고로 해당 태그가 붙은 EBS 볼륨은 2개입니다)
편의상 짤렸지만, Description 항목에 보면 “Created for policy: policy-xxxx schedule: Default Schedule” 라고도 명시되어 있습니다.


마치며


이제 마칠 시간입니다.

오늘 소개드린 기능은 어떻게 보면 편의 기능입니다.
어찌보면 없으면 없는대로 가래로도 막고 호미로도 막고 대체가 가능한 부분인데요.

요즘 AWS 애들 업데이트를 보면. 이런 세심한 부분들까지. 터치를 많이 해주려는 느낌이 들곤 합니다.
이런 잔가지는 잔가지대로. 뿌리나 줄기는 그 나름대로 드라이브를 하는거보면 참 대단하단 생각도 들구요.

만일 여러분께서 기존에 다른 방법으로 백업 자동화를 구현하셨다면.
일부 제약사항이 있지만. 그것이 문제가 되지 않는다고 하면. DLM을 통해 구성을 대체해 보시는건 어떨까요?

끝!

Related Post

태그 : , , ,

필자: 최준승

GS네오텍에서 일하고 있습니다. 정리하는 것을 좋아합니다

전체 게시물수 : 117

전체 조회수 : 1346

게시물 공유하기