이 챕터의 면접관이 되어,
원활한 면접진행을 위해 좀 더 내용을 열심히 읽어보았다.
대규모 서비스를 설계하려면 필요한 저장 공간, 네트워크 대역폭, 서버 수 등을 미리 예측해야 한다.
하지만 설계 초기부터 모든 상황을 고려하여 정확한 수치를 계산하는 것은 현실적으로 어렵고, 오히려 시간과 비용이 많이 든다. 따라서 시스템 설계에서는 빠르게 규모를 예측하는 개략적인 규모 추정(Back-of-the-envelope Estimation) 을 활용한다.
'개략적'이라는 표현이 다소 생소할 수 있으니 먼저 뜻을 알아보자.
"개략적인 규모 추정은 보편적으로 통용되는 성능 수치를 바탕으로 사고 실험을 통해 추정치를 계산하여, 설계가 요구사항을 만족하는지 판단하는 과정이다."
— Jeff Dean
즉, 정확한 값을 계산하는 것이 목적이 아니라, 설계 방향이 적절한지 빠르게 판단하는 것이 목적이다.
이를 위해서는 규모 확장성을 표현하는 데 필요한 기본기를 갖추고 있어야 한다. 특히 2의 제곱수, 응답 지연, 가용성 과 같은 개념을 이해해야 저장 공간, 처리량, 서버 수 등을 합리적으로 추정할 수 있다.
2의 제곱수
컴퓨터가 2진수를 사용하기 때문에, 데이터의 크기나 저장 용량 단위도 2의 제곱수(1KB = 2¹⁰Byte, 1MB = 2²⁰Byte …)를 기준으로 정의된다.
따라서 분산 시스템에서 다루는 저장 공간, 메모리, 네트워크 사용량 등을 추정하려면 2의 제곱수와 데이터 용량 단위의 관계를 이해해야 한다.
단위
시스템 설계에서는 빠르게 규모를 추정해야 하는 경우가 많기 때문에 계산을 단순화하여 2¹⁰≈1천, 2²⁰≈100만처럼 근사치를 사용하는 경우도 있다.
| 2의 제곱 | 근사치 | 데이터 용량 단위 | 약어 |
|---|---|---|---|
| 2¹⁰ | 약 1천 | 킬로바이트(Kilobyte) | 1KB |
| 2²⁰ | 약 100만 | 메가바이트(Megabyte) | 1MB |
| 2³⁰ | 약 10억 | 기가바이트(Gigabyte) | 1GB |
| 2⁴⁰ | 약 1조 | 테라바이트(Terabyte) | 1TB |
| 2⁵⁰ | 약 1000조 | 페타바이트(Petabyte) | 1PB |
ex)
Q. 사용자 100만 명이 사용하는 서비스에서 게시글 하나의 크기가 2KB라면 필요한 저장 공간은?
A. > A. 2KB × 1,000,000 = 2,000,000KB ≈ 1,953MB ≈ 1.91GB ≈ 약 2GB
모든 프로그래머가 알아야 하는 응답지연 값
저장 공간을 추정하기 위해 데이터 크기와 단위를 이해했다면, 이번에는 연산이 얼마나 빠르게 수행되는지도 알아야 한다.
대규모 시스템에서는 CPU 연산뿐만 아니라 메모리 접근, 디스크 I/O, 네트워크 통신 등 다양한 작업이 발생한다. 각 작업의 응답 지연(latency)을 이해하면 어떤 부분이 병목이 될 수 있는지 판단하고, 시스템의 성능을 대략적으로 예측할 수 있다.
통상적인 컴퓨터에서 구현된 연산들의 응답지연 값
| 연산 | 응답 시간 |
|---|---|
| L1 캐시 참조 | 0.5ns |
| 분기 예측 오류 (Branch Mispredict) | 5ns |
| L2 캐시 참조 | 7ns |
| 뮤텍스(Mutex) 락/언락 | 100ns |
| 주 메모리 참조 | 100ns |
| Zippy로 1KB 압축 | 10,000ns (10μs) |
| 1Gbps 네트워크로 2KB 전송 | 20,000ns (20μs) |
| 메모리에서 1MB 순차 읽기(Read) | 250,000ns (250μs) |
| 같은 데이터센터 내 메시지 왕복 지연시간(RTT) | 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) |
2010년에 공개된 컴퓨터 연산의 응답 지연 값.
일부 수치가 현재와 달라졌지만, 각 연산의 상대적인 처리 속도를 이해하는 기준으로는 여전히 유용하다.
2020년에는 이 수치를 시각화하기 위한 도구도 나왔다.
가용성에 관계된 수치들
가용성 : 시스템이 사용자가 필요할 때 정상적으로 서비스를 제공할 수 있는 정도. 즉, 시스템이 오랜시간동안 지속적으로 중단없이 운영될 수 있음을 의미한다.
고가용성 : 가용성을 매우높이기 위한 설계방식. 서비스 장애 예방과 조치에 보다 높은 초점을 맞추었다.
가용률 : 가용성 100%는 시스템이 단 한 번도 중단되지 않았음을 의미한다.
다만 현실적으로는 계획된 점검, 예기치 못한 장애 등으로 인해 100% 가용성을 달성하기는 매우 어려워, 실제 서비스에서는 99.9%, 99.99%, 99.999% 와 같은 수준을 목표로 설계하는 경우가 많다.
수치사용 예시
| 가용률 | 하루당 허용 장애시간 | 주당 허용 장애시간 | 월당 허용 장애시간 | 연간 허용 장애시간 |
|---|---|---|---|---|
| 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% | 864ms (0.864초) | 6.05초 | 26.30초 | 5.26분 |
| 99.9999% | 86.4ms (0.0864초) | 604.8ms (0.6048초) | 2.63초 | 31.56초 |
예제) 트위터 QPS와 저장소 요구량 추정
풀이핵심
개략적인 규모 추정 면접에서 가장 중요한 것은 문제를 해결해 나가는 사고 과정이다.
면접관은 정답보다 올바른 절차와 논리적인 접근 방식을 더 중요하게 평가한다.
예를 들어 99987 / 9.1 과 같은 계산 문제가 주어졌을 때, 정확한 계산 결과를 구하는 것이 목적이 아니다.
적절한 근사치를 활용해 빠르게 추정하고, 그 근거를 설명하는 능력이 더 중요하다.
※ QPS(Queries Per Second): 1초에 몇 개의 요청이 오는가
추정예시
- 월간 능동 사용자(MAU, Monthly Active Users)는 3억 명이다.
- 이 중 50%의 사용자가 매일 서비스를 이용한다.
- 사용자는 하루 평균 2개의 트윗을 작성한다.
- 전체 트윗의 10%는 이미지나 동영상과 같은 미디어를 포함한다.
- 모든 데이터는 5년간 보관한다.
일간 능동 사용자(DAU) 계산
- DAU = MAU × 50%
- = 3억 × 50%
- = 1억 5천만 명
평균 QPS 계산
하루 동안 생성되는 트윗 수는 다음과 같다.
- 1억 5천만 명 × 2개 = 3억 건/일
이를 하루의 초(24 × 60 × 60 = 86,400초)로 나누면,
- QPS = 3억 ÷ 86,400 ≒ 3,500 QPS
즉, 평균적으로 초당 약 3,500개의 요청을 처리해야 한다.
최대 QPS(Peak QPS) 추정
실제 서비스에서는 특정 시간대에 사용자가 몰리므로 평균 QPS만으로는 부족하다.
일반적으로 최대 QPS는 평균 QPS의 약 2배로 가정하여 용량을 산정한다.
- Peak QPS = 3,500 × 2
- = 약 7,000 QPS
미디어 저장소 요구량 계산
평균 트윗 크기는 다음과 같이 가정한다.
- tweet_id : 64Byte
- 텍스트 : 140Byte
- 미디어 : 1MB
미디어를 포함하는 트윗은 전체의 10%이므로 하루 저장되는 미디어 용량은
- 1억 5천만 명 × 2개 × 10% × 1MB
- = 약 30TB/일
5년간 저장소 요구량 계산
모든 미디어를 5년 동안 보관한다고 가정하면
- 30TB × 365일 × 5년
- = 약 55PB(Petabyte)
의 저장 공간이 필요하다.
예제) 윤아 쇼핑몰 QPS 급증과 대응방안
대답
Peak QPS를 기준으로 병목을 감지하고, 운영 지표를 모니터링하여 운영 정책으로 대응하자.
라이브 방송이 시작되면 채팅기능이 해제되며, 인기 상품을 구매하기 위한 동시 접속자가 늘어나면서 평소보다 QPS가 크게 증가할 것으로 예상됩니다.
이 쇼핑몰의 평소 하루 평균 접속자 수가 12만 명이라는 점을 고려하면, 이 정도 규모의 서비스를 안정적으로 운영하기 위해 기본적으로 트래픽 분산 구조와 대규모 트래픽 처리에 적합한 캐싱 전략이 적용되어 있을 것이라고 추정되는데, 정확한 수치는 문제에서 제시되지 않았으므로 용량 산정을 위한 기준값을 설정하겠습니다.
라이브 방송은 순간적인 트래픽 집중이 발생하는 이벤트이므로, 일정 수준의 여유를 고려하여 접속 요청이 평소 대비 약 2배 증가하는 상황을 기준으로 추정하겠습니다.
또한 라이브 방송의 특성상 시청자들의 참여도가 높기 때문에 모든 사용자가 최소 1회 이상 채팅을 입력한다고 가정하면, 웹 요청뿐 아니라 채팅 요청까지 동시에 발생하여 피크 큐피에스(Peak QPS)가 평상시보다 크게 증가할 것으로 예상됩니다.
이처럼 웹 요청, 스트리밍, 채팅, 주문을 모두 단일 서버가 처리하는 구조에서는 급격히 증가한 요청으로 인해 서버의 처리 한계를 초과하거나 네트워크 대역폭이 포화될 수 있습니다. 그 결과 응답 시간이 증가하고, 스트리밍 품질 저하, 방송 끊김, 버퍼링, 채팅 지연과 같은 문제가 발생할 수 있습니다.
이러한 상황을 감지하기 위해서는 운영 지표(QPS, 응답 시간(Response Time), CPU·메모리 사용률, 네트워크 사용량, 에러율 등)를 지속적으로 수집하는 모니터링 파이프라인을 구축하겠습니다. 운영 지표를 실시간 대시보드에서 확인하고, 평상시 기준치(Baseline)를 초과하는 경우 자동으로 알림을 받을 수 있도록 구성하여 이상 징후를 빠르게 감지하겠습니다.
이와 같이 평상시 운영 지표를 기준선으로 관리하고, 피크 큐피에스를 실시간으로 감지하여 병목 지점을 신속하게 파악한 뒤 운영 정책을 조정하겠습니다. 예를 들어 라이브 방송 시간에는 요청 제한 정책을 적용하거나, 중요 요청을 우선 처리하도록 우선순위를 조정하는 등 서비스 상황에 맞는 운영 정책을 통해 대규모 트래픽에 대응하겠습니다.
독서를 마치며...
대용량 시스템을 설계하고 구축하는 과정에서 효율성과 합리적인 자원 관리를 위해서는 개략적인 규모 측정이 중요한 능력일 것이라 생각된다.
그런 이유로 내가 면접관인 면접에서는 아마 2의 제곱수 개념 (ex. 100mb는 몇 kb인가) 등의 암기형 문제보다는 이러한 값들이 개략적인 규모를 산정하고 시스템을 설계할 때 어떻게 활용되는지를 묻는 문제가 나올 듯 하다.
면접자 오이데~
WoW