[ refactor ] 신청 승인 시 생성 트랜잭션 내 외부 HTTP 호출 분리

[dongmin0204]

🛠️ 계획된 리팩토링할 기능

신청 승인 시 인프라 프로비저닝 + DB 업데이트 로직

🛠 사유

현재 approveRequest()는 하나의 @Transactional 안에서 3개의 외부 HTTP API를 순차 호출한다:

@Transactional 시작 → DB 커넥션 획득
  → Ubuntu Account 생성 API (수 초)
  → NFS 내의 PVC 생성 API (수 초)
  → 각 서버에서 Pod 생성 API (수~수십 초)
  → DB 업데이트
@Transactional 종료 → DB 커넥션 반환

이 구조는 다음 운영 장애 가능성 존재함.

1. DB 커넥션 고갈: 외부 API 응답 대기 동안 DB 커넥션 점유. Pod 생성 timeout이 길어지면 HikariCP 풀(DB관리하는 녀석) 고갈 → 전체 서비스 장애
2. 트랜잭션 timeout 미설정: 외부 API 입력에 더 이상 반응하지 않고 정지된 상태 시 트랜잭션 무한 대기 (like Dstate)
3. 보상 트랜잭션 한계: DB 업데이트 실패 시 tryCompensateAll()이 같은 트랜잭션 내에서 @Transactional(MANDATORY) 메서드를 호출 — 롤백 상태에서 보상 실패 가능 (1대1로 삭제하고, 중간에 취소되어도 보장이 안된당)

개선 방향:

• 외부 API 호출을 트랜잭션 밖으로 분리: 인프라 프로비저닝(트랜잭션 없음) → DB 업데이트(@Transactional)
• PodService.deletePod(), UbuntuAccountService.deleteUbuntuAccount()에서 @Transactional(propagation = MANDATORY) 제거
• 보상 트랜잭션을 별도 트랜잭션(REQUIRES_NEW)으로 분리하거나 트랜잭션 밖에서 실행

연관 항목:

• approveModification() VOLUME_SIZE 케이스: PVC API 성공 후 DB 커밋 실패 시 PVC 크기 불일치 — 동일한 패턴의 보상 로직 필요
• UbuntuAccountService:99 사용자 삭제 실패 시 ErrorCode.USER_CREATION_FAILED 사용 중 → ErrorCode.UBUNTU_USER_DELETION_FAILED로 수정

📝 check-lists

• approveRequest() 외부 API 호출을 트랜잭션 밖으로 분리
• PodService에서 @Transactional(propagation = MANDATORY) 제거
• UbuntuAccountService에서 @Transactional(propagation = MANDATORY) 제거
• 보상 트랜잭션 실행 방식 개선 (별도 트랜잭션 또는 트랜잭션 밖)
• approveModification() VOLUME_SIZE 변경 시 PVC resize 보상 로직 추가
• UbuntuAccountService:99 ErrorCode를 UBUNTU_USER_DELETION_FAILED로 수정
• @Transactional(timeout = ...) 설정 검토
• 테스트 코드 작성