2장. 개략적인 규모 추정
가상 면접 사례로 배우는 대규모 시스템 설계 기초를 읽고 정리한 글입니다.
시스템 설계 면접을 볼 때, 때로는 시스템 용량이나 성능 요구사항을 개략적으로 추정해 보라는 요구를 받게 된다.
이건 단순히 계산 문제라기보다,
주어진 문제를 구조적으로 풀어가며 합리적으로 추정할 수 있는지,
시스템의 확장성과 실제성을 고려한 설계를 할 수 있는지를 보여주기 위한 것이다.
💡 개략적인 규모 추정(back-of-the-envelope estimation)
: 보편적으로 통용되는 성능 수치상에서 사고 실행을 행하여 추정치를 계산하는 행위로써, 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것이다.
개략적 규모 추정을 효과적으로 해내려면 규모 확장성을 표현하는 데 필요한 기본기에 능숙해야 하며,
특히 2의 제곱수나 응답지연 값, 가용성에 관계된 수치를 기본적으로 잘 이해하고 있어야 한다.
2의 제곱수
제대로 된 분산 시스템 데이터 계산 결과를 얻으려면, 데이터 볼륨의 단위를 2의 제곱수로 표현하는 방법을 알아야 한다.
최소 단위는 1바이트이며, 8비트로 구성된다.
흔히 쓰이는 데이터 볼륨 단위
| 2의 X제곱 | 근사치 | 이름 | 축약형 |
|---|---|---|---|
| 10 | 1천 | 1킬로바이트 | 1KB |
| 20 | 1백만 | 1메가바이트 | 1MB |
| 30 | 10억 | 1기가바이트 | 1GB |
| 40 | 1조 | 1테라바이트 | 1TB |
| 50 | 1000조 | 1페타바이트 | 1PB |
모든 프로그래머가 알아야 하는 응답지연 값
구글의 제프 딘은 2010년에 통상적인 컴퓨터에서 구현된 연산들의 응답지연값을 공개한 바 있다.
더 빠른 컴퓨터가 등장하면서 몇몇은 유효하지 않은 값이지만, 아직도 이 수치들은 컴퓨터 연산들의 처리 속도가 어느 정도인지 짐작할 수 있도록 해 준다.
| 연산명 | 시간 |
|---|---|
| L1 캐시 참조 | 0.5ns |
| 분기 예측 오류(branch mispredict) | 5ns |
| L2 캐시 참조 | 7ns |
| 뮤텍스 락/언락 | 100ns |
| 주 메모리 참조 | 100ns |
| Zippy로 1KB 압축 | 10,000ns = 10μs |
| 1Gbps 네트워크로 2KB 전송 | 20,000ns = 20μs |
| 메모리에서 1MB 순차적으로 read | 250,000ns = 250μs |
| 같은 데이터 센터 내 메시지 왕복 지연시간 | 500,000ns = 500μs |
| 디스크 탐색(seek) | 10,000,000ns = 10ms |
| 네트워크에서 1MB 순차적으로 read | 10,000,000ns = 10ms |
| 디스크에서 1MB 순차적으로 read | 30,000,000ns = 30ms |
| 한 패킷이 CA(캘리포니아)로부터 네덜란드까지 왕복 지연시간 | 150,000,000ns = 150ms |
위 그래프를 시각화한 수치는 다음과 같다(2020년 기준)
연도별 수치 참고
수치들을 분석하면 다음과 같은 결론이 나온다.
- 메모리는 빠르지만 디스크는 아직도 느리다.
- 디스크 탐색(seek)은 가능한 한 피하라.
- 단순한 압축 알고리즘은 빠르다.
- 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라.
- 데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고받는 데는 시간이 걸린다.
'단순한 압축 알고리즘은 빠르다'가 무슨 말일까?
데이터를 압축하거나 해제할 때 사용하는 알고리즘 중 복잡하지 않고 계산량이 적은 것들은 CPU 계산이 적어서 매우 빠르게 동작한다는 뜻이다.
가용성에 관계된 수치들
고가용성(high availability)은 시스템이 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력을 지칭하는 용어다.
주로 퍼센트(%)로 표현하는데, 100%는 시스템이 단 한 번도 중단된 적이 없었음을 의미한다.
대부분의 서비스는 99%에서 100% 사이의 값을 갖는다.
SLA(Service Level Agreement)는 서비스 사업자가 보편적으로 사용하는 용어로, 서비스 사업자와 고객 사이에 맺어진 합의를 의미한다.
아마존, 구글, 마이크로소프트 같은 사업자는 99% 이상의 SLA를 제공한다.
가용시간은 관습적으로 숫자 9를 사용해 표시하며, 9가 많으면 많을수록 좋다고 생각하면 된다.
9의 개수와 시스템 장애시간(downtime) 사이의 관계
| 가용률 | 하루당 장애시간 | 주당 장애시간 | 개월당 장애시간 | 연간 장애시간 |
|---|---|---|---|---|
| 99% | 14.40분 | 1.68시간 | 7.31시간 | 3.65일 |
| 99.9% | 1.44분 | 10.08분 | 43.84분 | 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초 |
예제 - 트위터 QPS와 저장소 요구량 추정
가정
- 월간 능동 사용자는 3억 명이다
- 50%의 사용자가 트위터를 매일 사용한다
- 평균적으로 각 사용자는 매일 2건의 트윗을 올린다
- 미디어를 포함하는 트윗은 10% 정도다
- 데이터는 5년간 보관된다
추정
QPS(Query Per Second) 추정치
- 일간 능동 사용자 = 3억 * 50% = 1.5억
- QPS = 1.5억 * 2 트윗 / 24시간 / 1분(3600초) = 약 3500
- 최대 QPS = 3500 * 2 = 약 7000
🤔 최대 QPS를 구할 때, 왜 QPS에 2를 곱할까?
평균 QPS는 하루 전체 트래픽을 고르게 나눈 값이지만, 현실에서는 특정 시간대에 트래픽이 몰리는 피크 현상이 발생한다.
보통 이런 피크 대비를 위해 여유 버퍼를 잡아야 하고, 일반적으로 평균 QPS의 약 2배를 최대 QPS로 추정한다.
`미디어 저장을 위한 저장소 요구량`
- 평균 트윗 크기(avg)
- tweet_id: 64바이트
- 텍스트: 140바이트
- 미디어: 1MB
- 일간 미디어 저장소
- 1.5억 2(개) 10% * 1MB = 30TB/일
- 5년간 미디어 저장소
- 30TB 365일 5년 = 약 55PB
팁
결과를 내는 것보다 올바른 절차를 밟느냐가 중요하다.
면접자가 보고싶어 하는 것은 여러분의 문제 해결 능력이다.
- 적절한 근사치를 활용하여 시간을 절약하라
- 나중에 볼 수 있도록 가정들을 적어 두라
- 단위를 붙이는 습관을 들여 모호함을 방지하라(ex 5MB, 5KB)
- 많이 출제되는 개략적 규모 추정 문제는 QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등을 추정하는 것이다.