RDBMS의 레플리케이션 전략

이번 포스팅은 PostgreSQL을 공부하다가 나온 Streaming Replication이 흥미로워서 이참에 다른 RDBMS의 레플리케이션 전략에 대해서 공부해보고 정리해보려고합니다. 

 

이 전략들을 공부하기 전엔 단순히 "RDBMS가 레플리케이션이라는 고가용성 전략이 있고 이걸 이용하면 데이터베이스 서버를 여러대 두면서 부하를 분산시킬 수 있다." 정도만 알고 있었습니다. 

 

이번 기회에 RDBMS의 다양한 전략들을 보면서 조금 더 깊이있는 공부를 한 것 같아서 조금 뿌듯합니다. 한번 정리해보도록 하겠습니다. 

 

Replication이란?

레플리케이션 (혹자는 리플리케이션이라고도 읽는 것 같습니다) 은 클러스터링에 비해 안정적으로 가용성을 높이면서 데이터베이스 한대로는 감당할 수 없었던 부하까지 분산시킬 수 있는 방법론입니다. 

 

기존 클러스터링은 하나의 DB스토리지에 여러대의 DB서버가 붙어서 부하를 분산시키기에는 적합했지만 DB스토리지가 죽어버렸을 때 다른 DB서버가 전부 죽어버린다는 점에서  가용성을 챙길 수는 없었습니다. 

 

데이터베이스 클러스터링, 레플리케이션에 대한 자세한 내용은 아래의 링크를 참고해주세요!

 

https://coding-review.tistory.com/309

데이터베이스 튜닝 방법 (Clustering, Replication, Sharding)

 

레플리케이션은 하나의 DB스토리지와 DB서버가 짝을 이룬 것이 여러개 있어서 하나의 DB스토리지가 죽어버리더라도 남아있는 DB스토리지들이 역할을 이어받으면서 가용성을 챙길 수 있었습니다. 

 

또한, 데이터베이스의 역할을 마스터노드, 슬레이브노드로 나누어서 마스터노드엔 쓰기작업을 진행하고 읽기작업은 슬레이브노드가 담당하면서 로드밸런싱까지 챙길 수 있었습니다. 

 

 

RDBMS의 레플리케이션 전략 (동기 레플리케이션, 비동기 레플리케이션)

RDBMS는 레플리케이션 전략으로 동기, 비동기 레플리케이션을 기본 전략으로 가져갑니다. 이 둘의 차이는 동기, 비동기의 차이와 매우 비슷합니다. 

 

동기 레플리케이션

동기 레플리케이션은 마스터 노드에 적힌 쓰기작업을 슬레이브 노드로 전파할 때 슬레이브 노드에 데이터가 적혔다는 것을 확인받은 다음에 마스터 노드를 재가동하는 방식입니다. 

 

이를 그림으로 표현하면 다음과 같습니다. 

 

 

비동기 레플리케이션

비동기 레플리케이션은 동기와 반대되는 특징을 가지고 있습니다. 

 

 

슬레이브 노드에서 커밋된 것을 마스터 노드가 확인하지 않고 그냥 일방적으로 데이터를 보내면서 마스터노드는 슬레이브노드에 데이터가 잘 적히는지 확인하지 않고 작동합니다. 

 

 

데이터베이스에서 둘의 차이점은 단순히 동기, 비동기의 차이처럼 속도가 빠르다거나 리소스를 많이 잡아먹는다거나 하는 문제를 조금 벗어난 새로운 차이점이 있습니다. 

 

바로 장애상황에서 데이터 유실의 관점에 대한 차이입니다. 

 

상황) 마스터 노드가 죽어버린 상황

• 동기 레플리케이션 : 동기 레플리케이션에서 마스터 노드가 죽어버리면 저절로 슬레이브 노드로 쓰기 연산을 전파하지 않아서 데이터 유실이 없습니다. 
  
  또한, 그렇기 때문에 마스터 노드가 죽었다는 것을 슬레이브 노드가 즉각적으로 인지할 수 있으며 추가적으로 다른 슬레이브 노드중 마스터 노드로 승격시킨다던가하는 장애회복 절차를 수행할 수 있습니다. 
• 비동기 레플리케이션 : 반대로 비동기 레플리케이션에선 어차피 마스터 노드는 슬레이브 노드로 쓰기 연산을 전파하고 슬레이브 노드의 응답을 받지 않았기 때문에 마스터 노드가 죽어버리면 그대로 데이터가 유실됩니다. 
  
  또한, 경우에 따라선 비동기 레플리케이션의 경우 마스터 노드가 죽었다는 정보가 슬레이브노드로 전파되는 것이 늦어 장애회복 절차가 조금 늦을 수  있습니다. 

 

때문에, 우리 서비스가 데이터 유실에 민감한 애플리케이션인지 아닌지 잘 따져보고 레플리케이션 전략을 선택해야 할 것같습니다. 

 

 

RDBMS에선 어떤 방법으로 레플리케이션을 구현했을까?

레플리케이션이 방법론이라면 각 RDBMS가 어떻게 레플리케이션을 구현했을지 궁금해서 MySQL과 PostgreSQL이 어떻게 레플리케이션을 구현했을지 알아보았습니다. 

 

MySQL

MySQL에선 비동기 레플리케이션, 세미동기 레플리케이션, 그룹 레플리케이션 이렇게 세가지가 구현되어있습니다. 

 

• 비동기 레플리케이션 : MySQL에선 마스터 노드에 binlog (binary log) 라는 로그파일이 있고 이 로그 파일엔 어떤 데이터가 조작되었는지 low level로 적혀있습니다. 이 binlog를 다른 레플리카에 전달함으로써 레플리카는 마스터 노드에서 벌어진 데이터 흐름을 파악할 수 있습니다. 
• 세미동기 레플리케이션 : 왜 동기 레플리케이션이 아니고 세미동기냐면 마스터노드가 슬레이브노드에 binlog를 전달하고 나서 단 하나의 슬레이브노드에서 응답이 온다면 그때 다시 마스터 노드를 동작하는 방식이기 때문입니다. 
  
  이렇게 함으로써 최소한의 지속가능성을 유지할 수 있고 최소한의 정합성을 지킬 수 있게 되었습니다. 
• 그룹 레플리케이션 : MySQL이 가진 독특한 레플리케이션 방식으로서 제가 알고 있던 내용의 레플리케이션 전략이었습니다. 
  
  노드들이 그룹을 이루고 마스터 노드가 죽었을 경우 슬레이브 노드의 투표를 통해 가장 상태가 좋은 슬레이브 노드를 마스터 노드로 승격시키는 레플리케이션 전략입니다. 

 

PostgreSQL

PostgreSQL에선 동기, 비동기 방식을 모두 지원하는데 Streaming Replication (이하 스트리밍 레플리케이션) 이라는 방식을 구현하고 있습니다. 

 

PostgreSQL에서 스트리밍 레플리케이션은 MySQL의 binlog와 마찬가지로 WAL (Write Ahead Logging) 라는 low level 로그를 레플리카에 실시간에 가까운 레이턴시로 전송하여 데이터의 정합성을 가지게됩니다. 

 

스트리밍 레플리케이션은 MySQL의 비동기 레플리케이션과 비슷하지만 조금 다른 성격을 가지고 있습니다. 비동기는 비슷하지만 동기 레플리케이션에서 거의 실시간에 가까운 데이터 동기화가 이루어지지만 단점은 마스터 노드에 과부하가 생긴다는 것입니다. 

 

 

스트리밍 레플리케이션이라는 이름에 걸맞게 데이터를 스트리밍하듯이 전송하기 때문에 자연스럽게 중앙집중형 네트워크를 구성하게됩니다. 

 

이런 단점 때문에 마스터 노드의 부하를 줄이기 위해 Cascade Replication을 구현하기도 하였습니다. 

 

 

 

 

마치며

이렇게 레플리케이션의 전략에 대해서 알아봤습니다. 기존에 알고있던 내용들에 살점을 더 붙인 느낌이 되어서 좋은 것 같네요. PostgreSQL은 엄청나게 넓은 커뮤니티 규모를 가지고 있어서 PostgreSQL에서 공부할게 엄청나게 많다는게 답답하긴 하네요. 

 

저는 이전에는 RDBMS = MySQL이라는 공식이 있었기 때문에 제가 알고있는 대부분의 지식들은 MySQL에 한정된 지식이라는 사실에 아직 제가 너무 부족하다는 것을 느끼게 되었습니다. 

 

이번 기회에 MySQL과 PostgreSQL의 차이 중에 MVCC를 이어 레플리케이션 전략까지 배워서 정말 뿌듯하고 좋습니다. 

 

긴 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요~

 

 

출처

https://blog.purestorage.com/purely-educational/synchronous-replication-vs-aynchronous-replication/

Synchronous Replication vs. Asynchronous Replication

https://www.cockroachlabs.com/blog/data-loss-prevention-during-outages-you-might-be-losing-data-without-knowing-it/

Synchronous and asynchronous database replication explained (& how data gets lost)

https://bitnine.tistory.com/576

[PostgreSQL]Streaming Replication의 이해 및 한계