Share
Sign In
URL 단축기
API Endpoint
클라이언트가 서버와 소통하기 위해 거치는 관문
URL 단축용 엔드포인트 : URL 단축 요청이 오면 결과를 반환한다.
URL 리다이렉션용 엔드포인트 : HTTP(S) 요청을 새 URL로 돌린다. (301 or 302)
URL Redirection
301 (Paermanently Moved)
영구적으로 URL이 리다이렉션되기 때문에 브라우저는 반환된 URL을 캐싱한다.
그리고 나중에 요청을 보낼 때 브라우저 단에서 URL을 바꿔서 보낸다.
이거 테스트 환경에서 잘 못 쓰면 많이 귀찮다.
302 (Found)
일시적으로 리다이렉션된다
매번 URL 단축기 서버를 거쳐 가기 때문에 트래픽 분석하기 좋다.
URL 단축
긴 URL을 해싱해서 짧은 URL을 만든다.
짧은 URL을 긴 URL로 복원해야 한다.
설계
데이터 모델
해시 테이블 : 유용하지만 메모리는 비싸다.
RDBMS : 단축 URL을 인덱스로 삼고 찾는다.
해시 함수
단축 URL은 숫자와 알파벳으로만 구성된다. ⇒ 한 문자에 62개의 경우의 수가 나온다.
(추정치에 따르면) 3650억 개의 URL을 만들어야 하므로 7자리면 충분하다. (62^7 \approx 3.5 \times 10^{12})
해시 충돌 해소
해싱을 하면 충돌이 발생하고 충돌을 해소하기 위해서는 임의의 문자열을 덧붙여야 한다.
이렇게 하면 DB에 질의가 많아지고 성능이 저하된다.
DB 대신 블룸 필터를 쓰면 공간 효율이 좋아진다.
false positive를 감안해도 거의 대부분을 거를 수 있다.
base 62 변환
앞서 한 문자에 62개의 경우의 수가 나온다고 했다. (숫자와 알파벳)
긴 URL은 결국 0과 1로 된 비트맵이다.
긴 URL을 62진법으로 변환한다.
base 62 계산
62 진법 대신 64 진법을 쓴다고 가정
1.
긴 URL을 DB에 저장하고 레코드 ID(숫자) 반환
2.
ID를 base62로 단축
동작
1.
클라이언트 → 웹 서버 : URL을 묻는다.
2.
웹 서버 → 캐시 : 캐시를 뒤져본다.
3.
웹 서버 → DB : 캐시가 miss 나면 DB를 찾는다.
4.
웹 서버 : DB도 miss 나면 단축 URL을 생성하고 DB에 저장한다.
a.
캐시에 저장할 지는 캐시 전략에 따라 다르다.
5.
웹 서버 → 클라이언트 : 결과를 반환한다.