RDS for MS-SQL: 고가용성 기능 소개

개요

TOAST Cloud Relational Database Service for SQL Server (RDS for MS-SQL)는 Microsoft SQL Server를 클라우드 환경에서 제공하는 서비스입니다. 복잡한 설정 없이 고가용성의 Microsoft SQL Server를 사용할 수 있습니다. 이 글에서는 어떻게 고가용성을 제공하는지에 대해서 간략하게 소개하고 있습니다.

고가용성 이란?

고가용성이란 오랜 기간 동안 지속적으로 정상 운영이 가능한 성질을 말합니다.(https://en.wikipedia.org/wiki/High_availability)

여러 상용 데이터베이스들은 보통 고가용성을 지원하기 위해 Active - Active 혹은 Active - Standby로 서버를 구성할 수 있게 해 주거나, 공유 스토리지를 이용하여 데이터를 공유하기도 합니다. 또한 경우에 따라서는 동일한 데이터를 분산 저장하는 분산 스토리지를 사용하여 고가용성을 지원하고 있습니다.

예를 들어 Oracle에는 HA, RAC, OPS 등, MySQL에는 MMM, MHA 등이 있습니다. Microsoft SQL Server에도 여러 가지 설루션이 존재합니다. 미러링과 장애 조치 클러스터, AlwaysON 이 대표적입니다.

RDS for MS-SQL의 고가용성 지원

RDS for MS-SQL에서는 현재 미러링을 이용하여 고가용성을 지원하고 있습니다. 장애 조치 클러스터는 공유 스토리지 장애 시 복구가 불가능하고, AlwaysON 은 최신 기술이긴 하나 Enterprise 에디션에서만 사용할 수 있다는 단점이 있습니다.

Microsoft SQL Server의 미러링 구성에 필요한 서버는 [그림 2]와 같이 총 3대의 서버가 필요합니다. Active 서버 역할을 하는 주 서버와 Standby 서버인 보조서버, 복제 상태를 감시하는 감시 서버로 구성됩니다.

미러링 설정은 개별 데이터베이스 별로 적용되며, 데이터의 복제와 장애 감지, 장애 조치를 담당합니다. RDS for MS-SQL 은 미러링 설정을 바탕으로 별도의 Agent를 이용하여 미러링 기능이 제공하지 않는 데이터의 복제 및 장애 조치의 후속 작업을 처리합니다.

고가용성 DB 인스턴스의 생성

웹 콘솔에서 DB 인스턴스를 생성할 때, 고가용성 사용 여부를 체크하면 손쉽게 고가용성을 지원하는 Microsoft SQL Server를 사용할 수 있습니다.

선택된 가용성 영역에 주 서버가 생성되며, 주 서버가 설치되지 않은 가용성 영역에 보조 서버와 감시 서버가 설치됩니다.

생성이 완료된 고가용성 DB 인스턴스에 접속할 때는 반드시 접속 정보에 표시된 도메인을 사용해야 합니다.

장애 조치가 일어나면, 도메인에 바인딩된 A record 가 주 서버의 IP에서 보조 서버의 IP로 변경되므로 도메인에 바인딩된 IP를 직접 사용하면 안 됩니다.

데이터베이스 미러링 설정

미러링 설정은 개별 데이터베이스 별로 자동으로 구성됩니다.

고가용성 DB 인스턴스에 데이터베이스가 생성되면, 별도의 Agent에 의해 해당 이벤트가 감지됩니다.

이벤트가 감지되면 미러링 구성을 시작하게 되며, 웹 콘솔의 데이터베이스 항목에서 현재 데이터베이스의 복제 상태를 확인할 수 있습니다.

미러링 설정이 완료되어 [복제됨] 상태인 데이터베이스는 주 서버에 장애가 발생 시, 장애 조치가 일어나게 됩니다.

자동 장애 조치

고가용성을 지원하기 위해 주 서버에 장애가 발생하면 보조 서버가 주 서버의 역할을 대신하게 됩니다. 이처럼 장애가 발생한 시스템을 대체하는 행위를 장애 조치라고 합니다.

감시 서버에 의해 주 서버의 장애가 감지되면 장애가 발생한 주 서버는 스플릿 브레인 방지를 위해 정지되며, 보조 서버가 주 서버의 역할을 대신하게 됩니다.

접속을 위한 내부 및 외부 도메인의 A record는 장애가 발생한 주 서버에서 보조 서버로 변경되므로, 응용 프로그램의 변경은 필요하지 않습니다.

장애 조치가 완료되면, 고가용성 DB 인스턴스는 없어지고, 장애가 발생한 DB 인스턴스와 장애로 인하여 승격된 DB 인스턴스로 분리됩니다.

승격된 DB 인스턴스는 원래 DB 인스턴스의 이름 뒤에 장애 조치가 발생한 시각이 붙은 새로운 이름을 가지게 됩니다. 승격된 DB 인스턴스는 일반 인스턴스로 승격되므로, 서버의 부하가 적을 때, 고가용성 인스턴스로 변경하는 것을 추천드립니다.

마무리

장애란 언제 어떻게 발생할지 아무도 모릅니다. 이러한 장애에 대비하여 탄탄한 아키텍처로 시스템을 설계하는 것은 매우 중요합니다. 특히 사용자의 데이터가 저장되는 데이터베이스의 경우는 더더욱 그렇습니다. 고가용성 기능을 이용해 장애 상황에서도 서비스를 이어나갈 수 있도록 시스템을 설계해보는 것이 어떨까요?