인프런 커뮤니티 질문&답변
URL 단축 서비스 시스템 디자인 및 스케일링 질문있습니다.
해결된 질문
작성
·
162
·
수정됨
답변 2
1
안녕하세요. 답변이 늦어 죄송합니다.
좋은 질문을 해주셔서 감사합니다.
- 먼저 트래픽을 줄일 수 있다는 것은 userId 를 partition key 로 사용하면, 데이터 베이스의 쓰기 및 읽기 트래픽이 사용자별로 분산될 수 있습니다. 예를 들어서, 사용자가 URL 을 생성할 때, 데이터 베이스는 해당 사용자의 userId 가 속한 파티션에서만 데이터를 저장합니다. 동일한 사용자가 생성한 URL 을 관리하거나 조회할 때 해당 사용자의 파티션만 조회하면 되기 때문에 다른 파티션에 영향을 주지 않을 수 있습니다. 그래서 결론적으로는 사용자 단위로 데이터와 트래픽이 분산되고, 특정 사용자에 대한 트래픽이 다른 사용자에게 영향을 주지 않아서 전체 시스템의 부하가 줄어드는 효율성이 있습니다. 
- 모든 방문객을 scan 해야 한다는 의미는 URL 단축 서비스의 방문자는 userId를 모른다는 점 입니다. URL 단축 서비스를 사용할 때, 대부분의 방문자는 단축 URL 만 알고 있고, 해당 URL 이 어느 사용자의 userId 에 속해 있는지 알 수 없습니다. 그래서 단축 URL 조회 요청이 생기면, 데이터베이스는 모든 파티션을 검색하여 해당 URL 의 데이터를 찾아야 합니다. 이 과정을 all partition scan 으로 정의하였습니다. 예를 들면, short.ly/inflearn 을 조회 요청했을 때 이 URL 이 어느 사용자 userId 의 파티션에 저장되어 있는지 알 수 없기 때문에 모든 파티션을 검색해야 하고 이 과정은 비효율적입니다. 결론적으로 파티션이 많아질수록 조회 작업의 성능은 점점 더 저하됩니다. 또한 이 과정이 더 큰 병목현상을 일으킬 수 있다는 점을 고려하여야 합니다. 
- Partition key 를 userId 로 사용하는 목적입니다. 특정 사용자가 URL 을 생성하거나 자신의 URL 을 확인 , 삭제하는 작업은 해당 사용자의 파티션에서만 이루어지기 때문에 효율적 입니다. 이렇게 되면, 한 사용자와 관련된 작업은 다른 사용자와 무관하게 수행되어서 성능이 향상됩니다. 하지만 방문자를 고려하지 않은 설계는 단축 URL 서비스 빠른 리다이렉션 기능에 악영향을 미칠 수 있습니다. 결론적으로 이를 해결하기 위해 캐싱을 도입하거나 userId 와 URL 의 해시값을 조합한 키를 사용하여 데이터베이스 파티션을 설계 합니다. 
결론적으로, URL 을 생성하고 관리하는 사용자의 성능을 높이기 위한 설계 방식이며, 방문자를 고려한 추가적인 보완책이 필요하다는 점을 고려해야 합니다.
0
안녕하세요, 인프런 AI 인턴입니다. 질문있습니다님께서 URL 단축 서비스의 시스템 디자인 및 스케일링 질문에 대해 주신 내용에 대해 설명드리겠습니다.
파티셔닝 키로 userId를 사용하는 경우
- 장점: 트래픽을 줄일 수 있다 - 파티셔닝 키로 userId를 사용하게 되면, 특정 사용자가 생성한 URL 정보가 동일한 파티션에 저장되므로 데이터 조회 시 해당 파티션만 접근하게 됩니다.
 
- 이는 다른 파티션에 접근할 필요가 없게 되어 네트워크 비용과 데이터베이스 조회 성능 면에서 트래픽을 줄일 수 있습니다. 즉, 여러 파티션을 모두 조회하는 대신, 특정 파티션만 조회하므로 트래픽이 감소합니다.
 
 
- 파티셔닝 키로 userId를 사용하게 되면, 특정 사용자가 생성한 URL 정보가 동일한 파티션에 저장되므로 데이터 조회 시 해당 파티션만 접근하게 됩니다.
- 단점: 모든 방문객을 스캔해야 한다 - URL 단축 서비스는 보통 URL이 어떤 사용자에 의해 생성되었는지를 모르는 경우가 많습니다. 특정 URL로 방문하는 사람이 어떤 userId로 생성된 URL에 방문하는지 알 수 없는 상황에서, 그 URL에 대한 정보를 찾기 위해 모든 userId의 데이터를 조회해야 할 수 있습니다.
 
- 이는 특정 URL에 접근한 모든 방문객을 스캔해야 한다는 의미로, 특정 partition에 절대적으로 데이터를 구성할 때 효율적이지 않을 수 있습니다.
 
 
- URL 단축 서비스는 보통 URL이 어떤 사용자에 의해 생성되었는지를 모르는 경우가 많습니다. 특정 URL로 방문하는 사람이 어떤 userId로 생성된 URL에 방문하는지 알 수 없는 상황에서, 그 URL에 대한 정보를 찾기 위해 모든 userId의 데이터를 조회해야 할 수 있습니다.
추가 리소스
비슷한 주제의 질의를 통해 더 많은 정보를 얻을 수 있는 리소스를 추천드립니다.
- “시스템 파티셔닝 설계 방법론” 마크다운 형식으로 게시물을 첨부하여 시스템 파티셔닝의 장단점과 서비스에 맞는 적절한 키 설계에 대한 이해를 도울 수 있는 추가적인 설명을 제공합니다.
 
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.





