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.
웹 서버 → 클라이언트 : 결과를 반환한다.