1. 단축 URL을 사용해야하는 이유
글자수 제한, 단축 URL의 클릭률을 통한 리서치, 마케팅(간결, 가독성 상승), QR 코드 - 단축 URL의 경우 속도가 더 빠름 등등 단축 URL의 장점은 기능성이나 심미성에서 긴 URL에 비해 가지는 장점이 많다.
2. 단축 URL의 기능적 요구사항
핵심 요구 사항은 아래와 같다.
긴 URL을 입력 받으면 단축 URL을 반환해야 한다.
단축 URL을 입력 받으면 원래의 긴 URL을 반환해야 한다.
단축 URL은 고유해야 하며 길이도 일정해야한다.
3. 비기능적 요구사항
대규모 시스템이라는 가정하에 대규모 시스템에서 가져야할 요구 사항들을 단축 URL도 가져야한다.
가용성 - 시스템이 항상 안정적으로 동작
확장성 - 사용자 1억명 이상을 지원할 수 있어야 함. 갑작스런 트레픽 증가에도 대응 가능
응답속도 - 지연 없이 읽기 쓰기가 가능해야함
일관성 - 여러 사용자가 단축 URL을 이용할 때 발생할 수 있는 사례들(동일 단축 URL 접근시 동일 긴 URL 반환, 동일한 긴 URL은 동일한 단축 URL을 반환, 반복적으로 단축 URL을 생성하려고 하면 같은 단축 URL 반환)
내구성 - 시스템 장애나 예기치 못한 상황에서 데이터 유지
신뢰성 - 내구성과 비슷
4. API 설계
핵심 기능은 단축 URL 생성과 원본 URL 반환.
단축 URL 생성 : POST /shorturl
요청 데이터 : 긴 URL
응답 : 단축 URL
긴 URL 반환 : GET /shortulrs/{shorturl}
요청 데이터 : 단축 URL
응답 : 긴 URL
5. 비기능적 요구사항을 추산하는 과정
사용자 10억명 중 10%(1억명)가 하루에 단축 URL 생성을 요청함.
10년간 저장하면 365*10*1억 = 3650억개의 단축 url을 저장해야함.
단축 url에 사용가능한 문자는 소문자,대문자 알파벳, 그리고 숫자 0~9 이다.
따라서 62개
6글자를 사용할시 62^6 = 500억
7글자 사용시 약 3조 5000억 개 사용 가능
여기에 단축 URL과 원본 URL의 저장 길이 등등 를 추가하면.3650억 * 1500 바이트 ~ 500 TB인데
레플리카 3개를 만든다고 가정하면 1.5PB가 필요하다.
- 단순히 이런식으로라도 계산을 해보는 방식이 많이 도움이 될 것 같다는 생각이 들었다.
6. 시스템 설계
시스템 설계시 여러 방법 중에 만들어야하는 시스템에 적합한 방법을 찾을 수 있도록 다방면으로 조사하는 것이 좋은 것 같다.
핵심 문제 : 어떻게 하면 겹치지 않는 단축 URL을 효과적으로 생성할 수 있을까?
1. 무작위 생성 - 생성과 구현이 쉽다. 지연과 동시성 충돌 발생 가능성이 높다.
2. MD5 해시 - 128비트의 해시 중 7글자(42비트)만 사용하기 때문에 겹칠 가능성이 높다.
3. 카운터 - 숫자를 하나씩 늘려 이를 통해 단축 URL을 생성 - 카운터 서버가 SPOF가 될 수 있다.
4. 분산카운터 - 범위를 정해서 분산한 카운터 방식 (1~100만, 100만1 부터 200만 ...)
데이터 베이스는 key-value(단축 URL- 긴 URL) 베이스인 레디스가 적합하다.