인프런 커뮤니티 질문&답변
작성한 질문수
6강 - 해시태그 모델의 샤딩 전략에 대하여, 분산 정도(데이터 편중)와 트랜잭션 성능의 trade off 상황 발생 시에 대한 고민
해결된 질문
작성
·
30
0
안녕하세요, 선생님!
6강 해시태그 모델을 배운 후 데이터 분산 정도와 트랜잭션 일관성의 trade off에 대한 선택이 생각났고, 이에 대한 선생님의 고견은 어떠하실지 궁금하여 질문 올리게 되었습니다.
질문 내용은 아래와 같습니다.
데이터 편중도 크고 vs 트래픽이 많이 발생하여 트랜잭션까지 고려해야할때 샤딩키를 어떤 것으로, 어떤 부분을 tradeoff의 우선순위로 지정하는 것이 좋을지
저의 경우 트래픽을 선택할 것 같은데, 데이터 편중에 대해 추가적인 보완사항이 있다면 어떤 것이 있을지
일단 강의의 경우, 제가 이해한 내용으로는,
해시태그 모델과 같이, PK/FK의 분산 정도가 비슷하고, 부모 속성(FK)에 의한 쏠림 현상이 발생하여도 그 규모가 충분히 크지 않으므로 쓰기 경로를 중점적으로 고려하여(동일 게시글에 대한 해시태그를 동일 샤드에 저장) 설계한다.
이와 같습니다.
저는 해시태그 모델과 함께, 다른 예를 들어, 하루에 50,000건의 거래가 이루어지는 대규모 거래가 발생하는데, 이를 거래 게시판을 각 도메인 별(화장품/전자기기 등)로 별도로 만들어서 한 거래게시판 당 하루에 10,000건의 게시글, 1개의 1000~2000개의 찜이 발생한다고 하였을때의 상황에 대해 생각해보았습니다.
제가 만약 실무에서 찜 DB를 설계한다고 가정하고, 이에 대해 대응한다고 하였을때,
1) 게시글 ID와 찜(누가 찜했는지 구분해야 함, 찜ID로 구분한다고 가정하면)의 트래픽이 한 한 게시글 기준 찜 몇천여개, 게시글 총 만여개의 수준으로 발생하여 규모가 충분히 작다고 볼 수 없습니다.
2) 따라서 데이터 쏠림 현상에 대해 고민을 안할래야 안할 수가 없고, 그러면서도 데이터의 균등한 샤딩에 대해서도 고민이 들게 되었습니다.
3) 결국 데이터 분산을 균등하게 하느냐, 쏠림이 발생하더라도 쓰기 트래픽의 성능과 일관성, 조회 성능의 이점이 큰 것인가를 선택해야 하는데
4) 분산을 선택하지 않고, 트래픽 성능/일관성/조회 성능을 생각하였을때, 확실히 단일 데이터베이스에 있을때 성능적인 측면에서도 좋고, 일관성, 특히 조회 시 별도의 CQRS 전용 쿼리모델이나 DB를 따로 두지 않고 인덱스도 따로 설계하지 않는 등 훨씬 엄청난 이점이 될 것으로 판단이 됩니다.
따라서, 분산 정도 대신 성능 쪽으로 결론짓고 샤딩 키를 찜 ID 대신 게시글 ID로 지을 것 같습니다.
대신, 엄청난 트래픽으로 인해 데이터 편중이 너무 커진다면 게시글 생성일자를 샤드키로 추가하여 데이터를 좀 더 세부적으로 분리할 것 같습니다(아니면 더 좋은 방안이 있을지).
이에 대해 선생님의 생각이 궁금하여 질문드리게 되었습니다!
감사합니다.
퀴즈
분산 데이터 모델링에서 '샤드 키'의 가장 중요한 역할은 무엇일까요?
데이터 압축률 최대화
데이터 보안을 위한 암호화
데이터가 저장될 샤드 결정
실시간 데이터 백업 수행
답변 2
0
Hyo Kyun Lee님, 안녕하세요!
일단 전제에서 게시글 당 1~2천개의 찜이 발생한다고 말씀 주셨는데요,
게시글 ID를 샤드 키로 설정한다고 해도 전혀 문제될 수준의 데이터 수는 아닙니다!
디스크 용량과 장비 성능은 충분히 크고 좋으니, 1~2천개의 데이터는 하나의 샤드로 쏠린다고 하더라도 문제되지 않는 크기일 것으로 보입니다. 저장 공간 뿐만 아니라 읽기/쓰기 트래픽 모두 그렇습니다.
강의에서는 애초에 설계 방향을 대규모 시스템을 가정하기 때문에, 최소 수천만~수억 이상의 데이터까지 고려한 부분으로 봐주시면 좋을 것 같습니다!
따라서, 게시글 ID를 샤드 키로 설정해도 문제 없을 정도의 데이터입니다.
게시글 당 작성되는 찜 데이터가 문제가 된다고도 상황을 가정해보겠습니다. (찜이 수천만~수억 건의 데이터라고 가정한 셈)
그러면 당연히 데이터 분산 또는 트래픽 부하 분산을 위해 댜른 샤딩 전략을 취하는게 유리합니다.
scale-up으로 풀 수 있는 물리적인 해결은 한계가 있기 때문에, 애플리케이션 레벨에서 분산할 방법이 필요할 수 밖에 없기 때문입니다.
찜 ID를 샤드 키로 설정할 수도 있고, 말씀하신대로 여러 개의 데이터를 복합 샤드 키로 설정할 수도 있습니다.
다만, 이러한 경우 인덱스 테이블 관리해야하고, 조회 부담도 늘어나며, 시스템 복잡성이 올라가는 문제가 있지만, 불가피한 부분으로 보이네요.
고정된 정답이 있다기 보단, 도메인 특성이나 시스템 정책에 맞춰서 유리한 방향을 선택하는게 중요할 것 같습니다!
0
안녕하세요, 인프런 AI 인턴입니다. Hyo Kyun님.
해시태그 모델과 같은 데이터 분산 및 샤딩 전략은 실제 시스템 설계에서 매우 중요한 단계입니다. 특히, 데이터 편중 문제와 트랜잭션 성능 간의 트레이드오프(trade-off)는 많은 고민을 필요로 합니다.
샤딩 전략 선택 시 고려 사항
트래픽 특성 이해:
- 트랜잭션 빈도와 데이터 크기를 정확히 파악하는 것이 첫 번째입니다. 예를 들어, 특정 게시글이 대량의 조회 수나 찜 수를 기록한다면, 이로 인한 트래픽 집중을 예측해야 합니다.
- 트랜잭션 빈도와 데이터 크기를 정확히 파악하는 것이 첫 번째입니다. 예를 들어, 특정 게시글이 대량의 조회 수나 찜 수를 기록한다면, 이로 인한 트래픽 집중을 예측해야 합니다.
데이터 편중:
- 데이터가 특정 샤드에 집중되는 경향이 있다면, 이는 데이터 편중(imbalanced loading) 문제를 일으킬 수 있습니다. 이러한 경우, 샤드를 추가적으로 나누거나, 동적 샤딩 전략을 통해 해결할 수 있습니다.
- 데이터가 특정 샤드에 집중되는 경향이 있다면, 이는 데이터 편중(imbalanced loading) 문제를 일으킬 수 있습니다. 이러한 경우, 샤드를 추가적으로 나누거나, 동적 샤딩 전략을 통해 해결할 수 있습니다.
트랜잭션 일관성:
- 동일한 데이터에 대해 일관성을 유지하기 위해 트랜잭션이 필요한 경우, 가능하면 동일한 샤드 내에서 처리되도록 샤딩하는 것이 좋습니다. 이는 성능과 일관성을 동시에 만족시킬 수 있는 접근법입니다.
- 동일한 데이터에 대해 일관성을 유지하기 위해 트랜잭션이 필요한 경우, 가능하면 동일한 샤드 내에서 처리되도록 샤딩하는 것이 좋습니다. 이는 성능과 일관성을 동시에 만족시킬 수 있는 접근법입니다.
보완 사항
샤드 키 설계:
- 최적의 샤딩을 위해 복합적인 샤드 키를 사용할 수 있습니다. 예를 들어,
게시글 ID와사용자 ID를 동시에 사용하는 등 다양한 접근법을 통해 데이터 분산을 보다 균일하게 유지할 수 있습니다.
- 최적의 샤딩을 위해 복합적인 샤드 키를 사용할 수 있습니다. 예를 들어,
데이터 재조정:
- 정기적인 데이터 분산 검사 및 필요 시 데이터 재분류(rebalancing)를 통해 편중을 완화할 수 있습니다.
- 정기적인 데이터 분산 검사 및 필요 시 데이터 재분류(rebalancing)를 통해 편중을 완화할 수 있습니다.
캐시 사용:
- 데이터 조회가 빈번하다면, Redis 등과 같은 캐시 시스템을 활용하여 데이터베이스 부하를 줄일 수 있습니다.
- 데이터 조회가 빈번하다면, Redis 등과 같은 캐시 시스템을 활용하여 데이터베이스 부하를 줄일 수 있습니다.
아래는 유사한 상황에서 샤딩 전략과 관련된 질문 및 답변을 찾을 수 있는 링크입니다:
- 샤딩의 기준 - 샤딩의 기준과 불균형 해결에 대한 논의.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
자세한 답변 감사드립니다!
최근 MSA/분산환경에 대해 공부하고 있는데, 답변 해주신 것 보니 Monolithic에서 대규모 MSA 환경에서 scaled out하는 기준이 생각보다 큰 것을 알 수 있었습니다.
답변해주신 내용 참고하겠습니다!
감사드립니다.