박재홍

문제

구매 결정 한 번에 위시 상태, 월 예산, 리마인더, 결정 이벤트가 함께 바뀝니다. 일부만 반영되면 예산과 결정 결과가 어긋납니다.

해결

• 결정 관련 변경을 하나의 트랜잭션으로 처리하고, 결과 조회 시 최신 상태가 아니라 결정 당시 이벤트를 반환
• 서비스 검증에 더해 CHECK·UNIQUE·partial index·trigger로 음수 금액, 셀프체크 범위, 활성 중복 데이터를 DB 레벨에서 차단

검증

H2 대신 Testcontainers PostgreSQL로 Flyway 마이그레이션, JSONB, partial index, trigger를 실제 DB에서 검증

문제

같은 상품을 다시 고민하는 건 정상 요청이지만, 더블탭이나 timeout 재시도로 같은 요청이 두 번 저장되면 안 됩니다. 내용 기반 중복 제거로는 둘을 구분할 수 없었습니다.

해결

Idempotency-Key 계약과 사용자별 partial unique index로 "같은 요청의 재전송"만 걸러내고, 같은 내용의 새 요청은 허용

create unique index uk_saved_items_user_idempotency_key
    on saved_items(user_id, idempotency_key)
 where idempotency_key is not null;

문제

상품 링크 분석은 브라우저(Playwright) 크롤링이라 느리고 무겁습니다. 동기 API로 두면 요청이 몰릴 때 서버 스레드와 브라우저 자원이 함께 묶입니다.

해결

• PostgreSQL 작업 테이블(PENDING → RUNNING → SUCCEEDED/FAILED)과 FOR UPDATE SKIP LOCKED 기반 worker로 비동기 처리, 202 + Location 응답
• 전체 큐 100개·사용자별 활성 작업 상한, 포화 시 429. 중단된 RUNNING 작업 재시도와 최대 시도 후 실패 처리
• 여러 사용자의 같은 URL 요청은 대표 작업 1건만 크롤링하고 결과를 전파, 성공 5분·실패 30초 단기 캐시
• 외부 브로커 대신 DB 큐를 고른 이유와 재검토 조건을 ADR로 기록

검증

작업 큐 통합 테스트와 전체 554개 테스트 통과, 전후 비교용 부하 테스트 도구(p50/p95/p99·오류율) 작성

문제

마이페이지 목록 20건을 조회할 때 게시글마다 투표·작성자·상품을 따로 불러와 쿼리가 수십 번 실행됐습니다.

해결

게시글별 투표 조회를 단일 배치 쿼리로 바꾸고, 투표 목록은 게시글·작성자·상품을 fetch join으로 함께 로딩

문제

단일 GCP VM에서 앱을 교체하면 새 버전이 뜨지 않을 때 서비스가 그대로 중단됩니다.

해결

• 새 JAR를 8081에 먼저 띄워 /health 통과 시에만 Caddy를 전환하고, 8080 교체 후 복귀. 어느 단계에서 실패해도 기존 프로세스가 트래픽을 계속 처리
• 배포 전 prod profile·secret·redirect 설정을 검사해 fail-fast, FCM 자격증명은 systemd drop-in으로 런타임 주입
• 운영 중 API 폭주와 로그인 공격에 대비해 경로별 요청 제한(429)과 차단 지표 추가

1. Build · Test
2. →
3. 8081 후보 기동
4. →
5. /health 통과
6. →
7. Caddy 전환
8. →
9. 8080 교체 · 복귀

문제

같은 사용자·해수욕장·시간의 예약이 동시에 들어오면, 서비스의 사전 조회만으로는 경쟁 조건을 막을 수 없습니다.

해결

DB UNIQUE 제약을 마지막 방어선으로 두고, 충돌을 500이 아닌 409 ProblemDetail(RESERVATION_DUPLICATE)로 변환

검증

10개 스레드 동시 요청을 MockMvc·실제 repository·고정 Clock으로 재현해 HTTP 응답과 최종 저장 상태를 함께 확인. 시간 경계(400), 인증(401), 타인 예약 취소(404), 취소 후 재예약도 검증

해결

• 30분 주기 스케줄러로 해수욕장별 혼잡도·날씨를 수집하고, 시간별 관측 이력(BeachCondition)과 조회용 현재 상태(Beach.status)를 분리
• 응답이 없거나 코드가 누락된 대상만 건너뛰어 한 곳의 실패가 전체 수집을 멈추지 않도록 처리

검증

Clock을 주입해 스케줄러 시각을 고정하고 경계 조건을 재현

해결

• 이미지를 latest와 commit SHA로 태깅해 배포 버전을 추적하고, secret은 이미지 밖 EC2 env 파일로 주입
• 배포 후 Actuator Health를 재시도로 확인하고, 실패하면 컨테이너 상태와 최근 로그를 바로 출력
• Firebase가 비활성화된 환경에서 앱이 부팅에 실패하던 문제를 조건부 빈 등록으로 해결

1. Docker Buildx
2. →
3. GHCR · SHA 태그
4. →
5. EC2 Compose pull/up
6. →
7. Actuator Health

문제

HTTP 요청, 비동기 이메일, 스케줄러가 각각 로그만 남겨 하나의 요청이 어디서 실패했는지 따라가기 어려웠습니다.

해결

• Micrometer Tracing(OpenTelemetry)으로 HTTP·@Async 이메일·SMTP 시도·스케줄러 구간에 span을 만들고 traceId를 로그 MDC와 연결
• 스케줄러는 실행별 root span과 대상별 span으로 나누고, 결과를 success/skipped/error로 제한해 개인정보·고카디널리티 값 수집을 차단
• Alloy → Loki 로그 파이프라인을 구성하고 Grafana에서 로그 ↔ Trace를 오가도록 연결

검증

in-memory exporter 기반 통합 테스트로 span 부모 관계와 예외 전파, MDC 정리 확인