본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
https://fastcampus.info/4n8ztzq
안녕하세요 :)
오늘은 "50일의 기적 AI 환급반_ 대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 " 챌린지에 도전하는 서른번째 날입니다.
스물 아홉번째 날에는 유니크 아이디 생성기가 필요한 이유에 대해 배웠었는데요. 오늘은 과연 어떤 내용들을 배울 수 있을지 공부하고 포스팅 하도록 하겠습니다.
오늘 학습할 내용의 제목은,
Part 5. 모놀리틱 서비스 분해 > Ch 1. 데이터베이스의 고가용성과 확장성 확보를 위한 샤딩 >
01. 왜 샤딩이 필요한가
입니다.
🔢 모놀리틱 서비스의 데이터베이스 확장을 위한 첫걸음: 왜 샤딩이 필요한가?
- 이번 포스팅에서는 모놀리틱 아키텍처를 분해하는 여정 중 데이터베이스의 고가용성과 확장성을 확보하기 위한 핵심 기술인 샤딩(Sharding) 에 대해 다뤄보겠습니다. 특히 채팅 시스템의 메시지 테이블을 중심으로, 왜 샤딩이 필요하며 어떤 방식으로 접근해야 하는지를 실제 사례와 함께 정리해보았습니다.
🧱 기존 아키텍처의 한계
- 파트4까지의 구현에서는 NGINX를 활용한 게이트웨이, 인증 서비스 및 푸시 서버의 분리, 메시지 순서를 보장하기 위한 시퀀스 발급기까지 구성되었습니다. 현재 DB는 리플리카를 통한 복제 구조로 구성되어 있지만, 여전히 쓰기 작업은 하나의 프라이머리 DB에 집중되고 있는 구조입니다.
- 문제는 바로 여기에 있습니다. 서비스가 수평 확장을 하더라도, DB는 수평 확장을 하지 못해 결국 병목이 생기게 됩니다. 캐시, Kafka, 서비스 인스턴스는 얼마든지 늘릴 수 있지만, 쓰기 부하는 오직 한 대의 DB가 처리해야 하므로 병목 현상과 장애 리스크가 커지는 것이죠.
🧩 샤딩이 필요한 이유
- 쓰기 부하 분산: 채팅 서비스의 가장 큰 쓰기 부하는 단연 ‘메시지 테이블’입니다. 사용자가 많아질수록 메시지 쓰기 요청이 폭증하고, 이는 단일 DB가 감당하기 어려운 수준까지 치솟을 수 있습니다.
- 저장 용량 한계 극복: RDB는 이론적으로 무한한 데이터를 저장할 수 있는 것처럼 보이지만, 테이블당 처리 가능한 물리적 용량에 한계가 있습니다. 테라바이트 수준의 메시지가 저장될 수 있기 때문에 단일 DB는 저장 용량 측면에서도 금세 한계에 도달하게 됩니다.
- 장기적인 확장성 확보: 파티셔닝만으로는 논리적 분산은 가능하더라도, 물리적 부하는 여전히 하나의 DB에 몰릴 수 있습니다. 샤딩은 물리적으로 DB를 분리함으로써 궁극적인 확장을 가능하게 합니다.
💬 샤딩 시 고려사항
- 조인 불가: 물리적으로 분리된 테이블 간 조인이 불가능하므로, RDB의 장점 중 하나를 포기해야 합니다. 따라서 샤딩 전에는 조인 로직을 제거하거나 역정규화 작업이 선행되어야 합니다.
- 샤딩 키 설정: 샤딩 시 데이터를 어느 노드에 저장할지를 결정하는 기준값이 필요합니다. 이를 샤딩 키라고 하며, 일반적으로 유저 ID나 채널 ID 등이 활용됩니다.
- 라우팅 로직 필요: 데이터가 분산되어 있기 때문에, 어떤 노드로 요청을 보낼지를 결정하는 라우팅 전략이 필수입니다.
🧠 샤딩 방식들
- 레인지 샤딩: 범위 기준으로 데이터를 분산합니다. 기존 시스템에 적용할 때 유용하며, 데이터 마이그레이션 없이 적용할 수 있다는 장점이 있습니다.
- 모듈러 샤딩(Modular Sharding): 샤딩 키를 나누는 수의 나머지를 기준으로 데이터를 분산합니다. 구조는 단순하지만, 노드가 추가될 때마다 데이터 재배치가 필요하므로 확장성 측면에서는 한계가 있습니다.
- 논리 샤드(Logical Shard): 버킷과 매핑 테이블을 활용해 유연하게 노드 추가 및 재배치를 관리할 수 있습니다. 다만, 구현이 복잡하고 운영 비용이 커질 수 있습니다.
📡 우리 시스템에서는?
- 우리는 채널 ID를 기준으로 모듈러 샤딩을 적용할 계획입니다. 채널 ID의 홀짝 여부에 따라 메시지를 1번 혹은 2번 노드로 분산 저장하게 되며, 이를 통해 채널 단위의 부하 분산 효과를 기대할 수 있습니다.
- 앞으로는 ShardingSphere를 활용한 실습을 먼저 진행하고, 이후에는 Spring Boot 기반의 커스텀 라우팅 구현도 실험해볼 예정입니다.
- 샤딩은 단순히 DB를 여러 개로 나누는 기술이 아니라, 비즈니스 로직, 데이터 설계, 인프라 운영까지 전반을 다시 설계해야 하는 큰 변화입니다. 그만큼 비용과 리스크가 따르지만, 그만큼 얻을 수 있는 이점 또한 큽니다.
- 이번 샤딩 적용 과정을 통해 단지 성능을 올리는 기술적 수단을 넘어서, 데이터와 시스템을 보는 시야를 확장할 수 있는 계기가 될 것 같습니다.
