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

📊 데이터 볼륨 단위 테이블

제곱수 (2^n)	값 (바이트)	단위	근사치 (10의 거듭제곱)
2¹⁰	1,024	1KB	≈ 10³ (1천)
2²⁰	1,048,576	1MB	≈ 10⁶ (1백만)
2³⁰	1,073,741,824	1GB	≈ 10⁹ (10억)
2⁴⁰	1,099,511,627,776	1TB	≈ 10¹² (1조)
2⁵⁰	1,125,899,906,842,624	1PB	≈ 10¹⁵ (1천조)

---

🔹 추가 설명

✔ KB (킬로바이트) ≈ 1천 바이트

✔ MB (메가바이트) ≈ 1백만 바이트

✔ GB (기가바이트) ≈ 10억 바이트

✔ TB (테라바이트) ≈ 1조 바이트

✔ PB (페타바이트) ≈ 1천조 바이트

📌 2의 제곱수 기반 값과 10의 거듭제곱 비교

• 실제 값은 2의 제곱수(1024 기준)로 계산되므로 10의 거듭제곱 근사치보다 1.024배 큼
• 개략적인 규모 추정 시 10의 거듭제곱을 참고하면 편리함

⚡ 응답 지연 시간 & 최적화 가이드 ⚡

응답 지연 테이블 (상세)

연산명	응답 시간	설명
CPU L1 캐시 접근	0.5 ns (나노초)	CPU 내부 가장 빠른 캐시
CPU L2 캐시 접근	7 ns	CPU 내부 보조 캐시
RAM 접근	100 ns	메모리 접근 속도
SSD (PCIe) 읽기	150 µs	고속 SSD 랜덤 읽기
SSD (SATA) 읽기	1 ms	일반 SSD 랜덤 읽기
HDD 탐색(랜덤 액세스)	10 ms	디스크 탐색(Seek)
HDD 순차 읽기	2 ms	회전 디스크에서 순차적 읽기
데이터 센터 내 네트워크 전송 (1Gbps)	500 µs - 1 ms	같은 데이터센터 내 전송
다른 지역의 데이터 센터로 전송	100 ms	지역 간 데이터 센터 전송
대륙 간 데이터 전송	150 - 300 ms	글로벌 네트워크 전송
데이터 압축 (빠른 알고리즘, 1GB)	10 - 50 ms	LZ4, Snappy 등
데이터 압축 (높은 압축률, 1GB)	500 ms - 1 s	gzip, bzip2 등
데이터 전송 (1GB over 1Gbps)	8 s	네트워크 최대 속도 기준

응답 지연 테이블 (상대적)

연산명	시간 (대체로)	설명
메모리 접근	10ns ~ 100ns	메모리는 매우 빠르며, CPU와 메모리 간의 데이터 전송이 빠릅니다.
디스크 접근	1ms ~ 10ms	디스크는 메모리보다 느립니다. 특히 HDD에서는 더 많은 지연이 발생합니다.
디스크 탐색	10ms ~ 100ms	디스크 탐색은 상대적으로 느리므로 가능한 피해야 합니다.
압축 (단순 알고리즘)	10ms ~ 100ms	데이터 압축은 빠르며, 특히 단순한 알고리즘에서는 빠른 성능을 보입니다.
데이터 인터넷 전송	10ms ~ 200ms (로컬) ~ 수초 (인터넷 연결 상황에 따라 달라짐)	인터넷을 통한 데이터 전송은 거리와 네트워크 상태에 따라 지연 시간이 큽니다.
데이터 센터 간 전송	수십 ms ~ 수초	데이터 센터는 여러 지역에 분산되어 있고, 센터 간 데이터 전송은 지연 시간이 발생합니다. 지역 간 거리와 네트워크 혼잡도에 따라 차이가 있습니다.

🚀 1. 메모리는 빠르지만, 디스크는 느리다

✅ RAM: CPU와 직접 연결되어 있어 10ns~100ns 수준의 빠른 접근 속도를 가짐

✅ SSD: HDD보다 훨씬 빠르지만, RAM보다는 100배 이상 느림

✅ HDD: 기계식 디스크로, 디스크 탐색(Seek)은 가능한 피해야 함 ⚠️

💾 2. 디스크 접근 & 탐색 최적화

📌 디스크 탐색(Seek)은 가장 큰 지연 요인 → 순차적 읽기/쓰기를 최대한 활용할 것

📌 HDD (1ms~10ms) vs SSD (100μs~1ms) → SSD를 사용하면 지연 시간 단축 가능

📦 3. 데이터 압축은 빠르다 → 전송 전에 압축할 것

⚡ 단순 압축 알고리즘 (예: RLE, Huffman 등)은 매우 빠름

⚡ 압축 후 전송하면 네트워크 대역폭을 절약하고 전송 속도를 개선할 수 있음

📌 예: 원본 데이터 1GB → 압축 후 200MB → 네트워크 트래픽 및 지연 시간 80% 감소

🌍 4. 데이터 센터 간 전송 최적화

📌 데이터 센터는 여러 지역에 분산 → 센터 간 전송 시 수십 ms~수초 지연 발생

📌 데이터 위치를 최적화하여 불필요한 전송을 최소화할 것

📌 CDN(Content Delivery Network) 활용하여 사용자와 가까운 곳에서 데이터를 제공

---

⚡ 핵심 정리

✅ 메모리(RAM) 사용을 극대화하고, 디스크 탐색(Seek)은 피할 것

✅ SSD가 HDD보다 훨씬 빠르지만, RAM보다는 느리다는 점을 고려할 것

✅ 네트워크 전송 전에 압축하여 속도를 최적화할 것

✅ 데이터 센터 간 이동을 최소화하고, 데이터 위치를 최적화할 것

🛡 가용성과 9의 개수 (Nine's Availability)

고가용성(HA, High Availability)은 시스템이 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력을 의미합니다.

서비스 사업자들은 SLA(Service Level Agreement)를 통해 고객과 가용성을 약속하며, 이는 흔히 "9의 개수"로 표현됩니다.

---

📊 가용성 & 시스템 장애 시간 테이블

가용성 (Nine's)	퍼센트 (%)	연간 허용 다운타임	월간 허용 다운타임	주간 허용 다운타임	일간 허용 다운타임
90% (1 Nine)	90.0%	36.5일	72시간	16.8시간	2.4시간
99% (2 Nines)	99.0%	3.65일	7.2시간	1.68시간	14.4분
99.9% (3 Nines)	99.9%	8.76시간	43.2분	10.1분	1.44분
99.99% (4 Nines)	99.99%	52.6분	4.32분	1.01분	8.64초
99.999% (5 Nines)	99.999%	5.26분	26초	6.05초	0.86초
99.9999% (6 Nines)	99.9999%	31.5초	2.6초	0.605초	0.086초

---

🔥 가용성 수준 선택 시 고려 사항

✔ 99.9% (3 Nines, 연간 8.76시간 다운타임)

→ 일반적인 클라우드 서비스, 웹 애플리케이션, B2C 서비스 수준

✔ 99.99% (4 Nines, 연간 52.6분 다운타임)

→ 은행 시스템, 대기업 SaaS 서비스 수준

✔ 99.999% (5 Nines, 연간 5.26분 다운타임)

→ 항공사, 금융거래 시스템, 의료 시스템 수준

✔ 99.9999% (6 Nines, 연간 31.5초 다운타임)

→ 실시간 미션 크리티컬 시스템 (ex: 군사, 우주, 항공관제 시스템 등)

---

⚠ 가용성이 높아질수록 비용 증가

💰 99.9% → 99.99% 증가 = 비용 2배 이상 증가

💰 99.99% → 99.999% 증가 = 비용 10배 이상 증가

✅ SLA 목표에 맞춰 적절한 가용성 수준을 선택하는 것이 중요!

✅ 서비스 특성에 따라 HA(High Availability) 전략을 조정할 것!

📊 QPS(초당 요청 수)와 저장소 요구량 추정 예시

🚀 예제 1: 간단한 웹 서비스의 QPS 및 저장소 요구량 계산

📌 가정:

• 평균 요청 수: 100 QPS
• 각 요청의 평균 응답 크기: 5KB
• 하루 24시간 운영

🧮 하루 동안의 총 데이터 전송량 계산

💾 1년 저장소 요구량

📌 결과: 단순한 웹 서비스라도 연간 15.8TB 저장소가 필요함.

---

🚀 예제 2: 로그 데이터 저장소 요구량 계산

📌 가정:

• 서비스 QPS: 10,000 QPS
• 각 요청당 로그 크기: 500B (0.5KB)
• 로그를 1년간 저장

🧮 하루 동안의 총 로그 데이터 크기

💾 1년 저장소 요구량

📌 결과: 로그 데이터는 많이 발생하기 때문에 1년 저장 시 157.7TB의 스토리지가 필요함.

---

🚀 예제 3: 영상 서비스의 QPS 및 저장소 요구량 계산

📌 가정:

• 사용자가 1,000만 명
• 동시 접속률: 10% (1백만 명 동시 접속)
• 각 사용자는 평균 1분에 1개의 영상 요청 (즉, QPS ≈ 16,667)
• 영상 크기: 10MB (720p 기준)
• CDN 캐시 적중률: 80% (즉, 원본 서버에서의 QPS = 3,333)

🧮 하루 동안의 총 데이터 전송량 (CDN 적용 후)

💾 1년 저장소 요구량 (비압축 저장 기준)

📌 결과: 동영상 스트리밍 서비스에서는 연간 1EB(엑사바이트) 이상의 저장소가 필요할 수도 있음.

---

🔥 요약 및 최적화 팁

📌 QPS가 높으면 💡

• 캐시(Cache, 예: Redis, CDN) 적용
• 데이터 압축 및 효율적 저장 (예: 로그 압축)
• 비동기 처리를 통해 부하 분산

📌 저장소 요구량이 크다면 💡

• 오래된 데이터 아카이빙 (예: S3 Glacier)
• 실시간 데이터 & 이력 데이터 분리 저장
• 압축 알고리즘 적용 (예: gzip, zstd)

---

✅ 결론

• QPS가 높아질수록 네트워크 및 저장소 요구량이 기하급수적으로 증가함 🚀
• 데이터 압축, 캐시, 비동기 처리, 보존 주기 관리 등을 고려하여 최적화할 것!

🎯 면접에서 규모 추정 문제 해결을 위한 팁

대규모 시스템 설계 면접에서는 정확한 수치보다는 빠른 추론과 논리적인 접근법이 중요하다.

복잡한 계산을 피하고 근사치를 활용하여 시간을 절약하는 것이 핵심이다.

---

✅ 1. 근사치를 활용하여 빠르게 계산하라

📌 면접장에서 복잡한 계산을 하면 실수할 가능성이 높음 → 적절한 근사치를 활용하여 빠르게 계산

📌 2의 제곱수(1024)를 1000으로 근사하거나 10의 거듭제곱(1M = 10⁶)을 사용하면 계산이 쉬워짐

📌 예: 1GB ≈ 10⁹ 바이트, 1TB ≈ 10¹² 바이트

🎯 예제 1: 초당 요청 수(QPS)로 1일 데이터 전송량 추정

• 가정
  • QPS = 5,000
  • 1회 요청당 데이터 크기 = 3KB
  • 1일 데이터 전송량 계산

근사치 적용:

---

✅ 2. 가정들을 미리 정리하고 필요 시 수정하라

📌 문제에서 주어진 값이 없으면 합리적인 가정을 먼저 설정

📌 계산을 진행하면서 필요하면 가정을 조정

📌 예: "QPS를 초당 1,000으로 잡고 계산해보겠습니다."

🎯 예제 2: 웹 서비스의 최대 QPS 추정

• 하루 100만 명이 방문하는 웹사이트
• 평균 체류 시간: 10분
• 사용자는 30초마다 요청 1회

💡 가정:

• 활성 사용자는 평균적으로 10분 동안 머무름
• 1명당 1분에 2번 요청
• 동시 접속자 수 = 100만 × (10/1440) ≈ 7,000명

최대 QPS 추정:

---

✅ 3. 단위를 반드시 붙여 모호함을 줄여라

📌 면접에서 단위를 명확하게 붙여야 논리적 오류를 방지할 수 있음

📌 예: 10MB ≠ 10Mb (MB는 바이트, Mb는 비트)

📌 시간, 데이터 크기, QPS 등 단위를 항상 확인할 것

---

✅ 4. 개략적 규모 추정 문제는 다음을 중심으로 다룬다

1️⃣ QPS (Queries Per Second)

• 시스템이 초당 처리해야 하는 요청 수
• 평균 QPS와 최대 QPS(트래픽 피크) 추정

2️⃣ 저장소 요구량

• 하루/월/년 단위로 저장되는 데이터량 계산
• 로그, 이미지, 영상 등의 저장소 용량 추정

3️⃣ 캐시 요구량

• 전체 데이터 중 얼마나 캐싱해야 하는지 분석
• CDN, Redis 등 활용 여부 고려

4️⃣ 서버 수

• 개별 서버의 처리량과 부하 분산을 고려하여 서버 개수 계산

---

🔥 면접에서 규모 추정 문제를 잘 해결하는 법

✅ 근사치를 적극 활용하여 빠르게 계산

✅ 가정들을 명확히 정리하고, 필요 시 조정

✅ 단위를 정확히 붙여 논리적 오류 방지

✅ QPS, 저장소, 캐시, 서버 수 등 주요 요소를 빠르게 추정