FeGwan-Training / FeGwan

0 stars 0 forks source link

가상 면접 사례로 배우는 대규모 시스템 설계 기초 2장 개략적인 규모 추정 #64

Closed MyeoungDev closed 10 months ago

MyeoungDev commented 10 months ago

Discussed in https://github.com/FeGwan-Training/FeGwan/discussions/63

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, 저장소 요구량, 캐시 요구량, 서버 수 추정 정도 가장 많이 나옴**. 확실히 연습할 것