Cloud Run을 이용하여 띄워 놓은 서비스가 운영단계로 접어들면서 테스트가 진행되었고, Response Time이 1초 미만이어야 한다는 클라이언트 측 요구 사항에 맞춰야한다.. 그래서 동접수와 API 호출수에 따라 서버가 버틸 수있는 상태를 기록하기 위해 부하 테스트를 진행하였다.
google에 나와있는 권장사항에 맞추어 Jmeter로 부하 테스트를 진행하였다.
부하 테스트 권장사항 | Cloud Run Documentation | Google Cloud
의견 보내기 부하 테스트 권장사항 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. 이 페이지에서는 Cloud Run 서비스의 부하 테스트를 통해 프로덕션 사용 중
cloud.google.com
JMeter 설치는 1분이면 가능하다!
압축을 풀면 bin 폴더에 jmeter.sh 파일과 jmeter.bat 파일이 있습니다.
맥에선 sh파일로, 윈도우에선 bat파일을 실행하면 됩니다.
Jmeter의 주요 구성 요소들을 간단히 살펴보자!
Thread Group은 쓰레드들을 관리하는 곳. 여기에서 쓰레드 수, 즉 가상의 사용자 수를 설정할 수 있음
1000명의 사용자가 동시에 접속한다 라는 테스트 환경을 쓰레드 그룹에서 쓰레드 숫자를 조정함으로써 설정!
두번째 줄 첫번째에 있는 Samplers는 요청을 추상화한 것, FTP, HTTP, SMPT 등 다양한 요청 유형을 선택.
두번째 줄 두번째에 있는 Logic Controller는 요청들을 묶어서 시나리오화한 것. 가령 하나의 Logic Controller에 여러 HTTP 요청 Samplers들을 순차적으로 담음으로써 사용자의 실제 사용 예상 시나리오와 유사하게 테스트 환경을 구성할 수 있음.
두번째줄 세번째에 있는 Listeners는 테스트 결과를 추상화 한것임. 그래프, 테이블 등 여러 형태로 테스트 결과를 시각화.
두번째줄 네번째의 Configuration Elements 는 테스트 환경에 적용될 것을 설정. 가령 HTTP 요청 Sampler를 이용한 테스트를 할 때, 헤더에 토큰을 담거나, 쿠키에 세션을 담음으로써 로그인된 사용자의 요청으로 만들기 위한 쿠키, 헤더 값을 설정할 수 있음.
테스트 환경에 사용되는 주요한 요소들에 대해서만 알아봤습니다. 앞서 언급한 Thread Group, Samples, Logic Controllers, Listeners, Congiruation Elements 등을 모두 JMeter 내에선 Element라고 부릅니다.
> 테스트 환경 생성
File -> New -> Test Plan Name 설정
1. Thread Group
테스트할 유저 수를 설정. 생성한 테스트에 오른쪽 클릭 -> Add -> Threads (Users) -> Thread Group
- Number of Threads: 몇 개의 쓰레드(유저 수)로 테스트할 지
- Ramp-up period: {Number of Thread} 만큼의 쓰레드를 몇초에 걸쳐서 만들 지
- Loop Count: 요청을 몇번을 반복할 지
2. Sampler
사용자를 만들었으니 이제 사용자가 해야 할 행동을 정의. 1에서 만든 Thread Group 우클릭 -> Add -> Sampler -> HTTP Request 클릭
3. Listener
위에서 만든 Sampler가 받아오는 리턴 값을 바탕으로 그래프, 레포팅을 만들어주는 Listener를 생성. 2에서 만든 HTTP Request에 오른쪽 클릭 -> Add -> Listener -> View Results Tree, Summary Report, View Results in Table 생성
이렇게 Jmeter의 사용법에 대해 자세히 알아보았다.
이제 Cloud Run 서버에 직접 호출을 하여 나의 서비스가 동시 호출 수 상황에 따라 Response Time이 어느정도의 delay가 발생하는지 테스트를 해보자!
* user: 500명 / ramp-up period : 30 / loop count: 15
* CPU 1Core, Memory = 1GB, 최소 인스턴스 = 5
(API 자체 복잡한 로직은 없어 메모리 용량에 따른 성능 변화는 없었다. cpu 코어 수를 늘릴경어 동시에 처리 할 수 있는 양은 늘어나지만 비용이 두배라 확장성을 고려하여 1Core 기준으로 테스트를 진행하였다.)
(1)동시 호출 수: 50 제한
(2)동시 호출 수: 70 제한
(2)동시 호출 수: 100 제한
실제로 1개의 인스턴스에서 최대 동시 요청 수가 70이 넘어가게 되면 reponse time이 최대 1.8초~2초까지 발생하는 것을 확인!
이렇게 테스트 과정을 진행하면서 1개의 인스턴스가 받을 수 있는 최대 동시 요청 수를 계산하였다.
어떤 로직을 가지고 있는 서비스인지, 상황 별로 다 다르겠지만 기준을 정하여 1개의 인스턴스가 처리 할 수 있는 최대 동시 요청 수의 설정을 높여가면서 최적의 조건을 찾아가는 과정이 필요하다.
궁금한 사항 있으면 댓글 주세요! 감사합니다.
출처
'Server & Infra' 카테고리의 다른 글
| [CI/CD] Github Action 시작하기 - Docker Hub, Slack 연동 (0) | 2025.04.08 |
|---|---|
| [CORS] 프론트와 백엔드 서버의 분리 환경 속 에서 발생한.. (0) | 2025.01.21 |