AWS 환경의 재해 복구 계획(DR)에 대해
안녕하세요 클래스메소드의 수재입니다.
이번에 잠깐 재해 복구 계획(이하 DR)1에 대해서 조사할 일이 있었습니다.
조사한 내용과 AWS가 작성한 아래의 시리즈를 바탕으로 정리해보려합니다.
AWS의 백서도 많은 도움이 되었습니다.
재해 복구 계획(DR) 이란?
재난 복구 계획(災害復舊, 영어: disaster recovery plan, DRP)는 자연재해나 인위적인 재해가 일어나면 특정 단체에 중요한 기술 인프라를 복구하거나 지속할 목적으로 준비하는 데 대한 과정, 정책, 절차를 가리킨다. 시설의 하드웨어나 소프트웨어상의 재해나 재난 발생에 대비하여, 실제 상황이 발생했을 때 취해야 할 행동 계획을 미리 준비하는 것이다. 재해 복구는 업무 연속성 계획(BCP)의 하부 분야이기도 하다. - 위키백과
정리하자면 자연재해나 화재 등의 인위적인 재해가 일어났을 때 운영 중인 서비스에 끼치는 영향을 최소화하기 위해 지속적인 복제 및 다른 지역에서의 복구 등을 계획하는 작업을 말합니다.
이러한 DR이 준비되어 있지 않으면 위급 상황 발생 시에 서비스가 제대로 운영되지 못하여 서비스에 대한 심각한 신뢰도 손상이 발생하기 때문에 올바른 운영을 위해서는 꼭 계획을 수립하고 실행하여야 합니다.
또한 DR을 수립하기 위해서는 비즈니스 전체의 영향을 분석할 필요가 있기 때문에 아무런 분석 없이 BCP의 준비 없이 DR만을 단독으로 수립한다면 큰 개선 효과는 얻을 수 없게 됩니다.
재해 복구 계획과 고가용성
고가용성(High Availability)와 재난 복구 계획은 다른 개념입니다.
고가용성은 서비스의 중단을 방지(혹은 최소화 된 중단을 유지)하여 지속적인 운영을 보장하는 개념입니다. 이러한 고가용성을 확보하기 위해 전체적인 워크로드의 각 구성 요소를 조작하거나 설정하게 됩니다.
재해 복구 계획은 서비스 운영에 영향을 미치는 자연 재해 등과 같은 큰 이벤트에 대하여 워크로드 전체를 복원하는 개념입니다.
고가용성을 확보하면서 재해 복구 계획까지 준비한다면 신뢰도가 높은 서비스를 제공할 수 있게 됩니다.
재해 복구 계획의 수립
DR 을 수립하기 위해서는 우선 RTO(복구 시간 목표)와 RPO(복구 지점 목표)를 정의할 필요가 있습니다.
RTO는 재해가 발생한 후 정상 성능으로 서비스가 되돌아오기까지 걸리는 시간입니다. 예로 들면 RTO가 3시간인 경우 재난 발생 직후부터 복구 까지 3시간이 걸린다는 뜻입니다.
RPO는 재해 발생 시점부터 복구할 수 있는 가장 최근의 시간을 얘기합니다. 예로 들면 RPO가 1시간인 경우 복구할 수 있는 데이터가 재난 발생 시점부터 1시간 전이라는 뜻입니다.
높은 수준의 RTO와 RPO를 보장하기 위해서는 많은 비용이 요구됩니다.
따라서 워크로드의 요구 수준을 정확히 파악하고 사용할 수 있는 예산 안에서 효율적인 RTO와 RPO를 수립할 필요가 있습니다.
AWS의 백서를 보시면 예산에 따른 적절한 RTO와 RPO를 수립하는 방법이 간략하게 기재되어 있습니다.
- Business Continuity Plan (BCP) 이 외에도 백업 시스템으로 자동으로 넘기는 재해 복구 프로세스인 페일 오버(failover)나 복구한 시스템을 원래 상태로 되돌리는 페일백(failback) 등도 정의할 필요가 있습니다.
페일백은 원래 시스템으로 돌아가는 재해 복구 프로세스입니다. 재해가 지나가고 기본 데이터 센터가 다시 작동되면 원활하게 페일백할 수 있을 것입니다.
AWS와 재해 복구 계획
온프레미스 환경에서는 물리적인 제약으로 인해 많은 비용이 발생하였지만 클라우드 환경을 이용함으로써 이러한 비용을 절약할 수 있습니다.
AWS에서도 이러한 DR을 위한 기능과 서비스를 제공하고 있으며 이 글의 처음에서 설명한 가이드라인도 제공하고 있습니다.
또한 네트워크를 리전과 가용 영역으로 나누어 관리할 수 있기 때문에 재해 발생의 영향에 따라 알맞은 계획을 수립할 수 있습니다.
예로 들면 어느 리전의 한 가용 영역에서 재해가 발생하는 경우를 대비하여 다중 가용 영역(Multi AZ)로 서비스를 구성할 수 있으며
리전 전체에 대해 자연 재해가 발생하는 경우를 대비하여 다중 리전(Multi Region)으로 서비스를 구성 할 수도 있습니다.
DR에 대한 책임
AWS 상에서 운영하는 서비스에 대해 DR을 수립할 때 어떤 부분까지 AWS가 담당하는지를 확인할 필요가 있습니다.
이에 대해서 복원력에 대한 공유 책임 모델이 정의되어 있습니다.
AWS 에서는 서비스의 SLA를 충족하기 위해 하드웨어 및 소프트웨어 등 인프라 적인 복원력을 담당합니다.
따라서 리전 및 가용 영역은 물리적으로 완전히 분리하여 관리하고 있습니다. 이렇게 물리적으로 격리된 환경이기 때문에 어떠한 재난이 발생하더라도 다른 환경에 미치는 영향을 최소화 할 수 있게 됩니다.
또한 나뉘어진 리전 간에 최적화된 네트워킹도 제공하고 있습니다.
고객은 AWS에서 제공하는 복원력에 대한 기능 및 서비스를 적절하게 이용할 필요가 있습니다. 예로 들면 EC2의 경우에는 DR을 위해 AWS에서 제공하고 있는 다중 가용 영역 환경을 구성할 수 있습니다.
이러한 기능의 이용 여부는 고객에게 달렸으며 그 책임 또한 고객이 지게 됩니다.
단순히 EC2의 다중 가용 영역 뿐만 아니라 다양한 서비스의 백업 관리 등도 고객의 책임이 됩니다.
클라우드의 재해 복구 전략
AWS 백서에서는 4가지의 재해 복구 전략을 소개하고 있습니다.
왼쪽에서 오른쪽으로 갈 수록 많은 비용을 요구하며 더 높은 수준의 RTO 및 RPO를 보장합니다.
백서의 해당 페이지는 꼭 읽어보시길 바랍니다.
단순히 한 리전의 단일 가용 영역에 대한 재해라면 백업/복원 전략으로 대응 가능한 경우가 많습니다.
하지만 데이터 손실의 최소화 및 리전 전체에 대한 계획이 필요한 경우라면 파일럿 라이트, 웜 스탠바이, 멀티 사이트 액티브/액티브 구성을 검토할 필요가 있습니다.
다중 가용 영역과 다중 리전의 우선 순위
AWS 상에서 하나의 리전에서 모든 가용 영역이 한번에 사용 불가능한 상태가 된 적은 없었습니다.
따라서 다중 리전의 구성을 준비하기 전에 우선 다중 가용 영역의 구성을 구현하는 것을 추천드립니다.
만약 단일 리전의 DR로 BCP를 충족하지 못하는 경우에는 다른 리전으로의 백업부터 검토하는 것을 추천드립니다.
AWS의 장애에 대한 기록
AWS Health Dashboard를 확인하시면 지난 1년간 발생한 장애에 대한 기록을 확인하실 수 있습니다.
그 이전의 장애에 대해서는 사후 이벤트 요약을 확인하거나 서포트 티켓을 작성할 필요가 있습니다.
AWS가 제공하는 복원력에 대한 서비스
DR 구성을 위해 AWS에서 제공하고 있는 서비스에 대해 간략하게 알아보겠습니다
백업
EC2는 스냅샷이나 AMI, RDS는 스냅샷, S3는 버전 관리 등 AWS의 대부분의 서비스는 백업에 관한 기능을 제공하고 있습니다.
그리고 AWS Backup을 사용하면 각 백업을 하나의 서비스에서 관리할 수 있습니다.
백업의 주기는 RPO와 직접적인 관련이 있습니다. 하지만 빈번한 백업 및 장기간 보관하는 백업은 많은 비용이 수반됩니다. 따라서 감당할 수 있는 수준의 워크로드와 비용의 트레이드 오프가 필요합니다.
재해가 발생하였을 때 백업을 기반으로 신속하고 안전하게 복구하는 프로세스를 구현하기 위해 CloudFormation과 같은 IaC 서비스를 이용하는 것이 좋습니다. IaC를 사용하지 않고 직접 구현하게 된다면 RTO의 증가 및 워크로드의 복잡성 증가 등이 발생할 수 있습니다.
다중 가용 영역
ELB 서비스를 이용하면 EC2나 ECS 등의 서버를 다중 가용 영역 구성으로 배치한 후 트래픽을 조절할 수 있습니다.
하나의 가용 영역에서 장애가 발생한다면 다른 가용 영역으로 트래픽이 라우팅됩니다. 또한 AutoScaling도 함께 설정하여 갑작스러운 트래픽 증가에 대해서도 대응하여 고가용성의 서비스도 제공할 수 있습니다.
헬스 체크 등을 이용하여 각 서버의 스테이터스도 확인 할 수 있으며 이를 토대로 경보 등을 발생시킬 수 있습니다.
DR 을 목표로하는 서비스
AWS Elastic Disaster Recovery(AWS DRS)을 이용하면 DRS의 전체적인 설정 및 테스트 등을 보다 간단하게 설정할 수 있습니다.
AWS DRS는 저렴한 스토리지, 최소한의 컴퓨팅 및 특정 시점으로 복구를 통해 온프레미스 및 클라우드 기반 애플리케이션을 빠르고 안정적으로 복구하여 가동 중지 시간과 데이터 손실을 최소화할 수 있습니다.
마무리
간략하게 AWS와 DR에 대하여 알아보았습니다. 서두에 첨부한 AWS 블로그 시리즈와 백서는 DR의 수립 전에 꼭 확인해보시는 것을 추천합니다.
긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 언제나 환영합니다. must01940 지메일로 연락 주시면 감사합니다!
본 블로그 게시글을 보시고 문의 사항이 있으신 분들은
클래스메소드코리아 ([email protected])로 연락 주시면 빠른 시일 내 담당자가 회신 드릴 수 있도록 하겠습니다 !
- 재난 복구 계획 이라고도 합니다. 본 글에서는 재해 복구 계획으로 표기합니다. ↩