관리 메뉴

백엔드 개발자 블로그

K6 본문

트러블 슈팅

K6

backend-dev 2025. 4. 27. 22:32

파레토 - 중요한거 먼저해라

주석 공부법 - 어떤 역할하는지 작성해봐라


자료

https://jscode.notion.site/14211062ff0780c2a77ee2f770da510a


처리량(Throughput) : 1초당 처리할 수 있는 트래픽 양, 단위 : TPS(1초당 처리한 트랜잭션의 수) 

지연 시간(Lagtency) : 요청에 대한 응답 시간


툴 선정

메모리 적고 많은 요청 수 보낼 수 있음

 

AWS 설정 하여 간단한 API 개발

부하테스틀 셔틀 서버 세팅 (5665 open)

 

점진적으로 부하 늘리기 script

 

대시보드

public ip:5665 에서 실시간 데이터 확인 가

http_reqs이 수평선이 될때까지 부하테스트 실행

1. http_reqs = Throughput > 증가하지 않는 Throughput이 최대 Throughput, 이거 나올때까지만 해도 ㄱ

2. Requeest Duration  = Latency > 점점 증가함, 지정한 시간보다 낮으면 합격

3. http request failed = 실패


병목 지점

전체 시스템에서 특정 서버 자원이 한계에 도달해 전체 성능이 저하되는 구간


부하 테스트 전체 흐름

1. 목표 Throughput, Latency 설정

2. 부하 테스트로 목표 도달했는지 파악

3. 도달 못하면 병목지점 파악


주의점

1. 적절한 부하 테스트 시간

2. 프로덕션 환경과 비슷한 데이터 셋팅

3. 프로덕션과 분리된 환경에서 테스트하기

4. 개인 컴퓨터에 ㄴㄴ 제한걸릴 때가 있다


1. 인프라 구성

Spring + RDS + ELB

 

2. 프로덕션 환경과 유사하게 부하 테스트

3. 병목지점 찾기

CPU

메모리

디스크

 

ec2 cpu

ec2 메모리

rds cpu

rds 메모

 

실시간 : top

 

가용성

이중

수평적 확장

수직적 확장

캐싱

 

EC2 병목 지점인 경우

1. 로직 개선

2. 정적 파일(S3, Cloudfront) 서버 분리

3. ELB를 활용해 수평적 확장

4. 수직적 확장

 

RDS 병목 지점인 경우

1. 쿼리 개선 (인덱스, SQL문 튜닝, 역정규화)

2. 수직적 확장

3. 읽기 전용 데이터베이스 도입

4. 캐시 서버 도입

 


1. 부하 테스트 목표 설정

2. 부하 테스트 진행

3. 병목 지점 파악 후 성능 개선

4. 개선한 시스템 부하 테스트 진


전문가가 알려주는 웹 퍼포먼스 튜닝

아마존 웹 서비스 부하 테스트 입

'트러블 슈팅' 카테고리의 다른 글

virtual thread  (0) 2025.05.02
예외 처리  (0) 2025.04.30
RDB 객체DB 객체  (0) 2025.04.23
JPA의 ddl-auto 옵션  (0) 2025.04.21
Spring Data JPA에서 새로운 Entity인지 판단하는 방법  (0) 2025.04.21