데이터베이스 이중화 전략과 AWS Aurora RDS에서의 설정

해외에서는 stanby보다 passive라는 말을 많이 쓰는 것 같다.

 

상용 DB를 막 만져봤던 뉴비 시절에 "우리 서비스의 데이터베이스는 HA 구조야" 라는 말을 들었었다.

 

그 당시에는 아무것도 몰라서 "오 상용서비스에서는 이렇게 구성하는구나"하고 넘어갔었다.

 

몇 년이 지난 지금, 그 기억을 곰곰이 떠올려보니 HA는 구조가 아니라 High Availability, 고가용성을 말하는 것이었다.

 

고가용성은 구조를 의미하는게 아니라, 예상치 못한 중단 없이 지속적으로 운영될 수 있는 능력을 의미하는 개념이다.

 

데이터베이스의 고가용성을 보장하기 위해 여러 가지 이중화 전략이 사용된다. 

 

이중화는 단순히 하나의 시스템이 고장나더라도 다른 시스템이 그 기능을 대신할 수 있도록 구성하는 것이다. 

 

전회사에서는 DB 고가용성을 제공하기위해서 Active/StandBy 구조를 사용하고 있었다.

 

Active/StandBy 구조 외에도 이중화 전략에는 다양한 방식이 있다.

 

하나씩 알아보고 AWS RDS에서는 어떻게 처리할 수 있는지 정리해보자.

 

왜 뜬금없이 AWS RDS에 대한 이야기를 하냐면, 고가용성과 이중화에 대해 생각해본 계기가 되어서다.

 

데이터 베이스 이중화 전략

1. Active - Active

 

여러 DB 인스턴스가 동시에 활성 상태로 작동하여 읽기와 쓰기 작업을 처리하는 방식이다.

 

로드밸런서를 통해 트래픽을 최적화할 수 있으며 장애 시에도 서비스가 중단되지 않게 운영이 가능하다. 

 

다만, 이중화 되어있는 DB들이 동일한 데이터를 다룰 때에는 데이터의 동기화 전략까지 고민해야 한다. 

 

동기화 전략과 충돌에 대한 롤백 전략 까지 필요하기 때문에 관리 복잡성은 상승한다.

 

2. Active - StandBy

 

Active/Standby 구조는 하나의 DB 인스턴스가 활성 상태로 작동하고,

 

다른 인스턴스는 대기 상태로 있다가 활성 인스턴스에 장애가 발생하면 대기 인스턴스가 활성화되는 구조이다.

 

장점으로는 비용 면에서 저렴하고 StanBy DB가 비동기적으로 동기화되기 때문에, 관리포인트도 적다.

 

다만 장애 조치(Fail Over)가 발생하면 대기 인스턴스가 활성화시켜, 장애에 대응해야한다.

 

이 과정이 수동일수도 있다는 점이 큰 단점이고, 조치 과정에서 다운 타임이 발생할 수도 있다.

 

그런데 생각해보니까 이전 회사에서의 데이터 베이스는 이중화 되어있었지만 같은 데이터센터에 있었다.

 

그럼 이중화의 의미가 있나 싶다.

 

AWS RDS의 고가용성을 위한 전략

AWS RDS에서도 고가용성을 보장하기 위해 기본적으로 Multi-AZ 방식을 채택하고 사용한다.

전체 개요 : https://aws.amazon.com/ko/rds/features/multi-az/

Multi-AZ 클러스터 배포

대상: Aurora가 아닌 일반 RDS 클러스터

자세한 내용: AWS 문서

 

 

AWS RDS Multi-AZ 클러스터 배포는 DB 엔진의 네이티브 복제 기능을 사용한다.

 

이때 Writer DB는 하나 이상의 Reader DB의 ACK를 받아야 커밋하는 Semi-sync 방식을 사용한다.

 

이 방식은 instance 방식에 비해 쓰기 대기 시간이 짧다는 장점이 있다.

 

Semi-sync 복제: Writer DB가 커밋을 완료하기 위해 하나 이상의 Reader DB의 확인(ACK)을 받아야 하는 방식입니다. 이는 데이터를 안정적으로 복제하면서도 성능을 최적화합니다.
쓰기 대기 시간: Semi-sync 방식은 완전 동기식 복제보다 쓰기 대기 시간이 짧아 성능이 향상됩니다.
읽기 트래픽 분산: Reader DB가 읽기 작업을 처리하여 Writer DB의 부하를 줄이고 전체 성능을 향상시킵니다.

 

설정 방법은 DB를 생성할 때, 아래의 옵션을 선택만하면 된다.

 

 

위와 같이 설정하면 아래와 같이 RDS에서 자동으로 생성 AZ에 DB를 배포해준다.

 

 

Aurora에서의 Multi-AZ

대상 : Aurora로 설정된 MySQL, PostgreSQL

자세한 내용: AWS 문서

 

앞서 언급한 일반적인 RDS의 DB와는 다른 구조로 동작한다.

 

Aurora는 6개의 데이터 복사본을 3개의 가용 영역(AZ)에 분산 저장하여 내구성을 보장하며,

 

장애가 발생하면시 자동으로 읽기 전용 복제본이 새로운 기본 인스턴스로 승격된다.

이를 통해 데이터 손실 없이 빠른 복구가 가능하며, 스토리지는 자동으로 확장된다.

 

장애 대응에 개발자가 관여할 필요가 없다는 가장 큰 장점이 있다.

 

기본적으로 Aurora는 기본 RDS DB보다 다양한 기능을 제공하기 때문에 요금이 살짝 비싸다.

 

Aurora에서도 클러스터를 생성할 때  MultiAZ 설정을 켜두면 된다.

 

 

Aurora Global Database를 사용한 AWS 리전 간 고가용성

최악의 경우 AZ 전체가 마비될 경우를 생각한다면 Multi Region 전략을 생각해볼 수 있다.

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html

 

 

 

데이터를 마스터링하는 하나의 기본 AWS 리전과 및 최대 5개의 읽기 전용 보조 AWS 리전으로 구성된다.

 

쓰기 연산을 기본 AWS 리전의 기본 DB 클러스터에서 시작하고 다른 리전의 DB에 전파한다.

 

Aurora는 일반적으로 1초 미만의 대기 시간으로 전용 인프라를 사용하여 보조 AWS 리전에 데이터를 복제합니다.

 

마치며

AWS RDS의 기능을 이것저것 사용해보면서, 완전관리를 맡겨버리면

 

DB 관리자의 업무가 많이 줄어들수밖에 없구나란 생각이 들었다.

 

옛날부터 완전관리 솔루션을 쓰는게 사람을 쓰는 것보다 싸다는 이야기가 공공연하게 돌긴했었다.

 

그러면서 백엔드 개발자의 역할이 DB 관리까지 일부 추가가 되었고..

 

많은 부분이 추상화되면서 사용성이 올라가고 스페셜리스트로 성장하기 어려워지는데

 

개발자에게는 모든 분야의 스페셜리스트 역량을 요구하는 곳도 늘어나는 것 같다.

 

개발 트렌드를 잘 읽으면서 시류에 잘 따라가야겠다는 생각이 들었다.