전체 글

현재 상황 병목현상 스테디 프로젝트는 메인 페이지에서 ‘좋아요’ 수 와 조회수를 기반으로 한 기간별 인기 모집 글을 보여주고 있습니다. 현재 개발 서버에는 300만 건의 데이터가 존재하고 인기 글의 기간 범위가 늘어날수록 Latency가 길어지는 문제가 발생하고 있었습니다. 인덱스를 적용했음에도 만족스러운 응답속도가 나오지 않았고 비슷한 서비스를 목푯값으로 잡아 성능을 개선해 보는 경험을 공유하려 합니다. 테스트 환경 nGrinder , nGrinde-agent VUser 150 (3/50) Ramp-Up 사용 10s → 1 Thread 증가 스크립트에 ThinkTime 700ms 현재 성능 VUser 수가 약 50 부터 1초 이상의 Latency가 발생하고 있습니다. RPS가 약 40 정도로 예상되는 ..

1. 캐시의 기본 개념 캐시(Cache)란? 캐시(Cache)란 일반적으로 자주 사용되는 데이터나 값을 미리 복사해 놓는 임시 저장소를 의미합니다. 컴퓨팅 분야에서는 이러한 캐시를 사용함으로써 데이터에 대한 접근 시간을 단축시키고, 전체적인 처리 성능을 향상시킬 수 있습니다. 다양한 수준에서의 캐시 사용 CDN(Content Delivery Network) CDN은 지리적으로 분산된 서버에 정적 컨텐츠를 캐시하여 클라이언트가 요청했을 때 가까운 서버(Edge Server)를 사용해 컨텐츠를 더 빠르게 전송시키는데 목적을 두고있습니다. 하지만 모든 서버에서 같은 컨텐츠를 갖고 있는것은 아닙니다.(비효율적) 클라이언트가 CDN을 사용해 요청을 보내면 탐색후 캐시에서 발견되지 않으면 원본 서버에서 컨텐츠를 가..

동시성 문제로 정합성이 깨지는 문제 해결 문제 상황 스테디 프로젝트 에서는 게시물에 눌린 좋아요 를 기준으로 인기 게시물을 보여주는 기능을 제공하고 있습니다. 그런데 이 좋아요 기능에는 현재 문제가 있는데 같은 게시물의 대해서 동시에 좋아요 요청이 들어오거나 따닥 문제가 발생했을 때 정합성이 깨지는 문제가 발생하고 있습니다. 아래 테스트 시나리오는 ExecutorService와 CountDownLatch를 사용하여 동일한 스터디의 대해서 유저가 좋아요 요청을 동시에 보내는 상황을 가정했습니다. @Test void updateSteadyLikeTest() throws InterruptedException { int threadCount = 50; ExecutorService executorService =..

문제 상황 현재 진행 중인 스테디 프로젝트는 개발이 거의 완료되었지만 아직 API의 성능이 검증되지 않아 더미 데이터를 추가한 후 QA 및 성능 테스트를 진행하며 개선하기로 했습니다. 더미 데이터를 약 300 ~ 600 만개를 삽입 후 테스트를 하던 중 모집 글 상세 조회 API 요청 소요 시간이 2초가 넘어가는 문제를 발견했습니다. 먼저, 구조를 파악해보겠습니다. 스테디는 많은 정보를 필요로 하고 정규화가 이뤄졌기 때문에 다른 엔티티들과도 연관관계를 많이 맺게 되었습니다. 사용자들은 빠른 응답을 기대하지만 처리시간이 길어지면 사용자 경험 저하와 이탈률이 상승할 거라고 생각했습니다. 그리고 서비스 측면에서도 처리 시간이 길어지면 동시에 처리해야 하는 요청의 수가 증가하고 서버 부하의 문제로도 직결된다고 ..

🪷 Grafana Loki Grafana Labs 에는 그라파나 외에도 Loki 라는 로그 집계 시스템이 존재합니다. Loki는 모든 애플리케이션과 인프라의 로그를 저장하고 쿼리할 수 있도록 설계된 로그 집계 시스템입니다. 🐛 1. Loki 설정하기 먼저, Grafana Loki를 모니터링 서버에 설치하고 구성해야 합니다. Loki는 로그 데이터를 받아들이고 저장하는 중앙 집중식 서비스 역할을 합니다. Loki를 통해 받은 로그를 S3와 같은 저장소에 저장할 수 있으나 우선은 로컬에 저장하도록 하겠습니다. 아래 명령어를 통해 loki 설정에 필요한 파일을 먼저 받아줍니다. wget https://raw.githubusercontent.com/grafana/loki/master/cmd/loki/loki-l..

이전 글에서는 스프링 부트에 의존성 추가와 메트릭 조회로 애플리케이션의 상태를 확인할 수 있었습니다. 하지만 상태확인을 매번 조회를 실행하면서 할 순 없습니다. 그래서 프로메테우스를 활용합니다. 🦾 프로메테우스 프로메테우스(Prometheus)는 단순히 모니터링 도구의 역할뿐만 아니라 메트릭을 수집하고 저장하며 쿼리, 시각화, 알림 등의 기능 또한 제공합니다. 🍸 주요 특징 메트릭 수집: 프로메테우스는 설정된 간격으로 메트릭을 수집하는 풀(Pull) 모델을 사용합니다. 이는 프로메테우스 서버가 구성된 대상에서 주기적으로 HTTP 요청을 통해 메트릭을 수집하는 방식입니다. 시계열 데이터베이스: 수집된 메트릭은 프로메테우스의 내장 시계열 데이터베이스에 저장됩니다. 이 데이터베이스는 고성능을 제공하며, 시간에..

단순히 모니터링 서버를 구축하기 위한 방법과 간단한 설명만 있습니다. 👉 단순히 모니터링 서버를 구축하기 위한 방법과 간단한 설명만 있습니다. 세부적인 지표와 옵션은 상황에 맞게 선택하셔야 합니다. 🍃 스프링 부트 의존성 추가 //build.gradle implementation 'org.springframework.boot:spring-boot-starter-actuator' implementation 'io.micrometer:micrometer-registry-prometheus' 스프링 부트 액츄레이터 (Spring Boot Actuator): 스프링 부트 액츄레이터는 스프링 부트 애플리케이션의 상태를 모니터링하고 관리하는 데 사용됩니다. 이는 여러 엔드포인트를 제공하여 애플리케이션의 다양한 측면..

이 블로그 포스트는 자바 기반의 Redis 클라이언트인 Jedis와 Lettuce를 탐구하는 내용입니다. Lettuce Lettuce는 논블락 방식의 Redis 자바 클라이언트입니다. 동기 및 비동기 통신을 지원합니다. 복잡한 추상화로 제품 확장을 쉽게 할 수 있습니다. 클러스터, 센티넬, 파이프라이닝 및 코덱 지원 등 고급 기능을 제공합니다. Jedis Jedis는 성능과 사용의 용이성을 위해 설계된 Redis 내부의 클라이언트 라이브러리입니다. 다른 Redis 자바 클라이언트에 비해 기능이 적지만, 많은 양의 메모리를 처리할 수 있습니다. 더 간단한 기능을 가지고 있어 사용하기 쉽지만, 클러스터와는 동기적으로만 작동합니다. Jedis를 선택하면 데이터 저장 메커니즘보다 애플리케이션과 데이터에 더 집중..