AWS에서 SQL Server를 위한 재해 복구 아키텍처 설계: 4부

 이 글은 AWS Database Blog에 게시된 Architect a disaster recovery for SQL Server on AWS: Part 4 by Ganapathi Varma Chekuri and Baris Furtinalar을 한국어 번역 및 편집하였습니다.

이 블로그 시리즈 (1부, 2부, 3부, 4부)에서는 Amazon EC2(Amazon Elastic Compute Cloud)에서 SQL Server에 사용할 수 있는 각각의 재해 복구(DR) 솔루션을 비교하여 장단점을 알아보고 AWS에서 SQL Server 워크로드용 DR을 구현하는데 드는 비용과 복잡성을 이해하는 데 도움을 드리고자 합니다. 이번 글에서는 AWS에서 SQL Server 용 DR을 구현하기 위한 두 가지 추가 방법을 소개합니다. AWS Database Migration Service(AWS DMS)와 AWS Elastic Disaster Recovery(AWS DRS)를 이용하는 방안입니다. 마지막으로는 지금까지 언급한 모든 방안을 정리하여 AWS에서 구현할 수 있는 SQL Server 용 DR 옵션에 대한 전체적인 관점을 제공하고자 합니다.

AWS Database Migration Service

AWS DMS는 AWS 내의 동일 리전뿐만 아니라 다른 리전으로의 데이터 실시간 마이그레이션을 지원합니다. 이 기능을 사용하여 다른 리전에서 별도의 SQL Server 인스턴스를 구성하여 DR 데이터베이스로 사용할 수 있습니다. 로그 전달(Log Shipping) 및 Always On 가용성 그룹(AG)과 같은 기능을 이용하여 EC2에서 동작하는 SQL Server의 DR 사이트를 설정할 수도 있지만, AWS DMS는 보다 저렴하면서 단순하고, 클라우드 네이티브 방식을 제공합니다. AWS DMS는 원본 데이터베이스에서 발생하는 데이터 변경 사항을 대상 데이터베이스에 자동으로 복제하는 등 마이그레이션 프로세스의 복잡성을 관리합니다. AWS DMS는 전체 로드 마이그레이션과 변경 데이터 캡처(CDC)를 지원하여 지속적인 데이터 복제를 가능하게 합니다. 데이터베이스 인스턴스 수준에서 작동하는 물리적 복제와 달리, AWS DMS는 논리적 복제 솔루션으로 스키마 또는 테이블처럼 데이터베이스의 하위 집합 기준으로 마이그레이션할 수 있다는 장점도 있습니다

RPO 및 RTO

AWS DMS를 이용한 DR 전략의 Recovery Point Objective(RPO)는, AWS DMS가 원본 SQL Server 인스턴스에서의 변경 사항을 얼마나 빨리 파악하여 대상에 적용하는지에 따라 달라집니다. 이 방안은 대상 SQL Server가 동작 중에 있으므로 Recovery Time Objective(RTO)가 거의 0에 가까워질 수 있습니다.

고려 사항

• 복제가 진행되는 동안 원본 데이터베이스 시스템과 AWS DMS 복제 인스턴스 간의 네트워크 대역폭을 파악하는 것이 중요합니다. 복제가 진행되는 동안 네트워크가 병목 현상을 일으키지 않는지 확인해야 합니다.
• 원본 데이터베이스 시스템에서 시간당 변경 속도와 트랜잭션 로그 생성량을 파악하는 것도 중요합니다. 이렇게 하면 복제를 진행하는 동안 고려해야 할 처리량을 이해하는 데 도움 됩니다.
• 여러 개의 복제 작업을 동시에 실행하려는 경우, 큰 크기의 복제 인스턴스 하나를 사용하는 것이 좋습니다. 복제 서비스는 상당한 양의 메모리와 CPU를 소비하므로 인스턴스를 크게 사용하는 것이 좋습니다.
• 지속적인 데이터 복제를 사용하려는 경우. 복제 인스턴스의 Multi-AZ 옵션을 설정하세요. Multi-AZ를 선택하면 복제 인스턴스에 대한 고가용성 및 장애 조치가 가능합니다. 그러나 이 옵션은 성능에 영향을 미칠 수 있으며 대상 시스템에 변경 사항을 적용하는 동안 복제 속도가 느려질 수 있습니다.
• 원본 데이터베이스가 Always On AG로 구성되었고 Second Replica에서 백업을 수행한다면, 아울러 AWS DMS가 이 백업 파일에서 데이터 변경 분을 읽어 대상 환경으로 복제하는 경우, 추가로 고려해야 할 연결 속성이 있습니다. 모든 노드에서 백업 파일을 확인하는 과정을 비활성화하면 예기치 않은 복제 작업 실패를 예방할 수 있습니다. 이를 위해서는 엔드포인트 연결 설정에 다음 속성을 추가합니다:

alwaysOnSharedSynchedBackupIsEnabled=false;

※ 연결 속성과 관련한 추가 사항은 Endpoint settings when using SQL Server as a source for AWS DMS를 참고하세요

AWS DMS 복제 성능과 관련하여 추가 상세 사항은 AWS DMS 마이그레이션 성능 개선을 참조하세요.

아키텍처

다음 다이어그램은 AWS DMS를 이용한 DR 전략의 아키텍처를 보여줍니다.

그림: Database Migration Service

이 방안에서는 먼저, AWS 계정에서 AWS DMS 인스턴스를 생성합니다. 이후 온프레미스 및 AWS 데이터베이스 인스턴스 모두에 연결할 수 있는 데이터베이스 연결 정보를 작성합니다. 그런 다음 마이그레이션할 테이블, 스키마 또는 데이터베이스를 선택하면 AWS DMS가 데이터를 초기 로딩하고 지속적으로 동기화 상태를 유지합니다. 마지막으로, 전환할 준비가 되면 기존 온프레미스 데이터베이스 대신 동기화된 AWS 데이터베이스로 연결하도록 애플리케이션 구성을 변경하기만 하면 됩니다.

장애 조치(Failover) 및 장애 복구(Failback)

AWS DMS의 장애 조치는 수동으로 진행됩니다. 원본 데이터베이스와 대상 데이터베이스가 동기화되고 애플리케이션이 컷오버 준비가 되면 복제 작업이 중지되고 애플리케이션이 Amazon EC2에서 실행 중인 SQL Server에 연결되도록 변경하면 됩니다.
장애 복구가 필요한 경우, 기존 운영 데이터베이스가 더 이상 DR 데이터베이스와 동기화되지 않고 있으므로 DR 전환 후 대상 데이터베이스에서 발생한 모든 변경 사항은 본 데이터베이스에 수동으로 재 반영하거나 혹은 데이터 손실을 무시하게 됩니다.
필요하다면 DR 데이터베이스에서 원본 데이터베이스로 복제 작업을 다시 구성해야 합니다.

특징

이 방안에는 다음과 같은 이점이 있습니다:

• 간편한 사용
• 다운타임 최소화하는 마이그레이션
• 널리 사용되는, 다양한 데이터베이스 엔진 지원
• 서로 다른 SQL Server 에디션 및 버전 간 복제 허용
• 서로 다른 AWS 계정 간 복제 허용
• 지속적인 복제로 데이터 손실 위험 감소
• 높은 복원력 및 자가 복구 기능

비용 최적화 고려 사항

AWS DMS는 비용 효율적인 서비스입니다. 데이터 마이그레이션(혹은 동기화) 중에 이용되는 복제 인스턴스의 컴퓨팅 리소스와 부가적인 로그 스토리지에 대한 비용만 고려하면 됩니다. SQL Server에서 읽기 워크로드의 분산을 위해 보조 복제본이 필요한 경우 일반적으로 Enterprise Edition을 검토하게 됩니다. AWS DMS를 사용하면 Standard Edition이어도 동기화된 복제본을 구성할 수 있어 라이선스 비용을 절감할 수 있습니다.

AWS Elastic Disaster Recovery

로그 전달, Always On AG 그리고 AWS DMS와 같은 다양한 옵션을 사용하여 SQL Server 데이터베이스에 대한 재해 복구를 설정할 수 있습니다. 그러나 이러한 옵션들은 인프라는 물론 운영 체제 및 SQL Server와 같은 소프트웨어가 구성되는 노드 수에 따라 필요하므로 비용이 제법 많이 드는 IT 프로젝트이면서 유지 관리에 어려움이 있습니다. 큰 비용이 필요한 것 외에도 이 방안에는 시스템 전체 대한 재해 대응이 아닌 일부 요소인 데이터베이스만 복제한다는 단점이 있습니다. 이에 반해, AWS Elastic Disaster Recovery (AWS DRS)는 서버의 복제를 관리하는 서비스형 소프트웨어 (SaaS)로서 모든 인프라에서 AWS로 DR 구성을 위한 복제를 관리합니다.

AWS DRS는 운영 체제는 물론, 그 위에 설치된 모든 응용 프로그램 및 데이터베이스를 포함한 전체 가상 머신을 스테이징 영역에 복제하는 에이전트 기반 솔루션입니다. 스테이징 영역에는 AWS DRS가 자동으로 프로비저닝하고 관리하는 낮은 비용의 리소스가 존재합니다. 따라서 중복 리소스를 프로비저닝하는데 드는 비용을 크게 절감할 수 있습니다. 스테이징 영역에서는 워크로드의 라이브 버전을 실행하지 않으므로 중복 소프트웨어 라이선스나 고성능 컴퓨팅에 대한 비용을 지불할 필요가 없습니다. 대신 저렴한 컴퓨팅과 스토리지에 대한 비용만 지불하면 됩니다. 복구된 워크로드에 필요한 적절한 크기의 컴퓨팅과 고성능 스토리지를 갖춘 완전 프로비저닝된 복구 환경은 재해 또는 훈련 중에만 실행됩니다.

RPO 및 RTO

AWS DRS는 원본 머신의 내용을 스테이징 환경에 지속적으로 복제하여 장애 발생 직전의 마지막 일관된 상태로 장애 조치할 수 있으므로 수 초의 RPO 및 수분의 RTO가 가능해집니다.
따라서 AWS DRS로 SQL Server 데이터베이스가 동작 중인 각 원본 머신을 복제하면, 재해 발생 시에 각 단일 EC2 인스턴스로 복구하여 수 초의 RPO 및 수 분의 RTO를 만족하는 장애 조치가 이루어집니다.

고려 사항

DR 계획을 실제로 테스트해야 하지만 종종 소홀히 하는 경우가 많습니다. 장애 조치 절차가 너무 복잡하고, 장애 조치 테스트가 프로덕션 환경의 중단이나 데이터 손실로 이어질 수 있다는 우려 때문에 많은 조직이 정기적으로 테스트하지 않습니다. 이러한 우려에도 불구하고 DR 사이트에 대한 정기적인 장애 조치 테스트를 수행하는 것은 중요합니다. 고도로 자동화된 AWS DRS 솔루션을 사용하면 원본 환경에 영향을 주지 않고 대상 리전에서 SQL Server 데이터베이스 및 기타 모든 워크로드를 실행하는 무중단 복구를 빠르고 쉽게 수행할 수 있습니다.

SQL Server Always On AG에서 AWS DRS를 이용하여 DR 사이트를 구성하는 방법은 How to set up disaster recovery for SQL Server Always On Availability Groups using AWS Elastic Disaster Recovery을 참고하시기 바랍니다.

아키텍처

다음 다이어그램은 AWS DRS를 이용한 DR 아키텍처를 보여줍니다.

그림: AWS DRS

이 시나리오에서 AWS DRS는 온프레미스 원본 서버의 데이터를 대상 리전의 스테이징 영역에 지속적으로 복제합니다. 스테이징 영역은 지속적인 복제 유지 관리에 합리적인 스토리지 및 최소한의 컴퓨팅 리소스 사용으로 비용을 절감합니다. DR 테스트를 위해 복제된 서버를 시작할 때 적절한 시점의 스냅샷으로 지정한 VPC, 서브넷, 인스턴스 및 봄륨 유형 등 시작할 테스트 인스턴스의 설정 및 구성을 정의하는 시작 템플릿을 조정할 수 있습니다. 다만 장애 조치 테스트인 경우 네트워크 충돌을 피하기 위해 별도의 서브넷 또는 다른 보안 그룹을 사용하여 인스턴스를 격리하는 시작 템플릿을 사용하는 것이 좋습니다. 실제 DR 이벤트로 인해 복구를 시작하는 경우, 프로덕션 요구 사항을 충족하는 적절한 버전의 시작 템플릿을 선택했는지 확인하세요.

장애 조치(Failover) 및 장애 복구(Failback)

원본 인프라와 DR 대상 리전이 연속 복제 모드로 완전히 동기화되면, 복구 모드로 장애 조치를 시작하거나 복구 테스트를 수행하도록 선택할 수 있습니다. 장애 조치(Failover)를 트리거하면 AWS DRS는 Amazon EC2 API를 사용하여 새 대상 인스턴스를 지정한 VPC에서 시작합니다. 이후 EC2 API를 사용하여 새 Amazon EBS 볼륨을 해당 인스턴스에 연결합니다. AWS DRS는 복제된 데이터를 저장하는 스테이징 영역의 볼륨에서 가져온 Amazon EBS 스냅샷을 사용하여 새 타겟 볼륨을 생성합니다.
실제 DR의 경우, AWS DRS는 고도로 자동화된 머신 전환 프로세스와 확장 가능한 오케스트레이션 엔진을 트리거하여 대상 리전의 머신을 몇 분 내에 가동할 수 있습니다. 이 프로세스를 통해 수 분 안에 RTO를 달성할 수 있습니다.
재해가 종료되면 AWS DRS는 원래 원본 서버 환경으로 자동화된 장애 복구(Failback) 프로세스를 제공합니다. 장애 복구는 대상 리전에서 실행 중인 워크로드를 데이터 손실 없이 원본 환경으로 전환합니다.

특징

AWS DRS를 사용하면 다음과 같은 이점이 있습니다:

• 모든 SQL Server 버전 및 에디션, 타사 소프트웨어 및 운영 체제를 위한 단일 재해 복구 솔루션
• 크래시 일관성(Crash-consistent) 기술로 데이터 일관성 100% 유지
• DB 인프라를 미리 구축할 필요가 없음
• DR 비용 대폭 절감
• 초 단위의 RPO 및 분 단위의 RTO
• 네트워크 불안정성에 대한 안정성 및 높은 내성 향상
• 온프레미스의 물리적 및 가상 인프라, 기타 퍼블릭 클라우드, 다른 리전을 포함한 모든 원본 인프라 지원
• 엔터프라이즈급 보안

비용 최적화 고려 사항

DR 머신은 바로 시작되지 않으며, 중복 소프트웨어 라이선스나 고성능 컴퓨팅에 대한 비용을 지불할 필요가 없습니다.
스테이징 영역에는 저비용 EBS 볼륨이 포함되어 있어 중복 리소스를 프로비저닝하는데 드는 비용이 절감됩니다.

요약

재해 복구 솔루션의 선택은 요구 사항과 예산은 물론, 이용하는 SQL Server의 버전과 에디션에 따라 달라집니다. 일부 사용 사례의 경우처럼 여러 DR 기술을 결합하는 것이 유리할 수 있습니다. DR 기술을 테스트하고 이러한 기술을 프로덕션 환경에 구현한 후 정기적으로 장애 조치 및 장애 복구 테스트를 수행하여 문제를 찾아서 해결하고 원하는 RTO 및 RPO 값을 충족하는 것이 중요합니다.
다음 표에는 Amazon EC2에서 SQL Server 용 DR 기술을 사용하여 달성할 수 있는 RPO 및 RTO 메트릭이 요약되어 있습니다.

* 장애 조치나 장애 복구가 자동으로 이루어지지 않으나, 그 절차가 마련되어 있고 이를 위한 추가 구성이나 설정이 필요하지 않습니다.
**장애 조치 후 데이터베이스에 연결하려면 애플리케이션에서 데이터베이스 연결 정보 변경이 필요한지를 의미합니다.
***거의 0에 가까우나 소프트웨어 제조사에서 이를 보장하지는 않습니다.

+ 여기에는 DR 전환 시 필요한 시간은 포함되어 있지 않습니다 – 일반적으로 워크로드에 따라 몇 밀리초에서 몇 분 정도 소요될 수 있습니다.

이번 블로그 시리즈에서는 AWS에서 운영 중인 SQL Server의 DR 기능을 강화하는 방안들에 대해 설명했습니다. 특정 시나리오에서 원하는 비즈니스 목표를 달성하기 위한 몇 가지 DR 기술 및 사용 사례를 소개했습니다.
향후 Amazon RDS for SQL Server에 대해서도 동일한 내용을 전달하고자 합니다.