Chapter 2. 개략적인 규모 측정

[LOG-INFO]

• 개략적인 규모 추정(back-of-the-envelope estimation) 뜻
  • back of the envelope..? 봉투 뒷면...? : 대략적으로, 대충 어림짐작으로
  • 시스템 설계 면접을 볼 때 요구사항에 따른 시스템의 필요 용량/성능 등을 물어보기도 한다
  • 2의 제곱수(bit, byte, kb, mb, gb, tb, ...), latency, 가용성 등
• disk read가 network read보다 느리군..!
  • (1MB기준 대략적인 속도) 메모리(250μs) >> 네트워크(10ms) > 디스크(30ms)
• 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라
  • 우리가 사용하는 Spring Framework도 전송 전 압축을 할까?
  • Spring Boot Configuration으로 설정 가능
    • https://www.baeldung.com/json-reduce-data-size
    • 위 문서의 예시에 따르면, gzip으로 압축할 경우 데이터 사이즈가 1/4로 줄어듦
    • https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.webserver.enable-response-compression
• 여기서는 트위터 QPS와 저장소 요구량 추정을 예시로 삼음
  • 가정
  • MAU 3억, DAU는 MAU의 50%, 각 사용자 평균적으로 하루 2건 트윗, 미디어 포함 트윗 10%, 5년 보관
  • 추정
  • QPS
    • DAU 1.5억, QPS: 1.5억 * 2트윗/일 / 24시간 / 3600초 = 약 3500
    • 최대 QPS(Peek QPS): 2 * QPS = 약 7000
    • 최대 QPS는 대충 2 곱하는가 봄
  • 저장소
    • 평균 미디어 크기 1MB(?)
    • 1.5억 2트윗/일 10% 1MB 5년 * 365일= 약 55PB
• 팁
  • 근사치 활용 - 정확한 계산은 필요없음
  • 가정은 적어두라
  • 단위를 붙이라 (Byte, KB, MB, 트윗/일, 3600초, ...)
  • 주요 출제: QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등

[minkukjo]

2의 제곱수

• ASCII 문자 하나는 1바이트!
• 10제곱은 1KB, 20제곱은 1MB, 30제곱은 1GB, 40제곱은 1TB, 50제곱은 PB ( 10제곱 외워두면 10씩 증가할 때 마다 큰 순서로 떠올리면 될 듯 )

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

• 뮤텍스 락과 주 메모리의 참조 시간은 같다고 한다! ( 락이 얼마나 오래 걸리는 작업인지 알 수 있는 부분 )
• 메모리에서 1MB를 순차적으로 읽는 시간은 250 μs (마이크로 세컨드), 디스크에서 1MB를 순차적으로 읽는 시간은 30 ms(밀리세컨드) 즉, 120배 느리다!!
• 네트워크에서 1MB를 읽는 시간이 디스크에서 1MB를 읽는 시간보다 3배 빠르다!
• 단순 압축 알고리즘 ( 10 마이크로 세컨드 )은 빠르므로 가급적이면 네트워크 전송을 할 때는 압축 후 전송하도록 하자.

QPS 추정하는 방법

• QPS는 초당 쿼리 추정치를 의미한다.
• 월간 능동 사용자가 3억이고 50%의 사용자가 매일 사용하는 경우 일간 능동 사용자는 3억의 50%인 1.5억명이다.
• 유저 한 명이 매일 2건의 트윗을 올리므로, 1.5억 x 2 트윗 / 24시간 / 3600초 = 약 3500이다.
• 최대 QPS는 2 X QPS = 7000
• 미디어 저장을 위한 요구량은 일간 능동 사용자인 1.5억 x 2 트윗 x 10% (미디어를 포함하는 트윗의 수)x 1MB = 30TB 이다.
• 데이터 보관 기간이 5년이라면 30TB x 365 x 5 = 약 55PB로 추정할 수 있다.

다른 서비스에서는 MAX QPS를 어떻게 계산할까?

• 위 트위터 예제에서는 최대 QPS 계산에 2를 곱했다.
• 그렇다면 다른 서비스들은 MAX QPS를 어떻게 계산하는지 궁금했다.

• 검색 엔진 서비스를 제공하는 알고리아의 Max QPS 공식은 다음과 같다.
• 서비스 별로 MAX QPS를 계산하는 방법은 다른 듯 하다.
• 트위터 예제는 그냥 Max QPS를 대략적으로 추산하기 위해 2배를 곱한 듯 하다.

팁

• 근사치를 활용하자 9.9998/998.42134 라면 그냥 10/1000으로 계산하자.
• 가정은 화이트보드나 메모에 잘 적어두자 까먹을 수 있으니까.
• 항상 단위를 잘 붙여두자.
• QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등을 추정하는 문제는 자주 나오니 공부해두자.
• 최대 QPS는 문제에 맞게 유연하게 가정을 두도록 하자. (알고리아의 MAX QPS 계산 예시 참고)

[MinJunKweon]

끄적끄적

• Disk seek이 네트워크 전송보다 훨씬 많은 비용이라는 걸 알게됨.. 고가용성을 위해서는 SSD는 필수인듯
• 근사치를 활용한 계산을 잘하려면 통찰력을 키워야하는듯
  • "탁구공으로 이 면접장을 다채우려면 몇개가 필요할까요?" 같은 면접질문도 있는 이유와 일맥상통하는 듯
  • 아무말이나 하는 것 같지만 나름의 논리가 있으면 프로페셔널해보임
• 단위를 붙이는 습관 중요!! 학교 시험에서 한번 단위를 안붙여서 낭패를 본적이 있었음.. 그뒤로는 어디에서든 열심히 붙이려는 중
• 최대 QPS를 계산할 때 왜 하필 2배를 곱할까요?

[2rohyun]

느낀점

---

• 직접 아키텍처를 설계해보고 개략적인 규모를 측정하여 리소스를 어떻게 할당할지 등에 대해 한 번도 고민해본 적이 없는 것 같다. ( 이런거 생각안하고 그냥 무지성 코딩만 한듯 .. )
• 이번 장은 짧았지만 매우 유용한 내용인 것 같다! 앞으로 잘 알아두면 두고 두고 활용할 수 있을 것 같음.
• 읽으면 읽을수록 흥미롭고도 유용한 좋은 책인 것 같다.
• Max QPS 가 왜 x2 인지 궁금했는데, 민국님께서 적어주신 것으로 궁금증이 해소되었다ㅎㅎ

끄적끄적

---

• 2의 제곱수
  • 1000 = 1KB
  • 1백만 = 1MB
  • 10억 = 1GB
  • 1조 = 1TB
  • 1000조 = 1PB
• 응답지연 값
  • L1 캐시 참조 = 0.5ns
  • 분기 예측 오류 = 5ns
  • L2 캐시 참조 = 7ns
  • 뮤텍스 락/언락 = 100ns
  • 주 메모리 참조 = 100ns
  • Zippy로 1 KB 압축 = 10,000ns = 10us ( 마이크로초 )
  • 1Gbps 네트워크로 2 KB 전송 = 20,000ns = 20us
  • 메모리에서 1 MB 순차적으로 read = 250,000ns = 250us
  • 같은 데이터 센터 내에서의 메시지 왕복 지연시간 = 500,000ns = 500us
  • 디스크 탐색(seek) = 10,000,000ns = 10ms
  • 네트워크에서 1 MB 순차적으로 read = 10,000,000ns = 10ms
  • 디스크에서 1 MB 순차적으로 read = 10,000,000ns = 30ms
  • 한 패킷의 캘리포니아로부터 네덜란드까지의 왕복 지연시간 = 150,000,000ns = 150ms
  • 결론!
    • 메모리는 빠르지만 디스크는 아직도 느리다.
    • 디스크 탐색은 가능한 피하라
    • 단순한 압축 알고리즘은 빠르다
    • 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라
    • 데이터 센터는 보통 여러 리전에 분산되어 있고, 센터들 간에 데이터를 주고 받는 데는 시간이 걸린다.
• 트위터 QPS와 저장소 요구랑 추정
  • 가정
    • MAU 3억 ( 300million ) 명
    • DAU 1.5억 명
    • 평균적으로 각 사용자는 매일 2건의 트윗
    • 미디어를 포함하는 트윗은 10%
    • 데이터는 5년간 보관
  • 추정
    • QPS 추정치
      • DAU = 1.5 억
      • QPS = 1.5 억 x 2 트윗 / 24 시간 / 3600초 = 약 3500
      • 최대 QPS = 2 x QPS = 약 7000
    • 미디어 저장을 위한 저장소 요구량
      • 평균 트윗 크기
        • tweet_id 64바이트
        • 텍스트 140바이트
        • 미디어 1MB
      • 미디어 저장소 요구량 = 1.5억 x 2 x 10% x 1 MB = 30TB
      • 5년간 미디어를 보관하기 위한 저장소 요구량 = 30TB x 365 x 5 = 약 55PB