스터디 포스트 >  시스템 설계 한번에 인터뷰 합격하기

URL 단축 서비스

김재엽 멘토
매일 조금씩 발전하려고 노력중인 개발자 입니다 :)

시스템 설계 한 번에 인터뷰 합격하기 - 1주차

 
💡
누구나 접근 가능한 URL을 더 짧은 URL로 대체하고 경로 재설정을 관리하는 서비스를 설계
 

1단계: QA

  • 서비스 규모는 어느 정도인가?
    • 경로 재설정 수백만 건이 가능한 서비스로 고려한다.
  • 사용할 수 있는 문자의 제한은?
    • 유저의 사용성을 고려하여 기호와 대문자는 제외한다.
    • 소문자와 숫자만 사용[a-z, 0-9]한다.
  • 본인만의 단축 url 지정이 가능한가?
    • 가입한 사용자, 유료 사용자에게만 제공한다.
  • 생성된 url의 수정/삭제가 가능한가?
    • 계정이 있다면 가능하다.
  • 단축 url의 지속시간은?
    • 영원하다.
  • 추가로 질문할 만한 포인트
    • 중복 URL에 대해서 같은 단축 URL을 제공해야하는가?
    • 한 계정이 등록할 수 있는 최대 갯수는?
    • 페이지가 없어진 URL에 대한 관리는 어떻게 하는가?
 

2단계: 설계

설계 포인트

  1. 어떤 API가 필요할까?
  1. 큰 규모에서 어떻게 redirection을 할까?
 

시스템 설계 사례1

  • API
    • 등록(POST)
    • 조회(GET)
    • 갱신(PATCH)
    • 삭제(DELETE)
    • 목록 조회(GET)
    • 경로 재지정(GET)
  • DB Table
    • Id : 등록할때마다 자동으로 생성
Id
user_id
short_url
original_url
고유 번호
계정 id
짧은 URL
원본 URL
  • 설계
    • notion image
    • LoadBalancer : 서버 부하 분산을 위하여 유저가 접속시 이를 통하게 함.
    • Servers : REST API 요청에 대한 응답을 하는 서버
    • NoSQL : URL 접속에 대한 조회 요청이 많을 것으로 예상되어 조회에 대한 Cache용으로 사용
    • Database : URL 데이터 저장 및 등록/갱신/삭제는 직접 Database에서 진행한다.
 

시스템 설계 사례2

API 설계

  • POST Add new url
    • long url, user Id = null -> status, short url
    • 모든 url은 순차 ID 얻음 -> 이걸 base36 인코딩
    • 동일한 url이어도 id가 다르기 때문에 문제 없이 사용 가능
    • 해시 함수는 동일 url의 경우 해시 충돌이 나는 걸 해결해야 함
  • POST Add new vanity url
    • long url, user ID, vanity url -> status
  • PATCH Update url
    • long url, user ID, updated long url -> status, existing short url
  • DELETE Delete url
    • long url, user ID -> status
  • GET Display mapping
    • long url, user ID -> status, short url
  • GET Redirect
    • short url -> redirect to long url

전체 구성

| 클라이언트 |      ↓    | 로드밸런서 |   ↓  ↓  ↓ | 서버1 | 서버2 | 서버3 | |    캐시    | ↓    | NoSql DB |

데이터 스키마

  • 인덱스
    • short_url 검색용 - short url -> long url 매핑
    • long_url 검색용 - long url 수정시

진행과정

  • 클라이언트가 API 요청, short url 보냄
  • 로드밸런서가 요청을 서버에 분산
  • 매핑할 long url이 캐시에 있는지 확인
    • redirect 요청시마다 디스크 히트 피할 수 있음
    • 매핑 수정될 일 거의 없으므로 오랫동안 캐시 가능
  • 캐시에 없으면 데이터 베이스에서 가져옴
    • DB는 확장 가능성 고려해서 NoSQL 사용
  • 가져온 long url으로 경로 재지정 리턴
  • 없으면 404 리턴

추가 정리

  • shortened url vs. vanity url
    • long url = “velog.io/@inhalin”
      • shortened url 생성 -> bit.ly/AbCDe
      • vanity url 생성 -> inhal.in/AbCDe
  • HTTP 상태 코드
    • 301 Permanently moved 영구 이동
    • 302 Temporarily moved 임시 이동
 

3단계: 스터디 후 필요한 내용

인터뷰에서 추가로 고려한 내용들

  • 짧은 URL 을 정하는데 있어서 유저 사용성에 대한 고민
  • shortURL을 생성하는 방법에 대한 설명(고유 ID 를 Base36으로 인코딩)
  • Add new URL/ Add New Vanity URL을 구분함
  • 조회/리다이렉션 API
  • 캐시에 대해 구체적인 예시 언급
  • DB 인덱스 설정 언급
 

추가로 알아야 할 것

  • Geolocation
  • Vanity URL 의 개념

참고

 
 
 
본 스터디는 Udemy의 <【글로벌 Best】 시스템 설계 (System Design) : 한번에 인터뷰 합격하기 (한글자막)> 강의를 활용해 진행됐습니다. 강의에 대한 자세한 정보는 아래에서 확인하실 수 있습니다.
 
 
프밍 스터디는 Udemy Korea와 함께 합니다.
 
 
원하는 스터디가 없다면? 다른 스터디 개설 신청하기
누군가 아직 원하는 스터디를 개설하지 않았나요? 여러분이 직접 개설 신청 해 주세요!
이 포스트는
"시스템 설계 한번에 인터뷰 합격하기" 스터디의 진행 결과입니다
진행중인 스터디
시스템 설계 한번에 인터뷰 합격하기
외국계 뿐만이 아니라 국내 기업 채용에서도 시스템 설계 인터뷰를 진행하고 있습니다. 그리고 junior와 senior를 구분짓는 능력 중 하나를 시스템 설계를 꼽고 있습니다. 개발자로서 그만큼 중요한 능력을 방향성을 잡고 제대로 키우기 위해서 이번 기회에 준비해보고자합니다.
김재엽 멘토
매일 조금씩 발전하려고 노력중인 개발자 입니다 :)