"가상 면접 사례로 배우는 대규모 시스템 설계 기초"를 읽고 정리한 글입니다 :)
긴 URL을 단축하여 짧게 줄여주는 URL 단축기를 설계해보자.
이 시스템의 기본 기능은 다음과 같다.
- URL 단축: 주어진 긴 URL을 짧게 줄인다.
- URL Redirection : 축약된 URL로 요청이 오면 원래 URL로 리다이렉션시킨다.
URL 리다이렉션
URL 리다이렉션을 위해서는 응답의 Location 헤더에 리다이렉션할 URL을 넣고, 301 혹은 302 HTTP Status Code를 사용하여 응답하면 된다. URL 단축키에서는 축약된 URL로 요청이 왔을 때, 기존의 URL을 Location 헤더에 넣은 후 301 혹은 302 상태코드로 응답하면 될 것이다. 여기서 301 혹은 302 응답의 차이는 다음과 같다.
301 상태코드는 Permanently Moved를 나타내며, 해당 URL에 대한 HTTP 요청의 책임이 영구적으로 Location 헤더의 URL로 이전된 것을 의미한다. 영구적으로 이전되었기에, 브라우저는 이 응답을 캐싱하고 다음에 같은 URL로 요청을 보낼 때 캐시된 원래 URL로 응답을 보낸다.
이와 달리 302 상태코드는 Found를 나타내며, 해당 URL에 대한 요청이 일시적으로 Location 헤더의 URL에서 처리되어야 한다는 뜻이다. 즉, 우리의 URL 단축기의 예시에서는 302 상태코드로 리다이렉션할 시, 클라이언트의 요청이 언제나 단축 URL 서버에 먼저 보내진 후 원래 URL로 리다이렉션된다.
이 두 방법은 각기 다른 장단점을 가진다. 301 상태코드를 쓸경우 브라우저에서 캐시처리를 하기에 서버 부하를 줄이는데 도움을 준다. 하지만 트래픽 분석이 중요할 때는 302 상태코드를 쓰는 것이 발생률이나 발생 위치를 추적하는데 더 좋을 것이다.
마지막으로 단축 URL과 기존 URL간의 매핑은 해시 테이블을 사용하는 것이 가장 직관적일 것이다. 달리 말해 캐시로 Redis와 같은 Key-Value 기반의 데이터베이스를 활용할 수 있을 것이다.
URL 단축
www.tinyurl.com/{hash_value}단축된 URL은 일반적으로 위 형태를 띌 것이다. 이는 결국 기존의 긴 URL을 해시 값으로 변환하는 것이 가장 핵심이라는 뜻이다.
단축 URL의 길이
우선 생각해볼 점이 해시 값의 길이이다. 단축 URL인 만큼 가능한 짧을수록 좋을 것이다. 이 URL의 길이를 정하는 것은 시스템의 규모를 고려해 판단해야 한다. 예를 들어 서비스가 최대 4000억 가량의 레코드를 가진다고 가정하자. 단축 URL은 일반적으로 문자와 숫자의 조합으로 이루어지기에 한 글자당 사용할 수 있는 문자의 개수는 10 + 26 + 26 = 62개이다. 그렇다면 문자열의 길이가 n일 때, 가능한 url의 개수는 62^n이므로 길이가 7이면 요구사항을 만족하기에 충분한 값이다. 이러한 방식으로 해시 값의 길이를 우선 결정하자.
해시 후 충돌 해소
이제 해시 함수를 구현할 것인데 책에서 설명한 방식은 "해시 후 충돌 해소" 방법과 "base-62 변환" 두가지가 있다.
해시 후 충돌 해소는 해시를 한번 돌린 뒤, 이 값에서 내가 원하는 길이(n)만큼 추출한다. 이 값이 기존의 값과 중복된다면 기존 Url 뒤에 사전에 정의한 문자열을 추가하고 다시 이 과정을 반복한다. 이 방법을 쓰면 충돌은 해소할 수 있지만, 단축 URL을 생성할 때 한번 이상 데이터베이스 질의를 해야하므로 오버헤드가 크다.
진법 변환
진법 변환(base conversion)은 URL 단축기를 구현할 때 흔히 사용되는 접근법 중 하나이다. 여기서 62진법을 쓰는 이유는 해시 값에 사용할 수 있는 문자의 개수가 62개이기 때문이다. base-62를 사용할 때는 0은 0으로, 9는 9로, 10은 a로, 36은 A로 대응하여 사용한다. 이 방식을 쓸때는 기존 URL 자체에 해시를 거는 것이 아니라 Unique한 정수형 ID 값에 Base-62 변환을 사용한다.
이 방식은 유니크한 ID를 사용하는 것을 전제로 하기에 중복이 발생할 일은 없다. 다만, Unique ID를 만들기 위해 이 ID를 만드는 생성기가 필요하다는 단점이 있다. 또한, ID가 1씩 증가하는 값이라고 가정하면 다음에 사용할 수 있는 단축 URL을 쉽게 유추할 수 있기에 보안상 문제가 될 수 있다.
