고가용성 및 재해 복구 옵션 살펴보기

15분

VM(가상 머신)에 맞는 솔루션을 구현하려면 먼저 IaaS 기반 배포를 위한 가용성 옵션을 이해해야 합니다.

Infrastructure-as-a-Service 및 Platform-as-a-Service 비교

가용성 측면에서 IaaS와 PaaS 중 무엇을 선택하느냐에 따라 결과가 달라집니다. IaaS를 사용한다는 것은 가상 머신이 있다는 것, 즉 SQL Server가 설치된 운영 체제가 있다는 것입니다. SQL Server를 담당하는 관리자 또는 그룹은 HADR(고가용성 및 재해 복구) 솔루션을 선택할 수 있으며 해당 솔루션이 구성되는 방식을 매우 효과적으로 제어할 수 있습니다.

Azure SQL Database와 같은 PaaS 기반 배포를 사용할 경우 HADR 솔루션이 해당 기능에 기본 제공되어 이를 활성화하기만 하면 되는 경우가 많습니다. 구성할 수 있는 옵션이 매우 적습니다.

차이로 인해 IaaS와 PaaS 중 무엇을 선택하느냐에 따라 HADR 솔루션의 최종 설계가 달라질 수 있습니다.

Azure 가상 머신용 SQL Server HADR 기능

IaaS를 사용하는 경우 SQL Server에서 제공하는 기능을 이용하여 가용성을 높일 수 있습니다. 경우에 따라 해당 기능을 Azure 수준 기능과 결합하여 가용성을 높일 수도 있습니다.

SQL Server에서 제공하는 기능은 아래 표에 나와 있습니다.

기능 이름	보호
Always On FCI(장애 조치(failover) 클러스터 인스턴스)	인스턴스
Always On AG(가용성 그룹)	데이터베이스
로그 전달	데이터베이스

SQL Server 인스턴스는 SQL Server(로그인, SQL Server 에이전트 작업 및 데이터베이스와 같은 항목을 포함하여 인스턴스 안에 있는 모든 개체, 이진 파일, 데이터베이스)의 전체 설치입니다. 인스턴스 수준 보호는 가용성 기능에서 전체 인스턴스가 사용됨을 의미합니다.

SQL Server의 데이터베이스에는 최종 사용자 및 애플리케이션에서 사용하는 데이터가 포함됩니다. 최종 사용자 및 애플리케이션에서 사용하도록 만들어진 데이터베이스 외에도 SQL Server가 사용하는 시스템 데이터베이스가 있습니다. SQL Server 인스턴스에는 항상 자체 시스템 데이터베이스가 있습니다. 데이터베이스 수준 보호는 데이터베이스에 있거나 사용자 또는 애플리케이션 데이터베이스에 대한 트랜잭션 로그에서 캡처되는 모든 항목이 가용성 기능의 일부로 사용됨을 의미합니다. 계획되거나 계획되지 않은 장애 조치(failover) 이벤트가 발생할 때 대상 서버가 주 서버처럼 기능하도록 하려면 데이터베이스 외부에 있거나 SQL Server 에이전트 작업 및 연결된 서버와 같이 트랜잭션 로그의 일부로 캡처되지 않은 모든 항목을 수동으로 처리해야 합니다.

FCI와 AG 모두 기본 클러스터 메커니즘이 필요합니다. Windows Server에서 실행되는 SQL Server 배포의 경우 WSFC(Windows Server Failover Cluster)가 필요하고 Linux의 경우에는 Pacemaker가 필요합니다.

Always On 장애 조치(failover) 클러스터 인스턴스

FCI는 SQL Server가 설치될 때 구성됩니다. SQL Server의 독립 실행형 인스턴스는 FCI로 변환할 수 없습니다. FCI에는 클러스터에 참여하는 기본 서버 또는 노드와는 다른 고유한 이름과 IP 주소가 할당됩니다. 이름과 IP 주소는 기본 클러스터 메커니즘과도 달라야 합니다. 애플리케이션 및 최종 사용자는 FCI의 고유 이름을 사용하여 액세스합니다. 추상화를 통해 애플리케이션은 인스턴스가 실행되는 위치를 확인할 필요가 없게 됩니다. Azure 기반 FCI와 온-프레미스 FCI 간의 주된 차이점 중 하나는 Azure에서는 ILB(내부 부하 분산 장치)가 필요하다는 것입니다. ILB는 애플리케이션과 최종 사용자가 FCI의 고유한 이름에 연결할 수 있도록 지원하는 데 사용됩니다.

FCI가 클러스터의 다른 노드로 장애 조치(failover)하면 수동으로 시작되든 문제로 인해 발생하든 관계없이 전체 인스턴스가 다른 노드에서 다시 시작됩니다. 즉, 장애 조치(failover) 프로세스에서는 SQL Server 전체가 중단 및 시작됩니다. 장애 조치(failover) 중에는 FCI에 연결된 애플리케이션 또는 최종 사용자의 연결이 끊어지고 중단을 처리하고 중단으로부터 복구될 수 있는 애플리케이션만 자동으로 연결할 수 있습니다.

다른 노드에서 FCI가 시작되면 해당 인스턴스는 복구 프로세스를 거칩니다. FCI는 실패 지점과 일관성을 유지하므로 기술적으로는 데이터가 손실되지 않지만 롤백되어야 하는 트랜잭션은 복구의 일부로 롤백됩니다. 위에서 설명한 것처럼 FCI는 인스턴스 수준의 보호이므로, 필요한 모든 항목(로그인, SQL Server 에이전트 작업 등)이 이미 갖추어져 있어 데이터베이스가 준비되기만 하면 평소와 같이 비즈니스를 계속할 수 있습니다.

FCI에는 하나의 데이터베이스 복사본이 필요하지만 데이터베이스는 단일 실패 지점이기도 합니다. 다른 노드에서 데이터베이스에 액세스할 수 있도록 하려면 FCI에 특정 형식의 공유 스토리지가 필요합니다. Windows Server 기반 아키텍처의 경우 공유 스토리지는 Azure 프리미엄 파일 공유, iSCSI, Azure 공유 디스크, S2D(스토리지 공간 다이렉트) 또는 지원되는 타사 솔루션(예: SIOS DataKeeper)을 통해 구축할 수 있습니다. SQL Server의 Standard Edition을 사용하는 FCI에는 최대 2개의 노드가 있을 수 있습니다. FCI는 AD DS(Active Directory Domain Services) 및 DNS(Domain Name System)를 사용해야 하므로 FCI가 작동하려면 Azure에 AD DS와 DNS를 구현해야 합니다.

Windows Server 2016 이상 버전을 사용하면 FCI에서 로그 전달 또는 AG와 같이 다른 기능을 사용하지 않고도 스토리지 복제본을 사용하여 FCI에 대한 기본 재해 복구 솔루션을 만들 수 있습니다.

Always On 가용성 그룹

AG는 SQL Server 2012 Enterprise Edition 및 SQL Server 2016에서 도입되었으며 Standard Edition에도 있습니다. Standard Edition에서는 AG에 데이터베이스 1개를 포함할 수 있지만 Enterprise Edition에서는 AG에 2개 이상의 데이터베이스를 포함할 수 있습니다. AG는 FCI와 일부 유사한 점이 있지만 많은 부분에서 상이합니다.

FCI와 AG의 가장 큰 차이점은 AG는 데이터베이스 수준 보호를 제공한다는 것입니다. 주 복제본은 AG에 참여하는 인스턴스로, 읽기/쓰기 데이터베이스를 포함합니다. 보조 복제본은 주 복제본이 로그 전송을 통해 트랜잭션을 전송하여 동기화시키는 대상입니다. 주 복제본 간의 데이터 이동은 동기식 또는 비동기식일 수 있습니다. 보조 복제본의 데이터베이스는 로드 중인 상태에 있습니다. 즉, 데이터베이스가 트랜잭션을 수신할 수는 있지만 해당 복제본이 주 복제본이 될 때까지는 완전히 쓰기 가능한 복사본이 될 수 없습니다. Standard Edition의 AG에는 최대 2개의 복제본(주 복제본 1개, 보조 복제본 1개)이 있을 수 있습니다. 반면 Enterprise Edition은 최대 9개(주 복제본 1개, 보조 복제본 8개)를 지원합니다. 보조 복제본은 데이터베이스의 백업에서 초기화되며 SQL Server 2016부터는 ‘자동 시드’라는 기능을 사용할 수 있습니다. 자동 시드는 구성된 엔드포인트를 사용 중인 가용성 그룹의 데이터베이스별로 로그 스트림 전송을 사용하여 백업 복사본을 보조 복제본으로 스트리밍합니다.

AG는 수신기를 사용하여 추상화를 제공합니다. 수신기는 FCI에 할당된 고유 이름처럼 작동하며 다른 항목(WSFC, 노드 등)과는 다른 고유한 이름과 IP 주소를 갖습니다. 또한 수신기는 ILB를 필요로 하고 중지 및 시작을 거칩니다. 애플리케이션 및 최종 사용자는 수신기를 사용하여 연결할 수 있지만 FCI와는 달리 원하는 경우 수신기를 사용하지 않아도 됩니다. 인스턴스에 직접 연결되는 경우가 발생할 수 있습니다. Enterprise Edition을 사용하면 필요한 경우 Enterprise Edition의 보조 복제본을 읽기 전용 액세스용으로 구성할 수도 있고 DBCC(데이터베이스 일관성 확인) 및 백업과 같은 다른 기능에 사용할 수 있습니다.

AG는 FCI와 비교하여 장애 조치(failover) 시간이 더 짧을 수 있으며 이 점이 AG이 매력적인 이유입니다. AG에는 공유 스토리지가 필요하지 않지만 복제본마다 데이터 복사본을 가지고 있기 때문에 데이터베이스 복사본의 총 수와 전체 스토리지 비용이 증가합니다. 스토리지는 각 복제본에 대해 로컬입니다. 예를 들어 주 복제본에 있는 데이터베이스의 데이터 공간이 1TB이면 각 복제본도 동일한 공간을 차지하게 됩니다. 5개의 복제본이 있다면 이는 5TB의 공간이 필요함을 의미합니다.

다른 SQL Server 인스턴스가 새로운 주 복제본이 되어야 하는 경우 해당 인스턴스에서는 데이터베이스 외부에 있거나 데이터베이스의 트랜잭션 로그에서 캡처되지 않는 모든 개체를 수동으로 만들고 처리해야 합니다. 개체의 예로는 SQL Server 에이전트 작업, 인스턴스 수준 로그인 및 연결된 서버가 있습니다. Windows 인증을 사용할 수 있거나 포함된 데이터베이스를 AG에 사용할 수 있는 경우 액세스가 단순화됩니다.

많은 조직에서 고가용성 아키텍처를 구현하는 데 어려움을 겪을 수 있으며 Azure 플랫폼에서 제공하는 고가용성 또는 Azure SQL Managed Instance와 같은 PaaS 솔루션을 사용하는 고가용성만 필요로 할 수도 있습니다. Azure 플랫폼 솔루션을 살펴보기 전에 알아야 하는 SQL Server 기능이 하나 더 있는데, 바로 로그 전달입니다.

로그 전달

로그 전달은 SQL Server의 초창기부터 사용되어 왔습니다. 이 기능은 백업, 복사 및 복원을 기반으로 하며 SQL Server에 HADR을 구현하는 가장 간단한 방법 중 하나입니다. 로그 전달은 주로 재해 복구에 사용되지만 로컬 가용성을 향상시키는 데도 사용할 수 있습니다.

AG와 같은 로그 전달은 데이터베이스 수준 보호를 제공합니다. 즉, SQL Server 에이전트 작업, 연결된 서버, 인스턴스 수준 로그인 등을 계속해서 처리해야 합니다. 기본적으로 로그 전달을 통해 제공되는 추상화는 없으므로 로그 전달에 참여하는 다른 서버로 전환하려면 이름 변경을 허용해야 합니다. 이름 변경이 가능하지 않은 경우 이름 변경 문제를 완화하기 위해 네트워크 계층에서 구성할 수 있는 DNS 별칭과 같은 메서드가 있습니다.

로그 전달 메커니즘은 간단합니다. 먼저 주 서버에서 원본 데이터베이스의 전체 백업을 수행하고 보조 서버 또는 웜 대기라는 다른 인스턴스에 로딩 상태(STANDBY 또는 NORECOVERY)로 복원합니다. 데이터베이스의 새 복사본을 보조 데이터베이스라고 합니다. 그런 다음 SQL Server에 내장된 자동화된 프로세스가 주 데이터베이스의 트랜잭션 로그를 자동으로 백업하고, 백업 복사본을 대기 서버로 복사하고 마지막으로 백업 복사본을 대기로 복원합니다.