8. URL 단축기

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

• 어떻게 동작해야하는가?

• 트래픽 규모, 매일 몇개의 URL을 만들어내야하는가?

  • 매일 1억개

• URL길이는 어느정도?

  • 가능한 짦게

• URL 문자에 제한?

  • 숫자, 영문자만

• URL 을 제거하거나 업데이트 가능?

  • 불가

개략적인 추정

• 쓰기 연산 -> 매일 1억개

• 초당 쓰기 연간 1억 / 24 / 3600 = 1160개

• 읽기 연산: 읽기 : 쓰기 = 10 : 1

• 10년간 운영한다고 하면 1억 * 365 * 10 = 3650억개의 레코드를 보관해야함

  • 축약전 URL 평균 길이 100byte

  • 그러면 3650 * 100 바이트 = 36.5TB

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

API 엔드포인트

생성

• POST /api/v1/data/shorten

조회

• GET /api/v1/shortUrl

  • 단축 URL을 받은 서버는

  • 301 응답과 할 께, Location에 헤더를 넣어 반환

301

• Permanently Moved : 영구적 이전. 브라우저는 이 응답을 캐시함. 추후 같은 단축 URL에 대해 요청을 보낼 필요가 있을 때, 브라우저는 캐시된 원래 URL로 요청을 보내게 됨.

302

• Found :일시적 이전. 캐시하지 않음

3. 상세 설계

해시 함수

• 0-9, a-z, A-Z -> 10 + 26 + 26 = 62개

• 3650억개의 URL을만들 수 있어야함

• hashValue의 길이를 정하기 위해서는

  • 62 ^ n >= 3650억.. n 의 최소값

  • n = 7

• base62 ![[Pasted image 20250907142550.png]]

• 해시 후 충돌 해소

  • 해시 후에 충돌 발생하면 해소 하는 방법 ![[Pasted image 20250907143058.png]]

base-62 변환 단점 개선

• AUTO_INCREMENT에서 하이브리드 생성

ID = 1234 (AUTO_INCREMENT) 
변형된_ID = (1234 * 1103 + 7919) % 1000000
-> Base62(변형된_ID)

• 각 서버마다 다른 시작점과 증가폭을 주는 방법? (서버1: 1,4,7... 서버2: 2,5,8... 서버3: 3,6,9...)

  • 서버수 변경 등에 대응하기가 어려워짐

  • 특정 서버에 트래픽이 몰리는 경우

• 중앙 집중식 ID 생성 서버를 두는 방법?

  • SPOF(Single Point of Failure)

• 보안상 문제 해결

  • 암호화 함수등

URL 단축기 상세 설계

![[Pasted image 20250907143410.png]]

중요 이슈

• 분산 환경에서 유일성이 보장되는 ID 생성기 가 필요함.

  • [[7. 분산 시스템을 위한 유일 ID 생성기]] 참고

URL 리디렉션 상세 설계

![[Pasted image 20250907143538.png]]

참고

• https://claude.ai/share/114f0cd5-491d-46c8-9549-979f7f6c0d6a

• https://jinseong-dev.tistory.com/21