이전 포스트: [ 대규모 시스템 설계 스터디 ] 1장 정리
다음 포스트: [ 대규모 시스템 설계 스터디 ] 3장 정리
2장. 개략적인 규모 추정
시스템을 설계할 때는 단순히 구조만 그리는 것이 아니라,
이 구조가 실제 사용자 수와 트래픽을 감당할 수 있는가?
를 수치로 확인할 필요가 있다.
이를 위해 사용자 수, 요청량, 데이터 크기 등의 정보를 바탕으로 QPS, 저장 공간, 네트워크 사용량, 필요한 서버 수 등을 대략적으로 계산하는 과정이 개략적인 규모 추정이다.
중요한 것은 완벽하게 정확한 값을 계산하는 것이 아니라, 주어진 조건을 바탕으로 시스템 규모를 합리적으로 예측하는 것이다.
규모 추정을 위해 알아야 할 기본 수치
개략적인 규모 추정을 하기 위해서는 기본적으로 다음과 같은 개념에 익숙해야 한다.
- 데이터 크기와 2의 제곱수
- 메모리, 디스크, 네트워크 등의 응답 지연 시간
- 시스템 가용성
- QPS와 같은 처리량 지표
이러한 기본 수치를 알고 있으면
사용자 수
↓
하루 요청량
↓
평균 / 최대 QPS
↓
필요 서버 수와 같은 방식으로 시스템 규모를 추정할 수 있다.
1. 데이터 크기와 2의 제곱수
컴퓨터에서 데이터 크기를 계산할 때는 바이트 단위를 기본으로 사용한다.
1 Byte = 8 bit예를 들어 일반적인 ASCII 문자 하나는 1Byte 정도의 공간을 사용한다.
데이터 규모가 커지면 다음 단위를 사용하게 된다.
KB
MB
GB
TB
PB분산 시스템에서는 하루에도 TB 이상의 데이터가 생성될 수 있기 때문에 이러한 단위 변환에 익숙해야 한다.
예를 들어
하루 데이터 생성량
×
보관 기간
=
필요 저장 공간과 같이 계산한다.
규모 추정에서는 반드시 완벽한 이진 단위 계산만 고집하기보다는 계산을 빠르게 하기 위해 적절한 근삿값을 사용하는 경우도 많다.
2. 응답 지연 시간 Latency
시스템 내부의 모든 연산 속도가 동일한 것은 아니다.
CPU 내부의 캐시 접근과 메모리 접근, 디스크 접근, 네트워크 통신은 각각 속도 차이가 매우 크다.
전체적으로 보면 다음과 같은 느낌으로 이해할 수 있다.
CPU Cache
↓
Memory
↓
SSD
↓
Disk
↓
Network아래쪽으로 갈수록 일반적으로 더 많은 시간이 필요하다.
응답 지연 수치에서 볼 수 있는 점
1. 메모리는 디스크보다 빠르다
자주 사용하는 데이터를 메모리에 저장하는 캐시가 중요한 이유이기도 하다.
DB / Disk 조회
↓
Cache 활용
↓
응답 속도 개선2. 디스크 탐색 비용은 크다
디스크에서 원하는 위치를 찾아 이동하는 Seek 과정에는 비교적 큰 시간이 필요하다.
따라서 가능한 경우 불필요한 디스크 접근을 줄이는 것이 중요하다.
3. 단순한 데이터 압축은 비교적 빠르다
데이터 크기가 크다면 네트워크로 그대로 전달하는 것보다 압축한 뒤 전송하는 것이 전체 처리 시간을 줄이는 데 도움이 될 수 있다.
원본 데이터
↓
압축
↓
Network 전송4. 데이터 센터 사이의 통신에도 시간이 필요하다
여러 데이터 센터를 운영한다고 해서 데이터가 즉시 동기화되는 것은 아니다.
예를 들어
서울 Data Center
↕
미국 Data Center처럼 물리적으로 멀리 떨어져 있다면 네트워크 지연이 발생한다.
따라서 다중 리전이나 다중 데이터 센터 구조에서는 데이터 복제와 통신 비용도 함께 고려해야 한다.
3. 가용성 Availability
서비스가 얼마나 안정적으로 운영되는지를 나타내는 대표적인 지표가 가용성이다.
가용성은 전체 시간 중 시스템을 정상적으로 사용할 수 있었던 시간의 비율을 의미한다.
가용성
=
정상 서비스 시간 / 전체 시간일반적으로 퍼센트로 표현한다.
예를 들어
99%
99.9%
99.99%
99.999%등과 같이 표현할 수 있다.
숫자상으로는 작은 차이처럼 보이지만, 실제 허용 가능한 장애 시간은 크게 달라진다.
고가용성 High Availability
장시간 서비스 중단 없이 지속적으로 시스템을 제공할 수 있는 특성을 의미한다.
서비스 규모가 커질수록 단순히 성능뿐만 아니라
장애가 발생했을 때 서비스를 얼마나 계속 유지할 수 있는가
도 중요한 설계 요소가 된다.
그래서 로드밸런서, 서버 다중화, DB Replica, 다중 데이터 센터 등의 구조가 필요해진다.
4. SLA
SLA는 Service Level Agreement의 약자다.
서비스 제공자와 고객 사이에서 서비스 수준을 어느 정도까지 보장할 것인지 정하는 약속이라고 이해할 수 있다.
대표적인 항목으로 가용성이 있다.
예를 들어
Availability ≥ 99.9%와 같은 형태로 일정 수준 이상의 서비스 운영을 보장할 수 있다.
가용성에서는 흔히 9가 몇 개 있는가로 안정성을 표현하기도 한다.
99.9%
99.99%
99.999%9가 늘어날수록 서비스 중단을 허용할 수 있는 시간이 크게 줄어든다.
5. 규모 추정에서 중요한 QPS
이번 장에서 처음 접한 개념 중 가장 중요했던 것이 QPS였다.
QPS Queries Per Second
초당 시스템이 처리하는 쿼리 또는 요청의 수를 의미한다.
예를 들어 서버에 하루 동안 8,640만 건의 요청이 들어온다면
86,400,000
÷
86,400초
=
1,000 QPS가 된다.
즉 평균적으로 초당 1,000개의 요청을 처리하는 시스템이다.
평균 QPS
일반적인 계산은 다음과 같다.
하루 전체 요청 수
÷
86,400초
=
평균 QPS여기서
24 × 60 × 60 = 86,400초이다.
6. Peak QPS
실제 서비스에서 요청이 하루 종일 일정하게 들어오는 경우는 거의 없다.
예를 들어
- 출근 시간
- 점심시간
- 퇴근 시간
- 이벤트 시작 시간
- 수강신청 시간
등 특정 시간에 요청이 몰릴 수 있다.
따라서 평균 QPS만 보고 서버를 설계하면 실제 트래픽이 몰렸을 때 시스템이 버티지 못할 수 있다.
이를 고려하기 위해 Peak QPS를 계산한다.
Peak QPS
=
평균 QPS × 여유 계수예를 들어 평균 QPS가 3,500이고 최대 트래픽을 평균의 2배로 가정하면
Peak QPS
=
3,500 × 2
=
7,000으로 볼 수 있다.
다만 Peak QPS를 반드시 평균 QPS의 2배로 잡아야 한다는 절대적인 규칙은 없다.
서비스 특성과 트래픽 패턴에 따라 2배, 3배 또는 그 이상으로 설정할 수 있다.
7. QPS와 RPS, TPS 차이
비슷하게 사용되는 용어가 몇 가지 있다.
QPS
Queries Per Second
초당 처리되는 질의 수
DB나 검색 시스템 등의 처리량을 표현할 때 많이 사용한다.
RPS
Requests Per Second
초당 처리되는 요청 수
특히 HTTP 서버 트래픽을 표현할 때 자주 사용한다.
Client
↓ HTTP Request
Server웹 서비스에서는 QPS와 RPS가 비슷한 의미로 사용되는 경우도 있다.
TPS
Transactions Per Second
초당 완료되는 트랜잭션 수
하나의 트랜잭션에는 여러 개의 쿼리가 포함될 수도 있다.
예를 들어 결제 한 번에서
재고 확인
↓
주문 생성
↓
결제 정보 저장
↓
재고 감소와 같이 여러 DB 작업이 묶여 하나의 트랜잭션이 될 수 있다.
8. 규모 추정 예제
간단한 SNS 서비스가 있다고 가정해보자.
조건
- 월간 활성 사용자: 3억 명
- 그중 50%가 매일 사용
- 사용자 한 명이 하루 평균 게시글 2개 작성
- 게시글 중 10%에 미디어 포함
- 데이터를 5년간 보관
이 조건을 이용하면 처리량과 저장 공간을 추정할 수 있다.
1단계. DAU 계산
월간 사용자 3억 명 중 절반이 매일 서비스를 사용한다고 가정한다.
3억 × 50%
=
1.5억따라서
DAU = 약 1.5억 명이다.
2단계. 하루 게시글 수 계산
사용자 한 명이 하루 평균 2개의 게시글을 작성한다.
1.5억 명
×
2개
=
3억 개 / 일3단계. QPS 계산
하루 동안 약 3억 개의 게시 요청이 발생한다고 가정한다.
3억
÷
86,400초
≈
3,500 QPS따라서 평균 QPS는 약
3,500 QPS정도로 추정할 수 있다.
4단계. Peak QPS 계산
최대 트래픽을 평균의 2배로 가정하면
3,500 × 2
=
7,000 QPS따라서 시스템은 최소한 약 7,000 QPS 수준의 순간 트래픽을 처리할 수 있도록 고려해볼 수 있다.
9. 저장 공간 계산
이번에는 미디어 데이터가 얼마나 저장되는지 계산한다.
미디어가 포함된 게시글의 비율을 10%라고 가정했다.
3억 게시글
×
10%
=
3천만 개하루 약 3천만 개의 미디어 파일이 업로드된다.
미디어 하나의 평균 크기를 1MB라고 가정하면
3천만
×
1MB
=
약 30TB / 일정도의 데이터가 생성된다.
5년간 저장한다면?
하루 약 30TB가 발생한다고 가정하면
30TB
×
365일
×
5년
≈
55PB정도의 저장 공간이 필요하다.
정확한 값을 계산하는 것보다
이 서비스에서는 수십 PB 수준의 저장 공간이 필요하겠구나
라는 전체 규모를 파악하는 것이 중요하다.
10. 규모 추정에서 중요한 사고방식
시스템 설계 면접에서 규모 추정을 요구하는 이유는 단순한 산수 실력을 확인하기 위한 것이 아니다.
오히려 중요한 것은
문제 조건 파악
↓
필요한 가정 설정
↓
계산식 구성
↓
결과 도출
↓
설계에 반영과 같은 사고 과정이다.
1. 복잡한 숫자는 근사한다
예를 들어
99,487이라는 숫자가 있다면 필요에 따라
약 100,000으로 계산할 수 있다.
규모 추정에서는 정확한 소수점보다 전체 규모를 빠르게 판단하는 것이 중요하기 때문이다.
2. 가정을 먼저 작성한다
계산을 시작하기 전에 어떤 조건을 사용했는지 명확하게 적는다.
예를 들어
MAU = 3억
DAU = MAU의 50%
1인당 게시글 = 2개 / 일
미디어 포함 비율 = 10%처럼 정리한다.
이렇게 하면 계산이 틀려도 어디에서 문제가 발생했는지 확인하기 쉽다.
또한 시스템 설계 면접에서는 면접관과 가정 자체를 먼저 맞출 수 있다.
3. 반드시 단위를 작성한다
예를 들어 단순히
500이라고 적는 것이 아니라
500 QPS
500 MB
500 GB
500 Mbps처럼 단위를 함께 작성해야 한다.
규모 추정에서는 계산 자체보다 단위 실수로 결과가 크게 잘못되는 경우가 있기 때문이다.
11. 규모 추정에서 자주 계산하는 것
시스템 설계 문제에서는 주로 다음과 같은 값을 구하게 된다.
요청 처리량
평균 QPS
Peak QPS
RPS
TPS데이터
하루 데이터 생성량
전체 저장 공간캐시
필요 Cache Size서버
필요 서버 수예를 들어 단일 서버가 최대
1,000 RPS를 처리할 수 있고 Peak RPS가
10,000 RPS라면 단순 계산상
10,000 / 1,000
=
10대정도의 서버가 필요하다는 식으로 접근할 수 있다.
물론 실제 시스템에서는 장애 대비와 여유 용량까지 추가로 고려해야 한다.
전체 흐름 정리
이번 장의 내용을 하나의 과정으로 정리하면 다음과 같다.
사용자가 얼마나 있는가?
↓
하루에 얼마나 서비스를 사용하는가?
↓
요청이 하루에 몇 건 발생하는가?
↓
초당 요청은 몇 개인가?
↓
Peak 상황에서는 얼마나 증가하는가?
↓
데이터는 하루에 얼마나 만들어지는가?
↓
몇 년 동안 저장해야 하는가?
↓
어느 정도 규모의 시스템이 필요한가?결국 개략적인 규모 추정은
사용자의 행동을 숫자로 바꾼 뒤, 그 숫자를 시스템의 처리량과 저장 공간 요구사항으로 변환하는 과정
이라고 이해할 수 있다.
공부하면서 정리한 핵심
1장에서 로드밸런서, 캐시, DB 다중화, 샤딩처럼 시스템을 어떻게 확장할 것인지를 배웠다면,
이번 장에서는 그보다 먼저
도대체 얼마나 확장해야 하는가?
를 판단하는 방법을 배웠다고 생각한다.
예를 들어 막연하게
"사용자가 많으니까 서버를 여러 대 둬야 한다."라고 판단하는 것이 아니라,
DAU
→ 하루 요청량
→ 평균 QPS
→ Peak QPS
→ 단일 서버 처리량
→ 필요한 서버 수와 같이 숫자를 근거로 설계할 수 있다.
특히 이번 장에서 가장 중요하게 느낀 부분은 정확한 계산보다 합리적인 가정과 계산 과정이었다.
처음에는 QPS나 가용성 같은 용어가 익숙하지 않았지만, 실제 계산 자체는 크게 어렵지 않았다.
다만 시스템 설계 면접에서는 주어진 조건을 보고 빠르게 가정을 세우고 계산해야 하므로
- 하루는 약 86,400초
- 데이터 크기 단위
- 평균 QPS 계산 방식
- Peak 트래픽을 고려하는 방법
- 가용성의 의미
정도는 바로 사용할 수 있도록 익숙해질 필요가 있을 것 같다.
이번 장은 새로운 아키텍처를 배우기보다는, 앞으로 시스템을 설계할 때 필요한 숫자 감각을 만드는 장에 가까웠다.
