AMI 관리, 서버를 다시 만들 수 있는 상태로 보관하기

이미지는 서버를 다시 만들 수 있는 상태의 사본입니다

머신 이미지는 디스크 내용과 시작 설정을 묶어 둔 사본이고, 같은 상태의 서버를 다시 만들 때 씁니다. 그래서 질문은 '백업을 어디에 두는가'가 아니라 '이 이미지로 지금 서버를 다시 세울 수 있는가'입니다. 다시 세울 수 없다면 이미지가 있어도 복구 수단이 아닙니다. 확인 방법은 한 가지뿐입니다. 이미지로 새 인스턴스를 띄워 서비스가 뜨는지 실제로 해 보는 것입니다. 이 시험을 한 번도 하지 않은 이미지는 '있다고 믿는 백업'입니다. 운영 중인 서버에서 그대로 떠낸 이미지에는 호스트 이름, 로그 파일, 임시 자격 증명처럼 복제되면 안 되는 흔적이 섞여 있기 쉽습니다.

이미지에 넣지 말아야 하는 네 가지

이미지를 만들 때 빼야 하는 항목이 있습니다. 첫째는 자격 증명입니다. 키나 토큰을 디스크에 둔 채 이미지를 뜨면 그 이미지를 쓰는 모든 서버가 같은 비밀을 공유합니다. 둘째는 호스트 고유 식별자입니다. 같은 식별자를 가진 서버가 여러 대 생기면 모니터링과 로그가 섞입니다. 셋째는 누적된 로그와 임시 파일입니다. 이미지 용량만 키우고 복구에 쓸모가 없습니다. 넷째는 사람이 수동으로 고친 설정입니다. 기록이 남지 않아 다음 이미지에서 사라집니다. 대신 넣어야 하는 것은 기본 패키지와 설정 적용 도구입니다. 서버 고유 값은 시작 시점에 주입하는 구조로 바꿉니다.

굽는 주기와 보관 개수를 숫자로 정합니다

학습용 가정으로 계산합니다. 가정값은 이미지 1개가 8기가바이트를 차지하고 보관 단가가 기가바이트당 월 60원이라고 두겠습니다. 이미지 1개의 월 보관 비용은 480원입니다. 주 1회 굽고 모두 보관하면 1년 뒤 52개가 되어 월 24,960원입니다. 중간 계산값입니다. 최종 금액은 보관 규칙을 넣어야 나옵니다. 최근 4개와 월말 이미지 12개만 남기는 규칙이면 16개로 월 7,680원이 되고, 연간 차이는 207,360원입니다. 여기에 굽는 작업 시간을 더합니다. 회당 10분이 들고 내부 시간 비용을 시간당 30,000원으로 가정하면 주 1회는 연 52회 곱하기 10분으로 약 8.7시간이므로 연 260,000원입니다. 자동화하면 이 항목이 사라집니다.

복구 시험을 건너뛰면 규칙이 무의미합니다

결론을 뒤집는 조건은 복구 시험의 부재입니다. 보관 규칙을 잘 세워도 이미지로 서버가 뜨지 않으면 비용만 지출한 셈입니다. 그래서 분기마다 1회, 가장 오래된 보관 이미지로 인스턴스를 띄워 서비스 기동까지 확인하고 소요 시간을 기록합니다. 두 번째 조건은 의존성 변경입니다. 외부 저장소 주소나 설정 서버가 바뀌면 과거 이미지는 기동 중에 멈춥니다. 이 경우 보관 기간을 길게 잡는 것이 오히려 위험을 늘리므로, 의존성 변경 시점에 기준 이미지를 다시 굽고 그 이전 이미지는 복구 대상에서 제외한다고 적어 둡니다.

클라우드 비교 실행 전 점검표

• 이미지로 새 인스턴스를 띄워 서비스 기동을 확인했다
• 자격 증명·호스트 식별자·로그·수동 설정을 제외했다
• 보관 개수 규칙을 정하고 월 비용을 계산했다
• 분기 1회 가장 오래된 이미지로 복구 시험을 한다