[회고] AWS 시스템 운영 (2) - 백업 자동화
이 글은 AWS 시스템 운영 1편에서 이어지는 내용입니다.
백업 자동화 - DLM(Data Lifecycle Manager)을 활용한 AMI 기반 EC2 백업 구축
운영 환경에서는 장애 발생 시 **RTO(복구 목표 시간)**를 최소화하기 위해서는 견고한 정기 백업 체계가 필수적입니다.
초기에는 개별 EBS 볼륨 단위의 스냅샷 백업을 검토했으나, 고객사의 요구사항을 반영하여 운영 서버 전체를 즉각 복구할 수 있는 방안을 모색하게 되었습니다. 그 결과, 인스턴스 단위의 형상을 그대로 보존하는 AMI(Amazon Machine Image) 기반 백업 자동화를 도입했습니다.
AMI 기반 백업을 선택한 이유
EBS 스냅샷이 개별 데이터 조각을 저장한다면, AMI는 인스턴스의 ‘스냅샷’ 그 자체를 제공합니다. AMI 백업을 사용하면 다음과 같은 요소가 통째로 저장됩니다.
- OS 및 커널 설정
- 설치된 애플리케이션 및 환경 변수
- 연결된 모든 EBS 볼륨의 데이터 덕분에 장애 발생 시 복잡한 재설정 과정 없이, 기존과 동일한 구성의 인스턴스를 즉시 프로비저닝하여 서비스를 정상화할 수 있습니다.
DLM(Data Lifecycle Manager)을 활용한 AMI 자동 생성
AMI 백업 자동화를 위해 AWS의 **DLM(Data Lifecycle Manager)**기능을 활용했습니다.
DLM은 태그(Tag) 기반으로 백업 생성 및 삭제 주기를 관리하므로 운영 공수를 획기적으로 줄여줍니다.
백업 대상 서버에는 다음과 같은 태그를 적용했습니다.
ImageBackupTarget = TrueDLM 정책 설정:
- 대상: ImageBackupTarget = True 태그가 설정된 EC2 인스턴스
- 백업 주기: 하루 1회
- 보관 기간: 고객사 및 서버 용도에 따라 1일 또는 7일로 차등 설정
- 자동 삭제(Retention): 1일 혹은 7일 이후 자동 삭제
동작 프로세스
- DLM 정책이 지정된 태그(ImageBackupTarget)를 가진 인스턴스 식별
- 해당 시점의 AMI 생성 시작
- 연결된 모든 EBS Volume의 Snapshot 생성 및 매핑
- 설정된 보존 기간(Retention)이 지난 구형 AMI 및 스냅샷 자동 삭제(Clean-up)
생성된 AMI는 EC2 콘솔에서 확인할 수 있으며, 필요 시 해당 AMI를 사용하여 새로운 인스턴스를 생성할 수 있습니다.
실무 적용 효과 및 복구 경험
AMI 기반 백업 자동화 도입 후, 다음과 같은 운영 이점을 얻었습니다.
- 완전한 서버 복구: 데이터뿐만 아니라 OS 환경까지 한 번에 복원 가능
- 운영 리소스 절감: 수동 백업 및 삭제 작업 불필요
- 비용 최적화: Retention 정책을 통해 불필요한 스토리지 비용 방지
장애 발생 시 복구 프로세스
- EC2 콘솔 내 [AMI] 메뉴 접속
- 백업된 AMI 선택 후 [Launch Instance from AMI] 클릭
- 기존 인스턴스 사양에 맞춰 실행 시 복구 완료
이 프로세스를 구축함으로써 운영 환경의 복구 신뢰도를 대폭 높였습니다. 실제로 운영 중 예기치 못한 서버 이슈가 발생했을 때, 이 과정을 통해 서비스를 신속하게 정상화하며 실무적인 안정성을 증명할 수 있었습니다.