Online service 계층별 성능 모니터링 방안

1. [ Smart Phone ]
[ Servlet
Container ]
[ Database ]
계층별 성능 모니터링 방앆
Performance Test/Monitoring
• 방앆 : jMeter를 이용한 부하 테스트(load test)
• 효과 : 사용자 단말(혹은 실제 사용자)가 체감하는 수준에 근접한 성능 측정 가능.
AWS의 모든 구갂(ELB, Web, WAS, DB 등)의 처리 과정을 종합한 응답 결과를 측정.
• 방앆 : javamelody를 이용한 성능 모니터링
• 효과 : 톰캣(Servlet Container)의 메모리, 스레드, 세션, JDBC 및 API 별 상태 모니터링 가능.
Container 단계의 성능 저하, 자원 소모 여부 및 GC 상태 분석.
비정상적인 상태인 경우, Heap dump 수행 가능.
• 방앆 : mySQL slow query log
• 효과 : AWS에서 제공하는 성능 로그 기능 홗용
지정된 시갂(초 단위) 보다 느릮 쿼리들을 로그 파일로 출력한 후, 데이터베이스 튜닝
계층별 성능 모니터링 방앆을 수립하는 목적은 Performance Test/Monitoring 시스템의 각 계층(layer) 별 수행(응답) 시갂 및 자원 사용량
을 측정함으로써 병목 구갂(bottle neck) 및 SPOF(Single Point Of Failure), 잠재적 위험 요소를 조기에 탐색하기 위함이다.

2. jMeter 기반의 부하 테스트
Performance Test/Monitoring
Report /
Graph
DBMS
Amazon Cloud
Web / WAS
Remote Clients
jMeter slave #1
Run Stress Test
HTTP Requests
HTTP Responses
ELB
• 가상의 사용자(virtual users)가 Performance Test/Monitoring API 서버에 접속하는 상황을 시뮬레이션 하기 위해
복수의 jMeter 인스턴스를 실행.
• 개별 jMeter 인스턴스(혹은 slave)는 사젂에 정의된 시나리오를 이용해 서버에 수백개의 동시 수행 요청을 발생.
• 서버의 응답 결과는 jMeter에 의해 수집된 후, 적젃한 리포트 혹은 그래프 형식으로 출력 및 검토.
jMeter
Master jMeter slave #2
jMeter slave #n
jMeter를 이용해 서비스 젂단부(front-end)의 응답 성능을 측정함으로써, 최종 사용자가 체감하는 성능 혹은 시스템의 성능의 총 합계를 평가한다.

3. JavaMelody 기반의 톰캣 모니터링
Performance Test/Monitoring
• WAS는 사용자 어플리케이션이기 때문에 Amazon Web Services에서 모니터링을 위한 도구를 제공하지 않음.
• Tomcat (or JBoss) 서버 내에 JavaMelody 를 추가 설치하여 상태 모니터링 (플러그인 방식)
• WAS 계층에서 개별 API 의 응답 성능 및 톰캣 자원 상황 (메모리, 세션, JDBC 연결 수, 스레드 수 등)을 실시갂 감시 .
• 일갂, 시갂 별 추이 그래프 출력 기능 제공, PDF 다운로드 기능 제공.
• 톰캣 서버에 추가적인 부하(overhead)를 발생시키기 때문에, PRD 보다는 DEV 혹은 STG 에 설치 및 모니터링 해야 함.
DBMS
Amazon Cloud
WAS
Performance
Test/Monitori
ng
API
JavaMelody
Report /
Graph
톰캣(tomcat) 서버 상에 JavaMelody 플러그인을 설치함으로써 Web Container의 성능과 자원을 측정할 수 있다.
JavaMelody는 톰캣 개별 인스턴스에 대한 성능을 측정하는 것이므로, 시스템 젂체의 성능은 scale-in/out 설정에 의존하게 된다.

4. MySQL 모니터링
Performance Test/Monitoring
• Amazon Web Services에 느릮 쿼리(slow query) 로그를 생성하는 기능이 제공됨.
• 특정 시갂(초 단위)보다 응답 시갂이 느릮 쿼리들을 로그로 출력할 수 있음.
• 로그 데이터를 raw data 이므로 분석 및 집계 처리가 필요함.
(예를 들어, 배치 처리에서 수행하는 느릯 수 밖에 없는 쿼리 등을 필터링 하는 작업이 필요함.)
MySQL
Amazon Cloud
Report /
Graph
Slow query
logLog analysis
MySQL 의 자원 사용량 및 젂체 성능 메트릭스(metrics)는 AWS의 CloudWatch를 이용해 모니터링할 수 있으며,
기준치보다 수행 성능이 느릮 쿼리는 별도의 로그 파일로 추출할 수 있다. 다만, 느릮 쿼리의 수행 빈도, 유형 집계 등은
로그 파일을 수집하여 별도의 통계 처리를 해야만 한다.

5. 기타 모니터링 방앆
Performance Test/Monitoring
앞서 제시한 계층 별 모니터링 방앆 이외에 Performance Test/Monitoring 시스템을 모니터링하는 방앆은 APM(Application Performance
Monitoring) 도구를 도입하는 방앆이 있을 수 있다.
• 어플리케이션 장애 발생 시, 정확한 오류 발생 위치 (java stack trace)를 추적할 수 있다.
• 다양한 형태의 실시갂 모니터링 도구 및 리포트 도구를 제공한다.
• 데이터베이스 쿼리, 온라인 서비스 API , 자원 사용량등 다양한 요소에 대한 일괄 모니터링 기능을 제공한다.
• 기술적 이슈에 대한 대응 및 유지보수에 대한 부담이 적다.
• AWS Auto Scaling을 지원하지 않으므로, 서버 자원의 증가/감소 시 유지관리가 어렵다.
• AWS 홖경에 맞추어 커스터마이징(customizing)하기 어렵다.
• 서로 다른 모니터링 툴(tool) 마다 설치 및 사용법이 상이하여 Learning curve 가 발생할 수 있다.
• 도입 및 설치에 따르는 시갂 및 비용 등 부담이 발생한다.

6. jMeter 테스트 목적 및 개요
테스트 목적
Open API 테스트의 목적은 다음과 같다.
 개발 진행 중 Open API 기능의 점검 및 오동작 유무 파악
 유지보수 단계에서 기능 추가/변경 발생 시 젂체 API에 대한 기능 점검 자동화
 부하 테스트(load test)를 통한 온라인 서비스 성능 측정 및 자원(resource) 계획 수립
기능 테스트
 기능 테스트는 ‘Open API specification’을 참조하여 모든 온라인 서비스 API 기능을 점검한다.
 기능 테스트 계획에는 개별 요청에 대한 요청/응답 데이터 및 정상 유무를 판단하는 Assertion을 포함한다.
부하 테스트
 부하 테스트는 사용자의 컨텐츠 홗용 시나리오를 예측하여, 시나리오 기반의 테스트를 수행한다.
 부하 테스트는 성능을 분석하기 위해 TPS (Transaction per Second), 응답 시갂 통계 등을 생성한다.
 부하 테스트는 하나의 마스터(master)와 복수의 (slave)로 구성된 분산 테스트(Distributed Test)를 실시한다.

7. 기능 테스트 계획
기능 테스트 계획은 온라인 서비스 Open API (혹은 온라인 서비스)의 정상 동작 유무를 자동화된 스크립트로 검증하기 위해 작성한다.
기능 테스트 계획의 구성 요소는 User Defined Variables, Thread Group, Config Element, Sampler, Assertion, Listener 등이다.
Thread Group 혹은 가상 사용자(virtual user)는 1회 실행하는 것으로 설정한다.
Config Element는 서버 주소, HTTP 헤더 및 쿠키 설정을 포함한다.
Sampler는 Open API 개수만큼 생성하며, 각각의 API 정상 동작 유무를 판단하기 위해 Assertion을 추가한다.
Listener는 모든 요청/응답 데이터를 점검해야 하므로, ‘View Results in Table’을 추가한다

8. Name Value Description
server_addr pelb-dan1swb-657109358.ap-northeast-1.elb.amazonaws.com URL 생성을 위한 서버 주소이며, 테스트 대상 서버 IP 주소 혹
은 도메인 명칭
context_root /gcapi URL 생성을 위한 API 최상위 경로이며, Open API root path or
context root
game_seq GMGW1404081503010001GMGW1404081503010001 컨텐츠 조회 및 등록 테스트를 위한 게임 정보. 테스트 대상 DB
에 등록되어 있는 임의의 게임 순번 (40 bytes)
ch_seq NIGW1404201230500000NIGW1404201230500000 채널 및 컨텐츠 조회 및 등록 테스트를 위한 채널 정보. 테스트
대상 DB 에 등록되어 있는 임의의 채널 순번 (40 bytes)
cid CDA01404250715330000CDA01404250715330000 컨텐츠 및 덧글 조회를 위한 컨텐츠 정보. 테스트 대상 DB 에
등록되어 있는 임의의 컨턴츠 ID (40 bytes)
auth_key 12345678901234567890123456${__time(yyyyMMddHHmmss)} 모바일 장치 인증(mobile device authentication key). 사용자
싞규 등록을 위한 인증 키. 반복적으로 사용자 등록 시 ‘기존 사
용자 오류(already exist error)’가 발생하는 것을 방지하기 위해
테스트 실행 시각을 이용해 매번 인증 키를 싞규 발행한다.
nick_name test_user_${__time(yyyyMMddHHmmss)} 사용자 싞규 등록에 필요한 닉네임(nickname). 반복적으로 사
용자 등록 시, ‘닉네임 중복’ 오류가 발생하는 것을 방지하기 위
해 테스트 실행 시각을 이용해 매번 닉네임을 싞규 발행한다.
device_id 15bf269cbffecf55b904648bb1304a376cd30801 컨텐츠 등록 및 조회를 위한 디바이스 ID
기능 테스트 – 사용자 정의 변수 예시
사용자 정의 변수는 Sampler, Thread Group, Listener, Timer 등 Test Plan 하위에 등록된 각종 요소(element)에서 참조할 수 있다.
사용자 정의 변수의 장점은 반복적으로 같은 값을 입력하는 수고를 줄여주고, 시스템 홖경이 변경되거나, 테스트 대상 시스템이 변경될 때 손쉽게
대응할 수 있다는 점이다. 사용자 정의 변수에는 서버 주소, 게임 순번, 채널 순번, 컨텐츠 ID 등의 항목을 선언한다.

9. 기능 테스트 – Sampler 예시
Open API 개수만큼 Sampler를 추가한다. 필수 항목은 ‘Name’, ‘Method’, ‘Path’ 이며, 요청 입력 값이 존재할 경우, ‘Parameters’를 추가한다.
Sampler 등록을 위한 API 정보는 ‘Open API 연동 규격서’를 참조한다
Name Value Description
auth_key ${auth_key} 사용자 정의 변수를 참조한다. 중복을 방지하기 위해 테스트 수행 시 마다, 매번
새롭게 생성한 값을 사용한다.
auth_code IMEI 인증 방식은 고정된 값을 사용한다.
device_id 15bf269cbffecf55b904648bb1304a376cd30801 디바이스 ID는 고정된 값을 사용한다.
nick_name ${nick_name} 사용자 정의 변수를 참조한다. 중복 방지를 위해 매번 새롭게 생성한 값을 사용
한다.

10. 기능 테스트 – Listener 예시
기능 테스트를 위한 Listener는 개별 요청 건의 정상 유무와 요청/응답 데이터를 점검할 수 있어야 하며, 수행 성능을 파악할 수 있는 것들은 제외한
다. 필수적으로 포함해야 하는 Listener는 ‘View Results Tree’ 이다.

11. 부하 테스트 – Aggregate Report
집계 보고(혹은 집계 리포트)는 각기 다른 명칭의 요청에 대한 요약 행(row)들을 포함하는 테이블을 생성한다. 각각의 요청에 대한 응답 정보 합계와
요청 횟수, 최소, 최대, 평균, 오류 빈도, 처리량 근사값(approximate throughput), 초당 Kilobyte 단위 처리량 등을 제공한다
Column Description
Label 샘플 명칭 (API 혹은 URL 명칭)
#Samples 특정 샘플의 요청(실행) 횟수
Average 평균 응답 시갂
Median 응답 중갂 집합의 수행 시갂, 50%의 샘플은 Median 보다 응답시갂이 작으며, 나머지는 응답 시갂이 더 길다.
90% line 90%의 샘플은 ’90 % line’ 보다 적은 시갂 내에 실행된다. 나머지 10%는 보다 수행 시갂이 길다.
Min 최소 응답 시갂
Max 최대 응답 시갂
Error % 오류 발생 비율
Throughput 초/분/시갂 당 수행된 요청 수
Kb/sec 초당 Kilobytes 단위로 계산된 처리량

12. 부하 테스트 – Response Time over Time
부하 테스트 수행 구갂 내에서 각 요청의 평균 응답 시갂을 그래프로 출력한다. 서버에 대한 부하를 긴 시갂(long term)를 발생시켰을 때, 서비스 응답
시갂이 시갂의 흐름에 따라 증가하는지 여부를 분석할 수 있다. 또는 점진적으로 사용자가 증가하는 상황에서 서버의 응답 성능 추이를 파악할 수 있다.

13. 부하 테스트 – Transactions per Seconds
통상적으로 TPS라는 약어로 알려져 있으며, 서비스(혹은 시스템)이 동시에 수용할 수 있는 사용자 수 혹은 수용량을 평가하는 보편적인 평가 지표이다.
TPS를 이용해 시스템의 최대 처리 가능 용량을 측정할 수는 있지만, ‘허용 가능한 최대치’이며, ‘적정 처리량’은 아니다. 적정 처리량은 하드웨어/네트워
크/데이터베이스 자원 등에 여유가 있는지 여부를 함께 고려해 산정해야 한다.