1. 동시성 제어 정의

동시성 제어(Concurrency Control)란, 여러 사용자나 프로세스가 데이터를 공유할 때 발생할 수 있는 문제를 해결하기 위해, 데이터베이스 시스템이 트랜잭션을 순서대로 실행하는 것이 아니라, 트랜잭션이 동시에 실행될 수 있도록 허용하면서도 데이터의 일관성과 무결성을 유지할 수 있도록 하는 기술이며, 데이터베이스 시스템에서 매우 중요한 개념 중 하나이다.

2. 동시성 제어 목적

• 여러 사용자가 DB에 접근하더라도 데이터의 일관성을 보장하고 데이터의 무결성을 유지
• 위를 만족하며 데이터베이스 시스템의 성능과 효율성을 유지하는 것

1. 분실된 갱신(Lost Update)
   • 두개의 트랜잭션이 같은 데이터를 갱신하는 작업을 진행하게 되면서 하나의 작업이 진행되지 않는 경우
2. 모순성(Inconsistency)
   • 두개의 트랜잭션이 같은 데이터를 동시에 갱신하게되어 사용자가 원하는 결과와 일치하지 않은 상태가 되는 경우
3. 연쇄복귀(Cascading Rollback)
   • 두개의 트랜잭션이 같은 데이터를 갱신하는 작업을 진행하는 과정에서 하나의 트랜잭션이 실패하면 원자성에 의해 두 트랜잭션 모두 복귀하는 경우
4. 비완료 의존성(Uncommitted Dependency)
   • 한개의 트랜잭션이 실패하였을때, 이 트랜재션이 회복하기전에 다른 트랜잭션이 실패한 수행 결과를 참조하는 경우

3. 동시성 제어 방법

3-1. Locking

Locking이란?

• Locking은 공유 자원에 대한 동시 액세스를 제어하는 전통적인 방법이다.
• 단일 스레드 또는 단일 프로세스에서만 동작하며, 한 번에 하나의 스레드만 공유 자원에 액세스할 수 있다.
• 신뢰성과 안전성이 높으며, 어떤 수준의 locking을 적용하느냐에 따라 교착 상태나 경쟁 조건과 같은 문제를 방지할 수 있다.
• 하지만 동시성 처리 속도가 저하될 수 있고, 대기 시간이 발생할 수 있다.
• 기본적으로 lock 연산과 unlock 연산을 사용한다.

Locking의 종류

• 공유 잠금 (shared lock/s-lock): 데이터를 읽을 때 사용하는 락
  • 공유잠금을 설정한 트랜잭션은 데이터 항목에 대해 읽기 연산(read)만 가능하다.
    • T1에서 x에 대해 S-lock을 설정했다면, T1은 read(x) 연산만 가능하다.
  • 하나의 데이터 항목에 대해 여러 개의 공유잠금이(S-lock) 가능하다.
    • T1에서 x에 대해 S-lock을 설정한 경우, 동시에 T2에서도 x에 대해 S-lock을 설정할 수 있다.
  • 다른 트랜잭션도 읽기 연산(read) 만을 실행할 수 있다.
    • T1에서 x에 대해 S-lock을 설정했다면, T2에서도 T1이 S-lock(x)을 실행하는 동안 read(x) 연산만 가능하다.
• 배타 잠금 (exclusive lock/x-lock): 데이터를 변경할 때 사용하는 락
  • 배타잠금을 설정한 트랜잭션은 데이터 항목에 대해서 읽기 연산(read)과 쓰기 연산(write) 모두 가능하다.
    • T1에서 x에 대해 S-lock을 설정했다면, T1은 read(x) 연산과 write(x) 연산 모두 가능하다.
  • 하나의 데이터 항목에 대해서는 하나의 배타잠금(X-lock)만 가능하다.
  • 동시에 여러 개의 배타잠금은 불가능하다.
    • T1에서 x에 대해 X-lock을 설정했다면, T1에서 unlock(x)를 하기 전까지 T2에서 x에 대해 X-lock을 설정할 수 없다.
  • 다른 트랜잭션은 읽기 연산(read)와 쓰기 연산(write) 모두 불가능하다.
    • T1에서 x에 대해 X-lock을 설정했다면, T2에서는 T1에서 unlock(x)를 하기 전까지 read(x), write(x) 연산이 모두 불가능하다.

• 추가) 교착상태 (deadlock)
  • 모든 transaction이 대기 상태에 들어가 아무런 진행이 일어나지 않는 상태를 교착상태라고 한다. 교착상태에 빠지면 외부에서 강제로 트랜잭션을 중단하거나 잠금을 해제하지 않는 이상 무한정 대기 상태로 남게 된다.

---

Locking을 활용한 동시성 제어 기법

• 낙관적 락 (optimistic lock)
  • 충돌이 발생할 가능성이 낮은 경우 사용되는 동시성 제어 기법이다.
  • 충돌이 발생하면 재시도 또는 병합을 통해 충돌을 해결한다.
  • 실제로 lock을 사용하지 않고 version을 이용함으로서 정합성을 맞추는 방법이다. 데이터를 읽을 때 lock을 사용하지 않고, 업데이트 시 내가 읽은 version이 맞는지 충돌 여부를 확인하여 처리한다.
  • 즉, 자원에 lock을 직접 걸어서 선점하지 않고, 동시성 문제가 실제로 발생하면 그때가서 처리하는 방식이다.
• 비관적 락 (pessimistic lock)
  • 충돌이 발생할 가능성이 높은 경우 사용되는 동시성 제어 기법이다.
  • 데이터를 읽거나 수정하기 전에 lock을 획득하여 다른 사용자의 액세스를 차단하고, lock을 가진 스레드만 접근하도록 제어한다.
  • 데이터에 대한 배타적인 액세스 권한을 보장하여 충돌을 방지한다.
  • 실제로 데이터에 lock을 걸어서 정합성을 맞추는 방법으로, 자원 요청에 따른 동시성 문제가 발생할 것이라고 예상하고 lock을 걸어버리는 방법이다.
  • 즉, 트랜젝션이 시작할 때 s-lock이나 x-lock을 실제로 걸고 시작한다.
• 낙관적 락 vs. 비관적 락

	낙관적 락	비관적 락
장점	트랜젝션을 필요로 하지 않고, 별도의 lock을 사용하지 않으므로 성능적으로 좋다.	동시성 문제가 빈번하게 일어난다면 rollback의 횟수를 줄일 수 있기 때문에 성능적으로 좋다.
단점	동시성 문제가 빈번하게 일어나면 계속 rollback 처리를 해주어야 하며, 업데이트가 실패했을 때 재시도 로직도 개발자가 직접 작성해야 한다.	모든 트랜젝션에 lock을 사용하기 때문에, lock이 필요하지 않은 상황이더라도 무조건 lock을 걸어서 성능상 문제가 될 수 있다. 특히 read 작업이 많이 일어나는 경우 단점이 될 수 있다. 또한, 선착순 이벤트같이 많은 트래픽이 몰리는 상황이나 여러 테이블에 lock을 걸면서 서로 자원이 필요한 경우, 데드락이 발생할 수 있고 이는 비관적 락으로 해결할 수 없는 부분이다.

• 분산락 (distributed lock)
  • 여러 컴퓨터 또는 프로세스 간에 공유된 자원에 대한 동시 액세스를 제어하기 위해 사용된다.
  • 분산 시스템에서 동시성 문제를 해결하기 위해 사용되며, 분산된 서버 또는 클러스터 간의 상호작용이 필요하다.
  • 주로 데이터베이스나 메시지 큐 등의 분산 시스템에서 사용된다.
  • 대표적인 분산락 기법으로는 ZooKeeper, Redis 등이 있다.
  • Redis는 RedLock이라는 알고리즘을 제안하며 3가지 특성을 보장해야한다고 한다.
    • 오직 한 순간에 하나의 작업자만이 락(lock) 을 걸 수 있다.
    • 락 이후, 어떠한 문제로 인해 락을 풀지 못하고, 종료된 경우라도 다른 작업자가 락을 획득할 수 있어야합니다.
    • Redis 노드가 작동하는한, 모든 작업자는 락을 걸고 해체할 수 있어야합니다.
  • 분산 락을 구현하기 위해 lock에 대한 정보를 Redis에 저장하고 있어야한다. 그리고 분산환경에서 여러대의 서버들은 공통된 Redis를 바라보며, 자신이 공유 자원에 접근할 수 있는지 확인한다.
• 스핀락 (spin lock)
  • 자원에 대한 접근이 필요할 때 무한루프를 돌면서 반복적으로 확인하며, 다른 스레드가 lock을 해제할 때까지 대기한다.
  • 경쟁 상태 (2개 이상의 프로세스가 공유 자원을 동시에 읽거나 쓰는 상황)가 짧고 자원 점유 시간이 길지 않은 경우에 효과적이다.
  • 주로 멀티코어 시스템에서 사용되며, 락 획득을 위해 CPU를 계속 사용하므로 서버에 많은 부하를 주어 주의해야 한다.
• 참고 자료
  • 동시성 제어 기법 — 잠금(Locking) 기법
  • [database] 낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock)
  • 상품 주문 동시성 문제 해결하기 - DeadLock, 낙관적 락(Optimistic Lock) & 비관적 락(Pessimistic Lock)
  • [Redis] 분산락(Distribution Lock) 을 구현해 다중화 서버에서 발생하는 동시성 문제 제어하기

---

3-2. MVCC (Multi-Version Concurrency Control)

MVCC 등장 배경: Locking의 한계

• lock은 해당 데이터를 선점한 사용자가 데이터의 lock을 해제하기 전까지는 다른 사용자가 해당 데이터를 컨트롤하는데 제약이 있다
  • 한 데이터에 대해 s-lock이 걸렸으면 다른 트랜젝션은 read는 할 수 있지만 write는 할 수 없다.
  • 한 데이터에 대해 x-lock이 걸렸으면 다른 트랜젝션은 read와 write 모두 할 수 없다.
• MVCC는 이런 locking의 단점을 보완하기 위해 만들어졌다.

MVCC란?

• 하나의 레코드에 여러 버전이 관리된다는 의미를 가진다.
• 즉, MVCC는 데이터의 업데이트를 할 때 기존의 내용을 덮어쓰지 않고, 그 데이터의 새로운 버전을 만든다.

1. Versioning (버전 관리): 각 트랜잭션이 데이터를 읽거나 수정할 때 해당 데이터의 버전을 관리한다. 즉, 트랜잭션이 시작될 때의 데이터 상태를 유지한다.
2. Snapshot Isolation (스냅샷 격리): 트랜잭션은 동시에 실행되지만 서로 격리된 스냅샷을 사용하여 데이터에 접근한다. 각 트랜잭션은 자신이 시작된 시점의 데이터 스냅샷을 사용하므로 다른 트랜잭션의 변경 사항에 영향을 받지 않는다.

• 특징
  • MVCC의 접근 방식은 잠금을 필요로 하지 않기 때문에 일반적인 RDBMS보다 매우 빠르게 작동한다.
  • 데이터를 읽기 시작할 때, 다른 사람이 그 데이터를 삭제하거나 수정하더라도 영향을 받지 않고 데이터를 사용할 수 있다.
  • 대신 사용하지 않는 데이터가 계속 쌓이게 되므로 데이터를 정리하는 시스템이 필요하다.
  • MVCC 모델은 하나의 데이터에 대한 여러 버전의 데이터를 허용하기 때문에 데이터 버전이 충돌될 수 있으므로 애플리케이션 영역에서 이러한 문제를 해결해야 한다.
  • UNDO 블록 I/O, CR Copy 생성, CR 블록 캐싱 같은 부가적인 작업의 오버헤드 발생한다.
• 참고 자료
  • MVCC에 관하여 정리

---

3-3. BullQueue

BullQueue란?

• Nest.js에서 제공하는 Redis 기반 분산 작업 큐로 분산 환경에서 작업을 처리하고 관리할 수 있다.
• Queue Design Pattern을 활용해 동시성 문제를 해결할 수 있다.
• 비동기적으로 실행되어야 하는 작업들을 큐에 추가하고 처리할 수 있다. 이 작업들은 백그라운드에서 실행되며, 큐에 추가된 작업들은 FIFO 방식으로 처리된다.
• Nest에서는 @nestjs/bull package를 제공한다.
  1. 작업 관리: 큐에 작업을 추가하고, 작업의 상태를 추적하고, 작업을 실행 및 완료할 수 있다. 작업은 비동기적으로 실행되며, 결과나 상태 변경은 이벤트를 통해 처리할 수 있다.
  2. 작업 우선순위: 작업에는 우선순위를 부여할 수 있다. 우선순위에 따라 큐에서 처리되는 순서가 달라질 수 있어, 중요한 작업이 먼저 처리되도록 조절할 수 있다.
  3. 작업 재시도 및 실패 처리: 작업이 실패한 경우, BullQueue는 재시도 및 실패 처리를 지원한다. 재시도 횟수나 실패 처리 전략은 개발자가 설정할 수 있으며, 오류에 대처하고 안정적인 작업 처리를 보장할 수 있다.
  4. 작업 상태 모니터링: BullQueue는 작업의 상태를 모니터링하고 추적할 수 있는 기능을 제공한다. 작업의 진행 상황을 확인하고, 완료 또는 실패 여부를 확인할 수 있다.

BullQueue를 선택한 이유

1. 유연한 작업 큐 및 작업 처리: 작업들을 큐에 추가하고 워커 프로세스가 이를 처리하는 방식으로 동시성을 제어할 수 있다. 이를 통해 비동기적으로 작업을 처리하고 작업 처리의 유연성을 높일 수 있다.
2. 분산 환경에서의 동시성 제어: 성능 개선을 위한 분산 서버 환경을 구축하는 상황이 생길 경우, 여러 서버 또는 클러스터 간에 작업을 공유하고 분산 처리를 수행할 수 있다.
3. 상태 관리 및 이벤트 알림: 작업의 상태를 관리하고 이벤트 알림을 제공한다. 작업의 진행 상황을 모니터링하고 필요에 따라 작업의 완료, 오류 또는 다른 상태 변경에 대한 알림을 받을 수 있다. 이를 통해 작업의 상태 변화를 실시간으로 추적하고 필요한 조치를 취할 수 있다.

• 참고 자료
  • Documentation | NestJS - A progressive Node.js framework
  • [NestJS] Redis Message Queue 구현해보기
  • [Nest.js][동시성 문제] Bull Queue
  • [Nest.js] 동시성 문제 다루기 with. JMeter, Bull Queue, event-emitter

• 번외) Apache Kafka: 실시간 대량 데이터 처리, 분산 스트리밍 플랫폼 (microservice)
  • 동시성 제어는 MSA에서 서비스 간의 동시에 실행되는 작업들을 제어하고 동기화하는 과정을 의미. 동시성 제어는 분산 시스템에서 중요한 요소이지만, Kafka 자체는 동시성 제어를 목적으로 디자인된 툴은 아님. Kafka는 메시지 전달과 데이터 스트리밍을 위한 시스템으로 사용되며, 동시성 제어를 위해서는 다른 메커니즘과 도구들을 사용해야 함.
  • Kafka는 분산 데이터 스트리밍 플랫폼으로서, 대용량의 데이터를 안정적으로 전송하고 저장하기 위한 시스템.
  • Kafka는 고가용성과 확장성을 갖춘 메시지 큐 시스템으로, 다양한 애플리케이션 간에 데이터를 신속하게 전송하고 처리할 수 있도록 도와줌. MSA(Microservices Architecture)에서는 Kafka를 이용하여 각각의 독립적인 마이크로서비스 간에 메시지 기반 통신을 수행할 수 있음. 이를 통해 이벤트 기반 아키텍처를 구현하고, 서비스 간의 느슨한 결합과 확장성을 갖출 수 있음.

4. 동시성 제어 테스트 모니터링 툴

Artillery

• Artillery를 선택한 이유
  1. JavaScript 기반: Artillery는 JavaScript로 작성된 스크립트를 사용하여 성능 테스트를 수행한다.
  2. 실시간 모니터링 및 결과 분석: Artillery는 테스트 진행 중에 실시간으로 모니터링 정보를 제공하고, 결과를 실시간으로 분석할 수 있는 기능을 제공한다. 동시성 처리를 수행하면서 실시간으로 성능 지표를 모니터링하고, 이를 기반으로 테스트를 조정하거나 성능 이슈를 신속하게 파악할 수 있다.
  3. 유연성과 확장성: Artillery는 다양한 동시성 시나리오를 지원하고, 테스트 스크립트를 유연하게 작성할 수 있는 기능을 제공한다. 다양한 동시 사용자 수, 요청 패턴 및 시나리오를 시뮬레이션하여 애플리케이션의 동시성 처리 능력을 효과적으로 평가할 수 있다.
• 다른 선택지: Apache JMeter
  • JMeter는 다양한 프로토콜과 기능을 지원하는 강력한 성능 테스트 도구이다. 다양한 테스트 시나리오, 요청 유형, 데이터 조작 및 추출, 보고서 생성 등의 기능을 제공한다. 만약 다양한 프로토콜 지원이 필요하거나 복잡한 테스트 시나리오를 다루어야 한다면 JMeter가 더 좋을 수 있지만, 우리의 동시성 제어 처리 부분은 크게 복잡한 시나리오를 가지지 않기 때문에 Artillery같이 가벼운 모니터링 툴을 사용하는 것이 적합하다고 판단하였다.