[독서📖/스터디] 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2장 : 개략적인 규모 추정

 

2장 : 개략적인 규모 추정

시스템 설계 면접시, 때로는 시스템 용량이나 성능 요구사항을 개략적으로 추정해보라는 요구를 받는다.

 

** 개략적인 규모 추정(back-of-the-envlope estimation)

: 보편적으로 통용되는 성능 수치상에서 사고 실험(thought experiments)을 행하여 추정치를 계산하는 행위

👉 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것   (by. 제프 딘)

개략적 규모 추정을 효과적으로 해 내려면 규모 확장성을 표현하는데 필요한 기본기에 능숙해야 한다.
특히, 2의 제곱수나 응답지연(latency) 값, 그리고 가용성에 관계된 수치들을 기본적으로 잘 이해하고 있어야 한다.

 

2의 제곱수

분산 시스템에서 다루는 데이터 양은 엄청나게 커질 수 있으나 계산법은 기본을 크게 벗어나지 않는다.

제대로 된 계산 결과를 얻기 위해 2의 제곱수로 표현한 데이터 볼륨 단위를 알아보자.

 

* 최소 단위 : 1바이트(byte) = 8비트(bit)

* ASCII 문자 하나가 차지하는 메모리 크기 : 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년에 통상적인 컴퓨터에서 구현된 연산들의 응답지연 값이 공개되었다. (by. 제프 딘)

이 수치들은 컴퓨터 연산들의 처리 속도가 어느 정도인지 짐작할 수 있도록 해준다.

(몇몇은 더 빠른 컴퓨터의 등장으로 더 이상 유효하지 않게 되었다)

 

연산명	시간
L1 캐시 참조	0.5ns
분기 예측 오류(branch mispredict)	5ns
L2 캐시 참조	7ns
뮤텍스(mutex) 락/언락	100ns
주 메모리 참조	100ns
Zippy로 1KB 압축	10,000ns = 10μs
1 Gbps 네트워크로 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 기준 시각화 수치)

 

 

 

> 수치 분석 내용

1) 메모리는 빠르지만 디스크는 아직도 느리다

2) 디스크 탐색(seek)은 가능한 한 피하라

3) 단순한 압축 알고리즘은 빠르다

4) 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라

5) 데이터센터는 보통 여러 지역(region)에 분산되어 있고, 센터들 간에 데이터를 주고받는 데는 시간이 걸린다

 

---

가용성과 관계된 수치들

** 고가용성(high availability)

: 시스템이 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력을 지칭하는 용어

👉 퍼센트(percent, %)로 표현

100%는 시스템이 단 한 번도 중단된 적이 없었음을 의미한다.
대부분의 서비스는 99%에서 100% 사이의 값을 갖는다.

 

 

** SLA(Service Level Agreement)

: 서비스 사업자와 고객 사이에 맺어진 합의 (서비스 사업자(service provider)가 보편적으로 사용하는 용어)

👉 서비스 사업자가 제공하는 서비스의 가용시간(uptime)이 공식적으로 기술되어 있다.

아마존, 구글, 마이크로소프트 같은 사업자는 99% 이상의 SLA 를 제공한다.

 

 

** 9의 개수와 시스템 장애시간(downtime) 사이의 관계

: 가용시간은 관습적으로 숫자 9를 사용해 표시한다

👉 9가 많을수록 좋다.

 

가용률	하루당 장애시간	주당 장애시간	개월당 장애시간	연간 장애시간
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초

 

---

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

> 가정

* 월간 능동 사용자(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 1MB = 30TB/일
* 5년간 미디어를 보관하기 위한 저장소 요구량 : 30TB X 365 X 5 = 약 55PB

 

 

---

 

팁

개략적인 규모 추정과 관계된 면접에서 가장 중요한 것은 문제를 풀어나가는 절차

- 올바른 절차를 밟느냐   >   결과를 내는 것

- 면접자는 지원자의 문제 해결 능력을 보고 싶어 한다.

 

* 근사치를 활용한 계산 (rounding and approximation)

면접장에서 복잡한 계산을 하는 것은 어려운 일이다. 적절한 근사치를 활용해 시간을 절약하자.
EX : "99987 / 9.1" 👉 "100,000 / 10"

 

* 가정(assumption)들은 적어 두라

나중에 살펴볼 수 있도록

 

* 단위(unit)를 붙이라

단위를 붙이는 습관을 두면 모호함을 방지할 수 있다.
5라고만 적으면 5KB 인지 5MB 인지 알 수가 없다.

 

* 많이 출제되는 개략적 규모 추정 문제

: QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등을 추정하는 것

미리미리 연습해놔라.

 

 

---

** 도서 링크 **

https://product.kyobobook.co.kr/detail/S000001033116

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬 - 교보문고