비용 절감 아이디어
A사 내 온라인 비즈니스 안정성 표준은 비즈니스가 승인한 TPS에 도달할 때 최대 CPU 사용률이 60%를 초과하지 않는 것입니다. 이는 안정적인 상태입니다.
이러한 배경에서 테스트 부서는 비즈니스 TPS 요구 사항을 충족할 때 성능 테스트 및 조정을 통해 테스트된 응용 프로그램의 최대 CPU 사용률을 줄이는 것을 목표로 CPU 소비가 많은 일부 시스템에 대해 통합 정렬 및 특수 성능 테스트를 수행했습니다. 최대 CPU 사용률이 크게 떨어지면 배포된 노드의 CPU 코어 수를 줄이고 비즈니스 시나리오에 따라 다시 테스트를 수행합니다. 최대 CPU 사용률이 여전히 60% 미만이고 TPS에 이상이 없는 것으로 확인되면 프로덕션 환경 배포 노드의 CPU 코어 수를 줄여 다른 서비스 배포에 더 많은 리소스를 할당합니다. 생산 모니터링 방식과 연계해 일정 기간 내에 이상이 없으면 원가 절감에 성공한 것으로 간주한다.
구체적인 아이디어가 그림에 나와 있습니다.
그림에 표시된 비용 절감 단계는 아래에 설명되어 있습니다.
1) 성능 스트레스 테스트: 테스트 중인 애플리케이션에 대해 높은 동시성 스트레스 테스트를 수행합니다.
2) 성능 평가: 성능 테스트 과정에서 성능 지표를 살펴보고 최적화 가능한 지점을 평가합니다. 성능 지표에는 TPS, 응답 시간, CPU 활용도, 메모리 사용량, 코드 응답 시간, 전체 링크 토폴로지 등이 포함됩니다.
3) 성능 분석: 다음 세 가지 차원을 포함합니다.
❑CPU 소비가 많은 테스트된 응용 프로그램에 대해 CPU 핫스팟 분석 및 스레드 추적 분석을 수행합니다. 시각적 보고서를 사용하여 CPU 사용률이 높을 때 실행 중인 애플리케이션의 코드 세그먼트 및 스레드 ID를 확인하고 코드 세그먼트 소스 코드 및 스레드 호출 스택에 대한 심층 분석을 수행하여 높은 CPU 사용률의 근본 원인을 찾습니다.
❑메모리 소비가 많은 테스트된 애플리케이션의 경우 메모리 관점 분석을 통해 JVM의 신세대, 구세대, GC, 오프힙 메모리, 메모리 개체, 클래스 개체 및 기타 지표를 저렴한 방법으로 얻을 수 있습니다. 시각적 보고서를 통해 실시간으로 비정상적인 지표나 곡선을 확인하고 해당 메모리 개체를 분석하여 근본 원인을 찾습니다.
❑코드 응답 시간이 긴 테스트된 애플리케이션의 경우 하위 메서드 호출 분석을 통해 실시간 바이트코드 향상 기술을 사용하여 코드에서 트리거된 하위 메서드 호출에 대해 시간이 많이 소요되는 마이크로초 수준의 분석을 수행합니다. 가장 시간이 많이 걸리는 코드 세그먼트를 찾은 후 소스 코드 분석을 시작하여 소스 코드 논리를 보고 근본 원인을 찾습니다.
4) 성능 튜닝: 발견된 CPU, 메모리, 스레드, 코드 문제를 해결하기 위해 프로젝트 팀과 통신합니다.
5) 비용 절감 검증: 테스트 중인 애플리케이션의 CPU 지표와 메모리 지표가 개선되었는지 확인하기 위해 동일한 시나리오와 동시성 수를 사용하여 최적화된 테스트 중인 애플리케이션을 검증합니다. 최적화가 확인된 테스트 중인 애플리케이션에 대해 CPU 및 메모리 구성을 줄이고 동일한 시나리오 및 동시성 수를 사용하여 성능 테스트를 수행하여 다운그레이드 후 성능 지표가 온라인 표준을 충족하는지 확인합니다.
다운그레이드 후 측정된 애플리케이션 지표가 온라인 기준에 부합하지 않는 경우, 성능평가 단계부터 다시 분석을 수행합니다.
원가절감 사례
위의 비용 절감 아이디어를 바탕으로 A사 내부의 실제 시스템 튜닝 과정은 다음과 같습니다. 1) 문제 설명: 높은 동시성 스트레스 테스트 시나리오에서 시스템 내 애플리케이션의 평균 CPU 사용률은 그림 10-19와 같으며, 실제 CPU 사용률은 70.07%에 도달하고 최고치는 100%에 달합니다.
그림 10-19 애플리케이션의 CPU 사용률 2) 포지셔닝 프로세스 설명: 성능 분석 플랫폼의 핫스팟 분석을 통해 로그 스택 상승 작업에서 CPU의 대부분이 소모되는 것으로 나타났습니다.
CPU 핫스팟 분석 차트
3) 성능 위험 지점 확인: 높은 동시성에서 빈번한 로그 상승은 과도한 CPU 소비로 이어지고 전반적인 애플리케이션 경험에 영향을 미칩니다.
4) 최적화 제안 제시: 개발 사양 관점에서 라인 번호로 찾는 것은 비용이 너무 많이 들고 자원을 낭비하기 때문에 권장하지 않습니다. 출력 로그 문자열을 정확하고 정확하게 사용하는 것이 가장 좋습니다. 코드 논리에 문제가 있는 단락을 명확히 하기 위한 기호입니다. 이 경우 우선 라인 번호를 출력하는 %I, %L 파라미터를 삭제하는 것이 좋습니다. 둘째, %method 또는 %m 구성을 삭제합니다. 현재 Debug, Info, Warn 및 Error 수준 로그는 동일한 출력 형식 집합을 사용합니다. 즉, 패턴 구성이 동일합니다. Debug 및 Info는 삭제하는 것이 좋습니다. 메소드 이름과 줄 번호를 인쇄하지만 Warn 및 Error를 직접 인쇄하는 것은 괜찮습니다.
5) 실제 최적화 효과: 구성 수정으로 TPS가 260트랜잭션/초에서 320트랜잭션/초로 25% 이상 증가했습니다.
6) 비용 절감 효과: 애플리케이션 서버 구성을 50% 줄인 후에도 전체 지표는 여전히 목표 값을 충족합니다.