DB Replication (with 우아한 테크 코스's 테크톡)

들어가기에 앞서

이번 포스팅에서는 우아한 테크 코스에서 공유한 테크톡(리비의 DB Replication)을 보고 함께 공부해 보려고 합니다. 제가 취업을 준비하던 시기부터 회사를 다니고 지금까지도 항상 보면서 많이 배우고 있는 유튜브 채널중 하나입니다. 그래서 앞으로는 우테코의 테크톡 뿐만 아니라 카카오, 네이버, 당근마켓, 인프런 등등 빅테크 기업들이 공유하는 기술 세미나 영상을 보면서 정리하며 공하는 글을 자주 올리려고 합니다. 

 

이번 편은 Database Replication에 대한 영상입니다. 저 역시 이전에 다니던 회사에서 Database Replication을 구성해 두었는데, 복제 지연을 어떻게 해결할 것인가에 대해 고민해 본 적이 있습니다. 우테코에서는 어떻게 데이터베이스 복제를 다루고 공부하는지 궁금해서 선택하였는데, 저의 경험과 테크톡의 내용을 잘 정리해 보겠습니다. 

 

---

 

대용량 트래픽을 수용할 수 있는 고가용성 서버를 구축하는 방법

이렇게 서버 1대와 데이터베이스 1대를 운영하고 있는 서비스에서 '초대박 이벤트'를 하게 된다면, 순간적으로 많은 트래픽이 유입될 것이 예상되기에 버스트(burst) 트래픽을 수용할 수 있도록 대비를 해야 합니다.

 

 

고가용성을 확보하는 방법 - Scale Out ?!  Scale In ?!  뿐일까?

일반적으로 가장 쉽게 생각 되는 부분은 서버의 사양을 늘리는 Scale Out 방식과 혹은 서버의 갯수를 늘리는 Scale In을 가장 많이 생각할 것 같습니다. Scale Out과 Scale In을 한다고 해서 틀린 문제 해결 방법 이라 생각하지 않습니다. 저 역시 이 두 방법을 당연히 가장 먼저 생각할 것 같습니다. 또한 서버는 당연히 Scale Out 혹은 Scale In을 해야 합니다. 

제가 이번 글에서 공유하고 싶은 주제는 꼭 Scale Out, Scale In 말고도 DB Replication 방안도 있다는 것을 공유하고 싶었습니다.

고가용성을 위해 서버와 데이터베이스를 무한정 늘리는 방법 말고도 DB Replication이 적용 되어 있지 않다면 DB Replication을 적용해 보면 무한정 서버를 늘리는 것 보다 더 좋은 효과를 얻을수 있을거라고 저는 생각합니다.

 

---

DB Replication (복제 서버)는 어떨까? 

이렇게 DB를 복제하고 Master DB에는 쓰기 작업만, Replication DB에는  읽기 작업만 하도록 설정할 수 있습니다. DB replication을 통해 Write-Only와 Read-Only를 분리하면 다음과 같은 주요 이점을 얻을 수 있습니다:

1. 성능 향상

• 부하 분산: Write 작업은 Master DB에서만 처리하고 Read 작업은 Replica DB에서 처리함으로써 부하를 분산시킬 수 있습니다.
• 읽기 성능 개선: 읽기 요청이 Replica로 분산되면서 Master DB의 부하가 줄어들고, 읽기 작업이 병렬적으로 처리될 수 있습니다.

2. 확장성

• 일반적으로 고부하 쿼리는 Read 작업에서 많이 발생합니다. 또한 Read 작업이 증가할 경우, Replica를 추가로 생성하여 처리 능력을 확장할 수 있습니다.

3. 가용성

• Replica DB를 통해 읽기 요청을 처리할 수 있어, Master DB에 장애가 발생하더라도 읽기 작업은 계속 수행될 수 있습니다.
• 여러 Replica를 두면 장애 발생 시에도 서비스 중단 시간을 최소화할 수 있습니다.

 

5. 트랜잭션 충돌 최소화

• Master DB에서 읽기 작업을 분리하면, Write 트랜잭션과 Read 트랜잭션 간의 충돌 가능성이 줄어들어 전체 성능이 향상됩니다.

즉, 부하분산이 아니더라도 고가용성을 얻을 수 있다는 장점이 있습니다. 조금 더 풀어서 설명한다면, 꼭 대용량 트래픽을 받는 상황이 아니더라도 평소에도 데이터베이스 성능을 개선할 수 있고, 데이터베이스에 장애가 발생하더라도 다른 복제된 서버가 정상적으로 운영되고 있기에 장애에 대한 피해를 최소하 할 수 있습니다.

 

---

DB 복제는 어떻게 동작하는 걸까?

일반 적으로 DB복제는 바이너리 로그 방식을 통해서 복제가 됩니다. 바이너리 로그는 데이터베이스에서 발생하는 모든 변경 사항이 기록된 바이너리 로그 파일 입니다.

 

복제를 위해서는 레플리카 서버는 마스터 서버에 복제 정보를 요청해야 한다. 레플리카 서버는 복제 요청시 약속된 데이터 타입으로 데이터를 요청해야 한다.

 

MySql 복제 타입은 두 가지가 있습니다.

• 바이너리 로그 파일 위치 기반 복제 : 파일명과 위치를 기반으로한 물리적인 방식
• 글로벌 트랜잭션 아이디 기반 복제 : 유니크한 식별자 매핑을 통한 놀리적인 방식

 

복제 방식 : 바이너리 로그 파일 위치 기반 복제 

해당 방식은 특정 바이너리 로그 파일과 position의 조합 타입으로 복제 정보를 요청한다.

 

 

하지만 바이너리 로그 파일 위치 기반 복제는 마스터 서버에 장애가 발생했을때 문제가 발생할 수 있습니다. 장애가 발생하기전 마스터 서버에만 바이너리 로그 파일을 소유하고, 장애 발생으로 인해 레플리카 서버가 마스터로 승격하였을때, 해당 마스터 서버에는 바이너리 로그 파일을 가지고 있지 않는 동기화 이슈가 있습니다. 즉, 특정 복제 이벤트가 다른 데이터베이스에서 동일한 위치에 저장되는 것이 보장되지 않습니다. 따라서 장애가 발생하면 오히려 데이터 복구를 어렵게 만들수 있습니다.

 

 

 

복제 타입 : 글로벌 트랜잭션 아이디 기반 복제 

글로벌 트랜잭션 아이디 기반 복제는 복제 시스템 내의 모든 DB가 복제 이벤트를 동일하게 식별할 수 있는 방식 입니다. GTID를 사용하게 되면 모든 데이터베이스에서 하나의 이벤트를 동일한 식별자로 알 수 있게 된다. 따라서 장애 상황에서도 유연하게 대처가 가능합니다.

( ** GTID : 복제 시스템 내에 모든 DB가 공유하는 유니크한 트랜잭션 ID)

 

 

---

복제 동기화 방식 (feat. 복제 이벤트를 얼마나 기다려야 할까?)

복제 동기화 방식에는 크게 3가지가 있습니다.

1. 비동기 복제 방식
2. 반동기 복제 방식
3. 동기 복제 방식

 

비동기 복제 방식

반동기 복제

동기 복제

 

---

복제 지연에 대한 이슈

Relicas 서버에 데이터를 복제할때 동기방식이 아니라면 복제 지연이 발생할 수 밖에 없습니다. 

• 비동기 방식 : 복제지연 발생 
• 반동기 방식 : 복제지연 발생
• 동기 방식 : 복제지연 없음

일반적으로 DB Replication 구조를 사용하게 된다면 Master DB는 쓰기 전용, Replica는 읽기 전용으로 사용하게 된다. 그렇다면 내가 데이터베이스에 값을 저장하고 그 값을 읽으려고 하는데, 복제에 4초가 걸린다면, 내가 읽으려고 하는 값은 Replica DB에 없을 것이다. 이러한 문제를 복제 지연 이라고 한다. 

 

Q. 복제 지연을 일부러 해결하지 않는 경우 (knowned Issue 처리)

일반적으로 복제는 정말 짧은 시간안에 됩니다. 하지만, 아무리 기업의 좋은 스펙의 운영서버라도 간헐적으로 오랜시간 복제 지연이 발생할 수 있습니다. 서비스의 종류에따라 데이터를 저장했음에도, 아주 잠시 짧은 시간 데이터를 읽는데 실패해도 큰 영향이 없는 서비스가 있는 반면, 데이터를 읽지 못한다면 서비스 이용에 큰 문제가 발생할 수 있는 서비스도 있습니다. 

 

ex) 복제지연이 늦어도 큰 문제가 되지 않는 비즈니스 : 별스타그램에 피드를 올렸지만 업데이트가 늦어지는 경우

ex) 복제지연이 늦어도 큰 문제가 되지 않는 비즈니스 : 쿠퍙의 한정판 상품이 이미 품절되었는데 지연으로 인해 구매 가능하다고 표시되는 경우

 

 

Q. 복제지연이 발생하면 안되는 비즈니스는 어떻게 해야 할까?

복제지연이 발생하면 안되는 비즈니스에서는 캐싱을 도입하는 것을 고려해 보면 좋을것 같습니다. 하지만 Redis 역시 Replication 구조로 사용이 가능합니다. DB Replication이 필요한 기업의 운영 서비스라면 당연히 Redis역시 여러 대 서버를 운영하고 있을 것이며, Replication 구조일 경우가 큽니다. 즉, Redis 역시 복제 지연 가능성이 있습니다. 하지만 데이터베이스 보다는 복제 지연이 발생할 가능성이 적기 때문에 캐싱을 적용해 보면 문제를 많이 개선할 수 있을것 같습니다.