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

알렉스 쉬 님의 "가상 면접 사례로 배우는 대규모 시스템 설계 기초" 책을 정리한 포스팅 입니다.

 

0. 개략적인 규모 추정

• 설계가 요구사항에 대략적으로 부합하는지 판단
• 시스템 설계자는 추정 능력 및 단위 감각이 필수

 

1. 2의 제곱수

축약형	지수 (2^x)	설명
1KB	2¹⁰	1,024 바이트
1MB	2²⁰	1,024KB = 약 10⁶ 바이트 (100만)
1GB	2³⁰	1,024MB = 약 10⁹ 바이트 (10억)
1TB	2⁴⁰	1,024GB = 약 10¹² 바이트 (1조)
1PB	2⁵⁰	1,024TB = 약 10¹⁵ 바이트 (1000조)

• 1바이트: 일반적으로 ASCII 문자 하나를 저장할 수 있음

 

2. 응답지연 값

연산 항목	설명	응답 지연 시간
L1 캐시 참조	CPU에 매우 가까운 저장소	0.5ns
분기 예측 오류 (Branch Mispredict)	CPU의 예측 실패로 인한 페널티	5ns
L2 캐시 참조	L1보다 느리지만 여전히 빠름	7ns
뮤텍스 잠금/해제 (mutex lock/unlock)	경량 동기화 연산	100ns
메모리 참조 (RAM access)	DRAM 액세스	100ns
Zippy 알고리즘으로 1KB 압축	매우 빠른 압축 알고리즘	10,000ns = 10μs
1Gbps 네트워크로 2KB 전송	네트워크 속도 기반 전송 지연	20,000ns = 20μs
메모리에서 1MB 순차 읽기	RAM에서 대량 데이터 읽기	250,000ns = 250μs
같은 데이터 센터 내 메시지 왕복 지연	내부 네트워크 통신	500,000ns = 500μs
디스크 탐색 (HDD seek)	물리적 위치 탐색 지연	10,000,000ns = 10ms
네트워크에서 1MB 순차 읽기	외부 네트워크 대역폭 한계	10,000,000ns = 10ms
디스크에서 1MB 순차 읽기	디스크 I/O 속도	30,000,000ns = 30ms
미국(CA) ↔ 네덜란드 간 왕복 지연	물리적 거리 기반 지연	150,000,000ns = 150ms

 

결론

결론	설명
💡 메모리는 빠르지만 디스크는 느리다	RAM과 캐시는 ns~μs 단위지만 디스크는 ms 단위
💡 디스크 탐색은 가능한 한 피하라	HDD는 특히 '랜덤 읽기' 시 매우 느림
💡 간단한 압축은 빠르고 효율적이다	Zippy 등 빠른 압축으로 IO/전송 시간 절감 가능
💡 전송 전에 압축하라	네트워크보다 CPU가 훨씬 빠르므로 전송 데이터량 줄이는 게 유리
💡 데이터 센터 간 전송은 고지연이다	지리적으로 멀면 왕복 통신에 수백 ms 소요됨

 

3. 가용성 관련 수치

고가용성(High Availability, HA)

• 시스템이 오랜 시간 동안 멈추지 않고 운영될 수 있는 능력
• 표현 방식: 퍼센트(%)로 표현
• 100%: 1년 365일 내내 단 1초도 멈춘 적 없음을 의미
• 하지만 현실적으론 대부분 99% ~ 99.9999% 수준의 가용성을 목표로 함

 

SLA(Service Level Agreement)

• 서비스 제공자와 고객 간 계약서
• 가용 시간(uptime)을 몇 % 이상으로 보장한다

 

 

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

가정

항목	값
월간 사용자(MAU)	3억 (300 million)
하루 사용 비율 (DAU 비율)	50%
1인당 트윗 수	하루 평균 2건
미디어 포함 트윗 비율	10%
데이터 보존 기간	5년

 

추정: QPS

항목	수치 / 설명
일간 능동 사용자 (DAU)	300M × 50% = 1억 5천만 명 (150M)
일간 전체 트윗 수	150M × 2 = 3억 건
평균 QPS	300,000,000 / 86,400 ≈ 3,472 ≈ 3,500
최대 QPS (피크 시간)	평균 QPS × 2 = 약 7,000 QPS (일반적으로 2배 이상으로 추정)

 

 

추정: 저장소

• 트윗 ID: 64 바이트

항목	수치/설명
텍스트	140 Byte
일간 텍스트 트윗 수	3억 × 90% = 2.7억 건
일간 텍스트 트윗 데이터양	2.7억 × (140B + 64B) = 약 55GB

 

항목	수치/설명
미디어	1MB
미디어 포함 비율	10%
일간 미디어 트윗 수	3억 × 10% = 3천만 건 (30M)
일간 미디어 트윗 데이터양	30M × (1MB + 64B) = 약 30TB

 

항목	값
일간 텍스트 트윗 저장량	약 55GB
일간 미디어 트윗 저장량	약 30TB
기간	5년 (365일 × 5 = 1,825일)
5년 누적 데이터량	1,825 * (30TB + 55GB) = 약 54.85PB