AWS에서 SQL Server를 위한 재해 복구 설계: 2부

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

이 블로그 시리즈 (1부, 2부, 3부, 4부)에서는 Amazon Elastic Compute Cloud (Amazon EC2)에서 운영 중인 SQL Server에서 고려할 수 있는 재해 복구 (Disaster Recovery, DR) 각 방안을 비교하고 설명합니다. 이번 글에서는 SQL Server의 기능 중 SQL Server의 자체 백업 및 복원, SQL Server 로그 전달 (Log Shipping), SQL Server 데이터베이스 미러링 (Database Mirroring)을 이용한 세 가지 재해 복구 구현 방안을 소개합니다.

SQL Server 백업 및 복원

고가용성 (High Availability, HA) 및 DR이 구성되어 있어도 실수로 데이터를 삭제하거나 데이터가 손상되는 등 데이터 복구에 실패할 경우를 대비해 백업은 여전히 필요합니다. 백업은 모든 DR 전략의 기본입니다. 백업 전략은 SQL Server 데이터베이스의 복구 모델 (Recovery Model)에 따라 달라집니다. 복구 모델은 SQL Server 내의 데이터베이스 속성이며, 트랜잭션이 기록되는 방식, 트랜잭션 로그의 백업 필요 여부 (혹은 가능 여부), 사용 가능한 복원 작업을 결정합니다.
데이터베이스의 복구 모델에 따라 SQL Server 에서는 다음 세 가지 유형의 백업이 가능합니다.

• 전체 백업 (Full Backup) – 데이터베이스 전체, 모든 데이터 파일을 백업하고, 복원 작업 후 데이터베이스를 복구하는 데 필요한 트랜잭션 로그를 백업합니다. 이 백업은 모든 복구 모델에서 지원됩니다.
• 차등 백업 (Differential Backup) – 가장 최근의 (마지막) 데이터베이스 전체 백업 이후 변경된 데이터 (Extents)를 백업합니다. 이 백업 방안 역시 모든 복구 모델에서 지원됩니다.
• 로그 백업 (Log Backup) – 트랜잭션 로그의 활성 부분을 백업합니다. 트랜잭션 로그 백업은 특히 OLTP (OnLine Transaction Processing) 성향의 데이터베이스에서 매우 중요합니다. 이를 통해 재해가 발생하기 직전 시점으로의 특정 시점 복구 (Point-In-Time Recovery, PITR)가 가능합니다. 이 백업은 전체 혹은 대량 복구 모델에서 지원됩니다.

RTO 및 RPO

SQL Server DR 방안으로 백업 및 복원 방안을 고려한 경우, 복원 프로세스의 최대 소요 시간 및 이에 따른 다운타임이 RTO (Recovery Time Objective)가 됩니다. RTO는 네트워크를 통해 백업 파일을 전송하는 데 필요한 시간과 백업 파일의 크기와 수를 결정하는 네트워크 처리량과 같은 여러 요소에 따라 달라집니다. 다수의 차등 및 로그 백업 파일이 있는 데이터베이스의 복구 시나리오에서 첫 번째 단계로 가장 최신의 전체 백업, 가장 최신의 차등 백업을 복원하고, 그리고 그 이후에 수행된 모든 로그 백업 파일을 복원해야 합니다. 일반적으로 RPO (Recovery Point Objective)는 로그 백업 간격에 의해 결정됩니다. 따라서 재해 복구를 위한 백업 전략을 설계할 때 로그 백업 실행 주기도 고려해야 합니다.

고려 사항

Amazon Simple Storage Service (Amazon S3)를 백업 스토리지로 고려할 수 있습니다. Amazon S3는 내구성이 뛰어난 겍체 스토리지 서비스로, 리전 내 또는 리전 간 복제 기능을 기본 제공합니다. Amazon S3 스토리지 클래스를 통해 백업 파일과 같이 자주 액세스하지 않는 데이터를 비용 효율적인 방식으로 보관할 수 있습니다. 또한 Amazon S3용 VPC 엔드포인트를 이용하면 AWS PrivateLink을 기반으로 한 VPC와 S3간에 프라이빗 연결을 구성할 수 있어 백업 파일을 안전하게 전송할 수 있습니다. 벡업 스토리지로 Amazon S3를 이용할 경우 안정성, 보안, 성능을 위해 VPC 엔트포인트 구성을 권장합니다.

SQL Server 백업 파일을 저장하는 또다른 옵션으로 Amazon FSx가 있습니다. FSx for Windows File Server 및 FSx for NetApp ONTAP은 백업 파일을 저장할 수 있는 완전관리형 공유 스토리지 서비스입니다. 하드웨어 또는 운영 체제 오류 발생 시 SQL Server의 백업 파일이 로컬 드라이브에 저장되어 있다면 복구에 훨씬 더 많은 시간이 소요됩니다. 반면에 백업 파일이 네트워크 공유 드라이브에 저장되어 있다면 즉시 다른 서버에서 해당 백업을 이용하여 복원 과정을 진행할 수 있습니다.

AWS를 DR 사이트로 사용하는 경우, AWS Storage Gateway를 데이터센터의 백업 스토리지로 구성해서 백업 파일을 S3 버킷으로 전송하는 것을 고려해 볼 수 있습니다.

또한, AWS System Manager에서 AWSSQLServer-Backup Automation document를 사용해서 프로세스를 자동화할 수 있습니다.

아키텍처

다음 다이어그램은 SQL Server의 자체 백업 및 복원 방안을 이용한 DR 아키텍처 예시를 보여줍니다.

그림: 백업 및 복원

이 그림에서는 온프레미스 데이터베이스의 전체, 차등 및 트랜잭션 로그 백업 파일을 EC2 인스턴스에 구성한 SQL Server 로 전송합니다. 이 때 백업 및 복원 프로세스의 속도를 높이기 위해 AWS Storage Gateway를 고려할 수 있습니다. AWS Storage Gateway를 이용하면 온프레미스에 거의 무제한의 스토리지를 제공할 수 있는 하이브리드 클라우드 스토리지 구성이 가능합니다. Storage Gateway는 네트워크 파일 공유를 제공하며 이를 SQL Server 백업의 대상 폴더로 사용할 수 있습니다. 백업 작업 속도를 높이기 위해 Storage Gateway에서 로컬 캐시를 구성할 수 있습니다. 이 캐시는 전체 백업 크기보다 크게 설정하는 것이 좋습니다. 캐시된 백업 파일은 VPN 이나 Direct Connect를 거쳐 S3 버킷에 원활하게 업로드됩니다.

이 버킷에서 전체, 차등 또는 트랜잭션 로그 백업 파일을 다운로드하여 파일 시스템으로 저장하면, EC2의 SQL Server로 복원할 수 있습니다. 따라서 AWS로 전환할 준비가 될 때까지 이 과정을 반복하면 온프레미스 데이터베이스와 클라우드 데이터베이스를 동기화 상태로 유지할 수 있습니다.

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

재해가 발생했다면, 복원 작업 (RTO)을 성공적으로 완료한 후 SQL Server 데이터베이스를 수동 장애 조치 (Failover)할 수 있습니다. 이를 재해 복구의 전략 중 하나로 사용할 수 있습니다.

백업은 자동 장애 복구 (Failback) 기능을 제공하지 않습니다. 데이터베이스를 일관된 상태로 만들려면, 데이터베이스 백업을 수동으로 복원해야 합니다.

특징

백업 및 복원 방안은 다음과 같은 이점이 있습니다:

• 간단하고 쉽게 구현할 수 있는 DR 기술
• 이 글에서 언급된 백업 유형은 모든 SQL Server 버전 및 에디션에서 지원
• 백업 파일을 여러 AWS 리전으로도 복사 가능

비용 최적화 고려 사항

AWS Storage Gateway를 사용하면 백업 파일을 Amazon S3에 저장하여 백업 작업을 간소화하고 스토리지 비용을 절감할 수 있습니다. 이 방안은 버전, 에디션과 관계없이 모든 SQL Server에서 이용할 수 있습니다.

SQL Server 로그 전달 (Log Shipping)

로그 전달은 재해 복구를 구현하는 데 사용할 수 있는 기술입니다. 로그 전달을 사용하여 현재 서비스 중인 온프레미스 SQL Server 데이터베이스 (Primary)의 트랜잭션 로그 백업을, EC2에 구성된 SQL Server 또는 Amazon RDS for SQL Server 인스턴스에 배포된 하나 또는 다수의 Secondary (Warm Standby) 데이터베이스로 보낼 수 있습니다. 로그 전달은 사용자 데이터베이스 기준으로 구성됩니다. Amazon RDS for SQL Server에서 로그 전달을 설정하려면 일부 스크립트의 수정이 필요할 수 있습니다.

RPO 및 RTO

로그 전달은 주 (Primary) 데이터베이스와 보조 (Secondary) 데이터베이스의 동기화 상태 차이가 있어, 일반적으로 재해 복구 솔루션으로 사용되지만 RTO와 RPO 요구사항이 유연할 때는 가용성 솔루션으로도 고려할 수 있습니다. 트랜잭션 로그 파일은 비동기식으로 전송되고 전체 내용을 보조 데이터베이스에 적용해야 해서 복제 지연이 커질 수 있습니다. 따라서 수 분의 RPO와 수 분에서 시간 단위의 RTO를 고려해야 합니다. 일정 시간의 지연이 필요한 DR 시나리오의 경우, 실시간으로 동기화되는 데이터베이스 미러링이나 Always On 가용성 그룹보다는 로그 전달이 보다 더 적합할 수 있습니다.

고려 사항

로그 전달을 이용할 때 다음 내용을 고려하시기 바랍니다

• 데이터베이스 복구 모델을 변경하지 마세요 (전체 ↔ 단순 혹은 대량로그). 복구 모델이 변경되면 트랜잭션 로그 체인이 끊겨 로그 전달이 정상 동작하지 않습니다
• 로그 전달에서 사용되는 것 이외의 다른 트랜잭션 로그 백업은 수행할 수 없습니다. 그렇게 하면 로그 전달 체인이 끊어집니다.
• 보조 데이터베이스에서 복원이 진행될 때 기존의 연결은 모두 중지됩니다. 복원 주기가 짧으면 짧을수록 기존 연결 중지의 간격도 빈번하게 됩니다. 보조 데이터베이스에서 복원 작업 중에 읽을 필요가 없는 경우 로그 전달을 충분히 활용할 수 있습니다.

아키텍처

다음 다이어그램은 온프레미스와 AWS간 로그 전달을 이용한 DR 아키텍처의 예시를 보여줍니다.

그림: 로그 전달

이 아키텍처에서는 온프레미스 데이터베이스가 주 데이터베이스로, EC2 인스턴스의 SQL Server 데이터베이스가 보조 데이터베이스로 하여, 주 데이터베이스에서 트랜잭션 로그 백업을 비동기적으로 전송하고 보조 데이터베이스에서 이를 복원하게 됩니다. 준비된 모든 로그 백업이 적용되면 수동 장애 조치 (Failover)를 수행하여 클라우드의 SQL Server를 주 데이터베이스로 전환할 수 있습니다.

AWS의 동일 리전에서 로그 전달을 구성하려는 경우는, 주 데이터베이스와 보조 데이터베이스의 인스턴스가 각각 별도의 가용 영역에서 실행하는 것이 좋으며, 선택 사항으로 로그 전달의 세부 정보를 추적하도록 모니터 인스턴스를 구성할 수 있습니다. 또한 AWS에서 다중 리전 DR을 구성하려는 경우, 서로 다른 두 리전에서 실행 중인 인스턴스 간에 로그 전달을 설정할 수 있습니다.

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

로그 전달은 주 서버에서 보조 서버로의 자동 장애 조치를 지원하지 않습니다. 주 데이터베이스를 사용할 수 없게 되면 보조 데이터베이스를 온라인 상태로 전환하여 수동으로 장애 조치 (Failvover)를 진행하게 됩니다. 장애 조치를 조정하는 별도의 모니터링 에이전트가 없으므로 이를 인지하고 관리하는데 노력이 필요합니다. 보조 서버에서 데이터베이스를 온라인 상태로 전환할 시점은 사용자가 결정해야 합니다.

장애 조치 후에는 기존 운영 환경의 데이터베이스가 더 이상 DR 데이터베이스와 동기화되지 않습니다. DR 전환 이후 장애 조치가 필요하다면 로그 전달을 다시 구성해야 합니다. DR 데이터베이스에서 전체 및 로그 백업을 수행하여 기존 운영 환경의 데이터베이스로 복원해야 합니다.

특징

로그 전달은 다음의 특징이 있습니다.

• 간편한 설정 및 관리
• 비교적 저렴한 솔루션
• 지연 복구 가능, 특정 시점으로의 복구 가능
• 별도의 Active Directory 혹은 Windows Server Failover Clustering 구성 불필요
• 다수의 보조 복제본 구성 가능
• 보조 데이터베이스를 STANDBY 상태로 전환하여 제한적으로 읽기 가능
• 다른 HA 및 DR 기술과 결합 가능
• Express Edition을 제외한 모든 Edition에서 구현 가능

비용 최적화 고려 사항

로그 전달은 SQL Server Web Edition 부터 구성 가능합니다. 설정과 운영은 비교적 간단하지만 관리 오버헤드가 발생할 수 있습니다. 또한 재해 발생 후 엔드포인트가 변경되어 운영의 복잡성이 증가합니다. 장애 복구 (Failback)를 위해서는 역방향으로 로그 전달을 처음부터 재구성해야 합니다.

SQL Server 데이터베이스 미러링 (Database Mirroring)

데이터베이스 미러링은 주 서버에서 보조 서버로 로그 레코드 스트림을 전송하는 방식으로 작동합니다. 데이터베이스 미러링에서는 이러한 서버를 주 (principal) 서버 와 미러 (mirror) 서버라고 합니다. 모든 데이터 수정은 주 서버에서 수행해야 합니다. 데이터베이스 미러링을 사용하면 미러 서버의 데이터베이스는 복원 모드 (Reconvering)에 있으며 클라이언트에서 액세스할 수 없습니다.

데이터베이스 미러링은 동기식 또는 비동기식 모드로 구성할 수 있으며, 보호 우선 모드 또는 성능 우선 모드로 불리기도 합니다. 동기식 데이터베이스 미러링인 보호 우선 모드에서 자동 장애 조치 (Failover)가 가능하며, 자동 장애 조치 구성을 위해서는 미러링 모니터 서버 (witness)가 필요합니다.

데이터베이스 미러링을 사용하여 SQL Server 데이터베이스를 위한 하이브리드 클라우드 환경을 구성할 수 있습니다. 이 경우, 주 데이터베이스는 온프레미스에서 실행되고 클라우드에 보조 데이터베이스가 구성됩니다. 데이터를 비동기식으로 복제하고, 전환할 준비가 되면 수동 장애 조치를 수행합니다. 이렇게 성능 우선 모드인 비동기 복제를 위해서는 Enterprise Edition이 필요합니다.
데이터베이스를 AWS로 장애 조치하여 마이그레이션한 후에, 고가용성 및 복원력을 위해 Always On 가용성 그룹 등을 사용하여 보조 복제본을 추가할 수 있습니다.

RPO 및 RTO

RPO는 주 서버와 미러 서버 간의 네트워크 대역폭 및 지연 발생 정도에 따라 달라집니다. 주 서버나 미러 서버에 부하가 많으면 복제 지연이 커질 수 있습니다. RTO는 미러 서버를 주 서버로 전환하는데 걸리는 시간에 따라 달라집니다. 데이터베이스 미러링은 분 단위의 RPO와 RTO를 제공합니다.

고려 사항

데이터베이스 미러링이 구성된 환경에서 쓰기 작업이 많은 워크로드를 실행하면 주 서버와 미러 서버 모두에서 데이터 변경 사항 (트랜잭션 로그)을 확인해야 하므로 성능에 영향을 미칠 수 있습니다. 또한, 미러링을 사용하면 인덱스 리빌딩과 같이 쓰기 작업이 많은 상황일 때 미러 서버에 더 많은 I/O 부하가 발생할 수 있습니다. 이를 반영한 스토리지 성능을 검토해야 합니다.

아울러 데이터베이스 미러링에 관련된 서버 간에 전용 네트워크가 있으면 좋습니다. 미러링에 참여 중인 서버가 다른 서버와 네트워크를 공유하고 있다면 미러링 통신에 사용할 수 있는 유효 대역폭이 줄어들 수 있어 동기화 성능에 영향을 미칠 수 있습니다. 따라서 대역폭이 높은 네트워크에서 데이터베이스 미러링을 구성하는 것이 좋습니다.

한 인스턴스에 여러 개의 사용자 데이터베이스가 있는 경우 각 데이터베이스를 개별적으로 미러링해야 합니다. 각 데이터베이스에 대해 다른 미러 서버를 선택할 수도 있지만, 하나의 애플리케이션에 속한 모든 데이터베이스에 대해 하나의 미러 서버를 선택하는 것이 가장 좋습니다. 인스턴스의 데이터베이스가 서로 다른 애플리케이션에 속하는 경우 각 데이터베이스에 대해 서로 다른 미러 서버를 선택할 수 있지만 구성이 복잡해 질 수 있습니다.

아키텍처

다음 다이어그램은 하이브리드 데이터베이스 미러링의 아키텍처를 보여줍니다.

그림: 데이터베이스 미러링

이 아키텍처에서는 EC2의 SQL Server 데이터베이스와 온프레미스 데이터베이스 간에 비동기 데이터베이스 미러링을 구성한 것으로 가정합니다. 주 데이터베이스는 트랜잭션에 대한 로그를 AWS 클라우드에 있는 미러 데이터베이스로 비동기적으로 전송합니다. 주 서버는 미러 서버의 동기화 신호를 기다리지 않고 클라이언트에 응답을 보냅니다. (미러 서버가 로그를 디스크에 기록할 때까지 기다리지 않고 주 서버의 트랜잭션이 커밋됩니다.)

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

보호 우선 모드 (동기식 미러링)와 미러링 모니터 서버 (witness)를 구성한 경우 필요에 따라 자동 장애 조치가 수행되어 데이터베이스 다운타임이 최소화됩니다. 미러가 주 데이터베이스가 되고 이전 주 데이터베이스가 미러의 역할을 맡습니다.

미러링 모니터 없이 동기식 미러링을 사용하는 경우 자동 장애 조치가 수행되지 않습니다. 이 경우 수동으로 장애 조치를 실행하여 미러 데이터베이스를 새로운 주 데이터베이스로 역할을 전환해야 합니다.

성능 우선 모드(비동기식 미러링)를 사용하는 경우, 자동 장애 조치를 제공하지 않습니다. 주 데이터베이스 장애 시 미러에 미처 도달하지 못한 트랜잭션이 있다면 이는 손실 될 수 있습니다. 데이터 손실 가능성을 인지하고 수동으로 강제 장애 조치를 실행해야 합니다.

주 데이터베이스가 정상화되면 자동으로 미러 역할로 전환됩니다. 그러나 미러링 세션은 일시 중단된 상태이므로 수동으로 미러링 세션을 다시 시작해야 합니다.

특징

데이터베이스 미러링에는 다음의 특이점이 있습니다:

• 자동 장애 조치 지원 (미러링 모니터 서버 구성시)
• 장애 조치를 위한 Windows Server Failover Clustering 구성 불필요

비용 최적화 고려 사항

SQL Server 데이터베이스 미러링을 이용하려면 Standard 혹은 Enterprise Edition이 필요합니다. 데이터베이스 미러링은 최신 버전에서 더 이상 제공되지 않는 것으로 언급되고 있으나 여전히 널리 사용하고 있습니다.

요약

이번 글에서는 AWS에서 SQL Server의 DR을 구현하기 위해 SQL Server 자체 백업 및 복원, SQL Server 로그 전달, SQL Server 데이터베이스 미러링 기술에 대해 설명했습니다. 다음 게시글에서는 SQL Server 장애 조치 클러스터링, SQL Server Always On 가용성 그룹, 분산 가용성 그룹 및 AWS에서 DR 사용 사례를 위한 여러 DR 기술 결합 사례에 대해 설명합니다.