데이터베이스의 다중화

시스템 설계 시 고려해야 하는 것 중에 데이터베이스의 다중화도 빠질 수 없다.

도커로 직접 데이터베이스를 구성하여 운영을 했었는데 다중화는 꼭 해야 될 것이라고 생각했다. 찾아보니 MHA(Master High Availability)라는 솔루션을 알게 되었고, 혼자 구성하고 테스트를 하다가 Master 서버가 다운되었을 때 Slave 서버가 승격하지 못하는 상황에 부딪히고 원인과 해결 방법을 찾지 못한 채 더 이상 진행을 하지 못했었다. (다시 한번 도전해보도록..) - 관련 깃허브

본 글에서는 데이터베이스의 다중화가 무엇이고 다중화를 진행하였을 때 동작 방식 그리고 장애가 발생하였을 때 어떻게 해결할 수 있는지에 대해 알아보려고 한다.

---

 

데이터베이스의 다중화와 필요성

데이터베이스의 다중화는 말 그대로 데이터베이스를 여러 대로 구성하여 과부하를 방지하고, 가용성을 높이는 것이다.

 

사용자가 많은 어플리케이션 시스템에서 만약 데이터베이스 한대로 운영하고 있다고 가정해보자.

하루에도 수십만 건에서 수백만 건의 트랜잭션이 발생할 수 있는데, 이는 높은 트래픽과 데이터 처리량을 한 대의 데이터베이스가 모두 처리하기에는 성능적으로 한계가 있을 수 밖에 없다.

만약 데이터베이스가 과부하에 걸리게 된다면 응답 시간이 느려져 사용자는 불편함을 느낄 수 있고, 데이터베이스가 다운되어 서비스 자체를 사용할 수 없는 상황이 발생하게 된다.

 

이러한 경우에 대비하여 데이터베이스의 다중화는 옵션이 아닌 필수가 되었다.

 

데이터베이스의 다중화 구성과 동작 방식

다중화 구성 요소는 크게 두 가지로 이루어져 있다.

Primary (주 서버)

다중화 구성에서 중심 역할로, 읽기/쓰기 연산을 지원하는 서버이다.

모든 변경 사항은 Replica 서버로 복제되도록 동기화 작업을 진행한다.

 

Replica (부 서버)

Primary 서버의 데이터를 복제하고 읽기 연산만을 지원하는 서버이다.

여러 대의 Replica 서버를 추가하여 읽기 작업에 대한 성능이 높일 수 있다. 시스템에서 주로 읽기 연산의 비중이 쓰기 연산의 비중보다 높기 때문에 일반적으로 여러대의 Replica 서버를 구성하는 것이 좋다.

만약 Primary 서버의 장애가 발생하였을 때, 일부 Replica 서버는 Primary 서버로 승격될 수 있는데 이를 Failover라고 한다.

https://jonghoonpark.com/2023/05/01/%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%88%98%EC%97%90-%EB%94%B0%EB%A5%B8-%EA%B7%9C%EB%AA%A8-%ED%99%95%EC%9E%A5%EC%84%B1-2

어플리케이션에서 쓰기 연산 발생하면 요청은 Primary 서버로 전송된다.

Primary는 해당 요청에 대한 작업을 진행하고 나서, 변경된 데이터를 Replica 서버에 복제한다. (복제 방식에 대하여 추가적으로 알아본다.)

 

읽기 연산이 들어오면 Replica 서버 중 하나로 요청을 전송한다. 로드 밸런서 또는 데이터베이스 클라이언트가 이 역할을 담당한다. 여러 Replica 서버에 읽기 요청이 분산되기 때문에 부하가 균등하게 이루어진다.

 

대략적인 동작 흐름은 위와 같은데, 이 과정에서 다양한 문제와 장애가 발생할 수 있다.

예를 들어 Primary 서버에서 쓰기 작업이 완료되었는데 변경된 데이터가 Replica 서버로 복제되는 시간이 지연되거나, 특정 서버에서 장애가 발생하는 경우이다. 다음 내용을 통해 알아보자.

 

장애가 발생하였을 때 동작 방식과 해결 방법

다중화를 구성했는데, 데이터베이스 서버 중 한대가 다운되었을 때 상황을 한번 알아보자.

Primary 서버 1대, Replica 서버 1대

1. Replica 서버가 다운된 경우

모든 읽기 작업을 Primary 서버가 처리하게 된다.

즉, 데이터베이스의 모든 연산을 Primary 서버가 처리하게 되는 것으로 이는 Primary 서버의 부하가 증가할 수 있게 된다. 따라서 Replica 서버가 복구되기 전까지 시스템의 성능이 저하될 수 있으며 최악으로 Primary 서버 또한 다운될 수도 있다.

 

2. Primary 서버가 다운된 경우

해당 Replica 서버가 새로운 Primary 서버로 승격(Failover)되는데, 이 과정에서 일시적으로 데이터베이스의 연산 처리가 진행되지 않을 수 있다. 승격 된 서버는 모든 연산을 처리하게 되며, Replica 서버는 새롭게 추가된다.

 

Primary 서버 1대, Replica 서버 여러대

우선 이 경우는 Replica가 1대인 경우보다 조금 더 안정적인 구조이다.

 

1. Replica 서버 중 하나가 다운된 경우

다른 Replica 서버들이 읽기 연산을 계속 처리할 수 있다. 다운된 Replica 서버는 복구된 후 다시 데이터 동기화를 진행하고 읽기 연산을 처리한다.

 

2. Primary 서버가 다운된 경우

Replica 서버 중 하나가 자동으로 Primary 서버로 승격된다.

승격된 서버는 쓰기/읽기 작업을 모두 처리하게 되고, 나머지 Replica 서버들은 승격된 서버로부터 데이터를 복제 받아 Replica 서버로 계속 동작한다. 다운된 Primary 서버가 복구되면, 이는 Replica 서버로 재 구성된다.

---

위에서 데이터베이스 다중화 구성에서 장애가 발생하는 경우에 대해 어떻게 동작하는지 확인해보았다.

하지만 동작 방식에도 데이터 복제 지연, 데이터 손실 및 데이터 불일치 등 다양한 상황과 문제들이 발생할 수 있다. 그러한 경우에 또 어떠한 방식으로 해결하는지 확인해보자.

복구 스크립트(Recovery Script)

데이터베이스 시스템에 문제가 발생하였을 때 데이터를 복구하거나 시스템 상태를 정상으로 되돌리기 위해 사용되는 자동화된 스크립트이다. Primary 서버가 다운되어 Replica 서버 중 하나가 Primary 서버로 승격될 때, Replica 서버에 대한 데이터가 최신 상태가 아닐 경우에도 사용된다.

 

다중 마스터(Multi-Master)

Primary 서버가 여러대로 구성되어 동시에 데이터 읽기/쓰기 작업을 처리할 수 있는 데이터베이스 복제 구조이다.

모든 Primary 서버는 쓰기와 읽기 작업을 동시에 처리할 수 있으며, 동기화 작업을 통해 데이터를 공유하여 일관성을 유지한다. 또한 하나의 Primary 서버에 장애가 발생하더라도 다른 Primary 서버가 요청을 처리할 수 있기 때문에 서비스 중단을 방지한다.

 

원형 다중화(Circular Replication)

Primary 서버들이 서로 원형 형태 구조로 구성되어 데이터를 복제하는 구조이다.

각 Primary 서버들은 자신이 받은 데이터에 대한 변경 작업(쓰기/업데이트)을 진행하면 자신과 연결된 Primary 서버에게 해당 정보를 전달하도록 한다.

대표적으로 MySQL에서 원형 다중화 구조를 지원하는데 어떻게 동작하는지 확인해보자.

---

복구 스크립트, 다중 마스터, 원형 다중화 (NDB 클러스터에 대한 내용) 동작 방식에 대해 상세하게 보충해보기

https://dev.mysql.com/doc/refman/8.4/en/mysql-cluster-basics.html

MySQL :: MySQL 8.4 Reference Manual :: 25.2.1 NDB Cluster Core Concepts

 

---

참조

가장 면접 사례로 배우는 대규모 시스템 설계 기초