` nGRINDER_TEAM_PROJECT

ngrinder를 활용한 scale 조정에 따른 web server 부하 테스트

✔️ Nginx와 Apache HTTPD를 활용하여 Web Server에 load balancing 구현
✔️ Ngrinder를 활용하여 Web Server에 대한 Scale up&down 또는 in&out을 통해 부하 테스트를 진행하며 최적 환경 탐색

Architecture

Project Description

1. Web Server 구축하기

1-1. Apache HTTPD

    - webpage를 구현해놓은 git repository를 clone 후 해당 page를 띄우기
     - crontab을 활용하여 매분마다 git pull 실행하여 변경사항을 주기적으로 갱신

1-2. Load Balancing

    - httpd server를 n개 구축 후 nginx를 로드 밸런서로 활용하여 n개의 server에 대한 로드 밸런싱 구현

2. Scale UP & DOWN

     - httpd server의 cpu/memory 리소스를 제한하여 진행

3. Scale IN & OUT

     - httpd server의 수를 조정하여 진행

4. nGrinder Test Environment

     - vuser 3,000
     - process 10, thread 300
     - thread로 ramp up
     - initial count 0, incremental step 1
     - initial sleep time 10초, interval 1초, grinder.sleep 1초
     - duration 6분

nGrinder Test Result

✔️ Test Run & Error


  • httpd 의 cpu와 memory를 변수로 9번의 테스트를 시도, 그 중 8번의 테스트 실행
  • 모두 약 2분 전후를 기점으로 'too many errors'로 중단
  • 표에 대한 추가 설명

    • - executed : 실행된 전체 테스트의 수
    - succesful : executed 중 성공한 테스트의 수
    - error count : executed 중 에러난 테스트의 수
    - error rate : executed 중 에러난 테스트의 비율
    - error time : 첫 에러가 발생한 시간 (첫 에러 발생 이후 점차 에러가 증가하는 추세이므로 첫 발생 지점을 기록)

  • 타겟 페이지의 용량이 5.8m 인 것을 고려하여 메모리 최소는 5.8 로 잡고 테스트를 시도하였으나, 웹서버 자체가 올라가지 않아 테스트 실행 불가
  • 이 점을 미루어 보아, 컨테이너가 뜨는 데에도 최소한의 메모리가 있을 것이라고 판단
  • 이에 메모리의 변화에 따른 퍼포먼스를 확인하기 위해 cpu는 0.01 으로 고정 후, 64m 을 시작으로 32m, 16m 으로 점차 scale down 진행
  • 이번에는 cpu 의 영향을 확인하기 위해 메모리는 64m 으로 고정 후, cpu 는 0.01 을 최소로 잡고 0.1,0.2,0.5 으로 점차 scale up 진행
  • error rate는 cpu가 증가함에 따라 미비하나 감소하는 추세를 확인
  • 반면, 첫 에러가 나타나는 error time은 점차 앞당겨지며 run time 은 점차 짧아지는 것을 확인
  • 앞선 테스트에서 명확한 memory와 cpu의 영향도가 파악이 되지 않아 cpu와 memory를 상대적으로 극단적으로 변동된 큰값으로 설정
  • error rate는 낮은 값이 나온 듯 하나, error time 은 매우 앞당겨졌으며, run time은 별다른 증가 추세를 보이지않음

✔️ Test 성능 지표 : tps, mtt, errors

  • tps는 달리한 조건에 따라 상이한 그림을 보이지 않고 전반적으로 요동치는 것을 미루어보아, tps 로 성능을 판단하기에 적합하지 않다고 판단
  • mtt 는 vuser 가 늘어감에 따라 점차 증가하는 추세이고 errors 는 대략 1분40초 기점으로 증가하다 2분 전후로 중단되는 추세를 공통적으로 보이고 있기에 error 가 처음 발생하는 지점을 뒤로 늦추고 전체적인 에러율을 낮추거나 mtt 의 최고점을 낮춰보는 식으로 성능 튜닝이 진행되면 보다 유의미한 결과를 볼 수 있을 것으로 판단
  1. server:2 blog_cpu: 0.01 blog_mem: 64
  2. server:2 blog_cpu: 0.01 blog_mem: 32
  3. server:2 blog_cpu: 0.01 blog_mem: 32
  4. server:2 blog_cpu: 0.01 blog_mem: 16
  5. server:2 blog_cpu: 0.1 blog_mem: 64
  6. server: 2 blog_cpu: 0.2 blog_mem: 64
  7. server: 2 blog_cpu: 0.5 blog_mem: 64
  8. server: 2 blog_cpu: 0.5 blog_mem: 1024

💪 향후 보완점

  • 웹서버 구성 변경
    •   - httpd server scale out
      - nginx server에 대한 cpu, memory limit test
  • 웹서버 머신 htop과 docker stat 비교
  • 로드밸런서와 웹서버 어느 곳의 리소스가 더 필요할지 확인
  • 웹서버 머신 자체의 리소스 부족은 없을지
  • 웹서버 머신 변경 : 웹서버를 클라우드 환경에서 띄어보거나 다른 pc 로 바꿔볼 것
  • 캐싱 추가
    •   - nginx, httpd 서버에 추가적인 설정을 하면 성능이 더 좋아질까