📓 8장. URL 단축기 설계

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

예시 시스템의 기본적 기능
1. URL 단축기: 주어진 긴 URL을 훨씬 짧게 줄인다.
2. URL 리디렉션(Redirection): 축약된 URL로 HTTP 요청이 오면 원래 URL로 안내
3. 높은 가용성과 규모 확장성, 그리고 장애 감내가 요구

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

API 엔드포인트

클라이언트는 서버가 제공하는 API 엔드포인트를 통해 서버와 통신

URL 단축기 - (일반적) 2개의 엔드포인트 요구

1. URL 단축용 엔드포인트
새 단축 URL을 생성하고자 하는 클라이언트
-이 엔드포인트에 단축할 URL을 인자로 실어서 POST 요청

POST /api/v1/data/shorten

• 인자: {longUrl: longURLstring}
• 반환: 단축 URL

2. URL 리디렉션용 엔드포인트
단축 URL에 대해 HTTP 요청이 오면 원래 URL로 보내주기 위한 용도

GET /api/v1/shortUrl

• 반환: HTTP 리디렉션 목적지가 될 원래 URL

URL 리디렉션

클라이언트-서버 사이의 통신 절차

여기서 유의해야 할 것은 301 응답과 302 응답의 차이

• 301 Permanently Moved : 해당 URL에 대한 HTTP 요청의 처리 책임이 영구적으로 Location 헤더에 반환된 URL으로 이전되었다는 응답.
  영구적으로 이전되었으므로, 브라우저는 이 응답을 캐시(cache)함.
  추후 같은 단축 URL에 요청을 보낼 필요가 있을 때 브라우저는 캐시된 원래 URL로 요청 보냄.
• 302 Found: 주어진 URL로의 요청이 '일시적으로' Location 헤더가 지정하는 URL에 의해 처리되어야 한다는 응답
  클라이언트의 요청은 언제나 단축 URL 서버에 먼저 보내진 후에 원래 URL로 리디렉션 되어야 함.

서버 부하를 줄이는 것이 중요하면 301 Permanent Moved
트래픽 분석(analytis)이 중요할 때는 302 Found

URL 리디렉션을 구현하는 가장 직관적인 방법은 해시 테이블을 사용하는 것.

URL 단축

해시 함수는 다음 요구사항을 만족해야 함

• 입력으로 주어지는 긴 URL이 다른 값이면 해시 값도 달라야 함.
• 계산된 해시 값은 원래 입력으로 주어졌던 긴 URL로 복원될 수 있어야 함.

3단계. 상세 설계

데이터 모델

해시 테이블 - 초기 전략에는 ㄱㅊ지만 실제 시스템에 쓰기에는 곤란..
더 나은 방법은 <단축 URL, 원래 URL>의 순서쌍을 관계형 데이터베이스에 저장하는 방법

해시 함수
원래 URL을 단축 URL로 변환하는 데 쓰임
편의상 해시 함수가 계산하는 단축 URL 값을 hashvalue라고 지칭.

1. 해시값 길이
   

해시 함수 구현에 쓰일 기술로는 1. 해시 후 충돌 해소 방법 과 2. base-62 변환 법을 알아보자.

1. 해시 후 충돌 해소
   긴 URL을 줄이려면, 원래 URL을 7글자 문자열로 줄이는 해시 함수가 필요.
   손쉬운 방법: CRC32, MD5, SHA-1같이 잘 알려진 해시 함수 이용.
   -> 이 방법 사용 시 7글자로 정확히 안 줄여짐
   -> [ 해결 방법 ] 만들어진 해시 함수를 맨 앞 7글자만 따서 쓰고, 충돌이 발생하면... 충돌이 해소될 때까지 사전에 정한 문자열을 해시값에 덧 붙이면 됨.
   

2. base-62 변환
   수의 표현 방식이 다른 두 시스템이 같은 수를 공유해야 하는 경우에 유용

1🤍2. 두 접근법의 비교

velog는 무슨.. 표 만들기도 안되노..

URL 단축기 상세 설계

예제에서는 62진법 변환 기법을 사용해 설계할 것이고. 그 처리 흐름을 순서도 형태로 정리한 것.

URL 리디렉션 상세 설계
[사진]

4단계. 마무리

앞에서 다룬 내용을 제외하고 고려해보아야 할 부분들
1. 처리율 제한 장치(rate limiter)
2. 웹 서버의 규모 확장
3. 데이터베이스의 규모 확장
4. 데이터 분석 솔루션(analytics)
5. 가용성, 데이터 일관성, 안정성