AWS를 사용한 재해 복구 시나리오
- 백업 및 복구
- AWS 로의 간단한 복구를 위한 파일럿 라이트
- 웜 대기 솔루션
- 다중 사이트 솔루션
(1) 백업 및 복구
- Amazon S3가 백업 데이터에 이상적인 솔루션인 이유는 99.9%의 객체 내구성을 제공하도록 설계됐기 때문
- 어떤 위치에서든 액세스 가능
- S3에 백업할 수 있는 다양한 상용 및 오픈 소스 백업 솔루션이 있다.
- AWS Import/Export 서비스는 스토리지 장치를 직접 AWS에 연결함으로써 대규모의 데이터 세트 전송이 가능함
- AWS Storage Gateway 서비스를 사용하면 온 프레미스 데이터 볼륨의 스냅샷이 백업을 위해 Amazon S3에 자동 복사되므로 나중에 이 스냅샷에서 로컬 볼륨이나 AWS EBS 볼륨을 생성할 수 있다.
- AWS에서 실행되는 시스템의 경우, 고객은 Amazon S3에도 백업을 할 수 있다. Amazon RDS의 Elastic Block Store(EBS) 볼륨 및 백업의 스냅샷은 Amazon S3에 저장된다. 또는 Amazon S3로 파일을 직접 복사하거나 백업 파일을 생성하여 Amazon S3에 복사할 수도 있다. Amazon S3에 백업 데이터를 저장하는 다양한 백업 솔루션이 있으며, Amazon EC2 시스템에서도 이러한 솔루션을 사용할 수 있다.
데이터 백업은 시작에 불과하다. 재해 시나리오에서는 데이터 복구를 테스트할 수 있어야 하고, 데이터 복구가 신속하고 신뢰할 만한 방식으로 이루어져야 한다. 고객은 자신의 시스템이 데이터를 적절히 보존하고, 데이터 보안을 유지하도록 구성되었는지, 데이터 복구 절차를 이미 테스트했는지 확인해야 한다.
백업 및 복구를 위한 핵심 단계 :
- 사용자의 데이터를 AWS에 백업할 적절한 도구 또는 방법을 선택한다.
- 이 데이터에 대한 적절한 보존 정책이 있는지 확인한다.
- 이 데이터에 대한 적절한 보안 방법(암호화 및 액세스 정책 등)이 마련되어 있는지 확인한다.
- 이 데이터의 복구 및 시스템 복구를 정기적으로 테스트한다.
AWS 로의 신속한 복구를 위한 파일럿 라이트
파일럿 라이트의 개념은 가스 히터에서 비롯되었다. 가스 히터는 항시 켜지는 작은 불꽃으로 전체 난로를 점화하여 필요할 떄 집을 따뜻하게 할 수 있다.
이 시나리오는 백업 및 복구 시나리오와 비슷하지만, 시스템의 가장 중요한 핵심요소가 이미 구성되어 AWS(파일럿 라이트)에서 실행되고 있는지를 확인해야 한다. 복구 시점이 되면 중요한 코어 주변으로 전체 생산 환경을 신속하게 프로비저닝해야 한다.
파일럿 라이트를 위한 인프라 요소에는 기본적으로 데이터베이스서버가 포함되는데, 이 서버의 데이터는 Amazon EC2에 복제된다. 시스템에 따라 AWS에 복제해야 하는 중요 데이터가 데이터베이스 외부에 있을 수도 있다. 이것이 시스템의 중요한 코어(파일럿 라이트)이다. 코어 주변으로 AWS의 모든 다른 인프라 요소(난로의 나머지 부분처럼)가 신속하게 프로비저닝되어 전체 시스템을 복구하는 것이다.
비즈니스 크리티컬한 서비스를 복구하기 위해 인프라의 나머지 부분을 프로비저닝하려면 일반적으로 Amazon 머신 이미지(AMI)로 번들링된 사전 구성된 서버가 있어야 한다. 이 서버는 복구 시점 통지를 받는 즉시 시작된다.
복구를 시작할 때, 이 AMI의 인스턴스가 신속하게 준비되어 파일럿 라이트 주변의 배포 범위에서 각자의 역할을 찾는다.
네트워킹 관점에서 보면 엘라스틱 IP 주소(재해 복구 준비 단계에서 미리 할당할 수 있음)를 사용하여 인스턴스와 연결하거나 Elastic Load Balancing을 사용하여 트래픽을 여러 인스턴스에 분배할 수도 있다. 다음으로 CNAME을 사용하여 Amazon EC2 인스턴스 시점이나 Elastic Load Balancing 시점으로 DNS 레코드를 업데이트한다.
덜 중요한 시스템의 경우에는 EBS 스냅샷의 형태와 같이 AWS에서 이용 가능한 설치 패키지 및 구성 정보가 덜 있는지 확인할 수 있다. 이는 애플리케이션 서버 설정 속도를 높여주는데, 여러 가용 영역에서 다수의 볼륨을 신속하게 생성하여 EC2 인스턴스에 연결할 수 있기 때문이다. 그런 다음 적당하게 설치 및 구성할 수 있다.
파일럿 라이트 방법은 상기 "백업 및 복구" 시나리오 보다 복구 시간을 더 단축할 수 있는데, 시스템의 핵심 요소가 이미 실행되고 있고 지속적으로 업데이트되기 때문이다. 애플리케이션을 완전히 복구하기 위한 설치 및 구성 작업이 남아있다. AWS를 사용해 인프라 자원의 프로비저닝 및 구성을 자동화해 상당한 시간을 절약하고 절약하고 인간의 실수로부터 보호할 수 있다.
준비 단계 :
다음 그림은 준비 단계를 보여준다. 이 단계에서는 복구 단계 시, 전체 환경이 시작되는 작은 코어인 파일럿 라이트에 정기적으로 변경되는 데이터를 복제해야 한다. 운영체제 및 애플리케이션과 같이 업데이트 빈도가 비교적 적은 데이터는 Amazon 머신 이미지(AMI)로 정기적으로 업데이트 및 저장할 수 있다.
준비 핵심 사항 :
- 데이터를 복제 또는 미러링하도록 EC2 인스턴스를 설정한다.
- AWS에 모든 사용자 정의 지원 스프트웨어 패키지가 있는지 확인한다.
- 빠른 복구가 필요한 핵심 서버의 Amazon 머신 이미지(AMI)를 생성 및 관리한다.
- 이 서버를 정기적으로 실행하고, 테스트하고, 소프트웨어 업데이트 및 구성 변경 사항을 적용한다.
- AWS 리소스의 프로비저닝을 자동화할 것인지 고려한다.
복구 단계 :
파일럿 라이트 주변 환경의 나머지 부분을 복구하기 위해, 적절한 인스턴스 형태로 몇 분 내에 Amazon 머신 이미지(AMI) 에서 시스템을 시작할 수 있다. 동적 데이터 서버의 경우, 크기를 조정하여 필요에 따라 생산 불륨을 처리하거나 적당히 용량을 추가한다. 대개의 경우 수평적 확장(가능한 경우)은 가장 비용 효율적인 방법이며, 시스템에 용량을 추가하는 확장성 있는 방법이다. 그러나 더 큰 EC2 인스턴스 유형을 선택하여 수직으로 확장하는 것도 가능하다. 네트워킹 관점에서 보면 필요한 DNS 업데이트는 무엇이든 병렬로 처리할 수 있다.
일단 복구한 후에는 중복을 최대한 빨리 복구해야 한다. 생산 환경에 장애가 발생한 직후에 재해 복구 환경에 장애가 발생할 확률은 적지만, 이 위험성 역시 염두에 두어야 한다. 시스템을 정기적으로 백업하고 데이터 계층에 추가 중복을 고려해 볼 수 있다.
복구 핵심 사항 :
- 사용자 정의 AMI에서 애플리케이션 EC2 인스턴스를 시작한다.
- 필요 시, 데이터베이스 / 데이터 저장 인스턴스의 크기를 조정 및 / 또는 확장한다.
- EC2 서버 지점으로 DNS를 변경한다.
- AMI에 기반하지 않는 시스템을 설치 및 구성한다. 이때, 자동화 방식으로 수행하는 것이 이상적이다.
AWS의 웜 대기 솔루션
웜 대기 솔루션은 파일럿 라이트 요소와 준비 과정을 제공한다. 이 솔루션을 사용할 경우 일부 서비스는 항상 실행되므로 복구 시간을 더욱 단축할 수 있다. 비즈니스 크리티컬한 시스템을 확인한 후 AWS에 완전히 복제하여 항상 실행할 수 있다.
이러한 서버는 규모가 제일 작은 EC2 인스턴스에서 실행할 수 있다. 이 솔루션은 최대 생산 부하를 처리할 정도로 규모가 확장되지는 않지만 기능은 온전하게 작동한다. 이 솔루션은 테스트, 품질 보증 및 내부 사용 목적 등 비생산 작업에 사용할 수 있다.
재해 시, 이 시스템은 생산 부하를 처리할 수 있도록 신속하게 규모를 확장한다. AWS에서는 로드밸런서에 더 많은 인스턴스를 추가하거나 작은 용량의 서버가 더 큰 EC2 인스턴스 유형에서 실행되도록 크기를 조정함으로써 규모를 확장할 수 있다. 위에서 설명한 바와 같이 대개의 경우 수평적 확장(가능한 경우) 이 수직적 확장보다 더 많이 이용된다
준비 단계 :
다음 다이어그램은 웜 대기 솔루션의 준비 단계를 보여주며, 이때 현장 AWS 솔루션이 나란히 실행된다.
준비 핵심 사항 :
- 데이터를 복제 또는 미러링하도록 EC2 인스턴스를 설정한다.
- Amazon 머신 이미지(AMI)를 생성 및 관리한다.
- EC2 인스턴스 또는 AWS 인프라의 최소 풋프린트를 사용하여 애플리케이션을 실행한다.
- 실제 환경에 맞게 소프트웨어 및 구성 파일을 패치하거나 업데이트 한다.
복구 단계 :
생산 시스템에 장애가 발생할 경우, 대기 환경은 생산 부하를 처리하도록 확장되며, DNS 레코드는 모든 트래픽을 AWS로 라우팅하도록 변경된다.
복구 핵심 사항 :
- 필요하다면 더 큰 EC2 인스턴스 유형에서 애플리케이션을 시작한다.(수직적 확장)
- Load Balancer로 서비스 내에서 EC2의 크기를 증가시킨다.(수평적 확장)
- DNS 레코드를 변경하여 모든 트래픽이 AWS 환경으로 라우팅되게 한다.
- AWS의 규모를 적정하게 조정하거나 증가된 부하를 수용할 수 있도록 Auto Scaling 사용을 고려한다.
AWS 및 현장에 배포된 다중 사이트 솔루션
다중 사이트 솔루션은 액티브-액티브 구성으로 기존의 현장 인프라뿐 아니라 AWS에서도 실행된다.
사용하는 데이터 복제 방법은 선택한 복구 시점에 의해 결정된다.
Amazon Route 53와 같은 가중 DNS 서비스는 서로 다른 사이트로 생산 트래픽을 라우팅하는 데 사용된다.
일정량의 트래픽은 AWS의 인프라로 전송되며, 나머지는 현장 인프라로 전송된다.
현장 재해 시, DNS 가중치를 조정하여 모든 트래픽을 AWS 서버로 보낼 수도 있다. 최대 생산 부하량을 처리할 수 있도록 AWS 서비스 용량을 신속하게 증가시킬 수 있다. EC2 Auto Scaling을 이용해 이 과정을 자동화할 수 있다.
기본 데이터베이스 서비스의 장애를 감지하고 AWS에서 실행되는 병렬 데이터베이스 서비스로 이관되기 위해 몇 가지 애플리케이션 로직이 필요할 수 있다.
이 시나리오의 비용은 정상 운영 중 AWS가 처리하는 생산 트래픽의 양에 따라 결정된다. 복구 단계에서는 트래픽을 사용한 만큼, 그리고 전체 재해 복구 환경을 사용한 기간에 대해서만 비용을 지불하면 된다.
"항시 작동하는" AWS 서버에 대해 예약 인스턴스를 구입하여 비용을 더욱 줄일 수 있다.
준비 단계 :
아래 그림에서 DNS를 사용하여 트래픽의 일부를 AWS 사이트로 라우팅하는 것을 볼 수 있다. AWS의 애플리케이션은 현장 생산 시스템의 데이터 원본에 액세스할 수 있다. 데이터는 AWS 인프라에 복제되거나 미러링된다.
준비 핵심 사항 :
- 생산 환경을 복제하도록 AWS 환경을 설정한다.
- DNS 가중치 또는 이와 유사한 기술을 설정하여 두 사이트에 전송되는 요청량을 분배한다.
복구 단계 :
아래 그림은 재해가 현장에 발생했을 때의 상황을 보여준다. 트래픽은 DNS 업데이트를 통해 AWS 인프라로 이관된다.
복구 핵심사항 :
- DNS 가중치를 변경하여 모든 요청이 AWS 사이트로 전송되도록 한다
- 로컬 AWS 데이터베이스 서버를 사용하도록 장애 조치에 대한 애플리케이션 로직을 구성한다.
- AWS의 규모를 적정하게 자동으로 조정하도록 Auto Scaling 사용을 고려한다.
다중 AZ 아키텍처를 설계하여 다중 사이트 솔루션의 가용성을 더 증가시킬 수 있다.
'AWS > 서비스 개념' 카테고리의 다른 글
| [AWS] AWS CloudFormation (0) | 2021.01.08 |
|---|---|
| [AWS] Amazon Kinesis Data Firehose (0) | 2021.01.08 |
| [AWS] Amazon VPC(Virtual Private Cloud) (0) | 2021.01.07 |
| [AWS] 재해복구(disaster recovery) (3) (0) | 2020.11.28 |
| [AWS] 재해복구(disaster recovery) (1) (1) | 2020.11.23 |
댓글