Architecture(1) - 개략적 규모 추정
in DEV on Architecture System-design Scalability Latency Capacity-planning Back-of-the-envelope Qps High-availability 대규모시스템설계 규모추정 응답지연 고가용성 트래픽예측 용량산정 아키텍처
- 대규모 시스템 설계 시 ‘대략적인 숫자 감각’이 필요한 이유
- 개략적 규모 추정(Back-of-the-envelope)
- 1. 2의 제곱수와 데이터 볼륨 단위
- 2. 응답 지연
- 3. 가용성과 관련한 수치들
- 4. 예시: SNS 데이터 기반 QPS와 저장소 요구량 추정
- 5. 마무리
- 참고 사이트 & 함께 보면 좋은 사이트
대규모 시스템 설계 시 ‘대략적인 숫자 감각’이 필요한 이유
수백만, 수천만 명의 트래픽을 감당하는 대규모 시스템을 설계할 때 우리는 종종 ‘서버는 몇 대나 필요할까?’, ‘DB 용량은 얼마나 잡아야 할까?’ 라는 질문에 직면한다.
이 때 복잡한 성능 테스트나 코딩에 앞서 요구사항을 빠르고 합리적으로 예측하는 과정이 필수적인데, 이를 개략적 규모 추정이라고 부른다.
여기서는 반드시 숙지해야 할 데이터 볼륨 단위, 응답 지연 시간, 고가용성 지표, 그리고 SNS 데이터를 바탕으로 한 QPS(초당 트래픽) 산정 방법에 대해 알아본다.
개략적 규모 추정(Back-of-the-envelope)
개략적 규모 추정이란, 시스템 설계 시 보편적으로 통용되는 성능 수치와 수학적 계산을 바탕으로 시스템의 용량이나 성능 요구사항을 대략적으로 예측하는 과정을 말한다.
어떤 설계가 요구사항에 부합하는지, 혹은 병목 현상을 유발할지 판단하는 나침반 역할을 한다.
1. 2의 제곱수와 데이터 볼륨 단위
컴퓨터의 최소 단위는 1byte이며, 이는 8bit로 구성된다.
우리가 흔히 아는 ASCII 문자 하나가 차지하는 메모리 크기가 바로 1byte이다.
시스템 용량을 계산하려면 데이터 볼륨 단위를 직관적으로 파악하고 있어야 한다.
데이터 볼륨 단위 표
| 2의 x 제곱 | 근사치 | 이름 | 축약형 |
|---|---|---|---|
| 10 | 1천(thousand) | 1킬로바이트(Kilobyte) | 1KB |
| 20 | 1백만(million) | 1메가바이트(Megabyte) | 1MB |
| 30 | 10억(billion) | 1기가바이트(Gigabyte) | 1GB |
| 40 | 1조(trillion) | 1테라바이트(Terabyte) | 1TB |
| 50 | 1000조(quadrillion) | 1페타바이트(Petabyte) | 1PB |
2. 응답 지연
컴퓨터 내부 및 네트워크에서 데이터가 이동할 때 걸리는 시간을 이해하는 것은 아키텍처 설계의 기본이다.
2020년 기준 프로그래머가 알아야 할 지연 시간 (Latency Numbers)
| 연산명 | 시간 |
|---|---|
| L1 캐시 참조 (L1 cache reference) | 1ns |
| 분기 예측 오류 (branch mispredict) | 3ns |
| L2 캐시 참조 (L2 cache reference) | 4ns |
| 뮤텍스(mutex) 락/언락 | 17ns |
| 일반 네트워크(commodity network)로 2,000 바이트 전송 | 44ns |
| 주 메모리 참조 (Main memory reference) | 100ns |
| Zippy로 1 KB 압축 | 2,000ns = 2µs |
| 메모리에서 1,000,000 바이트(1 MB) 순차적으로 read | 3,000ns = 3µs |
| SSD 임의(random) read | 16,000ns = 16µs |
| SSD에서 1,000,000 바이트(1 MB) 순차적으로 read | 49,000ns = 49µs |
| 같은 데이터 센터 내에서의 왕복 지연시간 (Round trip) | 500,000ns = 500µs |
| 디스크에서 1,000,000 바이트(1 MB) 순차적으로 read | 825,000ns = 825µs |
| 디스크 탐색(seek) | 2,000,000ns = 2ms |
| 한 패킷의 CA(캘리포니아)로부터 네덜란드까지의 왕복 지연시간 | 150,000,000ns = 150ms |
시간 단위 참고:
- ns = nanosecond (나노초), µs = microsecond (마이크로초), ms = millisecond (밀리초)
- 1나노초 = \(10^{-9}\)초
- 1마이크로초 = \(10^{-6}\)초 = 1,000나노초
- 1밀리초 = \(10^{-3}\)초 = 1,000µs = 1,000,000ns
위의 수치들을 보면 아래와 같은 결론이 나온다.
- 메모리는 빠르지만 디스크는 아직 느리다.
- 병목의 주범인 디스크 탐색(seek) 연산은 가능한 한 피해야 한다.
- 단순 압축 알고리즘 연산 속도는 매우 빠르다.
- 따라서 데이터를 네트워크로 전송하기 전에 가능하면 압축하라
- 데이터 센터는 보통 여러 region에 분산되어 있으며, 글로벌 센터 간 데이터를 주고받는 데는 시간이 소요된다.
💡2025~2026년 하드웨어 발전에 따른 지연 시간 변화
제프 딘의 지연 시간 표가 발표된 이후 하드웨어는 더 발전했다.
2026년 현재 대규모 시스템 설계 시 고려해야 할 최신 트렌드는 아래와 같다.
- 네트워크가 디스크를 이겼다.
- 100GbE(초당 100GB 전송) 이상의 초고속 데이터센터 네트워크 환경에서는 네트워크를 통해 다른 서버의 메모리(RAM) 데이터를 읽어오는 것(약 1.5µs~2µs)이, 로컬 디스크(HDD, SSD)에서 데이터를 읽는 것(2ms, 15µs)보다 훨씬 빠르다.
- 이로 인해 저장소와 컴퓨팅을 분리하는 ‘컴퓨트-스토리지 분리 아키텍처’가 대세가 되었다.
- 기존엔 서버 한 대에 CPU/RAM/디스크가 세트로 묶여 있었기 때문에 데이터가 너무 많아서 용량이 부족해지면 디스크만 사서 꽂는게 아니라 CPU, RAM이 포함된 비싼 서버 자체를 통째로 증성해야 하므로 비용 낭비가 있었다.
- 컴퓨트-스토리지 분리 아키텍쳐에서는
- 컴퓨트 클러스터: 계산과 로직 연산만 전담하는 서버들의 집합(CPU, RAM)
- 스토리지 클러스터: 데이터 저장만 전담하는 저장소 서버들의 집합(AWS S3 등)
- 로컬 HDD에서 데이터를 읽어오는 속도: 약 825µs ~ 2,000µs
- 초고속 네트워크를 통해 멀리 떨어진 스토리지 서버의 메모리/SSD에서 데이터를 읽어오는 속도: 약 1.5µs ~ 2µs
- NVMe SSD의 혁명
- 기존 HDD의 디스크 탐색이 2~10ms가 걸렸다면, 최신 NVMe SSD의 Random Read는 약 15µs 내외로 과거 대비 거의 1,000배 가량 빨라졌다.
- 메모리와 저장 장치 사이의 속도 격차가 급격히 줄었다.
3. 가용성과 관련한 수치들
가용성은 시스템이 중단 없이 정상적으로 운영되는 시간을 뜻하며, 관습적으로 숫자 ‘9’를 사용하여 표시한다.(예: 99.9%는 ‘Three nine’)
9의 개수가 많을수록 뛰어난 안정성을 의미하지만, 그만큼 인프라 비용이 발생한다.
9의 개수와 시스템 장애 시간(downtime) 사이의 관계
| 가용률(SLA) | 하루당 장애시간 | 주당 장애시간 | 개월당 장애시간 | 연간 장애시간 |
|---|---|---|---|---|
| 99% | 14.40분 | 1.68시간 | 7.31시간 | 3.65일 |
| 99.9% | 1.44분 | 10.08분 | 43.83분 | 8.77시간 |
| 99.99% | 8.64초 | 1.01분 | 4.38분 | 52.60분 |
| 99.999% | 864.00밀리초 | 6.05초 | 26.30초 | 5.26분 |
| 99.9999% | 86.40밀리초 | 604.80밀리초 | 2.63초 | 31.56초 |
4. 예시: SNS 데이터 기반 QPS와 저장소 요구량 추정
[가정 사항]
- 월간 능동 사용자(MAU)는 3억명
- 사용자의 50%는 매일 SNS를 사용함
- 평균적으로 각 사용자는 매일 2건의 포스트를 작성함
- 포스트 중 미디어(사진/영상)를 포함하는 포스트는 10%
- 데이터는 5년간 보관함
단계 1: QPS 추정치 산출
- 일간 능동 사용자(DAU)
- 3억 명 * 50% = 1.5억명
- 평균 QPS
- 1.5억명 * 2포스트 / 24시간 / 60분 / 60초 = 약 3,500 QPS
- 최대 QPS(Peak QPS)
- 2 * 평균 QPS = 약 7,000 QPS
- 보통 평균 QPS의 2배를 안전한 시스템 마지노선으로 계산하는 것이 업계 룰
- 2 * 평균 QPS = 약 7,000 QPS
단계 2: 미디어 저장을 위한 저장소 요구량 산출
- 1건당 평균 포스트 크기 산정
- post_id: 64 byte
- 텍스트: 140byte
- 초창기 SNS 포스트의 상징적 글자 수 제한인 140자에서 유래한 수치임
- ASCII 기준 1글자 = 1byte 이므로 140byte
- 미디어: 1MB
- 사진 및 짧은 영상 썸네일의 ‘압축된 평균 크기’를 계산하기 쉽도록 1MB로 일반화
- 하루 미디어 저장소 요구량
- 1.5억명 * 2포스트 * 10% * 1MB = 30TB/일
- 5년간 미디어 보관 요구량
- 30TB * 365일 * 5년 = 약 55PB
5. 마무리
개략적 규모 추정은 완벽히 정확한 숫자를 맞추는 것이 목적이 아니다.
주어진 요구사항 속에서 QPS, 최대 QPS, DB 저장소 요구량, 캐시 요구량, 필요한 웹 서버 수 등을 논리적으로 도출하고, 그 과정에서 타당한 근거를 제시하는 능력을 기르는 과정이다.
참고 사이트 & 함께 보면 좋은 사이트
본 포스트는 알렉스 쉬 저자의 가상 면접 사례로 배우는 대규모 시스템 설계 기초를 기반으로 스터디하며 정리한 내용들입니다.
- 가상 면접 사례로 배우는 대규모 시스템 설계 기초
- 책에 나온 링크들 모음
- Google Pro Tip: Use Back-of-the-envelope-calculations
- Latency Numbers Every Programmer Should Know (Colin Scott)
