•
이번 장에서는 고전적이면서도 재미있는 시스템 설계 문제 중 하나인 tinyurl같은 URL 단축기를 설계하는 문제를 풀어본다.
1단계 문제 이해 및 설계 범위 확정
•
URL 단축기 설계를 위해 해볼만한 질문은 다음과 같다.
◦
URL 단축기가 어떻게 동작하는지 예제를 물어볼 수 있다.
▪
특정한 URL 입력에 대해서 어떤 형식을 가지는 단축 URL을 결과로 제공하는지, 물어봐야 한다.
◦
트래픽 규모는 어느 정도인지 물어볼 수 있다.
◦
단축 URL의 길이에 대한 요구사항은 어느정도인지 물어볼 수 있다.
◦
단축 URL의 구성에 대한 제한사항이 있는지 물어볼 수 있다.
◦
단축된 URL을 시스템이 삭제, 갱신하는 등의 처리가 가능해야 하는가?
•
해당 장에서 설계를 위해 임의로 작성한 요구사항은 다음과 같다.
◦
URL 단축 : 주어진 URL을 훨씬 짧게 줄여야 한다.
◦
URL 리디렉션 : 축약된 URL로 HTTP 요청이 오는 경우, 기존의 URL로 리다이렉션 시킨다.
◦
높은 가용성과 규모 확장성 그리고 장애 관용성이 요구된다.
개략적 추정
•
쓰기 연산 : 매일 1억 개의 단축 URL 생성
◦
초당 쓰기 연산 : 100,000,000 / 24 / 3600 = 1160
•
읽기 연산 : 읽기 연산의 비를 임의로 쓰기 연산과 10:1이라고 규정했을 때, 대략 1,000,000,000이 된다.
◦
초당 읽기 연산 : 1,000,000,000 / 24 / 3600 = 11600
•
URL 단축 서비스를 n년간 운영한다고 할 때, 저장이 필요한 레코드의 수
◦
100,000,000 * 365 * 10 = 365,000,000,000
•
축약 전 URL의 평균 길이는 임의로 지정한다. 100이라고 가정하자.
◦
따라서 10년 동안 필요한 저장 용량은 365,000,000,000 * 100바이트일 것이다.
2단계 개략적 설계안 제시 및 동의 구하기
•
URL 단축기 웹 애플리케이션 서버를 구축하려면 API 엔드포인트, URL 리다이렉션 그리고 URL 단축 알고리즘 정도를 설계해야할 것이다.
API 엔드포인트
•
모르긴 몰라도, URL 단축을 요청할 엔드포인트 하나, 단축된 URL로 요청이 왔을 때, 기존 URL로 리다이렉션 시켜주는 엔드포인트 하나 총 2개의 엔드포인트가 필요할 것임은 알 수 있을 것이다.
•
URL 단축용 엔드포인트
◦
인자로 URL을 받고, 단축된 URL을 반환하는 간단한 구조의 엔드포인트가 필요할 것이다.
•
URL 리다이렉션용 엔드포인트
◦
단축 URL에 대해서 HTTP 요청이 발생했을 때, 기존 URL로 보내주기 위한 용도의 엔드포인트다.
◦
반환 값으론 HTTP 리다이렉션 목적지가 될 원래 URL일 것이다.
URL 리다이렉션
•
리다이렉션을 해주는 과정에서 응답 코드까지 고민해볼 수 있다.
URL 단축
•
해시테이블을 구현에 사용한다고 하면, 기존 URL을 특정 해시값으로 대응시킬 해시 함수를 찾아야할 것이다.
◦
이 해시 함수는 다음 요구 사항을 만족해야 한다.
▪
긴 URL이 다른 값이면 다른 해시 값을 제공해주어야 한다.
▪
계산된 해시 값은 원래 입력으로 주어졌던 긴 URL로 복원될 수 있어야 한다.
3단계 상세 설계
•
이번 절에서는, 개략적 설계에서 구체화되었던 데이터 모델, 해시 함수, URL 단축 및 리다이렉션에 관련된 구체적인 내용을 설계한다.
데이터 모델
•
개략적 설게 시에는 모든 것을 해시 테이블로 했었다. 이는 초기 전략으론 괜찮으나 실제 시스템 사용에는 곤란한데, 메모리는 유한하고 비싸기 때문이다.
•
더 나은 방법은 단축 URL, 원래 URL의 순서쌍을 관계형 데이터베이스에 저장하는 것이다.
해시 함수
•
해시 함수는 원래 URL을 단축 URL로 변환하는 데 사용된다.
•
단축 URL의 문자가 0-9, a-z, A-Z로 이뤄진다고 할 때, 총 62개의 문자를 사용할 수 있다.
•
10년간 서비스하므로 3650억개의 경우의 수가 필요하므로 3650억개의 경우의 수보다 커지는 최초의 n인 7을 사용하면 무리없이 제공할 수 있을 것이다.
•
해시 함수의 경우, 기존 해시 함수를 사용해볼 수 있다.
URL 단축기 상세 설계
1.
입력으로 긴 URL을 받는다.
2.
데이터베이스에 해당 URL이 있는지 검사한다.
a.
데이터베이스에 존재한다면 해당 값을 반환한다.
b.
데이터베이스에 없는 경우에는 유일한 ID를 생성한 후, 기본 키로 사용한다.
i.
해시함수를 적용해 단축 URL을 만든다.
ii.
데이터베이스 레코드를 추가한 후, 단축 URLd르 클라이언트에 제공한다.
4단계 마무리
•
설계를 마친 후, 다음과 같은 사항에 대해 면접관과 더 이야기해볼 수 있을 것이다.
◦
처리율 제한 장치 : 읽기의 비율이 쓰기에 비해 10배이므로 최소 3.6조 번의 읽기 요청이 발생할 것이고, 트래픽은 이보다 더 몰릴 수 있다. 따라서 적절한 처리율 제한 장치를 제공해볼 수 있다.
◦
웹 서버의 규모 확장 : 본 설계에 포함된 웹 계층은 기본적으로 무상태층이므로 웹 서버를 자유로이 증설하거나 삭제할 수 있다.
◦
데이터베이스의 규모 확장 : 데이터베이스를 다중화하거나 샤딩하여 확장성을 달성할 수 있다.
◦
데이터 분석 솔루션 : 성공적인 비즈니스를 위해 지표를 제공할 필요가 있는데, URL 단축기에 데이터 분석 솔루션을 붙여 사용자들의 이용 정보를 획득할 수 있다.
◦
가용성, 데이터 일관성, 안정성 : 대규모 시스템이 성공적으로 운영되기 위해 이 속성들을 달성하기 위한 요소들을 적용시킬 수 있다.
