따닥 클릭만 막으면 끝날 줄 알았습니다

동시 삽입 이슈(따닥 이슈)

개념 및 문제점

따닥 이슈란 사용자가 어떤 버튼을 동시에 여러 번 클릭해서 동일한 API 요청이 짧은 시간 안에 중복으로 서버에 전달되는 현상을 말한다.

중복 데이터 삽입이 허용되지 않는 정책에서 따닥 이슈로 인한 중복 삽입은 문제가 된다.

이때 서버에서는 각 요청이 독립적인 트랜잭션으로 처리되기 때문에, 단순한 비즈니스 로직 검증만으로는 동시성을 보장할 수 없다.

 

문제 상황

현재 멘토링 예약의 정책은 한 사람이 같은 멘토링을 중복 예약할 수 없다는 정책을 가지고 있다. 여기서 문제 상황은 따닥 요청으로 인한 중복 삽입이 될 수 있다는 것이다.

두 개의 요청이 거의 동시에 들어와 모두 아직 예약이 없다고 판단한 뒤 각각 예약을 생성하게 된다.
그 결과, 한 명의 사용자가 같은 멘토링에 대해 동시에 두 개의 예약을 가지는 문제가 발생한다.

 

동시성으로 인한 따닥 문제를 클라이언트에서 1차적으로 해결할 수 있다. 사용자가 동시에 두 번 클릭했을 때 요청을 하나씩 보내줄 수 있지만, 클라이언트의 코드가 변경되면 문제가 다시 드러나게 된다. 따라서 안정성을 위해서 서버에서도 동시성 문제를 제어해 보자.

 

목표

• 동시성으로 인한 중복 삽입 해결
• 현재 프로젝트의 규모와 상황에 따라서 가장 적절한 해결 방법을 찾는다.
• 중복 삽입은 DB 레벨에서 해결하는 것이 가장 좋다고 생각한다. 따라서 DB 레벨에서 막을 수 있는 방법을 찾는다.
• 구현 난이도가 너무 높지 않은 방법을 찾는다.

환경 정보

서버 및 애플리케이션 환경

• EC2 t4g.small 단일 인스턴스
• Java 21
• Spring Boot 3.5
• Spring Data JPA

DB 환경

• EC2 t4g.small 단일 인스턴스
• MySQL 8.0
  
  

DB 마이그레이션

• Flyway
  
  

테이블 정보

이번 문제의 대상이 되는 Reservation(예약) 테이블이다.

 

인덱스 정보

 

동시성이 발생하는 비즈니스 로직

 

 

원인 분석

원인은 동시에 예약하기 버튼을 두 번 클릭했을 때 동시에 요청이 들어와서 생기는 경쟁상태가 원인이다.

즉, Race Condition이다.

 

validateNoOngoinReservation()에서 중복예약 검증을 하게 되는데, 요청이 동시에 들어와서 만약, DB에 해당 멘토링에 대한 예약이 존재하지 않으면 둘 다 검증을 통과할 수 있다. 그렇게 되면 자연스럽게 예약이 두 번 삽입되게 된다.

위에서 봤던 그림을 다시 보면 이해가 편할 수도 있다.

 

 

해결 방법

복합 유니크 인덱스

가장 먼저 DB 제약 조건을 생각했다.

사용자는 같은 멘토링에 대해서 중복 예약할 수 없다. 여기서 중복은 예약의 상태를 말한다.

즉, 예약은 사용자, 멘토링, 상태로 중복되면 안 된다. 따라서 복합 유니크 인덱스를 생성해 제약 조건을 설정할 수 있다.

 

Reservation에 다음과 같이 복합 유니크 인덱스를 설정해 주자.

(member_id, mentoring_id, status)

flyway 스크립트를 아래와 같이 추가해 준다.

ALTER TABLE reservation
ADD CONSTRAINT uk_reservation_member_mentoring_status UNIQUE (mentee_id, mentoring_id, status);

그리고 동시에 두 개의 Http 요청을 보내는 테스트를 진행한다.

비즈니스 로직을 테스트할 수도 있었지만, 요청을 보냈을 때 응답 시간을 확인하기 위해서 http 테스트로 진행하였다.

결과는 성공적으로 하나는 성공했고, 하나는 실패하여 동시성 제어가 정상적으로 되었다. 성공 요청에 대한 응답 속도도 130ms으로 나쁘지 않다. 실패 응답속도는 예외처리 등으로 인해 조금 느린 것을 확인할 수 있다.

 

단순하게 유니크 제약조건으로 해결 한 줄 알았으나, 사실 해결하지 못했다.

 

잠깐, 상황에 따라서 달라지는 중복 삽입

멘티의 멘토링 예약부터 종료까지의 과정은 다음과 같다.

멘토링을 예약하고 멘토가 승인(또는 거절 -> 거절하면 예약 거절)하면 멘토링이 진행된다. 그리고 멘토링이 끝나면 종료된다.

이때 멘토링의 상태에 따라서 예약의 상태도 변경된다.

예약의 상태는 그림과 같이 "대기/승인/거절/완료"의 4가지 상태가 존재한다.

해당 예약의 상태에 따라서 예약의 중복 삽입이 달라지게 된다.

 

1. 예약이 승인되기 전, 대기 상태인 경우

멘토링 승인이 대기 중인 경우, 멘티는 같은 멘토링으로 예약을 신청할 수 없다.

이때 DB에는 대기 상태의 예약 데이터가 존재한다.

 

2. 예약이 승인되어 멘토링이 진행 중인 경우

멘토링이 진행중인 경우, 멘티는 같은 멘토링으로 예약을 신청할 수 없다.

이때, DB에는 승인 상태의 예약 데이터가 존재한다.

 

3. 예약이 거절된 경우

멘토가 예약을 거절하여 멘토링이 취소된 경우, 사용자는 같은 멘토링으로 다시 예약을 신청할 수 있다.

이때, DB에는 거절 상태의 예약 데이터가 존재하지만 같은 멘티가 같은 멘토링에 대해서 다시 예약 데이터를 추가할 수 있다. (중복 허용)

 

4. 멘토링이 종료되어 예약이 종료된 경우

멘토링이 끝나고 정상 종료된 경우, 사용자는 같은 멘토링으로 다시 예약을 신청할 수 있다.

이때, DB에는 완료 상태의 예약 데이터가 존재하지만 같은 멘티가 같은 멘토링에 대해서 다시 예약 데이터를 추가할 수 있다. (중복 허용)

 

정책 정리

정책을 정리하면 예약의 상태(완료, 거절)에 따라서 조건부로 중복 삽입이 허용되어야 한다.

즉, 지금과 같은 단순한 유니크 제약조건으로는 종료된 예약이 존재해도 다시 예약을 할 수 없게 된다.

 

해결해야 하는 문제 추가

정책에 따라서 중복 허용이 되어야 하므로 해결해야 하는 문제가 추가되었다.

따라서 목표도 아래와 같이 변경되었다.

• 동시성으로 인한 중복 삽입 해결
• 현재 프로젝트의 규모와 상황에 따라서 가장 적절한 해결 방법을 찾는다.
• 중복 삽입은 DB 레벨에서 해결하는 것이 가장 좋다고 생각한다. 따라서 DB 레벨에서 막을 수 있는 방법을 찾는다.
• 구현 난이도가 너무 높지 않은 방법을 찾는다.
• + 예약 상태에 따라서 조건부 중복 삽입 허용
  
  

다시, 해결 방법

이제 해결해야 하는 문제와 목표를 명확히 정했으니 다시 해결 방법을 찾아보자. 앞서서 동시성 문제는 단순한 복합 유니크 인덱스로도 해결할 수 있었다. 이제 예약 상태에 따라서 조건부로 중복 삽입이 가능해야 하니까, 앞에서 생성했던 복합 유니크 인덱스는 제거해야 한다.

다시 원래대로 돌아온 셈이다.

synchronized

자바에서 synchronized 키워드를 사용해서 메서드에 스레드가 동시 접근하지 못하게 막을 수 있다. 예약 생성 메서드에 하나의 스레드만 접근하게 하고, 애플리케이션 레벨의 검증 로직인 validateNoOngoinReservation() 으로 예약 상태를 검증하여 조건부 중복 삽입이 가능하다.

 

어떻게 보면 가장 간단한 방법이다. 만약 단일 프로세스(서버가 1대)라면 이 방법으로 가장 빠르게 문제를 해결할 수 있다.

하지만, 만약 서버가 분산환경으로 확장되어 서로 다른 인스턴스에서 DB에 동시 요청을 하면 중복 삽입이 가능한 구조가 된다.

synchronized 는 단일 애플리케이션에서 의미가 있기 때문에 다른 서버에서의 동시 요청은 막을 수 없다.

 

또 한 가지 찝찝한 부분은, 예약 상태를 검증하는 부분이 애플리케이션 로직에 의존하고 있다. DB 레벨에서는 여전히 중복 삽입이 가능하다는 점이다. 

 

현재는 단일 인스턴스이고, 앞으로도 단일 인스턴스 구조를 유지할 가능성이 높기 때문에 해당 방식을 채택해도 되지만, 여전히 테이블 제약 조건이 아니라 DB 삽입은 막을 수 없기 때문에 선택하지 않았다.

비관적 락

비관적 락은 동시성 문제를 해결하는 대표적인 방법으로 알려져 있다.

중복 검증을 하는 로직에 락을 걸면 되지 않을까?라는 생각을 했는데, 락을 걸 수 없다.

validateNoOngoingReservation()는 내부적으로 existsBy 쿼리메서드를 사용하여 존재 여부를 검증한다.

문제는 existsBy 메서드는 락이 걸리지 않는다. Spring Data JPA의 existsBy 계열 메서드는 기본적으로 단순 SELECT 조회를 한다.

innoDB는 트랜잭션 격리 수준과 무관하게, 일반 SELECT 조회는 MVCC 기반의 스냅샷 조회로 처리되어 Row Lock 이 발생하지 않는다.

메서드에 @Lock(LockModeType.PESSIMISTIC_WRITE)을 설정해도 무시된다.

그럼 다른 방법으로 락을 걸어야 한다.

SELECT FOR UPDATE / SELECT FOR SHARE 쿼리로 락을 획득할 수 있다.

앞선 existsBy 메서드로는 락을 걸 수 없으니 member를 조회하는 쿼리에 비관적 락을 걸어 조회하도록 한다.

그럼 SELECT FOR UPDATE 쿼리가 발생하면서 락이 걸리게 된다.

이렇게 락을 걸게 되면 다른 요청은 같은 row에 대해서 접근하려고 해도 락이 해제될 때까지 대기하게 되어, 동시성 영향을 받지 않게 된다.

동시에 같은 예약 요청을 두 개 보내는 테스트를 실행하고 결과를 보면 동시성 제어가 된 것을 확인할 수 있다.

 

비관적 락을 사용하면 분명 동시성을 제어하여 중복 예약을 막을 수 있다. 그러나, synchronized 처럼 비관적 락도 예약 테이블 자체의 제약 조건이 아닌 우회하는 방법이다. 해당 방식은 비즈니스 로직에 따라서 락의 범위가 달라지고, 중복예약을 허용할 수도 있기 때문이다. 때문에 비관적 락도 선택하지 않았다.

낙관적 락

지금은 낙관적 락을 사용하지 못하는 상황이다.

낙관적 락의 version은 기존에 존재하는 레코드에 update 쿼리가 발생했을 때 카운트 된다.

예약하기의 상황은 중복 삽입 문제이다. 따라서 이미 존재하는 레코드가 없기 때문에 낙관적 락을 사용하기 어려운 부분이 있다.

물론 현재 MentroingStastistc를 통해서 예약 시 통계 테이블에 예약 카운트를 증가시키는 로직을 함께 수행한다.

여기서 MentroingStastistc에 낙관적 락을 걸어 version을 확인할 수 있지만, 순순한 예약로직에서는 동시성 제어를 할 수 없다.

 

분산 락

분산 락을 사용해서 문제를 해결할 수도 있을 것 같다.

현재 인스턴스는 한대지만, 추후 인스턴스가 늘어날 수도 있다. 하지만 이 때도 정말 분산 락이 답일까? 생각해 봤을 때도 고민이 된다.

이유는 다음과 아래와 같았다.

• 다중 인스턴스가 될 가능성이 얼마나 높은가?
• 분산 락에 대한 지식이 부족한 경우, 유지보수가 쉬울까?
• 해당 문제의 우선순위가 최상인가?
• 유지보수에 대한 트레이드오프는?
• 현재 목표에 부합하는 기술인가?

이 문제를 해결하기 위한 목표는 최대한 DB 레벨에서의 해결이고, 과하지 않은 구현이다. 만약, 서버의 인스턴스가 늘어나서 분산 환경이 되어도, DB는 한대를 유지할 가능성이 높다.
DB가 여러대로 분리되면 모르지만 현재로는 분산 락 방법은 목표에 비해 너무 과한 기술이라는 생각이 들어서 선택하지 않았다.

 

Generated Column + 복합 유니크 인덱스 (선택한 방법)

위에서 (mentoring_id, mentee_id, status) 유니크 제약 조건은 완전한 중복 삽입을 막지 못한다고 했다. 이유는 예약상태 즉, status 의 컬럼 값에 따라서 중복예약이 허용되고, 허용되지 않기 때문이다. 그럼 우리에게 필요한 건 미완료 상태에서만 중복 예약이 허용되지 않아야 한다.

어떻게 구현하면 될까?

유니크 제약조건을 둘 것이다. 한 가지 달라지는 것은 특정 상태의 컬럼을 생성해서 그 컬럼으로 복합 유니크를 만들어 줄 것이다.

이 방식은 부분 유니크 인덱스 방식이라고도 하는데, 예를 들면 이런 식이다.

status가 PENDING/APPROVED일 때만 (mentee_id, mentoring_id) 중복 금지

안타깝게도 PostgreSQL는 해당 기능을 정식지원하지만, MySQL에서는 지원하지 않아서 문법적으로 작성할 수 없다.

대신 비슷하게 우회하는 방법이 있다.

Generated Column + 유니크 인덱스 조합으로 해결할 수 있다.

 

Generated Column

Generated Column 은 MySQL 5.7 버전부터 지원하는 기능이다.

MySQL 공식 문서에 따르면 생성 컬럼을 다음과 같이 정의하고 있다.

다른 컬럼 값을 기반으로 자동 계산되는 컬럼이다.

Generated Column 은 직접 값을 저장하거나 입력하지 않고, 다른 컬럼의 값을 기반으로 DB가 자동 계산해서 가지는 컬럼이다.

예를 들면 price, quantity 컬럼이 있을 때 total_price = price * quantity 일 때 total_price가 Generated Column이 된다.

중요한 건 total_price의 값은 사람이 넣는 것이 아니라 DB가 계산해서 넣는다.

 

규칙

Generated Column은 MySQL에서 정한 몇 가지 규칙이 존재한다. 그중 중요한 몇 가지만 살펴보자.

 

1. 결정적(deterministic)이어야 한다.

항상 같은 입력에 대한 같은 결과를 생성해야 한다. Generated Column은 계산 전용 컬럼이다. NOW() 같이 변하는 요소는 항상 금지한다.

 

2. INSERT / UPDATE 시 값 직접 넣기 금지

Generated Column은 직접 값을 넣는 컬럼이 아니다. DEFAULT를 제외한 직접 값을 넣는 것을 허용하지 않는다.

 

3. AUTO_INCREMENT 사용 불가

자동 증가 값은 "상태"이기 때문에 순수 계산이 아니다.

 

구조

Generated Column 은 VIRTUAL 컬럼과 STORED 컬럼, 두 가지 구조를 가진다. 각각의 구조를 간단하게 알아보면 다음과 같다.

구분	VIRTUAL	STORED
개념	조회할 때마다 계산	미리 계산해서 저장
계산 시점	SELECT 시	INSERT / UPDATE 시
디스크 공간	사용 안 함	사용함
조회 속도	느릴 수 있음 (매번 계산)	빠름 (이미 계산됨)
저장 비용	없음	있음
CPU 사용량	조회 시 증가	입력/수정 시 증가
인덱스	가능(InnoDB)	가능

별다른 지정을 해주지 않으면 기본값은 VIRTUAL이다.

 

구현

Reservation 엔티티에 Generated Column을 추가해 준다.

해당 컬럼은 Generated Column의 규칙에 따라서 INSERT/UPDATE가 불가능하므로 @Column 어노테이션의 옵션으로 막아준다.

그리고 현재 프로젝트의 스키마 마이그레이션을 Flyway로 하고 있으니 Flyway 마이그레이션 스크립트도 추가한다.

active_status_checker 라는 가상 컬럼을 추가한다. 이 컬럼은 실제로 DB에 저장되지 않고 조회할 때 계산된다.

status 컬럼의 값에 따라서 다음과 같이 동작한다.

status 값	active_status_checker 결과
PENDING	ACTIVE
APPROVED	ACTIVE
COMPLETE	NULL
REJECTED	NULL

진행 중 상태(PENDING, APPROVDED) -> 'ACTIVE' 값으로 적용

종료 상태 (COMPLETE, REJECTED) -> NULL 처리

추가로 예약(Reservation)은 Soft Delete 처리가 되므로 삭제돼도 데이터가 남아있게 된다.

삭제된 예약은 중복을 허용해줘야 하기 때문에 Soft Delete의 상태를 조건에 추가하였다.

유니크 제약 조건은 NULL은 중복 허용이라는 특징이 있다. 이를 이용해서

진행 중 예약은 중복 금지, 종료된 예약은 중복 허용이라는 비즈니스 정책을 구현할 수 있다.

다음으로 복합 유니크 인덱스를 추가한다.

(mentee_id, mentoring_id, active_status_checker)를 복합 유니크 인덱스로 지정해 3개의 컬럼 조합이 중복되지 않도록 DB레벨에서 강제한다.

서비스 로직도 변경이 필요하다.

before

이랬던 코드가

이렇게 변경되었다.

 

기존의 검증 로직 validateNoOngoingReservation()이 제거되고, reservationRepository.save()시에 active_status_checker 컬럼의 값이 계산되어 중복 예약을 검증한다. 그리고 예외(DataIntegrityViolationException)가 발생하면 적절하게 예외를 처리하고 있다.

 

DataIntegrityViolationException 는 DB 무결성 제약 조건을 위반했을 때 발생하는 예외다. 해당 예외만 잡아서 처리하면 다른 무결성 문제(예: FK/NOT NULL/기타 UNIQUE)도 사용자에게 “이미 예약됨”으로 잘못 안내된다.

해당 로직에서 잡히는 예외는 다른 이유가 아닌, 중복 예약에 대한 예외만 잡아야 한다.

 

그래서 예외를 명확하게 잡기 위해서 DataIntegrityViolationException 가 발생하면 "중복 예약"에 대한 예외인지 한번 더 검증해서

uk_active_reservation 제약 위반일 때만 중복 예약으로 변환하도록 예외의 범위를 좁혔다.

 

 

결과 검증

테스트 코드를 실행해 결과를 검증해 보자. 검증의 목표는 다음과 같다.

• 동시성 제어가 잘 되는지
• 해피 케이스와 예외 케이스 모두 잘 동작하는지

를 검증한다. (테스트 코드는 길이가 길어서 따로 첨부하지 않겠다)

테스트 방법은 Java에서 제공하는 ExecutorService 를 사용하여 동시 요청을 보내도록 구성했다.

중복 예약 테스트와 함께 정상적인 경우의 테스트도 모두 잘 동작하는 것을 확인할 수 있다.

 

 

선택한 방법

결론적으로 Generated Column + 복합 유니크 인덱스를 선택했다. 다른 방법들도 있었지만, 동시 삽입, 중복 삽입 문제는 DB 유니크 제약이 가장 안전한 장치라는 것과 트레이드오프, 구현 난이도를 따졌을 때 현재 상황에서 가장 적절한 방법이라고 판단했다.

하지만, 해당 방법은 예약 상태(Status)에 새로운 상태가 추가될 경우, DB의 가상 컬럼 정의(active_status_checker)도 함께 수정해야 하는 번거로움이 있다.

또한, 해당 방법은 MySQL에 종속된 방법이라 다른 DB를 사용할 경우 호환성을 따져봐야 한다. 현재는 MySQL에서 다른 DB로 변경될 가능성이 낮다고 판단하여 해당 방법을 선택했다.

 

따닥 이슈는 무조건 해결해야 하는 문제인가?

마지막으로, 따닥 이슈를 무조건 해결해야 하는 문제인가? 를 생각해 보면 좋을 것 같다. 문제라고 하면 문제가 맞지만, 도메인 정책, 그때의 상황에 따라서 충분히 선택지가 달라질 수 있다고 생각한다.

 

예를 들어, 댓글 쓰기와 같은 기능도 따닥 이슈가 생길 수 있다. 이것도 막아야 할까?

댓글 쓰기 같은 경우 따닥으로 인한 중복 삽입이 생길 수 있지만, 정책상 중복 댓글을 허용하는 경우가 많다.

이런 경우 따닥 클릭이지만, 꼭 해결해야 할 치명적인 문제는 아니라는 생각이 든다. 해당 상황에서 먼저 해야 할 우선순위가 있다면 그것부터 하는 것이 좋을 것 같다.

만약 그래도 문제를 막아야겠다면, 우선, 클라이언트와 협의를 통해서 1번만 클릭 가능하도록 제한을 둘 것 같다.

 

이 처럼 문제를 발견하고, 어떻게 대할 것인지 고민하는 것도 개발자에게 중요한 덕목이라고 생각한다.