[6팀 ark - 커넥트립] Next.js API 스트레스 테스트 시나리오

[sen2y]

목표

Next.js로 구축된 API의 내결함성을 테스트하기 위해 스트레스 테스트를 진행합니다. 특히, 많은 유저가 동시에 위치 전송 버튼을 누르고, 이를 통해 발생하는 GET 요청이 서버에 얼마나 많은 부하를 주는지 측정합니다.
유저 수가 초당 10명씩 점진적으로 증가하는 시나리오를 통해 Context Switching과 같은 성능 저하 문제를 확인합니다. 유저가 증가함에 따라 서버 자원이 어떻게 반응하는지, 그리고 소켓을 통한 위치 전송 API 요청이 늘어날 때 성능 병목이 발생하는지 확인합니다.

🛠️ 테스트 시나리오 개요

테스트 시나리오 흐름

1. 대량의 유저 접속: 여러 유저가 한 채팅방에 동시에 접속.
2. 위치 전송 버튼 클릭: 모든 유저가 동시에 위치 전송 버튼을 눌러, API 요청을 발생시킴.
3. 스크랩 요청 발생: 각 유저가 전송하는 위치 정보는 개별 유저의 닉네임과 위도, 경도 값으로 변환되어, GET /api/scrape?url=... 요청이 서버로 전송됨.
4. API 응답 성능 측정: 서버는 각각의 요청을 처리하며, 응답 속도와 시스템 성능을 측정.
5. 부하 증가에 따른 서버 상태 관찰: 점점 증가하는 트래픽 속에서 서버의 CPU, 메모리, 네트워크 등의 자원 사용률을 분석.
6. TPS(초당 처리량) 측정: 각 요청에 대한 처리량(TPS)을 측정하여 서버가 얼마나 많은 요청을 처리할 수 있는지 확인.

🎯 측정 목표

• 서버 성능 측정: 점진적으로 유저 수가 증가하는 상황에서 서버가 얼마나 안정적으로 처리할 수 있는지 확인하고, 서버가 많은 유저의 요청을 처리하는 능력을 측정.
• Context Switching 관찰: 트래픽이 급증할 때 서버의 CPU 스케줄링 및 Context Switching에 따른 성능 변화 측정.
• TPS(초당 처리량): 초당 처리할 수 있는 요청의 개수를 측정.
• 응답 시간 측정: 각 요청에 대한 응답 시간이 얼마인지 측정.
• 병목 지점 확인: 트래픽이 늘어날수록 발생하는 병목 구간을 확인.
• 서버 안정성 확인: 서버가 대량의 소켓 연결 및 HTTP 요청을 처리할 때의 안정성 평가.

⚙️ 테스트 환경

• 테스트 도구: JMeter
• 테스트 대상 API: GET /api/scrape
• 테스트 대상 URL: 유저의 닉네임과 위치에 따라 동적으로 변경
  • 예시: https://map.kakao.com/link/map/{닉네임},{위도},{경도}
• 유저 시뮬레이션: 1,000명 이상의 유저가 하나의 채팅방 내에서 점진적으로 증가되며 위치 전송 버튼을 클릭하여 API 요청을 발생시킴.
• 테스트 유형: 스트레스 테스트

📝 테스트 시나리오

1. 점진적 부하 테스트

🟢 점진적 부하 테스트 시나리오

• 테스트 시작 시 10명의 유저가 채팅방에 접속.
• 매 초마다 10명씩 추가로 접속.
• 각 유저는 자신의 닉네임과 위치(위도, 경도) 정보를 포함한 위치 전송 버튼을 클릭하여 요청을 전송.
• 요청 예시:
  • GET /api/scrape?url=https%3A%2F%2Fmap.kakao.com%2Flink%2Fmap%2F{유저닉네임},33.4875083,126.5319013

목표

• 유저 수가 점진적으로 증가함에 따라 서버의 성능 변화 확인.
• Context Switching으로 인한 성능 저하 여부 확인.
• 초당 처리량(TPS) 변화 측정.
• CPU, 메모리, 네트워크 사용량 증가 추세 분석.

테스트 계획

• 초당 유저 증가 수: 10명
• 최대 유저 수: 1,000명
• 테스트 시간: 총 100초 (1,000명이 도달할 때까지)
• 요청 빈도: 각 유저당 1초에 1번 요청 (최대 1,000 TPS)

🧪 테스트 단계별 예상

1. 초기 단계

• 유저 수: 10명부터 시작
• 처리량: 초기에는 낮은 TPS로 시작, 서버 자원은 여유로움
• 목표: 서버가 정상적으로 응답하고 있는지 확인

2. 점진적 유저 증가

• 유저 수: 초당 10명씩 증가, 100초 후에는 1,000명의 유저가 동시에 요청을 보냄
• 처리량: TPS가 점진적으로 증가, 초당 최대 1,000 TPS까지 도달
• 목표: 서버가 증가하는 요청을 어떻게 처리하는지 확인 (성능 병목 및 응답 시간 증가 여부)

3. Context Switching 확인

• 유저 수: 중간 구간(약 500명)에서 CPU 스케줄링으로 인한 Context Switching 발생 가능성 관찰
• 목표: CPU 사용률 및 Context Switching 빈도 증가에 따른 서버 반응 확인

4. 최대 부하 도달

• 유저 수: 1,000명 도달
• 처리량: 초당 1,000 TPS 도달
• 목표: 서버가 최대 부하에서 안정적으로 작동하는지, 또는 병목 발생 여부 확인

2. 장기 스트레스 테스트

🟠 장기 스트레스 테스트

• 1,000명의 유저가 일정 시간 동안 위치 전송 버튼을 반복적으로 클릭.
• 10분 동안 각 유저가 1초에 한 번씩 요청을 전송.
• API 요청:
  • GET /api/scrape?url=https%3A%2F%2Fmap.kakao.com%2Flink%2Fmap%2F%EC%84%B8%EB%8B%88%EC%96%8C%2C33.4875083%2C126.5319013

목표

• 장시간 동안 서버의 성능 저하 여부 확인.
• 메모리 누수, CPU 사용량 증가 등 장기적인 문제 확인.
• 장기적으로 서버가 안정적으로 요청을 처리하는지 확인.

테스트 계획

• 유저 수: 1,000명
• 시나리오: 유저당 1초에 한 번씩 요청을 전송, 총 10분 동안 지속.
• 요청 빈도: 10분 동안 1초에 1,000개의 요청 (총 600,000개 요청)

📊 테스트 데이터 수집 항목

• TPS(초당 처리량): 서버가 초당 얼마나 많은 요청을 처리하는지 확인.
• CPU 사용률: 서버 CPU의 사용률을 체크하여 과부하 여부 확인.
• Context Switching 빈도: CPU의 Context Switching 발생 빈도 측정.
• 메모리 사용량: 메모리 사용량이 안정적인지, 혹은 과도한 메모리 사용으로 인해 문제가 발생하는지 확인.
• 응답 시간: 요청이 서버에 도달하고 응답이 돌아오기까지의 시간 측정.
• 에러율: 요청 중 에러가 발생한 비율 측정.
• 네트워크 사용량: 요청 처리에 따른 네트워크 사용량을 측정하여 병목 현상 분석.

결론

이 테스트는 대규모 유저가 채팅방에 접속하여 위치 전송 버튼을 지속적으로 누르며 발생하는 부하 상황을 시뮬레이션합니다. 서버의 처리 능력을 측정하고, 성능 병목 구간을 확인함으로써 서버가 안정적으로 대규모 트래픽을 처리할 수 있는지 평가하는 것이 목표입니다.

---

예상 흐름