[면접 스터디] 개념정리: 8. URL 단축기 설계
URL 단축기란
길고 복잡한 URL을 짧고 간결한 형태로 바꿔주는 서비스 또는 시스템이다.
왜 필요한가
- 공유 용이성
- 통계 추적: 단축 URL을 통해 클릭 분석
- 가독성 향상: 짧아졌으니
- 리디렉션 제어: 단축 URL을 추후에 다른 곳으로 변경 가능
요구사항
쓰기 연산: 매일 1억 개의 단축 URL 생성 → 초당 1160
읽기 연산: 읽기: 쓰기 비율 10:1 로 가정하면 → 초당 11600
운영기간: 10년간 1억 * 365 * 10 → 3650억 개의 레코드
축약 전 URL 평균길이 100
총 저장 용량은 3650억 * 100 바이트 → 36.5TB
URL 단축기 구성요소
API 엔드포인트
클라이언트는 이 엔드포인트를 통해 서버와 통신한다.
REST API로 설계한다면
단축 URL 생성 (쓰기)
POST /api/v1/data/shorten
인자: {longURL: longURLstring}
응답: 단축 URL
단축 URL 접근(리디렉션 처리)
GET /api/v1/shortURL 302나 301 리디렉션
응답: 단축 URL
URL 리디렉션
단축 URL 접근 시 단축 URL로 리디렉션 해줘야한다.
이때 301, 302 응답의 차이가 발생한다.
301 Permanently Moved
이건 영구적으로 웹 페이지가 바뀌었다는 뜻이다. 따라서 클라이언트는 자신이 방문한 적있다면 단축 URL을 캐싱했다가 바로 원본 URL로 요청한다. → 서버에 부담 적지만 트래픽 로깅하지 못함
302 Found
항상 단축기 서버에 요청 후 리디렉션을 받아온다. 이 경우는 서버에 부담을 줄이진 못하지만 트래픽을 로깅할 수 있다.
URL 단축
URL을 단축하는 로직을 정해야한다.
하나의 원본 URL에 대응하는 단축 URL은 하나만 있어야한다.
다음 요구사항을 부합하는 해시 함수를 찾으면 된다.
- 입력으로 주어지는 긴 URL이 다른 값이면 해시 값도 달라야한다.
- 계산된 해시 값은 원래 입력으로 주어졌던 긴 URL로 복원될 수 있어야한다.
데이터 모델
하지만 여기서 모든 데이터를 해시 테이블에 넣는건 메모리에 부담
DB에 저장할 수 있어야 한다.
이때 <단축 URL, 원본 URL> 순서쌍으로 저장하면된다.
해시함수
해시 함수는 원래 URL을 단축 URL로 변환하는 데 쓰인다.
해시 값 길이
해시에 들어갈 수 있는 문자를 숫자 알파벳 대소문자라고 한다면 62개가 가능하다.
한글자 당 62개를 저장할 수 있다는 것
요구사항이 3650억개의 레코드기 때문에 해시 값 길이는 7개는 되어야 한다.
이제 이 해시 값을 얻어내는 방식인 해시 함수 구현 기술 2가지를 알아 볼 것이다.
해시 후 충돌 해소
해시 함수 중 잘알려진 함수를 사용하는 방식이 가장 편할 것이다.
CRC32, MD5, SHA-1 다음과 같은 함수들의 출력은 모두 7보다 긴 값을 출력한다.
이 때 앞의 7자리만 사용한다고 한다면 해결은 되겠지만 겹칠 확률이 올라 갈 것이다.
중복처리방법
이때 해시 함수를 통해 단축 URL을 만든 후 DB에서 조회를 해본다.
- 있다. → 중복인 것이다. 중복을 피하기 위해 원본 URL에 미리 정한 문자열을 추가 후 다시 수행
- 없다. → 바로 DB에 저장
추후에는 추가된 문자열을 제외하고 사용하면 될 것이다.
base-62 변환
진법 현환은 URL 단축기 구현에 흔히 쓰이는 방식이다.
여기서 62진법인 이유는 알파벳 대소문자 + 숫자(0~9) 가 62개이기 때문
base-62 변환에서는 변환할 ID를 만들어줄 생성기가 필수적이다.
여기서는 보통 트위터 스노우플레이크 방식의 유일성 보장 ID 생성기를 활용한다. → 정수이기 때문
이렇게 만들어진 ID를 62진법으로 변환하면 단축 URL이 되는 것이다.
이렇게 만들어진건 유일성이 보장되었기 때문에 별도의 중복 처리할 필요 없다.
또한 자리수가 고정되지 않을 수 있는 특징도 있다.
URL 단축기 상세 설계: 단축 URL 생성 과정
- 입력으로 원본 URL를 받는다.
- DB에 해당 URL이 있는지 검사
- 있다면 가져와서 제공
- 없다면 유일한 ID를 생성
- 62 진법 적용해 단축 URL로 만듦
- 새로운 레코드로 저장 후 단축 URL 제공
URL 리디렉션 상세 설계
먼저 DB에 매번 조회하는 것 병목지점이 된다.
여기에 <단축URL, 원본URL>로 된 쌍을 키벨류로 저장하는 캐시를 두어 성능을 높일 수 있다.
- 사용자가 단축 URL을 클릭
- 로드밸런서가 해당 클릭으로 발생한 요청을 웹 서버에 전달
- 단축 URL이 이미 캐시되어 있다면 원본을 바로 전달
- 없다면 DB에서 꺼내서 캐싱하고 단축 URL 전달
마무리
이번에는 URL단축기의 API, 데이터 모델, 해시 함수, URL 단축 및 리디렉션 절차를 알아봤다.
추가적으로 알아볼 내용으로는
- 처리율 제한 장치: 엄청난 양의 단축 요청 시 문제가 될 수 있다. 이걸 방지하기 위해 쓰기요청이나 읽기 요청의 제한을 둘 수 있을 것이다.
- IP 기반 제한
- 토큰 버킷 알고리즘
- Redis + Lua Script
- 웹 서버 규모 확장: 설계를 무상태성으로 했다면, 웹 서버 확장은 쉬울 것이다.
- DB 규모 확장: 다중화나 샤딩을 통해 확장 가능할 것이다.
- 데이터 분석 솔루션: URL 단축기에 데이터 분석 솔루션을 두어 어떤 링크를 자주 사용하는지 등을 분석할 수 있을 것이다.
- 가용성, 데이터 일관성, 안정성: 대규모 시스템이 성공적으로 운영되기 위해서는 반드시 갖추어야 할 속성들이다.