[AWS SAA] 59. 재해 복구

재해 복구 고려 사항

모든 재해 복구(DR) 계획이 동일하게 생성하는 것은  아니며 많은 계획이 실패합니다. 보다 나은 재해 복구를 위해 테스트, 리소스 및 절차를 고려해 계획을 마련해야 합니다.

 

1. 테스트
   DR 계획을 테스트하여 구현을 검증해야 합니다. 정기적으로 워크로드의 DR 리전으로 장애 조치를 테스트하여 복구 목표가 충족되는지 확인합니다. 드믈게 실행되는 복구 경로는 개발하지 않는 것이 좋습니다. 예를 들어 읽기 전용 쿼리에만 사용되는 세컨더리 데이터 스토어가 있을 수 있습니다. 기본 데이터 스토어에 장애가 발생했을 때 세컨더리 데이터 스토어로 장애 조치되도록 계획합니다.
   
   
2. 리소스
   정기적으로 복구 경로를 프로덕션 환경에서 실행해야 합니다. 이를 통해 복구 경로의 유효성이 검사되고 이벤트 동안 리소스가 운영에 충분한지 확인하는 데 도움이 됩니다. 프로덕션 호나경에서의 구성 변경을 DR 네트워크에도 동기화해야 합니다.
   
   
3. 계획
   복구 계획은 주기적으로 테스트를 해야만 제대로 작동합니다. 보조 리소스의 용량은 마지막으로 테스트 했을 때는 충분했더라도 운영 횐경 변화에 의해 더 이상 로드를 감당하지 못할 수 있습니다. 따라서 정기적인 테스트를 통해 보조 리소스의 용량이 실제 운영 환경에서 충분한지 확인해야 합니다.

 

가용성 개념

프로덕션 시스템은 대체로 가동 시간 측면에서 정의됐거나 암묵적인 목표를 갖고 있습니다. 장애 발생 시 가동 중단 시간이 최소화되면 "시스템은 고가용성이다"라고 합니다. 가동 중단 시간은 없앨 수 없지만 몇 초 또는 몇 분으로 단축해야 합니다.

 

고가용성은 가동 중단 시간 및 비용을 최소화하고 장애로부터 보호합니다. 매우 짧은 가동 중단, 신속한 복구, 낮은 비용으로 비즈니스를  계속 운영할 수 있게 합니다.

 

내결함성은 고가용성과 자주 혼동하지만 서비스 중단이 발생하지 않도록 애플리케이션 구성 요소에 내장된 중복성을 말합니다. 하지만 비용은 더 많이 듭니다.

 

백업은 데이터를 보호하고 비즈니스 연속성을 보장하는 데 있어 중요합니다. 그와 동시에, 백업을 제대로 구현하는 것은 까다로운 문제가 될 수 있습니다. 데이터가 생성되는 속도는 기하급수적으로 증가하고 있기 때문입니다. 그러나 로컬 디스크의 밀도 및 내구성은 데이터만큼 빠른 속도로 증가하고 있지는 않습니다. 엔터프라이즈 백업은 그 자체가 하나의 산업이 됐습니다.

 

 재해 복구는 가용성 구성 요소 중 하나로서 간과할 때가 많습니다. 자연재해로 하나 이상의 구성 요소에 장애가 발생하거나 기본 데이터 원본이 손상됐을 때, 데이터 손실 없이 신속하게 서비스를 복구할 수단이 있어야 합니다.

 

장애 조치와 리전

AWS는 전 세계적으로 여러 리전에서 사용할 수 있습니다. 시스템을 완전하게 배포할 사이트 외에 재해 복구 사이트로 가장 적합한 로케이션을 선택할 수 있습니다. 리전을 이용할 수 없는 경우는 매우 희박합니다. 그러나 매우 큰 규모의 이벤트(자연 재해 등)가 어떤 리전에 영향을 미칠 경우, 그럴 가능성도 있습니다.

 

AWS는 리전별로 제공하는 현재 제품 및 서비스의 자세한 사이트 페이지를 유지하고 관리합니다. AWS는 한 리전의 어떤 대규모 이벤트가 다른 리전에 영향을 미치지 안도록 엄격한 리전 격리 정책을 유지합니다. 당사는 고객들이 자사의 전략에도 이와 유사한 다중 리전 접근 방식을 취할 것을 권장합니다. 각 리전은 다른 리전에 영향을 미치지 않고 오프라인으로 전환할 수 있어야 합니다.

 

미국(US) 내 AWS 리전과 연결되는 AWS Direct Connect 회선을 보유하고 있는 경우, 퍼블릭 인터넷을 통한 트래픽 이동 없이 AWS GovCloud(US)를 퐇마한 미국 내 모든 리전에 액세스할 수 있습니다. 또한 애플리케이션 배포 방식도 고려해야 합니다. 각 리전에 개별적으로 애플리케이션을 배포할 경우, 재해 발생 시 해당 리전을 격리하고 모든 트래픽을 다른 리전으로 이전할 수 있습니다.

 

새로운 애플리케이션과 인프라를 신속하게 배포하는 경우, 액티브-액티브 리전이 필요할 수 있습니다. 어떤 리전의 애플리케이션이 오작동하거나 사용 불가능 상태가 되는 문제를 일으킨 무언가를 배포한다고 가정해 보겠습니다.  Route 53의 활성 레코드 세트에서 해당 리전을 제거하고 근본 원인을 확인한 다음, 변경 사항을 롤백한 후에 해당 리전을 다시 활성화할 수 있습니다.

 

RPO(복구 시점 목표) 및 RTO(복구 시간 목표)

복구 시점 목표(RPO)는 시간 단위로  측정한 허용 가능한 데이터 손실량을 나타냅니다. 예를 들어 어떤 재해가 오후 1:00에 발생하고 RPO가 12시간인 경우 시스템은 당일 오전 1:00에 존재하던 모든 데이터를 복구해야 합니다. 데이터 손식은 최대 12시간(오전 1:00와 오후 1:00 사이)입니다.

 

복구 시간 목표(RTO)란 운영 수준 계약(OLA)에서 정의한 바와 같이 중단 후 비즈니스 프로세스를 서비스 수준으로 복원하기까지 걸리는 시간을 의미합니다. 예를 들어 어떤 재하가 오후 1:00에 발생하고 RTO가 1시간인 경우 재해 복구 프로세스는 비즈니스 프로세스를 오후 2:00까지 허용 가능한 수준으로 복원해야 합니다.

 

일반적으로 회사는 시스템을 가동할 수 없을 때 기업에 미칠 재정적 영향에 근거하여 허용 가능한 RPO 및 RTO를 결정합니다. 회사는 가동 중단 시간 및 시스템 가용성 부족으로 인한 사업 손실 및 회사 평판 손상 등 여러 가지 요인들을 고려해 재정적 영향을 평가합니다. IT 조직은 RTO에 따라 수립된 일정 및 서비스 수준 범위 내에서 RPO에 근거해 비용 효율적인 시스템 복구를 제공할 수 있는 솔루션을 계획합니다.