2장 개략적인 규모 추정 #
구글의 시니어 펠로(senior fellow) 제프 딘(Jeff Dean)에 따르면,
“개략적인 규모 추정"은 보편적으로 통용되는 성능 수치상에서 사고 실험을 행하여 추정치를 계산하는 행위로서, 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것이다.
개략적 규모 추정을 효과적으로 해내려면 규모 확장성을 표현하는 데 필요한 기본기에 능숙해야 한다.
특히 2의 제곱수, latency(응답 지연), throughput(처리량, 처리율), 가용성과 관련된 수치들을 잘 이해하고 사용할 수 있어야 한다.
2의 제곱수 #
| 2^n | 근사치 | 단위 |
|---|---|---|
| 2^10 | 1,000 (1천) | KB |
| 2^20 | 1,000,000 (1백만) | MB |
| 2^30 | 1,000,000,000 (10억) | GB |
| 2^40 | 1,000,000,000,000 (1조) | TB |
| 2^50 | 1,000,000,000,000,000 (1,000조) | PB |
Latency (모든 프로그래머가 알야아 하는 응답 지연 값) #
구글의 제프 딘은 2010년에 통상적인 (컴퓨터에서 구현된 연산들의) 응답 지연 값을 공개한 바 있다.
이들 가운데 몇몇은 더 빠른 컴퓨터가 등장하면서 유효하지 않게 되었지만, 아래 표를 통해 대략적인 수치를 짐작할 수 있다.
| 연산 | 시간 |
|---|---|
| L1 캐시 | 0.5ns |
| Branch mispredict (분기 예측 오류) | 5ns |
| L2 캐시 | 7ns |
| Mutex lock/unlock | 100ns |
| Main Memory 참조 | 100ns |
| Zippy 1KB 압축 | 10,000ns = 10μs |
| 1 Gbps 네트워크에서 2KB 전송 | 20,000ns = 20μs |
| Memory 순차적 1MB READ (메모리에서 순차적으로 1MB READ) | 250,000ns = 250μs |
| (같은) IDC 내에서의 네트워크 왕복 지연시간 | 500,000ns = 500μs |
| Disk Seek 디스크 탐색 | 10,000,000ns = 10ms |
| 네트워크에서 1BM 순차적으로 READ | 10,000,000ns = 10ms |
| DISK에서 1MB 순차적 READ | 30,000,000ns = 30ms |
| 1 패킷의 CA(캘리포니아)로부터 네덜란드까지의 왕복 지연시간 | 150,000,000ns = 150ms |
위 표를 조금 정리해보면,
| 연산 | 시간 |
|---|---|
| L1 캐시 | 0.5ns |
| L2 캐시 | 7ns L1 에 비해 10배 이상의 비용이 든다. |
| Main Memory 참조 | 100ns L2 에 비해(CPU 참조에 비해) 최소 10배 이상의 비용이 든다. |
| 메모리에서 순차적 1MB READ | 250,000ns = 250μs |
| (같은) IDC 내에서의 네트워크 왕복 지연시간 | 500,000ns = 500μs |
| Disk Seek (디스크 탐색) | 10,000,000ns = 10ms |
| 네트워크에서 순차적 1MB READ | 10,000,000ns = 10ms |
| DISK에서 순차적 1MB READ | 30,000,000ns = 30ms |
| 1 패킷의 CA(캘리포니아)로부터 네덜란드까지의 왕복 지연시간 | 150,000,000ns = 150ms |
# (이 측정을 비교하는 것은 의미가 없겠지만) 대략적으로 어느정도 차이가 나는지 이해하자.
CPU 참조 (0.5 ~ 10ns)
ㄴ Main Memory 참조 (100ns ~ 250,000ns) (최소 10배 이상)
ㄴ DISK 참조 & 네트워크 참조 (10ms ~ ) (최소 4배 이상)
한 구글 엔지니어가 위의 딘 박사가 나열한 것을 토대로 2020년 기준으로 수치화한 내용도 있다.
| 연산 | 시간 |
|---|---|
| L1 캐시 | 1ns |
| Branch mispredict (분기 예측 오류) | 3ns |
| L2 캐시 | 4ns |
| Mutex lock/unlock | 17ns |
| 일반 상용 네트워크에서 2KB 전송 | 44ns 이 기준으로 1MB 이면 22,000ns(22μs) 기술/성능이 좋아져서인지? 제프 딘이 발표한 내용(10ms)보다 적은 비용(22μs)이 든다고 표시했다. |
| Main Memory 참조 | 100ns |
| Zippy 1KB 압축 | 2,000ns = 2μs 기술/성능이 좋아져서인지? 제프 딘이 발표한 내용(102μs)보다 적은 비용(2μs)이 든다고 표시했다. |
| Memory 순차적 1MB READ | 3,000ns = 3μs 기술/성능이 좋아져서인지? 제프 딘이 발표한 내용(250μs)보다 적은 비용(3μs)이 든다고 표시했다. |
| SSD(Disk)에서 임의 위치의 데이터 읽기 (Random Access) | 16,000ns = 16μs |
| SSD(Disk)에서 순차적 1MB READ | 49,000ns = 49μs |
| (같은) IDC 내에서의 네트워크 왕복 지연시간 | 500,000ns = 500μs 제프 딘이 발표한 내용과 동일하다. |
| DISK에서 1MB 순차적 READ | 825,000ns = 825μs 기술/성능이 좋아져서인지? 제프 딘이 발표한 내용(30ms)보다 적은 비용(825μs)이 든다고 표시했다. |
| Disk Seek 디스크 탐색 | 2,000,000ns = 2ms 기술/성능이 좋아져서인지? 제프 딘이 발표한 내용(10ms)보다 적은 비용(2ms)이 든다고 표시했다. |
| DISK에서 1MB 순차적 READ | 30,000,000ns = 30ms |
| 1 패킷의 CA(캘리포니아)로부터 네덜란드까지의 왕복 지연시간 | 150,000,000ns = 150ms 제프 딘이 발표한 내용과 동일하다. |
요약하면,
- 메모리는 빠르다. 디스크는 여전히 느리다.
- 디스크 탐색(Disk Seek)는 가능한 피하라.
- 디스크 탐색(Disk Seek)은 ‘같은 데이터 센터 내의 네트워크 왕복 지연시간’보다 느리며, ‘네트워크에서 순차적으로 1MB READ’ 하는 것과 동일한 비용이 발생한다.
- 단순한 압축 알고리즘은 빠르다.
- 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라.
- 단순한 압축 알고리즘은 빠르기에, 빠르게 압축하고 네트워크에 작은 용량으로 전달하는 것이 이득이다.
- 데이터 센터는 보통 여려 지역(region)에 분산되어 있다. 센터들 간에 데이터를 주고 받는데에는 시간이 걸린다.
Availability (가용성) #
고가용성(high availability)은 시스템이 오랜 시간 동안 지속적으로, 중단 없이 운영될 수 있는 능력을 지칭하는 용어이다.
고가용성을 표현하는 값은 퍼센트(percent)로 표현한다.
- 100%는 시스템이 단 한 번도 중단되지 않는 것을 의미한다.
- 대부분의 서비스는 99%~100% 사이의 값을 갖는다.
Service Level Agreement(SLA) 는 Service Provider(서비스 사업자)가 보편적으로 사용하는 용어로, 서비스 사업자와 고객 사이에 맺어진 합의를 의미한다.
이 합의에는 서비스 사업자가 제공하는 서비스의 가용시간(uptime)이 공식적으로 기술되어 있다.
아마존, 구글, MS 같은 사업자는 99% 이상의 SLA를 제공한다. 가용시간은 관습적으로 숫자 9를 사용해 표시한다. 9가 많으면 많을수록 좋다고 보면 된다.
아래 표는 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% | 864ms | 6.05초 | 26.30초 | 5.26분 |
| 99.9999% | 86.40ms | 604.80ms | 2.64초 | 31.56초 |
예제: QPS & 미디어 저장소 요구량 추정 #
[가정]
- Monthly active user : 3million (300,000,000)
- 50% 사용자는 매일 사용한다.
- 각 사용자는 평균 2건의 게시물을 올린다.
- Media 를 포함하는 게시물은 10% 정도다.
- 데이터는 5년 보관한다.
[추정]
- 매일 1.5명의 사용자가 사용한다.
- 매일 3억건의 게시물이 생성된다.
- 이 중 3천만 건은 미디어를 포함한 게시물이다.
1. 시간 당 게시물 생성 수
3억 / 24 = 1,250만건 건 (12,500,000)
2. 초당 게시물 생성 수 (생성에 대한 QPS)
12,500,000 / 60 / 60 = 3,472건
= 약 3,500
3. Peek QPS 추정치
2번의 QPS * 2 = 7,000
4. 저장소 요구량 추정
각 게시물당 평균 데이터의 사이즈를 다음과 같이 가정한다.
- 사용자 ID : 64 Byte
- 본문 내용 : 140 Byte
- 미디어 : 1MB
미디어 저장소 요구량
= 3억 * 10% * 1MB
= 30TB/일
5년간 미디어를 보관하기 위해 필요한 저장소 요구량
= 30TB * 365 * 5
= 약 55PB
위와 같은 방식으로 QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등을 추정해보는 연습을 해볼 수 있다.