동시성 문제를 해결해보자! 분산락 구현하기 (네임드락 - Named Lock 활용하기)

🌱 들어가기 전

DB 공부하다가 '네임드락'에 대해서 알게 되었는데, 네임드락을 사용하면 분산락을 구현할 수 있다는 글을 보고 한 번 테스트해보고 싶어서 글을 작성해보고자 한다. 전체 소스코드는 여기에서 확인 가능하다. (뭔가 테스트용 레포 만들기 애매해서 그냥 안 쓰는 레포에다가 하려다 보니 코틀린으로 작성하게 되었다.)

 

---

 

🌱 분산락이란?

분산락이란 멀티 스레드 환경에서 공유 자원에 접근할 때, 데이터의 정합성을 지키기 위해 사용하는 기술이다.

여기서 여러 스레드가 공유 자원을 접근하며 경쟁하는 상황을 'Race Condition (경쟁 상태)'라고도 부르며, 자바에서는 'synchronized'라는 키워드를 통해서 하나의 스레드만 접근할 수 있도록 동기화 기능을 제공한다. 하지만, 스프링 웹 애플리케이션 환경에서 규모가 커진다면 서버 역시 여러 대로 띄울 확률이 높다. 이러한 다중 서버에서는 synchronized 만으로는 동시성 이슈를 해결할 수 없기 때문에 다른 방법을 사용해야 하는데, 분산락을 구현하는 다양한 기법들을 통해서 이를 해결할 수 있다. 

 

---

 

🌱 도메인 설계

실시간 트래픽이 몰리는 환경에 대해서 고민해봤는데, '온라인 티켓팅 서비스'가 딱 떠올랐다.

그래서 간단하게 특정 콘서트에 대해서 티켓을 발행해주는 서비스를 만들기로 결정했다.

도메인이라고 할 것도 없지만, 분산락 테스트를 위해서 최대한 간결하게 설계하였다.

콘서트와 티켓은 1:N 관계를 가지고, 콘서트는 몇 좌석까지 가질 수 있는지에 대한 개수를 가지고 있는다. (ticketLimit)

 

@Entity
class Concert(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val name: String,

    @Column(nullable = false)
    val ticketLimit: Int,

    concertTickets: MutableList<ConcertTicket> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "concert")
    val concertTickets: MutableList<ConcertTicket> = concertTickets.toMutableList()

    fun isFull(): Boolean {
        return concertTickets.size >= ticketLimit
    }
}

콘서트에는 정원이 가득 찼는지 확인하는 커스텀 메서드만 간단하게 추가해주었다.

 

@Entity
class ConcertTicket(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val userId: Long,

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(
        name = "concert_id",
        foreignKey = ForeignKey(name = "fk_ticket_concert_id")
    )
    val concert: Concert
)

이거는 콘서트에 대한 티켓 도메인이다.

 

CREATE TABLE `concert_ticket` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `user_id` bigint NOT NULL,
  `concert_id` bigint NOT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_ticket_concert_id` (`concert_id`),
  CONSTRAINT `fk_ticket_concert_id` FOREIGN KEY (`concert_id`) REFERENCES `concert` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3

CREATE TABLE `concert` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `ticket_limit` int NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3

테이블은 위와 같이 JPA가 만들어 주었다.

 

---

 

🌱 코드 설계

💬 Repository

fun ConcertRepository.getConcertById(id: Long): Concert {
    return findConcertById(id) ?: throw NotFoundException("콘서트 정보가 존재하지 않습니다.")
}

interface ConcertRepository : JpaRepository<Concert, Long> {
    fun findConcertById(id: Long): Concert?
}

fun ConcertTicketRepository.getConcertTicketById(id: Long): ConcertTicket {
    return findConcertTicketById(id) ?: throw NotFoundException("콘서트 티켓 정보가 존재하지 않습니다.")
}

interface ConcertTicketRepository : JpaRepository<ConcertTicket, Long> {
    fun findConcertTicketById(id: Long): ConcertTicket?
}

 

💬 Service

@Service
@Transactional(readOnly = true)
class ConcertService(
    private val concertRepository: ConcertRepository,
    private val concertTicketRepository: ConcertTicketRepository
) {
    ...
    
    @Transactional
    fun createConcertTicket(
        concertId: Long,
        concertTicketCreateRequest: ConcertTicketCreateRequest
    ): Long {
        val concert = concertRepository.getConcertById(concertId)
        if (concert.isFull()) {
            throw ConcertFullException("정원이 가득 찼습니다.")
        }
        val concertTicket =
            ConcertTicket(userId = concertTicketCreateRequest.userId, concert = concert)
        val savedConcertTicket = concertTicketRepository.save(concertTicket)
        return savedConcertTicket.id
    }

    ...
}

 

여기서 중요한 메서드는 티켓에 대한 생성 메서드이기 때문에, 이 부분만 주목하자.

콘서트 티켓 생성 시 정원이 가득 차면 예외가 발생하도록 만들었다. 만약 요청이 여러 개가 오다가 정원이 가득차면 더 이상 insert는 진행되지 않을 것이다.

 

 

💬 Controller

@RestController
@RequestMapping("/concerts")
class ConcertController(
    private val concertService: ConcertService
) {
    ...

    @PostMapping("/tickets/{concertId}")
    fun createConcertTicket(
        @PathVariable("concertId") concertId: Long,
        @RequestBody concertTicketCreateRequest: ConcertTicketCreateRequest
    ) {
        concertService.createConcertTicket(concertId, concertTicketCreateRequest)
    }

}

 

티켓을 생성하는 API이다. 콘서트나 티켓 조회 같은 간단한 API는 전체 소스코드에 남겨두었다.

 

---

 

🌱 JMeter 테스트

부하 테스트를 어떻게 진행할까 고민했는데, JMeter를 활용하면 좋을 것 같아서 진행해보았다.

java -jar -Dserver.port=8080 ticketService.jar
java -jar -Dserver.port=8081 ticketService.jar

먼저, 분산된 환경을 만들기 위해 8080, 8081 2개의 포트를 띄워서 진행하였다.

 

샘플 데이터로 콘서트 1번에 대한 데이터를 미리 삽입해두었다.

해당 콘서트의 제한 인원은 100명으로, 예상 시나리오라면 100명 이상이 자리잡았을 때 오류가 발생할 것이다.

 

200개의 스레드를 활용하여 2개의 프로세스에서 동시에 콘서트 티켓 발행 요청을 날렸다.

select count(*) from concert_ticket;

그 결과, 100명까지만 받아야 하는데도 불구하고 111개의 값이 들어간 것을 확인할 수 있다.

 

왜 이런 문제가 발생한 것일까?

여러 개의 스레드가 조회하는 시점에서는 분명 가득차있지 않았지만, 검증을 통과해버린 스레드가 동시에 여러 개가 발생하면서 insert 연산 역시 한 번에 진행되어 100개가 넘는 데이터가 삽입된 것이다.

 

---

 

🌱 Named Lock으로 분산락 구현하기

그렇다면, 위의 상황을 해결하기 위해서는 어떻게 해야 할까?

간단하다. 티켓을 저장하는 로직에 대해서 순차적으로 처리할 수 있도록 만들면 되는 것이다.

 

fun LockRepository.executeWithLock(
    lockName: String, timeout: String, action: () -> Unit) {
    try {
        getLock(lockName, timeout)
        action()
    } finally {
        releaseLock(lockName)
    }
}

interface LockRepository: JpaRepository<ConcertTicket, Long> {

    @Query("select get_lock(:name, :time)", nativeQuery = true)
    fun getLock(@Param(value = "name") name: String,
                @Param(value = "time") time: String)
                
    @Query("select release_lock(:name)", nativeQuery = true)
    fun releaseLock(@Param(value = "name") name: String)
}

네임드락을 정의해주기 위해서 위와 같이 락을 획득하는 getLock()과 락을 해제하는 releaseLock() 메서드를 선언하였다.

두 가지 모두 jpql이 아닌 native query를 사용해야 하기 때문에, nativeQuery 옵션을 true로 선언해주었다.

 

getLock의 경우 파라미터로 입력받은 name에 대해서, 입력받은 time 만큼 락을 획득하기를 시도한다.

만약 time 값으로 음수를 넣으면 락을 획득할 때까지 무한 대기하기 때문에 주의해야 한다.

나는 MySQL 8.0을 사용하고 있어서 name으로 60자 이내를 넣어야 한다.

 

releaseLock의 경우 입력받은 name에 대해서 획득한 락을 해제하는 역할을 한다.

⭐️ 명시적으로 락을 획득했다면 명시적으로 락을 꼭 해제해줘야 하기 때문에 알아두자.

 

또한, 람다를 통해서 원하는 메서드 전후로 락을 걸고 해제하도록 만들기 위해 executeWithLock() 메서드를 만들어 주었다.

락 해제의 경우 finally를 통해 예외가 발생하더라도 꼭 실행되도록 만들었다.

 

@Component
class ConcertServiceFacade(
    private val lockRepository: LockRepository,
    private val concertService: ConcertService
){
    @Transactional
    fun createConcertTicket(
        concertId: Long,
        concertTicketCreateRequest: ConcertTicketCreateRequest
    ) {
        val lockName = "concert_$concertId"
        val timeout = "3000"
        lockRepository.executeWithLock(lockName, timeout) {
            concertService.createConcertTicket(concertId, concertTicketCreateRequest)
        }
    }
}

그리고, facade 패턴을 사용하여 lockRepository에 대한 부분을 분리하였다.

비즈니스 로직과 DB 관련 로직을 분리하는 차원에서 별도의 서비스를 생성했다고 생각하면 된다.

lockName으로는 중복되지 않게 하게 위해서 concert_라는 prefix와 concertId를 생성해주었고, 타임아웃은 3초 정도 주었다.

 

@Transactional(propagation = Propagation.REQUIRES_NEW)
fun createConcertTicket(
    concertId: Long,
    concertTicketCreateRequest: ConcertTicketCreateRequest
) {
	...
}

그리고, ⭐️ 기존의 콘서트 티켓 발행 로직에서 트랜잭션 전파 속성을 변경해줘야 한다.

이는, 락을 제어하는 커넥션과 비즈니스 로직을 위한 커넥션을 분리하기 위해서이다.

 

만약 락을 제어하는 로직과 비즈니스 로직이 동일한 트랜잭션으로 묶여 있다면, 비즈니스 로직에서 쿼리가 날라가고 커밋이 되었을 때 커넥션이 반환될 때 락이 함께 반환되지 않을 수 있다. 또한, 비즈니스 로직이 수행하는 역할이 많다면 (위 상황은 아니지만, 외부 호출을 진행하거나, 로직 자체가 길거나) 트랜잭션이 길어지기 때문에 락에 대한 제어과 비즈니스 로직의 트랜잭션을 분리하는 것이 좋다. 

 

@PostMapping("/tickets-lock/{concertId}")
fun createConcertTicketWithLock(
    @PathVariable("concertId") concertId: Long,
    @RequestBody concertTicketCreateRequest: ConcertTicketCreateRequest
) {
    concertServiceFacade.createConcertTicket(concertId, concertTicketCreateRequest)
}

이제, 만든 facade 클래스를 호출하는 간단한 end-point를 추가하여 호출해보자.

실행을 해보면 이런 식으로 락을 얻기 위해서 엄청난 호출이 일어난다.

2023-06-23T16:57:19.359+09:00 ERROR 81614 --- [o-8080-exec-289] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction] with root cause java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30005ms. at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:696) ~[HikariCP-5.0.1.jar!/:na] at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:181) ~[HikariCP-5.0.1.jar!/:na] at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:146) ~[HikariCP-5.0.1.jar!/:na] at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:128) ~[HikariCP-5.0.1.jar!/:na]

만약 타임아웃으로 설정한 시간 내에 락을 얻지 못하면 위와 같이 락을 얻지 못했다는 오류가 발생한다.

 

하지만, 성공적으로 락을 얻었다면 insert 쿼리 이후 락을 해제하게 된다.

즉, 순차적으로 락을 잡고, 락이 잡혀있는 동안에는 또 다시 동일한 이름의 락을 걸 수 없기 때문에 해당 락이 풀릴 때까지 대기하게 된다.

 

최종적으로 실행 결과를 보면 위와 같이 딱 100개의 정원만 차게 된다.

 

---

 

🌱 Connection Pool Size 조절하기

spring:
  datasource:
    hikari:
      maximum-pool-size: 100

스레드를 200개로 했기 때문에 connection pool size를 조금 더 늘려서 테스트를 해봐도 괜찮지 않을까 생각이 들었다.

그래서 connection pool size를 100으로 설정하고 테스트를 진행해보았다. (default는 10이다)

 

Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction] with root cause java.sql.SQLNonTransientConnectionException: Data source rejected establishment of connection, message from server: "Too many connections" at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:111) ~[mysql-connector-j-8.0.33.jar!/:8.0.33]

이전에 비해서 티켓 삽입에 대한 속도는 빨라졌지만, 위와 같이 'Too many connections' 오류가 발생하였다.

 

show variables like 'max_connections';

확인해보니, 기본적으로 mysql에서 제공하는 최대 커넥션 수는 151개이다.

2대의 서버에서 100개씩 점유하고, 총 200개의 요청이 오다 보니 위와 같이 오류가 발생한 것으로 파악되었다.

 

이런 상황에서는 mysql 서버의 max_connections 수를 충분히 늘리거나, 혹은 hikari pool size를 좀 더 줄이는 방향이 있다. 나는 hikari pool size를 줄이는 방향으로 진행했다. 75로 진행한다면 딱 151개니까 오류가 발생하지 않을 것이라고 예측했다. (1개는 아무 클라이언트가 연결되어 있지 않아도 기본적으로 점유하고 있다. 아마 MySQL 내부에서 사용하는 스레드가 아닐까 추측한다.)

 

show status where `variable_name` = 'Threads_connected';

실제로 2대의 서버를 띄운 다음, 연결된 스레드의 수를 보면 정확하게 151개를 점유한 것을 볼 수 있다.

 

티켓 생성 결과를 보니까 정확하게 100개만큼 차있는 것을 확인할 수 있다.

 

또한, grep을 통해 too many connections 오류가 발생했는지 확인했는데, 100개가 차는 동안 발생하지 않았다.

 

---

 

이번 포스팅에서는 간단하게 named lock을 통해서 분산락을 구현해보았다.

단일 서버가 아닌 다중 서버에서 동시성이 중요한 기능을 구축해야 할 때 redis 같은 외부 인프라 서비스 구축 비용이 부담된다면 이렇게 네임드락을 활용해서도 충분히 진행할 수 있다는 생각이 들었다. 다만, 네임드락에 대한 이해도 있어야 하기 때문에 락에 대한 모니터링을 철저하게 해야겠다는 생각이 들었다. 특히, 타임아웃을 적절하게 설정해서 꼭 점유한 락에 대해서 해제할 수 있도록 하는 게 중요하다는 걸 느꼈다. 또한, 지금은 엄청 작은 규모의 테스트였지만, 실제 운영에서 thread 수와 connection 수를 잘 설정해서 사용자의 요청을 처리해야겠다고 생각했다. 다음 포스팅에서는 redis를 활용해서 분산락을 구현해봐야겠다.

 

 

🌱 REFERENCE

https://hudi.blog/distributed-lock-with-redis/

https://sudal.site/namedLock/