[대규모 시스템 설계 기초] 2장. 개략적인 규모 추정

Use Back-Of-Envelope-Calculations To Choose The Best Design

참고 문헌

• 메모리는 빠르지만 디스크는 아직도 느리다
• 디스크 탐색(seek)은 가능한 한 피하라
• 단순한 압축 알고리즘은 빠르다
• 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라
• 데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고 받는 데는 시간이 걸린다

가용성에 관계된 수치들

고가용성(high availability)

• 시스템이 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력
• 퍼센트%로 표현
• 100%는 시스템이 단 한 번도 중단된 적이 없었음을 의미
• 대부분의 서비스는 99%에서 100% 사이의 값을 가짐

SLA(Service Level Agrement)

• 서비스 사업자가 보편적으로 사용하는 용어
• 서비스 사업자와 고객 사이에 맺어진 합의 
• 서비스의 가용시간(uptime)이 공식적으로 기술되어 있음
• 가용시간은 관습적으로 숫자 9를 사용해 표시
• 9가 많을수록 좋음

예제: 트위터 QPS와 저장소 요구량 추정

가정

• 월간 능동 사용자는 3억명
• 50%의 사용자가 트위터를 매일 사용
• 평균적으로 각 사용자는 매일 2건의 트윗을 올림
• 미디어를 포함하는 트윗은 10% 정도
• 데이터는 5년간 보관

추정

QPS (query per second) 추정치

Queries Per Second; QPS초당 쿼리 수

- 정보 조회 시스템의 트래픽 측정 단위 중 하나
- 검색엔진, 데이터베이스, API 등에서 사용하는 단위
https://zetawiki.com/wiki/%EC%B4%88%EB%8B%B9_%EC%BF%BC%EB%A6%AC_%EC%88%98_QPS

• 일간 능동 사용자(DAU) = 3억 * 50% = 1.5억
• QPS = 1.5억 * 2트윗 / 24시간 / 3600초 = 약 3500
• 최대 QPS = 2 * QPS = 약 7000

미디어 저장을 위한 저장소 요구량

• 평균 트윗 크기
  • tweet_id에 64바이트
  • 텍스트에 140바이트
  • 미디어에 1MB
• 미디어 저장소 요구량 = 1.5억 * 2 * 10% * 1M = 30TB / 일
• 5년간 미디어를 보관하기 위한 저장소 요구량 = 30TB * 365 * 5 = 약 55PB

팁

• 근사치를 활용한 계산(round and approximation)
• 단위(unit)를 붙이라.
• QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수등 추정 문제