[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 8. URL 단축기 설계

1. 문제 이해 및 설계 범위 확정

이 장에서 설계할 URL 단축기의 기능은 다음과 같다.

 

- URL 단축: 주어진 긴 URL을 짧게 줄인다.
- URL Redirection: 축약된 URL로 HTTP 요청이 오면 원래 URL로 안내한다.
- 높은 가용성과 규모 확장성, 장애 감내

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

- API 엔드포인트

URL 단축기를 사용할 수 있도록 클라이언트에게 다음의 두가지 엔드포인트를 제공한다.

1) URL 단축용 엔드포인트

단축하고 싶은 URL을 인자로 실어서 POST 요청을 보내면 단축된 URL을 응답으로 반환한다.

 

POST /api/v1/data/shorten

- 인자: {longUrl: longURLstring}
- 반환: 단축 URL

2) URL 리다이렉션용 엔드포인트

단축 URL에 대한 요청에 대해 원래 URL을 반환한다.

 

GET /api/v1/shortUrl

- 반환: HTTP redirection 목적지가 될 원래 URL

- URL 리다이렉션

단축 URL로 요청을 받은 서버는 해당 URL에 대한 원래 URL을 301 상태 응답의 Location 헤더에 넣어서 반환한다. 이때 301과 302 두 상태에 대한 차이가 있다.

 

- 301 Permanently Moved: 해당 URL에 대한 HTTP 요청의 처리 책임이 영구적으로 Location 헤더에 반환된 URL로 이전되었다는 의미이다. 301 응답을 받은 경우 브라우저가 원래 URL을 캐시하여 해당 URL로 요청을 보내게 된다.

- 302 Found: 주어진 URL에 대한 요청이 일시적으로 Location 헤더의 URL로 처리된다는 응답이다. 클라이언트의 요청은 단축 URL로 보내진 후 원래 URL로 리다이렉션된다.

 

두 방식은 장단점이 있는데, 서버 부하를 줄이기 위해서는 301을 클릭 발생률이나 발생 위치 추적 등의 트래픽 분석을 위해서는 302를 사용하는 것이 유리하다.

 

URL 리다이렉션은 해시 테이블을 사용하여 <단축 URL, 원래 URL>의 쌍을 저장하도록 하여 구현할 수 있다.

- URL 단축

긴 URL을 해시 값으로 대응시켜 단축 URL로 변환할 해시 함수가 필요하다. 이 해시함수를 통해서 여러 URL의 변환 결과가 중복되지 않아야 하고, 변환된 URL을 원래 URL로 복원할 수 있어야 한다.

3. 상세 설계

- 데이터 모델

이전 절에서 URL 리다이렉션을 위해 해시 테이블을 사용하였다. 그러나 해시 테이블을 위한 메모리는 비싸기 때문에 RDB에 해당 데이터들을 저장하도록 한다.

- 해시 함수

URL을 구성할 수 있는 문자는 10진수 숫자 10개와 알파벳 대소문자 각각 26개로 총 62개이다. 62개의 문자로 n자리수의 URL을 생성한다면 나올 수 있는 URL의 경우의 수는 62^n개이다. 이를 통해서 URL 단축기가 생성해야할 URL의 개수와 이에 따른 단축 URL의 자리수를 계산할 수 있다.

 

해시 함수 구현 방식으로는 '해시 후 충돌 해소 방법'과 'base-62 변환' 두가지 방법을 설명한다.

 

해시 후 충돌 해소 방법은 기존의 해시 함수를 이용하여 URL을 단축하고 단축된 URL이 DB에 존재하는지 조회하여 충돌이 발생하면 충돌이 해소될 때까지 특정한 문자열을 해시값에 덧붙여서 충돌을 해결한다. 이때 매번 충돌하는 URL이 있는지 DB 조회를 사용하면 오버헤드가 크기 때문에 책에서는 블룸 필터 사용을 추천한다.

 

base-62 변환은 사용할 수 있는 문자 62개를 기반으로 62진법 변환을 통해 URL을 단축시키는 방법이다. 이 방식으로 변환 요청된 URL 데이터의 id 값을 10진법에서 62진법으로 변환하는 등의 방식으로 단축 URL을 생성한다.

 

해시 후 충돌 해소 방법은 단축 URL의 길이가 고정되고, 유일성이 보장되는 ID 생성기가 필요없고, 랜덤하게 URL이 생성된다는 장점이 있지만, 충돌의 해소 전략을 어떻게 구성할 것인지 고민해야 한다. base-62 방식은 단축 URL의 길이가 ID 값에 따라 가변적이고, 유일성을 보장하는 ID 생성기가 필요하며, ID를 기반으로 생성하는 경우 다음에 생성될 단축 URL을 유추할 수 있다는 보안상 문제가 있다. 반면 ID가 이미 유일하기 때문에 해시 충돌의 위험은 없다.

- URL 단축기 상세 설계

URL 단축기의 동작 흐름은 다음과 같다.

 

1. URL이 입력된다.
2. DB에 해당 URL이 존재하는지 확인한다.
3. DB에 있다면 해당 URL에 대한 단축 URL을 클라이언트에게 반환한다.
4. DB에 없는 경우, 해당 URL에 대한 유일 ID를 생성하고 이를 DB에서 PK로 사용한다.
5. 62진법 변환을 적용하여 ID를 단축 URL로 만든다.
6. ID, 단축 URL, 원래 URL로 새로운 DB 레코드를 생성하고 단축 URL을 클라이언트에 전달한다.

- URL 리다이렉션 상세 설계

쓰기보다 읽기가 많이 발생하는 시스템이기 때문에 URL 쌍에 대한 캐시를 추가하면 성능을 높일 수 있다.

리다이렉션 기능의 동작 흐름은 다음과 같다.

 

1. 단축 URL을 클릭한다.
2. 로드밸런서가 해당 클릭으로 발생한 요청을 웹 서버에 전달한다.
3. 단축 URL이 캐시에 있는 경우 원래 URL을 바로 꺼내서 클라이언트에게 전달한다.
4. 캐시에 없는 경우 DB에서 조회한다. DB에도 없는 경우 잘못된 단축 URL을 입력한 것으로 이에 대한 결과를 반환한다.
5. DB에서 조회한 URL 정보를 캐시에 저장하고 클라이언트에게 반환한다.

4. 마무리

이외에도 URL 단축기와 관련하여 다음과 같은 주제들을 고민해볼 수 있다.

 

- 처리율 제한 장치 (rate limiter): IP 필터링 등을 통해서 과도한 요청 트래픽의 제한을 걸 수 있다.

- 웹 서버의 규모 확장: 본 설계에서 웹 계층이 무상태이기 때문에 자유롭게 웹 서버를 증설하거나 삭제할 수 있다.

- DB 규모 확장: DB의 다중화, 샤딩 등을 통한 DB 규모 확장

- 데이터 분석 솔루션: 요청이 들어온 링크 클릭에 대한 횟수, 주기 등의 정보를 분석하는 솔루션을 적용할 수 있다.

- 가용성, 데이터 일관성, 안정성: 대규모 시스템 운영을 위한 속성들이다.