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

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

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

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

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

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

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

Elasticsearch, Fluentd, Kibana 를 사용하는 데이터 수집 및 시각화 스택입니다.ElasticSearch : 분산된 검색 및 분석 엔진. 수집한 대용량의 데이터를 인덱싱(엄밀하게 역인덱싱)하여 저장하고 이를 검색할 수 있는 기능 제공Fluentd
😮💨 문제 상황 스프링 로그들을 Fluentd에서 수집할 때 TCP 통신을 이용하기 위해 LogstashTcpSocketAppender를 통해 로그 수집하도록 구현했습니다. > 왜 LogstashTcpSocketAppender? TCP 통신을 위해 여러 TcpAppender들을 적용해보았지만 Fluentd에 어떠한 로그도 전달되지 않음을 확인했습니다...

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

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

모놀리식에서 MSA로 전환되며 필수적으로 서버 간 통신이 발생하게 됩니다.이 때, 만약 호출한 곳에서 트랜잭션 실패가 발생했을 때, 호출당한 곳에서 롤백이 되어야 하기 때문에 어떻게 롤백시킬지에 대해 고민해보았습니다.그 중, 입찰 API를 예로 들어 설명해보겠습니다.R

만약 서버 간 통신에 실패한다면 어떻게 처리를 하는게 좋을까요? 서버 간 통신 실패의 이유는 다양합니다. 개발자의 실수로 실패할 수도 있고, 네트워크 통신 문제로 실패할 수도 있고, 올바르지 않은 요청으로 인해 실패할 수도 있습니다. 어떤 이유로 실패하든 공통된 응

이전 글에서 장애에 대비해 Retry와 Backoff 전략을 설계하고 적용해두었습니다. 이번 글에서는 장애가 발생했을 때 개발자가 바로 알고 대처할 수 있도록 알림 보내는 것을 적용해보았습니다. 알림 전송 배치가 실패했을 때, 개발자에게 알림을 보낼 수 있도록 St