System Designing Pastebin

1. 목표 Site

pastebin.com, controlc.com 등

 

2. Pastebin 서비스란?

사용자가 text를 네트워크를 통해서 특정 공간에 저장을 하고, 접근 가능한 unique한 url을 받음으로써 해당 url로 해당 저장 공간을 접근 할 수 있는 서비스

2021.08.01 - [System Design] - Shortening Url Service Design

Shortening Url Service를 응용한 서비스라고 생각하면 된다.

 

3. 시스템 요구사항

3.1. 기능 요구 조건

• text를 upload 또는 붙여 넣기로 저장이 가능해야한다.
• 저장된 데이터를 접근 가능한 unique url을 제공 한다.
• 일정 시간이 지나면 자동으로 해당 url은 종료되거나, 사용자가 지정한게 있다면 해당 시간 이후 삭제 된다.
• 사용자가 url을 선택 할 수 있다. (custom alias)

 

3.2. 비기능 요구조건

• 고 신뢰성을 제공해야 한다. 어떤 데이터도 지워지면 안된다.
• 고 가용성을 제공해야 한다.
• 최소한의 지연으로 해당 서비스에 접근 가능해야 한다.
• unique url은 예측되면 안된다.

 

• 확장 요구조건
• 분석 가능 환경
• REST APIs로 접근 가능해야 함

 

4. 디자인시 고려사항

• 사용자가 일회 업로드 할 수있는 데이터의 양은 10MB를 넘지 못한다
• URLs의 사이즈는 제한적이다. 사용자가 custom으로 넣을 수도 있지만 이 역시도 제한된 범위 내에서 DB를 통해 제공가능한 일관된 URL을 제공한다.

 

5. 용량 산정

기본적인 read : write의 ratio를 5:1이라고 전제한다.

5.1. Traffic Estimates

write를 위한 요청이 하루에 1million/day 이라고 예상 할 경우, 초당 Traffic 수는

• $11.5 write/sec = 1M/24/60/60$

Read를 위한 요청수는 5배 임으로 5 million/day라고 볼수 있고, 초당 Traffic 수는

• $57.8 read/sec = 5M/24/60/60$

가 된다.

 

5.2. Storage Estimates

사용자는 최대 1회 10MB의 데이터를 uplaod 할 수 있다.

하지만 일반적으로 10MB를 사용하지는 않고 평균적으로 10KB정도를 사용함으로 하루 저장용량은

• $10GB/day = 1M * 10KB$

하루에 10GB 정도의 용량이 사용된다.

만약에 해당 공간을 10년에 걸쳐서 유지 한다고 하면

• $36TB = 10GB * 365 * 10$

36TB의 Storage가 필요하게 된다.

이것은 Url 유지 갯수와도 동일한데

• $3.6 Billion = 1M * 365 * 10$

3.6 Billion이 필요하다.

이것을 Base64로 나타낼수 있는 String의 길이를 확인 할 수 있는데

• $68Billion ~= 64^6$

임으로 6 length만 있어도 충분히 사용이 가능한 url을 발행 할 수 있다.

만약에 한글자당 1 byte의 저장 공간이 필요하다고 하면

• $21.6GB = 3.6 Billion * 1byte * 6$

가 필요하다.

22GB정도는 36TB에 비하면 굉장히 작은 공간이기 때문에 계산 대상에서 제외 시켜도 문제는 없다.

Storage는 일반적으로 70%를 최대 넘지 않도록 하는 것이 일반적임으로

• $52TB = 32TB/7 * 10$

52TB가 필요하다.

 

5.3. Bandwidth estimates

위에서 초당 11.5의 write가 발생한다고 했다.

client에서 server로 보내는 Traffic임으로 이것을 Ingress라고 명명한다.

계산하기 편리하게 초당 12 write/sec 가 발생한다고 생각하자.

한번의 write는 약 10KB를 발생 시킨다고 했음으로

• Ingress = $120KB/sec = 12 * 10KB$

라고 생각할 수 있다.

반대로 Server client로 보내는 데이터를 Egress라고 명명한다.

초당 57.8 read가 발생한다고 했음으로 계산하기 편리하게 58 read/sec라고 생각해 보자.

한번의 read에 필요한 Data도 약 10KB로 볼수 있음으로

• Egress = $580KB = 58 * 10KB$

가 된다.

두개의 Traffic을 같이 합친다고 해도 0.7MB/sec 정도의 Bandwidth만 필요함으로 큰 대역폭이 필요 하진 않다는 것을 알 수 있다.

 

5.4. Memory estimates

20%의 Data가 Traffic의 80%를 차지하게 됨으로 하루에 발생하는 Read양의 20%를 Cache 할 수 있도록 하자.

• $10G = 10B = 5M * 10KB * 0.2$

약 10G 정도면 충분한 메모리양이 될 수 있을 것으로 보인다.

 

5.5. System API

addPaste(api_dev_key, paste_data, custom_url=none, user_name=none, paste_name=none, expire_date=None)

• api_dev_key : api developer key
• paste_data : text data
• custom_url : 사용자 요구에 의한 custom url
• user_name : url을 생성하는데 사용할 이름
• paste_name : paste name
• expire_date : 삭제 예정 날짜

return : 성공일 경우 shorten url 실패면 error

 

getPaste(api_dev_key, api_paste_key)

Data를 읽어오는 api인데 data를 프로그램적으로 얻어오려면 paste key가 필요하다.

 

deletePaste(api_dev_key, api_paste_key)

Paste된 데이터를 삭제

 

6. Database 설계

• billions의 rows를 저장해야 한다.
• 데이터 자체는 1KB 미만이다
• 큰 데이터는 MB 이상일 수 있다
• 각 Row간의 연관 관계는 없다.
• Read가 주를 이루는 서비스 이다.

User는 1개 이상의 Paste를 갖을 수 있고 각 Paste는 1개의 Url과 연결된다.

그런데 여기서 주의 해야할 것은 Data 자체를 Row로 유지할 수도 있지만, 다른 Storage(amazon S3같은)의 링크일 수도 있어야 한다.

 

7. High-Level Design

Client의 요청을 Web Application Server가 read와 write를 처리할 수있고, 해당 Application Server는 Metadata를 갖고 있는 Database와 Data 자체를 갖고 있는 Storage와 각각 연동이 가능 할 수 있어야 한다.

 

8. 상세(Component Design)

8.1. Application Server

Inboun와 outboud의 Traffic을 감당하며 중간에서 Metadata BD와 Object Storage와의 Data Delivery를 처리하는 기능이다.

이중에 Inbound Traffic에서 처리하는 기능에 대해서 생각해 보자.

• Application Server는 들어온 Traffic을 Object Storage에 담고 Metadata에 해당 정보를 저장 시킨다
  • 여기서 고려해 봐야 할것은 10MB의 Traffic을 누수 없이 잘 처리 하는가? 이다.
  • 저장 Failure Point or Continue Upload 기능 등을 고려해 볼 수 있다.
• 정상적으로 저장이 완료된 이후 url key를 generate해서 client에게 보내야 한다.
  • Hash나 Random key를 6자리 Letter로 내보낼 수 있지만, 중복이 발생할 여지를 고려해야 한다.
  • 미리 Generated Key를 생성해 놓은 값을 Assign 하는 방식의 고려가 필요하다.
• Key Gneration Service
  • 앞서 68Billion의 key를 미리 생성해 놓는다.
  • 이 key는 사용되지 않은 키와, Used key로 분리 될 수 있다.
  • Application Server들에게 일정양의 키를 배분하고 Used key로 관리하면, 빠르게 url key를 client에게 제공 가능하다.
  • Server Down이 발생할 경우 해당 키는 loss 하게 되는데, 이미 필요 키 이상의 양을 만들어 놨기 때문에 큰 문제는 없다.
  • 물론 주기적으로 key를 purge 해줌으로써 해당 키를 다시 살려 받아야 한다.
  • Single Point Failure가 될 수 있다. Fail-over 를 만들어 줘야 한다.

Outbound를 알아 보자

• Client가 unique url과 함께 접근할 경우 해당 url과 연관된 Object 정보를 Storage에서 얻어온 후 화면에 표시해 준다.
• 단, 비공개로 설정되어 있는 경우 User정보를 확인하던가 아니면 Password를 입력하는 방식을 사용해도 좋다.

 

8.2. Datastore Layer

• Metadata database : SQL같은 Relational DB를 사용하거나, No SQL형태의 key-value DB를 사용해도 좋다.
• Object Storage : Text Data를 Object 형태로 제공하면서, 만약에 저장공간이 차게 되면 Server를 쉽게 증설 함으로써 해당 문제를 해결한다. (aws storage S3)