DDD와 샤딩(feat.gpt)

오늘 어제 학습한 DDD를 복습을 했다.
DDD에는 중요한 개념이 2개가 나오는데
다음과 같다.
바운디드 컨텍스트: 컨텍스트의 경계를 나눈다?
이름에서 부터 알수 있듯이 경계를 나눈것이다. 보통 컨텍스트는 문맥이라고 한다.
그렇다면 DDD가 말하는 문맥이란 무엇일까에 대해 고민을 해보았다.
어떤걸 경계로 나눈것이 좋을까?
그래서 생각한것이 도메인이다. 도메인에 대한 영토, 분야, 영역, 범위를 뜻하는 단어

라 한다고 한다.
결국 바운디드 컨텍스트는 도메인별로 나눈것을 말한다는 것을 알 수 있다.
그러면 어그리게이트는 어떤걸까?
얘가 어떤 뜻을 내포하는지는 정확히 모르겠으나 내가 생각할때는 트랜잭션의 범위로 나눈것을 말하는 것같다.
튜터님께 크로스 체크를 해서 내가 이해한게 맞는지 확인해보니 맞다고 하셨다.
결국 바운디드 컨텍스트는 도메인별로 어그리게이트는 트랜잭션 범위로 나누는 거라 생각한다.
루트 어그리거트는 다른 바운디드 컨텍스트와 통신하는 최상위 역할을 가진게 아닐까 생각이 든다.
DDD는 요정도 이해하고 나중에 따로 공부하면 좋을거 같아 일단은 요정도 까지만 이해를 하였다.

다음은 샤딩이다.
나는 대규모 스트림 처리를 들었는데 공부해야 하는 키워드들이 굉장히 많았다.
그중에서 샤딩을 선택해서 공부를 했다. chat gpt의 도움으로 샤딩이 어떤건지 대략적으로 알 수 있었다.
샤딩은 쉽게 말해 데이터베이스를 수평적으로 분할시킨것을 말한다고 한다.
일반적으로는 비슷한 속성끼리 묶은다고 한다. 이걸 수평샤딩이라고 한다는데 거기까지는 잘 모르겠구
일단 수평적으로 분할시키는 정도만 이해를 하였다.
수평적으로 분할이 되니 
장점이 아무래도 성능이 향상이 될거라 생각이 든다. 왜냐하면 분할된 환경을 제공하기 때문에 데이터는 일반적인 환경보다는 
더 적게 들어갈거라 생각한다. 그러니 성능이 좋아지는게 아닐까 생각이 든다.
chat gpt로 찾아보니 다음과 같다고 한다.

1. 성능 향상
   • 부하 분산: 데이터와 트래픽을 여러 샤드로 분산시킴으로써, 단일 데이터베이스에서 발생할 수 있는 성능 병목 현상을 해결할 수 있습니다. 각 샤드가 독립적으로 쿼리 및 트랜잭션을 처리하기 때문에 전체 성능이 향상됩니다.
   • 읽기/쓰기 속도 향상: 트래픽이 많을 경우, 여러 샤드에서 병렬로 작업을 처리하여 데이터베이스의 처리 속도가 빨라집니다. 예를 들어, 읽기 전용 서버를 각 샤드에 배치해 읽기 성능을 더욱 높일 수 있습니다.
2. 수평 확장성 (Horizontal Scalability)
   • 데이터베이스가 커짐에 따라 샤드를 추가하는 방식으로 수평 확장이 가능합니다. 시스템이 커지더라도 성능 저하 없이 새로운 샤드를 추가하여 시스템을 확장할 수 있어 유연합니다.
   • 이는 수직 확장(기존 서버 성능 향상)과 달리 물리적 서버의 용량이 증가함에 따른 한계를 피할 수 있습니다.
3. 고가용성 (High Availability)
   • 샤딩은 데이터베이스를 여러 서버에 분산하여 저장하므로, 하나의 샤드에 문제가 발생해도 다른 샤드는 정상적으로 운영됩니다. 장애 발생 시에도 서비스의 가용성을 유지할 수 있습니다.
   • 여러 지역에 샤드를 배포하면, 특정 지역에서 발생한 장애가 다른 지역으로 영향을 미치지 않게 됩니다.
4. 지리적 분산
   • 데이터베이스를 여러 지역에 배포하여 지역별로 사용자들이 더 빠르게 데이터를 접근할 수 있습니다. 예를 들어, 유럽, 아시아, 미국에 각기 다른 샤드를 배치하여 지역에 맞는 데이터를 제공할 수 있습니다.
5. 데이터 용량 관리
   • 대용량 데이터베이스를 관리하는 데 유리합니다. 하나의 데이터베이스 인스턴스에 비해 수십 배, 수백 배 많은 데이터를 효율적으로 저장하고 관리할 수 있습니다.

근데 생각해보니 전부 성능 향상이랑 연관이 되는게 아닌가 생각이 든다.
그렇다면 단점은 무엇일까?
내가 생각할때 단점은 트랜잭션 관리라고 생각한다. 트랜잭션 관리라고 생각하는 이유는 여러 분산된 환경이 사용되어지기 때문에
어떤 데이터를 롤백을 시키는 행위는 어떤 특정한 db를 롤백을 시킬지 정확하게 알 수 없다는 점이다.
결국 그렇게 되면 쿼리문도 어려워질거라 생각한다.
이번에도 chat gpt에 물어보니..

1. 복잡성 증가
   • 샤딩을 구현하고 관리하는 데 복잡성이 증가합니다. 데이터베이스 설계, 분산 트랜잭션 처리, 데이터 이동 및 관리 등 여러 요소에서 추가적인 관리가 필요합니다.
   • 특히, 여러 샤드를 다루는 시스템은 복잡한 쿼리와 데이터 조합을 처리해야 하므로 애플리케이션 측에서도 로직을 추가로 구현해야 할 수 있습니다.
2. 쿼리 복잡성
   • 조인 문제: 샤딩된 데이터베이스에서는 샤드 간에 조인(JOIN)을 수행해야 하는 경우 성능이 저하될 수 있습니다. 여러 샤드에 걸친 데이터 연산이 필요할 때 성능이 급격히 떨어질 수 있습니다.
   • 샤딩 키를 기준으로 분산되어 있지 않은 데이터에 대한 쿼리는 여러 샤드를 조회해야 하기 때문에 성능이 떨어질 수 있습니다.
3. 재샤딩의 어려움
   • 데이터가 고르게 분배되지 않거나 데이터가 급격히 증가하면 재샤딩이 필요할 수 있습니다. 기존의 샤딩 전략을 변경하여 데이터를 다시 분배하는 작업은 복잡하고 비용이 많이 들며, 데이터 이전 중 시스템 중단 시간이 발생할 수 있습니다.
   • 샤딩 전략을 변경하려면, 데이터 마이그레이션과 관련된 많은 작업이 필요합니다.
4. 트랜잭션 처리의 어려움
   • 여러 샤드에 걸쳐 트랜잭션을 처리할 경우, 분산 트랜잭션이 필요할 수 있습니다. 이를 처리하려면 트랜잭션 관리가 복잡해지며, 성능에 부담을 줄 수 있습니다.
   • 샤딩된 시스템에서 원자성, 일관성, 격리성, 지속성(ACID)을 보장하는 것이 어려울 수 있습니다.
5. 운영 및 유지보수의 어려움
   • 여러 데이터베이스 인스턴스를 운영해야 하므로, 관리해야 할 데이터베이스가 많아져 운영이 복잡해집니다. 백업, 모니터링, 장애 대응 등 관리가 어렵고 비용이 증가할 수 있습니다.
   • 데이터베이스 서버가 여러 개가 되면, 시스템의 모니터링 및 관리가 어려워지고, 하나의 샤드에 문제가 생기면 다른 샤드에도 영향을 미칠 수 있습니다.
6. 샤딩 키 설계의 중요성
   • 샤딩 키를 잘못 선택하면 데이터가 불균등하게 분배되거나 특정 샤드에 부하가 집중될 수 있습니다. 이는 성능 저하를 초래할 수 있으며, 샤딩 키 선택은 시스템 설계에서 매우 중요한 요소입니다.
   • 잘못된 샤딩 키 선택은 재샤딩을 어렵게 만들 수 있으며, 초기에 신중하게 설계해야 합니다.

내가 생각할때 샤딩이 언제 사용하는지 여부보다 언제 사용하면 안되는지 아는게 중요하다고 생각한다.
그러면 뭘까

샤딩을 사용하지 말아야 할 경우:

1. 데이터가 적고 시스템이 작을 때: 샤딩은 관리와 복잡성이 추가되기 때문에 데이터가 적고 트래픽이 낮은 시스템에서는 불필요할 수 있습니다. 단일 데이터베이스로 충분히 처리할 수 있는 경우에는 오히려 관리가 더 쉬울 수 있습니다.
2. 단일 쿼리 성능이 중요한 경우: 샤딩된 시스템에서는 데이터가 여러 샤드에 분산되어 있기 때문에, 하나의 쿼리가 여러 샤드를 조회해야 하는 경우 성능 저하가 있을 수 있습니다. 모든 쿼리가 분산되도록 설계되지 않으면 복잡한 쿼리 처리에서 성능이 저하될 수 있습니다.

라고 하며
샤딩은 주로 성능 향상, 확장성 및 고가용성을 요구하는 대규모 시스템에서 적용되며, 이를 적용할 때는 시스템 설계 시 고려해야 할 요소가 많습니다. 샤딩을 도입하기 전에는 데이터 분배, 복잡한 쿼리 처리, 트랜잭션 처리 등 다양한 측면을 신중히 고려해야 합니다.

마지막으로 대안을 끝으로 설명을 마치겠다.
레플리케이션, 캐싱, CQRS, 파티셔닝