Offcanvas

How To / 개발자 / 데이터센터 / 빅데이터 | 애널리틱스 / 애플리케이션

칼럼 | DB 분산 처리 기법 '샤딩'을 신중하게 수용해야 할 이유

2021.07.08 Lee Atchison   |  InfoWorld
막 시작한 SaaS 서비스 신생업체는 애플리케이션을 어떻게 확장할지에 대해서는 거의 생각하지 않는다. 물론 언젠가 확장이 필요할 날이 올 것이라 생각하고 성장을 반영한 재무 계획을 세우지만 초기부터 확장성을 염두에 두고 애플리케이션을 설계하는 경우는 드물다. 그보다는 대부분 지금 바로 판매할 수 있는 기능을 완성하는 데 초점을 둔다.
 
그러나 확장에 대해 생각해야 할 시점은 처음 시작할 때, 첫 고객이 서비스에 가입하기 전이다. 기업이 기능을 하나 둘 추가함에 따라 가입하는 고객도 늘어나고 비즈니스는 성장한다. 비즈니스가 성장하면 확장이 걱정거리가 된다.
 
ⓒ Getty Images Bank


확장의 필요성은 새로운 SaaS 서비스가 리소스 용량, 구체적으로 데이터 액세스 리소스 용량 한계에 다다를 때 명확하게 드러나는 경우가 많다. 많은 경우 데이터베이스가(어느 데이터베이스 기술을 사용하든) 나무 작아서 증가하는 수요를 감당하지 못하고 특정 지점 이상으로는 확장이 되지 않는다.
 
이 문제는 어느 데이터베이스 기술을 사용하든, 그리고 성장의 여지를 위해 얼만큼 큰 서버나 기타 인프라를 확보했든 관계없이 발생할 수 있다. 조만간 확장 문제에 직면하게 된다.
 
리소스 확장을 가로막는 벽이 명확하게 드러나고 확장을 위한 중대한 의사 결정이 필요해지면 애플리케이션 확장 역량을 강화하기 위해 샤딩(여러 개의 병렬 데이터베이스에 걸쳐 데이터를 분할하고 각 데이터베이스에 비즈니스의 한 세그먼트가 저장됨)을 조기 솔루션 중 하나로 선택하는 경우가 많다. 이유는 여러가지다.

1. 데이터를 여러 세그먼트로 분할하는 것은 데이터 리소스 문제를 해결하기 위한 간편한 방법으로 보인다. 데이터베이스 한 개로는 너무 작아 트래픽을 감당하지 못한다면 2개, 3개, 아니면 4개를 사용하면 된다!

2. 애플리케이션 데이터를 샤딩하고 나면 향후 트래픽 증가 시 동일한 접근 방법을 사용해서 애플리케이션에 병렬 데이터베이스를 더 추가해 계속 간단히 확장해 나갈 수 있을 것이다.
 
샤딩에 대해, 그리고 샤딩이 초기 데이터베이스 확장 문제를 해결하는 데 어떻게 사용되는지에 대해 더 구체적으로 살펴보자.
 

간단한 샤딩 예

샤딩이란 정확히 무엇일까? 일반적인 SaaS 사용례를 보면 고객이 애플리케이션과 상호작용하고, 이후 애플리케이션이 데이터베이스에 저장된 데이터를 사용한다. 고객의 수가 증가하면 애플리케이션에 대한 부하도 커진다. 보통 이 부하를 처리할 서버를 더 추가하는 방법으로 애플리케이션의 용량을 늘리는 편이 더 쉽다. (물론 한계가 있다. 그 한계에 대해서는 다음에 별도의 기사로 다룰 기회가 있을 것이다.) 
 
그러나 특정 고객 수에 이르면 갑자기 데이터베이스가 확장의 제약 요인이 된다. 데이터베이스가 늘어난 고객을 효과적으로 처리할 수 없고 결국 애플리케이션에 가용성, 성능 및 기타 문제가 발생한다. 이 과정이 그림 1에 나와 있다.
 
그림 1, SaaS 애플리케이션이 한계에 다다랐을 때. ⓒ IDG

데이터베이스가 특정 크기와 용량에 이르면 더 이상 크기를 키우기가 어렵거나 불가능해진다. 대신 데이터베이스를 복수의 병렬 데이터베이스로 분할하고 고객층을 여러 데이터베이스로 나누는 방법을 선택할 수 있다.
 
그림 2와 같이 고객을 두 개의 별도의 데이터베이스로 나누면 늘어난 고객을 문제없이 처리할 수 있게 된다. 각 데이터베이스에는 특정 고객을 지원하는 데 필요한 모든 데이터가 들어가 있지만 개별 고객은 여러 데이터베이스에 걸쳐 분할된다.
 
그림 2. 단순한 샤딩을 적용한 SaaS 애플리케이션. ⓒ IDG

여러 데이터베이스에 걸쳐 어떻게 데이터를 분할하고, 애플리케이션 내에서 어느 데이터베이스에 어느 고객의 데이터가 있는지를 어떻게 알 수 있을까? 일반적으로 샤딩 키를 사용해서 특정 데이터 집합이 포함된 데이터베이스를 확인한다. 샤딩 키는 고객 ID와 같은 정보인 경우가 많다. 일부 고객 ID를 한 데이터베이스에 할당하고 다른 고객 ID를 또 다른 데이터베이스에 할당함으로써 특정 고객의 모든 데이터를 하나의 데이터베이스에 넣을 수 있다.

따라서 각 고객에 대해 하나의 데이터베이스가 모든 고객 요청을 처리하는 데 사용되며, 신규 고객을 적절한 규모의 새 데이터베이스에 추가할 수 있다.
 

샤딩이 잘못되는 경우

그렇다면 이 접근 방식에서 무엇이 문제일까? 고객이 성장을 시작하게 되면 문제가 시작된다. 고객은 애플리케이션 사용량이 증가하면 더 많은 스토리지를 사용하고 더 많은 리소스를 소비하기 시작한다. 어느 순간 샤드 중 하나에 과도하 부하가 걸려 한 샤드의 고객 일부를 다른 샤드(부하가 상대적으로 낮은)로 옮겨야 한다. 해당 고객의 모든 데이터를 새 샤드에 복사한 다음 고객 ID가 새 샤드를 가리키도록 해야 한다.
 
이 과정은 간단치 않다. 특히 고객이 인지할 만큼의 다운타임을 유발하지 않으면서 이 작업을 하고자 할 경우 더욱 어렵다. 고객의 애플리케이션 액세스에 영향을 미치지 않으면서 막대한 양의 데이터를 옮기려면 어떻게 해야 할까? 답은 보통 맞춤형 툴을 제작하는 것이다. 이 툴은 일반적으로 만들기 어렵고 실행에는 위험이 따른다. 그림 3은 “너무 큰 고객”이 데이터베이스 하나에 과부하를 일으켜 이 고객을 새로운 데이터베이스로 옮겨야 하는 상황에서 이 프로세스를 보여준다. 
 
그림 3. ⓒ IDG

그 다음에 발생하는 문제는 한 고객이 너무 커져서 단독으로 전체 데이터베이스 샤드가 필요하게 되는 경우다. 이 상황에서 몸집이 조금 더 커지면 어떻게 될까?
 
ⓒ IDG

이 고객을 옮길 곳이 없게 된다. 또 다른 확장의 제한, 지금의 샤딩 전략으로 해결할 수 없는 한계에 직면한 것이다.
 
리파티셔닝, 리밸런싱, 편중된 사용, 크로스-샤드 보고, 파티션된 분석 문제에도 대응해야 한다. 그러나 샤딩 메커니즘의 가장 큰 과제는 빠르게 변화하는 데이터 집합 크기에 대처해야 할 필요성과 샤드 간에 데이터를 옮겨야 할 필요성이다.
   

샤드, 할 것인가 말 것인가?

꼭 필요한 게 아니라면 하지 말 것을 권한다. 데이터를 샤드로 쪼개는 대신 서비스 및 기능별로 데이터를 분할하는 등의 다른 전략을 활용해서 데이터 확장에 대처할 수 있다.
 
그러나 샤딩이 불가피한 경우도 있다. 따라서 반드시 샤딩을 해야 한다면 다음 사항에 유의한다.

1. 필요한 시점보다 훨씬 이전에 샤드를 설정한다. 낙관적인 관점에서 샤딩의 필요성을 예측하고 실제 사용량이 샤딩이 필요한 정도로 커지기 전에 샤딩하라.

2. 샤딩 키를 신중하게 선택한다. 샤드는 독립적인 동시에 균형도 맞아야 한다. 고객 ID를 사용하는 것은 좋은 아이디어처럼 보이지만(독립적인 데이터 집합을 쉽게 만들 수 있게 해줌) 각 고객의 규모는 다양하므로 고객 ID를 기반으로 샤드 균형을 맞출 경우 문제가 발생할 수 있다. 다른 공통적인 리소스를 기반으로 샤딩할 수도 있지만 구체적인 답은 애플리케이션의 비즈니스 로직과 요구사항에 따라 크게 좌우된다.

3. 샤딩을 프로덕션에 구현하기 전에 샤드를 관리하기 위한 툴을 구축한다. 예상보다 훨씬 더 빨리 툴이 필요한 시점이 온다. 툴은 샤딩된 개별 요소(고객 등)를 샤드에서 다른 샤드로, 투명하고 빠르고 효율적으로 옮길 수 있어야 한다. 툴은 확장 사고 중에 여러 리소스를 신속하게 리밸런싱할 수 있어야 한다. 또한 샤드 크기 조정이 잘못될 경우 알리기 위한 분석이 필요하다. 

4. 다른 방법으로 데이터를 분할하는 방법을 진지하게 고려한다. 데이터를 중앙 데이터 저장소가 아닌 개별 서비스 및 마이크로서비스 내에 저장하는 방법을 고려한다. 데이터 집합이 작을수록 샤딩의 필요성은 낮아지며 필요할 때 샤딩을 더 간편하고 효율적으로 관리할 수 있다.

현대 애플리케이션은 성장한다. 사용량, 크기, 데이터의 복잡성, 애플리케이션의 복잡성, 애플리케이션을 관리하기 위해 필요한 사람의 수와 조직의 크기까지, 모두 성장하기 마련이다. 성장에 따라오는 과제를 무시하다가 시기를 놓치고, 이후 당면한 상황을 해결하기 위해 쉽고 빠른 방법을 선택하기 쉽다. 그러나 데이터 샤딩에서 아키텍처의 선택이 확장의 방해 요소가 아닌 도움이 되도록 하기 위해서는 계획과 철두철미한 실행이 중요하다. editor@itworld.co.kr 
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.