BLOG
SQL Server의 다중 지역 아키텍처는 고객과 작업 시 화제가 되는 주제입니다. 고객이 SQL Server 배포를 위해 다중 지역 아키텍처 접근 방식을 채택하는 근본적인 이유는 다음과 같습니다.
- 비즈니스 연속성 및 재해 복구
- 지리적으로 분산된 고객 기반 및 최종 사용자의 대기 시간 개선
본 게시물에서는 두 개 이상의 AWS 리전에 걸쳐있는 고 가용성 SQL Server 배포를 효과적으로 설계하기 위해 수행할 수 있는 아키텍처 패턴에 대해 설명합니다. 또한 다중 지역 접근 방식을 사용하여 읽기 워크로드를 확장하고 전 세계에 분산된 최종 엔드 유저의 대기 시간을 개선하는 방법에 대해서도 배웁니다.
기존의 최적화된 아키텍처
이 게시물에서는 다중 지역 Always On 가용성 그룹의 전통적인 접근 방식과 다중 지역 분산 가용 그룹의 최적 접근 방식이라는 두 가지 아키텍처에 대해 설명합니다.
다중 지역 Always On 가용성 그룹
기존의 접근 방식을 사용하면 리전 간 VPC 피어링 연결을 설정하고 두 개의 리전에서 단일 WSFC (Windows Server Failover Cluster)를 확장하고 두 리전의 노드로 상시 접속 가용 그룹 배포를 구축할 수 있습니다. 다음 다이어그램은 이 아키텍처를 보여줍니다.
이 아키텍처에서 리전 A는 기본 복제본을 호스팅합니다. 동기 보조 복제본도 리전 A에서 호스팅됩니다. 기본 복제본은 리전 A의 AZ1에 있고 동기 보조 복제본은 AZ2에 있습니다. 데이터 전송은 자동 장애 조치의 장애 조치 모드를 통해 복제본간에 동기화되며 연결 장애 또는 AZ1의 기타 장애가 발생하면 자동 장애 조치가 시작되고 AZ2 노드가 기본 복제본이 됩니다. 이는 상시 접속 가용 그룹에 참여하는 서버의 단일 데이터베이스가 실패하는 경우 발생하는 동작과 비슷합니다.
모범 사례로서 응용 프로그램은 상시 접속 가용 그룹 리스너를 통해 최신 지원 드라이버 및 MultiSubNetFailover=True와 같은 주요 매개변수와 연결하여 장애 조치를 용이하게 하고 오류나 시간 초과 없이 응용 프로그램이 새 복제본에 원활하게 연결되도록 해야 합니다. 또한 고려해야 할 쿼럼 관련 설정도 있으며 이는 추후 섹션에서 설명하도록 하겠습니다.
이 아키텍처에서 지역 B는 보조 지역으로 간주됩니다. 두 번째 및 세 번째 보조 복제본은 이 리전에서 구성되며 리전 A에서 호스팅되는 기본에서 비동기식으로 동기화됩니다. 데이터 전송 모드가 비동기로 설정되어 있기 때문에 장애 조치 모드는 수동으로 구성됩니다. 리전 간 통신은 비동기 전송이 권장됩니다. 리전 A에서 치명적인 지역 오류가 발생하면 수동 장애 조치가 트리거되고 애플리케이션이 가용성 그룹 리스너를 통해 리전 B에서 새로 지정된 기본 복제본에 연결할 수 있습니다.
이 방법의 주요 단점 중 하나는 리전 B의 보조 복제본에 대한 데이터 동기화 측면과 관련이 있습니다. 리전 A의 기본 복제본은 모든 보조 복제본과 리전 B의 모든 보조 복제본을 제공하는 역할을 하여 네트워크를 통해 별도로 데이터를 보냅니다. 하지만 다중 데이터 전송은 전체 데이터 전송 요금을 증가시킬 수 있으므로 비용 최적화 전략이라고 볼 수 없습니다.
이에 대한 한 가지 해결 방법은 보조 지역 B에 단일 노드만 두고 지역 장애 조치 시 새 노드를 추가하는 것입니다. 다른 취약점은 보안과 관련이 있습니다. 여러 리전에서 WSFC를 확장할 때 보안 그룹을 위해 많은 포트 세트를 열어야 합니다. 여기에는 클러스터 서비스 용 TCP / UDP 포트, RPC 용 TCP 포트, 클러스터 관리자 용 UDP, ICMP, SMB 용 TCP 및 임의로 할당된 UDP 포트가 포함됩니다. 광범위한 포트를 여는 것은 내부 보안 팀이 주시하는 문제입니다. 관련된 포트에 대한 자세한 정보는 Windows 지원 웹 사이트에서 Windows의 서비스 개요 및 네트워크 포트 요구 사항을 참고하세요.
다중 지역 분산 가용성 그룹
분산 가용 그룹이 있는 아키텍처는 다중 지역 SQL Server 배포를 위한 최적의 접근 방법입니다. 분산 가용 그룹은 두 가지 개별 가용성 그룹에 걸쳐있는 특수한 유형의 가용성 그룹이며 가용성 그룹 내의 가용성 그룹으로 보셔도 좋습니다. 기본 가용성 그룹은 서로 다른 두 개의 WSFC 클러스터에 구성됩니다.
분산 가용 그룹 접근 방식을 사용하여 온 프레미스 데이터 센터 및 AWS에 SQL Server 노드가 배포된 하이브리드 SQL Server 배포 아키텍처를 설계할 수도 있습니다. 자세한 내용은 분산 가용성 그룹을 사용하여 하이브리드 Microsoft SQL Server 솔루션을 설계하는 방법을 참고하세요.
다음 다이어그램은 다중 지역 분산 가용성 그룹 아키텍처를 보여줍니다.
이 아키텍처에서 리전 A는 기본 복제본을 호스팅합니다. 리전 A에 대해 WSFC1이라는 독립형 WSFC 클러스터가 있으며 이전 아키텍처와 같이 리전에 걸쳐 있지 않습니다. 동기 보조 복제본도 리전 A에서, 가급적 두 번째 가용 영역에서 호스팅됩니다. 기본 복제본은 리전 A의 AZ1에 있고 동기 보조 복제본은 AZ2에 있습니다. 두 복제본은 모두 AG1이라는 독립 실행형 가용성 그룹의 일부입니다. 장애 조치 모드로 자동 장애 조치를 사용하여 복제본간에 데이터 전송이 동기화됩니다. 장애가 발생하면 자동 장애 조치가 시작되고 AZ2 노드가 기본 복제본이 됩니다.
모범 사례로서 응용 프로그램은 상시 접속 가용성 그룹 리스너를 통해 최신 지원 드라이버 및 주요 매개 변수 (예 MultiSubNetFailover=True:)와 연결하여 장애 조치를 용이하게 하고 오류나 시간 초과 없이 응용 프로그램이 새 복제본에 원활하게 연결되도록 해야 합니다. 고려해야 할 쿼럼 관련 설정이 있으며 이는 이후 섹션에서 설명하겠습니다.
이 아키텍처에서 지역 B는 보조 지역으로 간주됩니다. 두 번째 보조 복제본은 이 리전에서 구성되며 리전 A에서 호스팅되는 기본과 비동기식으로 동기화됩니다. 이 복제본은 forwarder 라고 불립니다. Forwarder 는 새로운 개념으로 분산 가용성 그룹의 핵심 기능 중 하나입니다. Forwarder 는 지역 B의 다른 복제본을 동기화합니다.
Forwarder 는 이 최적 아키텍처의 주요 장점 중 하나입니다. 리전 A의 기본 복제본은 전달자에게만 비동기식으로 데이터를 전송하고 포워더는 리전 B의 다른 복제본으로 동기식 또는 비동기식으로 데이터를 전송합니다. 이렇게 하면 여러 노드가 있는 경우 리전 A에서 지역 B로 발생하는 전체 데이터 전송이 줄어듭니다. WSFC1 및 WSFC2는 독립형 독립 클러스터이므로 큰 포트 세트를 열 필요가 없습니다. 이렇게 하면 보안 위험을 감소시킬 수 있습니다.
읽기 파일 스케일링
분산 가용 그룹 아키텍처를 추가로 확장하여 리전 B에 읽기 전용 복제본을 제공할 수 있습니다. 이 방법은 서로 다른 두 리전에 애플리케이션 사용자가 있고 더 가까운 리전에서 읽기 파일을 사용할 수 있는 경우에 유용합니다. 이렇게 하면 읽기 전용 SQL 쿼리의 대기 시간이 향상됩니다. 다음 다이어그램은 이 아키텍처를 보여줍니다.
이 아키텍처에는 리전 B에 대해 3개의 추가 복제본이 구성되어 있습니다. 전달자는 이 3 개의 복제본의 데이터 동기화를 담당합니다. 읽기 파일을 확장하기 위해 추가 복제본을 사용할 수 있습니다. 각 가용성 그룹은 하나의 기본 복제본과 최대 8 개의 보조 복제본을 지원합니다. 기본적으로 이 구성으로 최대 18 개의 읽기 전용 복제본을 가질 수 있습니다.
고 가용성의 단일 지역 SQL Server 배포에 관심이 있는 경우 SQL Server 용 AWS Launch Wizard를 활용할 수 있습니다. SQL Server용 AWS Launch Wizard는 간단하고 직관적이며 무료로 사용할 수 있는 마법사 기반 환경으로 AWS에서 고 가용성 SQL Server 솔루션을 빠르고 쉽게 배포할 수 있습니다. 마법사는 규정 지침을 사용하여 항상 가용성 그룹에 대한 엔드 투 엔드 배포 환경을 안내합니다. AWS Launch Wizard를 사용하면 SQL Server 노드 설정 및 AMI에서 VPC( Virtual Private Cloud ), AD ( Active Directory ) 및 EC2 인스턴스에 이르는 애플리케이션의 구성 요소를 지정하여 프로덕션 환경에 쉽게 배포 할 수 있습니다.
고려할 사항
배포 전략을 선택할 때는 대역폭, 쿼럼 설정 및 자동 시딩을 고려해야 합니다.
대역폭
다중 지역 배포시 대역폭은 주요 고려 사항입니다. 예를 들어 미국 동부 (버지니아 북부)와 미국 서부 (오레곤)에 분산 가용성 그룹을 사용하여 다중 지역 SQL Server 배포를 설정했다고 가정합니다. 이 두 지역의 네트워크 대기 시간은 75-80 밀리 초입니다. 워크로드가 높은 OLTP 시스템인 경우 스트레스 및 성능 벤치마킹 테스트를 수행하여 다른 리전의 보조 복제본이 지연 없이 동기화되는지 확인해야 합니다. 보조 복제본을 동기화하는 데 상당한 지연이 발생하면 RPO (Recovery Point Objective) SLA에 부정적인 영향을 미칩니다.
쿼럼 설정
분산 가용 그룹을 사용하면 서로 다른 두 개의 WSFC가 있으므로 쿼럼 설정을 개별적으로 처리하기 때문에 노드 수에 따라 쿼럼 투표를 설정해야 합니다. 파일 공유 감시는 권장되는 감시 유형이며 파일 공유 감시 요구 사항에 대해 완전 관리형 서비스 Windows 파일 서버용 Amazon FSx를 사용할 수 있습니다.
Amazon FSx를 사용하여 Always On 장애 조치 클러스터 인스턴스 (FCI)를 설계할 수도 있습니다. 자세한 내용은 Windows 파일 서버용 Amazon FSx를 사용하여 Microsoft SQL Server 고 가용성 배포 단순화를 참고하세요.
자동 시딩
SQL Server 2016에는 가용성 그룹의 자동 시딩이 도입되었습니다. 자동 시딩으로 가용 그룹을 만들면 SQL Server는 그룹의 모든 데이터베이스에 대한 보조 복제본을 자동으로 만듭니다. 더 이상 보조 복제본을 수동으로 백업 및 복원할 필요가 없습니다. 이 기능은 상대적으로 작은 데이터베이스 집합을 처리할 때 유용 할 수 있습니다. 더 큰 데이터베이스로 작업하는 경우 자동 시드가 권장되지 않습니다. 자동 시딩에 대한 자세한 내용은 Microsoft 문서 웹 사이트에서 자동 시딩을 사용하여 Always On 가용성 그룹 초기화를 참고하세요.
결론
업무에 중요한 SQL Server 배포에는 다중 리전 전략이 핵심이라고 할 수 있습니다. 이 포스트는 분산 가용 그룹을 사용하여 이를 최적으로 달성하는 방법에 중점을 두었습니다. 분산 가용 그룹을 사용하여 읽기 파일 확장과 같은 다른 이점에 대해서도 배웠습니다.
SQL Server 배포 최적화에 대한 추가 게시물을 확인하세요.
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.