제공 : 한빛 네트워크
저자 : 박성훈, 류성곤, 이원영
원문 : 프로젝트 성공을 결정짓는 성능 시험 방법론과 실무 5장 내용 중에서
[이전 기사 보기]
성능 시험 방법론 - Workload 분석(1)
3. 웹 기반 시스템하에서의 Workload 분석
웹 기반 시스템의 경우 HTTP 프로토콜의 Connectionless 특성 상 Workload를 분석하는데 다소 어려움이 따릅니다. 통상적으로 컴퓨터 시스템의 동시 사용자 수는 클라이언트와 서버 사이의 네트워크 연결(Connection) 개수를 측정하여 구하는데, 웹 기반 시스템의 경우에는 이런 방식으로 구하는 것이 불가능합니다.
즉, 웹 기반 시스템에서는 사용자가 웹 서버로 요청을 보내게 되면 사용자 PC와 웹 서버 사이에 네트워크 연결이 생성된 후 처리가 시작되는데, 이 때 생성된 네트워크 연결은 웹 서버가 해당 결과 내용을 사용자 PC로 전송을 한 후에 끊어지게 됩니다(실제로는 웹 서버에 설정되어 있는 Keep Alive Timeout 시간 동안 대기한 후 추가 요청이 없을 경우에 끊어집니다). 그러므로 동일 사용자가 또 다른 요청을 보내게 되면 기존 네트워크 연결은 이미 끊어지고 없기 때문에 새로운 네트워크 연결을 생성한 다음 위의 과정을 반복하게 됩니다.
또한, 웹 기반 시스템에서는 한 화면에서 여러 정보들을 함께 보여주기 위해서 화면을 논리적으로 분할하는 프레임(FRAME, IFRAME) 기법이나 현재 화면에서 다른 화면으로 자동으로 전환시켜 주는 페이지 전환(Forward, Redirect) 기법 그리고 사용자에게 정적 페이지를 제공하는 정적 컨텐츠(HTML, GIF, JPG, CSS)와 사용자가 원하는 정보를 동적으로 구성하여 동적 페이지를 제공하는 동적 컨텐츠(ASP, JSP, Servlet, PHP) 기술을 함께 사용하여 구성할 수 있기 때문에 한 사
용자에 의한 호출(Request)을 정의할 때 어느 범위까지 결정할 것인지에 대하여 이견이 발생하기도 합니다.
이와 같은 웹 기반 시스템의 복잡성으로 인해 현재까지도 웹 환경하에서의 표준화된 Workload 분석 방법은 제시되지 못하고 있는 실정이며, 우리는 이러한 현실을 극복하기 위해서 다년간의 실무적인 경험을 통해서 웹 환경하에서의 Workload 분석 방법을 자체적으로 개발하게 되었습니다.
다음 소개되는 내용은 웹 환경하에서의 Workload 분석 방법에 대해서 간략히 소개하고 있습니다.
동시 사용자 산정 방안
앞에서 소개한 것과 같이 웹 기반 시스템의 경우 클라이언트와 서버 사이의 네트워크 연결 개수를 측정하여 동시 사용자 수를 구하는 것은 불가능한데, 이에 대한 대안 책으로 웹 서버의 웹 로그 파일을 이용하여 분석을 하면 됩니다.
다음의 [그림 5-5]는 그러한 원리를 보여주고 있는 것으로서 다음과 같은 방법을 통해서 산정됩니다. 그림에서와 같이 개별 사용자는 각자의 고유한 시간 간격으로 Hit를 남깁니다. 그리고 개별 사용자는 일반적인 경우 고유한 IP 주소를 가지고 있습니다. 여기에서 동시 사용자를 구하는 방법은 특정 시각을 기준으로 10분 전후에 모두 기록이 남아 있다면 그 사용자는 동시 사용자 중의 한 사람으로 간주하는 방법을 사용합니다. 만약, 10분전 구간에서는 Hit가 남아 있으나 해당 시각 10분 후 구간에 Hit가 없다면 해당 시각에서 그 사용자는 로그아웃 했다고 여겨도 되지 않겠습니까? 이 같은 논리로 볼 때 다음 그래프에서 해당 시각의 동시사용자는 6명으로 파악됩니다. 이러한 수치를 직관적으로 보듯, 10분 동안 Hit가 남아 있는 서로 다른 IP 수 보다 작습니다.
[그림 5-5] 동시 사용자 산정 방안
이와 같은 통계적 분포를 통한 동시 사용자 산정 방안은 다년간의 경험을 통해 얻은 경험으로 성립된 것이며, 이에 대한 이론적인 배경에는 다소 한계가 있음을 미리 밝힙니다.
예를 들어, 특정 시각을 기준으로 왜 전후 10분인가? 5분이면 안 되는가? 10분에 대한 근거는 무엇인가? 등의 질문에 대한 속 시원한 답변은 없는 상황입니다.
단지, 통계적인 가정을 한 채로 분석을 해 본 결과 대부분의 사이트에서 적절하게 맞아 떨어지는 결과가 나왔고 또한 웹 로그 분석을 통한 동시 사용자 수 산정의 한계로 인해 더 이상의 연구가 이루어지지 못한 점도 정확한 답변을 얻지 못한 이유입니다.
Workload 대상 트랜잭션 선정
앞에서 설명하였듯이 웹 환경하에서는 사용자가 한 번 요청할 때 마다 여러 컨텐츠 요청들이 웹 서버로 전달되기 때문에 웹 로그에 기록되는 정보에는 동일 시간대에 각 사용자별로 여러 컨텐츠 요청 URL이 보이게 됩니다. Workload 분석 시이들을 별도의 요청으로 인식하여 카운트 하게 되면 실제 사용자가 요청한 건수보다 훨씬 많이 집계 되기 때문에 Workload가 왜곡될 수 있습니다. 이러한 특성 때문에 트랜잭션을 정의할 경우 한 사용자가 마우스를 한 번 클릭할 때 웹 로그
에 기록되어 있는 여러 컨텐츠들이 한 개의 트랜잭션으로 카운트 될 수 있게끔 Main 동적 컨텐츠만 선별하여 카운트 해야 합니다. 여기에서 Main 동적 컨텐츠는 화면을 구성하고 있는 동적 컨텐츠(JSP, Servlet, ASP, PHP) 중에서 사용자가 맨 처음 호출하는 컨텐츠를 의미하는 것으로 프레임(Frame or Iframe)으로 나뉘어진 페이지와 페이지 전환 기능(Forward 또는 Redirect)에 의해서 호출되는 동적 컨텐츠는 제거됩니다.
이러한 동적 컨텐츠의 필터링 작업은 해당 어플리케이션 개발자의 도움 없이는 불가능하기 때문에 성능 시험 담당자는 Workload 대상 트랜잭션을 선정할 때 도움을 구하시기 바랍니다.
다음의 [그림 5-6]은 Workload 대상 트랜잭션의 목록을 보여주고 있는데 개발자의 협조하에 프레임으로 나뉘어진 페이지와 페이지 전환 기능에 의해서 호출되는 동적 컨텐츠는 모두 제거 된 채로 분석 되었습니다.
[그림 5-6] Workload대상 트랜잭션 목록
Workload 분석 방법 요약
다음 내용은 웹 기반 시스템하에서의 Workload 분석 활동을 간단히 요약한 내용입니다.
분석 대상 소스
대상 시스템의 Peak 일자 기준 웹 서버의 웹 로그 파일(Access Log)
분석 대상 트랜잭션 선정
사용자가 웹 서버에 요청할 때 호출된 Main 동적 컨텐츠(Iframe, Redirect, Forward로 호출되는 동적 컨텐츠는 배제)
분석 방법
Workload Modeler 도구를 사용하여 해당 웹 로그 파일(Access Log)을 분석
분석 결과
Workload 분석 결과는 다음과 같음
- 시간당 처리 건수(Trans/Hour)
- 분당 최대 처리 건수(Trans/Min)
- 초당 최대 처리 건수(Trans/Sec)
- 최대 동시 단말 사용자 수(명)
- 사용자당 최대 호출 간격(초)
- 업무별 업무 가중치(%)
분석 절차
Workload Modeler 도구를 통한 Workload 분석 절차는 다음의 절차대로 수행
① Workload Modeler 도구를 수행합니다.
② [단일로그 분석] 탭을 클릭합니다. 고객명과 서버명을 기입하고 해당 웹 서버의 로그 타입을 설정합니다. 그런 다음 아래 동적 컨텐츠 구분에서 분석 대상 동적 컨텐츠(JSP, Servlet, ASP, PHP)를 기술하고 개발자의 협조하에 제거 대상으로 선정된 제외 대상 컨텐츠 목록도 기술합니다.
③ 위의 과정을 모두 마쳤으면 [분석 시작] 버튼을 클릭하여 분석을 시작합니다.
④ 분석 결과 창이 나타나면 [파일]-[WLM 저장] 메뉴를 선택하여 해당 결과를 파일로 저장합니다.
⑤ 분석 결과 창에서 분석 결과 요약 항목을 선택하면 다음의 정보가 표시되는데 여기에서 Peak 시간과 Peak 시간대 최대 TPS, Peak 시간대 최대 동시 사용자 수, Peak 시간대 최대 호출 간격 수치 등을 기록하여 성능 기준선으로 정합니다.
⑥ 시간당 호출 건수 현황 항목을 선택하면 다음의 정보가 표시되는데 각 시간대별 호출 건수 현황을 파악할 수 있습니다. 위의 분석 결과 요약 정보에서 시스템의 Peak 시간은 18시경인데 이때, 당시의 TPH는 7,374(Trans/Hour)인 것을 확인할 수 있습니다.
⑦ 분당 호출 건수 현황 항목을 선택하면 다음의 정보가 표시되는데 각 분 단위별 호출 건수 현황을 파악할 수 있습니다. 위의 분석 결과 요약 정보에서 시스템의 Peak 시간은 18시경인데 이때 당시의 TPM는 181(Trans/Min)인 것을 확인할 수 있습니다.
⑧ 동시 사용자 수 분석 현황 항목을 선택하면 다음의 정보가 표시되는데 각 분단위로 동시 사용자 수 현황을 파악할 수 있습니다. 위의 분석 결과 요약 정보에서 시스템의 Peak 시간은 18시경인데 이때 당시의 최대 동시 사용자 수는 32명인 것을 확인할 수 있습니다.
⑨ Peak Time 개별 컨텐츠 호출 현황 항목을 선택하면 다음의 정보가 표시되는데 Peak 시간 동안에 호출되었던 각 업무 어플리케이션에 대한 호출 건수 비율을 확인할 수 있습니다. 이 정보는 성능 시험 도구상에서 각 개별 업무별 가상 사용자 수를 결정할 때 기준이 됩니다.
4. TP-MONITOR 기반 시스템하에서의 Workload 분석
TP-MONITOR의 경우 이전부터 미션 크리티컬한 환경하에서 주로 사용되었던 전형적인 미들웨어 시스템으로 분산된 환경에서 어플리케이션간 상호 통신(Messaging), 분산 트랜잭션들의 모니터링(Monitoring) 및 관리 기능(Management) 등을 수행해야 하는 금융/통신 비즈니스 환경하에서 많이 사용되어 왔습니다. TP-MONITOR에는 오픈 시스템 환경하에서 사용되는 Tuxedo/Top End/Entera/Tmax 시스템과 메인 프레임에서 사용되는 CICS/IMS/MVS 등이 있으나 기본적인 구조는 유사하다고 볼 수 있습니다.
통상적으로 TP-MONITOR는 Workload 분석을 위해서 필요한 각종 사용자 요청 내역 및 처리 내역 등의 데이터들을 자체 관리 콘솔을 통해 제공하는데, 이들 데이터들을 분석할 경우 각종 Workload 결과들을 손쉽게 생성할 수 있습니다.
동시 사용자 산정 방안
TP-MONITOR의 경우 일반적인 C/S 시스템과 같이 클라이언트가 서버와 연결(tpstart)한 후 서비스를 수행(tpcall)한 다음 더 이상 요청을 보내고 있지 않더라도 연결 종료 명령(tpend)을 통해 연결을 끊기 전까지는 동시 사용자에 포함됩니다. 그러므로 동시 사용자 산정 방안은 웹 기반 시스템의 경우처럼 복잡하고 통계적인 가정을 통해서 구하는 것이 아니라 관리 콘솔에서 기본으로 제공하는 기능을 통하여 손쉽게 구할 수 있습니다.
Workload 대상 트랜잭션 선정
TP-MONITOR의 경우도 웹 화면의 경우와 마찬가지로 사용자가 한 번 클릭할때 마다 여러 개의 서비스 요청이 TP-MONITOR로 호출되기 때문에 관리 콘솔에 기록되는 서비스 내용에는 동일 시간대에 한 사용자당 여러 서비스 요청 목록이 보이게 됩니다. Workload 분석 시 이를 별도의 요청으로 인식하여 개별적으로 카운트 하게 되면 실제 사용자가 요청한 건수보다 훨씬 많게 집계 되기 때문에 Workload가 왜곡될 수 있습니다.
이러한 특성 때문에 트랜잭션을 정의할 경우 한 사용자가 마우스를 한 번 클릭할 때 관리 콘솔에 기록되는 여러 서비스들이 한 개의 트랜잭션으로 카운트 될 수 있게끔 Main 서비스만 선별하여 카운트 해야 합니다. 여기에서 Main 서비스라함은 사용자가 맨 먼저 호출하는 서비스를 말하는 것으로 타 서비스에 의해 호출되는 서비스나 공통 모듈들은 배제됩니다.
Workload 분석 요약
다음 내용은 TP-MONITOR 기반 시스템의 Workload 분석 활동을 요약한 내용입니다.
분석 대상 소스
Peak 일자의 TP-MONITOR의 관리 콘솔에서 출력되는 각종 현황
분석 대상 선정
사용자가 업무 요청 시 호출하는 Main TP 서비스
(Main TP 서비스가 호출하는 Called TP 서비스 및 모듈 제외)
분석 방법
관리 콘솔에서 출력되는 각종 데이터를 수집한 다음 Tmax Modeler를 이용하여 분석 실시
분석 결과
Workload 분석 결과는 다음과 같음
- 시간당 처리 건수(Trans/Hour)
- 분당 최대 처리 건수(Trans/Min)
- 초당 최대 처리 건수(Trans/Sec)
- 최대 동시 단말 사용자 수(명)
- 사용자당 최대 호출 간격(초)
- 업무별 업무 가중치(%)
분석 절차
Workload 분석 절차는 다음의 절차대로 수행
① 부록 CD에 포함되어 있는 TP-MONITOR 모니터링을 위한 쉘 프로그램(TUXEDO의 경우 mon_tuxedo.sh, TMAX의 경우 mon_tmax.sh)을 TPMONITOR 서버에 설치하여 Peak 일자에 대한 분석 결과 파일(서비스 로그파일, 동시 사용자 로그 파일)을 생성합니다.
② 부록 CD에 포함되어 있는 TP-MONITOR 분석용 프로그램(TMAX의 경우 TMAXLOG V1.0)을 구동합니다.
③ 구동 후 분석 결과 파일들을 각각 지정하여 분석을 실시합니다.
④ 분석 결과가 나타나면 [파일]-[WLM 저장] 메뉴를 선택하여 해당 결과를 파일로 저장합니다.
⑤ 분석 결과 창에서 분석 결과 요약 항목을 선택하면 다음의 정보가 표시되는데 여기에서 Peak 시간과 Peak 시간대 최대 TPS, Peak 시간대 최대 동시 사용자 수, Peak 시간대 최대 호출 간격 수치 등을 기록하여 성능 기준선으로 결정합니다.
⑥ 서비스별 평균 실행 시간 현황 항목을 선택하면 다음의 정보가 표시되는데, 서비스 코드별 평균 실행 시간을 확인할 수 있습니다. 평균 실행 시간이 상대적으로 높은 서비스의 경우 튜닝 대상 업무로 관리하시면 됩니다.
⑦ 서버별 평균 대기 시간 현황 항목을 선택하면 다음의 정보가 표시되는데 현재 큐잉이 발생하고 있는 서버 목록을 확인할 수 있습니다. 이들 서버들은 업무요청량 대비 프로세스의 개수가 적게 셋팅 되어 큐잉이 발생할 수도 있기 때문에 파라미터 튜닝 대상으로 관리하시면 됩니다.
⑧ 서비스별 수행 현황을 선택하면 다음의 정보가 표시되는데 각 서비스별 평균 요청 건수를 확인할 수 있습니다.
⑨ 동시 사용자 수 현황을 선택하면 다음의 정보가 표시되는데 각 분 단위로 동시 사용자 수 현황을 파악할 수 있습니다.