BLOG

분산 가용성 그룹을 사용하여 하이브리드 Microsoft SQL 서버 솔루션을 설계하는 방법
작성일: 2018-03-19

단일 업무에 필수적인 Microsoft SQL Server 데이터베이스를 사내에서 AWS (즉, Amazon EC2 기반의 SQL Server)로 마이그레이션 하는 것은 종종 어려운 작업입니다. 이 문제는 주로 다음과 같은 이유로 인해 발생합니다.

 

  • 컷오버 중에도 비즈니스에 부정적인 영향을 미칠 수 있는 장기적인 다운타임 기간
  • 데이터베이스(사내 및 AWS)의 동기화 유지와 관련된 과제
  • 마이그레이션을 위한 단계별 접근 방식을 계획하고 준수하기 위한 유연성 부족

 

이 글에서는 중요한 SQL 서버 데이터베이스를 AWS로 올리고 이동하거나 변환하는 하이브리드 솔루션을 설계하는 방법에 대해 자세히 설명합니다. 이 솔루션은 SQL 서버 2016에 도입된 새로운 기능인 분산 가용성 그룹을 사용합니다. 이 글에서는 분산 가용성 그룹을 사용하여 마이그레이션을 제어함으로써 유연성을 높일 수 있는 단계별 접근 방식에 대해서도 설명합니다.

 

분산 가용성 그룹의 개요

분산 가용성 그룹은 두 개의 개별적인 가용성 그룹으로 확장되는 특수한 AG(가용성 그룹) 유형입니다. 이를 가용성 그룹들에서의 한 개의 가용성 그룹 또는 AG들 중 하나의 가용성 그룹으로 간주할 수 있습니다. 기본 가용성 그룹은 두 개의 서로 다른 WSFC(Windows Server Failover Clustering)클러스터에 구성되어 있습니다.

 

분산 가용성 그룹 아키텍처는 기존 사내의 WFSC(Windows Server Failover Clustering)를 AWS로 확장하는 것보다 더 효율적입니다. 데이터는 사내 primary에서 AWS 복제본(포워더) 중 하나로만 전송됩니다. 포워더는 AWS의 다른 읽기 복제본으로 데이터를 보내는 일을 맡고 있습니다. 이 아키텍처는 사내와 AWS 사이의 트래픽 흐름을 줄이며, 그 반대의 경우도 마찬가지입니다.

 

아키텍처 개요

다음 다이어그램은 솔루션의 전체 아키텍처를 보여 줍니다.

 

 

표시된 것처럼 첫 번째 WSFC 클러스터(WSFC1)는 사내에서 호스팅됩니다. 사내 가용성 그룹(AG1)에 전력을 공급합니다. 두 번째 WSFC클러스터(WSFC2)는 AWS에서 호스팅됩니다. AWS 가용성 그룹(AG2)에 전원을 공급합니다.

 

이 경우 사내 SQL 서버 인스턴스와 데이터베이스는 기존의 물리적 서버 또는 VMs(가상 서버)에서 전원을 공급받습니다. AWS의 SQL Server 인스턴스는 Amazon EC2에서 호스팅되며 SQL Server 데이터베이스는 Amazon EBS 볼륨에서 구성됩니다. AWS Direct Connect는 사내에서 AWS로의 전용 네트워크 연결을 설정합니다.

 

앞의 아키텍처 다이어그램에서 설명한 것처럼, 사내 가용성 그룹(AG1)은 2개의 복제본(노드)을 가지고 있습니다. 이들 간의 데이터 전송은 자동으로 페일오버되면서 동시에 발생합니다. 사내 복제본 중 하나에 오류가 발생하면 AG는 보조 복제본으로 페일오버하고 애플리케이션 및 사용자가 DB를 사용할 수 있습니다. 언제든지 복제본을 더 추가할 수 있습니다. (각 가용성 그룹은 기본 복제본 하나와 보조 복제본을 최대 8개까지 지원합니다.) 고가용성 요구 사항 및 읽기 복제본을 사용한 확장 요구 사항에 따라 추가 복제본을 동기에 발송해야 할지 또는 동시에 발송하지 말아야 할지에 대한 여부를 결정할 수 있습니다.

 

AWS 가용성 그룹(AG2)에도 두 개의 복제본이 있으며, 두 복제본 간의 데이터 전송은 자동으로 페일오버되면서 동시에 이루어집니다. EC2 인스턴스 또는 가용성 영역에 오류가 발생하면 AG가 다른 가용성 영역의 두 번째 EC2 인스턴스로 페일오버합니다.

 

이 솔루션의 일부로 분산 가용성 그룹을 구성합니다. 이 그룹에는 사내 가용성 그룹(AG1)과 AWS 가용성 그룹(AG2)이 모두 포함되어 있습니다. 분산 가용성 그룹은 빨간 색 점선으로 이어지는 아키텍처 다이어그램에서 볼 수 있듯이 데이터베이스를 비동기화 방식에서 동기화 상태로 유지합니다.

 

포워더(앞의 다이어그램에서 초록색으로 보여지는)는 AWS의 다른 읽기 복제품에 데이터를 보내는 일을 맡고 있습니다. 데이터 포워딩은 사내와 AWS 사이의 트래픽 흐름을 줄여 줍니다. 데이터는 주요 복제본에서 한번만 전송되며, 포워더는 나머지 seeding을 처리합니다.

 

특정 시점에 쓰기가 가능한 데이터베이스는 하나만 있습니다. 보조 복제본의 나머지 데이터베이스는 읽기에 사용할 수 있습니다. 앞의 샘플 아키텍처 다이어그램에서는 사내의 주 데이터베이스를 읽기/쓰기에 사용할 수 있고 AWS 보조 데이터베이스는 읽기에 사용할 수 있는 것으로 간주합니다.

 

AWS에서 읽기 복제본을 추가할 수 있는 기능은 주요 이점입니다. 이 기능을 통해 AWS 마이그레이션의 경우 먼저 읽기 전용 애플리케이션을 AWS로 이동할 수 있습니다. 그럼 데이터베이스는 애플리케이션 및 사용자와도 가깝습니다.
읽기 워크 로드를 확장하려면 AWS와 여러 가용성 영역에서 읽기 복제본을 더 추가해야 합니다. 이 접근법은 세 개의 서로 다른 가용 영역에서 세 개의 읽기 복제본을 보여 주는 아키텍처 다이어그램으로 표현됩니다.

 

 

단계별 마이그레이션 방식
분산 가용성 아키텍처를 사용하면 마이그레이션에 단계별 방식을 사용할 수 있으므로 뛰어난 유연성을 달성할 수 있습니다.

 

1단계

이 단계에서 읽기 전용 앱의 대부분을 AWS로 이동하여 읽기 전용 보조 데이터베이스에 액세스 할 수 있습니다. 읽기/쓰기 애플리케이션은 사내의 주 데이터베이스에 계속 액세스합니다.

 

클라우드 마이그레이션의 이 단계에서 데이터베이스 워크 로드에 대한 stress 테스트, 기능 테스트 및 회귀 테스트가 핵심 요소입니다. 읽기 워크 로드를 지원하기 위해 EC2 인스턴스의 정확한 크기도 이 단계에서 중요한 단계입니다.

 

고려해야 할 또 다른 주요 측면은 AWS 측의 읽기 전용 앱이 비동기화식으로 복제된 데이터를 읽는다는 점입니다. 따라서 데이터의 신선도에 영향을 미치는 데이터 복제 지연이 있습니다. 이 솔루션은 Direct Connect 연결을 사용하기 때문에 지연 시간이 최소화되지만, 대기 또는 데이터 지연을 허용하지 않는 애플리케이션의 경우 이 점을 고려해야 합니다.

 

다음은 이 아키텍처를 보여 주는 다이어그램입니다.

 

 

2단계

두 번째 단계에서는 AWS에 대한 분산 가용성 그룹 장애가 발생하여 AWS 데이터베이스가 기본 데이터베이스가 됩니다. 이제 읽기/쓰기 애플리케이션이 AWS의 기본 데이터베이스에 액세스합니다.
특정 읽기 전용 애플리케이션이 계속해서 사내의 보조 데이터베이스에 액세스합니다. 이러한 읽기 전용 앱은 AWS로 이동하지 않을 계획입니다. 이러한 애플리케이션은 특정 시점 이후에 종료되도록 계획하지만 지연 시간을 방지하기 위해 데이터베이스를 더 가까이 두어야 하는 필요성이 있습니다.

 

페일오버는 수동 프로세스이며 분산 가용성 그룹의 동기화 상태를 동기화로 설정합니다. 상태가 동기화되면 페일오버를 시작할 수 있습니다. 페일오버는 상대적으로 빠르기 때문에 다운타임이 줄어듭니다.

 

아키텍처 다이어그램은 다음과 같습니다.

 

 

설정 및 구성
분산 가용성 그룹을 생성하는 전반적인 단계는 다음과 같습니다.

 

  1. 사내 가용성 그룹을 생성하고 보조 복제본(또는 복제본)을 사내 가용성 그룹에 가입시킵니다.
  2. 사내 가용성 그룹에 대한 AG 수신기를 생성합니다.
  3. AWS 가용성 그룹을 생성하고 AWS 가용성 그룹에 보조 복제본(또는 복제본)을 가입합니다.
  4. AWS 가용성 그룹에 대한 AG 수신기를 생성합니다.
  5. 사내 측에서 Asynchronous_Commit 으로 설정된 가용성 모드를 사용하여 분산 가용성 그룹을 생성합니다.
  6. AWS측의 분산 가용성 그룹에 가입합니다.
  7. AWS가용성 그룹의 데이터베이스에 가입합니다.

 

분산 가용성 그룹에 대한 Microsoft 설명서를 참조하여 구성 스크립트 및 단계에 대해 자세히 알아볼 수 있습니다.

 

결론

분산 가용성 그룹 아키텍처는 업무에 필수적인 SQL Server 인스턴스 또는 데이터베이스를 AWS로 올리고 이동하는 데 있어 유연성을 제공합니다. 단계별 접근 방식을 사용하면 마이그레이션 단계를 보다 효과적으로 제어할 수 있을 뿐 아니라 충분한 stress, 회귀 및 기능 테스트를 수행할 수 있습니다.

읽어 주셔서 감사합니다.

 

원문 URL: https://aws.amazon.com/ko/blogs/database/how-to-architect-a-hybrid-microsoft-sql-server-solution-using-distributed-availability-groups

 

** 메가존 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.