“재해 상황에서 모든 서버를 같은 방식으로 복구해야 할까요?”

재해복구(DR, Disaster Recovery)는 시스템 장애나 재해 상황에서 서비스를 복구하기 위한 체계입니다. 백업을 확보하고 복제를 구성하는 것까지는 비교적 명확한 작업에 해당합니다. 일반적으로 재해복구의 목표는 모든 시스템을 장애 이전 상태로 되돌리는 것으로 설정됩니다. 다만 모든 시스템에 동일한 복구 수준을 적용하려면 그만큼의 자원과 운영 부담이 따릅니다. 복구 시간을 짧게 잡을수록 상시 유지해야 하는 자원이 늘어나고, 보호 대상을 넓힐수록 복제 비용과 검증해야 할 범위도 함께 늘어납니다. 그래서 실제 구축에서는 시스템의 중요도에 따라 복구 수준을 나누게 되는데, 그 기준을 세우는 일이 쉽지 않습니다. 서버 목록과 사양만으로는 각 시스템이 어떤 조건에서 복구되는지, 그 조건을 갖추는 데 무엇이 필요한지 판단할 근거가 부족하기 때문입니다.

웅진프리드라이프는 온프레미스 서버 21대를 대상으로 AWS Elastic Disaster Recovery(AWS DRS) 기반 재해복구 체계를 구축하고 모의 복구 훈련을 수행하였습니다. 보호 대상의 86%가 Windows Server였으며, Windows Server 2012 R2부터 2019까지 여러 세대가 혼재한 환경이었습니다. 오랜 기간 운영되면서 서버마다 설정과 구성이 조금씩 달라져 있어, 자료만으로는 각 서버가 복구 환경에서 어떻게 동작할지 판단하기 어려운 상태였습니다.

그래서 복제를 구성한 뒤 drill 수행 과정을 통해 서버를 실제로 기동해보는 방식으로 하나씩 확인해 나갔습니다. 이 과정에서 복제 단계, 부팅 단계, 서비스 단계마다 확인해야 할 항목이 드러났고, 서버마다 복구에 필요한 조건이 서로 다르다는 점도 함께 확인할 수 있었습니다. 본 블로그에서는 단계별로 확인된 이슈와 대응 방법, 그리고 서버별 복구 목표를 정의하기까지의 과정을 공유합니다.

웅진프리드라이프 소개

웅진프리드라이프는 국내 상조업계를 선도하는 라이프 케어 기업입니다. 2019년 업계 최초로 누적 선수금 1조 원을 돌파한 데 이어 2023년 2조 원, 2026년 4월에는 단일 상조기업 최초로 3조 원을 넘어섰습니다.

2025년 6월에는 웅진그룹 계열사로 편입되어 웅진그룹은 기존 교육, 에너지, 여가 사업에 상조를 더해, 생애주기 전반을 지원하는 ‘토탈 라이프 케어’ 기업으로 사업 구조를 확장하고 있습니다. 이번 프로젝트는 AWS의 Migration & Modernization 컨설팅 파트너인 ㈜웅진 클라우드사업본부와 함께 진행되어 재해복구 체계 설계부터 복구 훈련 검증까지 약 4개월간 수행되었습니다.

프로젝트 배경과 목표

프리드라이프는 온프레미스 환경 전체를 AWS로 이관하는 마이그레이션을 준비하고 있었습니다. 이번 프로젝트는 그 여정의 첫 단계로, 두 가지 목표를 함께 설정했습니다.

1. 재해복구 체계 확보 – 24시간 운영되는 서비스에 대한 복구 수단 마련
2. 마이그레이션 사전 검증 – 온프레미스 서버들이 AWS 환경에서 정상 기동되는지, 이관 전에 정비해야 할 항목이 무엇인지 미리 확인

특히 마이그레이션 사전 검증 관점에서 AWS DRS의 Drill 기능은 운영 서비스와 복제 상태에 영향을 주지 않고 복구 인스턴스를 실제로 기동해볼 수 있도록 합니다. 재해복구 훈련인 동시에 마이그레이션 리허설로도 활용할 수 있는 구조입니다.

시스템 요구 사항

장례 의전은 발생 시점을 예측할 수 없고 접수 즉시 대응이 시작되어야 하는 24시간 서비스입니다. 콜센터(CTI), ERP, 회원·계약 관리, 홈페이지가 하나의 업무 흐름으로 연결되어 있어, 일부 시스템의 중단이 접수와 배정 지연으로 이어집니다.

기존 환경의 특성

클라우드 DR을 선택한 배경

전통적인 DR은 별도 DR 센터를 구축하고 장비를 이중화하는 방식입니다. 상면과 장비, 라이선스를 평상시에도 유지해야 하므로 초기 투자와 고정비가 발생하며, 이를 상시 운영하고 정기적으로 검증할 인력도 필요합니다. 이러한 온프레미스 DR 대비 AWS 상에서의 DR 환경 구축 시 기대되는 결과는 세 가지였습니다.

• 초기 인프라 투자 감소 – 온프레미스 DR은 복구용 대기 서버를 물리적으로 갖춰야 하지만, AWS DRS는 복구 인스턴스를 평상시 기동하지 않습니다.
• 복제 대상의 선택적 구성 – 온프레미스 복제는 디스크를 통째로 다루는 경우가 많습니다. AWS DRS에서는 로그 데이터나 백업 볼륨처럼 복구에 불필요한 영역을 파티션 단위로 제외할 수 있어 복제 비용을 줄일 수 있었습니다.
• 모의훈련 부담 감소 – 기존 방식의 DR 훈련은 대규모 인력 투입을 전제로 합니다. AWS DRS는 격리된 VPC에서 운영 서버에 영향 없이 복구 인스턴스를 기동할 수 있어 정기적인 검증이 가능합니다.

AWS에서는 RTO(목표 복구 시간)와 RPO(목표 복구 시점) 수준에 따라 백업 후 복원(Backup & Restore), 파일럿 라이트(Pilot Light), 웜 스탠바이(Warm Standby), 다중 사이트(Multi-site) 등 다양한 전략을 구현할 수 있습니다.

솔루션 개요

AWS DRS 동작 방식

AWS DRS는 온프레미스 또는 다른 클라우드 환경의 서버를 AWS로 실시간 복제하여, 장애 발생 시 신속하게 복구할 수 있도록 지원하는 AWS 네이티브 재해복구 서비스입니다.

[AWS DRS 구성 절차]

1. DRS Agent 설치 – 원본 서버에 에이전트를 설치합니다.
2. 지속적인 복제 – 원본 서버의 데이터를 블록 레벨로, 실시간에 가깝게 AWS로 복제합니다.
3. 복제 서버(Replication Server)와 스테이징 영역 – AWS 측에 저비용 복제 전용 영역을 구성합니다.
4. 복구 인스턴스(Recovery Instance) – 복구 시점에 Amazon EC2 인스턴스를 자동 생성합니다.
5. Failover – 장애 발생 시 복구 환경으로 서비스를 전환합니다.
6. Failback – 원본 환경의 이슈가 해소된 후 온프레미스로 복귀합니다.

아키텍처

다음 다이어그램은 웅진프리드라이프의 온프레미스 데이터센터에서 AWS DR 환경까지의 전체 구성을 나타냅니다.

복제 트래픽을 수신하는 스테이징 서브넷과 복구 인스턴스가 기동되는 복구 서브넷을 분리하여 구성했으며, 두 서브넷 모두 2개 가용 영역에 배치했습니다. 보안 그룹은 복제 수신용 인바운드 TCP 1500과 제어 평면 통신용 아웃바운드 TCP 443만 허용했고, DR 계정은 운영 계정과 분리하여 별도로 생성했습니다.

복제 데이터는 다음 경로를 따라 이동합니다. 원본 서버에 설치된 DRS 에이전트가 디스크의 블록 변경을 감지해 TCP 1500 포트로 복제 서버에 전송하면, 복제 서버는 이를 스테이징 영역의 EBS 볼륨에 기록합니다. 복구가 필요한 시점에는 해당 볼륨의 스냅샷을 기반으로 복구 인스턴스의 볼륨이 생성됩니다. 평상시 비용이 발생하는 구간은 복제 서버와 스테이징 볼륨뿐이며, 복구 인스턴스는 Drill이나 Failover를 실행할 때만 기동됩니다.

두 서브넷을 분리한 이유는 각 구간의 통신 요건이 서로 다르기 때문입니다. 스테이징 서브넷은 온프레미스로부터 복제 트래픽을 수신하는 역할만 수행하므로 인바운드를 복제 포트로 한정할 수 있습니다. 반면 복구 서브넷은 복구된 서버들이 서로 통신하고 필요에 따라 외부 연계를 수행하는 구간이므로 요구되는 정책이 다릅니다. 두 구간을 나누면 각각에 필요한 최소한의 규칙만 적용할 수 있습니다.

복구 인스턴스의 사양과 배치는 복구 시점에 결정하지 않고 사전에 정의해두었습니다. AWS DRS의 시작 설정(Launch settings)에서 서버별 인스턴스 타입, 배치할 서브넷, IP 할당 방식을 미리 지정해두면 복구 시점에 설정을 검토하는 과정 없이 바로 기동할 수 있습니다. 인스턴스 타입은 원본 서버의 사양을 기준으로 매핑했으며, 데이터베이스 서버와 애플리케이션 서버에 서로 다른 계열을 지정했습니다.

또한 AWS DRS는 복제된 데이터에 대해 일정 기간의 시점 복구 지점(Point-in-time)을 유지합니다. 장애 발생 직전 시점뿐 아니라 그 이전 시점을 선택해 복구할 수 있으므로, 데이터가 손상된 채로 복제된 경우에도 손상 이전 시점으로 되돌릴 수 있습니다.

보호 대상 현황

전체 복제 대상 용량은 초기 산정 기준 약 48TB였으며, 이 중 일부 서버는 최대 단일 볼륨 8TiB를 사용하는 등 대규모 데이터 복제가 필요한 구성이었습니다.

이렇듯 레거시 OS 세대, Windows 서버 중심의 Active Directory 종속성, 대규모 복제 용량이라는 세 가지 특성이 이후 검증 과정의 주요 변수가 되었습니다.

구축 과정과 주요 이슈

프로젝트에서 확인된 이슈는 복제 구성, 부팅 수행, 서비스 점검의 세 단계로 구분됩니다. 복제가 정상이어도 부팅이 완료되지 않는 경우가 있었고, 부팅이 완료되어도 서비스가 동작하지 않는 경우가 있었습니다. 이때 각 단계 별 발생 가능한 이슈와 그 문제 해결 과정을 짚어봅니다.

1단계: 복제 구성

복제 구성 단계에서는 원본 서버의 데이터가 AWS로 정상적으로 전송되는지를 확인합니다. AWS DRS는 에이전트 설치 직후 전체 디스크를 한 차례 복사하는 초기 동기화를 수행하고, 이후에는 변경된 블록만 지속적으로 전송합니다. 초기 동기화는 전체 용량을 한 번에 옮기는 작업이므로 회선과 복제 서버 양쪽에 평소보다 높은 부하가 발생하며, 이 구간에서 확인된 항목은 다음 두 가지였습니다.

초기 복제 대역폭 산정과 회선 증설

웅진프리드라이프의 데이터센터에서 운영 중인 디스크 총량이 약 48TB였는데, 기존 500Mbps 회선으로는 초기 백업 완료에만 최소 한 달 이상이 소요될 것으로 산정되었습니다. 해당 기간 동안 회선이 점유되면 운영 트래픽에 영향이 발생할 것으로 예상되어, 초기 복제 착수 전에 500Mbps에서 1Gbps로 회선을 증설했습니다.

복제 서버 스펙 선정

초기 백업 진행 중, 완료 예상 시간이 당초 산정치보다 크게 증가했습니다. 원인은 복제 서버의 인스턴스 타입과 EBS 처리량 설정 두 가지였습니다.

먼저 인스턴스 타입입니다. 초기에 t3 계열로 구성을 했는데, t3는 버스터블 인스턴스로 baseline을 초과하는 CPU 사용 시 크레딧을 소모합니다. 초기 복제는 수십 TB를 연속 처리하는 작업이므로 CPU 사용률이 장시간 높게 유지되고, 크레딧이 고갈되면 성능이 baseline 수준으로 제한됩니다.

다음은 EBS 처리량입니다. AWS DRS의 복제 서버는 원본 서버에서 전송된 데이터를 스테이징 영역의 EBS 볼륨에 기록합니다. 여러 서버의 복제가 동시에 진행되면 하나의 복제 서버가 다수의 볼륨에 동시에 쓰기를 수행하게 되므로, 볼륨 단위로 설정된 처리량과 인스턴스가 지원하는 EBS 대역폭이 함께 상한으로 작용합니다. 초기 구성에서는 이 상한이 전송량을 감당하지 못해 회선과 CPU에 여유가 있어도 쓰기 단계에서 대기가 발생했습니다. 두 원인은 서로 맞물려 있었는데, t3 계열은 CPU뿐 아니라 EBS 대역폭도 버스트 방식으로 제공되므로 고부하가 이어지는 초기 복제 구간에서는 양쪽 모두 baseline으로 떨어지기 때문입니다.

이에 대한 조치로 EBS 볼륨의 처리량을 상향하고 복제 서버 패밀리 타입을 t3에서 c6i로 변경했습니다. 이처럼 초기 복제는 지속적인 고부하 작업이므로 버스터블 계열은 적합하지 않습니다. 컴퓨팅 최적화 계열로 시작한 뒤 안정화 이후 사용량을 확인하며 하향하는 순서를 권장합니다.

2단계: 부팅 수행

복제가 정상적으로 유지되고 있다는 것은 원본 디스크의 블록이 AWS 측 볼륨에 동일하게 기록되어 있다는 의미입니다. 다만 이는 데이터가 도착했다는 사실을 확인해줄 뿐, 그 데이터로 서버가 기동되는지까지 보장하지는 않습니다. 실제로 Drill을 수행하면서 복제 상태는 정상(Healthy)이지만 복구 인스턴스가 부팅되지 않는 서버들이 확인되었습니다.

UEFI와 레거시 BIOS 부팅 모드 불일치

복구 인스턴스는 생성되지만 부팅이 완료되지 않는 Windows 서버가 있었습니다. 원인은 부팅 모드 불일치로, 복구 인스턴스는 UEFI 모드로 구성되어 있으나 원본 OS가 UEFI를 사용하도록 설정되어 있지 않았습니다.

원본 서버에서 명령 프롬프트를 열고 msinfo32를 실행하면 시스템 요약에서 BIOS 모드를 확인할 수 있습니다.

[UEFI 예시]

[Legacy 예시]

이때 결과가 UEFI가 아닌 레거시로 표시되는 경우 UEFI 모드로 설정을 변경해야 합니다.

# 유효성 검사
mbr2gpt /validate /disk:0 /allowFullOS
# 변환
mbr2gpt /convert /disk:0 /allowFullOS

mbr2gpt는 디스크의 파티션 구조를 MBR에서 GPT로 변환하는 명령입니다. 실행 전 백업을 확보해야 하고 변환 후 재부팅이 필요하므로, 운영 중인 서버에 적용할 때는 서비스 중단 시간을 함께 계획해야 합니다.

Linux grub 부트 경로 설정

Linux 서버에서도 부팅 실패가 확인되었습니다. grub.cfg의 root device가 디바이스 이름으로 고정 지정되어 있었기 때문입니다. AWS 환경에서는 디스크가 NVMe로 연결되면서 디바이스 이름이 원본과 달라지므로 지정된 경로를 찾지 못합니다.

[부팅이 완료되지 않는 상태]

[상세 콘솔 로그]

BOOT_IMAGE=/vmlinuz-2.6.32-754.35.1.el6.x86_64 root=/dev/nvme1n1p4 console=ttyS0 rd_NO_LVMCONF rd.lvm.conf=0 ... snap.check: [NOTICE] Attach request for device /dev/xvda2(alt name (null) parent /dev/xvda)
blksnap.check: [NOTICE] Attach request for device /dev/xvda3(alt name (null) parent /dev/xvda) 
blksnap.check: [NOTICE] Attach request for device /dev/xvda4(alt name (null) parent /dev/xvda) 
blksnap.check: [NOTICE] Attach request for device /dev/xvda1(alt name (null) parent /dev/xvda)

디바이스 이름은 디스크가 연결된 방식과 인식 순서에 따라 결정되므로 환경이 바뀌면 함께 바뀔 수 있습니다. 반면 UUID는 파일 시스템을 생성할 때 부여되어 볼륨을 복제해도 그대로 유지되므로, 환경이 달라져도 동일한 값으로 참조할 수 있습니다.

이때 디바이스 이름 대신 UUID를 사용하도록 변경하여 해결했습니다.

# 1. UUID 확인
$ sudo blkid
 
# 2. grub.cfg 파일 변경
# /etc/default/grub과 /boot/grub2/grub.cfg 파일에서 root=/dev/nvme1n1p4의 형식을 하기와 같이 변경
# 작업 전
root=/dev/nvme1n1p4 # 예시 naming
# 작업 후
root=UUID= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

NTFS 권한 및 로컬 보안 정책에 의한 볼륨 접근 제한

3대의 서버에서 부팅과 로그인은 정상이었으나 특정 드라이브(C: 또는 D:)에 접근할 수 없었습니다.

원인은 두 가지였습니다. 로컬 보안 정책이 드라이브 접근을 차단하고 있었고, NTFS 권한상 복구 인스턴스의 계정이 해당 볼륨의 소유자가 아니었습니다. 원본 서버에 설정된 접근 제어가 복구 환경에도 그대로 적용되었기 때문입니다.

조치 방법은 다음과 같습니다.

• 로컬 보안 정책 – 사용자 구성 > 관리 템플릿 > Windows 구성 요소 > 파일 탐색기의 ‘내 컴퓨터의 드라이브 액세스 제한’ 정책 해제
• NTFS 권한 – 대상 드라이브 속성의 보안 탭에서 소유자를 Administrator 또는 로그인 계정으로 지정

다만 두 항목 모두 원본 운영 서버의 설정 변경이 필요하고 적용에 재기동이 수반됩니다. 24시간 운영 환경에서 DR 검증을 위해 운영 서버를 중단하는 것은 우선순위가 맞지 않다고 판단하여, 현재는 위 절차를 복구 계획서에 명시해두고 적용 시점을 조율하고 있습니다.

3단계: 서비스 점검

서비스 점검 단계에서는 기동된 서버가 실제로 업무를 수행할 수 있는 상태인지 확인합니다. 운영체제가 올라오는 것과 그 위에서 애플리케이션이 동작하는 것은 별개이며, 인증 경로와 외부 연계까지 이어져야 서비스가 성립합니다. 이 구간에서는 서버가 정상 기동되었음에도 서비스가 동작하지 않는 경우가 확인되었습니다.

Active Directory 종속성과 복구 목표 재정의

도메인 컨트롤러와 파일 서버의 경우, 복구 인스턴스 접근 시도 시 부팅은 완료되어 로그인 화면까지는 조회가 되었으나, AD join 오류로 인해 연결이 되지 않았습니다.

이 시점에서 두 서버의 복구 목표를 재검토했습니다. 원인을 규명하여 완전한 부팅 복구 대상으로 전환하는 대신, 복구 목표를 데이터 확보로 재정의했습니다. 디스크 복제는 유지하되, 복구가 필요한 시점에는 복제된 볼륨을 정상 동작하는 다른 서버에 연결하여 데이터를 확보하는 방식입니다.

판단 근거는 두 가지였습니다. 첫째, Windows 도메인 환경의 복구는 개별 서버 단위가 아닌 도메인 전체의 인증 구조 문제입니다. 격리된 DR 네트워크에서 도메인 인증 경로를 재현하려면 도메인 컨트롤러와 멤버 서버의 복구 순서, DR 네트워크에서의 DNS 구성, 서버 간 시간 동기화까지 함께 설계해야 합니다. 개별 서버의 복제 상태와는 별개의 작업입니다. 둘째, 해당 서버들이 보유한 핵심 자산은 파일 형태로 저장된 고객 정보와 계약서 데이터로, 서버의 기동보다 데이터 접근이 우선순위였습니다.

Failover 소요 시간과 OS 업데이트

Failover 테스트 결과 서비스 사용 가능 상태에 도달하기까지 최소 30분이 소요되었으며, 3시간 가까이 소요된 서버도 있었습니다.

원인은 누적된 Windows 업데이트였습니다. 데이터센터 운영 특성상 장기간 서버를 shutdown하지 않아 적용 대기 중인 업데이트가 축적되어 있었고, Failover로 복구 인스턴스가 처음 부팅되는 시점에 해당 업데이트가 일괄 적용되면서 3시간 가까이 업데이트가 수행되었습니다.

인스턴스 생성 자체는 수 분 내에 완료됩니다. 소요 시간의 대부분은 OS 부팅 및 서비스 기동 단계에서 발생합니다. RTO의 기준은 인스턴스 시작 시간이 아니라 OS 부팅 완료 및 서비스 기동 완료 시점이기 때문에, 서비스 복구 계획 수립 시 원본 서버의 패치 상태 관리 역시 고려가 되어야 합니다.

복제 상태 감시

복제 작업은 한 번 구성하면 끝나는 작업이 아니라 상태를 지속적으로 확인해야 하는 대상입니다. 때문에 초기 동기화 구간과 지속 복제 구간에서 각각 무엇을 확인해야 하는지, 지연이나 중단이 발생했을 때 어떻게 감지하고 대응하는 지 등 포괄적인 모니터링 환경 구성이 필수입니다.

초기 동기화 구간

초기 동기화 진행 상황은 AWS DRS 콘솔의 소스 서버 목록에서 확인했습니다. 동기화가 진행 중인 서버는 진행률과 남은 예상 시간이 함께 표시되고, 완료된 서버는 Healthy 상태로 전환됩니다.

AWS DRS 콘솔의 소스 서버 목록 — 서버별 복제 상태와 초기 동기화 진행률

화면에서 볼 수 있듯 서버마다 복제 진행 속도의 편차가 있습니다. 앞서 다룬 복제 서버의 CPU 크레딧 고갈 및 디스크 대역폭 이슈 역시 이 잔여 시간을 일정 시간 모니터링함으로써 조기에 원인 분석을 시작할 수 있었습니다. 때문에 시간에 따른 진행률 및 잔여 시간의 변화를 함께 보면 복제 성능 저하를 조기에 판단할 수 있습니다.

지속 복제 구간

초기 동기화가 끝나면 변경된 블록만 전송하는 지속 복제 상태로 전환됩니다. 이 구간에서 주의해야 할 것은 복제가 완전히 멈추는 상황보다, 복제는 계속되지만 원본의 변경 속도를 따라가지 못해 지연이 쌓이는 상황입니다. 지연이 길어질수록 복구할 수 있는 시점이 과거 시점으로 밀리기 때문입니다.

콘솔을 상시 확인할 수는 없으므로, AWS DRS가 AWS/DRS 네임스페이스로 제공하는 지표에 Amazon CloudWatch 알람을 설정해 임계값 초과 시 통보받도록 구성했습니다.

CloudWatch 알람 구성 — 지표별 임계값과 조치 안내

LagDuration은 결과에 해당하는 지표로 목표 RPO 위반 위험을 직접 알려주고, Backlog는 원인에 가까운 지표로 지연이 커지기 전 사전 경고성 정보를 알려줍니다. 그래서 Backlog는 경고, LagDuration은 비상으로 등급을 나누어 대응 우선순위를 구분했습니다.

알람 설명에는 지표 값과 함께 무엇을 점검해야 하는지를 적어두었습니다. LagDuration 알람에는 사내 회선과 원본 서버의 에이전트 상태를, Backlog 알람에는 온프레미스 디스크 I/O 급증 여부와 아웃바운드 대역폭 포화 여부를 확인하도록 안내를 넣었습니다. 알람을 받은 담당자가 지표 이름만 보고 원인 분석을 시작하지 않고, 설명에 기재된 추가 지침을 참고하도록 하기 위해서입니다.

운영 체계

개별 알람과 별개로, 21대의 복제 상태를 한 화면에서 확인할 수 있도록 CloudWatch 대시보드를 구성했습니다.

CloudWatch 대시보드 — 보호 대상 서버 현황과 복제 지표 추이

상단에는 전체 등록 서버 수, 정상 보호 중인 서버 수, 복제 활성 서버 수를 배치했습니다. 하단에는 서버별 LagDuration과 Backlog 지표를 추가하여 각 서버의 복제 상태를 실시간으로 확인할 수 있도록 구성하였습니다. 알람이 특정 시점의 임계값 초과를 알려준다면, 대시보드는 평소 임계값에 얼마나 근접해 있는 지와 특정 서버에서 반복되는 패턴인 지를 보여줍니다. 알람이 울리지 않더라도 추세가 올라가고 있다면 사전에 점검할 수도 있습니다.

프로젝트 성과

금번 프로젝트를 통해 웅진프리드라이프는 AWS DRS를 통해 총 21대 서버에 대해 성공적으로 DR 환경 구축을 완료하였습니다.

구축 결과 요약

복구 소요 시간

DR 환경 구축 완료 후 Drill 수행 시 확인된 실제 소요 시간은 다음과 같았습니다.

두 방식의 소요 시간이 구분되므로, 서버별 복구 목표에 따라 복구 순서와 방식을 설계할 수 있습니다. 서비스 전체를 기동해야 하는 서버와 데이터 확보만으로 충분한 서버를 나누어 접근하면, 제한된 시간 안에서 우선순위가 높은 시스템부터 복구할 수 있습니다. 이 측정값은 복구 계획서에 기준 시간으로 반영했으며, 정기 Drill을 통해 갱신할 예정입니다.

DR 구축 시의 비용 최적화

금번 프로젝트에서는 DR 환경으로 인한 운영 비용 최적화를 위해 복제 인스턴스 타입을 하향(c6i.xlarge → c6i.large)하여 복제 서버 비용을 약 50% 절감했습니다. 초기 복제 구간에는 컴퓨팅 성능이 필요했으나, 지속 복제 단계로 전환된 이후에는 부하가 크게 낮아지기 때문입니다.

또한 Standby 서버, 백업 볼륨, 미사용 서버를 복제 대상에서 제외하여 복제 볼륨 총량을 약 8% 축소했습니다. 총 복제 볼륨이 감소하여 비용도 함께 감소하였습니다.

이외에도 추가적으로 약정(Savings Plans / Reserved Instance) 적용을 검토하며 추가 비용 최적화 안을 검토 중에 있습니다. 마이그레이션 과정에서 미사용 서버 폐기와 복제 범위 조정이 함께 이루어져, 구성이 안정화된 이후 적용하는 것이 적절하다고 판단했습니다.

운영 측면의 성과

정량적인 성과 외에도 두 가지 변화가 있었습니다.

첫째, 복구 절차가 문서로 확보되었습니다. 서버별 복구 목표와 우선순위, 인스턴스 타입 매핑, 검증 절차, 확인된 제약과 대응 방법이 복구 계획서에 정리되어 있습니다.

둘째, DR 구축이 마이그레이션의 사전 점검 역할을 했습니다. 부팅 모드 불일치, 부트 경로 지정 방식, 볼륨 접근 제어 설정, 누적된 OS 업데이트 이 목록은 재해복구 이슈인 동시에 마이그레이션 선결 과제였습니다. AWS DRS 환경 구축 후 Drill 수행을 통해 이관 이전 시점에 확인할 수 있었습니다.

셋째, 정기적인 복구 검증이 가능해졌습니다. 기존 방식의 DR 훈련은 운영 중단을 감수하거나 별도 인력을 투입해야 했지만, 격리된 VPC에서 복구 인스턴스를 기동하는 방식은 운영 서비스에 영향을 주지 않습니다. 이에 따라 반기 1회 주기의 정례 검증을 협의하고 있습니다.

향후 계획

정기 Drill은 반기 1회 주기로 협의하고 있으며, 훈련 결과를 복구 계획서에 반영해 현행화하는 작업을 함께 진행 중에 있습니다. 인프라 구성이 변경되면 복구 가능 여부도 달라지므로, 검증을 일회성 작업이 아닌 주기적인 절차로 두는 것을 목표로 하고 있습니다.

온프레미스로 되돌리는 Failback 절차는 마이그레이션 완료 이후에 검증하고 정책화할 예정입니다. 백업 체계 측면에서는 AWS Backup과 Amazon GuardDuty Malware Protection을 활용해 백업 데이터 자체를 보호하는 불변 백업 체계 구성을 검토하고 있습니다.

비용 측면에서는 복제 서버에 대한 약정 적용과 복제 볼륨 범위의 추가 조정을 진행 중입니다. 마이그레이션 과정에서 미사용 서버 정리가 함께 이루어지고 있어, 구성이 안정화되는 시점에 맞춰 적용할 계획입니다.

단계별 점검 항목

이번 프로젝트에서 확인된 항목을 단계별로 정리하면 다음과 같습니다. 설계 단계에서 미리 점검하면 검증 단계의 재작업을 줄일 수 있습니다.

마치며

이번 프로젝트를 통해 확인한 내용을 세 가지로 정리하면 다음과 같습니다.

첫째, 재해복구 준비는 복제·부팅·서비스 세 단계의 검증으로 구성됩니다. 복제 진행 후 데이터가 정상적으로 동기화가 완료되었는 지, 해당 데이터로 서버가 기동되는 지, 기동된 서버가 정상적으로 서비스가 가능한 지는 각각 별도로 확인이 필요합니다. AWS DRS의 경우 이 과정에서 Drill 기능을 활용할 수 있습니다.

둘째, 레거시 환경의 DR 구축은 클라우드 측 작업 외에도 온프레미스 측 정비의 비중이 높습니다. 부팅 모드, 부트 경로, 볼륨 접근 제어, 패치 상태 등 실제 DR 상황을 시뮬레이션하며 면밀히 조치가 필요한 지점이 다수 발견되었습니다.

셋째, 모든 서버가 동일한 방식으로 복구되어야 하는 것은 아닙니다. 서버별로 복구 시 확보해야 하는 대상을 정의하면, 부팅 복구가 아닌 데이터 복구가 적합한 경우를 구분할 수 있습니다. 이렇게 정리한 서버별 복구 목표 역시 DR 설계의 산출물 중 하나가 될 수 있습니다.

이번 사례에서 다룬 서비스에 대한 자세한 내용은 AWS Elastic Disaster Recovery 문서에서 확인하실 수 있습니다. 레거시 서버 중심의 온프레미스 환경에서 재해복구 체계 구축이나 클라우드 이관을 검토하고 계시다면, 이 글의 단계별 점검 항목이 참고가 되기를 바랍니다.