Originally posted by **MyeoungDev** January 5, 2024
# 2장 개략적인 규모 추정
시스템 설계 면접을 볼 때, 시스템 용량이나 성능 요구사항을 개략적으로 추정해보라는 요구도 받게 된다고 한다. (무섭네…)
> 구글의 시니어 펠로(Senior Fellow) 제프 딘(Jeff Dean) 왈
”개략적인 규모 추정(back-of-the-envelope estimation)은 보편적으로 통용되는 성능 수치상에서 사고 실험(thought experiments)을 행하여 추정치를 계산하는 행위로서, 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것”
>
개략적 규모 추정을 효과적으로 하려면 규모 확장성을 표현하는 기본기인 **2의 제곱수**, **응답지연(latency) 값**, **가용성에 관련된 수치**들을 잘 이해하고 있어야 한다.
# 2의 제곱수
분산 시스템에서 다루는 양은 엄청나게 커질 수 있다.
제대로 다루려면 **데이터 볼륨의 단위를 2의 제곱수로 표현**하면 어떻게 되는지를 알아야 한다.
**최소 단위 1바이트, 8비트 구성. ASCII 문자 == 1바이트**
![image](https://github.com/FeGwan-Training/FeGwan/assets/73057935/836d8563-dc5c-4659-bfca-786a1d322ed2)
# 모든 프로그래머가 알아야 하는 응답지연 값
아까 위에서 말한 제프 딘 선생님이 **2010년에 통상적인 응답지연 값**을 공개했다.
이 중 몇개는 컴퓨터의 성능 향상으로 의미가 없는것도 있다고 하지만, 아직 해당 수치들은 **컴퓨터 연산들의 처리 속도를 대충 짐작**할 수 있도록 해준다.
![image](https://github.com/FeGwan-Training/FeGwan/assets/73057935/e41b54b2-0607-4d4c-9f57-b16a4684aa06)
아래의 그림은 위의 표를 도구를 사용하여 2020년 기준으로 시각화 한 것이라고 한다.
(근데 이걸 봐도 잘 모르겠음…)
![image](https://github.com/FeGwan-Training/FeGwan/assets/73057935/0fc96cbc-cafe-4eb4-9ecf-a2bfce03e833)
## 분석 결과
- 메모리는 빠르지만 디스크는 아직도 느리다.
- 디스크 탐색(seek)은 가능한 한 피하라. → (하드 디스크 메모리 내에서 특정 파일 위치 등을 찾는 행위)
- 단순한 압축 알고리즘은 빠르다.
- 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라.
- 데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고받는 데는 시간이 걸린다. → (AWS S3의 경우에도 이런걸로 알고 있음)
# 가용성에 관계된 수치들
**고가용성(High Availability)**은 **시스템이 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력**을 지칭하는 용어다.
고가용성은 %로 표현하며, 100%는 단 한 번도 중단된 적이 없음을 뜻한다.
대부분의 서비스는 99%에서 100%사이의 값을 갖는다고 한다.
보편적으로 SLA(Service Level Agreement) 라는 합의된 단어를 사용해서 표현한다.
아마존, 구글, MS 같은 사업자는 99% 이상의 SLA를 제공한다.
관습적으로 숫자 9를 이용해 표현하고, 9가 많으면 많을수록 안정적인 서비스를 잘 제공한다는 것을 뜻한다.
![image](https://github.com/FeGwan-Training/FeGwan/assets/73057935/09fcb9de-5eb0-47da-b7bf-2c5677b6a2c1)
# ⚠️ 중요! ⚠️ 예제: 트위터 QPS와 저장소 요구량 추정
개인적으로 해당 챕터에서 가장 중요한 내용을 말한다고 생각한다.
그래서 중요라고 혼자 달아봤다.
참고: 해당 예제는 트위터랑 전혀 상관이 없고, 그냥 가정일 뿐.
## 가정
- 월간 능동 사용자(Monthly Active User)는 3억(300million) 명이다.
- 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) = 2 x QPS = 약 7000
### 저장소 요구량
- 평균 트윗 크기 아래와 같이 추정
- tweet_id == 64바이트
- 텍스트 == 140바이트
- 미디어 == 1MB
- 미디어 저장소 요구량: 1.5억 x 2 x 10% x 1MB = 30TB / 일
- 5년간 미디어를 보관하기 위한 저장소 요구량: 30TB x 365. 5 = 약 55PB(Petabyte, 10^15)
# 팁
개략적인 규모 추정과 관련된 면접의 팁중 가장 핵심은 **결과보다는 올바른 절차를 밟느냐 이다.**
면접관들이 우리에게 궁금한건 우리가 **올바른 문제 해결 능력**이다.
- 근사치를 활용한 계산
- 질문: 99987 / 9.1 몇이에요?
- 답변: 해당 내용은 100,000 / 10 으로 간소화 할 수 있습니다!
- 가정들은 명확하게 기록할 것
- 단위는 항상 붙이자.
- tweet_id == 64 ⇒ 이건 64 바이트 인지 KB인지 MB인지 쓴사람도 다시 보면 햇갈림-
- **QPS, Peek QPS, 저장소 요구량, 캐시 요구량, 서버 수 추정 정도 가장 많이 나옴**. 확실히 연습할 것
Discussed in https://github.com/FeGwan-Training/FeGwan/discussions/63