1. 개요

품질 좋은 소프트웨어는 수많은 테스트 수행을 통해 제작됩니다. 그러나 외주 용역 사업이 대부분을 차지하는 국내 SW개발 환경에서 충분한 테스트를 보장하는 기간을 사업계획에 반영하기 어려운 것이 사실입니다. 이런 현실적인 이유로 공공정보화사업을 통해 구축된 웹사이트가 일부 만족할 만한 평가를 받지 못합니다. 

제작된 어플리케이션을 이용하는 사용자의 체감 성능을 향상시키고, 잠재적 성능 저하 요인을 제거하고, 사용자 증가에 따른 올바른 확장 전략 수립을 위해 어플리케이션의 성능점검은 무엇보다 중요합니다. GIS 분야가 아닌 모든 분야에 적용되는 공통사항으로써 본 글을 통해 필자가 적용하는 기법을 공유합니다. 완벽한 성능평가는 아니지만 웹을 통해 게시되는 어플리케이션에 일반적으로 적용될 수 있는 방법으로 제한된 기간을 극복하면서 사용자의 체감성능을 충분히 향상시킬 수 있습니다.

적용되는 성능평가는 크게 두부분으로 나누어 진행이 됩니다. 
첫번째는 서버와 클라이언트 사이의 요청/응답 성능 평가입니다. Apache JMeter를 이용합니다.
두번째는 서버로부터 응답이 도달한 후 클라이언트의 브라우저에 표시되는 부분의 성능평가 입니다. Google Page Insights를 이용합니다.

> 바로가기 : Apache JMeter
> 바로가기 : Google Page Insights

2. Apache JMeter를 이용한 서버, 네트워크 성능 평가

Geoserver를 통해 전개되는 WMS를 대상으로 성능평가를 진행합니다.

이 후 실행되는 Apache JMeter 성능 평가는 다음의 URL을 테스트 합니다. 테스트 환경에 따라 클라이언트에 도달하는 시간에 차이가 있겠으나 필자의 네트워크 환경에서 단건 기준 약 0.2초내에 응답이 완료되고 있습니다.

http://1.250.62.223:8180/geoserver/progworks/wms?service=WMS&version=1.1.0&request=GetMap&layers=progworks:group_uq&bbox=126.9092,37.4978,126.9689,37.5437&width=700&height=500&srs=EPSG:4326&format=image/png 


2.1 성능평가 준비 및 설정

Apache JMeter의 설치 및 기본 사용은 인터넷에 좋은 자료가 많이 있습니다. 별도 설명하지 않겠습니다. 간단한 아래 그림을 참고하십시오. 아래 그림의 Thread Group을 통해 사용자(요청) 개수, 반복횟수(Loop Count), 실행통제시간(Ramp-up period) 을 지정하고
HTTP Request 를 통해 성능평가 대상 WMS의 서버 및 입력파라미터를 설정하면 Test Listener를 통해 결과 값을 확인합니다.


2.2 사용자 수용 능력 평가
예측되는 전체 쓰레드 갯수( 사용자 요청 갯수) 가 지정된 시간 내에 실행되는지 여부를 평가합니다. 쉽게 말하면 사이트의 특정 페이지에 1분에 60번의 요청을 처리하는 것이 목표라면, 
Apache JMeter의 Thread Group에서 1분(Ramp-Up Period)에 60번의 요청(Number of Threads)을 처리하는 것을 테스트하면 됩니다.
또는 Thread Group에서 Ramp-Up Period : 1분, Number of Threads: 6, Loop Count: 10 으로 설정해도 됩니다. 차이점은 전자의 경우 1초에 한 번씩 60개의 요청이 수행이 되고, 후자의 경우 6개의 요청이 동시에 이루어지고 10초간격으로 1분간 반복이 됩니다.

위의 첨부 그림의 분당 60개의 요청처리는 실제 테스트 결과로 반영하기에는 무리가 있습니다. 실제 필드에 적용하는 경우라면 피크타임의 전체 시간(1시간, 2시간 등)을 Ramp-up Period로 설정한 후 실행 쓰레드 개수를 지정해야 할 것입니다. 
위 시험의 목표는 사이트 구축 시 수용하고자 하는 사용자 수를 계량화하고, 목표로 하는 시간 내에 해당 사용자의 요청을 처리하는지 점검합니다. 


2.3 과부하 점검

사용자를 지속적으로 증가시켜 개별 응답이 지정된 시간 내에 응답하는지 여부를 평가합니다. 쉽게 말해 개별 요청의 처리 제한 시간이 1초일 경우 1초에 응답할 수 있는 동시요청개수를 찾는 것입니다. 이를 통해 테스트 대상 서버의 물리적 수용한계점을 찾을 수 있고 시스템 확장이 필요한 기준을 수립할 수 있습니다.
과부하 점검에서 Ramp-Up Period는 크게 의미 없습니다.
필자의 경우 Loop Count를 10, 20 등으로 고정하고 Number Of Threads의 갯수를 1, 5, 10, 15, 20, 30 과 같은 형식으로 지속적으로 늘려가며 테스트를 수행합니다. 만일 개별 요청의 응답 제한 시간이 1초라고 할 때 Number Of Threads 개수가 얼마일 때 응답제한시간을 초과하는지 측정하고, 실제 처리되는 초당 Throughput이 언제 감소하는지를 살펴봅니다.

위의 테스트 결과 예시는 동시 사용자를 30명, 40명, 50명 지정하고 각 10회씩 동시 요청한 후 결과 값을 표시합니다.
먼저 평균응답시간을 살펴보면 동시 사용자 30일 때 1초 내에 있었으나 40명일 경우 1초를 초과하고 있습니다. 50명일 경우 거의 2초에 가까운 평균응답시간을 보여주고 있습니다. Throuhput을 보면 3명일 경우 초당 37건을 처리하고 있으나 40명일 경우 오히려 초당 35건으로 처리 능력이 떨어짐을 알 수 있습니다.

일반적으로 잘 짜여진 코드라고 하면 동시 사용자 증가에 따라 평균응답시간은 선형으로 지속적으로 증가합니다. 증가하는 평균응답시간이 제한된 시간을 넘어서는 경우, 사용자 증가 시점에 따라 Throughput이 오히려 감소하는 경우는 테스트 대상 서버가 한계치에 도달한 경우입니다.
주의할 점은 과부하 테스트 시 필수적으로 테스트 계통에 걸치는 서버 자원을 모니터링 해야 합니다.

만일 WAS 자원은 여유가 있는데, DBMS 자원에 여유가 없다면 DBMS의 확장(수직확장 우선)이 우선적으로 고려되어야 합니다.
DBMS는 안정적이나 WAS 자원에 여유가 없다면 WAS의 확장(수평확장 우선)이 우선적으로 고려되어야 합니다. 드문 경우이긴 하지만 모든 자원은 여유가 있는 상태인데 사용자의 증가에 따라 전송되는 패킷(Received Byte)량이 증가하지 않는다면, 테스트 서버와 연결되는 네트워크 설정 점검 또는 증설이 요구됩니다.


3. Google Page Insights를 이용한 페이지 최적화

서버가 충분한 성능을 발휘하고 있는데 실제 브라우저에 표출이 늦다면 웹 페이지 레벨의 최적화가 요구됩니다. 필자가 애용하는 방법은 첫 번째 구글 개발자 도구를 이용하여 페이지의 로딩속도를 점검하고 그 시간이 늦는 경우 페이지와 함께 전송되는 리소스 등을 점검합니다. 이 때 이용하는 것이 "Goolge Page Insights"입니다.
서버 성능 점검은 개별페이지를 테스트하지 실제 브라우저 표출의 대상이 되는 JS, CSS 등 리소스에 대한 다운로드는 포함하지 않습니다. 따라서 성능점검 시 꼭 페이지 표출 속도도 점검해야 합니다.

Google Page Insights는 친절하게도 어떤 방식으로 수정해야하는지 친절히 알려줍니다. 단순한 수고가 서비스의 만족도를 높인다면 보람있는 일입니다.
위의 예시는 국가공간정보포털 오픈마켓을 측정한 것으로 평균정도의 응답속도를 보이고 있습니다.

4. 맺음말

제가 겪어본 바에 의하면 공간정보분야 공공 부문 서비스에 대한 평판이 그리 좋은 편은 아닙니다. 오직 국가정보화사업을 통해 먹고사는 공간정보업체는 특히 더욱 성능부분에 충실할 필요가 있습니다. 비교적 영세한 업체로 이루어진 산업계의 특성상 아키텍처그룹, PM 그룹을 별도로 운영할 수 없는 형편도 이해하지만 정보화사업이 아니면 망할 수 밖에 없는 형편에서 고객이 만족할 수 있도록 더욱 노력해야 합니다. 전 고객이 떠나는 것이 두렵습니다.

마지막으로 프로그웍스는 앞장 서서 테스트를 철저히 하겠음을 다짐하며 마무리 합니다.

+ Recent posts