URL 단축기 설계

문제 이해 및 설계 범위 확정

시스템 설계 면접 문제는 의도적으로 어떤 정해진 결말을 갖지 않도록 만들어진다.

면접장에서 시스템을 성공적으로 설계해 내려면 질문을 통해 모호함을 줄이고 요구사항을 알아내야 한다.

 

시스템의 기본적 기능

• URL 단축
• URL 리디렉션
• 높은 가용성과 규모 확장성, 그리고 장애 감내

 

개략적 추정

• 쓰기 연산 : 매일 1억 개의 단축 URL 생성
  • 초당 쓰기 연산 : 1억 % 24시간 % 3600초 = 1160
• 읽기 연산 : 쓰기 연산의 10배라 가정 = 11600
• URL 단축 서비스를 10년간 운영한다고 가정 : 1억 * 365일 * 10년 = 3650억 개의 레코드 보관
• 축약 전 URL의 길이 100byte라고 가정
  • 10년 동안 필요한 저장 용량 3650억 * 100byte = 36.5TB

개략적 설계안 제시 및 동의 구하기 

• API 엔드포인트
  • URL 단축용 엔드포인트
    • POST /api/v1/data/shorten
      • 인자: {longUrl}
      • 반환: 단축 URL
  • URL 리디렉션용 엔드포인트
    • 단축 URL에 대해서 HTTP 요청이 오면 원래 URL로 보내주기 위한 용도
    • GET /api/v1/shortUrl
      • 반환: HTTP 리디렉션 목적지가 될 원래 URL
• URL 리디렉션
  • 클라이언트로부터 단축 URL을 받은 서버는 그 URL을 원래 URL로 바꾸어서 301 응답의 Location 헤더에 넣어 반환한다.
    • 301 응답 : Permanently Moved
      • 해당 URL에 대한 HTTP 요청의 처리 책임이 영구적으로 Location 헤더에 반환된 URL로 이전
      • 브라우저는 이 응답을 캐시 하여 사용
    • 302 응답 : Found
      • 일시적으로 Location 헤더가 지정하는 URL에 의해 처리

출처:https://velog.io/@minu/8장.-URL-단축기-설계

 

출처:https://velog.io/@minu/8장.-URL-단축기-설계

• URL 단축
  • 결국 중요한 것은 긴 URL을 해시 값으로 대응시킬 해시 함수 fx를 찾는 일
  • 요구사항
    • 입력으로 주어진 긴 URL이 다른 값이면 해시 값도 달라야 한다.
    • 해시 값이 원래 입력으로 주어졌던 긴 URL로 복원될 수 있어야 한다.

상세 설계

• 데이터 모델
  • pk:id, shortURL, longURL 필드를 가지는 DB 테이블(메모리에 저장하긴 양이 많음)
• 해시 함수
  • 해시 값 길이
    • 사용할 수 있는 문자 : [0-9, a-z, A-Z] 10+26+26=62
    • 62^n > 3650억 n=7, shortURL 길이는 7로 지정
  • 기술
    • 해시 후 충돌 해소
      • 잘 알려진 해시 함수를 이용(SHA-1, MD5, CRC32)
      • 길이가 7보다 길어 앞에 글자만 잘라서 사용 -> 충돌 가능
        • 사전 정의 문자열 추가 
    • base-62 변환
      • 진법 변환
      • id를 10진수 사용, 이를 62진수로 변환하여 shortURL 생성
    • 두 접근법 비교 

출처:https://velog.io/@minu/8장.-URL-단축기-설계

URL 단축기 상세 설계

ID생성기는 단축 URL을 만들 때 사용할 ID를 만들고, 이 ID는 전역적 유일성이 보장되는 것이어야 한다.

고도로 분산된 환경에서 이런 생성기를 만드는 것은 어려운 일이다.

(https://kkang-joo.tistory.com/175)

출처:https://velog.io/@minu/8장.-URL-단축기-설계

 

 

URL리디렉션 상세 설계

쓰기보다는 읽기가 더 많이 일어나므로, 캐시를 사용하여 성능을 높일 수 있다. 

출처:https://velog.io/@minu/8장.-URL-단축기-설계