[Redis] 항공 예매 서비스 - 항공권 예매 동시성 이슈 해결을 위한 Redisson 분산 락 적용

📖 목차

 

 

 

---

 

Spring Boot MSA 기반으로 항공권 티켓팅 서비스를 구현하던 중, 항공권 예매 시 발생할 수 있는 동시성 이슈를 해결하기 위해 대기열 서비스에 Redis의 Redisson 라이브러리를 이용해 분산 락을 적용했다.

 

초기 구현 당시 대기열 서비스가 사용자 요청 순서를 보장하고 있었지만,

'대기열 서비스에 적용된 동시성 제어가 항공편 서비스에서의 좌석 수까지 안전하게 보장해 줄 수 있을까?'라는

의문을 가지게 되면서 서비스 간 동시성 제어의 책임 분리에 대한 문제점을 인식하여 개선하는 과정을 정리해 보았다.

   

 

 

 

 

 

 

📌  대기열 서비스에만 적용된 동시성 제어에 의문을 가지계 된 계기

  항공편 예매 서비스의 기본 흐름은 다음과 같다.

1️⃣ 사용자가 항공편 예약 요청
2️⃣ 대기열 서비스에서 해당 항공편의 좌석 수 조회
3️⃣ 좌석 수가 충분하면 대기열에 진입(요청 순서 보장)
4️⃣ 순서에 따라 항공편 서비스에 좌석 차감 요청(동기 호출)
5️⃣ 좌석 차감 후 예약 생성 요청

 

 

 

  초기 구현 당시에는 대기열 서비스가 사용자 요청 순서를 보장하고 있었기 때문에 항공편 서비스 내부에서는 별도의 동시성 제어 없이 좌석 수를 차감해도 안전할 것이라고 판단했다.

< 초기 설계 및 구현 단계 - 항공편 예매 서비스의 흐름 >

 

...
	if(seatCount <= remainingSeats) {
	    // 항공편 좌석 차감
	    flightClient.decreaseSeats(flightId, seatCount);
	    log.info("대기열 선점에 성공 했습니다. 남은 좌석 수: {}", remainingSeats - seatCount);
	    rankOps.remove(key, topUser);
	
	    producerService.sendReserveSuccess(flightId, userId, seatCount);
	    return QueueResponseDto.of(EventStatusEnum.SUCCESS, "대기열 선점에 성공했습니다.");
	} else {
	    log.info("남은 좌석이 없습니다. 남은 좌석 수: {}", remainingSeats);
	    rankOps.remove(key, topUser);
	    deleteExistReserve(flightId, userId);
	    return QueueResponseDto.of(EventStatusEnum.FAILED, "남은 좌석이 없습니다.");
	}

 

 

 

 

 

---

 

 

 

 

 

  테스트 중 발생한 문제나 특정한 오류는 없었지만, 좌석 수의 감소와 증가에 대한 비동기 처리로의 전환 과정에서 로직을 점검하던 중 다음과 같은 의문이 들었다.

 

'대기열 서비스에서 사용자 요청 순서를 보장해 준다고 해도, 항공편 서비스 내부의 좌석 수 감소 작업까지 안전하게 보장할 수 있을까?'

 

 

이러한 의문을 바탕으로 서비스 간 역할을 다시 점검한 결과, 정해진 순서대로 사용자 요청을 관리하는 것은 대기열 서비스의 책임이지만 좌석 수의 변경은 항공 서비스에서 직접 제어해야 할 책임이기 때문에 좌석 수의 원자성을 보장하는 목적의 동시성 제어가 별도로 필요하다는 결론을 도출하게 되었다.

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

📌  대기열 서비스와 항공편 서비스간 책임의 분리

  대기열 서비스와는 달리 항공 서비스의 항공편 좌석 수는 DB 내에서 변경되는 공유 자원으로 여러 스레드나 프로세스가 동시에 접근할 경우, 동시성 제어가 되지 않는다면 좌석 수가 잘못 차감되어 데이터 정합성 문제가 발생할 수 있다. 

* 좌석 수의 차감뿐만 아니라, 좌석 수의 복구 로직도 마찬가지이다.

 

이에 따라 데이터의 일관성을 유지하기 위해 항공편 서비스 내부에서 좌석 수를 변경하는 로직에 Redisson을 사용하여 분산 락을 적용하기로 결정했다.

public class DistributedLockAop {
...
        // 예외 처리 및 락 획득을 재시도하는 로직
        int retryCount = 0;

        while (retryCount < distributedLock.maxRetryCount()) {
            try {
                boolean available = rLock.tryLock(distributedLock.waitTime(),
                        distributedLock.leaseTime(), distributedLock.timeUnit());

                if (available) {
                    log.info("[DistributedLock]: Lock acquired with key: {}", key);
                    try {
                        return aopForTransaction.proceed(joinPoint);
                    } finally {
                        if (rLock.isLocked() && rLock.isHeldByCurrentThread()) {
                            log.info("[DistributedLock]: Lock released with key: {}", key);
                            rLock.unlock();
                        }
                    }
                } else {
                    log.info("[DistributedLock]: Lock acquisition failed with key: {}", key);
                    retryCount++;
                    Thread.sleep(distributedLock.retryDelay());
                }
            } catch (InterruptedException e) {
                log.error("[DistributedLock]: Lock interrupted", e);
                Thread.currentThread().interrupt();
                throw e;
            }
        }
        log.warn("[DistributedLock]: Lock acquisition failed after {} retries with key: {}", retryCount, key);
        throw new LockFailedAfterRetryException();
    }
}

 

// 좌석 수 차감
@DistributedLock(key = "#flightId.toString()")
public void decreaseSeats(UUID flightId, Integer requiredSeats) {
    ...
}

// 좌석 수 복구
@DistributedLock(key = "#flightId.toString()")
public void increaseSeats(UUID flightId, Integer requiredSeats) {
    ...
}

 

AOP 기반으로 @DistibutedLock 어노테이션을 선언하여 항공편 ID에 락을 걸어 동시성 제어를 할 수 있도록 구현했다. AOP 기반으로 분산 락을 구현하는 과정은 아래 포스팅에서 확인할 수 있다.

 

[Redis] 이커머스 서비스 - Redisson을 이용한 분산 락 구현으로 동시성 이슈 해결

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

📌  Redisson 분산 락의 적용

  위에서 언급했듯이 대기열 서비스와 항공편 서비스의 책임을 분리하여 항공편 서비스 내부의 좌석 차감 및 복구 로직에 분산 락을 적용하였다. 그리고 분산 락의 적용 전과 후, 동시성 제어가 정상적으로 동작하는지 확인하기 위해 다음과 같은 조건으로 테스트를 진행했다. 

💡 테스트 진행 조건 💡
✔️ 항공편 좌석 수: 10,000개
✔️ 동시 사용자: 100명
✔️ 요청 수: 10초 동안 동시 요청

< 해당 항공편의 좌석 수를 10,000개로 설정 >

 

 

아래와 같이 좌석 차감 스크립트를 작성하여 k6로 테스트를 진행했다.

import http from 'k6/http';
import { check, fail } from 'k6';

export let options = {
    vus: 100,
    duration: '10s',
};

const token = 'Bearer '; // token 입력 필요
const flightId = '2129373a-1741-45a4-a2b0-56914adcc906';

export default function () {
    const url = `http://localhost:19091/internal/v1/flights/${flightId}/seats/decrease?requiredSeats=1`;

    const headers = {
        Authorization: token,
    };

    let res = http.put(url, null, { headers });

    const success = check(res, {
        'status is 200': (r) => r.status === 200,
    });

    if (!success) {
        console.error(`❌ 요청 실패 | 상태코드: ${res.status} | 응답: ${res.body}`);
    }
}

< k6 테스트 결과 - 요청 건수: 428건 / 요청 성공 확률: 100% >

< 예상한 결과와 다른 좌석 수 / 예상 좌석 수: 9,572개 >

• 테스트 시나리오 : 총 428건의 요청이 모두 성공하였으니 좌석의 수는 10,000개 → 9,572개가 되어야 한다.
• 테스트 결과 : 좌석 수 10,000개 → 9,949개, 요청 수와 다른 51개의 좌석 감소 *

 

 

 

  분산 락을 적용하기 전에는 총 428건의 요청이 확인되었고, 요청이 모두 성공했으니 좌석의 수는 428개가 감소한 9,572개가 되어야 한다. 하지만 예상과 다르게 좌석의 수는 10,000개 → 9,949개로 51개의 좌석만 감소하며 데이터의 정합성과 원자성이 깨진 것을 확인할 수 있었다.

 

 

 

 

 

---

 

 

 

 

 

‼️ 이번에는, 분산 락을 적용 한 후, 동일한 조건으로 테스트를 진행한 뒤 결과를 비교해 보자.

< k6 테스트 결과 - 요청 건수: 2,971건 / 요청 성공 확률: 100% >

< 로그를 통해 락 해제 및 획득 여부 확인 >

< 예상한 결과와 같은 좌석 수 / 예상 좌석 수: 7,029개 >

• 테스트 시나리오 : 총 2,971건의 요청이 모두 성공하였으니 좌석의 수는 10,000개 → 7,029개가 되어야 한다.
• 테스트 결과 : 좌석 수 10,000개 → 7,029개, 요청의 수만큼 좌석 감소 *

 

 

 

  분산 락을 적용한 후에는 총 2,971건의 요청이 확인되었고, 요청이 모두 성공했으니 좌석의 수는 2,971개가 감소한 7,029개가 되어야 한다. 로그를 통해 락 획득 및 해제가 정상적으로 되는 것을 확인했고, 좌석의 수는 예상한 결과와 같이 10,000개 → 7,029개로 정확히 요청의 수만큼 감소한 것을 확인할 수 있었다. 

 

 

 

 

---

 

 

 

 

💡 위에서 진행한 테스트 결과를 정리하자면 다음과 같다. 💡 

✔️ 초기 좌석 수: 10,000개 / 테스트 조건: 동시 100명, 10초간 요청 / 도구: k6 ✔️ 

✅ 분산 락 적용 전
• 요청 수: 428건
• 요청 성공률: 100%
• 기대 좌석 수: 10,000 - 428 = 9,572개
• 실제 좌석 수: 9,949개 (51개만 차감됨)
→ 응답은 성공이라 했지만, 실제 DB에 반영되지 않음
→ 데이터 정합성 문제 발생

---

✅ 분산 락 적용 후
• 요청 수: 2,971건
• 요청 성공률: 100%
• 기대 좌석 수: 10,000 - 2,971 = 7,029개
• 실제 좌석 수: 7,029개 (정상 차감)
→ 로그에서 락 획득 및 해제 정상 확인, 실제 DB에 성공적으로 반영
→ 데이터 정합성과 원자성 보장 확인

---

 

✅ 결과 정리
• 서비스 경계를 명확히 이해해야 함
• 순서 보장과 원자성 보장은 별개의 문제
• 공유 자원에 대한 정합성 보장 책임은 해당 자원을 직접 다루는 서비스에 있어야 함
• 분산 락을 통한 동시성 제어는 필수적

* 좌석 수의 증가에 대해서도 같은 방식으로 테스트를 진행하였고, 정상적으로 동작하는 것을 확인할 수 있었다.

 

 

 

 

  이렇게 문제점 개선 후, 테스트를 진행하여 결과를 확인하고 정상 작동하는 것까지 확인해 보았다. 이를 통해 서비스 간 경계를 명확히 이해하고, 단순히 요청 순서를 제어한다고 해서 데이터 정합성이 보장되지 않는다는 점과 실제 자원을 제어하는 쪽에서 명시적으로 동시성 제어를 해야 한다는 점에 대해 조금 더 깊이 이해하게 되었다.

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

여기까지 서비스 간 동시성 제어의 책임 분리에 대한 문제점의 인식과 해결과정에 대해 정리해 보았다.