복잡한 QueryDSL 쿼리, 문제 배경사용자 질의 기록을 분석하여 분석 결과 요약 리스트를 제공하는 API를 개발하면서, 다음과 같은 기능 요구사항이 있었습니다특정 기간 내 사용자 요청을 기준으로 응답/미응답 여부를 필터링분석 결과는 3가지 알고리즘 (a 분류, b 분류, c 유사도) 별로 각각 존재분석 결과 외에도 시나리오 정보, 엔티티 탐지 정보 등 다양한 부가 정보도 함께 보여줘야 함즉, 기준 테이블(A)에서 다수의 결과 테이블(B, C, D)를 각각 조인 또는 별도로 조회해야 하는 상황이었고, 단일 쿼리로 모든 결과를 가져오면 다음과 같은 문제가 있었습니다알고리즘마다 JOIN이 추가되며 성능 저하 발생응답/미응답 여부 판단을 위해 알고리즘별 조건이 달라 별도 조건 분기를 동적으로 처리해야 함UI..

AI 백엔드 팀으로 이직 후 작성하는 첫 회고록이다.새로운 환경에서 업무를 시작하면서 가장 먼저 중요하게 여긴 것은 도메인 파악이었다.이를 빠르게 진행하기 위해 설계도와 프로젝트 셋업을 우선적으로 시작했다. 이 프로젝트는 MSA 환경에서 동작하는 멀티 모듈 기반이었으며, 브랜치 전략 또한 이전 회사와 달라서 별도로 분석이 필요했다. 업무 중 자사 서비스를 이용하며 API를 살펴보던 중, 하나의 Request 객체가 여러 Controller에서 전역적으로 사용되고 있다는 점을 발견했다. 다양한 곳에서 재사용되는 구조였지만, 필드에 @Nullable 등의 명시적 제약이 없어 어떤 필드가 필수인지 파악이 어려웠다. API 명세서는 postman, request 파일, openapi 파일 등으로 따로 관리되고 ..

(대규모 대기열 접속 시스템에서 최소의 자원으로 최대의 효율을 내기 위한 방법을 공부하던 중 기록하게 되었습니다.) Redis의 기본 방식에서는 여러 개의 명령어 실행 시 네트워크 왕복 비용이 증가한다.LUA 스크립트는 Redis 서버 내부에서 실행되므로, 네트워크 왕복을 줄이고 성능을 향상.캐싱된 LUA 스크립트를 EVALSHA로 실행하면 추가적인 성능 최적화 가능.LUA 스크립트로 변환해야 할 주요 메서드대기열 등록 (registerWaitQueue)→ ZADD를 사용하여 사용자 추가 (이미 존재하는 경우 추가 방지)사용자 입장 허용 (allowUser)→ ZPOPMIN으로 대기열에서 사용자 추출 후 진행 목록에 추가→ TTL 설정 추가 (EXPIRE)즉, 반복되는 작업을 레디스 내에서 동작하도록 하..

FIlter Spring Cloud Gateway에서 Filter는 요청(Request) 및 응답(Response)을 처리하거나 변환하는 데 사용된다. 필터를 설정 이유공통 로직 처리:모든 요청에 대해 동일한 작업(예: 인증, 로깅)을 중앙에서 처리가 가능하다.유연한 요청 처리:서비스별로 맞춤형 필터를 적용해 요청을 동적으로 변환이 가능하다.관리와 확장성:개별 서비스에 중복 코드를 작성할 필요 없이 Gateway에서 일괄 관리 가능하다..yml 필터 작성server: port: 8000eureka: client: register-with-eureka: true fetch-registry: true service-url: defaultZone: http://localhost:8..

Spring Cloud Netflix EurekaService DiscoveryEureka는 Spring Cloud Netflix에서 제공하는 서비스 디스커버리 도구로, MSA 환경에서 각 서비스의 위치(IP와 포트)를 동적으로 관리한다.서비스 디스커버리란?MSA에서는 각 서비스가 독립적으로 배포되고 확장되므로, 고정된 IP와 포트를 사용하는 것이 어렵다.Eureka는 서비스 레지스트리로 작동하여 각 서비스의 위치 정보를 등록하고, 다른 서비스가 이를 검색할 수 있도록 돕는다.Eureka Server와 Eureka ClientEureka Server: 모든 서비스의 위치 정보를 저장 및 관리.Eureka Client: 애플리케이션이 Eureka Server에 자신의 위치를 등록하거나, 다른 서비스의 위치..

미납 회수를 위한 연체 이자 도입 기획구독 시스템의 미납 회수율을 개선하고, 결제 없이 서비스를 지속적으로 이용하는 연체 사용자 문제를 해결하기 위해 연체 이자 시스템을 도입하고자 합니다.주요 신용카드사의 연체 관리 방식을 참고하고, 관련 법적 요구 사항을 기반으로 구체화하였습니다.현재 로직 분석1. 미납 결제 시도 시bill_id가 존재하는지 확인가장 최근 데이터의 status 확인status = success이면 정상 결제 완료 → 결제 시도 ❌status != success이면 미납 상태 → 결제 재시도 retry_count에 따라 이자율 증가2. 문제점같은 구독자라도 연체 기간이 다르면 부담하는 이자가 다를 수 있음현재 방식은 retry_count만 고려하여 이자율을 증가시키기 때문에, 장기 연체..

전기 자전거 구독 서비스 - 초과 구독 문제 해결하기 🚴‍♂️⚡️문제 상황: 초과 구독 발생구독 서비스에서 동시에 다수의 사용자가 신청을 시도하면서, 실제 잔여 재고보다 더 많은 예약이 이루어지는 문제가 발생.문제 시나리오확정 재고: 180대사용자가 동시에 구독 버튼을 누르면, 180대 이상이 예약될 가능성이 있음특정 사용자가 구독을 신청하는 동안, 다른 사용자의 요청도 처리되면서 재고 초과 결제 문제 발생결제 페이지에 초과된 사용자가 진입하면, 불필요한 결제 시도를 경험하게 됨해결 목표최대한 사용자가 재고보다 많은 인원이 결제 페이지에 접근하지 않도록 제한불가피하게 결제 페이지까지 초과 인원이 들어왔다면, 안정적으로 초과 결제되지 않도록 관리해결 방법1차 방어: 결제 페이지에 초과 인원이 접근하지 못..

Redis Pub/Sub - 모니터링 w/ Prometheus & Grafana1. Redis Pub/Sub (Publish/Subscribe) 패턴Pub/Sub란?Redis의 Pub/Sub(Publish/Subscribe)는 메시지 브로커 역할을 수행하며, 클라이언트 간의 실시간 메시징을 가능하게 한다.Publisher:특정 채널에 메시지를 발행하는 역할.Subscriber:특정 채널을 구독하고, 발행된 메시지를 수신.Redis Pub/Sub의 특징:In-Memory 기반으로, 매우 빠른 메시징 속도 제공.비동기 방식으로 실시간 처리 가능.메시지는 발행 시점에만 전달되며, 서버 다운 시 누락 가능.MSA(Microservices Architecture)에서의 활용:비동기 메시징을 통해 서비스 간 결합도..

Redis: In-Memory Database로의 활용과 성능 분석Redis란?Redis(Remote Dictionary Server)는 데이터를 메모리에 저장하여 빠른 데이터 처리와 높은 성능을 제공하는 In-Memory Database이다.디스크 대비 매우 빠른 응답 속도를 제공하며, 다양한 데이터 타입과 기능을 통해 데이터베이스, 캐시, 메시지 브로커 등으로 활용 가능하다.Redis의 특징In-Memory Database:데이터를 메모리에 저장하여 빠른 읽기/쓰기 속도 제공.휘발성 데이터로 기본적으로 시스템 종료 시 데이터가 삭제되지만, 데이터 영구화를 위한 옵션 제공.다양한 데이터 타입:Strings, Lists, Sets, Hashes, Sorted Sets 등 다양한 데이터 구조 지원.데이터 ..

온라인 결제 시스템을 개발하다 보면, 결제 요청이 성공했음에도 불구하고 네트워크 장애로 인해 응답을 받지 못하는 상황이 발생할 수 있습니다.이 경우, 결제는 성공했지만 서비스에서는 실패로 인식하는 문제가 발생할 수 있으며,이는 결제 데이터 정합성을 해치는 주요 원인이 됩니다. 따라서, Toss Payments 결제 API를 활용하면서 네트워크 장애 시 결제 상태를 보장하는 Fallback 처리 방식을 정리해 보겠습니다. 결제 흐름은 아래와 같은 순서로 진행됩니다.POST /v1/billing/{billingKey} 요청을 통해 결제 시도정상적으로 결제 완료 후, 결제 완료 응답을 받아서 데이터 저장고객에게 결제 완료 메시지 전달하지만, 결제 완료 후 네트워크 장애가 발생하면 어떻게 될까요?실제 결제는 성..