분류 전체보기 (44) 썸네일형 리스트형 피드백 생성 요청의 비동기 아키텍처 전환 배경 및 구조 설계 1. 배경: 동기식 피드백 처리 구조의 한계초기 시스템은 사용자가 주간 활동 피드백을 요청하면, 프론트엔드(FE)에서 백엔드(BE)로 HTTP POST 요청을 보내고, BE는 다시 인공지능(AI) 서버에 HTTP POST 요청을 전달하는 동기식 처리 구조를 가지고 있었다. 즉, 전체 플로우는 다음과 같았다:[FE] → [BE] → [AI 서버] ↓ [메시지 큐 등록 → 처리] ↓ [AI → BE] 결과 POST AI 서버는 받은 요청을 자체적으로 내부 메시지 큐(GCP Pub/Sub or Redis Queue)에 적재하고, 큐에서 하나씩 꺼내 순차적으로 주간 활동 피드백을 생성한 뒤, 해당 결과를 다시 B.. 타임딜 목록 조회 시 상태값이 로컬과 서버에서 다르게 표시되는 문제 (UTC → KST) 트러블슈팅 로그 문제 요약타임딜 목록 API(/api/store/products/timedeals) 조회 시,로컬(KST) 환경에서는 상태값이 정상적으로 "ONGOING"으로 표시됨Dev 서버(UTC)*에서는 같은 타임딜이 "UPCOMING"으로 잘못 표기됨예시 타임딜:startTime = 2025-06-12T16:00:00조회 시점: 정확히 2025-06-12T16:00:00기대 상태: ONGOING실제 서버 응답 상태: UPCOMING원인 분석서버의 시스템 시간대가 UTCLocalDateTime.now() 기준이 UTC로 계산됨startTime이 16:00인데 서버 현재 시각은 07:00으로 인식되어 아직 시작되지 않은 것으로 판단됨Docker 컨테이너 시간도 UTCJVM 내부 시간과 동일하게 잘못 계산됨applic.. Kakao Redirect URI mismatch (KOE303) 트러블슈팅 로그 이슈 요약문제 현상: 배포 환경(docker-local)에서 카카오 로그인 시 KOE303 오류 발생정상 동작: 로컬(local) 환경에서는 정상 로그인됨오류 메시지: { "error": "invalid_grant", "error_description": "Redirect URI mismatch.", "error_code": "KOE303" }발생 일시2025.06.10 오후상세 증상로컬(local)에서는 .env.local에 설정된 kakao_redirect_uri=https://leafresh.app/member/kakao/callback 값과 Kakao Developers 콘솔 등록 값이 일치하여 로그인 성공.docker-local(dev) 환경에서는 .env.docker-loc.. Chatbot SSE 기능 구현 트러블슈팅 로그 문제 정의:AI 챗봇 추천 결과를 FE에 실시간 스트리밍으로 전달해야 하는 요구사항이 있었다.FE → BE → AI → BE → FE 흐름에서, AI가 보낸 SSE 응답을 포맷 그대로 FE에 중계해야 하며,FE는 각 이벤트별로 event: challenge, event: close 등을 수신하고자 했다.초기 문제 1 – 단순 문자열 Flux로 수신하면 이벤트가 깨지는 현상시도초기에는 WebClient .bodyToFlux(String.class) 형태로 AI의 응답을 수신하고 \n\n을 기준으로 메시지를 자른 뒤 SseEmitter.send()로 전달했다.문제event: 와 data: 헤더가 한 줄 이상으로 나뉘는 경우 정상 전송되지 않음일부 클라이언트에서 이벤트가 하나로 병합되거나 파싱되지 않음AI 서.. Redis Lua·Pub/Sub 기반 주문 처리 시스템 구축기 1. 문제 정의사용자 경험 주문 요청이 몰리는 시점에도 대기 없이 즉시 응답을 반환하여 구매 전환율을 극대화해야 합니다.고민: 동기 처리만으로는 한 번에 몰리는 트래픽을 감당하기 어려워 API 응답이 지연될 수 있었습니다.해결: 주문 요청과 실제 주문 처리(재고·결제·저장)를 분리하여, 사용자에게는 “주문 접수 완료”만 빠르게 응답하도록 비동기 메시징을 도입했습니다.재고 일관성 보장 동시성 높은 환경에서 재고가 음수로 내려가지 않도록 과매진(over-sell)을 방지해야 합니다.고민: DB에서 SELECT → UPDATE 방식으로 재고를 차감하면, 트랜잭션 격리 수준을 높여야 하지만 성능 저하가 우려되었습니다.해결: Redis에 Lua 스크립트를 배포하여 GET과 DECRBY를 단일 원자 연산으로 실.. Redis 기반 통계 동기화 시스템에서의 캐시 누락 및 지수적 증가 문제 문제 상황조회수·댓글수·좋아요수 등 인증 통계는 Redis에 캐싱된 값을 기준으로 DB와 일정 주기마다 동기화되도록 설계되어 있었다.그러나 다음과 같은 현상이 반복적으로 발생하였다:동기화 로그에서 조회수 +2048, 댓글수 +8 등 지수적으로 증가한 값이 로그에 찍힘실제 DB에는 댓글이 11개인데, Redis에서는 commentCount = 57 등 불일치된 수치가 기록redis-cli로 확인한 결과, verification:stat:2 키가 존재하지 않음 → Redis 캐시 자체가 누락된 상태127.0.0.1:6379> keys verification:stat:2(empty array)그럼에도 불구하고 동기화 스케줄러는 캐시 값 - DB 값으로 delta를 계산하여 DB에 누적 반영하였기 때문에 증분이.. @PostConstruct에서 ClassCastException 발생 – JPA 쿼리 반환 타입 이슈 상황 설명@PostConstruct로 실행되는 VerificationStatCacheInitializer.initializeVerificationStats() 내부에서 GroupChallengeVerificationRepository.findAllViewCountByVerificationId() 결과를 기반으로 Redis 캐시를 초기화하는 로직을 구현했다.해당 쿼리는 다음과 같은 JPQL 형태로 작성되어 있음:@Query("""SELECT v.id, v.viewCountFROM GroupChallengeVerification vWHERE v.deletedAt IS NULL""")List findAllViewCountByVerificationId();해당 결과를 다음과 같이 처리 중이었음:for (Obje.. 상품 구매 처리 흐름 및 멱등성 보장 방식 1. 일반 상품 구매 처리 단계 요약1. 요청 수신 (Controller)인증된 사용자로부터 productId, quantity, idempotencyKey 를 입력받음2. Idempotency 키 저장 (purchase_idempotency_keys)memberId + idempotencyKey 조합으로 선 저장 (unique 제약)동일한 키 재요청 시 DataIntegrityViolationException 발생 → 중복 처리 방지목적: 중복 요청 방지 및 재시도 상황 대비3. 재고 선점 (Redis Lua Script)Redis에서 DECRBY 명령으로 재고 차감 시도재고 없음: 1, 수량 부족: 2 반환실패 시 예외 발생 → 트랜잭션 종료4. 구매 요청 비동기 발행 (GCP Pub/Sub)Purc.. 이전 1 2 3 4 ··· 6 다음
