서비스 운영에 필요한 서버 스펙 정의

서비스 수준 (Service Level)

서비스 수준에는 크게 세가지 용어로 설명한다.

서비스 수준 목표(ServiceLevel Objectives, SLO): 시스템에서 기대되는 가용성을 설정한 목표.
서비스 수준 지표(Service Level Indicators, SLI): 시스템의 가용성을 파악하기 위한 핵심 측정치와 지표.
서비스 수준 계약(Service-Level agreements, SLA): 시스템이 SLO를 충족하지 못할 경우 발생하는 상황과 합의된 내용을 설명하는 법적 계약.

트래픽 산정을 다루기 위해 SLO 개념을 주로 다룹니다. 서비스 수준의 종류에 대한 비교와 상세 설명은 여기를 참조해주세요.

SLO 정의(성능 목표)
1. 가용성: 예) 99.9%
수요 모델링(Workload)
1. 사용자 규모: DAU/WAU/MAU, 피크배율(평균 대비 최대 트래픽 배수)
2. 사용 패턴: 세션 길이, 페이지/분, API 호출/페이지, Think time
3. 트래픽 조합: GET/POST 비율, 실시간 여부, 배치 작업 유무
리소스 모델링(자원/비용)
1. CPU, 메모리, 네트워크(대역폭/egress), 디스크(용량/IOPS/Throughput), DB/캐시
2. 한 요청당 자원 사용량(서비스 시간, 쿼리 수, 바이트)
검증(Load Test/관측)
가설 수치로 부하 테스트 → 관측치로 모델 보정 → 여유분(헤드룸) 확정

모델을 먼저 만들고, 실측으로 보정하는 편이 추정만 하는 것보다 좋다고 한다.

QPS/RPS(초당 요청 수)
RPS = 동시활성 사용자 x 사용자당 RPS
사용자당 RPS = (페이지/분 x 페이지당 API콜 수) / 60
대역폭(Throughput)
초당 전송량(바이트/초) = RPS x 평균응답크기(바이트)
원본 서버 기준 트래픽 = 전체 트래픽 x (1 - 캐시적중률)
Little’s Law
동시요청수 L = λ(도착률 RPS) × W(평균 응답시간)
예) RPS=200, 평균=0.2초 → L=40개 동시 처리 필요
CPU 활용도(단일 코어 근사)
U = λ × S (S=평균 서비스시간/요청의 CPU점유 시간)
목표 활용도(ρ)를 0.6~0.7로 제한 → 필요 코어수 ≈ (λ × S) / ρ
DB IOPS
DB RPS = App RPS x 요청당 쿼리수 x (1 - 캐시히트)
스토리지 IOPS/Throughput은 엔진, 인덱스, 트랜잭션 크기에 따라 상이 → 부하테스트로 보정
저장소 용량(로그/이벤트)
일간 데이터량 = 이벤트 수/일 x 평균 바이트
필요 용량 = 일간 x 보관일수 x (1 + 압축여유)

문제를 가정하고 더 쉬운 풀이로 계산해나간다.

동시에 쓰는 사람 수(피크 동시 사용자)
- 어디서: 구글 애널리틱스 동시 접속, 서버 로그(시간대별 요청), 없다면 합리적 추정(=평균의 3~10배)
- 뜻: 가장 바쁠 때 한순간에 놀러 오는 사용자 수
한 사람이 1분에 몇 화면 보나(페이지/분)
- 뜻: 사용자이 1분에 몇개의 컨텐츠를 보는지
- 어디서: 프론트 로그/GA4, 없으면 1~3으로 가정
화면 하나에 API를 몇 번 요청하는지(API/화면)
- 뜻: 컨텐츠 하나 볼 때 서버로 몇 번 요청하는지
- 어디서: 네트워크 탭/백엔드 라우트 카운트(대개 1~5)
응답 크기(바이트)
- 뜻: 서버에서 응답하는 데이터 크기
- 어디서: 서버 로그 response size 평균 (예: 10~50KB)
목표 속도(응답시간)
- 뜻: 사용자 한 명을 평균 몇 초 만에 처리할지 (예: 평균 0.2초)
- 어디서: APM/로그, 없으면 목표로 정함 (예: 0.1 ~ 0.3초)
캐시 유무(적중률)
- 뜻: 자주 요청하는 건 미리 준비해서 바로 제공(정적/GET 캐시 적중률)
- 어디서: CDN/프록시 통계(없으면 0~60% 가정)
요청 하나에 DB를 몇 번 쿼리 요청하는지(쿼리/요청) (QPS)
- 뜻: 서버가 DB에 몇 번 조회 하는가
- 어디서: 쿼리 로깅/ORM 미들웨어 (예: 대개 1~5)

핵심 공식 일부를 사용해 모의로 트래픽을 계산한다.

초당 요청 수(RPS): 동시 사용자 x 한 사람의 초당 요청 수
- 한 사람 초당 요청 수: (페이지/분 x API/페이지) / 60
- 예) 페이지/분 2, API/페이지 2 → 4/60 = 0.0667
- 동시 50명 → RPS = 50 x 0.0667 = 약 3.33RPS
- 즉, 초당 3.33개의 요청이 발생
동시 처리 요청 수: RPS x 평균 응답 시간(초)
- 예) 3.33 x 0.2초 = 0.666 (= 대략 0.67개)
- 뜻: 서버가 동시에 붙잡고 있는 사용자 수
초당 데이터 양(대역폭): RPS x 평균 응답 크기
- 예) 3.33 x 15KB = 약 50KB/s (= 약 0.4Mb/s)
초당 DB 일(쿼리 수): RPS x (쿼리/요청) x (1 - 캐시 히트)
- 예) 쿼리/요청 2, 캐시 없음 → 3.33 x 2 = 6.66QPS

여기까지 계산하면 “얼마나 바쁜지” 눈에 보인다. 초당 3.33명이 사용하고, 동시에 1명을 처리중이며, 초당 50KB데이터가 응답되며, DB는 초당 6~7번 일한다.

서버(계산대), DB(창고 직원), 캐시/CDN(진열대)으로 나눈다.

애플리케이션 서버(계산대)
- vCPU(계산대 수):
  대략 동시요청 수 x 2배면 초보자 사용에 충분
  이유는 스파이크, GC 등 버퍼가 필요하기 때문
  - 예) 동시 요청 = 약 1 → 2 vCPU 추천(최소 2개 = N + 1)
- 메모리:
  앱 기본 메모리 + (동시요청 x 요청당 임시 메모리 5~20MB) + 여유 30%
  - 예) 기본 300MB + (1 x 10MB) → 1~2GB면 충분
- 네트워크:
  대역폭 계산값 x 1.5 ~ 2배
  - 예) 50KB/s x 2 = 100KB/s 여유(클라우드 기본으로 충분)
데이터베이스(창고 직원)
- QPS 보고 작은 사양으로 시작 + 인덱스/쿼리 튜닝
  - 예) 6~7 QPS명 소형 인스턴스도 무난
- 중요: 느린 쿼리를 해결하면 서버 스펙보다 효과 큼
캐시/CDN(진열대)
- GET 결과 30~120초 캐시만 해도 RPS/DB부하 크게 감소
- 이미지/정적 리소스는 CDN 기본

다음은 계산에 필요한 데이터 조건.

✅ 레퍼런스

📅 작성일: 2025-11-06 03:18:24
✍️ 작성자: 김경남