URL Shortener (URL 단축 서비스) 예시

단순함 뒤에 숨겨진 복잡성

https://www.google.com/search?q=system+design 같은 긴 URL을 https://tinyurl.com/a1b2c3d4(임의의 주소입니다 클릭해도 뭐 없을겁니다ㅎㅎ) 와 같이 짧게 줄여주는 서비스, 바로 URL Shortener입니다. 겉보기에는 매우 간단한 서비스처럼 보이지만, 전 세계 수많은 사용자의 요청을 처리하고 방대한 양의 데이터를 안정적으로 저장하며 빠르게 응답해야 하는 시스템입니다.

URL Shortener를 설계하는 과정은 지금까지 우리가 배운 분산 시스템의 모든 핵심 개념들(Key-Value Store, Consistent Hashing, Rate Limiter 등)을 모두 동원해야하는 적당한 실전 연습 문제입니다. (물론 면접에선 직접 언급 되는 경우는 너무 오래된 문제라 이젠 안나올테지만요) 이번 포스팅에서는 URL Shortener의 설계 과정을 단계적으로 풀어보며, 대규모 서비스 설계에 대한 실질적인 감각을 키워보겠습니다.

---

1단계: 요구사항 및 제약사항 명확화

설계에 앞서, 먼저 시스템의 요구사항을 명확히 정의하는 것이 가장 중요합니다.

• 기능적 요구사항:
  • URL 단축(Shortening): 긴 원본 URL을 입력받아 짧은 URL을 생성하고 저장해야 합니다.
  • URL 리다이렉션(Redirection): 짧은 URL로 요청이 오면, 원래의 긴 URL로 리다이렉션해야 합니다.
  • 커스텀 단축: 사용자가 원하는 짧은 URL을 직접 지정할 수 있어야 합니다.
• 비기능적 요구사항:
  • 고가용성: 시스템은 항상 동작해야 합니다.
  • 낮은 지연 시간: 특히 리다이렉션 요청은 매우 빠르게 처리되어야 합니다.
  • 높은 확장성: 초당 수많은 요청과 수십억 개의 URL을 처리할 수 있어야 합니다.
• 제약사항 및 예상 트래픽:
  • 읽기 vs. 쓰기: URL 단축(쓰기) 요청보다 리다이렉션(읽기) 요청이 훨씬 많을 것입니다. 읽기 중심(Read-Heavy) 시스템으로 설계해야 합니다.
  • 예상 규모: 월간 1억 개의 신규 URL, 읽기 요청은 쓰기의 100배 (초당 약 4000 QPS) 등 구체적인 수치를 가정합니다.

면접 상황이라면, 보통 제약 사항 정도는 적당히 현실적인 숫자를 제안하면 되고, 요구사항을 파악하는 과정에서는 면접관과 이야기를 나누면 됩니다. 전부 물어보면 안되고, 어느정도 현실적으로, 면접 시간내로 설계 하고 이야기 나눌 수 있을만큼만 핵심 기능에 대해서만 정의 합니다. - 보통 위의 정도로 이야기하면 충분 합니다. (로그인, 인증, 과금 등의 실서비스 디테일은 신경 쓰지 않아도 됩니다)

---

2단계: 개략적인 설계 및 핵심 컴포넌트 식별

요구사항을 바탕으로 시스템의 큰 그림을 그려봅시다.

• 핵심 컴포넌트:
  • API 서버: URL 단축 및 리다이렉션 요청을 처리합니다.
  • 단축 키 생성 서비스: 짧은 URL에 사용할 고유한 키(예: a1b2c3d4)를 생성합니다.
  • 데이터베이스(DB): [단축 키, 원본 URL] 쌍을 저장합니다.
  • 캐시(Cache): 자주 접근하는 URL 리다이렉션 요청에 빠르게 응답하기 위해 사용합니다.
  • 로드 밸런서(Load Balancer): 트래픽을 API 서버에 분산시킵니다.
  • Rate Limiter: 악의적인 요청을 막아 시스템을 보호합니다.
• 데이터 흐름:
  • URL 단축: User -> API Server -> 단축 키 생성 서비스 -> DB 저장 -> 단축 URL 반환
  • URL 리다이렉션: User -> API Server -> 캐시(Cache Miss 시) -> DB 조회 -> 원본 URL로 301/302 리다이렉션

---

3단계: 핵심 컴포넌트 심층 설계

이제 각 컴포넌트를 구체적으로 설계하며 트레이드오프를 고민해 봅시다.

3.1. 단축 키 생성 서비스 설계

가장 중요한 문제 중 하나는 중복되지 않는 고유한 단축 키를 어떻게 생성할 것인가입니다.

• 방법 1: 무작위 문자열 생성:
  • 개념: 랜덤한 문자열을 생성하고, DB에 이미 존재하는지 확인 후 저장합니다.
  • 장점: 구현이 간단하고, 키가 무작위로 생성되어 예측하기 어렵습니다.
  • 단점: 키가 충돌할 가능성이 있고, 충돌 시 재시도 로직이 필요합니다. 대량의 트래픽을 처리할 때 비효율적입니다.
• 방법 2: Base62 변환:
  • 개념: 고유한 ID를 생성하고, 이를 62진법(A-Z, a-z, 0-9)으로 변환하여 짧은 문자열을 만듭니다.
  • 장점: 키 충돌 걱정 없이 고유성을 보장하며, ID를 이용하므로 예측 가능합니다.
  • 구현:
    • 단일 DB의 AUTO_INCREMENT: 간단하지만 확장성 한계가 있습니다.
    • 분산 ID 생성 서비스: Snowflake 같은 분산 ID 생성기를 활용하여 여러 서버에서 독립적으로 고유한 ID를 생성합니다. 이는 매우 높은 확장성을 제공합니다.

3.2. 데이터베이스 설계 및 선택

• 어떤 DB를 사용할까?
  • [단축 키, 원본 URL]의 구조는 전형적인 Key-Value Store 형태입니다.
  • 관계형 DB(RDBMS): MySQL, PostgreSQL 등은 데이터 일관성이 뛰어나지만, 읽기/쓰기 요청이 많아지면 병목 현상이 발생할 수 있습니다.
  • NoSQL DB:
    • Key-Value DB(Redis, DynamoDB): 읽기/쓰기 성능이 매우 뛰어나고 수평 확장이 용이합니다. URL Shortener와 같은 단순한 키-값 구조에 최적입니다.
    • 설계 선택: 읽기 중심 시스템이므로, Key-Value DB를 메인 저장소로 사용하고, Consistent Hashing을 통해 데이터를 분산시키는 아키텍처가 이상적입니다.

3.3. 캐싱(Caching) 전략

• 왜 필요한가? 리다이렉션 요청이 쓰기 요청보다 100배 이상 많으므로, DB에 대한 부하를 줄이고 응답 속도를 극대화하기 위해 캐싱이 필수적입니다. (상황에 따라서 보통 캐시 레이어는 있으면 좋고 없어도 괜찮은 존재일 수 있으나 지금 같은 상황은 캐싱이 필수입니다.)
• 전략:
  • Read-through Cache: 요청이 들어오면 먼저 캐시에서 데이터를 찾고, 없으면 DB에서 가져온 후 캐시에 저장합니다.
  • Write-through Cache: 데이터를 쓸 때 캐시와 DB에 동시에 씁니다.
  • 무엇을 캐시할까?: 리다이렉션 요청은 Get(key) 연산이므로, 가장 자주 접근하는 URL들을 캐시하는 전략이 가장 효과적입니다.

Read-through , Write-through 전략을 언제 어떻게 쓸지에 대해서 물어볼 수 있습니다.

URL 생성을 하는 시점과 실제 사용되는 시점간의 시차가 어느정도냐에 따라, 호출 되는 빈도에 따라 선택하면 됩니다.
- 단축 URL 생성 후 요청이 금방 들어온다면 미리 캐싱해두는게 효율적이겠죠?

4단계: 확장성 및 고가용성 고려

• API 서버 확장성: 로드 밸런서 뒤에 여러 API 서버를 두어 트래픽을 분산시키고, 필요에 따라 서버를 수평 확장(Horizontal Scaling)합니다.
• 데이터베이스 가용성:
  • 복제(Replication): DB의 복제본(Replica)을 여러 개 두어, 읽기 요청을 분산하고, 주 서버(Primary) 장애 시 백업 서버로 빠르게 교체(Failover)합니다.
  • Consistent Hashing: 데이터 분산 및 노드 장애 시 영향을 최소화합니다.
• Rate Limiter 추가: API 서버 앞단에 Rate Limiter를 배치하여, URL 생성 요청(쓰기) 및 리다이렉션 요청(읽기)에 대한 트래픽을 제어합니다.

---

마치며: 연결하여 완성하기

URL Shortener는 복잡한 시스템의 구성 요소들을 어떻게 조합하고 활용해야 하는지 보여주는 완벽한 예제입니다. 우리는 이 설계를 통해 단일 컴포넌트의 지식을 넘어, 시스템 전반을 조망하는 통합적인 설계 역량을 확인해 볼 수 있었습니다.

• 요구사항 분석: Read-Heavy 시스템임을 파악.
• ID 생성 전략: 확장성 높은 분산 ID 생성기 활용.
• 저장소 선택: Key-Value DB의 최적성.
• 데이터 분산: Consistent Hashing.
• 성능 최적화: 캐싱 전략.
• 안정성 확보: Rate Limiter.

이처럼 시스템 디자인은 마치 여러 퍼즐 조각들을 맞춰 하나의 그림을 완성하는 과정과 같습니다. 

궁금한 점이 있으시다면 언제든지 질문해 주십시오!