2장 개략적인 규모 추정
- 개략적인 규모 추정을 효과적으로 해 내려면 규모 확장성을 표현하는 데 필요한 기본기에 능숙해야 한다.
2의 제곱 수
- 분산 시스템에서 다루는 데이터 양은 엄청 커질 수 있으나 계산법은 기본을 크게 벗어나지 않는다.
- 제대로된 계산 결과를 얻으려면 데이터 볼륨의 단위를 2의 제곱수로 표현하면 어떻게 되는지를 우선 알아야 한다.
- 최소 단위: 1바이트(8비트)
2의 x제곱 |
근사치 |
축약형 |
10 |
1천 |
1KB |
20 |
1백만 |
1MB |
30 |
10억 |
1GB |
40 |
1조 |
1TB |
50 |
1000조 |
1PB |
모든 프로그래머가 알아야 하는 응답지연 값
- 구글의 제프 딘은 2010년에 통상적인 컴퓨터에서 구현된 연산들의 응답지연 값을 공개했다.
- 몇몇은 빠른 컴퓨터의 등장으로 유효하지 않다.
- 그럼에도 컴퓨터 연산 처리 속도가 어느 정도인지 짐작하게 해준다.
연산명 |
시간 |
L1 캐시 참조 |
0.5ns |
분기 예측 오류 |
5ns |
L2 캐시 참조 |
7ns |
뮤텍스 락/언락 |
100ns |
주 메모리 참조 |
100ns |
Zippy로 1KB 압축 |
10,000ns |
1Gbps 네트워크로 2KB 전송 |
20,000ns |
메모리에서 1MB 순차적으로 read |
250,000ns |
같은 데이터 센터 내의 메시지 왕복 지연시간 |
500,000ns |
디스크 탐색 |
10,000,000ns = 10ms |
네트워크에서 1MB 순차적으로 read |
10ms |
디스크에서 1MB 순차적으로 read |
30ms |
한 패킷의 CA(캘리포니아)로부터 네덜란드까지 왕복 지연 시간 |
150ms |
- 수치 분석의 결과
- 메모리는 빠르지만 디스크는 아직 느리다.
- 디스크 탐색은 가능한 피하라.
- 단순한 압축 알고리즘은 빠르다.
- 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라.
- 데이터 센터는 보통 여려 지역에 분산되어 있어 센터 간 데이터 전송 시간이 걸린다.
가용성에 관계된 수치들
- 고가용성 - 시스템이 지속적으로 중단 없이 운영될 수 있는 능력
- SLA(Service Level Agreement) - 서비스 사업자와 고객 사이에 맺어진 가용시간에 관한 합의
- 구글, 아마존 등의 사업자는 99% 이상의 SLA를 제공하며 관습적으로 9를 사용해 표시한다.
- 9가 많을수록 좋다. (99% < 99.9% < 99.99%)
예제: 트위퍼 QOS와 저장소 요구량 추정
- 가정
- 월간 능동 사용자(MAU)는 3억명이다
- 50%의 사용자가 트위터를 매일 사용한다.
- 평균적으로 각 사용자는 매일 2건 트윗을 올린다.
- 미디어를 포함하는 트윗은 10% 정도다.
- 데이터는 5년간 보관된다.
- QPS(Query Per Second) 추정치
- 일간 능동 사용자(DAU) = 3억 x 50% = 1.5억
- QOS = 1.5억 x 2 트윗 / 24시간 / 3600초 = 약 3500
- 최대 QPS = 2 x QPS = 약 7000
- 미디어 저장을 위한 저장소 요구량
- 평균 트윗 크기
- tweet_id에 64바이트
- 텍스트에 140바이트
- 미디어에 1MB
- 미디어 저장소 요구량: 1.5억 x 2 x 10% x 1MB = 30TB/일
- 5년간 미디어를 보관하기 위한 저장소 요구량: 30TB x 365 x 5 = 약 55PB
팁
개략적 규모 추정과 관계된 면접에서 가장 중요한 것은 문제를 풀어 나가는 절차다.
- 근사치를 활용한 계산: 면접장에서 복잡한 계산을 하기 어렵다. 계산의 정확함을 평가하는게 아니기에 적절한 근사치를 활용하자.
- 가정들은 적어두라. 나중에 살펴볼 수 있도록
- 단위를 붙이는 습관을 들이면 모호함을 방지할 수 있다.
- 많이 출제되는 개략적 규모 추정 문제는 QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등을 추정하는 것.