[AWS] 재해복구(disaster recovery) (3)

데이터 복제

원격지에 데이터를 복제할 때, 고려해야 할 몇 가지 요인이 있다.

• 사이트 간의 거리 : 거리가 멀수록 일반적으로 지연 시간 및 / 또는 지터가 더 발생하기 쉽다.
• 이용 가능한 대역폭 : 연결 범위와 다양성
• 애플리케이션에 필요한 데이터 전송 속도 : 데이터 전송 속도는 이용 가능한 대역폭보다 낮아야 한다.
• 복제 기술은 네트워크를 효과적으로 사용할 수 있도록 병행해서 사용 가능해야 한다.

데이터 복제 시 두가지 주요 방법이 있다. 

 

동기 복제

데이터가 여러 위치에서 개별적으로 업데이트된다. 이 작업은 네트워크 성능과 가용성에 의존한다.

 

비동기 복제

데이터가 여러 위치에서 개별적으로 업데이트되지 않는다. 데이터는 네트워크 성능과 가용성이 허용하는 범위에서 전송되며, 애플리케이션은 데이터를 계속 작성한다. 이러한 데이터는 아직 완전히 복제되지 않을 수 있다.

 

많은 데이터베이스 시스템이 비동기 데이터 복제를 지원한다. 데이터베이스 복제본은 원격에 배치 가능하며, 복제본은 기본 데이터베이스 서버와 완전히 동기화될 필요는 없다. 이 점은 많은 시나리오에서 허용되는데, 이를테면 백업 소스 또는 보고/읽기 전용 사용 사례가 이에 해당한다.

 

AWS에서는 지역 내 가용 영역이 잘 연결되어 있으나, 물리적으로는 분리되어 있다. 예를 들어, "다중 AZ" 모드를 사용하는 경우 Amazon Relational Database Service는 동기 복제를 통해 2차 가용 영역에 데이터를 복제한다. 이렇게 함으로써 기본 가용 영역을 사용할 수 없게 될 경우에도 데이터 손실을 방지할 수 있다.

 

AWS 지역은 서로 완전히 독립되어 있으나, 액세스하고 사용하는 방식은 모두 같다. 고객은 서로 다른 대륙 간처럼 멀리 떨어진 위치의 재해를 해결하는 복구 프로세스를 만들 수 있다. 장거리 재해 복구 시 흔한 문제나 비용이 발생하지 않는다. 고객은 데이터와 시스템을 두 곳 이상의 AWS 지역에 백업하여 대규모 재해가 발생하더라도 서비스를 복구할 수 있다. 고객은 AWS 지역을 사용하여 작업 프로세스의 복잡성을 상대적으로 줄이고 전 세계 최종 사용자에게 서비스를 제공할 수 있다.

 

재해복구 계획의 개선

탄탄한 재해 복구 계획을 수립하기 위해서는 몇 가지 중요한 단계를 따라야 한다.

 

테스트

재해 복구 솔루션을 배치한 다음에는 테스트를 해야 한다. "게임 데이"는 재해 복구 환경에 장애 조치를 수행하는 날이다. 충분한 설명서를 준비하여 실제 상황이 발생했을 때 프로세스를 최대한 간소화하도록 한다.

AWS에서는 게임 데이 시나리오를 테스트하기 위한 복제 환경을 신속하고 비용 효율적으로 구성할 수 있으며, 일반적으로 기존의 생산 환경을 변경할 필요가 없다. AWS CloudFormation을 사용하여 AWS에 완벽한 환경을 배포할 수 있다.

이 서비스는 템플릿을 사용하여 AWS 리소스에 대해 설명하며, 전체 환경을 생성하기 위해 필요한 관련 종속성 또는 런타임 매개 변수에 대해서도 설명한다.

 

차별화된 테스트는 다양한 종류의 재해를 대비하고 있는지 확인하기 위한 중요한 요소이다. 다음은 "게임 데이" 시나리오 예이다.

• 특정 사이트와 컴퓨터 세트에 전력 손실 발생
• 단일 사이트의 ISP 연결 손실
• 핵심 비즈니스 서비스에 영향을 미치는 바이러스가 다중 사이트에 작용함
• 사용자의 실수가 데이터 손실을 야기하여 PIT(Point in Time) 복구가 필요하다

모니터링 및 경보

정기적인 점검과 충분한 모니터링을 실시하여 재해 복구 환경이 서버 장애나 연결 문제, 애플리케이션 문제 등으로 영향을 받았을 때 경고해 주어야 한다. Amazon CloudWatch 를 통해 AWS 리소스의 메트릭에 액세스할 수 있다. 경보는 어떤 메트릭에서든 정의된 임계값에 따라 설정할 수 있으며, 필요한 Amazon Simple Notification Service 메시지를 전송하여 예기치 않은 동작 발생에 대해 경고할 수 있다. AWS에서 어떠한 모니터링 솔루션이든 사용할 수 있다.

 

사용자의 회사가 인스턴스 메트릭뿐만 아니라 게스트 OS 통계 및 애플리케이션 상태를 모니터링하기 위해 사용하는 기존의 모니터링 및 경고 도구를 계속 사용할 수도 있다.

 

백업

재해 복구 환경으로 전환한 경우, 지속적으로 정기적인 백업을 해야 한다. 백업 및 복구를 정기적으로 테스트하는 것은 폴백 솔루션에 필수적이다.

 

AWS를 사용하면 재해 복구 인프라를 "항시 작동"할 필요 없이 저렴한 비용으로 자주 재해 복구 테스트를 수행할 수 있다.

 

사용자 액세스

AWS Identity and Access Management(IAM)을 사용하여 재해 복구 환경의 리소스에 안전하게 액세스할 수 있다.

이 방식으로 재해 복구 환경에서 작업하는 동안 사용자의 책임을 분리하는 역할/사용자 기반 보안 정책을 만들 수 있다.

 

자동화

구성 관리 또는 오케스트레이션 소프트웨어를 사용하여 AWS 기반 서버와 온 프레미스 서버에 애플리케이션 배포를 자동화할 수 있다. 자동화를 통해 두 환경 모두에서 애플리케이션 및 구성 변경 관리를 손쉽게 처리할 수 있다.

몇 가지 인기 있는 오케스트레이션 소프트웨어 옵션이 제공된다.

AWS CloudFormation 은 몇 가지 도구와 함께 작동하여 인프라 서비스를 자동으로 프로비저닝한다. 처음 부팅 시 사용자 데이터를 인스턴스로 전달하고, 인스턴스 유형 또는 역할을 결정하기 위해 구성 관리 도구로 이동시킬 수 있다.

이를 통해 정확한 소프트웨어 및 구성이 배포되었는지 확인한다. 자동화의 전반적인 목표는 인스턴스 상태가 변경되지 않도록 자동으로 유지하는 것이다.

 

Auto Scaling을 사용하여 인스턴스 풀의 규모가 CloudWatch에서 지정한 메트릭에 따른 수요량을 충족하기에 적합한지 확인할 수 있다. 재해 복구 측면에서 다시 말하면 사용자가 환경을 더 많이 사용하면 이러한 증가된 수요를 충족하도록 솔루션을 자동으로 확장할 수 있다는 것이다. 이벤트가 종료되고 사용량이 잠재적으로 감소하면 솔루션을 최소 수준의 서버로 다시 축소할 수 있다.

 

소프트웨어 라이선스와 재해 복구

AWS 환경에 대한 라이선스를 제대로 받았는지 확인하는 것은 다른 어떤 환경에 대한 라이선스를 받는 것 못지 않게 중요하다.

Amazon은 라이선스 관리를 용이하게 해주는 다양한 모델을 제공한다.

예를 들어, "Bring Your Own License"를 몇몇 소프트웨어 구성 요소 또는 운영 체제에서 사용할 수 있다.

또는 라이선스 비용이 시간당 요금에 포함되어 있는 소프트웨어군도 있다. 이를 "License included"라고 한다.

"Bring Your Own License"는 재해 시, 기존의 소프트웨어 투자 요소를 활용할 수 있다. "License included"는 재해 복구 테스트 기간과 같이 매일 사용하지 않는 재해 복구 사이트에 대한 사전 라이선스 비용을 최소화한다.