개략적인 규모 추정 :: 숫자에 대한 감 잡기

개략적인 규모 추정

구글 엔지니어 Jeff Dean에 따르면 개략적인 규모 추정이란 보편적으로 통용되는 성능 수치상에서 사고 실험을 행하여 추정치를 계산하는 행위로서, 어떤 설계가 요구사항에 부합할 것인지 확인해보는 과정을 이야기합니다.

2의 제곱수

분산 시스템에서 사용하는 데이터의 양은 크게 커질 수 있으나, 데이터 볼륨의 단위를 2의 제곱수로 어떻게 표현하는지 알아야 합니다.
위와 같은 제곱수에 대한 어느정도의 감을 머릿속에 집어넣어두는 것은 꽤 중요합니다.
예를 들어, 이전 포스팅에서 GFS에서 가정한 Individual STREAMING READ operation size는 대략 수백 KB ~ 1MB라고 했습니다.
"넉넉 잡아 1MB라고 생각하고 2^20정도이구나" 정도의 숫자에 대한 감을 기억해두면 개력적인 규모 추정을 할 때 비교적 단순하게 접근할 수 있습니다.

• 최소 단위 = 1 Byte = 8 Bit
• ASCII 문자 1개 = 1 Byte
• 1KB = 1024 Byte = 2^10 Byte
• 1MB = 2^20 Byte
• 1GB = 2^30 Byte
• 1TB = 2^40 Byte
• 1PB = 2^50 Byte

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

아래의 지연시간에 대한 정보도 대략적으로 알고 있으면 좋다고 합니다.

연산명	시간
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

• ns = nanosecond (나노초), μs = microsecond (마이크로초), ms = millisecond (밀리초)
• 1나노초 = 10^-9초
• 1마이크로초 = 10^-6초
• 1밀리초 = 10^-3초

개인적으로 위의 표에서 가장 와닿은 부분은 네트워크에서의 READ가 디스크에서의 READ보다 3배나 더 빠르다는 점입니다.
개인적으로 위 표의 내용을 아래처럼 기억하려고 합니다. HDD 기준이고 상황에 따라서 많이 달라지겠지만, 대략적인 숫자의 감을 기억하는데는 좋은 것 같습니다.

• DISK I/O (30ms) = Header Seek(10ms) + Rotational Latency(10ms) + Data Transfer(10ms)
• NETWORK I/O (10ms) = Data Transfer(10ms)

책에서 제시해주는 기억해야할 2가지 포인트가 더 있습니다.

• 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라
  • 압축하는데 소요되는 시간이 전송에 걸리는 시간보다 압도적으로 빠르다.
• 데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고받는 데는 시간이 많이 걸린다.
  • 물리적인 거리에서 오는 속도 지연을 최대한 줄이자

What is QPS

QPS는 Query Per Second를 의미합니다. 하루 1억건의 요청이 들어온다면, 단순 계산했을 때 1초당 약 1,157건의 요청이 들어옵니다.

• 하루 1억건 = 초당 약 1천건 = Query Per Second 1000 = QPS 1000

단일 노드의 시스템에서 얼마나 큰 QPS를 감당할 수 있는지는 상황에 따라서 매우 다릅니다.
QPS도 성격에 따라서 Read 중심, Write 중심, Read & Write 혼합 등으로 구분해서 생각해볼 수 있습니다.

• Read 중심인 경우에는 Relica를 고려해야하며
• Write 중심인 경우 단일 DB의 한계인지 검토해야합니다.
• 10,000 QPS 처럼 매우 큰 경우는 반드시 분산해서 처리해야 합니다.

RocksDB

QPS에 대한 하나의 예시를 공유합니다.

 

RocksDB는 google에서 만든 leveldb 코드와 Hbase의 아이디어를 참고해서 facebook에서 만든 key value storage입니다.
RocksDB In Memory Workload Performance Benchmarks에 따르면 QPS를 point lookups, prefix range scans 인 경우를 구분해서 명시하고 있습니다.

• 4.5M - 7M read QPS for point lookups with sustained writes. 4M - 6M QPS prefix range scans with sustained writes.
• point lookups = 정확히 한 키 조회 = Get("user:1234")
• prefix range scans = 범위 조회 = Get("user:12*")