일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- error
- 후기
- backend
- grafana
- Spring
- 레디스
- 트러블슈팅
- nGrinder
- java
- F-Lab
- 백엔드
- 로드밸런서
- 플러터
- 멘토링
- 에프랩
- 자바백엔드
- Flutter
- redis
- MySQL
- AWS
- 성능테스트
- github
- EC2
- 데이터구조
- 자바
- 부트캠프
- FLAB
- 도커
- 알고리즘
- 코딩테스트
- Today
- Total
민스씨의 일취일장
Grafana | 성능 테스트 | 모니터링 | 필요한 지표들 선정한 뒤 그라파나 대시보드 생성하기 본문
성능 테스트에서 측정할 지표들에 대한 글로, Github Issue #12의 1-2에 대한 내용입니다.
성능 테스트 지표들 선정하기
성능테스트를 기반으로 프로젝트를 진행할 계획이다. 이를 통해 적절한 최적화를 진행하며 기능들을 추가해 나갈 것이다. 테스트와 모니터링 환경이 구축되었으니 이제 본격적으로 어떤 정보들을 수집해 분석할 것인지 정해야 한다.
어떤 것을 측정할 것인가?
어떤 성능을 갖춰야 하는지는 프로젝트의 지향점에서 찾으면 된다. 이번 프로젝트의 목표는 "대용량 트래픽을 빠른 속도로 안전하게 처리할 수 있는 고가용성 결제시스템"을 만드는 것이다.
대용량 트래픽을 빠른 속도로 안전하게 처리할 수 있는 고가용성 결제 시스템
목표에서 중요 키워드를 뽑아보자면 다음과 같다.
- 대용량 트래픽
- 빠른 속도
- 안전성
- 고가용성
이 4가지를 달성했는지를 알 수 있는 지표들을 찾아야 한다.
대용량 트래픽
대용량 트래픽은 측정값은 아니고 테스트 변수에 해당한다. 인자로 살펴보자면 아래와 같은 지표가 있다고 생각한다. (추후 더 추가할 수 있다.)
- 요청 수
- 요청 데이터 크기
대용량 트래픽은 성능 테스트를 진행할 때 살펴보도록 하겠다.
빠른 속도
빠른 속도는 성능 테스트에서 측정되어야 할 지표이다. 인자로는 아래와 같은 것이 있다고 생각한다.
1. 초당 처리량 (Throughput)
rate(http_server_requests_seconds_count{uri="/payments"}[1m])
sum(rate(http_server_requests_seconds_count{uri="/payments"}[1m]))
2. 응답 시간 (Response Time)
rate(http_server_requests_seconds_sum[1m])
max(http_server_requests_seconds_max)
안정성
안전성도 성능 테스트에서 측정되어야 할 지표이다. 인자는 아래와 같이 꼽아볼 수 있을 것 같다.
1. 에러율 (Error Rate)
sum(rate(http_server_requests_seconds_count{status=~"5.."}[1m])) / sum(rate(http_server_requests_seconds_count[5m]))
sum(rate(failed_transactions_total[5m])) / sum(rate(total_transactions[5m]))
2. 응답시간 일관성
stddev(http_server_requests_seconds_sum / http_server_requests_seconds_count)
3. 시스템 리소스 사용률
CPU 사용률
100 * system_cpu_usage
메모리 사용률
(jvm_memory_used_bytes / jvm_memory_max_bytes) * 100
4. 장기 실행 테스트 결과
시간 경과에 따른 응답 시간 추이 (5분 간격 지난 24시간 평균)
avg_over_time( ( rate(http_server_requests_seconds_sum[5m]) / rate(http_server_requests_seconds_count[5m]) )[24h:5m])
메모리 누수
장기 실행 중 에러율 변화
연결 풀 사용량 추이
hikaricp_connections
hikaricp_connections_max
hikaricp_connections_idle
고가용성
고가용성은 성능 테스트만으로는 측정하기 어려운 면이 있다. 아래와 같은 지표들이 분석해볼 필요가 있다고 한다.
- 가동 시간 비율 (Uptime)
- 평균 복구 시간 (MTTR Mean Time To Recovery)
- 장애 빈도
- 부하 분산 효율성
- 페일오버(Failover) 성능
고가용성 모니터링은 일단 위의 단계들을 완수한 다음에 업데이트 하도록 하겠다.
완성 대시보드
완성한 대시보드들이다. 앞으로 계속 튜닝해야겠지만, 일단 이 정도의 대시보드를 만든 것에 만족한다.
'Projects > MetaPay' 카테고리의 다른 글
nGrinder | 성능 테스트 결과 - Simple Case (0) | 2024.08.18 |
---|---|
nGrinder | 동시성 시나리오 만들기 (0) | 2024.08.17 |
성능 테스트 | 컨테이너 메모리 제한 설정 (0) | 2024.08.16 |
TIssue | EC2 내 컨테이너에서 로컬 PC로의 요청이 전달되지 않는 이슈 (feat. Public IP vs. Private IP) (0) | 2024.08.14 |
TIssue | Nginx | EC2 | 도커 컨테이너로 띄운 로드밸런서가 하나의 서버만 연결하는 이슈 (0) | 2024.08.14 |