제로베이스 팀프로젝트 진행록4 - 리팩토링 & 멘토 피드백

Transactional 사용에 대한 멘토 피드백과 리팩터링

 

Transaction 사용에 대해서 대용량 환경에서는 deadlock이나 트래픽 수용성이 떨어지기 때문에 최대한 사용을 피하는 것이 좋다고 하셨다. Trasnaction을 사용할때 방지하고자하는 위험한 케이스가 1. 실제로 일어나는 일인가? 2. 막아야하는 일인가? 3. 다른 방법은 없는가 세가지 질문을 먼저 던져보라고 조언해주셨다. 

 

(1) Fail-fast를 통한 rollback 상황 최소화

  실제로 내 코드에서 Trasnaction을 사용했던 케이스들을 보면 Trasnaction 없이 코드의 구조만 조금 변경하면 데이터 무결성을 보장할 수 있는 구조였다.

  기존에는 Entity상태를 변경하고 저장한후에, API 통신이 실패하면 Payment데이터 저장을 rollback하는 구조였다면, 현재는 entity의 상태변경과 save 단계를 분리하고 그 중간에 API통신을 넣어서, API통신이 실패하면 Payment데이터가 저장이 안되는 구조로 변경하였고, 이 경우에 Transaction을 사용하지 않고 Rollback과 동일한 효과를 얻을 수 있었다. 

  Transaction에 대한 비용을 생각해보면 API호출은 꽤 오래걸리는 작업이고 정말 오랜 시간동안 DB에 Lock을 걸고 있는 격이었구나 하는 생각이 들었다.

public void clientSuccessDepositPay(
    String userId, String pgToken) {
    log.info("success customer DepositPay");

    PaymentEntity paymentEntity = paymentService.ChangeStatusToCompleteByUserId(
        userId);

    kakaopayApiService.sendPayConfirmSign(
        paymentEntity.getPaykey(), paymentEntity.getReferentialOrderId(),
        userId, pgToken);

    paymentService.savePayments(paymentEntity);
}

 

 

정책적/프론트 관점으로 문제 해결하기

(1) 데이터의 상태분리를 통한 트랜잭션 사용최소화

최초에는 transactional을 사용해서 결제처리까지 완료가 되면 participation data를 생성하도록 하였는데, transaction으로 인해서 lock이 과도하게 장기간 걸릴 것 같아서 participation ready와 fail이라는 상태를 만들어서 이를 처리함. 

  이를 위해서 기존의 정책을 변경하여 결제처리가 되지 않아도 참여인원으로 보이도록 

 

(2) 데이터의 상태분리를 통한 트랜잭션 사용최소화

유저의 게시글 참여신청 -> 유저의 카카오페이를 통해서 결제진행 -> 카카오페이 서버에서 유저를 게시글로 redirect  -> 유저는 redirect페이지에서 백엔드 서버에 결제완료 전송 -> 백엔드서버 내에서 게시글을 결제완료상태로 변경 

위와 같은 상황이었을때, redirect를 게시글로 하면, 게시글이 아직 결제완료상태로 변경되지 않아서 조회가 되지 않는 에러문제가 발생하였다.

  백엔드의 코드흐름을 변경할 수 없다는 것을 확정하고 프론트에게 결제완료페이지를 만들어서 게시글의 상태가 변화될때까지 포스트로 이동을 재시도 로직을 추천하여 게시글 상태를 바꿀때까지 시간을 벌도록 요청하였다. 문제해결을 위해서 백엔드의 관점에 갖혀있는 것이 아니라 정책적, 프론트적 다양한 선택지를 바라볼 수 있는 개발자가 되겠다. 

 

비동기화 처리

 

 

 

인덱스사용