AWS 기술 블로그

AWS에서 SQL Server를 위한 재해 복구 아키텍처 설계: 1부

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

오늘날의 세계에서 재해가 발생하는 것은 시간 문제이며, 재해가 발생하면 데이터 손실과 다운타임을 최소화하면서 SQL Server 데이터베이스를 복구하고 시스템을 온라인 상태로 전환하는 것이 필수적입니다. SQL Server 데이터베이스 액세스 중단에 대응하고 복구하기 위해 고가용성(HA) 및 재해 복구(DR) 솔루션이 활용됩니다. 고가용성은 가동 중단을 방지하기 위해 구성하는 작업을, 재해 복구는 가동 중단 후 고가용성을 다시 설정하기 위해 수행하는 작업을 다룹니다. AWS는 SQL Server 워크로드를 위한 HA 및 DR 솔루션의 비용과 복잡성을 낮추는 데 도움을 줄 수 있습니다.

많은 고객이 AWS의 SQL Server에 적합한 HA 또는 DR 솔루션을 선택하기 위해 도움을 요청하지만, 모든 경우에 적합한 단일 솔루션은 없습니다. 데이터 손실 가능성, 복구 시간, 운영 복잡성 및 비용과 관련된 절충 사항이 있습니다. 경우에 따라서는 이러한 기술을 결합하여 HA와 DR 기능을 모두 갖춘 솔루션을 구현할 수도 있습니다.

대다수의 경우, 고객은 관리형 서비스인 SQL Server용 Amazon Relational Database Service(Amazon RDS for SQL Server)로 작업할 수 있으며, 이를 통해 AWS에서 SQL Server를 더 쉽게 설정, 운영 및 확장할 수 있습니다. 또한, Amazon EC2(Amazon Elastic Compute Cloud)에서 SQL Server 데이터베이스를 직접 실행하고 관리할 수도 있습니다.

이 블로그 시리즈에서는 Amazon EC2의 SQL Server에 사용할 수 있는 DR 솔루션을 비교 및 대조하고, 각 솔루션의 특성과 AWS에서 SQL Server 워크로드용 DR을 구현하는 데 드는 비용 및 복잡성을 이해하는데 도음드리고자 합니다. SQL Server용 Amazon RDS에 대해서도 유사한 시리즈를 작성할 계획이며, 사용 가이드에서 Amazon RDS 복원력에 대해 자세히 알아볼 수 있습니다.

이 게시물에서는 다양한 SQL Server 버전 및 에디션에 사용할 수 있는 기술 용어와 DR 솔루션을 소개합니다. 2부에서는 SQL Server 백업 및 복원, SQL Server 로그 전송, SQL Server 데이터베이스 미러링에 대해 살펴봅니다. 3부에서는 SQL Server Always on Failover Cluster Instances (FCIs) 및 Always On availability groups에 대해 자세히 살펴봅니다. 마지막으로 4부에서는 AWS Database Migration Service (AWS DMS), AWS AWS Elastic Disaster Recovery (AWS DRS),를 소개하고 시리즈에서 논의한 모든 기술을 마무리합니다.

기술 용어

이 블로그 시리즈에서는 다음과 같은 용어를 사용합니다:

  • 고가용성(HA) – HA는 데이터 센터, 가용 영역, 서버, 네트워크 및 스토리지 하위 시스템 장애로부터 보호하여 다운타임 없이 비즈니스를 계속 운영할 수 있도록 지원합니다.
  • 재해 복구(DR) – 재해 복구는 재해에 대비하고 재해로부터 복구하는 것입니다. 비즈니스 연속성이나 재정에 부정적인 영향을 미치는 모든 이벤트를 재해라고 할 수 있습니다. 여기에는 하드웨어 또는 소프트웨어 장애, 네트워크 중단, 정전, 화재나 홍수와 같은 건물의 물리적 손상, 인적 오류 또는 기타 혼란스러운 사고가 포함될 수 있습니다.
  • 복구 시간 목표 – Recovery Time Objective(RTO)는 서비스 중단과 서비스 복구 사이의 허용 가능한 최대 지연 시간(조직에서 정의)입니다. 이는 서비스를 사용할 수 없을 때 허용 가능한 시간으로 간주되는 기간을 결정합니다.
  • 복구 시점 목표 – Recovery Point Objective(RPO)는 마지막 데이터 복구 시점 이후 허용 가능한 최대 시간(조직에서 정의)입니다. 이는 마지막 복구 지점과 서비스 중단 사이에 허용 가능한 데이터 손실로 간주되는 시간을 결정합니다.
  • 장애 조치 – 애플리케이션에서 기본 노드에 더 이상 액세스할 수 없는 경우 서비스가 자동으로 대기 노드로 전환되는 프로세스입니다. 장애 조치에는 사용자의 개입이 필요하지 않습니다.
  • 스위치오버 – 장애 조치와 달리 스위치오버는 테스트 및 예정된 유지 관리를 위해 서비스를 기본 노드에서 대기 노드(새 기본 노드)로 의도적으로 전환하는 프로세스입니다. 스위치오버에는 사용자의 개입이 필요합니다.
  • 장애 복구 – 장애 복구는 원래 노드가 정상 상태로 복구되고 서비스를 재개할 준비가 된 장애 조치 또는 스위치오버의 반대 동작입니다. 장애 복구는 항상 사용자가 시작합니다.
  • 액티브-패시브 – 정전이 발생하지 않는 한 단일 노드(기본 노드)에서 항상 서비스를 제공하는 액티브-패시브 클러스터 구성입니다. 중단이 감지되면 서비스가 전용 대기 노드로 전송됩니다. 이러한 서비스 이전은 자동 장애조치 또는 사용자 주도 전환을 통해 이루어질 수 있습니다.
  • 액티브-액티브 – 기본 노드와 보조 노드 모두에서 동시에 서비스를 제공하는 액티브-액티브 클러스터 구성입니다. 이 구성에서는 활성 노드 중 하나만 사용할 수 없게 되는 경우 장애 조치가 필요하지 않습니다. 활성 노드 하나를 사용할 수 없게 되더라도 다른 활성 노드는 계속 사용할 수 있습니다.
  • 파일럿 라이트 – 한 리전에서 다른 리전으로 데이터를 복제하고 핵심 워크로드 인프라의 사본을 프로비저닝합니다. 데이터베이스 및 오브젝트 스토리지와 같이 데이터 복제 및 백업을 지원하는 데 필요한 리소스는 항상 켜져 있습니다. 애플리케이션 서버와 같은 기타 요소에는 애플리케이션 코드 및 구성이 로드되지만 전원이 꺼져 있으며 테스트 중이거나 재해 복구 장애 복구가 호출될 때만 사용됩니다.
  • 웜 스탠바이 – 웜 스탠바이는 축소되었지만 모든 기능을 갖춘 워크로드 버전을 항상 DR 리전에서 실행하도록 유지합니다. 비즈니스 크리티컬 시스템은 완전히 복제되어 항상 켜져 있지만 규모가 축소된 상태로 유지됩니다. 복구 시점이 되면 시스템이 빠르게 확장되어 프로덕션 부하를 처리합니다. 웜 스탠바이를 더 많이 확장할수록 RTO 및 제어 플레인 의존도가 낮아집니다. 최대 규모로 확장하면 이를 핫 스탠바이라고 합니다.
  • 콜드 스탠 바이 – 콜드 스탠바이에서는 기본 노드의 이중화를 유지합니다. 대기 노드는 종료 모드에 있으며 기본 노드와 동기화를 유지하려면 수동으로 켜야 합니다.
  • 동기식 복제 – 동기식 복제는 한 데이터베이스에서 다른 데이터베이스로 데이터 변경 내용을 복사하는 것입니다. 대부분의 동기식 복제 제품은 기본 스토리지와 복제본에 동시에 데이터를 씁니다. 따라서 기본 복사본과 복제본은 항상 동기화된 상태로 유지되어야 합니다.
  • 비동기식 복제 – 비동기식 복제 솔루션은 먼저 기본 스토리지에 데이터를 쓴 후 복제본에 데이터를 복사합니다. 복제 과정은 보조 복제본과의 사이에서 최소 대기 시간으로 실행됩니다. 기본 스토리지가 비동기 모드로 구성된 경우 수동 장애조치만 허용합니다. 장애조치 이벤트가 발생할 경우 일부 데이터 손실이 발생할 수도 있습니다.

다음 표에는 HA 및 DR에서 기대할 수 있는 사항이 요약되어 있습니다.

고가용성 재해 복구
장애 조치(Failover) 자동 수동
장애 복구(Failback) 자동 수동
복제 동기식 비동기식
목표/의도 서비스/서비스 가용성 유지 데이터/서비스 연속성 유지

SQL Server 버전 및 에디션 요구 사항

SQL Server는 조직이나 개인 사용자의 요구 사항에 따라 필요한 성능이나 기능, 그리고 가격 요구 사항에 따른 다양한 에디션을 제공합니다. 아울러 요구 사항에 따라 설치해야 하는 SQL Server 구성 요소도 달라지게 됩니다. 고려하고 있는 HA 혹은 DR 요구 사항에 맞는 최상의 선택에 이해를 돕고자, 다음 2개의 표는 SQL Server 버전 및 에디션에 따라 구현할 수 있는 기능을 소개하고 있습니다.

다음 표에는 SQL Server 에디션별 DR 솔루션이 요약되어 있습니다. 이 블로그 시리즈에서 이러한 옵션을 살펴보겠습니다.

솔루션 SQL 2008 SQL 2008 R2 SQL 2012 SQL 2014 SQL 2016 SQL 2017 SQL 2019 SQL 2022
SQL Server Backup and Restore
SQL Server Log Shipping
SQL Server Database Mirroring (Deprecated)
SQL Server Always On Failover Cluster Instances
SQL Server Always On Availability Groups 아니오 아니오 예(복제본 4개) 예(복제본 8개) 예(복제본 8개) 예(복제본 8개) 예(복제본 8개) 예(복제본 8개)
SQL Server Distributed Always On Availability Groups 아니오 아니오 아니오 아니오 예(2개 AG 간 최대 18개 복제본) 예(2개 AG 간 최대 18개 복제본) 예(2개 AG 간 최대 18개 복제본) 예(2개 AG 간 최대 18개 복제본)
AWS DMS
AWS Elastic Disaster Recovery

다음 표에는 SQL Server 버전별 DR 솔루션이 요약되어 있습니다.

솔루션 고가용성 재해복구 Enterprise Edition Standard Edition Web Edition
SQL Server Backup and Restore 아니요
SQL Server Log Shipping 아니오
SQL Server Database Mirroring (Deprecated) 예(Full safety only) 예(witness only)
SQL Server Always On Failover Cluster Instances 아니오 예(최대 16개 복제본) 예(복제본 2개) 아니오
SQL Server Always On Availability Groups 예(최대 8개 복제본) 예(기본 AG로 복제본 2개) 아니오
SQL Server Distributed Always On Availability Groups 예(2개 AZ 간 최대 18개 복제본) 아니오 아니오
AWS DMS 아니오
AWS Elastic Disaster Recovery 아니오

요약

재해 복구 솔루션의 선택은 요구 사항과 예산은 물론 설치하는 SQL Server 제품의 버전과 에디션에 따라 달라집니다. 일부 사용 사례에서는 여러 DR 기술을 결합하는 것이 유리할 수도 있습니다.

이번 글에서는 SQL Server에서의 DR 용어와 AWS에서 DR 구현을 위해 고려해야할 SQL Server 버전과 에디션에 대해 설명했습니다. 다음 블로그에서는 DR 사용 사례를 위한 SQL Server의 백업 및 복원, SQL Server 로그 전달 (Log Shipping) 그리고 SQL Server 데이터베이스 미러링 (Database Mirroring)에 대해 설명하겠습니다.

Dongcheol Ryu

Dongcheol Ryu

류동철 솔루션스 아키텍트는 다양한 산업군에서의 Microsoft worklods 경험을 바탕으로 현재는 AWS 파트너사들의 MS 기술 역량 강화와 MS 워크로드 기반 클라우드 시스템 설계 등의 업무를 지원하고 있습니다.

JuYeon Park

JuYeon Park

박주연 Microsoft Specialist Solutions Architect는 온프레미스나 다른 클라우드 환경에서 운영 중인 모든 Microsoft Workloads를 AWS로의 마이그레이션 및 현대화 과정에 필요한 기술적 도움을 드리고 있습니다.