재해 복구(DR)란?

 

최근에 Aurora RDS for Postgres를 버전 업그레이드해야 하는 상황이 있었다. 꽤 예전 버전을 쓰고 있었는데, AWS 측에서 RDS for postgres를 지원할 때, 특정 기간 동안 지원하기 때문이다. 지원 기간이 끝난 경우에는 추가 비용을 지불하고 RDS를 써야 한다. 공식적으로 지원하지는 않지만 확장 관리한다는 명목으로 꽤 많은 비용이 센다.

 

아무튼, 이러한 과정 속에서 RDS를 백업하고 작업을 진행했는데, 일반적으로는 AWS Lambda를 써서 RDS를 주기적으로 S3 dumpall을 사용하는 것으로 알고 있었다. 하지만 AWS Backup이라는 서비스가 나오게 되면서 보다 편리하고 간편하게 백업을 진행할 수 있게 되었다.

 

https://aws.amazon.com/ko/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/

이번에는 데이터베이스를 백업하고 복구하는 의미인 재해복구(Disaster Recovery, DR)에 대해서 살펴보고, RDS를 백업하는 일반적인 방법론에 대해서 다뤄보려고 한다.

 

본론

재해복구(DR)

인프라에 관심이 있는 사람이라면 누구나 시스템의 안정성과 복원력 확보가 얼마나 중요한지 잘 알 것이다. 특히 비즈니스의 핵심 자산인 데이터가 저장된 데이터베이스가 날라가거나 심각한 손상을 입어 사용할 수 없게 되는 상황은 끔찍한 상황이다.

 

바로 이러한 재해(Disaster) 상황에 대비하고, IT 시스템을 신속하게 복구하여 비즈니스 연속성을 확부하기 위한 핵심 전략이 바로 재해 복구(Disaster Recovery, DR)이다. DR은 단순히 특정 데이터베이스의 문제를 넘어, 자연 재해, 시스템 오류, 사이버 공격 등 예측 불가능한 이유로 IT 인프라 전체가 마비되었을 때, 미리 정의된 복구 목표(PRO와 PRO)에 따라 시스템과 데이터를 복원하고 핵심 비즈니스 기능을 빠르게 재개할 수 있도록 하는 체계적인 프로세스를 말한다.

 

간단히 말해, '시스템이 멈추거나 데이터가 사라졌을 때, 어떻게 얼마나 빨리 복구할 것인가?'에 대한 답을 미리 준비하는 과정이라고 할 수 있다. 이 과정에서 가장 중요한 지표가 바로 PRO(복구 목표 시점)와 RTO(복구 목표 시간)이다.

 

[AWS]재해 복구(DR) 목표 - 안정성 원칙

 

이 두 지표는 재해 발생 시점을 기준으로 그 의미를 명확히 할 수 있다.

• RPO (Recovery Point Objective, 목표 복구 시점) : 재해 발생 이전의 어느 시점까지의 데이터를 복구할 것인가? 즉, 최대 허용 데이터 손실량을 의미한다.
• RTO (Recovery Time Objective, 목표 복구 시간) : 재해 발생 이후 시스템을 정상 상태로 복구하는 데 까지 걸리는 최대 허용 시간, 즉 목표 다운타임을 의미한다.

아무래도, 데이터를 조금 유실하고, 빠르게 복구하려고 하면 할수록 비용이 많이 발생할 것이다. 이번 포스팅에서는 특히 AWS 환경에서 이러한 재해 복구(DR)를 어떻게 설정할 수 있을지 다뤄보려고 한다. 이번 포스팅에서는 Aurora RDS를 사용하는 경우에 한해서 이야기를 해보려고 한다.

 

RPO ( Recovery Point Objective, 목표 복구 시점 )

RPO는 시스템 장애나 재해 발생 시, 최대 얼마만큼의 데이터 손실을 감수할 수 있는가?를 시간 단위로 정의하는 핵심 목표이다. 이는 복구 시 '최소한 이 시점까지의 데이터는 복원되어야 한다'는 기준선과 같다. 재해 발생 시점을 기준으로 그 이전(과거)의 특 정 데이터 복구 지점을 의미하며, 흔히 "재해의 왼쪽에 있다"라고 시각적으로 표현하기도 한다.

 

RPO는 본질적으로 데이터 백업 또는 복제 빈도에 의해 직접적으로 결정된다. 백업 주기가 길수록 장애 발생 시점과 마지막 백업 시점 사이의 간격이 벌어져 잃어버릴 수 있는 데이터의 양(시간)이 많아지므로 RPO는 길어진다. 반대로 백업 주기가 짧을수록 RPO도 짧아져 데이터 손실을 최소화할 수 있다.

 

RDS  기본 스냅샷의 RPO

AWS RDS에서 제공하는 기본적인 자동 스냅샷 기능만 사용하고, 이 스냅샷이 매일 새벽 3시에 생성된다고 가정해 보자. 만약 다음날 새벽 2시 59분에 데이터베이스에 치명적인 장애가 발생한다면, 우리가 가진 가장 최신의 백업은 거의 24시간 전엔 전날 새벽 3시의 스냅샷이다. 이 경우, 장애 발생 직전까지 최대 23시간 59분 동안의 데이터를 잃어버릴 수 있으므로, 이 시스템의 RPO는 24시간이 된다.

 

RDS의 자동 백업 및 시점 복구 ( Point-in-Time Recovery, RITR )

 

이 기능은 RDS에서 자동 백업 기능을 설정해두었을 때만 사용할 수 있다. 만약 자동 백업 기능을 사용하지 않았다면, 특정 시점으로 복원 버튼이 비활성화된다. 자동 백업을 활성화하면, 설정된 백업 보존 기간(최대 35일) 동안 주기적인 스냅샷 생성과 더불어 데이터베이스 트랜잭션 로그를 지속적으로 5분 간격으로 S3에 백업한다.

 

이 트랜잭션 로그 덕분에 스냅샷 사이의 특정 시점, 예를 들어 장애 발생 5분 전 시점으로 데이터베이스를 복구하는 시점 복구(PITR)가 가능해진다.  결과적으로 PITR을 사용하면 RPO를 최대 5분까지 획기적으로 줄일 수 있다. 이는 24시간 RPO 요구사항을 훨씬 상회하는 기능이다.

 

Lambda + S3를 이용한 주기적인 논리 백업

AWS Lambda와 Amazon S3를 사용하여 원하는 주기로 데이터베이스의 논리 백업 (pg_dumpall 또는 mysqldump) 명령을 수행하고 그 결과 파일을 S3에 저장하는 방식도 있다.

 

이 방식의 경우 스케쥴러를 1시간 간격으로 쓴다면 RPO는 1시간이 된다. 이 경우에는 이론적으로 더 짧게 설정할 수도 있지만, 비용 문제나 성능 문제가 따른다. pg_dumpall 등의 기능을 사용하는 경우 PITR보다 짧은 RPO를 가지는 것은 RDS에 무리가 가지만, 장점으로는 특정 시점의 완전한 논리 백업본을 확보할 수 있어, 다른 환경으로의 마이그레이션이나 데이터 분석 등에 활용하기 용이할 수 있다.

 

 

이벤트브릿지를 통해서 스케쥴러를 Lambda로 실행하고, RDS의 내용을 S3에 저장하고, 추가적으로 필요하지 않다면 삭제하거나 S3의 Lifecycle Policy 정책을 사용할 수 있다. 이 아키텍처는 서버리스 구성 요소를 활용하여 RDS 데이터베이스의 정기적인 논리 백업을 자동화한다.

 

최근에는 AWS Backup이라는 서비스가 나오면서 복잡하게 서버리스로 구성할 필요도 없고, 사실 Aurora의 기능이 굉장히 좋기 때문에 쿠버네티스를 쓰는 환경에서도 크론잡을 써서 위와 같은 구조를 구성하지 않아도 충분히 백업을 잘할 수 있다.

 

 

RTO ( Recovery Time Objective, 목표 복구 시간 )

다음은 RTO(Recovery Time Objective)이다. RTO가 "어느 시점까지의 데이터를 복구할 것인가?" 에 대한 답이었다면, RTO는 서비스 장애 발생 시, 얼마 만에 서비스를 정상 상태로 복구할 것인가?를 정의하는 목표이다. 즉, 시스템 장애 후 서비스가 다시 가동될 때까지 허용되는 최대 시간(다운타임)을 의미한다. 재해 발생 타임라인에서 RPO가 재해 시점의 왼쪽(과거 데이터)에 해당한다면, RTO는 오른쪽(미래 복구 시간) 영역을 나타낸다.

 

단순히 데이터 복구 완료 시간이라기보다는, 사용자가 실제로 서비스를 다시 사용할 수 있게 되기까지 걸리는 총 시간을 목표로 설정하는 것이 더 정확하다. 데이터 복수는 전체 서비스 복구 과정의 중요한 일부이다.

 

RTO를 짧게 설정하기 위해서는, 즉 서비스를 신속하게 복구하기 위해서는 철저한 준비가 필요하다. 복구 계획의 상세 수준, 복구 프로세스의 자동화 정도, 비상시 즉시 사용할 수 있는 대기(Standby) 시스템의 유무, 기술 팀의 대응 속도 및 숙련도 등이 RTO 달성에 영향을 미친다.

 

백업으로부터 복원

가장 기본적인 재해 복구 방법은 백업(스냅샷 또는 RITR 데이터)으로부터 새로운 데이터베이스 인스턴스를 생성하는 것이다. 이는 데이터를 복원하는 확실한 방법이지만, 새 인스턴스를 프로비저닝 하고 데이터를 로딩하는 데 상당한 시간이 소요될 수 있다. 데이터베이스의 크기와 성능 설정에 따라 수십 분에서 몇 시간까지 걸릴 수 있으므로, RTO가 상대적으로 길어도 무방한 서비스나 대규모 재해 복구 시나리오에 주로 사용된다. 신속한 복구가 최우선인 상황에는 적합하지 않을 수 있다.

 

RDS 다중 AZ (Multi-AZ) 배포

RDS에서 고가용성과 낮은 RTO를 확보하기 위한 표준적인 방법 중 하나이다. Multi-AZ 배포를 설정하면, AWS는 자동으로 다른 가용 영역 (AZ)에 동일한 구성의 예비(Standby) DB 인스턴스를 생성하고, 원본(Primary) DB의 데이터를 예비 인스턴스로 실시간 동기식 복제(Synchronous Replication)한다.

 

만약 원본 DB 인스턴스에 문제가 발생하면, AWS는 이를 자동으로 감지하고 내부적으로 DNS 엔드포인트를 예비 DB 인스턴스로 전환하는 자동 장애 조치(Automatic Failover)를 수행한다. 이 전체 장애 조치 과정은 일반적으로 몇 분 안에 완료되어 서비스 중단 시간을 크게 줄일 수 있다. 다만, 예비 인스턴스를 항상 운영해야 하므로 단일 AZ 배포 대비 약 두 배의 인스턴스 비용이 발생한다.

 

Amazon Aurora 활용

 

Amazon Aurora는 아키텍처 설계 단계부터 고가용성과 빠른 복구를 염두에 두었기 때문에 RTO 단축에 특히 강점을 가진다. 특히, Amazon Aurora는 생성할 때, 클러스터의 형태로 생성하는데, 기본적으로는 라이터 인스턴스와 리더 인스턴스를 분리한다. DEV 환경에서 권장 사항이 하나 있는 것을 볼 수 있는데, 이는 리더 인스턴스를 지웠기 때문에 라이터 인스터 스마 있어 리더 인스턴스를 만들라는 권장 사항이다. 

 

Aurora를 사용하는 경우 굉장히 빠른 장애 조치를 수행할 수 있다. Aurora는 최대 15개의 읽기 전용 복제본(Reader Instance)을 생성할 수 있다. 이 복제본들은 읽기 부하 분산 외에도 중요한 역할을 하는데, 원본(Writer Instance)에 장애 발생 시 이 복제본 중 하나를 매우 신속하게 새로운 원본 인스턴스로 승격시켜 서비스 연속성을 확보할 수 있다.

 

 

여기서 중요한 것이 복제본별 장애 조치 우선순위 설정이다. 각 복제본에 Tier 0부터 15까지 우선순위 등급을 지정할 수 있다. 장애 발생 시 Aurora는 가장 높은 우선 순위인 Tier 0과 Tier 1에 속한 복제본을 최우선으로 새로운 원본 후보를 고려하여 승격을 시도한다. 따라서, 가장 중요한 복제본들을 Tier 0 또는 Tier 1로 설정하면, 장애 조치 시간을 일반적으로 1분 미만, 많은 경우 수 초 내로 단축할 수 있다. 이는 매우 빠른 복구 속도이다. Tier 2부터 15까지의 복제본들은 그다음 순서로, 동일한 우선순위를 가지고 승격 후보가 된다.

 

이를 스탠바이(Standby) 혹은 핫-로드(hot-load)라고 부르며, 장애가 발생한 경우 자동으로 스스로 복구할 수 할 수 있다.

 

마치며

일반적으로 RPO와 RTO는 짧으면 짧을 수록 장애 발생 시점에 가까워져서 여러모로 좋다. 하지만 현실적으로는 비용적인 문제가 많으니 적절한 것을 선택하는 것이 좋다.

 

위 내용은 기술 블로그의 정석적인 마지막 멘트... 결론적으로는 Aurora를 쓰는 것이 좋다.

 

참고

• [AWS] Amazon Aurora, 추가 장애 복구 : https://aws.amazon.com/ko/blogs/korea/additional-failover-control-for-amazon-aurora/

감사합니다.