[Spring] 동시성 문제를 더 구체적으로 해결해보자!_ 리팩토링

 

 

만들었던 코드를 다시 살펴보니
동시성 문제를 애매하게 해결하고 있었다.
좀 더 확실하게 동시성 문제를 해결해 보자.

 

 

 

1. 원인

• 초반 로직

if (customerRepository.existsByCode(code)) {
    throw new DuplicateCodeException("초대코드가 중복되었습니다.");
}

customerRepository.save(customer);
customerSearchRepository.save(toSearchEntity(customer));

CustomerService 중 save 메서드의 일부분이다. 처음 고객 등록 로직은 이런 흐름이었다. code가 들어오면 existsByCode로 code가 존재하는지 보고, 존재하면 DuplicateCodeException을 던졌다.

두 관리자가 거의 동시에 같은 초대코드를 들고 요청이 들어왔다고 가정해 보자. 이런 경우 문제가 발생할 수 있다. 

A: existsByCode("1234") → false
B: existsByCode("1234") → false​

existsByCode 단계에서 아직 중복이 없다고 판단(false)하여 A, B 둘 다 통과할 수 있는 것이다. 

 

@Table(
    name = "customer",
    uniqueConstraints = @UniqueConstraint(
        name = "uk_customer_code",
        columnNames = "code"
    )
)

그러나 실제로 둘 다 통과되진 않고 저장단계에서 갈릴 것이다.

A: save("1234") 시도 → 성공
B: save("1234") 시도 → 실패

OR

B: save("1234") 시도 → 성공
A: save("1234") 시도 → 실패

왜냐면 Customer 엔티티에 위의 코드처럼 유니크 제약을 걸어뒀기 때문이다. 그래서 최종적으로 먼저 DB에 반영된 요청은 성공하고 나중에 같은 값을 넣으려는 요청은 유니크 제약 위반으로 실패하면서 중복 저장은 안 된다.

 

• 결론
  - 애플리케이션 레벨의 사전 검사(existByCode)는 동시성 상황에서 완전한 보장이 아니다.
  - 다행히 Customer.cdoe 칼럼에서 unique 제약이 걸려 있어서 실제 DB에는 같은 초대코드가 둘 다 저장되지는 않는다. 
  - 즉, 최종 정합성은 DB unique constraint가 보장한다.
  
  
• 문제점
  - unique 제약 위반이 발생했을 때 사용자에게 명확한 응답을 내려주지 못했다.
  

@RestController
public class ApiExceptionHandler {

    @ExceptionHandler(DuplicateCodeException.class)
    public ResponseEntity<String> handleDup(DuplicateCodeException e) {
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(e.getMessage());
    }
}

이 클래스가 에러를 처리하는 클래스인데, 보면 BAD_REQUEST로 상태코드를 설정했다. 이건 400 BadRequest이다. 400 BadRequest는 보통 요청이 잘못 왔을 때 사용한다. 예를 들어서 초대 코드가 4자리인데, 3자리가 오는 경우 내리는 응답이라고 볼 수 있다.

중복 오류는 보통 409 Conflict를 사용한다. 그래서 이 상태와 맞게 코드를 수정해야 한다. 첫 번째로 적용 범위를 넓힐 것이다. @RestController는 해당 컨트롤러 내부에서 발생하는 예외만 잡는데, 이걸 전역적으로 감지해서 처리하도록 할 것이다. 두 번째는 DB 레벨에서 발생하는 데이터 무결성 제약 조건 위반(DataIntegrityViolationException)까지 함께 처리할 거다. 에러 메시지를 파싱 해서 어떤 unique 제약 조건을 위반했는지 구체적으로 판단하는 로직으로 수정할 것이다. 마지막으로 400 BadRequset를 409 Conflict로 바꿀 것이다. 

    - 초대 코드 검증은 프런트엔드에서만 하고 있어서 백엔드 검증 로직도 작성해야 한다.

        String code = customer.getCode();

        if (code != null && customerRepository.existsByCode(code)) {
            throw new DuplicateCodeException("초대코드가 중복되었습니다.");
        }

나도 몰랐다. 프론트엔드에서 4자리를 막아두고 백엔드에는 작성하지 않았다. 프론트엔드에서 막았으면 되는 거 아니냐고 생각할 수 있다. 그런데 이렇게 작성하면 안 된다. 애초에 프런트엔드는 검증을 쉽게 우회할 수 있는 구조이다. 그렇기에 백엔드는 방어적 설계를 해야 한다. 백엔드는 스스로 자신의 데이터 무결성을 지킬 수 있어야 한다.

프런트엔드 검증 로직은 UX 목적이다. 사용자가 실수로 초대 코드 4자리 중 3자리만 입력했을 때, 서버까지 갔다 오는 시간을 낭비하지 않고 바로 4자리를 입력하라고 알려주어 빠른 사용자 경험을 제공한다. 백엔드 검증은 우회된 공격이나 잘못된 데이터가 DB 시스템을 망가뜨리지 않도록 최종적으로 방어하는 목적으로 사용한다.

이 코드를 보면 custoemr 엔티티에서 code를 직접 뽑아 들고 와서 확인하고 있다. 이렇게 검증이 필요한 칼럼의 경우 임베디드 타입으로 따로 빼서 검증 로직을 짜면 된다.

 

 

 

- 초대코드 동작

[Spring, React] 코드를 입력하면 고객 등급에 맞는 페이지를 결과로 보내기

 

 

 

 

---

 

 

 

 

 

 2. 리팩토링

• InviteCode 클래스

// JPA에게 이 클래스는 다른 엔티티의 일부로 포함될 수 있는 값 객체임을 알린다.
@Embeddable
// Lombok을 통해 필드(value)의 Getter 메서드를 자동으로 생성한다.
@Getter
// JPA가 내부적으로 객체를 생성할 때 필요한 기본 생성자를 만든다.
// 다만 무분멸한 외부 생성을 막기 위해 PROTECTED로 레벨을 설정해서 접근을 제어한다.
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class InviteCode {

    // 코드 패턴은 숫자로 이뤄진 4자리이다.
    private static final String CODE_PATTERN = "\\d{4}";

    // 초대코드 문자열 값이 저장되는 캡슐화된(private) 필드이다.
    private String value;

    private InviteCode(String value) {
    
        // 생성 시점에 입력값이 유효한지 검증한다. 
        if (!isValid(value)) {
            // 잘못되었으면 표준 예외를 던지다.
            throw new IllegalArgumentException("초대코드는 숫자 4자리로 입력해야 합니다.");
        }

        // 검증이 통과되면 trim으로 공백을 제거한 뒤 필드에 안전하게 저장한다.
        this.value = value.trim();
    }

    // 들어온 초대코드를 객체로 만드는 정적 팩토리 메서드이다.(of 메서드)
    // 전에는 초대코드를 단순히 String으로 다뤘으면 이젠 초대코드를 값 객체로 감싼다.
    public static InviteCode of(String value) {
        // "1234" 문자열은 -> InviteCode.of("1234")가 되면서 객체 생성된다.
        // 그리고나서 위에 있는 InviteCode 생성자 안으로 들어가서 검사한다.
        return new InviteCode(value);
    }

    // 초대코드의 유효성을 검증하는 도메인 로직이다.
    public static boolean isValid(String value) {
        // null도 아니고, 공백도 아니고, 공백 제거 후 4자리 숫자여야한다.
        return value != null && !value.isBlank() && value.trim().matches(CODE_PATTERN);
    }

    // 메모리 주소가 달라도 안의 데이터가 같으면 같은 객체로 취급하기 위한
    // 동등성 비교를 정의하는 메서드이다.
    @Override
    public boolean equals(Object o) {
        
        // 비교 대상과 나의 메모리 주소가 완벽히 같다면 참을 반환한다.
        if (this == o)
            return true;
        
        // 비교 대상이 null이거나 InviteCode 타입이 아니라면 거짓을 반환한다.
        if (!(o instanceof InviteCode that))
            return false;
        
        // 최종적으로 내부의 value가 서로 일치하는지 비교한 결과를 반환한다.
        return Objects.equals(value, that.value);
    }

    // 객체를 식별할 수 있는 해시코드를 반환하는 메서드이다.
    @Override
    public int hashCode() {
        
        // 내부 value 값을 기반으로 해시코드 생성한다.
        // 해시 기반 컬렉션에서 중복 체크가 정확히 작동한다.
        return Objects.hash(value);
    }
}

캡슐화의 핵심은 외부에서 객체의 내부 데이터를 마음대로 접근하거나 수정하지 못하도록 숨기고 객체가 제공하는 안전한 통로를 통해서만 소통하는 것이다. 사실 캡슐화를 하려고 한 건 아니었는데, 하고 보니 캡슐화가 되었다(?)

private String value;​

private로  접근하지 못하도록 막았고, of( ) 메서드를 통해 검증을 거친 값만 저장할 수 있게 했다. -> 이런 식이 캡슐화라고 한다. 

    public static InviteCode of(String value) {
        return new InviteCode(value);
    }​

 

자바에서 표준적으로 객체를 생성하는 정적 팩토리 메서드를 만들 때, of라는 이름을 주로 사용한다. of가 적힌 걸 보고 객체를 생성해 주는 정적 팩토리 메서드라는 걸 알 수 있다. 

 @Override
    public boolean equals(Object o) {
        if (this == o) // 메모리 주소 확인
            return true;
        if (!(o instanceof InviteCode that)) // InviteCode 객체인지 확인
            return false;
        return Objects.equals(value, that.value); // 코드가 같은게 있는지 확인
    }

자바의 모든 클래스는 최상위 클래스인 Object를 자동으로 상속받는다. equals(Object o)는 이 Object 클래스가 기본으로 제공하는 메서드를 재정의한 것이다. 코드에서 Object o는 비교 대상이 될 메모리에 존재하는 어떤 객체를 뜻한다. 자바의 모든 객체는 Object 타입으로 받을 수 있기 때문에 파라미터가 Object o가 된 것이다.

this는 현재 이 equals 메서드를 실행하고 있는 주체 객체를 뜻한다. that은 매개변수로 들어온 Obejct o를 InviteCode 타입으로 형변환하여 꺼낸 상대방 객체를 뜻한다. 

쉽게 설명해 보겠다. 구준표 회원이 1234라는 초대코드를 들고 왔다. 그러면 if(this == o)를 통해 주소 값이 같은 게 있는지 확인한다. 만약 같은 주소값이 있다면 내부 문자열을 확인하지 않고 바로 true를 반환한다. 그다음 넘겨받은 객체가 inviteCode 타입인지를 확인한다. String 문자열을 보냈다면 구조가 다르기 때문에 false를 반환한다. 이제 마지막으로 구준표 회원의 초대 코드가 다른 회원의 초대코드가 맞는 게 있는 Object.equals로 확인한다. 글자가 똑같으면 true를 반환한다.

 

 

 

- @Embedded와 @Embeddable

[Spring][JPA] @Embeddable와 @Embedded를 사용하는 경우

 

 

• Customer 클래스

    @Embedded
    @AttributeOverride(name = "value", column = @Column(name = "code", nullable = false, length = 4))
    private InviteCode inviteCode;

 

 

• CustomerService의 save 메서드

        if (customerRepository.existsByInviteCode(inviteCode)) {
            throw new DuplicateCodeException("초대코드가 중복되었습니다.");
        }

이제 아까 만든 InviteCode 매개변수를 넣어서 초대 코드가 있는지 확인한다. 맨 처음 코드는 Code를 뽑아서 직접 넣었다. 이렇게 되면 JPA의 객체 중심 구조랑 안 맞게 된다. 그래서 현재 코드처럼 바꿔줬다.

 

 

 

• ApiExceptionHandler 클래스

// 어플리케이션 내의 모든 @RestController에서 발생하는 예외를 이곳에서 처리한다.
@RestControllerAdvice
public class ApiExceptionHandler {

    // DuplicateCodeException 예외를 감지하는 메서드이다.
    @ExceptionHandler(DuplicateCodeException.class)
    public ResponseEntity<String> handleDup(DuplicateCodeException e) {
        // HTTP 상태 코드를 409 Conflict로 설정했다.
        return ResponseEntity.status(HttpStatus.CONFLICT).body(e.getMessage());
    }
    
    // DB 레벨에서 제약 조건 위반으로 인해 발생하는
    // DataIntegrityViolationException 예외를 감지한다.
    @ExceptionHandler(DataIntegrityViolationException.class)
    public ResponseEntity<String> handleDataIntegrityViolation(DataIntegrityViolationException e) {
        
        // 밑에 작성한 메서드를 호출하여 초대코드 중복 때문에 일어난건지 확인한다.
        if (isCustomerCodeUniqueViolation(e)) {
            // 초대코드 중복이 맞으면 HTTP 409 상태 코드와 함께 에러 메시지를 반환한다.
            return ResponseEntity.status(HttpStatus.CONFLICT).body("초대코드가 중복되었습니다.");
        }
        // 초대코드 중복이 아닌 다른 DB 제약 조건 위반인 경우 409와 에러 메시지를 반환한다.
        return ResponseEntity.status(HttpStatus.CONFLICT).body("데이터 중복 또는 제약 조건 위반이 발생했습니다.");
    }

    // DB 예외의 이유를 분석하는 메서드이다.
    private boolean isCustomerCodeUniqueViolation(DataIntegrityViolationException e) {
        
        // 스프링 예외 프레임워크 기능으로 래핑된 에러에서 가장 구체적인 에러를 꺼내온다.
        Throwable cause = e.getMostSpecificCause();
        // 삼항 연사자로 최하당 에러가 있으면 갖고 오고 없으면 상위 에러 e를 사용한다.
        String message = cause == null ? e.getMessage() : cause.getMessage();
        // "uk_customer_code"가 포함되어 있는지를 true, false로 반환한다.
        return message != null && message.toLowerCase().contains("uk_customer_code");
    }

}

 

 

 

 

---

 

 

 

 

3. 해결?

• 동시성 문제를 해결하는 방법은 대표적으로 3가지 정도가 있다.
• 첫 번째는 지금 한 방법인 데이터베이스 Unique 제약 조건이다.
• 두 번째는 데이터베이스 비관적 락이다. existByCode를 사용할 때 데이터가 있으면 읽기 잠금을 걸거나, 공유 자원에 대기하도록 만드는 방법이다. 그런데 비관적 락은 현재 프로젝트에 맞지 않는다. 왜냐면 동시에 같은 초대코드가 들어오면 Insert 되기 전이라서 락을 걸 수 없게 된다. 그래서 결국 동일한 초대코드가 넘어가게 된다. 지금 코드에서 사용할 수 있는 방법은 네임드 락이다. 네임드 락은 DB에 데이터가 있든 없든, 메모리 공간에 들어온 초대코드를 가상으로 만들어 락을 걸어서 동시성을 막을 수 있다.
• 세 번째는 Redis를 이용한 분산 락이다. 서버가 여러 대인 환경에서 가장 많이 사용하는 글로벌 동시성 제어 방식이다. 
• 이 중 데이터베이스 Unique 제약 조건이 현재 코드에서 잘 맞다고 생각이 들었다. 어차피 개인 프로젝트고 실제로 서버를 운영할 생각은 없기에 이렇게 해결했다.
• 그나저나 이 코드를 고치면서 새로운 문제를 발견했다. 그건 바로 ElasticSearch 인덱스 저장과 DB의 불일치가 발생할 수 있다는 점이다. 이 부분을 다음에 어떻게 고쳤는지 설명해 보겠다.