[Pagely] 3. 1차 성능 개선

[Pagely] 1. 모니터링 도입과 부하 테스트[Pagely] 2. 1차 부하 테스트 결과 분석[Pagely] 3. 1차 성능 개선기존 부하테스트 결과 정리CPU 사용량 약 27% 로 자원은 여유로움현재 상황에서는 DB Connection pool 설정을 늘리면 성능 병목을 완화할 수 있다고 판단 됨혹은 캐시 도입으로 DB 부하를 나눈다면 병목을 완화 할 수 있을거라 생각RPS 800구간 에서 병목지점을 확인하였고, 이 이상의 break point 를 찾기위한 부하 테스트는 테스트 환경의 성능상 어렵다고 판단테스트 시나리오가정상세조회 도서가 DB에 모두 존재함 (1000건)좋아요 등록, 취소는 중복 요청이 들어올 수 있음유저 행동에는 Thinktime 존재(0.5s~2.5s, 기댓값 1.5 내외)총 테..

• format_list_bulleted Spring_Project/기타
• · 2026. 5. 29.

[Pagely] 2. 1차 부하 테스트 결과 분석

[Pagely] 1. 모니터링 도입과 부하 테스트[Pagely] 2. 1차 부하 테스트 결과 분석[Pagely] 3. 1차 성능 개선스트레스 테스트 부하 시나리오가정상세조회 도서가 DB에 모두 존재함좋아요 등록, 취소는 중복 요청이 들어올 수 있음유저 행동에는 Thinktime 존재(0.5s~2.5s, 기댓값 1.5 내외)최대 vu 5000, 최대 rps(실제 측정값) 1400테스트 시간 : 14분각 읽기/쓰기 비율도서 상세 조회(읽기 ): 80%도서 좋아요 등록(쓰기): 15%도서 좋아요 취소(쓰기): 5%각 요청 별 설정한 임계치상세 조회 : p95 좋아요 : p95 실패율 : 10%vu 500 시작, vu 5000종료500 → 1000 → 2000 → 3000 → 4000 → 5000각 구간 ram..

• format_list_bulleted Spring_Project/기타
• · 2026. 5. 29.

[Pagely] 1. 모니터링 도입과 부하 테스트

[Pagely] 1. 모니터링 도입과 부하 테스트[Pagely] 2. 1차 부하 테스트 결과 분석[Pagely] 3. 1차 성능 개선모니터링 도입과 부하테스트모니터링 도입에 앞서, 모니터링이 필요했던 이유와 맥락을 설명도입 배경모니터링은 서비스의 안정성을 보장하기위해 필요한 수단서비스의 안정성을 보장한다라는 것은 반대로, “어떤 서비스 상태가 안정적이지 못한가?” 라는 기준이 있어야 판단 가능맥락서비스 상태를 판단 할 기준 선정을 위해 SLO, SLA 필요SLO 설정을 위해선 SLI 측정이 선행되어야 함SLI 즉, 서비스 지표를 측정할 매트릭 정보 수집, 시각화, 분석의 필요성모니터링 도입 후에는 본래 목적인 SLO,SLA 설정을 위해 서비스 장애 지점을 파악해야 함그리고, 장애 지점을 파악하기 위해서는..

• format_list_bulleted Spring_Project/기타
• · 2026. 5. 29.

퍼센타일 지표와 해석법

P95, P99 지표💡지표는 숫자가 아니라행동 기준이 될 때 의미가 있음전체 데이터를 정렬했을 때, 하위 n% 지점에 해당하는 값즉, 99P는 시스템의 평균 상태가아닌, 가장 불행한 사용자를 가리킴퍼센타일은 성능 지표이면서 경험 지표평균의 함정에 빠지지 말자평균 200ms 응답 속도 일지라도, 하위 10명의 응답 속도는 10s 일 수 있음P95가 먼저 흔들리는 이유큐가 생기기 시작하면 지표는 아래의 순서대로 무너진다.평균 → 거의 그대로P95 → 서서히 상승P99 → 급격히 폭등타임아웃 → 폭증P99 만 보면 되는가?P99 만 보면, 이미 늦은 상태P50 만 보면, 아무것도 안보임P95 는 구조의 신호P99 는 장애의 신호기준선 잡는 법💡이 요청은 몇 ms를 넘기면 사용자에게 ‘느리다’로 인식 될까?..

• format_list_bulleted 정리/Monitoring
• · 2026. 5. 17.

모니터링 도구 연동 가이드 Prometheus + Grafana

Spring Actuator, Prometheus, Grafana 기준기본 동작 흐름Spring Application 으로 Prometheus 가 일정 주기로, Actuator 엔드포인트를 통해 매트릭 정보를 수집 (/actuator/prometheus)Prometheus 는 해당 매트릭 정보를 저장Grafana는 데이터 소스로 해당 Prometheus를 설정하여, 매트릭 정보를 시각화Prometheus & Grafana Docker compose디렉토리 구조임의로 infra-repo 쪽에 구성했지만, 정해진 내용이 아니므로 지금은 각자 서비스에서 구현하는 걸 권장디렉토리 구조만 예시로 참고docker-compose./docker-compose.monitoring.yamldocker-compose.mon..

• format_list_bulleted 정리/Monitoring
• · 2026. 5. 15.

DB Lock

DB Lock데이터베이스에서 여러 트랜잭션이 동시에 같은 데이터에 접근할 때, 데이터의 무결성을 보장하기 위해 사용되는 메커니즘쉡게 말해, 한 트랜잭이 특정 데이터에 대해 작업을 하고 있을 때 다른 트랜잭션이 그 데이터에 접근하지 못하도록 잠그는 것이로써 데이터의 일관성을 유지하고, 동시에 발생할 수 있는 충돌을 방지할 수 있음DB Lock의 필요성데이터베이스는 여러 사용자나 시스템이 동시에 데이터를 읽고 쓰는 환경에서 운영이런 환경에서 발생할 수 있는 대표적인 사례Dirty Read한 트랜잭션이 데이터를 수정 중일 때 다른 트랜잭션이 그 데이터를 읽는 상황. 만약 첫 번째 트랜잭션이 롤백된다면, 두 번째 트랜잭션은 잘못된 데이터를 읽은 것트랜잭션 A가 고객의 은행 계좌 잔액을 수정하고 1000원을 더함..

• format_list_bulleted 정리/MSA
• · 2026. 4. 16.