목표
사이드 프로젝트를 진행하며 Infra 구축부터 개발까지 진행을 하고 있습니다.
현재 서비스 런칭전 운영중인 서버에서(현재 단일서버) 목표하는 서비스 지표를 설정하고 목표를 향해가는 과정을 기록하고자 합니다.
Postman으로 요청한 먼저 간단한 API의 1회 응답시간은 다음과 같습니다.
제일 많이 걸리는 시간은 DNS Lookup으로 사용자 Device, Browser 에서 DNS 가 캐싱된다면 이를 제외한 실제 서버 지연시간은 200ms 정도 입니다.
강력한 트랜잭션이 필요한 API 가 아닌 일반적인 API 기준 으로 크게 성능적 지표와 가용성 지표로 나누어 봤습니다.
- 1주일 기준으로 사용자는 99% 사용할 수 있어야 한다.
- 동시 API 요청은 초당 500건 처리가 가능해야 한다.
- 서버 Laytency 는 1s 미만이 되어야 한다.
성능 테스트
환경
cpu: 4 core 4 thread(hyper threading X)
memory: 16GB
gateway, target 은 webflux 환경
평소 사용량
cpu: 30%
memory: 67%
테스트 목적
관심사를 묶어주는 Spring Cloud Gateway 가 추가 되며 Network Hop 이 추가 와 현재 서버 에서 사용하는 리소스가 성능 수준에 영향을 얼마나 미치는지 확인하기 위함
Test 시나리오
1000개의 동시 요청 후
500개의 동시 요청이 Spike 로 발생
서비스 목표의 2배의 요청이 온 뒤 다시 목표의 요청이 왔을때 안정성이 얼마나 유지 되는지 확인하기 위해 위와같이 시나리오를 설정 하였습니다.
1000 요청
gateway
target
현재 테스트 케이스는 CPU Intensive 한 작업보단 I/O Intensive 한 작업이 대부분이기에 cpu 사용량이 낮을거라 예상 했습니다.
22:50:15 : traefik -> scg
22:50:30 : scg -> target
file discriptor 가 생성되어 Socket 통신을 위해 API Gateway, Target Server 에서 file 이 열리고(실질 적인 네트워크 통신이 이뤄진 다음) cpu 사용량이 급격히 올라가는 것을 확인 할 수 있습니다.
500 요청 비교
Gateway
Computer instance
Gateway
Target Server
Direct
Computer instance
Target Server
결론
-
API Gateway 가 영향이 있는가?
cpu 사용량 자체는 유의미한 차이를 보여줬습니다. 하지만 현재 상태에선 도입 했을때 서버내부에서 통신하기에 hop 추가로 인해 처리량 측면에선 유의미한 차이를 확인하지 못했습니다.
cpu 자원이 부족한 상황이라 고민되는 부분 이지만 현재 배포되어 있는 서비스는 4개가 실행중이고 이런부분들을 webserver 수준에서 라우팅을 하는것보다 공통된 로직들을 처리하는 Gateway를 처리하는것이 프로젝트 관점에서 생산성을 높이고, throttling 처리를 통해 극복할 수 있는 수준이라 생각하기에 현 상태로는 채택하는 것도 적절 하다 생각합니다. -
성능개선 해야할 점은?
현재 확인할수 있는 정보는 file 이 Open 될때 cpu 가 많이 사용된 다는것을 알 수 있습니다.
http2.0 프로토콜인 Grpc 를 활용한다면 open file을 최적화 할 수 있고, 사용자정보가 담긴 header 의 압축을 통해 리소스를 더 절하여 유의미한 성능 개선을 할 수 있겠다는 생각이 들어 내부 서비스간의 통신은 Grpc 로 변경하고 gateway 를 통해 json -> grpc 로 변경하는 과정의 Overhead 를 테스트 해보고자 합니다. -
이정도면 괜찮은가?
지금 정보만으론 추측성으로 성능개선을 할 수 밖에 없습니다. 좀 더 세부적인 지표를 확인하기 위해 Async profiler 를 설치하여 더 디테일한 정보를 얻어야 유의미한 테스트 케이스를 작성할 수 있겠다고 생각이 들었습니다.
