도담하랑 개발팀의 데이터베이스 일기-2

이전 이야기

안녕하세요.

이전에 데이터베이스의 기본적인 buffer_pool_size와 index 튜닝에 이어서 저희 데이터베이스 튜닝 일기를 시작하려구 합니다.

전과 같이 buffer_pool_size와 index 튜닝을 하였지만 앞 글에 언급과 같이 수직적 확장은 결국에 제한점이 생깁니다.

그래서 저희가 생각한 해결책은 바로 Database-Clustering입니다.

초기에는 클러스터링 역시 고질적인 문제가 있기 때문에 (데드락..ㅠㅠ) 아직은 서비스가 그래도 초기이고 유저가 100만명이 되는 그런 서비스는 아니기 때문에 Mysql-ReplicationGroup을 생각하였습니다.

하지만 초기설계를 말끔히 해야 향후에 대한 유지보수와 시간을 아낄 수 있고 저는 “잘 만들면 손님이라도 온다” 라는 말을 좋아하고 자주 사용하기 때문에 유저입장에서 당장에는 못 느끼지만 언젠가 항상 빠른 서비스에 감동할 것이라 믿고 더욱더 생각을 하였습니다.

그래서 낸 결론이 바로 Database-Clustering입니다. 데이터베이스 클러스터링이란 여러 대의 컴퓨터 혹은 서버를 하나의 시스템으로 결합하여 데이터를 공유하고 처리 성능을 향상 시키는 방법 입니다.

즉, 기존에 데이터베이스가

위와 같이 처리를 하였다면 클러스터링은

위와 같이 내부적으로 동기식 복제를 통해 각각 데이터를 처리하고 데이터를 공유하게됩니다.

ReplicationGroup은 좋은 솔루션이지만, 클러스터링 처럼 Multi-Master구성이 아닌 Master-Slave 구조이기 때문에 모든 Slave가 Master에게 데이터를 요청하고 복제해야 하기 때문에 읽기 성능은 향상되지만 쓰기 성능은 저하되어 저희같이 각 종 이벤트와 구매가 일어나는 커머스 로직에는 매력적이지 않았습니다.

하지만 위 경우에 역시 무조건적인 솔루션이라고 볼 수 없습니다.

아직 해결해야할 점이 매우 많습니다.

1. Data Replication Lag:ReplicationGroup도 마찬가지지만 새로운 Slave혹은 Cluster Join Member를 생성하였을 경우 기존 멤버에게 데이터 복제를 요구합니다. 이는 향후 서비스가 커질수록 많은 시간을 요구합니다. 복제중인 서비스에 요청이 갈 경우 서비스에 대한 리스폰스가 오지 않고 오류로 반환될 수 있습니다. 대부분 이런 경우의 처리를 Deployer가 처리하지만 운영자 입장에선 무조건적인 신뢰를 할 수 없습니다.
2. Dead-Lock : 이것은 단일디비 혹은 ReplicationGroup에서도 발생하지만 Cluster의 경우 더 자주 발생하는 문제입니다. Cluster의 경우 모든 멤버가 읽기 업데이트 권한이 있기 때문에 같은 리소스에 트랜젝션이 걸릴 경우 기본적인인 Database규칙 First Commit Win 규칙에 위배되어 Dead-Lock이 걸릴 확률이 더 높아집니다.
3. BootStrap Crash -1 Error : 기본적으로 클러스터는 Statefulset으로 배포가 되어 관리가 됩니다. 물론 Sts(Statefulset)은 노드에서 관리가 되는 것이 아니기 때문에 노드업데이트와 별개로 문제될 일은 없지만 간혹 예상치 못한 문제로 Sts자체가 갑작스럽게 죽게되면 클러스터는 마지막 종료 노드를 파악하지 못한채 -1 로 재실행되지 않습니다. 따라서 일반적으로 Cluster는 3Node Deploy를 원칙으로 하는데요. 즉 Node 1,2 는 의견자고 3이 결정권자로서 밸런스를 이루는 것입니다. 하지만 모두 죽을 경우 Node1이 먼저 배포되고 Node1은 결정권이 없으므로 Join하지 못하고 재배포가 되지 않습니다.
4. Gcache Space : 내부 동기식 복제를 할 경우 복제할 데이터를 Gcache에 삽입합니다. 하지만 너무 많은 트래픽이 몰릴 경우 이 용량이 부족하여 메모리가 기하급수적으로 올라가거나 다운될 수 있습니다.

이러한 오류만 해결된다면 우리는 클러스터를 사용하는데에 있어서 두려움이 없습니다. 그럼 다음에는 저희가 이러한 문제를 어떻게 해결하였는지 알려드리겠습니다.