📑 로그

이전 Scale-Out 과정에 대해 다룬 글에서 Blocking 모델의 한계점으로 인한 병목지점에 대해 언급했다. 이에 대해서 다시 한번 간단하게 이야기 하자면 Spring MVC와 톰캣을 사용할 경우 애플리케이션 레벨에서는 인터셉터, 필터, 디스패처 서블릿 등 다양한 이유로 요청이 Blocking 모델을 기반으로 처리된다. 이로 인해 I/O 작업을 진행하는 동안 스레드가 Timed-Waiting 상태를 유지하게 되고 CPU를 효율적으로 사용하지 못하게 된다. 그 결과 부하테스트시 아래와 같이 최대 200개 이상의 스레드가 Timed-waiting 상태를 유지하며, 부하를 계속해서 늘리더라도 CPU 사용률이 60~80%를 넘어가지 않는 것을 확인할 수 있다. 이 문제를 해결하기 위해서 Non-Blocki..

지난 부하테스트에서 Blocking 작업으로 인해 CPU 사용률이 70%에 머무는 문제에 대해 다뤘다. 그러나 Blocking 작업이라고는 Redis 요청밖에 없는 상황에서 이는 너무 낮은 수치라고 생각했다. 또한  이때까지 부하테스트를 진행하면서 항상 부하테스트의 진폭이 왜이렇게 크지...가끔씩 왜 그래프가 튈까...와 같은 생각을 항상 해왔다. 이러한 의문을 해결하기 위해 인프라의 모든 부분을 내가 완벽하게 통제할 수 있도록 바꾸고, 이를 통해 문제점을 찾고자했다.    ☑️ Ngrinder Agent와 Controller 분리 기존에는 부하테스트 툴로 사용하던 Ngrinder의 Agent와 Controller를 하나의 PC에서 사용했다. 이때 두 구성 요소가 CPU, 메모리, 네트워크 I/O 등 같..

☑️ 고가용성과 장애내구성 부하테스트 중 WAS가 실행되고 있는 EC2가 중지되거나 문제가 발생했다. 서비스가 실제로 운영되는 중에 이와 같은 현상이 발생하면 안되기 때문에 고가용성 인프라를 구축하게 되었다. 이는 성능 개선과 직접적으로 관련있는 것은 아니지만 서비스를 운영함에 있어서 성능보다 중요한 요소일 수 있다고 생각하기 때문에 이전 글의 성능 개선에 이어 고가용성과 장애내구성, 확장성을 보장하고자 노력했던 경험을 글로 남겨보고자한다.  먼저 고가용성이라는 용어에 대해서 알아보자. 고가용성은 복원력과 관련된 용어이며 말 그대로 높은 가용성을 의미한다. 자세하게는 장애가 발생했을 때 서비스를 정상적으로 유지하고 제공할 수 있는 능력을 나타낸다. 예를 들어, 시스템이 100시간 중 1시간동안 의도치않게..

☑️ Scale-Out 적용 배경 및 목표이전 글에서 Redis와 Lua Script를 도입하면서 Scale-up을 진행했다. Scale-up을 계속해서 해 나간다면 단일 서버의 자원을 증설함으로써 처리 용량을 증가시키는 방식으로 일정 부분까지 효과적이지만 비용적인 한계와 하드웨어의 성능적 한계에 부딪힐 수 있다. 따라서 Scale-out을 통해 다수의 WAS 서버에 부하를 분산시키고 Auto Scaling과 로드밸런서를 적용하여 시스템의 유연성과 확장성을 확보하고자 했다.   Scale-Out 설계 💠 주요 변경 사항WAS EC2 인스턴스 추가 - 기존 인프라에 추가적으로 WAS EC2 인스턴스를 배치하여 다중 서버 환경을 구성했다.Application Load Balancer 배치 - ALB를 통해..

☑️ Scale-Up 이전 글에서 말한 근거를 바탕으로 Scale-up (1vCpu, 1GB RAM → 2vCpu, 2GB RAM) 한 결과, 평균 TPS가 1093까지 증가했으며, 평균 응답 시간은 167ms로 감소했다. 하지만 아래 부하테스트 결과에서 볼 수 있듯이, 간헐적으로 TPS가 대폭 감소하는 현상이 발생했다.  문제 원인을 찾기위해 Pinpoint를 확인한 결과, TPS가 감소한 시점마다 캐시가 만료되어 다수의 요청이 DB로 향하고 있었고 Redis에 캐시를 적재하는 무의미한 중복 쓰기가 계속해서 일어나는 것을 확인할 수 있었다. 이러한 현상을 Cache Stampede 라고 한다. DB 조회 시간이 오래걸리거나 DB 리소스가 충분하지 않은경우 Cache Stampede는 치명적이다. 만약 ..

목차부하테스트인덱스 개선EC2 Redis VS ElasticacheScale-upCache Stampede (TTL, 분산락, PER)Lua ScriptScale-out고가용성 인프라 구축Virtual Thread 적용과 Pinning 문제  성능 테스트에 대해 작성한 이전 글 마지막 부분에서 볼 수 있듯이, 실제 서비스용 DB 서버에서는 이미 여러개의 쿼리가 실행 중일 것이고 이에 따라 자원을 점유하기 위한 경합이 발생할 것이므로 일반적으로 테스트보다 느린 성능을 보일 것이다.이러한 점을 고려하여 이번 부하 테스트에서는 다양한 파라미터를 가진 API를 요청하고 API의 요청 비율을 정규 분포를 통해 조절하는 등 실제 운영 환경과 최대한 유사하게 구성하고자 했다.    ☑️ 부하 테스트 아키텍처 부하 테..