TIL

8장 URL 단축기 설계

URL 단축기

• URL 단축(URL shortening)은 월드 와이드 웹 상의 긴 URL을 짧게 만들어 주는 기술
• URL 단축 시스템의 기본적 기능
  • URL 단축: 주어진 긴 URL을 훨씬 짧게 줄인다.
  • URL 리다이렉션: 측약된 URL로 HTTP 요청이 오면 원리 URL로 안내
  • 높은 가용성과 규모 확장성, 그리고 장애 감내가 요구됨

API 엔드포인트

• 클라이언트는 서버가 제공하는 API 엔드포인트를 통해 서버와 통신한다.
  • RESTful API
• URL 단축용 엔드포인트 예
  • POST /api/v1/data/shorten
  • 인자: {longUrl: longUrlString}
  • 반환: 단축 URL
• URL 리다이렉션용 엔드포인트 예
  • GET /api/v1/shortUrl
  • 반환: HTTP 리다이렉션 목적지가 될 원리 URL

URL 리다이렉션

• 단축 URL을 받은 서버는 원래 URL을 Location 헤더에 담아 301 응답을 보낸다.
• 301 Permanently Moved
  • HTTP 요청의 처리 책임이 영구적으로 Location 헤더에 반환된 URL로 이전되었다는 응답
  • 영구 이전이므로 브라우저는 이 응답을 캐시한다.
  • 이후 브라우저는 캐시된 원래 URL로 요청을 보낸다.
• 302 Found
  • 주어진 URL로의 요청이 ‘일시적으로’ Location 헤더 URL로 처리되어야 한다는 응답
  • 클라이언트 요청은 언제나 단축 URL 서버에 보내진 후 원리 URL로 리다이렉션 되어야 한다.
• 응답 코드 선택 기준
  • 서버 부하를 줄이는 것이 중요하다면 301
  • 트래픽 분석이 중요할 때는 302를 쓰는 쪽이 클릭 발생률, 발생 위치를 추적하는 데 유리
• URL 리다이렉션을 구현하는 가장 직관적인 방법은 해시 테이블

URL 단축

• 단축 URL이 www.tinyurl.com/{hashValue}라고 하면 긴 URL을 이 해시 값으로 대응시킬 해시 함수 fx가 필요
• 이 해시 함수는 다음 요구사항을 만족해야 한다.
  • 입력인 긴 URL이 다른 값이면 해시 값도 달라야 한다.
  • 계산된 해시 값은 긴 URL로 복원될 수 있어야 한다.

데이터 모델

• <단축 URL, 원래 URL>을 해시 테이블에 두는 것은 실제 시스템에 쓰기엔 곤란하다.
  • 메모리는 유한한 데 비싸기 때문
• 더 나은 방법은 <단축 URL, 원래 URL> 쌍을 관계형 DB에 저장하는 것

해시 함수

• 해시 값 길이
  • hashValue는 [0-9, a-z, A-Z]의 문자로 구성되므로 사용 가능 문자 개수는 62
  • 해시 값 길이는 62^n에서 n의 최솟값을 찾아야 한다.
  • 설계 과정에서 URL 단축 서비스가 얼마나 많은 URL을 만들어내야 하는지에 따라 n 값이 달라짐
• 해시 후 충돌 해소
  • 긴 URL을 줄이려면 해시 함수가 필요
  • 손쉬운 방법은 CRC32, MD5, SHA-1 등 잘 알려진 해시 함수를 이용하는 것
  • 하지만 이 함수들로 나온 값이 n보다 커진다면 줄일 필요가 있다.
  • 계산된 해시 값에서 처음 n개 글자만 이용하는 방법이 있지만 충돌 확률이 높아진다.
  • 충돌이 해소될 때까지 사전에 정한 문자열을 해시값에 덧붙인다.
  • 단축 URL 생성 시 한 번 이상 DB 질의가 필요하므로 성능을 높이기 위해 블룸 필터를 이용할 수도 있다.
• base-62 변환
  • 진법 변환은 URL 단축기 구현 시 흔히 사용되는 접근법
  • 수 표현 방식이 다른 두 시스템이 같은 수를 공유해야 하는 경우에 유용
  • 62진법을 이용하는 이유는 해시 값에 사용할 수 있는 문자 개수가 62개이기 때문
  • 0~9는 숫자, 10은 a, 11은 b, … 35는 z로 36은 A로 … 61은 Z로 대응

• 해시 충돌 두 접근법 비교

  해시 후 충돌 해소 전략	base-64 변환
  단축 URL의 길이가 고정됨	단축 URL 길이가 가변적. ID 값이 커지면 같이 커짐
  유일성 보장 ID 생성기가 필요치 않음	유일성 보장 ID 생성기 필요
  충돌이 가능해서 해소 전략이 필요	ID 유일성이 보장된 후에야 적용 가능한 전략이라 충돌이 아예 불가능
  ID로부터 단축 URL을 계산하는 방식이 아니라 다음에 쓸 수 있는 URL을 알아내는 것이 불가능	ID가 1씩 증가한다 가정하면 다음 단축 URL이 무엇인지 알아낼 수 있어 보안 문제가 될 소지가 있음

URL 단축기 상세 설계 예제

• 62진법 변환 기법 사용
  1. 긴 URL을 입력 받음
  2. DB에 해당 URL이 있는지 검사
  3. DB에 있다면 단축 URL을 클라이언트에 반환
  4. DB에 없는 경우 유일 ID를 생성해 DB 기본 키로 사용
  5. 62 진법 변환을 적용, ID를 단축 URL로 만든다.
  6. ID, 단축 URL, 원래 URL로 새 DB 레코드를 만든 후 단축 URL을 클라이언트에 전달

URL 리다이렉션 상세 설계

• 쓰기보다 읽기를 더 자주 하는 시스템이라 가정
• <단축 URL, 원래 URL> 쌍을 캐시에 저장하여 성능을 높임
  1. 사용자가 단축 URL을 클릭
  2. 로드밸런서가 요청을 웹 서버에 전달
  3. 단축 URL이 이미 캐시에 있다면 원래 URL을 클라이언트에 전달
  4. 캐시에 URL이 없는 경우 DB에서 꺼내 사용자에게 반환

마무리

추가적으로 논의해 볼만한 것

• 처리율 제한 장치
  • 엄청난 양의 URL 단축 요청이 오는 경우 무력화될 수 있다는 잠재적 보안 결함을 갖고 있다.
  • 처리율 제한을 통해 IP 주소를 비롯한 필터링 규칙으로 요청을 거를 수 있다.
• 웹 서버의 규모 확장
  • 위 예제에 포함된 웹 계층은 무상태이므로 자유로이 증설하거나 삭제할 수 있다.
• 데이터베이스 규모 확장
  • 데이터베이스를 다중화하거나 샤딩하여 규모 확장성을 달성할 수 있다.
• 데이터 분석 솔루션
  • 성공적 비즈니스를 위해선 데이터가 중요
  • URL 단축기에 데이터 분석 솔루션을 통합해 두면 어떤 링크를 얼마나 많은 사용자가 클릭했는지 등 중요 정보를 알 수 있다.
• 가용성, 데이터 일관성, 안정성
  • 대규모 시스템이 반드시 갖추어야 할 속성들