시리즈

all in auction

1.경매 종료 로직 구현

우리 시스템은 경매 관련해 아래와 같은 플로우로 진행이 됩니다. 사용자가 경매를 시작한다. ▷ 경매를 시작할 때, 경매 마감 기한을 입력받는다. 경매 마감 기한에 따라 경매가 종료된다. 경매가 종료되면 최고 입찰자에게 입찰 알림을 보내고, 판매자에게 판매금을 입금해준다. 이 때, 경매는 사용자의 요청에 따라 마감 기한이 모두 다르기 때문에 마감된 경...

2024년 11월 6일

2.[오류 해결] Bean is not eligible ... BeanPostProcessor

Spring Batch 5를 통해 쿠폰 만료 처리 배치를 구현하던 도중, 배치 자체는 이상없이 돌아가지만 로그에 아래와 같은 WARN이 잔뜩 뜨는 것을 확인했다.찾아보니 Spring Boot 3.2와 Spring Batch 5.0 이상에서 발생하는 문제로, 근본적으로

2024년 11월 28일

3.Spring Batch 성능 최적화

사용 기한이 지난 쿠폰은 사용자에게 보이면 안되기 때문에 매일 정시에 사용자에게 보이지 않도록 처리하는 쿠폰 만료 배치를 개발했습니다. 성능 최적화 전 테스트 조건 만료일이 지나 삭제해야 하는 사용자의 쿠폰 2,000,000개 최적화 전 배치 처리 설정 Sprin

2024년 11월 22일

배치 최적화 이후 실행 시간이 지나치게 단축되어 장애가 발생할 수도 있겠다는 우려가 있었습니다. 그렇기에 장애를 사전에 예방하고자 Retry와 Backoff 전략을 설계하고 적용하였습니다. 장애는 여러 가지 원인으로 발생할 수 있지만, 데이터베이스 관련 일시적인 장애가 발생한 경우를 제외하고는 재시도가 성공할 가능성이 낮다고 판단했습니다. 이에 따라, S...

2024년 11월 28일

5.RabbitMQ 장애 방지와 부하 분산

현재 경매 종료의 경우, RabbitMQ의 Delayed Queue를 이용해 경매 종료 시점을 감지할 수 있도록 설계되었습니다. 그러나 RabbitMQ가 단일 노드로 구성되어 있어 장애 발생 시 경매 등록과 종료 처리에 문제가 생기며, 메시지 부하로 인한 성능 저하의 가능성이 있어 성능 개선이 필요하다고 판단했습니다. RabbitMQ Cluster Ra...

2024년 11월 29일

6.RabbitMQ Sharding with RabbitMQ Plugin (1)

이전에 RabbitMQ 클러스터링 + 해싱을 통한 메시지 분산을 통해 Queue의 부하를 줄이려는 시도를 했던 적이 있습니다. 현재는 3개의 노드, 그리고 3개의 큐로 고정이 되어 있는데 만약 노드가 더 늘어나고 큐가 늘어난다면 이벤트를 소비하는 부분이나 큐를 정의하는 부분에 수정이 필요하게 됩니다. 이를 해결하기 위한 방법으로 RabbitMQ Shard...

2025년 11월 5일

7.RabbitMQ Sharding with RabbitMQ Plugin (2)

RabbitMQ Sharding with RabbitMQ Plugin (1)로부터 이어집니다! 😮‍💨 문제 상황 이제 3개의 노드에 존재하는 모든 샤드에서 메시지를 받아볼 수 있으리라고 생각했는데요 .. 네 . . .. 이상하게도 3번 노드, 0번 샤드의 메시지

2025년 11월 10일

8.ELK Vs. EFK

Elasticsearch, Fluentd, Kibana 를 사용하는 데이터 수집 및 시각화 스택입니다.ElasticSearch : 분산된 검색 및 분석 엔진. 수집한 대용량의 데이터를 인덱싱(엄밀하게 역인덱싱)하여 저장하고 이를 검색할 수 있는 기능 제공Fluentd

2024년 12월 1일

9.[오류 해결] EFK TCP 통신

😮‍💨 문제 상황 스프링 로그들을 Fluentd에서 수집할 때 TCP 통신을 이용하기 위해 LogstashTcpSocketAppender를 통해 로그 수집하도록 구현했습니다. > 왜 LogstashTcpSocketAppender? TCP 통신을 위해 여러 TcpAppender들을 적용해보았지만 Fluentd에 어떠한 로그도 전달되지 않음을 확인했습니다...

2024년 12월 2일

10.CQRS (Command Query Responsibility Segregation)

CQRS 도입 이유 V2 개발 완료 후, 1000명이 동시에 입찰을 시도하는 부하 테스트를 진행했습니다. 테스트 결과, 입찰 API의 평균 응답 시간은 8.5초로 나타났습니다. 이는 팀 내 다른 로직들의 평균 응답 시간(1초 내외)에 비해 현저히 느린 수치였습니다. 문제를 분석한 결과, 입찰 로직에서 3번의 DB 조회와 2번의 DB 업데이트로 인해 DB ...

2024년 12월 17일

11.API Gateway

MSA로 전환하면서 각 서버마다 다른 URL을 가지게 되었고, 이로 인해 프론트에서 여러 URL을 관리하게 되었습니다. 그러나 프론트에서 여러 URL을 관리하는 것은 비효율적이기 때문에, 서비스 단일 진입점이 필요하다고 판단하여 API Gateway를 도입하게 되었습니