AWS DRS서비스를 활용한 DR(Disaster Recovery) 전략 수립 및 적용
이번 글에서는 AWS의 대표적인 DR(Disaster Recovery) 서비스인 DRS(Elastic Disaster Recovery)를 통한 전략을 수립하고 적용하는 방법에 대해 소개를 해드리려고 합니다.
본 글은 AWS를 이제 막 시작하신 L100(기초) 레벨의 단계는 다소 어렵게 느껴질수 있습니다만, 재해 복구 전략이 무엇인지 기초 개념을 정립한다는 관점에서는 어느정도 도움이 될것으로 생각합니다. 하지만, 대부분의 내용은 L200(중급)정도의 지식을 가지신 분들을 기준으로 작성 되었다는 점 참고 부탁드립니다.
1. 본 글을 이해하기 위해 사전지식
소개에 앞서 AWS DRS 서비스의 주 목적인 DR(Disaster Recovery)이라는 것이 무엇인지 기초적인 내용들을 알아야 합니다. 때문에, 먼저 주요 개념들과 특징들에 대해서 간략히 정리하도록 하겠습니다.
1-1. 재해 복구(Disaster Recovery)란?
재해 복구는 중단된 이벤트를 준비 및 복구하는 프로세스를 뜻합니다. 중단된 이벤트의 범위 또한 광범위한 개념을 가지기도 하는데요. 현재 사용중인 Application 또는 Infra 등 이벤트에 관련된 리소스를 수초 또는 수분 내로 서비스를 복구하는 것을 뜻합니다.
1-2. 재해(Disaster)와 재해의 네 가지 주요 범주
재해(Disaster)란, 아래 하나 이상의 이유로 애플리케이션 운영을 부분적으로 또는 완전히 중단시키는 이벤트를 뜻합니다.
- 인적 오류 : 사람의 실수에 의해 발생한 재해
- 소프트웨어 또는 데이터베이스의 부주의한 구성 오류와 같이 보안 침해로 이어지는 의도하지 않은 작업
- 관리자 또는 작업자의 실수로 인해 발생하는 작업 또는 이벤트 - 악의적인 공격 : 외부 세력에 의해 발생한 재해
- 서비스 거부(DoS) 또는 랜섬웨어 공격과 같이 피해자의 시스템에 영향을 미치는 무단 행위
- 공격자로부터 서비스에 문제가 생기도록 의도하는 행위 - 자연 재해 : 자연적인 문제에 의해 발생한 재해
- 지진, 홍수 등 자연에 의해 시스템 장애를 일으키는 환경적으로 발생하는 요인 - 기술적 오류 : 리소스를 운영하는 시설 또는 자원에 의해 발생한 재해
- 정전, 네트워크 연결 오류 등 소프트웨어, 하드웨어 또는 시설의 오작동
1-3. 특정 재해에 대한 대응을 계획할 경우, 고려해야 할 몇 가지 요소
- 재해 예상 기간
- Application이 얼마나 빨리 복구 되며 재해가 자체적으로 해결될 가능성은 얼마나 되는지 - 충격 크기(폭발 반경이라고도 함)
- 어떤 응용 프로그램이 영향을 받으며 해당 프로그램 기능이 얼마나 손상 되는지
- 문제가 발생했을 경우, 얼마나 큰 Application 영향도가 생기는지 - 지리적 영향
- 지역, 국가, 대륙 또는 글로벌 규모와 같이 얼마나 큰 지리적 영향이 생기는지 - 가동 중지 시간 허용
- Application이 작동하지 않는 경우의 영향은 얼마나 중요한지
- 서비스가 되지 않을 때의 시간은 얼마나 가능한지
1-4. 복구 목표 설정
재해 복구 설정은 계획의 일환으로 영향 분석 및 위험 평가를 기반으로 각 Application에 대한 RTO 및 RPO를 정의해야 합니다.
- RTO(Recovery Time Objective) : 목표 복구 시간, 애플리케이션 중단과 서비스 복원 사이에 허용되는 최대 지연입니다. 이 목표는 애플리케이션을 사용할 수 없는 허용 가능한 기간을 결정합니다.
- RPO(Recovery Point Objective) : 목표 복구 시점, 재해 복구 사이트의 데이터와 재해 발생 시 애플리케이션에 저장된 최신 데이터 간에 허용 가능한 최대 차이입니다. 이 목표는 재해로 인해 발생할 수 있는 데이터 중단/손실에 허용되는 최대 시간을 결정합니다.
1-5. 일반적 또는 표준 복구 목표 시간
각 애플리케이션의 RTO 및 RPO는 다양한 요소(예: 서비스 수준 계약(SLA) 및 외부 규정 준수요구 사항)에 따라 달라지지만 몇 가지 공통 표준이 존재합니다.
- 미션 크리티컬 애플리케이션(계층 1 애플리케이션)의 경우, 일반적으로 RTO는 15분, RPO는 거의 0(near-zero)
- 미션 크리티컬하지 않은 중요한 애플리케이션(계층 2 애플리케이션)의 경우,일반적으로 RTO는 4시간, RPO는 2시간
- 다른 모든 애플리케이션(계층 3 애플리케이션)의 경우, 일반적으로 RTO는 8~24시간, RPO는 4시간
1-6. 재해 복구 전략
재해 복구 전략은 대표적으로 3가지 정도의 종류가 존재하는데요. 각 재해 복구 전략에 따라 RTO/RPO 시간의 상당한 차이와 비용의 차이가 발생합니다. 관련하여 아래 각 특징에 대해서 작성해보았는데요. 각 복구 전략은 사용자가 어떠한 것이 중요한지에 대해 다르게 선택되게 됩니다. 예를들어 비용, RTO/RPO, 무중단 등이 예가 되겠습니다.
1) 파일럿 라이트 (Pilot Light)
- 개념: 핵심 데이터는 DR 리전에 동기화하고, 인프라의 최소 핵심 부분만 가동 상태로 유지하다가 재해 시 전체 인프라를 신속하게 활성화하는 방식입니다.
- 최대 장점: 비용 효율성 (웜/핫 스탠바이 대비 저렴)
- 최대 단점: 상대적으로 긴 복구 시간 (웜/핫 스탠바이 대비)
2) 웜 스탠바이 (Warm Standby)
- 개념: DR 리전에 운영 환경의 축소된 버전을 항상 가동 상태로 유지하고, 재해 시 전체 규모로 신속하게 확장하는 방식입니다.
- 최대 장점: 빠른 복구 시간과 비용 효율성 간의 균형
- 최대 단점: 파일럿 라이트보다는 비용이 높고, 핫 스탠바이보다는 복구 시간이 더 소요될 수 있음
3) 핫 스탠바이 (Hot Standby / Multi-Site Active-Active)
- 개념: DR 리전에 운영 환경과 거의 동일하거나 완전 동일한 시스템을 항상 완벽하게 가동 상태로 유지하여 재해 시 거의 즉시 전환하는 방식입니다.
- 최대 장점: 가장 빠른 복구 시간 (거의 무중단 서비스 가능)
- 최대 단점: 가장 높은 구축 및 운영 비용과 복잡성
2. AWS DRS(Elastic Disaster Recovery) 개요
물론 AWS DRS 서비스가 아니더라도 제외하더라도 다양한 재해 복구 솔루션이나 도구들이 존재합니다. 하지만 AWS DRS를 선택한 이유는 AWS를 사용하고 있는 상황에서는 AWS Native 서비스를 활용했을때 다른 재해 복구 도구 보다 “AWS 환경에 대한 통합이 편리”하고 또한 “현재 복제 진행상황을 AWS DRS UI를 통해 가시성 있게 확인이 가능하며 단순하게 버튼 하나만으로 손쉽게 서비스 Recovery가 가능”하다는 점 때문에 선택을 하게 되었습니다.
2-1. AWS DRS(Elastic Disaster Recovery)란?
AWS 공식 문서에 의하면 AWS Elastic Disaster Recovery(AWS DRS)는 저렴한 스토리지, 최소한의 컴퓨팅 및 특정 시점 복구를 사용하여 온프레미스 및 클라우드 기반 애플리케이션을 빠르고 안정적으로 복구하여 가동 중지 시간과 데이터 손실을 최소화하는 서비스입니다.
애플리케이션을 복구해야 하는 경우 최신 서버 상태 또는 이전 시점을 사용하여 몇 분 내에 AWS에서 복구 인스턴스를 시작할 수 있습니다.
2-2. AWS DRS(Elastic Disaster Recovery) 특징
1) Elastic Disaster Recovery의 RTO 및 RPO 시간
- RTO(복구 시간 목표) : 일반적으로 분 단위로 복구가 가능합니다. 하지만 결론적으로 서비스가 동작하기 위한 OS 부팅 시간에 따라 크게 시간이 달라질 수 있습니다.
- RPO(복구 시점 목표) : 일반적으로 복구 시점 목표의 경우, 1초 미만 범위에 있습니다.
2) Elastic Disaster Recovery의 지원하는 인프라
AWS DRS에서는 다양한 인프라 환경에 대해 DR 작업을 수행할 수 있습니다.
- 물리적(Physical) 인프라
- VMware (VMware vSphere, 온프레미스 및 VMware on AWS 모두)
- Microsoft (Hyper-V, Microsoft Azure)
- Hypervisor On VM
- Other Cloud Infra
3) Elastic Disaster Recovery의 지원하는 환경 및 요구사항
AWS DRS가 다양한 환경들을 지원하지만 모든 가상화 종류와 운영체제를 지원하지는 않습니다. 그러므로 AWS 복제 에이전트 (Replication Agent) 설치를 위한 요구사항 확인이 필요합니다. (자세한 내용은 아래 공식 문서를 참고 하시기 바랍니다.)
참고 문서 : https://docs.aws.amazon.com/ko_kr/drs/latest/userguide/installation-requirements.html
3. AWS DRS(Elastic Disaster Recovery) 재해 복구 전략
3-1. DR 아키텍처 구성도
- 그림[1]
본 DR 소개에서 사용하게 될 아키텍처는 위 그림[1]과 같이 구성하도록 하겠습니다. 아키텍처 시나리오의 흐름은 아래와 같습니다.
- 재해 상황이 발생할 경우, 복구를 시도할 IDC의 물리적 서버에 AWS Replication Agent를 설치하여 지속적으로 실시간 데이터 복제(Replication) 및 동기화(Sync)를 수행합니다.
- AWS Replication Agent와 AWS DRS Endpoint가 지속적으로 상태를 주고받으며 재해 상황 발생할 경우, 즉시 복구 할 수 있도록 대기를 합니다.
- AWS Recovery Server는 AWS Replication Agent에서 복제 및 동기화를 한 데이터를 지속적으로 EBS에 저장합니다.
- 재해 상황이 발생하여 복구가 수행될 경우, AWS Replication Server에서 복제 된 EBS를 활용하여 Recovery Instance를 즉시 생성 후 서비스 복구를 수행합니다.
3-2. DR 환경 정보
DR 환경 구성 및 재해복구를 수행하기 위한 환경 정보는 아래와 같습니다. 일반적으로 VPN으로 연결된 Private 환경에서 데이터 복제 및 동기화가 수행이 되므로 아래와 같이 구성되었습니다. 또한 비용을 가장 고려하여 위 재해 복구 전략에서 소개드린 “Pilot Light” 전략을 선택하였습니다.
1) AWS 환경 정보
- Network : AWS S2S VPN (Private Network)
- Recovery Region : 서울 (ap-northeast-2a, 2c)
2) IDC 환경 정보
- Network : IDC VPN (Private Network)
- Source Region : 서울
- Source OS : Windows Server
3-3. AWS 사전 필수 준비사항
AWS Cloud에서도 DR 구성을 위해 미리 사전에 준비해야할 리소스 또는 자원들이 있습니다. 즉, AWS로 재해 복구를 하기 위한 사전 환경이 미리 필요하다는 뜻입니다. 설정에 필요한 요구상이 많기 때문에 DRS 서비스 사용에 필요한 사전 준비가 필요합니다. (자세한 내용은 아래 공식 문서를 참고해주세요.)
참고 문서 :
- https://docs.aws.amazon.com/ko_kr/drs/latest/userguide/Network-diagrams.html
- https://docs.aws.amazon.com/ko_kr/drs/latest/userguide/Network-Settings-Preparations.html
- https://docs.aws.amazon.com/ko_kr/drs/latest/userguide/Network-Requirements.html
사전에 구성해야할 요소들이 조금 많다보니 본 글에서 다 다루지는 않겠지만 주로 잘 봐야하는 네트워크 구간에 대해서만 좀 소개를 드리겠습니다.
- Security Group : IDC와 AWS 사이에 통신을 하기 위해서는 TCP 443, 1500 Port를 필수적으로 사용하게 됩니다. 이 부분이 완료되지 않으면 정상적인 복제가 되지않으니 잘 확인이 필요합니다.
- Endpoint Service : Network를 Private 하게 구성을 하다보니 Recovery EC2와 Replication Agent에서 통신이 필요한 S3, EC2, DRS Endpoint 설정이 필요합니다.
3-4. AWS DRS 환경 구성
환경 구성은 Windows Server를 위한 DRS Agent 설치 과정에 사용되는 명령어들 입니다. 아래 명령어를 순차적으로 진행하되, 복구 전략 대상 Source Server에 특정 Disk만 복제를 한다거나 Endpoint를 지정하는 Replication Agent Install Parameter 부분을 확인 후 쓰시는게 좋습니다.
참고 문서 :
- https://docs.aws.amazon.com/ko_kr/drs/latest/userguide/installer-parameters.html
앞서 말씀드렸던 Windows Server를 활용한 환경이므로 아래 명령어들을 통해 순차적으로 AWS Replication Agent를 설치합니다. (DRS에서 지원하는 운영체제 확인이 필요합니다.)
1) Windows 전용 Replication Agent 프로그램 다운로드 (관리자 권한 필요)
curl -o AwsReplicationWindowsInstaller.exe https://aws-elastic-disaster-recovery-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe2) Replication Agent Installer 프로그램 실행 (관리자 권한 필요)
.\AwsReplicationWindowsInstaller.exe --region ap-northeast-2 --aws-access-key-id <Access Key> --aws-secret-access-key <Secret Key> --region ap-northeast-2 --endpoint <DRS Endpoint URL> --s3-endpoint <S3 Endpoint URL>
4. AWS DRS 구성 결과
4-1. 복제 연결 성공 및 완료
- 그림[2] : Replication Agent 설치 성공
- 그림[3] : Source Server Replication 100% 완료
그림에 보이는 “Ready” 상태는 현재 지속적으로 복제가 되고 있는 정상적인 상태를 뜻합니다. 그리고 Recovery Instance를 띄우기 위한 준비가 완료 되어 언제든 복구가 가능하다는 뜻이기도 합니다. 위 그림[3]의 “Healthy”의 “Replication progress”는 복제 완료가 100% 되어 있고 현재 복제된 데이터는 2.15TiB 중 2.15TiB가 된 것 입니다.
- 그림[4] : Source Server와의 통신 및 연결이 끊긴 상태
현재 그림[3]과는 다르게 “Ready for recovery” 부분에 “Ready | lag 3 hours” 라고 확인이 되는데요. Lag는 쉽게 말해, 현재 복제 데이터가 실제 소스 서버의 최신 데이터와 얼마나 차이(지연)가 있는지, 즉 "몇 분/몇 시간 전 상태까지 복제되어 있는가"를 나타냅니다.
즉, 위 그림은 지금 복구 인스턴스를 띄우면 3시간 전 상태로 복구된다는 뜻입니다.
Lag 상태가 발생하는 경우는 아래와 같이 다양한 이유가 있기 때문에 자세한 것은 Source Server에 대한 분석이 필요합니다.
- 네트워크 대역폭 부족, 일시적인 네트워크 장애
- 소스 서버에서 데이터 변경(쓰기)량이 급증하여 복제 속도를 따라가지 못할 때
- 소스 서버의 디스크 I/O가 느리거나, 서버 자원이 부족할 때
- 복제 에이전트의 일시적 문제, 또는 서버 재시작 등으로 CDP 모드에서 벗어난 경우
- 그림[5] : Replication 된 데이터를 Recovery(복구) Instance 생성 완료 Log
그림에 보이는 Details의 Type에서 “Recovery” 관련된 Log라는 것을 확인할 수 있습니다. 또한 상태도 Completed와 함께 “Start / Completed time”을 통해 어떠한 시점에 시작되고 완료가 되었는지 확인이 가능합니다. 이후 “Job log”를 통해 “성공/에러”에 대한 Log를 확인할 수 있었습니다.
5. 마치며
이상 AWS DRS 서비스를 활용하여 실시간 데이터 복제 및 동기화를 실제 업무에서 진행헀던 사례를 기반으로 설명했습니다.. DR 구성을 하기 위해서 사전에 준비해야할 것들이 많았지만 구성을 한번 해놓는다면 UI를 통해 손쉽고 버튼 몇 개로 서비스 복구를 신속하게 할 수 있다는 것과 실시간 데이터 복제가 안정적으로 이뤄진다는 것을 알 수 있습니다.
또한 AWS DRS를 구성하며 향후 개선사항 및 고도화 할 만한 것들을 생각해 보았는데요.
- 사전에 필요한 DRS 필수 자원을 Terraform 또는 CloudFormation을 통한 프로비저닝 환경 고도화
- 내부적으로 재해 상황에 대한 기준을 잡았다면 해당 기준을 근거로 Lambda를 트리거 하여 활용해
Recovery(복구) 작업 자동화 수행 - Job Log에 출력되는 이벤트에 따른 Slack 또는 사내 메신저 Webhook 자동화
위 방법들을 향후에 고려하고 적용을 해본다면 보다 더 안정적이고 AWS Native한 DR 구성을 만들 수 있을 것 같습니다.
긴글 읽어 주셔서 감사합니다.