모니터링과 부하테스트
1.AWS Auto Scaling Group EC2 WAS 대상Actuator Prometheus Grafana Micrometer 모니터링 적용
AWS로 Spring Boot Web Application Server를 배포하고 이를 운영하던 중 해당 WAS가 원인 모르게 종료되거나 하는 일이 종종 발생했습니다. Auto Scaling Group을 적용 했었기에 자동적으로 복구 되었지만 어떤 원인으로 해당 문제가
2.Perfomance Test - 백엔드 아키텍처 병목 확인.
Load TestingLoad Testing은 부하가 임계치(Threshold Value)에 도달할 때까지 시스템의 부하를 지속적으로 증가시키면서 시스템을 확인하는, Performance Testing의 한 유형입니다. 여기서 부하를 증가시킨다는 것은, 동시단말사용자(
3.Scalability Test - Thread Pool, DBCP 적정 설정값 찾기.
0. 이전 포스트 이전 포스트 이전 포스트에서 테스트 시나리오, 테스트 장애지점, 테스트 병목원인에 대해서 분석하여습니다. 이번 포스트에서는 해당 병목을 해결하기 위해서 Thread pool, DBCP적정 값을 설정해보려고 합니다. 1. Thread pool 1-1
4.캐시 정의 및 전략 별 장단점 정리.
캐쉬란 데이터 요청 주체와 메모리 저장공간 사이에 위치하면서 메모리 저장공간에 대한 조회 요청을 앞에서 먼저 대신 처리해주는 저장장치이다.데이터 요청자는 먼저 cache에서 원하는 데이터가 존재하는지 찾아보고 있는 경우 cache의 데이터를 가져가고 없는 경우 원본 데
5.DB 병목 분산 캐시(Redis) 해결 기록
1. 문제 상황 및 원인 서버 튜닝이후 자원들을 적절하게 사용하게 되어 4배가량 TPS를 올릴 수 있었지만 MYSQL에 병목이 발생하였음. 2. 해결 방법 캐시를 통해 조회 부하를 분산하여 해결하기로 결정하였음. 이 과정에서 캐시 전략및 트레이드오프를 고려하여 적절
6.Hot key Cache Stampede와 Probabilistic Early Recomputation 적용
0. 작성 배경 이전 포스트에서 읽기 부하를 분산시키기 위해 Redis Cache를 활용하였습니다. 이때, TTL을 5초로 두게 되었는데 캐싱과 관련된 내용들에 대해서 더 학습하게 되면서 Hot key에서 발생할 수 있는 여러 문제점들에 대해서 알게 되었습니다. Hot