introduction

본 페이지에서는 URL shortner의 시스템 디자인에 대해 가볍게 다룬다.

design

use case

Use case는 다음과 같다.
1. Url 단축: 요청받은 long URL에 대해, short URL로 단축시킨다.
2. Url 리다이렉션
3. 그 외 고려사항: 고가용성(High availabilty), 확장성, fault tolerance

요구 API

• URL shortning: Client는 Url 단축을 위해 POST request를 전송한다.
  • POST
    • requst parameter: long URL
    • return: short URL
• URL redirecting: Client는 short URL을 long URL로 리다이렉션 하기 위해 GET requrst를 전송한다.
  • GET
    • return: HTTP redirection을 위한 long URL

URL 단축

URL 단축에 대해서 두 가지 기능이 요구된다.

• 요청받은 long URL에 대해, short URL로 변환을 위한 hash value 를 관리해야 한다.
• hash 값은 리다이렉션을 위해 long URL로 매핑되어야 한다.

일반적으로 short URL을 구하기 위해 hash function은 BASE62 encoding을 이용한다.

BASE62 encoding할 때, long URL을 직접 BASE62 encoding하지 않고, URL 단축 요청이 server로 전달되었을 때 생성된 <short URL, long URL> 의 매핑 정보에 대한 auto incremented Primary key나 index 등을 encoding한다.

encoding한 결과가 short URL이 되며, 이를 DB에 저장한다.

즉 URL 단축에 필요한 data model은 다음과 같다.

attribute	설명
id (Primary key)	auto increment된다.
long URL
short URL	encoding 결과를 저장

BASE62 algorithm은 여기 에 짧게 정리해두었다.

URL 리다이렉션

다음의 두 리다이렉션을 고려해볼 수 있다.

• 301 리다이렉션: 301 리다이렉션은 요청받은 URL을 영구적으로 long URL로 redirect하는 것이다. 즉 Client side에서 short URL -> long URL 의 리다이렉션 정보를 캐싱하고, 이후 short URL 요청은 URL shortner server로 전달되지 않고 즉시 long URL로 리다이렉트 된다.
• 302 리다이렉션: 302 리다이렉션은 요청받은 URL을 임시로 long URL로 redirect하는 것이다. 301 리다이렉션과 다르게 항상 URL shortner server로 요청된다.

성능을 고려한다면 301 리다이렉션을 선택하는 게 좋을 것이다. 왜냐하면 첫 리다이렉션 이후로는 동일한 short URL에 대해 URL shortner server로 요청하지 않기 때문이다.
분석을 고려한다면 302 리다이렉션을 선택하는 게 좋다. client의 요청을 트래킹할 수 있기 때문이다.

Reference

• System Design Interview – An insider's guide
• https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C