8. URL 단축기 설계
1단계 문제 이해 및 설계 범위 확장#
- 다음의 기본적 기능이 있습니다.
- URL 단축: 주어진 긴 URL을 훨씬 짧게 줄입니다.
- URL 리다이렉션: 축약된 URL로 HTTP 요청이 오면 원래 URL로 안내
- 높은 가용서과 규모 확장성, 그리고 장애 감내가 필요합니다.
- 개략적 추정
- 쓰기 연산: 매일 1억 개의 단축 URL 생성
- 초당 쓰기 연산: 1억(million)/24/3600 = 1160
- 읽기 연산: 읽기 연산과 쓰기 연산 비율은 10:1이라고 하며, 그 경우 읽기 연산은 초당 11,600회 발생합니다.
- URL 단축 서비스를 10년간 우녕시, 1억 x 360 x 10 = 3650억 개의 레코드를 보관해야합니다.
- 축약 전 URL의 평균 길이는 100이라고 가정합니다.
- 따라서 10년 동안 필요한 저장 용량은 3650억 * 100byte = 36.5TB 입니다.
2단계 개략적 설계안 제시 및 동의 구하기#
API 엔드포인트#
- URL 단축키는 기본적으로 두 개의 엔드포인트를 필요로 합니다.
- URL 단축용 엔드포인트: 새 단축 URL을 생성하고자 하는 클라이언트는 이 엔드포인트에 단축할 URL을 인자로 실어서 POST 요청을 보내야 합니다.
- URL 리다이렉션용 엔드포인트: 단축 URL에 대해서 HTTP 요청이 오면 원래 URL로 보내주기 위한 용도의 엔드포인트
URL 리다이렉션#
- 리다이렉션 응답에도 차이가 있습니다.
- 301 Permanently Moved
- 응답은 해당 URL에 대한 HTTP 요청의 처리 책임이 영구적으로 Location 헤더에 반환된 URL로 이전되었다는 응답입니다.
- 단축 URL에 요청을 보낼 필요가 있을 때 브라우저는 캐시된 원래 URL로 요청을 보냅니다.
- 302 Found
- 이 응답은 주어진 URL로의 요청이 일시적으로 Location 헤더가 지정하는 URL에 의해 처리되어야 한다는 응답입니다.
- 언제나 단축 URL 서버에 먼저 보내지 후에 원래 URL로 리다이렉션 되어야 합니다.
- 301 Permanently Moved
- 두 방법은 각기 다른 장단점이 있습니다.
- 서버 부하를 줄이는게 중요하면 301 Permanent Moved를 사용하는 것이 좋습니다.
- 트래픽 분석이 더 중요할 때는 302 Found를 사용하는 것이 좋습니다.
URL 단축#
- 긴 URL을 단축하는 것은 해시 함수입니다.
- 해시 함수는 다음 요구사항을 만족해야 합니다.
- 입력으로 주어지는 긴 URL이 다른 값이면 해시 값도 달라야 합니다.
- 계산된 해시 값은 원래 입력으로 주어졌던 긴 URL로 복워노딜 수 있어야 합니다.
3단계 상세 설계#
데이터 모델#
- 초기 전략으로는 괜찮으나, 실제 시스템에서 사용하기 어렵습니다.
해시 함수#
- 해시 함수는 원래 URL을 단축 URL로 변환하는 데 쓰입니다.
해시 값 길이#
- 해시 함수 구현에 쓰일 기술로는 두 가지 방법이 있습니다.
해시 후 충돌 해소#
CRC32, MD5, SHA-1같이 잘 알려진 해시 함수를 이용하는 것입니다.- 해시 함수를사용하나 크기를 줄이면 충돌이 발생하게 되고, 단축 URL을 생성할 때 한 번 이상 데이터베이스 질의를 해야하므로 오버헤드가 큽니다.
base-62 변환#
- 62진법을 쓰는 이유는 hashValue에 사용할 수 있는 문자 개수가 62개 입니다.
두 접근법 비교#
| 해시 후 충돌 해소 전략 | base-62 변환 |
|---|---|
| 단축 URL의 길이가 고정됨 | 단축 URL의 길이가 가변적, ID 값이 커지면 같이 길어짐 |
| 유일성이 보장되는 ID 생성기가 필요치 않음 | 유일성 보장 ID 생성기가 필요 |
| 충돌이 가능해서 해소 전략이 필요 | ID의 유일성이 보장된 후에야 적용 가능한 전략이라 충돌은 아예 불가능 |
| ID로부터 단축 URL을 계산하는 방식이 아니라서 다음에 쓸 수 있는 URL을 알아내는 것이 불가능 | ID가 1씩 증가하는 값이라고 가정하면 다음에 쓸 수 있는 단축 URL이 무엇인지 쉽게 알아낼 수 있어서 보안상 문제가 될 소지가 있음 |