🎇 트러블 슈팅

1️⃣ RDB & MongoDB 트랜잭션 분리

문제 상황

문서를 삭제할 때, RDB(MySQL)과 MongoDB에 분산된 데이터가 함께 삭제되어야 한다. 하지만 두 데이터베이스 간에 단일 트랜잭션을 묶는 것은 불가능하며(하나의 @Transactional로 처리 X), 처리 순서나 실패 복구를 잘 설계하지 않으면 두 데이터베이스간 불일치가 발생할 수 있다.

현재 구조:

db	저장 내용
RDB(JPA 기반)	Doc, Branch, Edge와 Save, Commit의 메타데이터 (제목, 설명, 생성/수정 일자 etc)
MongoDB	SaveContent, Block, CommitsBlockSequence (Save와 Commit의 본문, Commit의 블록 리스트)

저장 트랜잭션 설계

저장의 경우 다음과 같은 위험이 발생할 수 있다:

• Mongo 먼저 저장 → 이후 RDB 실패: Mongo에 쓰레기 데이터 남음
• RDB 먼저 저장 → 이후 Mongo 실패: RDB에 내용이 없는 저장이 생김

이를 해결하기 위해 다음과 같은 저장 로직을 고안하였다:

✔ MongoDB 저장 후 → 성공 시 ID를 받아 → RDB에 저장

예시 프로세스: RDB의 @Transactional 안에서 다음 처리 실행

try {
    1. [RDB] MongoID를 제외한 Save 메타데이터를 우선 RDB에 저장

    2. [MongoDB] SaveContent를 MongoDB에 저장 → saveContentId 반환

    3. [RDB] 반환받은 saveContentId를 기존 Save(RDB)에 업데이트

    4. 최종적으로 모든 저장 성공 → 트랜잭션 커밋

} catch (예외 발생 시) {
    - [MongoDB 수동 롤백] 실패한 Mongo 저장 내용 직접 삭제 (saveContentId 등)
    - 예외 종류에 따라 적절한 CustomException 발생 후 
    - 전체 트랜잭션 롤백
}

삭제 트랜잭션 설계

삭제의 경우 다음과 같은 위험이 발생할 수 있다:

• Mongo 삭제 중 예외 → RDB는 이미 삭제 완료 상태 → 롤백 불가로 데이터 정합성 깨짐

• 반대로 Mongo는 삭제됐는데 RDB 트랜잭션이 롤백된다면 → MongoDB에 고아 데이터 발생

삭제는 저장과 달리 RDB만 먼저 삭제되고 MongoDB에 고아 데이터가 남더라도 UX 관점에서 문제가 없으므로, Mongo 삭제를 RDB 트랜잭션 이후로 분리한다.

이를 해결하기 위해 다음과 같은 삭제 로직을 고안하였다:

✔ 이벤트 기반 처리 + 트랜잭션 분리 + 재시도 + 비동기

1. RDB 삭제

• Doc, Branch, Commit, Save 등(RDB)은 하나의 @Transactional 내에서 삭제
• 동시에 삭제해야할 Mongo 관련 ID를 수집하여 DocDeleteMongoIdsDto에 담고
• eventPublisher.publishEvent()로 삭제 이벤트 발행

2. MongoDB 삭제

• @TransactionalEventListener(phase = AFTER_COMMIT)를 통해 RDB 트랜잭션이 성공적으로 커밋된 후에만 Mongo 삭제를 시도
• @Retryable은 AOP 기반으로 프록시를 통해 호출돼야 작동하기 때문에 이벤트리스너에서 직접 삭제하지 않음 (리스너에서 직접 호출 시 동작 안 함)

3. Mongo 삭제: 재시도

• MongoDB는 Atlas 기준 기본적으로 Replica Set을 지원하므로, 트랜잭션 사용이 가능함
• MongoTransactionManager를 @Bean으로 등록해 트랜잭션 분리

4. 삭제 실패 → @Recover 진입

• 삭제가 3회 모두 실패하면 @Recover 메서드로 이동
• 이 시점에는 트랜잭션 컨텍스트가 종료되어 있으므로, 직접 RDB 저장 시도 시 예외 발생 (no transaction is in progress)
• @Async 로 위임하여 트랜잭션을 새로 생성하고 Mongo 삭제 실패 내역(MongoDeleteFailure)을 저장

5. Mongo 삭제 실패 기록 저장

• @Async + @Transactional 조합으로 새 트랜잭션 컨텍스트를 생성하여 RDB에 Mongo 삭제 실패 내역 저장

6. 실패 내역 재시도: 스케줄러 기반

• 일정 주기(1시간?)로 MongoDeleteFailure 내역 조회
• 삭제 성공 시 resolved = true로 soft delete 처리

2️⃣ 연관관계 CASCADE 오류 및 해결

문제 상황

• 문서(Doc) 삭제 시 하위 Branch, Commit, Edge를 cascade = CascadeType.ALL로 제거하도록 구성되어 있었음
• 그러나 Doc 삭제 시 Edge에서 SQL Error: 1048 발생함

Column 'next_commit_id' cannot be null

다음은 기존의 관련 코드와 ERD이다.

• Doc 삭제 메서드 (기존)

    public void delete(Long docId, Long userId) {
        User user = getUserOrThrow(userId);
        Doc doc = getDocByIdAndUserId(docId, userId);

        List<Branch> branches = doc.getBranches();
        MongoIdsDto docDeleteMongoIds = mongoIdsCollector.collectFrom(branches);

        user.removeDocument(doc);
        eventPublisher.publishEvent(docDeleteMongoIds);

• Edge 엔티티

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "document_id", nullable = false)
    private Doc doc;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "prev_commit_id", nullable = false)
    private Commit prevCommit;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "next_commit_id", nullable = false)
    private Commit nextCommit;

• Doc 엔티티

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "user_id", nullable = false)
    private User user;

    @OneToMany(mappedBy = "doc", cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.LAZY)
    private List<Branch> branches;

    @OneToMany(mappedBy = "doc", cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.LAZY)
    private List<Edge> edges;

• ERD

해결

• 서비스 레이어에서 Doc 삭제 전 Edge를 명시적으로 삭제하도록 수정:

    public void delete(Long docId, Long userId) {
        User user = getUserOrThrow(userId);
        Doc doc = getDocByIdAndUserId(docId, userId);

        List<Edge> edges = doc.getEdges(); // 간선 수집
        List<Branch> branches = doc.getBranches();

        MongoIdsDto docDeleteMongoIds = mongoIdsCollector.collectFrom(branches);
        edgeRepository.deleteAll(edges); //간선 삭제

        user.removeDocument(doc);
        eventPublisher.publishEvent(docDeleteMongoIds);

원인 분석

테스트

기존 doc 삭제 테스트코드에서는 given에 주어진 doc에 edge 자체가 세팅되지 않아 이 오류를 발견하지 못했던 것으로 보인다.
해당 오류는 배포 후 api 테스트에서 발견하고 위와 같이 바로 수정해 다시 배포하였지만, 보다 정확한 원인 파악을 위해 오류를 재현해보고자 한다.

다음과 같은 간단한 테스트코드로 쿼리를 확인하였다.

• H2->MySQL 테스트용 테이블을 만든 후 기존의 delete() 서비스 메서드를 그대로 호출
• edges에 cascade = CascadeType.ALL (혹은 REMOVE)가 걸려있으면 항상 다음 테스트 통과함 (orphanRemoval = true 존재와 무관)

    @Test
    void 문서_삭제시_엣지_삭제순서로_FK제약조건_예외발생() throws JsonProcessingException {
        // given
        User user = userRepository.saveAndFlush(DocTestUtils.createUser());

        Doc doc = DocTestUtils.createDocWithEdgesForDeleteTest(user, saveContentRepository,
                commitBlockSequenceRepository, blockRepository);

        docRepository.saveAndFlush(doc);
        assertThrows(DataIntegrityViolationException.class, () -> {
            docService.delete(doc.getId(), user.getId());
            docRepository.flush(); // 여기서 MySQL이 FK 위반 예외 던짐
        });
    }
}

// 이전 로그 생략

Hibernate: 
    /* update
        for io.ejangs.docsa.domain.branch.entity.Branch */update branches 
    set
        document_id=?,
        from_commit_id=?,
        leaf_commit_id=?,
        name=?,
        root_commit_id=?,
        updated_at=? 
    where
        id=?
Hibernate: 
    /* update
        for io.ejangs.docsa.domain.doc.entity.Edge */update edges 
    set
        document_id=?,
        next_commit_id=?,
        prev_commit_id=? 
    where
        id=?
2025-08-16T18:25:11.482+09:00  WARN 7556 --- [    Test worker] o.h.engine.jdbc.spi.SqlExceptionHelper   : SQL Error: 1048, SQLState: 23000
2025-08-16T18:25:11.482+09:00 ERROR 7556 --- [    Test worker] o.h.engine.jdbc.spi.SqlExceptionHelper   : Column 'next_commit_id' cannot be null

로그를 보면, doc 삭제 전 두 번의 UPDATE 쿼리가 나가는 것을 확인할 수 있다.

Hibernate 동작 방식

• Hibernate는 FK 무결성을 지키기 위해 DELETE 이전에 UPDATE를 날림
  • doc 삭제 전 commit을 삭제하기 위해 먼저 이 commit을 참조하는 edge의 FK를 끊음
  • edge의 next_commit_id를 null로 UPDATE하는 과정에서 NOT NULL이 걸려있기에 MySQL:1048 예외 발생

결론

복잡한 연관관계에서는 CASCADE 에 전적으로 의존하기보다, Hibernate의 예상치 못한 내부 동작 가능성을 고려하여 일정 수준의 명시적 처리를 병행하는 것이 시스템의 안정성 확보에 더 바람직할 것으로 생각된다.

3️⃣ MultipleBagException

문제 상황

그래프 조회 API는 UI 좌측 사이드바에 커밋 히스토리를 표시하기 위해 문서 조회 시마다 실행된다. 이 과정에서 문서의 브랜치, 커밋, 저장 정보를 불러오는 중 다음과 같은 에러가 발생하였다.

org.hibernate.loader.MultipleBagFetchException: cannot simultaneously fetch multiple bags: [io.ejangs.docsa.domain.branch.entity.Branch.commits, io.ejangs.docsa.domain.doc.entity.Doc.branches]

• 그래프 조회 방식 (기존)
  • Hibermate는 성능 저하 방지를 위해 동시에 2개 이상의 bag(링크)를 FETCH JOIN 하지 못하도록 MultipleBagFetchException(링크) 발생시킴
  • branches와 edges 두 개의 List 컬렉션을 FETCH JOIN
  • branches 내부에서 commits라는 또 다른 List 컬렉션까지 FETCH JOIN을 시도하며 해당 에러 발생

public interface DocRepository extends JpaRepository<Doc, Long> {

    @Query("""
        SELECT DISTINCT d
        FROM Doc d
        LEFT JOIN FETCH d.branches b
        LEFT JOIN FETCH b.commits
        LEFT JOIN FETCH d.edges
        WHERE d.id = :id
    """)
    Optional<Doc> findByIdWithBranchesAndEdges(@Param("id") Long id); 

해결과 성능비교

테스트

• 테스트 방법
  • 쿼리 개수, 실행 시간(ms), 메모리 사용량(MB) 기록
  • 하나의 문서(doc)에 대해 데이터 크기별 조회 성능 측정
    • case 1) branches=2, commits=40, edges=40
    • case 2) branches=2, commits=100, edges=100
    • case 3) branches=2, commits=200, edges=200
    • case 4) branches=3, commits=1500, edges=1501
• 환경
  • MySQL 테스트용 DB
  • Hibernate SQL 로그 및 EXPLAIN을 활용해 쿼리 수와 실행 계획 확인

a. DTO Projection

b. @BatchSize

결과

결론