안녕하세요.
오늘은 샤딩 (Sharding)에 대해 공부를 하게 된 김에 내용을 정리해 봤어요.
제가 공부한 글의 원문은 아래 링크에 있으니 원문을 보고 싶으신 분들은 아래 링크를 참고하세요! 본 글은 추가적인 자료 조사와 함께 원문을 제가 이해한 내용대로 재정리한 거예요.
4 Advanced Sharding Techniques Every Software Engineer Must Know
Beyond Basic Partitioning: A Deep Dive into Modern Sharding Methods
levelup.gitconnected.com
샤딩 (Sharding) 이란?
데이터베이스 샤딩은 대량의 데이터를 관리하기 위한 분산처리 기술 중 하나로 큰 데이터베이스를 여러 개의 작은 데이터베이스로 분할하는 프로세스를 의미해요. 이를 통해 데이터베이스의 성능, 확장성 및 관리가 개선될 수 있다고 하는데요. 이제부터 샤딩에 대해 하나씩 자세히 설명해 보도록 하겠습니다!
영어에서 'Shard'라는 단어는 "조각", 또는 "부분"을 의미하는데요. 데이터베이스에서의 샤딩은 누군가 단어를 정의함으로써 새롭게 생겨난 개념은 아니래요. 데이터의 양이 방대해지더라도 시스템이 문제없이 돌아갈 수 있게끔 하기 위해 데이터를 나누고 관리하기 위한 자연스러운 과정에서 시작된 것이죠.
우리가 아주 큰 도서관에서 책을 찾는다고 생각해 볼게요. 만약, 책이 저자별, 장르별, 주제별로 정돈되어 있지 않는다면 사막에서 바늘을 찾는 것과 같이 책을 찾는데 시간이 한참 걸릴 거예요. 샤딩은 우리가 쉽게 책을 찾을 수 있도록 책을 주제별로 정리하는 것과 같은 역할을 한답니다!!
도서관을 인터넷에 비유한다면 무려 10년 사이에 데이터의 양이 20배나 증가했다고 하네요! 그러니 책을 잘 정돈해 놓는 작업은 시간이 갈수록 더욱 더 중요해지겠죠?
과거의 샤딩
초기 단계의 데이터베이스 시스템에서는 유저의 ID나 알파벳 순서를 기준으로 샤딩을 수행했고 이 정도로도 충분했어요. 하지만 데이터의 양이 점차 증가하면서 이런 기초적인 방식으로는 문제가 발생했죠. 이를테면 알파벳으로 데이터베이스를 쪼개었을 때 균등하게 분배되어야 할 데이터가 한 쪽에 쏠리는 현상이 발생한 거죠. 결국 이러한 비효율성이 투입한 리소스 대비 낮은 성능을 낳게 되었어요.
요구 사항에 기반한 샤딩 기술
이러한 문제점이 부각됨에 따라 기술은 변화하기 시작했어요. 단순한 기준에 따라 데이터베이스를 분류하는 것이 아니라 전략적으로, 그리고 요구 사항과 실제 데이터를 기반으로 데이터베이스를 쪼개기 시작했죠. 결과적으로 많은 회사들은 이렇게 개선된 방식으로 샤딩을 진행하였을 때 성능이 향상된다는 점을 경험적으로 알 수 있었어요.
샤딩을 위한 개선된 접근 방법들
그렇다면 시스템의 요구 사항에 적합하면서도 성능을 개선하기 위해서는 어떤 부분을 고려해서 데이터베이스를 분산화해야 할까요?
Directory-based Sharding
디렉토리 기반 샤딩은 우리가 컴퓨터에서의 파일들을 여러 계층의 폴더에 나누어 저장하는 것과 같은 방식으로 데이터를 나누는 것을 의미해요. 만약에 우리가 컴퓨터에 있는 모든 파일들을 A와 B라는 이름의 폴더에 나누어 저장했다고 해볼게요. 샤딩이 적절히 잘 이루어졌다면 A와 B 폴더에는 각각 균등한 양의 파일들이 존재하겠죠. 이때 디렉토리 기반 샤딩에서는 각 파일들이 A 폴더에 있는지, 또는 B 폴더에 있는지에 대해 미리 정보를 생성해 놓아요. 그렇게 해서 특정 파일을 찾을 때 앞서 생성해놓은 정보를 통해 파일의 위치를 금방 찾을 수 있게 해주는 것이죠!
Lookup 테이블에 대해 들어보신 분이라면 이러한 논리적 흐름이 많이 유사하다고 느끼셨을 텐데요. 정확해요! 다만 A와 B 각각을 폴더가 아닌 데이터베이스 또는 하나의 샤드 (Shard)라고 생각해 주시면 될 것 같습니다.
정리하자면, 디렉토리 기반 샤딩의 핵심은 각 데이터 조각들이 어디에 존재하는지 지속적으로 확인해 주는 것이라고 보시면 돼요!
디렉토리 기반 샤딩의 장점은 각 샤드의 위치가 변경되거나 데이터 변경이 일어날 때, Lookup 테이블과 같은 역할을 하는 (각 파일이 A와 B 중 어느 폴더에 들어있는지에 대한 정보에 관한) 부분만 수정되면 전체 시스템에 영향을 주지 않는다는 점이에요. 실제로 무수히 많은 글들이 시시각각으로 생성되는 소셜 미디어에서 우리가 아주 빠르면서도 안정적으로 서비스를 이용할 수 있는 것은 이런 방식의 샤딩 덕분이라고 하네요!
Geo-based Sharding
혹시 외국 사이트에 접속을 하였을 때 느린 속도 때문에 고생해 본 적이 있으신가요? 해당 웹서버의 성능 문제일 수도 있지만 물리적으로 거리가 아주 멀 때에도 웹사이트에 대한 응답이 느려질 수 있어요. 따라서 요즘에는 서비스하는 지역이 여러 군데라면 이에 맞게 서버를 분산화하기도 해요. 데이터도 마찬가지겠죠?
위치 기반 샤딩은 데이터를 서비스 지역에 따라서 분산화하는 작업을 말해요. 위치 기반 샤딩은 통신에 대한 물리적 거리를 가깝게 하여 성능을 향상시킬 뿐만 아니라 각 서비스 지역의 데이터 관련 규제 사항을 쉽게 충족시킬 수 있도록 도와줄 수 있어요. 예를 들어 유럽과 한국의 개인정보 보호에 대한 규제가 다르듯이, 유럽에서 수집 가능한 정보들이 한국에서 수집할 수 없게 된다면 두 지역 간의 데이터베이스 구조나 데이터 자체에 차이를 둘 수 있겠죠. 국가마다 넷플릭스에서 볼 수 있는 콘텐츠에 차이가 있는 것도 이 때문일지도 몰라요.
Adaptive Sharding
적응형 샤딩, 또는 동적 샤딩은 말 그대로 인지되는 데이터 패턴에 따라서 샤딩 시스템의 구조들을 조정해나가는 방법을 말해요. 디렉토리 기반 샤딩과 위치 기반 샤딩이 사람에 의해 수동으로 개입되어 미리 정해진 룰에 따라 진행된다면, 적응형 샤딩은 실제 데이터의 패턴에 따라 지속적으로 변경되는 것이죠. 보통 스트리밍 플랫폼과 같이 트래픽이 급격하게 발생할 수 있는 서비스에 주로 적용된다고 하네요.
Hybrid Sharding
하이브리드 샤딩은 정적 샤딩 (디렉토리 기반 샤딩 및 위치 기반 샤딩)과 동적 샤딩을 결합한 샤딩 방법이에요. 복수개의 샤딩 전략을 동시에 채택함으로써 성능을 최적화하는 것이죠. 주로 많은 클라우드 서비스 제공 업체, 또는 글로벌 인프라를 보유하고 있는 서비스들에서 찾아볼 수 있어요.
그 외...
피처 (Feature, Column, Schema)로 분리하느냐, 또는 레코드 (Record, Row)에 따라 분리하느냐에 따라 Vertical Sharding과 Horizontal Sharding으로 방법론이 분류되기도 합니다. 따라서 샤드를 나누는 관점에는 단일한 기준이 있는 것이 아니라 다양한 기준이 있을 수 있다고 생각해주시는 게 좋을 것 같습니다.
샤딩을 어렵게 만드는 요인
실제 데이터와 요구 사항에 적합한 샤딩 전략을 적용하는 것이 성능 향상을 도모할 수 있을 것이라는 견해에는 아마 이견이 없을 것이라고 여겨지는데요. 그럼에도 불구하고 샤딩을 적용하는 것에는 다음과 같은 어려움이 따를 수 있습니다.
- 샤딩은 시스템 구조의 복잡성을 야기하고 만일 잘못 설계되었을 경우 데이터에 대한 접근성 문제와 시스템 성능 저하로 이어질 수 있음.
- 샤딩을 처음 구축하는 것과 이를 유지 및 보수하는 것은 전혀 다른 차원의 문제임. 복잡한 샤딩 시스템을 가지고 있는 회사의 경우 오로지 샤딩 시스템을 유지하는 것에 전념하는 전담 팀이 존재해야 할 정도.
- 데이터베이스 일관성에 대한 신뢰성을 보장하기가 더 어려워짐. 여러 지역에 샤드가 널리 분포되어 있고 특정 샤드의 값에 따라 나머지 샤드의 값도 함께 변경되어야 한다면 데이터 무결성을 지키기 어려워짐.
- 데이터는 정적이지 않고 지속적으로 생성됨. 이로 인해 샤드 간의 불균형이 발생한다면 데이터 분리 작업을 다시 하는 데이터 리밸런싱이 필요할 수 있음. 그리고 이 과정은 리소스를 아주 많이 사용하기에 연쇄적으로 다른 문제들을 야기할 수 있음.
- 데이터 백업과 복구에 대한 난이도를 증가시킴.
엄청난 양의 데이터를 관리하고 양질의 서비스를 제공하기 위해서는 샤딩이 반드시 필요하다는 사실은 이해하지만 실제로 구현 및 유지 보수를 하기에 복잡함이 있고 잘못 설계되었을 때의 문제점도 작지 않아 쉽게 생각할 수 있는 작업은 아닌 것 같네요. 하지만 요즘에는 샤딩을 쉽게 적용할 수 있는 데이터베이스들도 있고 문서들도 많이 찾아볼 수 있어서 공부를 해보기에 나쁜 상황은 아닌 것 같습니다.
추후에 시간이 된다면 MongoDB 같은 서비스에서 샤딩을 구현하는 과정에 대해서도 글을 작성해 보도록 하겠습니다.
감사합니다.