CH2. 개략적인 규모 추정

이하얀·2024년 6월 5일

🎸 Theory Summary

목록 보기

3/10

구글 시니어 펠로(Senior Fellow) 제프 딘(Jeff Dean)
- “개략적인 규모 추정(back-of-the-envelope estimation)은 보편적으로 통용되는 성능 수치상에서 사고 실험(thought experiments)을 행하여 추정치를 계산하는 행위로서, 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것”
개략적 규모 추정을 효과적으로 해내는 방법
- 규모 확장성을 표현하는 데 필요한 기본기에 능숙해야 함
- 특히, 2의 제곱수나 응답지연(latency) 값, 가용성에 관계된 수치들을 기본적으로 잘 이해하고 있어야 함

분산 시스템에서 다루는 데이터 양은 엄청나게 커질 수 O → 계산법은 기본을 크게 벗어나지 X
- 데이터 볼륨의 단위를 2의 제곱수로 표현하면 어떻게 되는지 알아야 함
- 최소 단위는 1바이트, 8비트로 구성
- ASCII 문자 1개가 차지하는 메모리 크기가 1바이트

흔히 쓰이는 데이터 볼륨 단위

2의 x 제곱	근사치	이름	축약형
10	1천(thousand)	1킬로바이트(Kilobyte)	1KB
20	1백만(million)	1메가바이트(Megabyte)	1MB
30	10억(billion)	1기가바이트(Gigabyte)	1GB
40	1조(trillion)	1테라바이트(Terabyte)	1TB
50	1000조(quadrillion)	1페타바이트(Petabyte)	1PB

구글의 제프 딘 - 2010년에 통상적인 컴퓨터에서 구현된 연산들의 응답지연 값 공개

아직도 이 수치들은 컴퓨터 연산들의 처리 속도가 어느 정도인지 짐작할 수 있게 해줌

연산명	시간
L1 캐시 참조	0.5ns
분기 예측 오류(branch mispredict)	5ns
L2 캐시 참조	7ns
뮤텍스(mutex) 락/언락	100ns
주 메모리 참조	100ns
Zippy로 1KB 압축	10,000ns = 10μs
1 Gbps 네트워크로 2 KB 전송	20,000ns = 20μs
메모리에서 1 MB 순차적으로 read	250,000ns = 250μs
같은 데이터 센터 내에서의 메시지 왕복 지연 시간	500,000ns = 500μs
디스크 탐색(seek)	10,000,000ns = 10ms
네트워크에서 1 MB 순차적으로 read	10,000,000ns = 10ms
디스크에서 1 MB 순차적으로 read	30,00.000ns = 30ms
한 패킷의 CA(캘리포니아)로부터 네덜란드까지의 왕복 지연시간	150,000,000ns = 150ms

고가용성(high availability)
- 시스템이 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력을 지칭하는 용어
- 표현 값: 퍼센트(percent)
  - 100% → 시스템이 단 한 번도 중단된 적이 없었음을 의미
  - 대부분의 서비스는 99% ~ 100% 사이의 값을 가짐
SLA(Service Level Agreement)
- 서비스 사업자(service provider)가 보편적으로 사용하는 용어
- 서비스 사업자와 고객 사이에 맺어진 합의를 의미
- 이 합의에는 서비스 사업자가 제공하는 서비스의 가용시간(uptime)이 공식적으로 기술되어 있음
  - 가용시간: 관습적으로 숫자 9를 사용해 표시, 9가 많으면 많을수록 좋음
- 아마존, 구글, 마이크로소프트 같은 사업자 : 99%이상의 SLA를 제공
9의 개수와 시스템 장애 시간(downtime)

가용률	하루당 장애시간	주당 장애시간	개월당 장애시간	연간 장애시간
99%	14.40분	1.68시간	7.31시간	3.65일
99.9%	1.44분	10.08분	43.83분	8.77시간
99.99%	8.64초	1.01분	4.38분	52.60분
99.999%	864.00밀리초	6.05초	26.30초	5.26분
99.9999%	86.40밀리초	604.80밀리초	2.63초	31.56초

💡 궁금한 점 1: 가용률이 높더라도 연간 장애시간이 3.65일 정도로 꽤나 긴 건 이유가 뭘까?

기본적으로 대규모 시스템을 고려했을 때에는, 일반적인 규모의 시스템보다 고가용성을 띈다고 하더라도 장애시간 자체는 꽤 길 수 있을 것이라 판단

다음 수치는 연습용(트위터의 실제 성능이나 요구사항과는 아무 관계 X)
가정
- 월간 능동 사용자(monthly active user)는 3억(300million)명이다.
- 50%의 사용자가 트위터를 매일 사용한다.
- 평균적으로 각 사용자는 매일 2건의 트윗을 올린다.
- 미디어를 포함하는 트윗은 10% 정도다.
- 데이터는 5년간 보관된다.
추정
- QPS(Query Per Second) 추정치
  - 일간 능동 사용자(Daily Active User, DAU) = 3억 x 50% = 1.5억(150million)
  - QPS = 1.5억 x 2 트윗 / 24시간 / 3600초 = 약 3500
  - 최대 QPS(Peek QPS) = 2 x QPS = 약 7000
미디어 저장을 위한 저장소 요구량
- 평균 트윗 크기
  - tweet_id에 64바이트
  - 텍스트에 140바이트
  - 미디어에 1MB
- 미디어 저장소 요구량: 1.5억 x 2 x 10% x 1 MB = 30TB/일
- 5년간 미디어를 보관하기 위한 저장소 요구량: 30TB x 365 x 5 = 약 55PB

근사치를 활용한 계산(rounding and approximation)
- 면접장에서 복잡한 계산을 하는 것은 어려운 일
- 예를 들어, “99987 / 9.1”의 계산 결과는 무엇인가? → 이런 곳에 시간을 쓰는 것은 낭비
- 계산 결과의 정확함을 평가하려는 목적이 X
- 적절한 근사치를 활용해 시간 절약하기 → “100,000/10”로 간소화
가정(assumption) 적어두기
- 가정들을 적어두기. 나중에 참고!
단위(unit) 적기
- 5라고만 적으면 5KB인지 5MB인지 알 수가 없음
- 단위를 붙이는 습관을 들여두면 모호함 방지 가능
많이 출제되는 개략적 규모 추정 문제는 QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등을 추정하는 것
- 면접에 임하기 전에 이러한 값들을 계산하는 연습 미리 해두기
- 완벽함을 달성하는 방법은 연습뿐

언젠가 내 코드로 세상에 기여할 수 있도록, BE 개발 기록 노트☘️