이번주 월, 화는 Docker와 Jenkins을 배웠습니다.
Jenkins를 통해서 자동화 되는 과정들은 매우 편리했습니다.
수요일과 목요일은 Devops team project를 했습니다.
Docker
- nginx routing: URL PATH 에 따라 다른 서비스로 라우팅(A, B)
Jenkins
- install jenkins
- docker build & deploy with jenkins
- springboot build & run
👁🗨 Devops team project
요구사항
- SPRING-BOOT APP-SERVER 준비
- NGINX PROXY 서버는 모든 사용자 요청을 받아 APP-SERVER 로 전단 중계하는 대리자 PROXY 역할을 하도록 구성
- 기본 NGINX 설정으로 최대 TPS 를 도출한다.
최대 TPS 의 기준은 (a) 에러가 없는 상태에서(100개 미만) (b) 평균응답속도가 초기 대비 1.2 배 상승하지 않는 범위 안에서 (b) 5분간 유지 - 테스트 환경 구성은 여러대의 컴퓨터를 네트워크로 연결하여 구성하며 각각 구성은 아래와 같음
- nGrinder Controller - 1ea
- nGrinder Agent - 1 ~ 2 ea
- nginx proxy - 1ea
- App Server & DB server- 1ea- 공식 가이드를 참조하여 proxy 단의 캐싱을 적용하여 성능을 개선하고, 개선 전후를 비교하는 결과 리포트를 생성
저희 팀원은 4명으로, 각 nGrinder Controller, nGrinder Agent, nginx proxy, App Server & DB server을 담당했습니다.
😊 좋았던 점
- 데브옵스 프로젝트에 Spring 프로젝트 결과물을 활용한 부분이 재미있었습니다. 팀원들 모두 다른 프로젝트의 팀원이였기 때문에, 선택한 프로젝트를 담당했던 팀원이 App Server & DB server을 담당했습니다.
- PROXY CACHING와 부하테스트, 그리고 포트포워딩에 대해서 프로젝트를 하면서 많은 공부가 되었습니다.
😡 아쉬운 점
- NGRINDER 컨트롤러와 에이전트 간의 통신문제를 해결하는 것에 반나절 이상을 쓰면서 캐싱에 들어갈 시간이 부족했다.
- 캐싱을 적용하면 당연히 성능이 좋아질 줄 알았는데, 같은 조건에서 정상적으로 테스트 되던 케이스가, 기본 캐싱을 적용한 이후 에러로 중단되어 어려움을 겪었다.
- 시간적 여유가 부족해 다양한 조건들을 모두 적용해보며 최적의 캐싱을 찾지 못한게 아쉬웠다.
- 하나의 PC에서 진행한 테스트의 경우에는 CPU, 메모리가 100%를 넘어가는 것을 원인으로 중단이 되었는데, 여러 PC에서 테스트를 진행한 경우 CPU, 메모리의 사용률이 높지 않았음에도 에러로 테스트가 중단되었다.
- 사실 결론적으로 프로젝트 요구사항 중 캐싱 부분에 대해서는 실패한 프로젝트였다고 생각합니다.
📖 배운 점
- NGRINDER 컨트롤러 - 에이전트 통신문제
핵심: 컴퓨터간 통신에서는 윈도우 네트워크로 서로 접속하고, 그 안에서 터널링(포트 포워딩) 연결
1) window 터미널에서 netsh로 포트 포워딩
2) agent 설정파일에서 컨트롤러 포트 설정: 공식 가이드 참조 - nGrinder 실행 시, 호환되는 JAVA version 반드시 확인 필요.
- 캐싱 path를 설정할 때, 공식가이드 경로에 따라 설정하기 전에, 해당 경로가 있는지 확인 후 경로를 설정해야 한다.
Navigating Developer