Be-Developer

[대규모 시스템 설계 기초] 08 URL 단축기 설계

URL 단축기 설계

  1. 문제 이해 및 설계 범위 확정.
    • 요구사항
    • 트래픽 확인 > 매일 1억개 생성 > 1160/s
    • url redirection
    • 생성만 지원. 수정삭제 불가.
  2. 개략적 설계안 제시 및 동의 구하기.
    • API 엔드포인트
    • 단축용 POST API
    • redirect용 원본 URL을 반환할 GET API - URL redirection
    • 301 Permanently Moved : 브라우저가 응답과 Location을 캐시 한 후 redirect
    • 302 Not Found : 캐시하지않고 redirect된다.
      • 트래픽 분석이 요구될때는 301을 사용하면 안됨. - URL 단축
    • 입력이 다르면 출력도 달라야한다.
    • 출력값에서 입력값 복원이 가능해야한다.
  3. 상세 설계
    • 데이터 모델
    • 필요 컬럼 추리기 id/shortUrl/longUrl - 해시 함수
    • [0-9a-zA-Z] = 62개 문자
    • $62^n >= 3650억(대략적인 추정값)$ 을 만족하는 n(해시의 길이)를 찾아야한다. = 7
    • 해시 충돌 해소 : 잘 알려진 해시함수 사용 (CRC32, MD5, SHA-1)
      • n=7 길이가 맞지 않을텐데, 앞n글자만 잘라서 db저장시 중복체크를 하면 된다.
      • 중복되면 원본 url에 특정 문자열을 덧붙여가면서 반복 - base62변환
    • url단축기 구현시 흔히 사용되는 접근법.
    • base 는 표현 방식이 다른 두 시스템이 같은 수를 공유하여야 하는경우에 유용.
    • 62진법을 쓰는 이유는 hashValue에 이용할 수 있는 문자가 62개이기때문.
    • 유일성이 보장되는 id를 base62 변환.
    • | 해시 후 충돌해소 전략 | base-62 | | ——————————— | ———————————– | | 길이 고정 가능 | 가변적, url길이에 비례 | | | 유일성이 보장되는 id생성기 필요 | | 충돌해소 전략 필요 | ID의 유일성이 보장되면 충돌은 없음 | | 다음에 쓸 URL을 알아내는것은 불가 | 다음URL을 알아낼 수 있어서 보안이슈 | - URL 단축기
    • 비즈니스 로직 플로우 짜보기. - URL redirection
    • 서버간의 플로우 짜보기. 캐시사용 여부 등
  4. 마무리
    • 추가로 할 얘기
    • rate limiter, ip주소 필터링
    • 웹서버의 규모확장, stateless이므로 확장 가능.
    • db규모 확장, 다중화,sharding
    • 데이터 분석 솔루션, 어떤 정보가 필요할지?
    • 가용성-데이터 일관성-안정성,보장이 되는지.
      • 가용성 : db다중화, 웹서버 규모확장, 등등?
      • 데이터 일관성 => update/delete는 지원이 안되서 보장될듯.
      • 안정성 : 보안성? 유일id가 1씩증가되는거면 다음key 예상가능할듯. -> 근데 이게 위험한가