[AWS SAA-C03] AWS 재해복구계획(DR) 정리 2

재해복구계획

• 복구 시간 목표(RTO): 운영 수준 협약(OLA)에 정의된 대로 운영 중단 후 비즈니스 프로세스를 서비스 수준으로 복원하는 데 걸리는 시간(예: RTO가 1시간이고 재해가 오후 12시(정오)에 발생하는 경우, DR 프로세스는 시스템을 1시간 이내, 즉 오후 1시까지 수용 가능한 서비스 수준으로 복원해야 합니다.

• 복구 시점 목표(RPO): 재해가 발생하기 전 시간으로 측정된 허용 가능한 데이터 손실량입니다. 예를 들어 재해가 오후 12시(정오)에 발생하고 RPO가 1시간인 경우 시스템은 오전 11시 이전에 시스템 내에 있던 모든 데이터를 복구해야 합니다.

재해 복구 시나리오

• 재해 복구 시나리오는 AWS와 함께 데이터 센터에서 실행되는 기본 인프라를 사용하여 구현할 수 있습니다.
• 기본 사이트가 AWS 다중 리전 기능을 사용하여 AWS에서 실행되는 경우에도 재해 복구 시나리오가 적용됩니다.
• 아래의 조합 및 변형은 언제나 조정 가능합니다.

재해 복구 시나리오 옵션

1. Backup & Restore(데이터 백업 및 복원)
2. Pilot Light(최소한의 중요 기능만)
3. Warm Standby(모든 기능을 축소한 버전)
4. multi-Site(액티브-액티브)

• DR 시나리오 옵션의 경우, 백업 및 복원 옵션에서 멀티 사이트 옵션으로 이동하면 비용이 증가함에 따라 RTO 및 RPO가 감소합니다.

• 백업 및 복원
  AWS를 사용하여 비용 효율적이고 내구성 있으며 안전한 방식으로 데이터를 백업하고 데이터를 빠르고 안정적으로 복구할 수 있습니다.

• 백업 단계
  대부분의 기존 환경에서는 데이터를 테이프에 백업하고 정기적으로 오프사이트로 전송하여 중단이나 재해 발생 시 시스템을 복원하는 데 시간이 오래 걸립니다.

1. Amazon S3는 데이터를 백업하고 빠른 복원을 수행하는 데 사용할 수 있으며 어느 위치에서나 사용할 수 있습니다.
2. AWS 가져오기/내보내기는 인터넷을 거치지 않고 스토리지 장치를 AWS로 직접 전송하여 대규모 데이터 세트를 전송하는 데 사용할 수 있습니다.
3. 시간의 검색 시간이 적절하고 허용 가능한 데이터 아카이빙에 Amazon Glacier를 사용할 수 있습니다.
4. AWS 스토리지 게이트웨이를 사용하면 온프레미스 데이터 볼륨의 스냅샷(EBS 볼륨 생성에 사용됨)을 백업용으로 S3에 투명하게 복사할 수 있습니다. 백업 솔루션(게이트웨이 저장 볼륨) 또는 기본 데이터 저장소(게이트웨이 캐시 볼륨)로 사용할 수 있습니다.
5. AWS 다이렉트 커넥트를 사용하여 온프레미스에서 Amazon으로 데이터를 일관되고 빠른 속도로 직접 전송할 수 있습니다.
6. Amazon EBS 볼륨, Amazon RDS 데이터베이스, Amazon Redshift 데이터 웨어하우스의 스냅샷을 Amazon S3에 저장할 수 있습니다.

• 복원 단계
  백업한 데이터를 사용하여 컴퓨팅 및 데이터베이스 인스턴스를 빠르게 복원하고 생성할 수 있습니다.

백업 복원 - 복구 단계백업 및 복원을 위한 주요 단계입니다:

1. 적절한 도구 또는 방법을 선택하여 AWS에 데이터를 백업합니다.
2. 이 데이터에 대한 적절한 보존 정책을 확인합니다.
3. 암호화 및 액세스 정책을 포함하여 이 데이터에 대한 적절한 보안 조치가 마련되어 있는지 확인합니다.
4. 이 데이터의 복구 및 시스템 복원을 정기적으로 테스트합니다.

Pilot Light

파일럿 라이트 재해 복구 시나리오 옵션에서는 최소 버전의 환경이 항상 클라우드에서 실행되며, 기본적으로 데이터베이스와 같은 애플리케이션의 중요한 기능을 호스팅합니다.

이 접근 방식에서는 다음과 같이 합니다.

1. 데이터를 복제하고 계속 업데이트해야 하는 데이터베이스 등 시스템의 가장 중요한 핵심 요소를 AWS에서 구성하고 실행하여 파일럿 라이트를 유지합니다.
2. 복구 중에 애플리케이션 및 웹 서버와 같은 전체 프로덕션 환경(예: 사전 구성된 AMI 및 EBS 볼륨 스냅샷 사용)을 중요 코어를 중심으로 신속하게 프로비저닝할 수 있습니다.
3. 네트워킹의 경우, 여러 인스턴스에 트래픽을 분산하고 DNS가 로드 밸런서를 가리키도록 하는 ELB 또는 인스턴스가 연결된 사전 할당된 Elastic IP 주소를 사용할 수 있습니다.

준비 단계:

1. 데이터 중요 데이터를 복제 또는 미러링하기 위해 Amazon EC2 인스턴스 또는 RDS 인스턴스 설정
2. AWS에서 모든 지원 사용자 정의 소프트웨어 패키지를 사용할 수 있는지 확인합니다.
3. 빠른 복구가 필요한 주요 서버의 AMI를 생성하고 유지 관리합니다.
4. 이러한 서버를 정기적으로 실행하고 테스트하며 소프트웨어 업데이트 및 구성 변경 사항을 적용합니다.
5. AWS 리소스 프로비저닝 자동화를 고려하세요.

복구 단계 :

1. 사용자 지정 AMI에서 애플리케이션 EC2 인스턴스를 시작합니다.
2. 증가된 트래픽을 처리하기 위해 기존 데이터베이스/데이터 스토어 인스턴스의 크기를 조정합니다(예: RDS를 사용하는 경우, 수직으로 쉽게 확장할 수 있는 반면 EC2 인스턴스는 수평으로 쉽게 확장할 수 있음).
3. 데이터베이스/데이터 스토어 인스턴스를 추가하여 데이터 티어에서 DR 사이트에 복원력을 제공합니다(예: 복원력을 개선하기 위해 RDS용 Multi-AZ를 켜는 경우).
4. Amazon EC2 서버를 가리키도록 DNS를 변경합니다.
5. 자동화된 방식으로 AMI 기반이 아닌 시스템을 설치 및 구성합니다.

Warm Standby

Warm Standby DR 시나리오에서는 비즈니스 크리티컬 시스템과 동일한 완전한 기능을 갖춘 환경의 축소된 버전이 항상 클라우드에서 실행됩니다.
이 설정은 테스트, 품질 보증 또는 내부 용도로 사용할 수 있습니다.
재해가 발생하면 시스템을 쉽게 확장 또는 축소하여 프로덕션 부하를 처리할 수 있습니다.

• 준비 단계 단계 :

1. 데이터를 복제 또는 미러링하기 위해 Amazon EC2 인스턴스를 설정합니다.
2. 더 빠른 프로비저닝을 위한 AMI 생성 및 유지 관리
3. 최소한의 EC2 인스턴스 또는 AWS 인프라를 사용하여 애플리케이션을 실행하세요.
4. 라이브 환경에 맞춰 소프트웨어 및 구성 파일을 패치하고 업데이트하세요.

• 복구 단계:

1. 로드 밸런서를 사용하여 서비스 중인 Amazon EC2 플릿의 크기를 늘립니다(수평 확장).
2. 필요에 따라 더 큰 Amazon EC2 인스턴스 유형에서 애플리케이션을 시작합니다(수직 확장).
3. DNS 레코드를 수동으로 변경하거나 Route 53 자동 상태 확인을 사용하여 모든 트래픽을 AWS 환경으로 라우팅합니다.
4. 자동 확장을 사용하여 플릿의 크기를 적절히 조정하거나 증가된 부하를 수용하는 것을 고려한다.
5. DR 다운에 대비하여 복원력을 추가하거나 데이터베이스를 확장한다.
   웜 대기 - 복구 단계

Multi Site

• 멀티사이트는 액티브-액티브 구성 DR 접근 방식으로, 동일한 솔루션이 온사이트 인프라와 동일한 AWS에서 실행됩니다.
• DNS 서비스 가중 라우팅 방식을 사용하여 필요에 따라 트래픽을 두 인프라에 균등하게 분산할 수 있습니다.
• 재해가 발생하면 모든 트래픽을 AWS 환경으로 전송하도록 DNS를 조정하고 그에 따라 AWS 인프라를 확장할 수 있습니다.

준비 단계 :

1. 프로덕션 환경과 복제하도록 AWS 환경을 설정합니다.
2. DNS 가중치 또는 유사한 트래픽 라우팅 기술을 설정하여 들어오는 요청을 두 사이트로 분산합니다.
3. 영향을 받는 사이트에서 트래픽을 재라우팅하도록 자동 장애 조치를 구성합니다. 예를 들어 애플리케이션이 기본 DB를 사용할 수 있는지 확인한 후 사용할 수 없는 경우 AWS DB로 리디렉션합니다.

복구 단계 :

1. 수동으로 또는 DNS 장애 조치를 사용하여 모든 요청이 AWS 사이트로 전송되도록 DNS 가중치를 변경합니다.
2. 모든 쿼리에 로컬 AWS 데이터베이스 서버를 사용하도록 장애 조치에 대한 애플리케이션 로직을 설정합니다.
3. 자동 스케일링을 사용하여 AWS 플릿의 크기를 자동으로 조정하는 것을 고려하세요.

참고

• https://jayendrapatil.com/aws-disaster-recovery-whitepaper/