Sharding

MongoDB의 Query, Aggregation 혹은 Product들에 대하여 학습하다보면 "Sharding" 혹은 "Shard"라는 단어에 대하여 한 번쯤은 들어본 기억이 있을 것 입니다.
저 또한 MongoDB Certification을 위한 학습을 진행하면서, 그리고 회사에서 Atlas 결제를 위해 zoom Meeting을 진행하면서 sharding에 대해 적어도 10번 이상은 들어온 것 같습니다.
도대체 sharding이란 무엇인가 고민만 하다가, 드디어 sharding에 대해 알아보고자 블로그를 작성하게 되었습니다.

사전적 의미

Oxford Languages에 의하면 shard란 a piece of broken ceramic, metal, glass, or rock, typically having sharp edges. 라고 말 합니다.
번역해보자면 부서진 도자, 금속, 유리 혹은 돌 조각 처럼 날카로운 면을 가지는 하나의 조각이라고 합니다.
네이버 사전에서는 (유리, 금속 등의)조각, 파편이라고 정의하고 있습니다.

MongoDB에서의 의미

MongoDB에서 sharding에 대해 검색해보면 A database architecture that partitions data by key ranges and distributes the data among two or more database instances. Sharding enables horizontal scaling. See Sharding. 라고 적혀있는 문장을 쉽게 찾아볼 수 있습니다.
키 범위별로 데이터를 분할하고 둘 이상의 데이터베이스 인스턴스에 데이터를 분산하는 데이터베이스 아키텍처입니다. 샤딩은 수평 확장을 가능하게합니다. 라고 합니다.
즉, 데이터를 하나의 인스턴스에만 저장하는 것이 아니라 일정 기준에 따라 데이터를 분할하고, 그것을 여러개의 DB Instance에 분리하여 저장하는 "구조"인 셈입니다.

Sharding의 중요성

우리 앞에 하나의 데이터베이스가 놓여져있다고 생각해봅시다.
처리해야할 데이터 요청의 수가 적으면 DB가 다운 될 경우의 수가 별로 생기지 않을 것 입니다.
요청량이 적으니 정전 등이 일어나지 않는 이상 과열에 의한 다운이 일어날 일도 없겠죠.
하지만 서비스하는 어플리케이션이 잘 되어서 초당 수 만개, 수십 만개 씩 데이터 요청이 일어난다고 가정해봅시다.
데이터베이스에서는 계속해서 끊임없이 요청을 처리해야하고, 과열에 의한 오류, 혹은 그 외의 이유에 의해 DB가 다운 될 가능성이 높아집니다.
DB가 다운된다면, 유저들은 더 이상 데이터에 접근이 불가능하게 되고 그것은 곧 금전적 혹은 기타 손실을 불러일으키게 되겠죠.

일반적으로 데이터 분산처리를 하는데에는 크레 두 가지 방식이 존재합니다.
Vertical Scaling, Horizontal Scaling 즉 수직, 수평적인 확장입니다.

Vertical Scaling

단순하게 직역하자면 수직 확장의 개념입니다.
즉, 단일로 단순하게 DB의 크기를 확장시키거나, 고성능의 CPU를 사용하도록 함으로써 자체의 성능을 업그레이드 시키는 방식입니다.
이렇게 되면 한 번에 여러개의 데이터 요청이 들어오더라도 허용 가능 범위가 넓어지게 되겠죠 :)

Horizontal Scaling

수평 확장의 개념으로, 시스템 데이터 세트를 나누고 여러 서버에로드하여 필요에 따라 용량을 늘리기 위해 서버를 추가하는 방식입니다. 단일 시스템의 전체 속도 또는 용량은 높지 않을 수 있지만, 각 시스템은 전체 워크로드의 하위 집합을 처리하므로 잠재적으로 단일 고속 대용량 서버보다 더 나은 효율성을 제공합니다.

MongoDB는 이러한 두 가지 분산처리 방식 중 Horizontal Scaling, 즉 Sharding 기법을 통한 수평 확장이 가능하도록 서포트 하고 있습니다.

Shard Cluster

클러스터는 사전적 의미 그대로 어떤 꾸러미, 집합 등을 의미합니다.
몽고 디비에서는 실제 데이터의 꾸러미(도큐먼트 꾸러미)라고 이해하면 될 것입니다 :)

MongoDB 샤딩 된 클러스터 는 다음 구성 요소로 구성됩니다.

• shard : 각 샤드는 분할 된 데이터의 하위 집합을 포함합니다. 각 샤드는 복제본 세트 로 배포 할 수 있습니다.
• mongos :mongos클라이언트 애플리케이션과 분할 된 클러스터 간의 인터페이스를 제공하는 쿼리 라우터 역할을합니다. MongoDB 4.4부터지연 시간을 최소화하기 위해 헤지 읽기 를mongos지원할 수 있습니다 .
• 구성 서버 : 구성 서버는 클러스터에 대한 메타 데이터 및 구성 설정을 저장합니다.

Sharding을 사용했을 때의 장점

읽기 / 쓰기

MongoDB 는 분할 된 클러스터 의 샤드 에 읽기 및 쓰기 워크로드를 분산하여 각 샤드가 클러스터 작업의 하위 집합을 처리 할 수 있도록합니다.
더 많은 샤드를 추가하여 읽기 및 쓰기 워크로드를 클러스터 전체에서 수평으로 확장 할 수 있습니다.

샤드 키 또는 복합 샤드 키 의 접두사가 포함 된 mongos쿼리의 경우 특정 샤드 또는 샤드 집합에서 쿼리를 대상으로 지정할 수 있습니다. 이러한 대상 작업 은 일반적으로 클러스터의 모든 샤드에 브로드 캐스트 하는 것보다 더 효율적 입니다.

MongoDB 4.4부터 mongos는 지연 시간을 최소화하기 위해 헤지 읽기를 지원합니다.

저장 용량

클러스터의 데이터를 분산하여 각 샤드가 전체 클러스터 데이터의 하위 집합을 포함 할 수 있도록 합니다. 데이터 세트가 증가함에 따라 추가되는 샤드는 클러스터의 스토리지 용량을 증가시킵니다.

고 가용성

구성 서버 및 샤드를 복제본 세트로 배포하면 가용성이 향상됩니다.

하나 이상의 샤드 복제본 세트를 완전히 사용할 수없는 경우에도 샤딩 된 클러스터는 부분 읽기 및 쓰기를 계속 수행 할 수 있습니다. 즉, 사용할 수없는 샤드의 데이터에 액세스 할 수 없지만 사용 가능한 샤드에 대한 읽기 또는 쓰기는 계속 성공할 수 있습니다.

End of This Post

처음엔 샤딩이 대체 뭔질 모르니, 미팅에서도 해당 부분에 대해 쫓아가지 못 했고,
강의를 들으면서도 계속 아리송해서 다른 내용들까지 함께 어버버 하게 되는 경우가 생겼었습니다.
막상 공식 도큐를 읽고, 블로그들을 찾아보니 별 것 아닌 것이었네요:)

샤딩! 데이터를 샤드 키에 의해 나누어 클러스터로 저장하는 데이터베이스 구조!