8장 URL 단축기 설계

tiny url 같은 URL 단축기 설계

•

https://tinyurl.com/abcd-efgh 처럼 나와야 함

•

매일 1억개의 단축 url 생성

•

짧으면 짧을수록 좋다.

•

숫자, 대/소문자

•

개략적 추정

◦

초당 쓰기 연산: 1억/24/3600 = 1160

◦

읽기는 쓰기 * 10

◦

1년간 365억개의 데이터가 쌓인다.

◦

저장 용량은 365억 * 100 바이트 = 3.65TB

•

REST API 스타일로 설계

•

url 생성 엔드포인트

◦

POST, 인자: {longUrl: longUrlString}, 응단: 단축 URL

◦

GET, 응답 헤더: 리디렉션용 원래 URL, 301 또는 302 code

•

301 Permanently Moved: 해당 Location 의 url 을 영구 사용. 브라우저는 이 응답을 캐시한다. 따라서 추후 같은 단축 URL 에 요청을 보낼 필요가 있을 때 브라우저는 캐시된 URL 로 보낸다.

•

302 Found: 일시적인 Location 의 url 로 리디렉션

•

서버 부하를 줄이고 싶을 때는 301, 트래픽 분석이 중요하다면 302

•

저장은 해시 테이블이 적절하다. <단축 URL, 원래 URL>

•

해시 테이블은 메모리에 저장하는데 메모리는 유한하고 비싸서 <단축, 원래> 쌍을 RDB에 저장하는 것이 더 나은 방법

•

원래 URL 을 단축 URL 의 식별자로 변환하는 데에 쓰인다.

•

숫자 10개+대소문자 52 = 62, 62^n ≥ 365억개 를 만족하는 n 은 6~7이다. 

•

가장 짧은 해시 변환 함수가 7보다 길다.

•

첫 번째 해결 방법은 처음 7개 글자만 사용하는 것인데 이는 해시 충돌할 확률이 있다. 이는 로직으로 풀어야한다. 하지만 이는 오버헤드가 크다.

•

해시값에 사용할 수 있는 범위가 62개라서 62진법 변환이 많이 쓰인다.

해시 후 충돌 해소	base-62 변환
단축 URL의 길이가 고정된다.	가변적인 단축 URL 길이를 갖는다. ID 값이 커지면, URL 길이도 길어진다.
유일성 보장 ID 생성기가 필요없다.	ID를 기반으로 URL이 결정되므로, 유일성이 보장되는 ID 생성기가 필요하다.
충돌을 해소하는 작업이 필요하다. 이로 인한 오버헤드가 발생한다.	충돌이 아예 불가능하다. 유일한 ID로 URL을 생성하기 때문이다.
다음에 생성된 단축 URL을 유추할 수 없다.	ID가 Auto Increment로 생성된다는 가정하에, 다음 URL을 예측할 수 있으므로 보안상 문제가 될 수도 있다.

•

쓰기보다 읽기의 비중이 더 높아 <단축, 원래> 쌍을 캐시에 저장하면 성능을 높일 수 있다.

•

처리율 제한 장치가 있으면 무분별한 요청을 제한할 수 있다.

•

웹 서버 규모 확장

•

DB 규모 확장: DB 를 다중화하거나 샤딩

•

가용성, 데이터 일관성, 안정성!!!