[대규모 시스템 설계 기초] 2장. 개략적인 규모 추정

🌱 들어가기 전

이번 포스팅에서는 개략적으로 규모를 추정하는 내용에 대해 알아보자.

---

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

개략적 규모 추정을 효과적으로 해 내려면 규모 확장성을 표현하는 데 필요한 기본기에 능숙해야 한다.

- 2의 제곱수

- 응답지연 값(latency)

- 가용성에 관계된 수치들

 

🌱 2의 제곱수

데이터 최소 단위는 1바이트, 8bit로 구성된다. ASCII 문자 하나가 차지하는 메모리 크기가 1바이트이다.

 

데이터 볼륨 단위를 2의 제곱수로 표현하면 어떻게되는지 알아야 한다.

2의 x 제곱	근사치	이름	축약형
10	1천	1킬로바이트	1KB
20	1백만	1메가바이트	1MB
30	10억	1기가바이트	1GB
40	1조	1테라바이트	1TB
50	1000조	1페타바이트	1PB

 

🌱 모든 프로그래머가 알아야 하는 응답지연 값

통상적인 컴퓨터에서 구현된 연산들의 응답지연 값

 

더 빠른 컴퓨터 등장으로 몇몇은 더 이상 유효하지 않지만, 아직 이 수치들은 컴퓨터 연산들의 처리 속도가 어느 정도인지 짐작할 수 있게 도와준다.

연산명	시간
L1 캐시 참조	0.5ns
분기 예측 오류	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

 

이 수치를 분석하면 다음 결론이 나온다.

- 메모리는 빠르지만 디스크는 아직 느리다

- 디스크 탐색은 가능한 한 피하라

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

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

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

🤔 데이터를 인터넷으로 전송하기 전 압축하는게 좋은 구체적인 상황은 어떤 것이 있을까?💡이미지를 전송하는 상황을 가정해보자.이미지 저장에 "client -> server -> image server" 의 순서로 통신하면, 총 두 번의 통신에 용량이 큰 이미지가 들어간다. 따라서, 이미지를 압축하여 전송하는 것이 좋다.또한 용량이 큰 이미지는 "client -> image server" 의 순서처럼 이미지 서버로 바로 전송하는 것이 더 효율적일 것이다.

 

🌱 가용성에 관계된 수치들

고가용성: 시스템이 오랜 시간동안 지속적으로 중단 없이 운영될 수 있는 능력 (퍼센트로 표현)

100%: 시스템이 단 한 번도 중단된 적이 없었음을 의미한다.

대부분의 서비스는 99%에서 100% 사이의 값을 갖는다.

 

가용률은 관습적으로 숫자 9를 사용해 표시한다. 9가 많을수록 좋다고 보면 된다.

 

가용률	하루당 장애시간	주당 장애시간	개월당 장애시간	연간 장애시간
99%	14.40분	1.68시간	7.32시간	3.65일
99.9%	1.44분	10.08분	43.83분	8.77시간
99.99%	8.64초	1.01분	4.38분	52.60분

 

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

💭 가정

- 월간 능동 사용자는 3억명이다.

- 50%의 사용자가 트위터를 매일 사용한다.
- 평균적으로 각 사용자는 매일 2건의 트윗을 올린다
- 미디어를 포함하는 트윗은 10% 정도다.
- 데이터는 5년간 보관된다.

💭 추정

<QPS(Query Per Second) 추정치>
-일간 능동 사용자(Daily Active User, DAU) = 3억 X 50%=1.5억
- QPS=1.5억 x 2 트윗/ 24시간/3600초 = 약 3500
- 최대 QPS(Peek QPS) = 2x QPS=약 7000

 

🤔 최대 QPS를 구할 때, 왜 QPS에 2를 곱할까?

💡 하루 중 특정 시간대에 트래픽이 집중될 수 있으므로, 이 피크 시간대에 대비하여 최대 QPS를 계산하는데, 이를 위해 일반적으로 평균 QPS의 2배를 사용한다. 

<미디어 저장을 위한 저장소 요구량>

- 평균 트윗 크기

tweet_id: 64바이트

텍스트: 140바이트

미디어: 1MB

 

- 미디어 저장소 요구량: 1.5억 X 2X 10% X 1 MB=30TB/ 일

- 5년간 미디어를 보관하기 위한 저장소 요구량: 30TB X 365× 5=약 55PB

 

🌱 팁

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

올바른 절차를 밟는 것이 결과를 내는 것보다 중요하다.

면접자가 보고싶어 하는 것은 문제 해결 능력!

 

- 근사치를 활용한 계산

복잡한 계산을 하는 것은 어렵고, 시간낭비다. 계산 결과 정확함을 평가하는 것이 아니기에 적절한 근사치를 활용해 시간을 절약하자.

 

- 가정은 적어두라

나중에 살펴볼 수 있도록

 

- 단위를 붙이라

모호함 방지

 

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

QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등