[aws 패턴] aws 백업 알아보기 - 장애대비편(가용성 확보, 장애대비 오프사이트 구성 등)

개인 aws study note입니다.

수정이 필요하거나 다른 의견은 댓글로 남겨주세요.

(무단 복제 및 배포를 금함)

AWS 백업/오프사이트로 장애 대비 & 운용효율성 & 가용성 확보하기

 

 

 

장애 대비편

비즈니스 운영 방향에 따라 장애 발생 시 어떻게 대응할 지 구축 단계에서 설계하게 된다. 대부분 장애는 내부적인 원인이거나, 드물게 지진/홍수 등과 같은 자연 재해가 원인이다. 즉, 특정 리전 내에 원인이 있기 때문에, 지리적으로 떨어진 offsite에 백업을 구성한다. 오프사이트에 동일한 시스템 구성으로 리전 간 중복성을 가져가 메인사이트에서 장애 발생 시, 오프사이트가 그 역할을 바로 대체할 수 있도록 하는 것이다. 다음으로 백업사이트로의 전환 방법을 결정해야 하는데, 직접 전환하는 수동 전환 방식과 자동으로 전환되는 자동 전환 방식이 있다.

 

---

수동 전환 방식

자동 전환 방식과 가장 큰 차이는 수동으로 전환하는 것이기 때문에 다운타임이 발생한다는 것이다. 비즈니스 운영방향에 있어(ex 실시간 서비스가 아닐 경우) 어느정도의 장애시간을 가져갈 수 있다면 비용측면을 고려하여 수동 전환 방식을 사용할 수 있다.

 

이 방식의 전제 조건은 메인사이트와 백업사이트의 시스템 구성을 동일하게 구축해놓는 것이다. 평상시에는 백업사이트를 운영하지 않으므로, 비용 절감 측면에서 강점을 가진다. 

 

메인 사이트왇 동일한 구성의 오프사이트, 장애 발생 시 AMI와 S3에서 동기화/재기동 되어 정상화 될 수 있도록 구성

 

메인 사이트 -> 백업 사이트

aws console이나 AWS CLI를 통해 스냅샷을 지시하여, 메인 사이트에서 스냅샷을 생성하고 이를 오프사이트의 S3로 복사하는 작업을 스크립트로 작성하여 정기적으로 백업할 수 있도록 셋팅해야 한다.(그래야 백업사이트로 서비스 운영 시 데이터 동기화 유지) 

S3의 경우, 크로스 리전 복제 기능을 사용하여 백업사이트로 데이터 동기화를 수행해주면 된다. 

 

백업 사이트

스냅샷으로부터 데이터를 복원 하여 서비스를 정상화 해야한다. 평소에는 정지상태이기 때문에, 시스템을 기동하는데 시간이 소요된다.(이 구성으로 백업사이트를 운영할 경우 다운타임 감안 해야 함, 물론 비용은 더 저렴하다) 

 

 

 

 

자동 전환 방식

자동 전환 방식은 [aws 패턴] 가용성 확보하기에서 다뤘던 라우트53의 DNS failover기능을 사용하는 것이다.

 

(참고)

3. 백업사이트(Off Site)에 재해 복구 구현하기(자동/수동)

 3-1. Route53을 통한 자동 전환 / Region 간 데이터 백업

 

https://ysuekkom8915.tistory.com/30

[aws 패턴] 시나리오별 설계/구축 - 가용성 확보하기

 

라우트53이 ELB의 상태를 감시하게 되고(감시 모니터링 지표는 위 포스팅 1-1-1. EC2 인스턴스 지표 링크 확인), 메인 사이트의 서버다운을 감지했을 경우 자동으로 백업사이트의 ELB로 연결하여 서비스를 재개하는 방식이다. 

 

라우트53의 DNS Failover 방식은 메인 사이트와 백업 사이트간 동일한 구성&데이터(RDS)가 동기화 되어있다는 것을 전제로 한다. 

(데이터 동기화 방식은 애플리케이션에 따라 다르다.)

 

RDS 는 Cross-Region Read Replicas 기능을 사용하여, 다른 지역에 읽기 전용 복제본을 만든다. 

오프사이트에서 읽기 전용의 RDS를 구성하여, 메인 사이트의 RDS에 대한 복제본이다. 리전간 가용성을 높이기 위한 서비스이다. 

장애 시 읽기 전용 복제본의 마스터 승격 기능으로 오프사이트에서 동기화된 데이터를 가지고 서비스를 이어받는다. API(PromoteDBCluster)가 실행되면, 오프사이트의 읽기 전용 복제본은 마스터로 승격 되고, Replica를 중지한 뒤 독립인 Master RDS로 동작하게 된다. 

마스터로 승격되는데 까지 시간이 소요되므로, 클라우드워치 서비스를 함께 이용해야 한다. 클라우드워치의 임계치설정/모니터링/알람 기능을 이용하여 임계치에 도달하면 CloudWatch Events를 사용, Lamda가 마스터로 승격시키는 API를 호출한다. 

 

S3 는 CrossRegionReplication 기능으로 메인 사이트와 백업 사이트간 데이터 동기화를 수행한다. S3의 Bucket(버킷)에 파일을 보관하게 되는데, 이 버킷 단위로 관리가 이루어지기 때문에, 백업 조건이 다를경우 각각 다른 버킷으로 관리해야 한다. (aws console에서 리전 간 복제기능을 활성화하여 사용한다.)

 

EBS 는 실시간 복제 기능이 없기 때문에, 스냅샷을 이용하여 저장해야 한다. 정기적으로 스냅샷을 찍어서 백업 사이트로 복사하는 방법과(정기적으로 스냅샷 후, 복사할 수 있도록 스크립트이용), 데이터 동기화 도구를 이용하여 디스크 내용을 실시간으로 동기화하는 방법이 있다. EBS 스냅샷을 이용하여 백업하는 방법은 AWS 공식문서를 참고하고, 다음 포스팅에서 자세히 다뤄보겠다.

 

 

---

aws는 알다시피 공동책임 모델이다.  즉, 장애가 발생하여도 공동으로 책임을 지는 개념인데, 제공받는 서비스(ex. 관리형 서비스이냐 아니냐 등등)에 따라 책임 범위가 달라진다. 가장 중요하게 다가올 수 있는 데이터의 보안 책임 범위가 사용자에게도 있다는 것이다. 

따라서, AWS에서 제공하는 수많은 서비스들을 활용하여(ex. CloudWatch, CloudTrail 등), 운영 시 대응하는 것이 필수적이다.  

 

 

다음 포스팅에서는 온프레미스의 데이터를 AWS로 백업, AWS에서 운영중인 시스템을 AWS에 백업하는 것에 대해 알아보겠다.