AWS EC2 Free Tier 기반 부하 테스트

토이 프로젝트를 진행하던 중 AWS의 EC2 Free Tier는 과연 어느정도 트래픽을 견딜 수 있을까? 라는 의문에서 시작해서 직접 부하 테스트를 진행하고 그 결과를 정리한 내용입니다.

목차

---

1. 프로젝트 개요
2. 프로젝트 준비
3. 프로젝트 수행
4. 프로젝트 결과
5. 제언

프로젝트 개요

---

• 목표:
• AWS EC2 Free Tier 인스턴스를 활용해 애플리케이션의 최대 안정적인 RPS(초당 처리할 수 있는 요청의 수)를 측정하고, 부하 분산 효과를 확인.
• 환경:
  • Backend: Java17 + Springboot 3.4
  • 인프라 구성: EC2 Free Tier 인스턴스 3개 + ALB
  • 부하 테스트 도구: k6(javascript)
• 주요 작업:
  • 부하 테스트를 통한 인스턴스 수에 따른 RPS 한계치 분석
  • ALB를 통한 분산 처리 효과 확인
  • 안정적인 RPS와 성능 개선 방안 도출

프로젝트 준비

---

Spring boot 애플리케이션 개발

평소 서버요청에 대한 응답처리에 걸리는 시간을 구현하기 위해 0~500ms 의 랜덤 지연시간을 생성하고, 해당시간동안 Sleep 이후 응답을 하도록 개발했다.

• 코드 저장소:
• Github | https://github.com/dev-jhjoo/TrafficServer

인프라 구축

ALB를 통해 인터넷에서 들어오는 요청을 퍼블릭 서브넷 내의 EC2 인스턴스들로 분배합니다. EC2는 모두 Free Tier로 구성했으며, Spring boot 프로젝트를 Docker 이미지로 빌드 후 EC2에 실행하는 방법으로 구현.

간단히 구현한 트래픽 분산 인프라 구조(alb + ec2 free tier * 3)

부하 테스트 도구 선정

Javascript 코드 기반으로 부하 테스트 진행가능한 K6라는 오픈소스를 사용. K6의 경우 Go 언어로 개발된 부하 테스트 오픈소스로서, Grafana Labs에서 제공.

• 공식링크:
• Web Page | https://k6.io/
• 코드저장소:
• Github | https://github.com/dev-jhjoo/traffic-monitor

프로젝트 수행

---

인스턴스 증가에 따른 분산환경에서의 처리량 분석

• 테스트 환경:
• { duration: '1s', target: 1000 }, // 1초 동안 1000명의 사용자 { duration: '1m', target: 10000 }, // 1분 동안 10000명의 사용자
• 결과:지표 인스턴스 1개 인스턴스 2개 (ALB 사용) 인스턴스 3개 (ALB 사용) 분석 및 개선 점

  총 요청 수	57,417 (631 RPS)	95,429 (1,048 RPS)	120,368 (1,322 RPS)	처리량이 인스턴스 수에 따라 선형적으로 증가.
  응답 실패율	4.04% (2,321 실패)	6.65% (6,347 실패)	5.34% (6,428 실패)	3개 인스턴스에서 실패율 감소 (분산 효과).
  평균 응답 시간	5.13초	1.16초	655ms	응답 시간이 크게 개선됨.
  95% 응답 시간	8.81초	2.76초	1.52초	응답 시간 분포가 안정적으로 감소.
  최대 응답 시간	15.57초	3.24초	1.86초	병목 구간(최대 응답 시간)도 줄어듦.
  데이터 전송량	9MB 받음 / 5MB 보냄	17MB 받음 / 11MB 보냄	21MB 받음 / 15MB 보냄	요청 처리량 증가에 따라 데이터 전송량도 증가.
  동시 사용자 (VUs)	최대 9,924	최대 9,906	최대 9,907	동시 사용자 수는 테스트 조건에서 동일.
  네트워크 대기 시간	2.62ms (최대 3.02초)	20.81ms (최대 11.03초)	15.71ms (최대 7.13초)	네트워크 대기 시간이 3개 인스턴스에서 감소.

스파이크, 점진적, 지속적 부하에 따른 처리량 분석

• 테스트 환경:

  { duration: '10s', target: 1000 }, // 10초 동안 1,000명
  { duration: '30s', target: 5000 }, // 30초 동안 5,000명
  { duration: '10s', target: 0 },    // 10초 동안 사용자 수 감소
  

  EC2 Free Tier 3대: 점진적 부하EC2 Free Tier 3대: 지속 부하
• { duration: '5m', target: 1000 }, // 5분 동안 1,000명 유지
• { duration: '10s', target: 100 }, // 10초 동안 100명 { duration: '20s', target: 500 }, // 20초 동안 500명 { duration: '30s', target: 1000 }, // 30초 동안 1,000명 { duration: '1m', target: 2000 }, // 1분 동안 2,000명 { duration: '1m', target: 3000 }, // 1분 동안 3,000명
• EC2 Free Tier 3대: 스파이크 부하
• 결과:지표 스파이크 부하 테스트 점진적 부하 테스트 지속 부하 테스트 분석 및 결론

  총 요청 수	53,504 (697 RPS)	161,358 (768 RPS)	100,320 (304 RPS)	요청 수와 RPS는 부하 패턴에 따라 다름.
  응답 실패율	5.65% (3,024 실패)	1.54% (2,499 실패)	0.84% (850 실패)	지속 부하에서 실패율이 가장 낮음.
  평균 응답 시간	249.17ms	257.89ms	260.05ms	모든 테스트에서 안정적으로 250ms 근처 유지.
  95% 응답 시간	488.48ms	486.68ms	486.98ms	모든 테스트에서 95% 응답 시간 < 500ms.
  최대 응답 시간	641.09ms	656.51ms	1.19s	최대 응답 시간은 지속 부하 테스트에서 가장 큼.
  데이터 전송량	9.4MB 받음 / 6.4MB 보냄	30MB 받음 / 20MB 보냄	19MB 받음 / 13MB 보냄	점진적 부하 테스트에서 가장 많은 데이터 처리.
  처리된 반복(iterations)	53,435	161,344	100,319	반복 횟수는 점진적 부하 테스트에서 가장 많음.
  동시 사용자 (VUs)	최대 4,963	최대 2,997	최대 999	부하 패턴에 따라 동시 사용자가 달라짐.

프로젝트 결과

---

인스턴스 증가에 따른 분산환경에서의 처리 결과

• 처리량:
• 인스턴스 1개에서 2개로 증설됨에 따라 요청 처리량이 약 1.66배 증가 (631 RPS → 1,048 RPS). 인스턴스 2개에서 3개로 증설될때는 요청 처리량이 약 1.26배 증가 (1,048 RPS → 1,322 RPS). 이를 통해 인스턴스 수에 따라 처리량이 선형적으로 증가하며, 분산 처리의 효과를 확인할 수 있었다.
• 응답 시간:
• 평균 응답 시간이 인스턴스가 늘어남에 따라 5.13초, 1.16초, 655ms로 안정적으로 감소하는 모습을 확인했다. 클라이언트 요청에 대해 분산처리의 효과를 직접적으로 확인 했다.

스파이크, 점진적, 지속적 부하에 따른 처리 결과

테스트 유형 최대 RPS 평균 응답 시간 95% 응답 시간 실패율 최대 안정 RPS

스파이크 부하	697	249ms	488ms	5.65%	약 600 RPS
점진적 부하	768	257ms	486ms	1.54%	약 750 RPS
지속 부하	304	260ms	486ms	0.84%	약 300~350 RPS

• 스파이크 부하: 순간적인 트래픽 급증에 비교적 잘 대응했지만, 실패율이 높아졌다.
• 점진적 부하: 동시 사용자 수와 요청이 점진적으로 증가했을 때 서버가 안정적으로 대응했다. 또한 실패율이 1.54%로 애초 생각했던 1%에 약간 미달하는 성능을 보였다.
• 지속적 부하: 장시간 일정한 부하에 대해서 실패율이 가장 낮았지만, 안정적으로 처리가능한 RPS도 낮았다.
• Free Tier 3개와 ALB로 구성된 환경에서 최대 안정 RPS: 600~750 RPS는 단기 부하에서 안정적으로 처리 가능하고, 300~350 RPS는 장기적인 안정성을 유지하며 처리 가능하다.

제언

---

이번 프로젝트를 통해 AWS EC2 Free Tier 인스턴스 3대와 ALB를 활용하여 분산처리에 다른 처리량 변화와 안정적인 RPS 수치를 확인했습니다. 이를 바탕으로 다음과 같이 제언합니다.

적정 RPS 활용 방안:

• Free Tier 3대와 ALB 환경에서는 600~750 RPS가 단기 부하에서 안정적으로 처리 가능하며, 장기적인 안정성을 고려할 경우 300~350 RPS로 운영하는 것이 적합 합니다.
• 트래픽 패턴이 일정하거나 예상 가능하다면, Auto Scaling 대신 정적으로 3개 인스턴스를 유지하여 비용 효율적인 운영이 가능합니다.

향후 확장성 확보:

• 인프라 업그레이드: EC2 Free Tier에서 T3.medium 이상의 인스턴스로 업그레이드 시 처리량이 2배 이상 증가할 것으로 예상되며, 기회가 된다면 검증하는 프로젝트를 진행해 보고 싶습니다.
• 캐싱 및 비동기 처리: Redis와 같은 캐싱 솔루션 도입과 비동기 처리 방식을 적용하면 응답 시간을 더욱 줄일 수 있을 것으로 사료됩니다.

테스트 자동화와 지속적인 성능 평가:

• k6 스크립트를 CI/CD 파이프라인에 통합하여 코드 변경 시마다 성능을 자동으로 검증하는 방식을 도입하는 방식도 고려해볼 수 있습니다.