URL 단축 서비스 시스템 디자인 및 스케일링 질문있습니다.

미국 빅테크 29개의 실습으로 배우는 시스템 디자인 설계

URL 단축 서비스 시스템 디자인 및 스케일링

해결된 질문

작성

수정됨

안녕하세요!

강의 마지막 부분의 scaling - partitioning 관련해서 이해가 안가는 부분이 있어서 질문 드립니다.

partitioning key를 userId로 했을 때, 장단점에서

장점의 '트래픽을 줄일 수 있다'에서 어떤 트래픽을 의미하는지 잘 모르겠습니다.

단점에서도 모든 방문객을 scan해야 한다고 말씀해주셨는데 이 부분도 더 자세한 설명을 해주실 수 있을까요?

partition key를 userId로 할 때는 url을 생성하고 관리하는 User의 성능을 높일 때 사용하는걸까요?

소프트웨어-설계 시스템-디자인

답변 2

미국달팽이

지식공유자

안녕하세요. 답변이 늦어 죄송합니다.

좋은 질문을 해주셔서 감사합니다.

먼저 트래픽을 줄일 수 있다는 것은 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 을 생성하고 관리하는 사용자의 성능을 높이기 위한 설계 방식이며, 방문자를 고려한 추가적인 보완책이 필요하다는 점을 고려해야 합니다.

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. 질문있습니다님께서 URL 단축 서비스의 시스템 디자인 및 스케일링 질문에 대해 주신 내용에 대해 설명드리겠습니다.

파티셔닝 키로 userId를 사용하는 경우

장점: 트래픽을 줄일 수 있다
- 파티셔닝 키로 userId를 사용하게 되면, 특정 사용자가 생성한 URL 정보가 동일한 파티션에 저장되므로 데이터 조회 시 해당 파티션만 접근하게 됩니다.
- 이는 다른 파티션에 접근할 필요가 없게 되어 네트워크 비용과 데이터베이스 조회 성능 면에서 트래픽을 줄일 수 있습니다. 즉, 여러 파티션을 모두 조회하는 대신, 특정 파티션만 조회하므로 트래픽이 감소합니다.
단점: 모든 방문객을 스캔해야 한다
- URL 단축 서비스는 보통 URL이 어떤 사용자에 의해 생성되었는지를 모르는 경우가 많습니다. 특정 URL로 방문하는 사람이 어떤 userId로 생성된 URL에 방문하는지 알 수 없는 상황에서, 그 URL에 대한 정보를 찾기 위해 모든 userId의 데이터를 조회해야 할 수 있습니다.
- 이는 특정 URL에 접근한 모든 방문객을 스캔해야 한다는 의미로, 특정 partition에 절대적으로 데이터를 구성할 때 효율적이지 않을 수 있습니다.

추가 리소스

비슷한 주제의 질의를 통해 더 많은 정보를 얻을 수 있는 리소스를 추천드립니다.

“시스템 파티셔닝 설계 방법론” 마크다운 형식으로 게시물을 첨부하여 시스템 파티셔닝의 장단점과 서비스에 맞는 적절한 키 설계에 대한 이해를 도울 수 있는 추가적인 설명을 제공합니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변