트러블 슈팅

동시성 제어 기술 선택 과정

1. ReentrantLock 과 ConcurrnetHashMap을 사용하여 동시성 제어

처음에는 하나의 서버 인스턴스로만 운영되는 것으로 가정하고, ReentrantLock으로 잠금을 관리하고 ConcurrentHashMap을 사용하여 특정 객체에 대한 접근을 동시성 제어했습니다.

이 방법은 단일 서버 환경에서는 잘 동작하지만, 서버 인스턴스가 여러 개로 늘어나면 각 서버 간에 잠금을 공유할 수 없어 동시성 제어가 어려워집니다.

2. 비관적락을 사용하여 동시성 제어

이후에는 서버에서 많은 충돌이 발생하는 것으로 예상되어, 낙관적 락 방식보다는 비관적 락 방식을 선택했습니다.

이 방법은 데이터베이스의 락(lock)을 사용하여 동시성을 제어합니다. 하지만 이 방식도 분산 데이터베이스 환경에서는 동시성 제어에 한계가 있습니다.

3. Redis 분산락을 사용한 동시성 제어

마지막으로, Redis를 분산 락으로 사용하여 동시성 제어를 구현했습니다. Redis는 메모리 기반의 데이터 저장소로서 읽기와 쓰기가 빠르기 때문에 동시성 제어에 적합합니다.

또한 Redisson과 같은 라이브러리를 사용하면 분산 환경에서도 락을 효과적으로 관리할 수 있습니다.

이렇게 선택한 각 동시성 제어 방법의 장단점을 고려하여, 최종적으로 Redis 분산 락을 채택했습니다. 이 방법은 확장성과 성능 면에서 우수하며, 분산 환경에서도 효과적으로 동작합니다.

콘서트 대기열 구현 기술 고민

1. DB를 사용하여 대기열 구현

초기에 대기열을 구현할 때는 데이터베이스를 활용하여 대기열을 관리했습니다. 대기열은 특정 테이블에 저장되고, 각 토큰은 만료 시간과 상태 값을 가지고 있었습니다.

이러한 상태 값은 스케줄러를 통해 주기적으로 확인되어 각 토큰의 상태를 업데이트했습니다.

이 방법은 간단하고 직관적이었으나, 대규모 트래픽이 발생할 경우 데이터베이스에 부하가 커질 수 있고, 실시간성이 낮을 수 있습니다.

2. Redis sorted set을 활용한 구현

나중에는 Redis의 sorted set을 활용하여 대기열을 구현했습니다.

Redis의 sorted set은 멤버와 스코어(score)로 구성되어 있어서, 스코어를 기준으로 정렬된 상태로 데이터를 저장할 수 있습니다. 이를 이용하여 토큰을 스코어로 설정하고, 만료 시간을 스코어로 사용하여 대기열을 관리했습니다.

Redis의 sorted set을 사용함으로써 데이터베이스에 비해 빠르고 실시간성이 높은 대기열을 구현할 수 있었습니다. 또한 Redis의 내결함성과 확장성을 활용하여 대규모 트래픽에도 안정적으로 대응할 수 있습니다.

이러한 이유로, Redis sorted set을 활용한 대기열 구현을 진행하였습니다.