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

오늘 포스팅에서는 데이터베이스 튜닝 방법인 Clustering, Replication, Sharding에 대해서 알아보도록 하겠습니다. 

 

제가 설명할 이 세가지는 바로 분산시스템을 구현하는 방법들입니다. 분산시스템 혹은 분산환경이라고 불리는데, 여러개의 데이터베이스로 쪼개는 작업을 일컫습니다. 즉, MVCC와 마찬가지로 특별한 기술이 아닌 방법론으로 이 방법론들을 개발자들은 Architecture라고 하는 듯 합니다. 따라서 이 셋을 구현하는 방법은 정말 여러가지로 많고 우리는 그중에서 가장 대표적인 것들을 위주로 알아볼 예정입니다. 

 

Clustering

Clustering (이하 클러스터링)은 하나의 데이터베이스 인스턴스 혹은 시스템 서버를 더많은 과정으로 쪼개는 작업입니다. 보통 데이터베이스 클러스터 안에서 다중 데이터베이스 인스턴스는 보통 마스터라고 불리는 단 하나의 데이터베이스에 의하여 관리됩니다. 

 

클러스터링을 구현하는 것이 특히 큰 시스템에서 필요할지도 모릅니다. 데이터베이스 서버를 하나만 두는것은 모든 고객의 요청을 핸들링하기 쉽지않습니다. 이러한 이슈를 해결하기 위해 다중 데이터베이스 서버를 병렬로 사용하는 것이 시스템적으로 필요합니다.

 

이러한 기술을 사용하는 것은 더 많은 유저를 핸들링하거나 시스템적인 실패를 극복하는데 수많은 이점을 가져다줍니다. 이 아키텍처의 단 한가지 주요한 단점은 시스템을 구현하는 것이 복잡하다는 것입니다. 

 

데이터베이스 클러스터링의 장점

• 시스템의 load balancing (이하 로드 밸런싱) 을 잘 잡아준다 : 로드 밸런싱은 여러개의 다른 리소스에 의한 수많은 주어진 일들을 분산처리 하는 것입니다. 이러한 작업의 목적은 전체적인 실행 과정에서 시스템을 더 효율적으로 만들기 위함입니다. 
• 더 많은 고객을 유치할 수 있다 : 수많은 기업들이 데이터베이스 클러스터링에 투자하는 가장 주된 이유는 확장성 때문입니다. 더 많은 데이터베이스 서버를 늘림으로써, 회사는 전 세계의 수많은 유저들을 더 쉽게 핸들링을 할 수 있습니다. 
• 시스템 전반의 데이터 여분을 남길 수 있다 : 데이터를 여분으로 남겨두면 유저가 한번에 많이 몰려도 여분의 데이터를 가지고 처리할 수 있기 때문에 병목 현상이 일어나지 않습니다. 
• 애플리케이션 다운에 대한 리스크를 극복할 수 있다 : 만약 애플리케이션이 하나의 데이터베이스 서버만을 두고 서비스한다면, 그 서버가 죽어버렸을 때 전체 서비스가 죽어버려서 금전적으로 큰 손실을 일으킬 수 있습니다. 하지만 클러스터링을 통해 데이터베이스 서버를 많이 늘리면 하나가 죽더라도 옆에거 쓰면 되니까 안정적입니다. 

 

데이터베이스 클러스팅의 단점

가장 큰 단점은 SAN이라 불리는 Storage area Network인 DB 스토리지가 하나밖에 없기때문에 이 DB스토리지가 장애가 나는 경우, 모든 데이터베이스 서버가 죽어버리면서 모든 데이터가 소실 혹은 유실되는 상황이 발생할 수 있습니다. 

 

또한 모든 DB 서버를 active로 놓고 돌리는 경우 이전 하나의 서버가 부담하던 부하를 여러개의 서버가 나눠 감당하므로 CPU, Memory 자원의 부하도 적어지게 됩니다. 

 

하지만 DB 스토리지가 여러개의 DB서버를 공유하기 때문에 병목현상이 일어날 수 있고, 이전보다 많은 비용이 투자되어야 한다는 단점이 있습니다. 

 

따라서 이 경우를 대비하여 여러대의 DB스토리지를 구축해놓을 필요가 있습니다. 

 

이러한 해결책으로 등장한 것이 바로 Replication입니다. 

 

 

Replication

데이터베이스 레플리케이션은 단순히 얘기해서 DB스토리지를 잔뜩 카피해서 데이터 손실 혹은 유실을 막는 방법입니다. 그래서 모든 유저가 같은 레벨의 정보를 공유할 수 있죠. 

 

사용자는 마스터 DB서버에 DML 작업을 하면 마스터 DB는 그 데이터를 Slave 쪽에 데이터 복제를 합니다. 이를 통해 DB스토리지가 한대여서 발생할 수 있는 데이터 손실을 방지할 수 있습니다. 

 

하지만 이러한 방식의 단점은 Slave인 DB서버가 늘게 된다는 점입니다. 

 

그래서 마스터 DB서버에는 INSERT, DELETE, UPDATE 작업을 하고, Slave DB서버에는 SELECT 를 함으로써 DB서버의 부하를 분산시킬 수 있습니다. 

 

 

Replication의 장점

• 데이터베이스 부하를 줄여준다 : 복제된 데이터 덕분에 서버 전반에 걸쳐서 확장할 수 있습니다. 복제된 데이터는 어떤 하나의 DB서버가 데이터를 위해 쿼리를 사용하면 압도되는 상황을 제거할 수 있습니다. 
• 효율성인 측면에서 우수하다 : 쿼리때매 생기는 부하가 적어진 서버는 향상된 성능을 기대할 수 있습니다. 
• 높은 유용성 : 같은 데이터를 여러 서버에 분배하는 것은 높은 유용성을 가져다 줍니다. 이것은 만약 한 DB서버가 죽어버리면, 전체 시스템이 성능을 유지할 수 있습니다.  

 

Replaction의 단점

• 데이터 로스가 생길 수 있다 : 데이터 로스는 데이터베이스의 올바르지 못한 데이터나, 업데이트가 복제될 때 레플리케이션 동안 일어날 수 있습니다. 결과적으로 중요한 데이터가 삭제될 수 있습니다. 이러한 일은 데이터의 퀄리티를 증명하는데 사용되는 primary key가 오작동하거나 올바르지 못한 경우에 일어날 수 있습니다. 
• 데이터 부정합문제 : 위의 경우와 비슷하게 올바르지 못한 복제된 데이터는 다른 데이터와 일치하지 않는 경우가 생길 수 있습니다. 
• 여러대의 서버가 필요하다는 점 : 여러대의 DB스토리지를 운영한다는 것은 유지하는데 코스트가 많이 드는 작업입니다. 또한 데이터가 너무 많은 경우에는 여러대의 Slave DB서버에서 데이터를 찾는 시간이 오래걸릴 수 있습니다. 

 

이러한 문제를 해결하기 위해 나온 방법이 바로 Sharding입니다. 

 

 

Sharding

Sharding (이하 샤딩) 은 여러대의 데이터베이스에 걸친 하나의 데이터셋을 분산하기위한 방법입니다. 그리고 샤딩은 여러대의 기기에 데이터를 저장할 수 있게 도와주죠. 샤딩은 큰 데이터셋을 더 작은 크기인 chunk (이하 청크)에 분리해서 담습니다. 그리고 여러개의 데이터 노드에 저장하죠. 

 

여러 기기에 데이터들을 분산시키는 것과 비슷하게 샤드된 데이터베이스는 하나의 기기가 할 수 있는 것 보다 더 많은 요구를 처리할 수 있습니다. 

 

샤딩은 수평적인 확장으로 알려진 확장의 형태입니다. 추가적인 노드들은 load를 분할하기 위해 채워집니다. 수평적인 확장은 빅데이터를 처리하기위해 거의 제한없는 확장성을 할 수 있게 해줍니다. 

 

이러한 수평적인 확장은 수직적인 확장과 대조적인데, 사실 성능적인 부분에서 강력한 향상을 원한다면 수직적인 확장이 더 도움이 됩니다. 예를 들어 CPU를 더 늘린다거나, RAM을 더 늘린다거나 스토리지 저장용량을 더 늘린다거나 이런 작업이 성능적으로는 더 우위를 점합니다. 

 

하지만 이런 수직적은 확장은 비용이 많이들고 무한히 늘릴 수 없기 때문에 한계가 있죠. 그런 한계를 맞이했을 때 샤딩을 고려해볼만 합니다. 

 

왜냐하면 샤딩은 단점이 하나도 없는 혁신적인 아키텍처가 아닙니다. 샤드를 세팅하고 유지하는데 굉장히 복잡하고 오버헤드가 발생하기 쉽습니다. 따라서 샤딩을 고려하기 전에 다른 대안책을 고려한 후에 이후 그럼에도 추가적인 성능이 필요하다면 그때 고려해볼만 합니다. 

 

먼저 샤딩을 고려하기전 대안책을 몇가지 소개해드리도록 하겠습니다. 

 

1. 수직적인 확장 : 애플리케이션을 가장 간단하고 강력하게 성능향상시킬 수 있는 것이 바로 수직적인 확장입니다. RAM을 더 늘리고, CPU를 더 늘리는것 말입니다. 이렇게 수직적으로 확장하게 되면 사용가능한 DB스토리지가 늘어나고, 데이터베이스가 감당할 수 있는 트래픽도 늘어납니다. 때문에 샤딩을 고려하기전 가장 간단하게 생각할 수 있는 부분입니다. 
2. 서비스별로 분화시키기 : 서비스별로 분화한다는 의미는 쉽게 설명해서 MicroService Architecture (이하 MSA)를 고려하라는 의미입니다. 혹은 DB스토리지를 클라우드 저장소로 옮겨버리는 작업도 이 카테고리에 포함됩니다. 
3. 클러스터링 / 레플리케이션 : 샤딩을 고려하기전 레플리케이션이 고려되지 않았다면 레플리케이션을 생각해볼만 합니다. DB스토리지와 DB서버를 복제함으로써 읽기성능만큼은 늘린 스토리지, 서버만큼 향상되게 되어있습니다. 

 

위의 것들을 다 고려했음에도 추가적인 성능을 원한다면 그때서야 샤딩을 생각해볼만 합니다. 

 

샤딩의 장점

• 읽기/쓰기 작업의 수율이 올라간다 : 저는 수율이라고 해석하는게 이해하기도 좋고 해석하기도 편한데 어떤 분들은 throughput이라고 단어 그대로 말하는것이 더 이해되시는 분들도 있을겁니다. 아무튼 여러개의 샤드를 통해 데이터셋을 분산시킴으로써 읽기와 쓰기실행에 필요한 capacity가 single shard로 구현한 것 보다 더 향상됩니다. 
• 스토리지 capacity가 증가됩니다 : 앞서 설명했던 것과 비슷하게 많은 수의 샤드를 증가시킴으로써 전반적인 스토리지 capacity를 증가시킬 수 있습니다. 이렇게 하면 거의 제한없는 확장성을 맛볼 수 있습니다. 
• 높은 유용성 : 샤드는 두가지 방면에서 높은 유용성을 제공합니다. 첫번째는 각각의 샤드가 복제된 세트이기 때문에 각각의 데이터는 복제된 상태가 유지됩니다. 두번째로는 만약 전체 샤드가 사용불가능이 된다면, 데이터는 분산되어있기 때문에 전체 데이터베이스는 다른 샤드에 대한 스키마의 일부분을 가지고 부분적으로 기능을 유지할 수 있습니다. 

샤딩의 단점

• 쿼리 오버헤드가 발생한다 : 각각의 샤드화된 데이터베이스는 어떻게 적절한 샤드로 쿼리 실행이 유도되는지 알고있는 기기와 서비스로 분리되어야합니다. 이러한 작업은 모든 실행에 추가적인 레이턴시가 요구합니다. 게다가 데이터들은 다수의 샤드를 통해서 수평적으로 분할된 쿼리를 요구한다면 라우터는 결과물을 다같이 병합하거나 각각의 샤드들을 가져와야 하기때문에 하나하나 실행을 할 때마다 꽤 비싼 코스트가 들어가고 느린 응답시간을 초래합니다. 
• 관리가 복잡하다 : 단하나의 샤드화되지않은 데이터베이스는 그 데이터베이스 하나만 유지하는데 코스트가 들어갑니다. 데이터베이스가 샤드화 되어있다면 각각의 샤드를 유지하기위해 적잖은 관리가 필요합니다. 거기다가 이 데이터베이스들이 레플리케이션까지 사용되고 있다면 각각의 데이터들을 업데이트 하는것이 복제된 노드들 전반에 걸친 중복된 작업을 하게 됩니다. 
• 기반시설을 유지하기위한 코스트가 증가한다 : 샤딩은 싱글 데이터베이스 서버보다 기기나 계산하는 능력이 추가적으로 요구합니다. 각각의 추가적인 샤드들은 높은 코스트들을 가져옵니다. 분산된 데이터베이스 시스템의 비용이라는 것은 특히 최적화를 빼먹는다면 성능상 상당히 안좋은 결과를 초래할 수 있습니다. 

 

샤딩을 구현하는 방법에는 크게 세가지가 있습니다. Hash Sharding, Dynamic Sharding, Entity Group Sharding 이렇게 세가지이죠. 각각에 대해 자세히 알 필요는 없을 것 같습니다. 간단하게 짚고 넘어가도록 하겠습니다. 

 

Hash Sharding

샤드의 수 만큼 Hash 함수를 사용해서 나온 결과에 따라 DB 서버에 저장하는 방식으로 정말 구현이 간단하다는 것이 장점이 됩니다. 

 

단점은 확장성이 낮다는 것인데 만약 DB서버가 추가될 경우 Hash 함수가 변경되어야 하므로 기존에 저장된 데이터의 정합성이 깨지게됩니다. 

 

이러한 확장성을 해결하기 위해 나온 것이 바로 Dynamic Sharding입니다. 

 

 

Dynamic Sharding

Dynamic Sharding은 로케이터 서비스를 이용하여 테이블 형식의 데이터를 바탕으로 샤드를 결정해서 적절히 저장하는 방식을 말합니다. 레코드를 기준으로 일정한 간격을 두고 각각의 간격을 Shard Key로 부여하여 저장하는 방식입니다. 

 

장점으로는 Hash Sharding과 달리 단순히 레코드의 추가에 따른 키만 추가해주면 되므로 확장이 쉽다는 것이지만 단점으로는 로케이터 서비스가 단일 장애점이 되므로 로케이터 서비스에 장애가 발생하면 나머지 샤드 또한 문제가 발생하게 됩니다. 

 

 

Entity Group Sharding

앞서 설명한 두개의 Sharding은 NoSQL에 최적화되어있지만 이 방식은 RDBMS와 잘 어울리는 방식입니다. 엔티티 그룹으로 샤딩을 하는 것은 연관성이 있는 (관계를 가지고 있는) 엔티티를 한 샤드에 두는 방식입니다. 

 

장점으로는 같은 샤드에 있는 데이터를 조회할 때는 효과적이지만, 다른 샤드에 있는 데이터를 함께 조회할 때는 오히려 성능이 떨어지는 단점이 있습니다. 

 

 

여기까지 Clustering, Replication, Sharding에 대해서 알아봤습니다. 논문을 읽다가 Sharding이라는 단어가 나와서 사전지식 공부겸해서 블로그 포스팅을 해봤습니다. 

 

너무 깊은 곳까지 들어와버린 상황인데... 면접에서 이런건 당연히 안물어볼 것 같구요. 신입때는 안쓴다 뿐이지 샤딩이라는 이 튜닝 방식 그리고 앞서 설명했던 클러스터링과 레플리케이션은 실무에서 자주 볼 것 같은 예감이 듭니다. 지금 공부해둬서 나쁠 것 없지요. 

 

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

 

 

출처

https://www.harperdb.io/post/what-is-database-clustering

What is Database Clustering?

https://www.techtarget.com/searchdatamanagement/definition/database-replication

What is Database Replication and How Does it Work?

https://www.mongodb.com/features/database-sharding-explained

Database Sharding: Concepts & Examples