대규모 시스템 설계 스터디 02. 개략적인 규모 추정

대규모 시스템을 설계할 때는 정확한 숫자를 처음부터 알 수 없는 경우가 많습니다. 그래도 “대략 초당 몇 건을 처리해야 하는지”, “저장소가 TB 단위인지 PB 단위인지”, “장애 허용 시간이 몇 분인지”는 빠르게 가늠해야 합니다.

2장은 이 숫자 감각을 다룹니다. 계산기 없이도 큰 규모를 추정하는 방법, 단위를 빠르게 바꾸는 방법, 지연 시간과 가용성을 읽는 방법을 정리합니다.

개략적인 규모 추정은 정답을 맞히는 계산 문제가 아닙니다. 틀리지 않는 방향으로 가정하고, 단위를 붙이고, 설계에 필요한 크기를 빠르게 확인하는 과정입니다.

먼저 알아야 할 기본 용어

용어	뜻
개략적 추정	정확한 값이 아니라 대략적인 규모를 계산하는 방법입니다. 영어로 Back-of-the-Envelope Estimation이라고 합니다.
규모의 차수	10배, 100배, 1,000배처럼 숫자의 자리 자체가 달라지는 크기 차이입니다.
MAU	Monthly Active Users의 약자입니다. 한 달 동안 서비스를 사용한 활성 사용자 수입니다.
DAU	Daily Active Users의 약자입니다. 하루 동안 서비스를 사용한 활성 사용자 수입니다.
QPS	Queries Per Second의 약자입니다. 초당 처리해야 하는 요청 수입니다.
Peak QPS	가장 바쁜 시간대의 초당 요청 수입니다. 평균 QPS보다 보통 더 큽니다.
저장소 용량	데이터를 저장하는 데 필요한 공간입니다. KB, MB, GB, TB, PB 같은 단위를 씁니다.
지연 시간	요청을 보낸 뒤 응답이 돌아오기까지 걸리는 시간입니다. latency라고도 부릅니다.
가용성	서비스가 정상적으로 동작하는 시간의 비율입니다. 99.9% 같은 숫자로 표현합니다.
SLA	Service Level Agreement의 약자입니다. 서비스 제공자가 약속하는 성능이나 가용성 기준입니다.

숫자 감각은 설계 범위를 좁혀 줍니다

같은 “게시글 서비스”라도 규모에 따라 설계가 달라집니다.

하루 게시글이 1만 건이면 단일 데이터베이스와 캐시만으로도 충분할 수 있습니다. 하루 게시글이 3억 건이고 이미지가 함께 올라온다면 저장소, CDN, 비동기 처리, 데이터 분산을 처음부터 검토해야 합니다.

그래서 규모 추정은 설계 전에 하는 범위 확인입니다. 이 시스템이 작은 서비스인지, 중간 규모 서비스인지, 이미 분산 시스템을 전제로 해야 하는 서비스인지 판단하는 데 사용합니다.

핵심은 세 가지입니다.

확인할 것	왜 필요한가
QPS	서버, 로드밸런서, 캐시가 처리해야 할 요청량을 가늠합니다.
저장소	데이터베이스, 객체 저장소, 백업 전략의 규모를 가늠합니다.
가용성	장애 대응, 이중화, 복구 목표를 어느 수준으로 잡을지 정합니다.

데이터 단위는 1,000배씩 커진다고 보면 됩니다

데이터 용량을 계산할 때는 먼저 단위 감각이 필요합니다.

단위	대략적인 크기
1KB	약 1,000 bytes
1MB	약 1,000KB
1GB	약 1,000MB
1TB	약 1,000GB
1PB	약 1,000TB

컴퓨터 내부에서는 1KB를 1,024 bytes로 계산하는 경우도 많습니다. 하지만 개략적 추정에서는 1,000 단위로 계산해도 충분합니다. 목적은 정밀한 회계 계산이 아니라 설계 규모를 빠르게 판단하는 것이기 때문입니다.

실전 감각은 예시로 잡아두면 편합니다.

데이터	대략적인 크기
짧은 텍스트 1개	수백 bytes
프로필 이미지 1장	수백 KB
일반 사진 1장	300KB ~ 1MB 이상
HD 영상 1분	수십 MB 이상

텍스트 서비스와 이미지 서비스의 저장소 규모가 크게 달라지는 이유가 여기 있습니다. 텍스트는 작고, 이미지와 영상은 큽니다.

지연 시간은 느린 작업을 피하게 해 줍니다

지연 시간 기준값은 “무엇이 빠르고 무엇이 느린지”를 알려 줍니다.

작업	대략적인 지연
CPU 캐시 접근	ns 단위
메모리 접근	약 100ns
SSD 임의 읽기	수백 microseconds
HDD 탐색	ms 단위
같은 데이터센터 네트워크 왕복	1ms 안팎
대륙 간 네트워크 왕복	100ms 이상

여기서 ns는 나노초, ms는 밀리초입니다. 1초는 1,000ms이고, 1ms는 1,000,000ns입니다.

이 숫자를 외울 필요는 없습니다. 대신 방향을 이해하면 됩니다.

메모리는 빠릅니다. 디스크는 상대적으로 느립니다. 같은 데이터센터 안의 네트워크는 빠르지만, 대륙을 건너는 네트워크는 사용자에게 체감될 정도로 느립니다.

그래서 대규모 시스템에서는 자주 읽는 데이터를 캐시에 올리고, 이미지는 CDN으로 사용자 가까이에 두고, 데이터베이스 디스크 접근을 줄이려 합니다.

가용성은 장애 허용 시간을 숫자로 바꿉니다

가용성은 서비스가 살아 있는 시간의 비율입니다. 99%와 99.999%는 비슷해 보이지만 운영 의미는 완전히 다릅니다.

가용성	부르는 방식	1년 동안 허용되는 장애 시간
99%	two nines	약 3.65일
99.9%	three nines	약 8.77시간
99.99%	four nines	약 52.6분
99.999%	five nines	약 5.26분

99.9%는 1년에 약 9시간까지 장애가 날 수 있다는 뜻입니다. 99.999%는 1년에 약 5분만 허용된다는 뜻입니다. 소수점 한 자리 차이처럼 보이지만 복구 체계, 이중화 비용, 운영 난이도는 크게 달라집니다.

따라서 “가용성을 높이겠습니다”라고만 말하면 부족합니다. “연간 장애 허용 시간을 어느 정도로 볼 것인가”로 바꿔야 설계가 구체화됩니다.

QPS는 하루 요청 수를 초 단위로 나누면 시작할 수 있습니다

QPS는 초당 요청 수입니다. 하루 요청 수를 알고 있다면 다음처럼 계산할 수 있습니다.

QPS = 하루 요청 수 / 86,400초

86,400초는 하루의 초 수입니다.

예를 들어 하루에 3억 건의 게시글 작성 요청이 있다고 가정하겠습니다.

하루 요청 수 = 300,000,000건
평균 QPS = 300,000,000 / 86,400 ~= 3,500

평균 QPS는 하루 전체를 고르게 나눈 값입니다. 실제 서비스는 하루 종일 고르게 사용되지 않습니다. 점심시간, 퇴근 후, 이벤트 시간처럼 요청이 몰리는 시간이 있습니다.

그래서 Peak QPS를 따로 잡습니다.

Peak QPS = 평균 QPS x 2 ~= 7,000

여기서 2배는 예시 가정입니다. 서비스 특성에 따라 3배, 5배, 10배가 될 수 있습니다. 중요한 것은 평균만 보고 설계하면 피크 시간에 장애가 날 수 있다는 점입니다.

저장소 추정은 큰 데이터를 먼저 찾는 일입니다

이번에는 게시글 서비스 저장소를 계산해 보겠습니다.

가정은 다음과 같습니다.

항목	값
MAU	3억 명
DAU	MAU의 50% = 1.5억 명
사용자당 하루 게시글	2건
전체 게시글 중 미디어 포함 비율	10%
미디어 1개 평균 크기	1MB
보관 기간	5년

하루 게시글 수는 다음과 같습니다.

1.5억 명 x 2건 = 3억 건/일

텍스트 크기를 게시글 1개당 204B로 잡으면 하루 텍스트 저장소는 다음과 같습니다.

3억 x 204B ~= 61.2GB/일

미디어 저장소는 다릅니다.

3억 x 10% x 1MB = 30TB/일

5년 동안 보관하면 다음과 같습니다.

(30TB + 0.06TB) x 365 x 5 ~= 54.75PB

이 계산에서 중요한 결론은 텍스트가 아니라 미디어가 저장소를 지배한다는 점입니다. 텍스트 크기를 조금 더 정확히 계산하는 것보다 이미지와 영상 크기, 압축 방식, 보관 정책을 확인하는 일이 더 중요합니다.

좋은 추정은 가정을 먼저 보여 줍니다

개략적 추정에서 가장 중요한 습관은 가정을 숨기지 않는 것입니다.

습관	이유
가정을 먼저 말합니다	계산 결과가 어디서 나왔는지 추적할 수 있습니다.
근사치를 씁니다	빠르게 규모를 판단할 수 있습니다.
단위를 붙입니다	5가 5건인지, 5MB인지, 5초인지 혼동하지 않습니다.
평균과 피크를 나눕니다	실제 장애는 보통 피크 시간에 발생합니다.
가장 큰 항목을 먼저 찾습니다	설계에 영향을 주는 지점을 빠르게 찾을 수 있습니다.

정확한 계산은 나중에 다시 할 수 있습니다. 초반 설계에서는 “이 시스템이 어느 규모의 문제인가”를 빠르게 잡는 것이 우선입니다.

다음 글에서는 시스템 설계 질문을 어떻게 순서대로 풀어갈지 정리합니다. 요구사항을 확인하고, 큰 그림을 그리고, 병목이 되는 지점을 깊게 파고드는 흐름입니다.