시스템 설계 한 번에 인터뷰 합격하기 - 1주차
누구나 접근 가능한 URL을 더 짧은 URL로 대체하고 경로 재설정을 관리하는 서비스를 설계
1단계: QA
- 서비스 규모는 어느 정도인가?
- 경로 재설정 수백만 건이 가능한 서비스로 고려한다.
- 사용할 수 있는 문자의 제한은?
- 유저의 사용성을 고려하여 기호와 대문자는 제외한다.
- 소문자와 숫자만 사용[a-z, 0-9]한다.
- 본인만의 단축 url 지정이 가능한가?
- 가입한 사용자, 유료 사용자에게만 제공한다.
- 생성된 url의 수정/삭제가 가능한가?
- 계정이 있다면 가능하다.
- 단축 url의 지속시간은?
- 영원하다.
- 추가로 질문할 만한 포인트
- 중복 URL에 대해서 같은 단축 URL을 제공해야하는가?
- 한 계정이 등록할 수 있는 최대 갯수는?
- 페이지가 없어진 URL에 대한 관리는 어떻게 하는가?
2단계: 설계
설계 포인트
- 어떤 API가 필요할까?
- 큰 규모에서 어떻게 redirection을 할까?
시스템 설계 사례1
- API
- 등록(POST)
- 조회(GET)
- 갱신(PATCH)
- 삭제(DELETE)
- 목록 조회(GET)
- 경로 재지정(GET)
- DB Table
- Id : 등록할때마다 자동으로 생성
Id | user_id | short_url | original_url |
고유 번호 | 계정 id | 짧은 URL | 원본 URL |
- 설계
- LoadBalancer : 서버 부하 분산을 위하여 유저가 접속시 이를 통하게 함.
- Servers : REST API 요청에 대한 응답을 하는 서버
- NoSQL : URL 접속에 대한 조회 요청이 많을 것으로 예상되어 조회에 대한 Cache용으로 사용
- Database : URL 데이터 저장 및 등록/갱신/삭제는 직접 Database에서 진행한다.

시스템 설계 사례2
API 설계
POST
Add new url- long url, user Id = null -> status, short url
- 모든 url은 순차 ID 얻음 -> 이걸 base36 인코딩
- 동일한 url이어도 id가 다르기 때문에 문제 없이 사용 가능
- 해시 함수는 동일 url의 경우 해시 충돌이 나는 걸 해결해야 함
POST
Add new vanity url- long url, user ID, vanity url -> status
PATCH
Update url- long url, user ID, updated long url -> status, existing short url
DELETE
Delete url- long url, user ID -> status
GET
Display mapping- long url, user ID -> status, short url
GET
Redirect- short url -> redirect to long url
전체 구성
| 클라이언트 |
↓
| 로드밸런서 |
↓ ↓ ↓
| 서버1 | 서버2 | 서버3 |
| 캐시 |
↓
| NoSql DB |
데이터 스키마
- 인덱스
- short_url 검색용 - short url -> long url 매핑
- long_url 검색용 - long url 수정시
진행과정
- 클라이언트가 API 요청, short url 보냄
- 로드밸런서가 요청을 서버에 분산
- 매핑할 long url이 캐시에 있는지 확인
- redirect 요청시마다 디스크 히트 피할 수 있음
- 매핑 수정될 일 거의 없으므로 오랫동안 캐시 가능
- 캐시에 없으면 데이터 베이스에서 가져옴
- DB는 확장 가능성 고려해서 NoSQL 사용
- 가져온 long url으로 경로 재지정 리턴
- 없으면 404 리턴
추가 정리
- shortened url vs. vanity url
- long url = “velog.io/@inhalin”
- shortened url 생성 ->
bit.ly/AbCDe
- vanity url 생성 ->
inhal.in/AbCDe
- HTTP 상태 코드
301
Permanently moved 영구 이동302
Temporarily moved 임시 이동
3단계: 스터디 후 필요한 내용
인터뷰에서 추가로 고려한 내용들
- 짧은 URL 을 정하는데 있어서 유저 사용성에 대한 고민
- shortURL을 생성하는 방법에 대한 설명(고유 ID 를 Base36으로 인코딩)
- Add new URL/ Add New Vanity URL을 구분함
- 조회/리다이렉션 API
- 캐시에 대해 구체적인 예시 언급
- DB 인덱스 설정 언급
추가로 알아야 할 것
- Geolocation
- Vanity URL 의 개념
- 왜 memcached를 Caching DB로 사용하고, NoSQL을 저장용으로 사용했을까?
- HTTP Status Code 301/302
참고
본 스터디는 Udemy의 <【글로벌 Best】 시스템 설계 (System Design) : 한번에 인터뷰 합격하기 (한글자막)> 강의를 활용해 진행됐습니다. 강의에 대한 자세한 정보는 아래에서 확인하실 수 있습니다.
프밍 스터디는 Udemy Korea와 함께 합니다.