System Outline

---

소개

• Tracking Link를 통해 사용자들이 원하는 URL로 잘 이동할 수 있는 서비스 제공
• Tracking Link에는 다양한 정보들이 파라미터로 붙을 수 있는데, 이 경우 URL이 매우 길어지는 단점이 있다.
• 이러한 점을 해결하기 위해, URL을 짧게 만들어주는 기능과 Tracking 기능을 개발한다.
• 하루에 10억번의 요청이 발생하고 빠른 응답과 통계를 제공하는 시스템 개발

---

기능

Url shorten

• 입력 폼에 줄이고 싶은 URL을 입력

Url redirection

• ShortId를 도메인 + /r/{shortId} 입력 -> 리다이렉션

Statistics

• 7일동안 ShortId 리다이렉션 횟수 조회
• User-Agent, Client-IP 를 기준으로 이벤트 발생하므로 추후에 client 정보를 활용할 수 있음.

---

요구사항, 가정 및 예상

요구사항

• 아래 조건을 만족하는 random shortId 생성해야함.
  • 3글자 이상의 alphanumeric 문자열
  • unique 해야함
  • 가능하면 짧아야함
• 하루에 10억번 이상의 클릭이 발생하는데 아래 2가지 조건을 만족해야함.
  • 빠르게 제공한다.
  • 통계를 저장한다.

가정 및 예상

가정

• 가정 1: Short URL은 Read Heavy 함.

  • Write 작업 수보다 Read 작업 수가 훨씬 더 많을 것으로 Read Heavy 하다고 가정
  • read 및 redirection requests :write requests = 100:1이라고 가정함.

• 가정 2: 데이터를 3년 동안 저장함.

  • 요구 사항에는 없지만, 데이터를 3년 동안 저장해야 한다고 가정.

• 가정 3: 각 데이터의 용량은 최대 500 Bytes

• 가정 4: Short URL은 8:2 법칙을 따른다.(파레토 원칙)

  • 캐시 히트의 약 80%가 데이터의 20%에서 발생한다고 가정
  • 전체 URL 중 20%를 캐싱하면 80%의 캐시 히트가 발생할 것이라고 가정

예상

• 예상 1: 가정 1에 따른 Requests per day Estimates(하루동안 발생하는 요청수)
  • read 및 redirection requests per day
    • approximately 990M(9억 9천만)
  • write requests per day
    • approximately 10M(1천만)
• 예상 2: 가정 1에 따른 Traffic per sec Estimates(단위 초당 발생하는 트래픽)
  • read 및 redirection requests per sec
    • 990M / 24hr * 3600sec = approximately. 11,458 / sec
  • write requests per sec
    • 10M / 24hr * 3600sec = approximately 115.74 / sec
• 예상 3: 가정 1,2,3에 따른 Storage per 3 years Estimates(DB 용량)
  • write requests per day
    • 10M(1천만)
  • data counts during 3 years
    • 10M 30 days 12 month * 3 years = approximately 10.8B (108억)
  • Needed total storage per 3 years
    • 10.8B * 500bytes = approximately 5.4TB
• 예상 4: 가정 1,3에 따른 Bandwidth per sec Estimates(대역폭)
  • write requests per sec * data size
    • 500 bytes * 115.74 / sec = approximately 57.87KB
  • read 및 redirection requests per sec * data size
    • 500 bytes * 11,458 / sec = approximately. 5.729MB
• 예상 5: 가정 1,3,4에 따른 Caching Memory Estimates(캐시 메모리)
  • URL의 20%를 캐싱하면 대략 80 퍼센트의 캐시 히트가 발생할 것이라고 예상할 수 있다.
  • 하루 당 990M Read Requests가 발생하므로, 이 중 20%만 캐싱을 한다고 하면 필요한 메모리 용량은
    • 990M * 0.2 * 500Bytes = 대략 100GB
    • 중복된 요청이 발생한다고 가정하면 실제 필요한 캐싱 용량은 100GB 보다 더 적을 것으로 예상된다.
• 종합: Total Estimates
  • Write Requests: 115.74/s
  • Read Requests: 11458/s
  • Incoming Data: 57.87KB
  • Outgoing Data: 5.729MB
  • Storage for 3 years: 5.4TB
  • Memory for Caching: 100GB