AWS에서 SQL Server의 재해 복구 아키텍처 설계: Part3

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

블로그 시리즈(1부, 2부, 3부, 4부)에서는 Amazon Elastic Compute Cloud (Amazon EC2)에서 동작하는 SQL Server에서 고려할 수 있는 재해 복구(DR) 각 방안을 비교하고 설명합니다.
이번 글에서는 AWS에서 SQL Server의 기능 중 SQL Server Always On 장애 조치 클러스터 인스턴스(FCI), Always On 가용성 그룹, 분산 가용성 그룹, 그리고 일부 기술의 일반적인 조합을 소개합니다.

SQL Server Always On Failover Clustering Instance

SQL Server Always On 장애 조치 클러스터 인스턴스(Failover Clustering Instance, FCI)는 WSFC(Windows Server 장애 조치 클러스터링) 노드 및 여러 서브넷에 걸쳐 설치 되는 SQL Server의 단일 인스턴스입니다. 네트워크에서 FCI는 단일 컴퓨터에서 실행되는 SQL Server 인스턴스로 보이지만, 현재(엑티브) 노드를 사용할 수 없게 되는 경우 한 WSFC 노드에서 다른 노드로 장애 조치를 제공합니다. SQL Always On 장애 조치 클러스터의 일반적인 설치는 사용자 및 시스템 데이터베이스를 위한 공유 스토리지가 있는 동일한 데이터 센터의 두 노드로 구성됩니다. 이러한 설정에서 솔루션은 SQL Server 인스턴스에 고가용성(HA)을 제공하도록 설계되었습니다.

AWS에서는 모든 워크로드에 대해 고가용성을 높이기 위해 여러 가용 영역을 사용하는 아키텍처를 권장합니다. 이러한 가용 영역은 서로 간에 높은 대역폭과 짧은 대기 시간 링크를 제공합니다. 즉, 하나의 프라이머리 데이터 센터에서 실행하던 것과 동일한 두 노드 SQL Server 장애 조치 클러스터를 한 노드는 하나의 가용 영역에, 다른 노드는 같은 리전의 다른 가용 영역에서 실행할 수 있습니다. 가용 영역 간 고성능 링크는 성능 저하 없이 여러 가용 영역에서 클러스터를 실행할 수 있다는 것을 의미하며, 따라서 SQL 설정에서 HA와 DR을 동시에 달성할 수 있습니다.

멀티 서브넷 SQL Server 장애 조치 클러스터에서는 여러 데이터 센터에 걸쳐 확장할 수 있는 스토리지가 필요합니다. 이는 Amazon FSx for Windows File Server 를 사용하여 구성 할 수 있습니다. FSx for Windows File Server는 서비스 메시지 블록(SMB) 프로토콜을 통해 액세스할 수 있는 Windows Server에 구축되는 완전관리형 파일 스토리지입니다. Amazon FSx 공유는 Multi-AZ 옵션으로 두 개의 가용 영역에 배포할 수 있으며, 지속적으로 사용 가능한 (Continuously Available, CA) 파일 공유를 지원하여 SQL Server 데이터베이스를 위한 공유 스토리지로 최적화할 수 있습니다. 이 스토리지를 이용하면 SQL Server 인스턴스에 이중화 구성이 가능할 뿐만 아니라 데이터베이스 파일을 여러 가용 영역에 저장하여 SQL Server가 이용하는 스토리지의 내구성을 높여줍니다.

RPO 및 RTO

Amazon EC2에서 SQL Server 장애 조치 클러스터 설정에 대한 복구 시간 목표(RTO)는 다른 노드로 장애 조치하는 데 걸리는 시간입니다. 일반적으로 이것은 자동 장애 조치이며, 장애 조치 시간은 장애 조치 시점에 활성 트랜잭션에 의해 수정된 데이터의 양에 따라 크게 달라집니다.
SQL Server 장애 조치 클러스터를 사용하려면 모든 데이터베이스는 공유 스토리지에 위치 합니다. 따라서 SQL Server 장애 조치 클러스터 설정의 복구 지점 목표(RPO)는 스토리지 솔루션에 따라 다르며 이론적으로는 0입니다.

고려 사항 

SQL Server는 SMB 파일 공유를 활성 데이터 파일의 스토리지 옵션으로 배포할 수 있습니다. Amazon FSx는 지속적으로 사용 가능한(CA) 파일 공유를 지원하여 SQL Server 데이터베이스용 공유 스토리지 제공에 최적화되었습니다. 이러한 파일 공유는 공유 파일 데이터에 중단 없이 액세스해야 하는 SQL Server와 같은 애플리케이션을 위해 설계되었습니다. Single-AZ 2 파일 시스템에서도 CA 공유를 생성할 수 있지만, HA 여부 관계없이 모든 SQL Server 배포에는 Multi-AZ 파일 시스템에서 CA 공유를 사용해야 합니다.

Windows Server 장애 조치 클러스터 배포에서는 일반적으로 클러스터 리소스의 쿼럼을 유지하기 위해 SMB 파일 공유 감시(File Share Witness)를 이용할 수 있습니다. 파일 공유 감시에는 쿼럼 정보를 위한 소량의 저장소만 필요합니다. Amazon FSx 파일 시스템을 Windows Server 장애 조치 클러스터 배포를 위한 SMB 파일 공유 감시로 사용할 수도 있습니다.

아키텍처

다음 다이어그램은 AWS의 SQL Server Always On 장애 조치 클러스터 인스턴스에 대한 아키텍처를 보여줍니다.

그림: SQL Server Always On 장애 조치 클러스터

이 시나리오에서 처럼 이미 AWS에서 SQL Server 장애 조치 클러스터를 사용하고 있는 경우, 여기에 참여하는 모든 노드는 액세스할 수 있는 공유 스토리지가 필요합니다. FSx for Windows File Server는 두 개의 가용 영역에서 데이터를 동기식으로 자동 복제하고, 자동 장애 감지, 장애 조치(Failover) 및 장애 복구(Failback)을 통해 고가용성을 제공하며, SMB CA 기능을 완벽하게 지원하는 공유 스토리지를 제공하는 완전 관리형 서비스입니다. 이를 통해 SQL Server 장애조치 클러스터 구성을 간소화하고 Amazon FSx를 SQL Server 장애조치 클러스터용 스토리지 티어로 사용할 수 있습니다. 자세한 내용은 Simplify your Microsoft SQL Server high availability deployments using Amazon FSx for Windows File Server를 참조하세요.

온프레미스에서 SQL Server FCI와 Always On AG의 조합으로 고가용성 및 재해 복구를 모두 만족하는 경우, AWS에 위치한 SQL Server FCI로 이동할 수 있습니다. 이를 통해 별도의 HA 및 DR 솔루션을 이용하지 않고도 비용을 더욱 절감하고 배포를 단순화할 수 있습니다.

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

SQL Server 장애 조치 클러스터는 재해 발생 시 SQL Server 인스턴스의 자동 장애 조치를 지원합니다. 또한 장애 복구 후 SQL Server 인스턴스의 자동 장애 복구도 지원합니다.

특징

이 솔루션에는 다음과 같은 이점이 있습니다:

• SQL Server Standard Edition 및 Enterprise Edition에서 지원됩니다.
• 모든 사용자 및 시스템 데이터베이스는 SQL Server 인스턴스 수준에서 보호됩니다.
• Amazon FSx를 공유 스토리지로 사용하면 완전 관리형 및 완전 복제형 Multi-AZ 스토리지를 사용할 수 있습니다.
• 장애 조치 및 장애 복구 작업은 자동적이며 간단합니다

비용 최적화 고려사항

SQL Server 장애 조치 클러스터 솔루션을 실행하려면 SQL Server Standard Edition 또는 Enterprise Edition이 필요합니다. 또한 이 기술은 설정 및 운영을 위해 Microsoft Active Directory에 의존합니다. 다른 HA 및 DR 기술에 비해 SQL Server 장애 조치 클러스터 시스템 및 사용자 데이터베이스를 위한 공유 스토리지도 필요하므로 솔루션의 복잡성과 총소유비용(TCO)도 증가합니다.

SQL Always On Availability Group

SQL Server Always On 가용성 그룹은 주(Primary) 서버에서 보조(Secondary) 서버로 로그 레코드 스트림을 전송하는 방식으로 작동합니다. 가용성 그룹에 있는 데이터베이스에서 모든 데이터 수정은 주 복제본(Primary Replica)에서 수행됩니다. 가용성 그룹 구성에서 보조 데이터베이스에 대한 읽기 전용 엑세스를 활성화한 경우, 클라이언트는 보조 복제본(Secondary Replica)에서 데이터를 액세스하고 읽을 수 있습니다. 이는 동기 또는 비동기 커밋 모드에서 모두 이용 가능합니다. 동기 커밋(Synchronous-commit) 모드는 보조 복제본으로 전달된 로그가 커밋 완료될 때까지 주 복제본의 트랜잭션은 대기하다 커밋합니다. 이 때문에 주 복제본과 보조 복제본은 동기화된 데이터가 완전히 보호됩니다. 하지만 네트워크 지연이 발생하는 경우 복제 동기화 역시 지연이 발생하게 됩니다. 비동기 커밋(Asynchronous-commit) 모드는 주 복제본은 보조 복제본의 커밋 완료를 기다리지 않고 트랜잭션 커밋하므로 네크워크 지연에 영향받지 않습니다, 다만 이 경우 지연이 발생하면 데이터 손실이 발생할 수 있습니다. DR 구성에서 동기 커밋 모드를 사용할 수는 있지만 네트워크 대역폭 제한으로 인해 복제 지연이 발생하고 이는 마스터 데이터베이스에 영향을 줄 수 있어, 비동기 커밋 모드를 권장합니다.

SQL Server Always On 가용성 그룹은 고가용성 및 재해 복구 솔루션을 제공하기 위한 고급 엔터프라이즈급 기능입니다. 이 기능은 SQL Server 2012 이상 버전에서 사용할 수 있습니다. 또한 Always On 가용성 그룹을 사용하여 온프레미스 SQL Server 데이터베이스를 AWS의 Amazon EC2로 마이그레이션 할 수 있습니다. 이 경우 다운타임 없이 또는 다운타임을 최소화하면서 데이터베이스를 마이그레이션할 수 있게 됩니다.

온프레미스 환경에 SQL Server Always On 가용성 그룹이 존재하고 주 복제본과 보조 복제본이 가용성 그룹 내에서 동기 모드로 데이터를 복제한다고 가정합니다. 이 때 데이터베이스를 AWS 클라우드로 이전하려면 Windows Server 장애 조치 클러스터링(WSFC) 클러스터를 클라우드로 확장할 수 있습니다. AWS 클라우드에 보조 복제본을 만들고 비동기 복제로 설정합니다. 보조 복제본이 온프레미스 데이터베이스의 주 복제본과 동기화된 후에는 필요에 따라 수동 장애 조치(failover)를 수행하면 마이그레이션 목적으로 일시적으로 사용될 수 있습니다.

RPO 및 RTO

온프레미스 데이터 센터에서 AWS로의 DR 장애 조치 시나리오에서 RTO는 Amazon EC2에서 실행 중인 Always on AG 보조 복제본으로 장애 조치할 시간을 정하는 것입니다. 비동기 커밋 모드를 사용하면 강제로 장애 조치를 수행해야 하므로 데이터 손실의 위험을 감수해야 합니다. RTO는 일반적으로 분 단위로 간주됩니다. 이 모드에서는 주 복제본이 트랜잭션 로그 레코드를 보조 복제본으로 보내지만 트랜잭션 커밋에 대한 승인을 기다리지 않습니다. 이 프로세스는 더 빠르지만 RPO 값은 트랜잭션 발생량에 따라 몇 분까지 올라갈 수 있습니다.

고려 사항

가용성 그룹을 구성할 때 다음 사항을 고려할 수 있습니다:

• 가용성 그룹의 모든 복제본은 동일한 워크로드를 처리할 수 있도록 동일한 EC2 인스턴스 패밀리와 크기에서 실행되어야 합니다.
• 가용성 그룹의 모든 데이터베이스에 대해 트랜잭션 로그 백업 전략을 마련하고 예기치 않은 트랜잭션 로그의 증가가 발생하지 않도록 지속적으로 모니터링해야 합니다.
• 최상의 성능을 위해 가용성 그룹의 구성에 대한 전용 네트워크 어댑터(NIC)를 사용을 권장합니다.
• 가용성 그룹 복제본 간의 로그 스트림 전달이 중단되지 않도록 네트워크 연결은 매우 중요합니다. 보조 복제본에 연결할 수 없는 경우 주 복제본에서 트랜잭션 로그의 재사용(트랜잭션 로그 백업에 의한 로그 자르기)이 원활하지 않고, 이로 인해 주 복제본의 트랜잭션 로그 크기가 보조 복제본과의 연결이 정상화될 때까지 계속 증가할 수 있습니다.

아키텍처

다음 다이어그램은 SQL Always On 가용성 그룹을 사용하는 아키텍처를 보여줍니다.

그림: SQL Server Always on AG

이 아키텍처에서는 온프레미스의 SQL Server는 Always on AG로 고가용성이 구성되어 있고, 이 가용성 그룹에 보조 복제본을 AWS로 확장하여 비동기 커밋 모드로 구성된 상황을 보여주고 있습니다. 온프레미스와 AWS 사이의 네트워크 성능이 충분하다면, 온프레미스 복제본들과 AWS에 추가되어 있는 복제본은 클라우드로 전환될 때까지 동기화 상태를 유지하게 됩니다.

장애 조치 및 장애 복구

일반적인 가용성 그룹의 복제본은 DR을 위한 비동기 커밋 모드로 구성됩니다. 재해가 발생하면 수동으로 장애 조치가 시작되며 이를 강제 장애 조치라고 합니다.

가용성 그룹의 강제 장애 조치는 보조 복제본을 웜 스텐바이 서버로 사용할 수 있게 해주는 재해 복구 방법입니다. 강제 장애 조치는 데이터 손실의 위험이 있기 때문에 주의 깊게 사용해야 합니다. 가용성 데이터베이스를 즉시 서비스에 이용해야 하고 데이터 손실 위험을 감수할 수 있는 경우에만 강제 장애 조치를 수행하는 것이 좋습니다.

장애 복구(Failback) 과정은 한 가지 예외를 제외하고는 장애 조치와 동일합니다. Always on AG는 주 사이트를 복구한 후 데이터 손실 없이 장애 복구를 계획하고 구현할 수 있습니다. 가용성 그룹의 복제본을 정상적으로 장애 복구 하려면 동기 커밋 모드로 변경한 후 DR 사이트에서 주 사이트로 수동으로 장애조치를 시작할 수 있습니다. 장애 복구에 성공하면 복제본을 DR을 위한 비동기 커밋 모드로 전환할 수 있습니다.

특징

이 솔루션에는 다음과 같은 이점이 있습니다:

• 애플리케이션은 AG 리스너라는 단일 엔드포인트로 연결 가능하므로 장애 조치 및 장애 복구 과정에 추가 작업이 필요하지 않습니다
• 읽기 워크로드의 성능을 위해 보조 복제본을 활용할 수 있습니다
• 공유 스토리지가 필요하지 않습니다
• Standard Edition은 기본 가용성 그룹만 지원되며, 여기에서는 하나의 사용자 데이터베이스에 대한 장애 조치가 가능합니다.

비용 최적화 고려사항

SQL Server Always on AG가 제공하는 모든 기능을 활용하려면 SQL Server Enterprise Edition이 필요합니다. Always on AG를 구성하고 운영하는데는 다소 어려움이 있으며 비용 증가도 고려해야 합니다. 가령, 가용성 그룹의 Passive Node에서 가능한 기능을 이용하려면 공급업체의 소프트웨어 비용(예: 라이선스 비용)이 추가로 발생하게 됩니다.

Distributed Always On AG

분산 가용성 그룹은 두 개의 가용성 그룹 간에 데이터를 동기화하는 가용성 그룹의 확장입니다. 분산 가용성 그룹을 사용하면 Windows Server에서 동작 중인 가용성 그룹과 Linux에서 동작 중인 가용성 그룹 간에 데이터 동기화할 수 있으며, 읽기 가능한 보조 복제본을 하나의 가용성 그룹의 한도를 초과하여 확장할 수 있습니다. 분산 가용성 그룹 설정에서 각각의 가용성 그룹은 Windows Server 장애 조치 클러스터가 됩니다. 또한 분산 가용성 그룹은 클러스터 확장을 위해 복잡하게 구성하고 운영할 필요 없이 사이트 간 복제를 수행할 수 있습니다.

RPO 및 RTO

분산 가용성 그룹 설정에서 두 AG 간의 관계는 일반적으로 비동기식이며, 장애조치는 항상 수동으로 시작됩니다. 따라서 RPO 및 RTO 값은 단일 비동기식 AG 설정에서 예상할 수 있는 것과 동일하게 간주됩니다.

솔루션 개요

다음 다이어그램은 하이브리드 분산 가용성 그룹의 아키텍처를 보여줍니다.

그림: 분산 가용성 그룹

이 시나리오에서는 주 사이트에 SQL Server Always On AG가 있습니다. AWS에서 DR을 구현하는 경우, AWS에 별도의 AG를 설정하고 이 두 AG 간에 비동기 커밋 관계 모드의 분산 가용성 그룹를 설정할 수 있습니다. Active Directory 도메인이 필요한 경우, 온프레미스 Active Directory 도메인의 확장이거나 별도의 Active Directory 도메인이 될 수 있습니다.

특징

이 솔루션에는 다음과 같은 이점이 있습니다:

• 분산 가용성 그룹의 각 AG는 별도의 Active Directory 도메인에 속하거나 Active Directory가 전혀 없을 수 있습니다.
• 분산 가용성 그룹의 각 AG는 별도의 Windows Server 장애 조치 클러스터이므로 다중 사이트 DR 시나리오를 위해 지리적으로 확장된 장애 조치 클러스터가 필요하지 않습니다.
• 분산 가용성 그룹에서 다양한 버전의 SQL Server 를 사용할 수 있습니다.

비용 최적화 고려사항

분산 가용성 그룹 기능은 SQL Server 2016을 포함한 이후 버전에서 사용할 수 있습니다. 이는 Enterprise Edition에서만 지원합니다. 분산 가용성 그룹에는 리스너를 구성할 수 없습니다. 따라서 애플리케이션에서 연결을 다른 클러스터로 자동으로 리디렉션할 수 없습니다. 애플리케이션 연결 문자열에 명시적인 구성이 필요하므로 관리 오버헤드가 증가합니다.

기술 결합: 로그 전달과 SQL Server 장애 조치 클러스터의 결합

하이브리드 환경에서 SQL Server 워크로드를 실행할 수도 있습니다. 예를 들어, 온프레미스 또는 코로케이션 데이터 센터에서 SQL Server를 운영하고 있지만 고가용성 또는 재해 복구 솔루션을 구현하기 위해 AWS 클라우드를 사용하여 아키텍처를 향상시키고자 할 수 있습니다. 또한 하이브리드 솔루션을 사용하여 AWS에 SQL Server 백업을 지속적으로 저장하고, 문제가 발생할 경우 마이그레이션을 롤백하거나, AWS에서 SQL Server Always on 가용성 그룹을 사용하여 보조 복제본을 추가할 수 있습니다. SQL Server에는 고가용성 및 재해 복구 솔루션을 제공하는 여러 복제 기술이 있습니다.

비즈니스 목표와 요구 사항을 충족하기 위해 여러 DR 및 HA 기술을 결합하여 안정적이고 유연한 솔루션을 만들어야 할 수 있습니다. 대표적인 예로 SQL Server 장애조치 클러스터와 로그 전달을 결합하는 것이 있습니다. SQL Server 장애조치 클러스터를 사용하여 기본 사이트에서 고가용성을 달성한 다음 로그 전달을 사용하여 DR을 수행하고 SQL Server 데이터베이스에 대한 리포팅을 오프로드하는 것이 일반적인 관행입니다. 이러한 기술을 결합하는 이유에는 다음과 같은 가능성이 있습니다:

• 서로 다른 사이트 간에 WSFC 구성을 유지 관리할 수 없습니다.
• 대상 서버가 이미 다른 WSFC 구성의 일부이기 때문에 WSFC 구성의 DR 사이트에서 대상 서버를 사용할 수 없습니다.
• 로그 전달에서는 보조 데이터베이스에 확실한 지연이 발생할 수 있습니다. 로그 전달을 사용하면 복구 중에 특정 시점을 유연하게 선택할 수 있습니다.

RPO 및 RTO

기본 RPO는 15분이며, 기본 로그 전달 간격에 따라 결정됩니다. 노드 간 네트워크 링크에 충분한 대역폭이 있는 경우 최대 1분까지 늘릴 수 있습니다. RTO는 데이터베이스가 복구되는 정확한 시점에 따라 달라집니다.

아키텍처

이 시나리오에서는 온프레미스 데이터 센터의 SQL 장애 조치 클러스터입니다. 그런 다음 데이터베이스의 트랜잭션 로그는 AWS의 DR 사이트에서 실행 중인 대기 SQL Server로 전송됩니다. 다음 다이어그램은 이 아키텍처를 보여줍니다.

그림: 로그 전달과 결합된 SQL Server 장애 조치 클러스터

장애 조치 및 장애 복구

장애 조치 프로세스는 기존 로그 전달 프로세스와 유사합니다. 데이터베이스를 AWS 사이트로 가져오려면 수동 개입이 필요합니다. 장애 조치 후에는 애플리케이션에서 장애 조치된 데이터베이스로 연결이 변경되어야 합니다.
장애 복구하려면 DR 사이트와 주 사이트 간에 로그 전달을 재구성해야 합니다. 장애 복구 후 이 데이터베이스를 사용하는 애플리케이션의 리디렉션도 수동으로 구성해야 합니다.

특징 

이 솔루션에는 다음과 같은 이점이 있습니다:

• 복구 중 이전 시점을 유연하게 선택할 수 있습니다.
• 주 데이터베이스와 보조 데이터베이스는 서로 다른 WSFC 구성의 일부가 될 수 있습니다. 보조 인프라의 중단은 메인 인프라에 영향을 미치지 않습니다.

비용 최적화 고려사항

로그 전달은 SQL Server Web Edition 이상이 필요합니다. 비용 측면에서는 Standard Edition 기준의 로그 전달과 동일한 구성으로 고려될 수 있습니다.

요약

이 포스팅에서는 SQL Server 장애조치 클러스터, SQL Always On 가용성 그룹, 분산 가용성 그룹, 그리고 여러 DR 기술들을 결합하여 AWS에서 DR을 구현하는 방법에 대해 설명했습니다. 다음 포스팅에서는 AWS의 AWS Database Migration Service (AWS DMS)와 AWS Elastic Disaster Recovery(AWS DRS)를 사용하는 방법에 대해 설명합니다. 또한 이 시리즈에서 논의한 모든 SQL Server를 위한 재해 복구 설계 방안을 요약 정리하겠습니다.