feat/117 :: Release 릴리즈 서비스 구현

[lian2945]

📌 관련 이슈

• close #117

---

📝 변경 사항 요약

작업 유형

• ✨ feat: 새로운 기능 추가 (기능 단위 완료 후 PR)
• 🐛 fix: 버그 수정 (버그 1개 = PR 1개)
• ♻️ refactor: 코드 리팩토링 (작업 단위 완료 후 PR)
• ✅ test: 테스트 코드 추가/수정 (작업 단위 완료 후 PR)

변경 내용

• 도메인: Release Aggregate (ReleaseStatus, ReleaseLevel, 판매 시작/종료, 판매 수량 관리), VO 3종, 예외 3종
• 애플리케이션: UseCase 8종 (등록/조회/판매시작·종료/자동판매/수량증가), Port, Service, DTO
• 어댑터: REST Controller (Command/Query/Admin), gRPC 서버 (릴리즈 정보 제공), gRPC 클라이언트 (creator → creatorId 조회), JPA Persistence, Security, 스케줄러 (10분 단위 자동 판매 시작), 커스텀 Validation (@ScheduledAtMultipleOfTenMinutes)
• 설정: application-local/dev.yml, build.gradle, Dockerfile, proto (creator/release)

변경 이유

• 마술 작품 발매(릴리즈) 등록, 판매 상태 관리, gRPC 서버 제공이 필요하며 order/waiting/creator 서비스에서 릴리즈 정보를 조회하는 핵심 서비스

---

✅ 테스트 체크리스트

• 단위 테스트 작성 및 통과
• 통합 테스트 통과
• 기존 기능 정상 동작 확인 (Regression)
• API 응답값 확인
• 예외 케이스 처리 확인
• 로컬 환경에서 직접 테스트 완료

---

📸 스크린샷 / 로그

펼쳐보기

curl-test.sh 기반 릴리즈 API 테스트 완료

---

🔄 동작 플로우 (Mermaid)

flowchart TD
    A[릴리즈 등록 요청] --> B[ReleaseCommandController]
    B --> C[RegisterReleaseService]
    C --> D[gRPC → creator 서비스 creatorId 조회]
    D -->|NOT_FOUND| E[CreatorNotFoundException 404]
    D -->|성공| F[Release Aggregate 생성 저장]
    F --> G[판매 시작 시간 도래]
    G --> H[StartSaleScheduler 10분 주기]
    H --> I[ReleaseStatus → ON_SALE]
    I --> J[판매 종료 요청]
    J --> K[ReleaseStatus → SALE_ENDED]

Loading

💬 리뷰어에게

• gRPC 서버(ReleaseGrpcService)가 order, waiting, creator 서비스에 릴리즈 정보를 제공합니다. proto 정의와 응답 매핑을 검토해주세요.
• @ScheduledAtMultipleOfTenMinutes 커스텀 Validation이 10분 단위 판매 시작 시간을 강제합니다.
• Resilience4j CircuitBreaker 설정(creator gRPC 클라이언트)을 확인해주세요.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[f-lab-ted]

Release Aggregate(상태 SCHEDULED → ON_SALE → SOLD_OUT/ENDED, 한정 수량/판매 수량/판매 예정 시각 관리)와 헥사고널 구성(REST/gRPC/Kafka/JPA/Scheduler), creator 서비스로의 gRPC 호출 + Resilience4j CircuitBreaker, 10분 단위 판매 시작 시각 강제 Validation, 자동 판매 시작 스케줄러, release-sold-quantity-increase Kafka Inbox 처리를 함께 검토했습니다. 또한 다른 서비스(auth/creator)의 Inbox DEAD_LETTERED 만료 처리/@RetryableTopic 전환, URL prefix /api/creator → /creator//admin/creator 변경 영향도 함께 살펴봤습니다.

잘한 점

DDD/헥사고널 경계가 명확하게 분리되어 있고(core ↔ port ↔ adapter), Release Aggregate에 상태 전이 규칙과 검증을 집중시킨 점, gRPC ↔ Resilience4j ↔ deadline 조합으로 외부 호출 안정성을 챙긴 점은 좋습니다.

보완할 점 (Critical/Major 위주)

1. Critical ReleaseGrpcService.toProtoRelease 가 proto의 created_at 필드에 scheduledAt 값을 매핑하고 있어, 호출 측(creator 등)에서 의미가 달라진 데이터를 받게 됩니다. proto 정의를 scheduled_at/status/limited_quantity/sold_quantity까지 포함하도록 보강하고 매핑을 일치시켜야 합니다.
2. Critical StartSaleScheduler가 분산 락 없이 1분 주기로 돌고 있어 다중 인스턴스 환경에서 같은 SCHEDULED 릴리즈를 동시에 잡아 OptimisticLockingFailureException 또는 중복 startSale 시도가 발생합니다. 최근 order 서비스의 AutoConfirm 스케줄러에 적용된 분산 락 + 청크 처리 패턴을 동일하게 적용해 주세요. 또한 PR 설명의 "10분 주기"와 코드의 fixedDelay = 60000(1분) 불일치도 정정 필요합니다.
3. Major IncreaseSoldQuantityUseCase 가 gRPC(ReleaseGrpcService#increaseSoldQuantity)와 Kafka(OrderEventKafkaListener) 두 경로 모두에서 호출됩니다. 동일 주문에 대해 양쪽이 모두 발화하면 이중 차감/oversell 위험이 있고, 책임 분리가 모호합니다. 비동기(Outbox→Inbox) 단일 경로로 통일하거나 gRPC 경로를 제거하는 것이 안전합니다.
4. Major /admin/release/* 가 SecurityConfiguration의 anyRequest().permitAll() 정책 하에 인증/관리자 권한 검사 없이 노출됩니다. 게이트웨이에서 prefix-기반 보호가 있더라도 서비스 자체에 방어선이 필요합니다.
5. Major RegisterReleaseService#registerRelease 내부에서 creator gRPC 호출이 @Transactional 안에 포함되어 있어, 외부 호출(최대 2초 + 서킷브레이커 전환) 동안 DB 트랜잭션이 유지됩니다. gRPC 호출은 트랜잭션 밖에서 수행한 뒤 결과만 들고 트랜잭션을 시작하도록 분리해 주세요.

그 외 가이드에서 지적된 IdempotentAspect.isTooOld 중복 저장 위험, @DltHandler ↔ retry topic 이름 불일치, auth/creator 간 @RetryableTopic 비대칭, FRONTEND_URI→URL 환경변수 변경, creator gRPC 채널 일관성도 같은 맥락의 보완 대상입니다.

결론

Request Changes — 1번 proto 매핑(데이터 정합성), 2번 스케줄러 분산 락(다중 인스턴스 안전성), 3번 increaseSoldQuantity 이중 경로(이중 차감), 4번 admin 보호 부재 점에 대해서는 반드시 수정 바랍니다.

[f-lab-ted]

[Critical] proto created_at 필드에 scheduledAt 값을 매핑하고 있습니다.

.setCreatedAt(Timestamp.newBuilder()
        .setSeconds(scheduledAt.getEpochSecond())
        .setNanos(scheduledAt.getNano())
        .build())

• 호출 측(creator 서비스의 ReleaseQueryGrpcAdapter 등)은 응답의 created_at을 실제 생성 시각으로 신뢰합니다. 여기에 판매 예정 시각이 들어가면 정렬/노출 로직이 모두 어긋납니다.
• 그리고 getReleasesByCreatorId 응답에는 status, scheduled_at, limited_quantity, sold_quantity 같은 release 의 핵심 속성이 누락되어 있어 order/waiting 같은 호출 측에서 다시 확인 호출이 필요해질 가능성이 큽니다.

제안: proto 정의에 created_at/scheduled_at/status/limited_quantity/sold_quantity 를 추가하고, 매핑을 의미에 맞게 분리해 주세요. (특히 created_at은 result.createdAt()을 써야 합니다.)

[f-lab-ted]

[Critical] 분산 락 없이 1분 주기로 동작하여 다중 인스턴스에서 충돌 위험이 큽니다.

• AutoStartSaleService#autoStartScheduledReleases는 findScheduledBefore(now) 로 모든 대상 릴리즈를 한 트랜잭션에서 가져와 release.startSale() + update()를 반복 호출합니다. 여러 pod 가 같은 SCHEDULED 행에 대해 동시에 진입하면 @Version 기반 낙관락 충돌로 일부 instance 가 예외와 함께 종료되고, 다음 주기까지 시작이 지연됩니다.
• 최근 order 서비스의 AutoConfirm 스케줄러에 적용한 "분산 락 + 청크 처리" 패턴을 동일하게 도입하는 것이 자연스럽습니다 (ShedLock / Redisson 등).
• PR 설명에는 "10분 단위 자동 판매 시작"이라고 적혀있지만 fixedDelay = 60000(1분)으로 설정되어 있어 설명과 코드가 불일치합니다. 의도가 1분이라면 PR 문서를 수정하고, 10분이 의도라면 fixedDelayString = "PT10M" 또는 cron 으로 명시해 주세요.

@Scheduled(fixedDelay = 60000) // 1분
public void autoStartScheduledReleases() { ... }

부가적으로, @ScheduledAtMultipleOfTenMinutes 로 등록 시각을 10분 단위로 강제했다면 스케줄러도 10분 주기(또는 cron 0 */10 * * * *)로 정렬하는 것이 의미 충돌이 적습니다.

[f-lab-ted]

[Major] increaseSoldQuantity 동기 gRPC 경로 / Kafka Inbox 경로가 중복됩니다.

같은 도메인 행위(Release#increaseSoldQuantity)가 두 진입점에서 호출됩니다.

• 동기: ReleaseGrpcService#increaseSoldQuantity (RPC)
• 비동기: OrderEventKafkaListener#handleReleaseSoldQuantityIncrease (Kafka Inbox)

위험 요소:

1. 주문 서비스가 두 경로를 모두 사용하면 동일 주문에 대해 sold_quantity 가 2회 증가하여 oversell 됩니다.
2. gRPC 경로에는 멱등성 보호(Inbox/eventId 검증)가 없어, 클라이언트가 재시도하면 그대로 또 증가합니다.
3. 두 경로 모두 @Version 낙관락에 의존하기 때문에 단순 충돌 시 예외만 던지고 재시도 정책이 없습니다.

제안: 주문→릴리즈 sold quantity 증가는 Outbox→Inbox(Kafka) 단일 경로로 통일하고 gRPC increaseSoldQuantity 엔드포인트는 제거하거나, 반대로 동기 차감을 유지하려면 Inbox 리스너를 제거하고 멱등키(eventId)에 대한 명시적 중복 방지를 gRPC에 도입해 주세요.

[f-lab-ted]

[Major] /admin/release/* 가 인증/권한 없이 노출되어 있습니다.

.authorizeHttpRequests(auth -> auth.anyRequest().permitAll())

AdminReleaseCommandController(start-sale / end-sale)는 운영자만 호출해야 하는데, 현재 설정에선 외부에서 누구나 호출 가능합니다. 게이트웨이가 보호한다 하더라도 서비스 자체적으로:

• /admin/** 경로는 UserInfoExtractFilter 가 주입한 ROLE_ADMIN 권한 보유자만 통과하도록 requestMatchers("/admin/**").hasRole("ADMIN") 추가
• 또는 컨트롤러 메서드에 @PreAuthorize("hasRole('ADMIN')") 적용

이 필요합니다. 외부 노출 위험이 큰 상태 전이(판매 시작/종료) 엔드포인트라 우선순위를 높여 봐주세요.

[lian2945]

이것은 AuthorizationPolicy를 통해 해결할 예정입니다

[f-lab-ted]

[Major] gRPC 외부 호출이 @Transactional 경계 안에 포함되어 있습니다.

@Transactional
public Long registerRelease(RegisterReleaseCommand command) {
    CreatorId creatorId = creatorIdQueryPort.getCreatorId(command.userId()); // gRPC + CircuitBreaker
    Release release = Release.createBuilder()....build();
    return releaseRepositoryPort.save(release);
}

• getCreatorId 는 최대 2초 deadline + Circuit half-open 상황까지 고려하면 응답이 늦어질 수 있는데, 그 동안 DB 커넥션이 점유됩니다.
• creator 서비스가 NOT_FOUND 가 아닌 다른 원인으로 실패하면 CreatorServiceUnavailableException 까지 트랜잭션 안에서 처리됩니다(불필요한 트랜잭션 rollback 비용).

제안: creator 조회는 트랜잭션 밖에서 수행 후, 검증된 creatorId 만 들고 짧은 트랜잭션 안에서 저장하도록 분리하는 것을 권장합니다.

public Long registerRelease(RegisterReleaseCommand command) {
    CreatorId creatorId = creatorIdQueryPort.getCreatorId(command.userId());
    return saveNewRelease(creatorId, command); // 이 안에 @Transactional
}

[f-lab-ted]

[Major] 대상 릴리즈 전체를 한 트랜잭션에서 순차 처리합니다.

List<Release> releases = releaseRepositoryPort.findScheduledBefore(Instant.now());
releases.forEach(release -> {
    release.startSale();
    releaseRepositoryPort.update(release);
});

• 누락된 시작 예정 건이 수십~수백 건 쌓이면 단일 트랜잭션이 길어지고 한 건 실패 시 모두 롤백됩니다.
• release.startSale() 은 SCHEDULED 가 아닐 때 ReleaseStatusConflictException 을 던지는데, 그 사이 다른 인스턴스/이벤트가 상태를 바꿔놓았다면 전체 작업이 무산됩니다.

제안: order 서비스의 AutoConfirm 청크 처리 패턴(분산 락 + 페이지 단위 + 개별 트랜잭션)을 적용해 부분 실패 격리를 확보해 주세요. 최소한 release.startSale() 을 try/catch 로 감싸 한 건 실패가 다른 건을 막지 않도록 해야 합니다.

[f-lab-ted]

[Major] 만료 메시지 DEAD_LETTERED 저장 시 existsByEventId 중복 체크가 누락되어 있습니다.

if (isTooOld(occurredAt)) {
    transactionTemplate.executeWithoutResult(status ->
        authInboxRepository.save(AuthInboxEntity.builder()
                .eventId(eventId)
                ...
                .status(AuthInboxStatus.DEAD_LETTERED)
                .build())
    );
    return null;
}

동일 eventId 가 (정상 처리된 후) 재전달되어 만료 판정을 받게 되면, 위 분기는 정상 처리 분기와 달리 중복 체크 없이 곧바로 save 를 호출하므로 event_id UNIQUE 제약 위반이 발생합니다. 또한 같은 메시지가 retry로 여러 번 들어와 모두 만료 처리되면 동일하게 위반됩니다.

제안:

if (isTooOld(occurredAt)) {
    if (authInboxRepository.existsByEventId(eventId)) {
        log.info("[Inbox] 이미 기록된 만료 이벤트. eventId={}", eventId);
        return null;
    }
    // save DEAD_LETTERED ...
}

creator 측 IdempotentAspect 도 동일 구조이므로 같이 보완해 주세요.

[f-lab-ted]

[Major] @DltHandler 안에서 consumerRecord.topic() 으로 Inbox 를 조회하면 원본 토픽이 아니라 retry 토픽을 받게 됩니다.

@RetryableTopic 사용 시 메시지는 outbox.event.user-withdrawn → outbox.event.user-withdrawn-retry-0 → ...-retry-1 ... 식으로 토픽이 바뀌며 흐릅니다. 결국 DLT 핸들러에서는 retry 토픽의 이름이 들어오는데, IdempotentAspect 가 Inbox 에 저장할 때는 원본 토픽 이름으로 저장합니다. 따라서:

creatorInboxRepository.findByTopicAndPartitionAndOffset(consumerRecord.topic(), ...)

는 매칭되지 않아 markDeadLettered() 가 실행되지 않습니다.

제안: Inbox 저장 시 KafkaHeaders.ORIGINAL_TOPIC/ORIGINAL_PARTITION/ORIGINAL_OFFSET 헤더를 우선 사용하거나, eventId 기준으로 조회/마킹하도록 변경해 주세요. auth 서비스의 DLT 핸들러는 @RetryableTopic 없이 동작하므로 같은 이슈는 아니지만, 두 서비스의 정책(@EnableKafkaRetryTopic 적용 여부)이 비대칭이라 일관성 확인이 필요합니다.

[f-lab-ted]

[Minor] 같은 PR에 GrpcConfiguration 으로 releaseManagedChannel Bean 을 등록해두고도, 본 어댑터에서는 매 호출마다 grpcChannelFactory.createChannel(...) 로 새 채널을 만들고 있어 일관성이 깨졌습니다.

채널 생성은 비용이 큰 작업이고 keep-alive 등의 설정도 채널 단위로 관리되므로, 새로 추가된 releaseManagedChannel Bean 을 주입받아 재사용하도록 통일해 주세요. subscribeManagedChannel, reviewManagedChannel, userManagedChannel, shortformManagedChannel 사용처도 모두 동일 문제를 가집니다.

release 서비스의 CreatorGrpcAdapter 는 이미 creatorManagedChannel 을 주입받아 재사용하고 있어 좋은 레퍼런스가 됩니다.

[f-lab-ted]

[Minor] URL prefix 일괄 변경(/api/creator/* → /creator/*, /admin/creator/*)은 Breaking Change 입니다.

다음 영역을 PR 머지 전에 반드시 동기화 확인해 주세요.

• API Gateway 라우팅 규칙
• 타 마이크로서비스의 REST 호출 위치(있다면)
• tools/curl-test.sh 류 운영 스크립트
• 프론트엔드 API base path
• e2e/통합 테스트 픽스처

특히 /admin/creator/* 는 새 prefix 이므로 게이트웨이에서 일반 사용자 토큰으로 접근하지 못하도록 별도 라우트/필터를 두는 것이 안전합니다.

[sonarqubecloud]

Quality Gate failed

Failed conditions
9 Security Hotspots

See analysis details on SonarQube Cloud