서버는 어디까지 버틸 수 있는가? - 고가용성과 부하 테스트
개발자라면 누구나 한 번쯤 이런 고민을 해봤을 것입니다.
“우리 서버 스펙은 어느 정도로 잡아야 할까?” “이번 주말 이벤트 때 트래픽이 몰릴 텐데, 서버가 터지지 않을까?”
이 질문에 대해 “아마 될 걸요?”라고 대답하는 것은 매우 위험합니다. 현업에서는 부하 테스트(Load Testing)를 통해 명확한 데이터로 답변해야 합니다. 기능을 배포하기 전, 설계와 실제 운영 환경 간의 간극을 줄이고 시스템이 견딜 수 있는 한계를 파악하는 과정이 필수적입니다 [file:4].
이번 포스트에서는 고가용성(High Availability)을 확보하기 위한 전략과, 이를 검증하는 다양한 부하 테스트 기법을 소개합니다.
1. 고가용성(HA)과 SPOF
고가용성(High Availability)이란 서버나 네트워크가 오랜 기간 동안 지속적으로 정상 운영 가능한 성질을 말합니다. 흔히 “99.9% 가용성” 하는 식으로 표현하는데, 이는 1년 중 서비스가 중단되는 시간이 약 8.7시간 이내여야 함을 의미합니다. AWS의 SLA처럼 99.9999999%를 목표로 하기도 합니다 [file:4].
고가용성을 위협하는 가장 큰 적은 SPOF(Single Point Of Failure)입니다.
숨겨진 SPOF 찾기
SPOF라고 하면 보통 서버가 한 대만 떠 있는 물리적 구성을 생각하기 쉽습니다. 하지만 소프트웨어 레벨의 SPOF도 존재합니다.
- 잘못된 락(Lock) 사용: DB 리소스가 고갈되어 아무도 접속하지 못하는 상황.
- 외부 API 의존성: 타임아웃 설정 없이 외부 API를 호출하다가 스레드가 모두 잠식되는 상황.
이중화(Redundancy)나 서킷 브레이커(Circuit Breaker) 도입도 중요하지만, 부하 테스트를 통해 이러한 논리적인 병목 지점을 찾아내는 것이 선행되어야 합니다.
2. 부하 테스트의 목적과 지표
부하 테스트를 통해 확인해야 할 핵심 지표는 다음 3가지입니다 [file:4].
- 예상 TPS (Transaction Per Second): 초당 얼마나 많은 요청을 처리할 수 있는가?
- 응답 시간 (Response Time): 평균, 중간값, 그리고 상위 99%(P99)의 응답 속도는 얼마인가?
- 동시성 이슈: 다량의 트래픽이 몰릴 때 데이터 정합성이 깨지거나 데드락(Deadlock)이 발생하지 않는가?
3. 상황에 맞는 테스트 종류
부하 테스트는 목적에 따라 크게 4가지로 분류됩니다. 현업에서는 보통 Load Test와 Peak Test를 우선적으로 수행합니다 [file:4].
| 테스트 종류 | 설명 | 목적 |
|---|---|---|
| Load Test (부하 테스트) | 예상되는 평소 부하를 일정 시간 동안 주입 | 시스템이 목표 성능을 충족하는지 검증, 배포 스펙 산정 |
| Stress Test (스트레스 테스트) | 점진적으로 부하를 계속 증가시킴 | 시스템의 한계점(Breaking Point) 파악, 최대 수용량 확인 |
| Peak Test (최고 부하 테스트) | 순간적으로 임계치 이상의 부하를 ‘팍’ 하고 주입 | 선착순 이벤트 등 트래픽 폭주 상황(Spike) 대비 |
| Endurance Test (내구성 테스트) | 적정 부하를 장시간(수 시간~수 일) 지속 주입 | 메모리 누수(Memory Leak), 자원 반환 문제 등 장기 운영 시 문제 파악 |
4. 도구 선정 (Tools)
부하 테스트를 위한 다양한 도구가 존재합니다. 팀의 상황과 언어에 맞춰 선택하면 됩니다 [file:4].
- k6: Go 언어로 작성되었으나 스크립트는 JavaScript(ES6)를 사용합니다. 가볍고 성능이 뛰어나며, 시나리오 작성이 개발자 친화적이라 최근 많이 사용됩니다.
- JMeter: Java 기반의 전통적인 강자입니다. GUI가 제공되며 플러그인 생태계가 넓지만, 무겁고 스크립트 관리가(XML 기반) 다소 번거로울 수 있습니다.
- nGrinder: 네이버에서 만든 툴로, Groovy나 Jython을 사용하여 스크립트를 작성합니다. 에이전트 관리와 모니터링이 편리합니다.
- Artillery: Node.js 기반으로 클라우드 환경 테스트에 용이합니다.
5. 테스트 시나리오 설계 팁
무작정 API를 호출한다고 좋은 테스트가 아닙니다. 실제 유저의 행동 패턴을 모사해야 합니다.
- 데이터 준비: 수만 명의 유저가 동시에 쿠폰을 발급받는 상황이라면, 테스트 전에 수만 개의 유저 계정과 쿠폰 데이터를 미리 생성해두는 스크립트가 필요합니다 [file:4].
- 복합 시나리오: 단순히 ‘결제’만 테스트하지 말고,
로그인 → 상품 조회 → 장바구니 → 결제로 이어지는 유저 플로우를 구성해야 실제 병목을 찾을 수 있습니다.
결론
부하 테스트는 시스템을 괴롭히는 것이 아니라, 시스템의 체력을 키우는 훈련입니다. 이 과정을 통해 우리는 “이벤트 때 서버 터질까요?”라는 질문에 “아니요, 저희는 TPS 3,000까지는 거뜬합니다.”라고 자신 있게 말할 수 있게 됩니다.
다음 포스트에서는 이렇게 발견된 장애 상황을 실제로 어떻게 해결하고, 조직 차원에서 대응하는지 다루는 ‘장애 대응 시나리오와 회고 문화’에 대해 알아보겠습니다.