시스템 디자인 인터뷰 준비 (4) - HLD 인터뷰 예제

1) 시스템 디자인 인터뷰에 필요한 개념들을 확실히 함
2) 디자인 패턴/LLD
3) 시스템 디자인 시 각 컴포넌트의 역할 (HLD)
4) HLD 인터뷰 예제 <- NOW!

5) HLD 인터뷰 예제에 나온, 컴포넌트 뜯어보기

 

 

원래 시리즈의 마지막이어야했으나 기력부족으로 부득이하게 5까지 연장되었다.. 이렇게 긴 시리즈물을 써본 적이 없었는데 그럼에도 불구하고 정말 개요 핵심, 내가 특별히 강조하고 싶은 부분 만 작성했다. 

이전 글에도 언급했지만 System Design Interview An Insider’s Guide by Alex Xu 책을 여러번 읽어봐야겠다는 생각이 든다.

뭐든 갈수록 어려워지니 이제는 경력이 쌓인다는게 두려워질 지경이다 ㅋㅋㅋ;

 

 

-

인터뷰어가 문제를 준다:

bit.ly같은 URL Shortener를 설계해주세요.

요구사항은 아래와 같습니다.

 

요구사항 정의 (Requirement Clarification)

✅ 기능적 요구사항 (Functional Requirements)
사용자가 긴 URL을 입력하면 짧은 URL을 생성해야 한다.
생성된 단축 URL을 방문하면 원래 URL로 리디렉트해야 한다.

✅ 비기능적 요구사항 (Non-Functional Requirements)
확장성(Scalability): 수십억 개의 URL을 저장하고 빠르게 조회할 수 있어야 한다.

 

..

여기까지 보고, 오 별거없네~ 하면서 파밧 하고 시작해버리면 안된다..

머릿속에 떠오르는 질문들을 꼭! 인터뷰어에게 물어보고 요구사항을 구체화시켜야 한다.

예를 들면,

* 이 url shortener가 동작했을때의 결과 예시를 줄 수 있을까?

* 단축된 url의 길이 제한이 있니?

* 생성한 url이 삭제/수정될 수도 있니?

* 이 서비스의 트래픽이 어느정도 될까?

등등..

 

이렇게 면접관과의 티키타카를 통해 얻은 결론을 토대로 요구사항이 아래와 같이 구체화될 것이다.

Updated:

✅ 기능적 요구사항 (Functional Requirements)
사용자가 긴 URL을 입력하면 짧은 URL을 생성해야 한다.
생성된 단축 URL을 방문하면 원래 URL로 리디렉트해야 한다.

+ 생성된 url은 숫자, 알파벳 대소문자만 사용하며, 최대한 짧게 생성해야 한다.

+ 생성된 url 삭제/수정/저장 등의 기능은 구현하지 않는다.

✅ 비기능적 요구사항 (Non-Functional Requirements)
확장성(Scalability): 수십억 개의 URL을 저장하고 빠르게 조회할 수 있어야 한다.

+ 하루에 1천만 개의 url이 생성되므로, 이를 감당할 수 있는 시스템을 구현해야 한다.

+ High Availability를 제공해야 한다.

+ 사용 통계를 수집한다.

 

추정치 및 용량 산정 (Back-of-the-Envelope Calculation)

서비스 규모를 예측하여 저장 용량과 처리량 추정이 필요하다.

사실 책을 보고 이렇게까지 필요할까..? 했는데 아마존 SDE2 면접에서 물어보는거같다 ㅎ

이 부분은 면접이든 일할때든 내가 직접적으로 경험한 바가 없어서 이런게 있고 이런 방식으로 한다~ 정도로만 작성한다. 아쉽게도.. ㅠㅠ

📌 트래픽 예상
하루 5억 개의 URL 조회 요청 (5B/day)
하루 1천만 개의 새로운 단축 URL 생성 (10M/day)
📌 스토리지 예상
각 URL이 평균 500 bytes를 차지한다고 가정하면,

하루 1천만 개의 단축 URL이 추가될 경우 → 5GB/day
5년 동안의 데이터 저장량 → 5GB × 365 × 5 ≈ 9TB
👉 이를 고려하여 확장 가능한 데이터 저장소 선택이 필요합니다.

 

 

시스템 인터페이스 정의 (API Design)

기능적 요구사항에서 확인한대로, 각 기능별로 필요한 API Endpoint 두가지를 정의한다. 

이 예제에서만 Endpoint가 기능 숫자대로 두개인 것이지, 꼭 기능 숫자에 맞출 필요는 없을 것 같다.

 

URL shortening 

클라이언트는 단축된 URL을 얻기 위해 POST 요청을 보낸다.

POST /shorten
• request parameter: {longUrl: longURLString}
• return shortURL

URL redirecting

단축된 URL을 주소창에 입력했을 때, 원본 url로 리다이렉트하기 위해 클라이언트는 GET 요청을 보낸다.

GET /shortUrl
• return longURL

 

 

 

기능 Flow

이 시스템의 주요 기능 두가지, URL shortening과 URL redirecting의 흐름을 확인하여 딥다이브할만한 내용을 짚고 넘어간다.

URL shortening 

 

어떻게 단축 URL을 생성할까? 두 가지의 유명한 URL 단축 알고리즘을 비교해보고, 이 시스템에 알맞은 방식을 선택할 수 있다.

📌 Base62 Encoding
62진법(0-9, A-Z, a-z)을 사용하여 URL을 인코딩한다.
예: 10진수 123456789 → Base62 변환 → 1LY7VK

function encodeUrl(id) {
    const chars = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
    let shortUrl = "";
    while (id > 0) {
        shortUrl = chars[id % 62] + shortUrl;
        id = Math.floor(id / 62);
    }
    return shortUrl;
}

📌 해싱 + 충돌 방지
URL을 최대한 짧게 만들어야 하므로, 7자리 해시 값을 만들기로 했을 때, SHA-256 등의 해싱함수를 적용한다. 

충돌이 더이상 발생하지 않을때까지 미리 정의된 문자열을 추가하여 다시 해싱하는 방식으로 문제 발생도 방지해야 한다.
👉 매 요청마다 데이터베이스에서 해당 단축 URL이 존재하는지 확인해야 하므로 성능이 떨어진다. 성능 개선을 위해 블룸 필터를 활용하여 불필요한 DB 조회를 최소화하는 방안도 고려해야 한다.

 

 

URL redirecting

여기에서 301 redirect vs 302 redirect를 비교해보므로서 왜 301 redirect를 선택했는지 설명할 수 있다.

📌 301 redirect
요청된 URL이 영구적으로(permanently) 원본 URL로 이동했음
이 방식은 브라우저가 응답을 캐싱하기 때문에, 동일한 URL에 대한 이후 요청은 URL 단축 서비스로 가지 않고 직접 원본 URL 서버로 이동한다. 즉, 한 번만 URL Shortener에 요청이 전달되고 이후에는 브라우저가 바로 원본 URL로 접속한다.

👉 한 번만 URL Shortener에 요청이 전달되므로 서버 부하를 줄이는 것에 유리하다.

📌 302 redirect
요청된 URL이 임시로(temporary) 이동했음
이후에도 동일한 URL 요청이 발생하면 항상 URL Shortener에 먼저 요청이 전달되고, 이후 URL Shortener가 원본 URL을 찾아 리다이렉트한다. 

👉 클릭 수, 방문 경로, 유입 소스 등의 데이터를 추적할 수 있다.

📌 URL redirect 구현 방법
가장 직관적인 방법은 { key: 단축 URL, value: 원본 URL } 의 해시 테이블(Hash Table)을 사용하는 것이다.
조회 속도가 (O(1))으로 빠르기 때문이다.

 

 

 

다음편 예고..

시스템 디자인 (High-Level Design)

URL Shortener 서비스의 핵심 구성 요소와 다이어그램을 정의한다.

✅ 아키텍처 개요
사용자가 긴 URL을 입력하고 "Shorten" 버튼 클릭
API 서버가 URL을 저장하고 짧은 ID를 생성
데이터베이스에 저장 후 사용자에게 단축된 URL 반환
사용자가 단축 URL을 입력하면 원래 URL로 리다이렉트

✅ 주요 컴포넌트
API Gateway: 클라이언트 요청을 처리하고 로드 밸런싱 수행 (또는 로드 밸런서를 따로 두는 방법)
Application Layer: URL 단축 및 리디렉션 로직을 처리
Database (SQL or NoSQL): 원본 URL과 단축 URL 저장
Caching Layer (Redis): 자주 조회되는 URL을 캐싱하여 빠르게 제공
Logging & Analytics: URL 사용 통계를 수집

 

📌 High-Level Architecture 다이어그램

예시: 

Client → API Gateway → Application Server → Database
                          ↘ Redis Cache

온라인으로 면접을 보는 경우 draw.io등으로 빠르게 그려내는 연습도 필요할 수 있다.

 

 

 

 

전체적인 내용을 봤을 때, 중요하다고 생각되는 부분은 이런 것들이 있다.

* 주어진 요구사항을 있는 그대로 받아들이지 않고, 발생할 수 있는 문제 또는 아이디어를 생각해내고 질문할 수 있다.

* 어떤 시스템 구성 요소를 선택할 때, (가능하면) 두가지 이상의 옵션을 제시할 수 있고 그 중에서 적절한 이유와 함께 한 가지를 선택할 수 있다. (내가 생각한 이유가 틀릴 수도 있지만, 어쨌든 내가 제대로 알고는 있고 그 이유를 토대로 결정을 내릴 수 있다는 것이 중요할듯)

* 어느 정도의 딥다이브가 필요하다.