동시성 처리

예전 뱅킹 서비스를 주제로 한 프로젝트를 진행했지만, 동시성에 대한 처리를 해주지 못 한 점을 보완하기 위해 공부한 내용을 정리한 글입니다.

 

동시성 이슈 해결방법

synchronized

• 하나의 프로세스에서만 동작. 즉 서버가 여러대이고 서로 다른 서버에서 동시에 접근한다면 synchronized 는 기능을 발휘할 수 없다.
• @Transactional 을 사용하면, 트랜잭션이 커밋할 때 잠깐의 텀에 다른 스레드가 접근할 수 있어서 동시성 문제를 해결할 수 없다.

Lock (DB에서 재공하는 락기능을 사용)

Pessimistic Lock (비관적 락)

• row나 table 단위로 락을 검
• 자원 요청에 따른 동시성 문제가 발생할 것이라고 예상하고 락을 걸어버리는 비관적 락
• 공유락(Shared Lock)과 베타락(Exclusive Lock) 둘 중 하나의 락을 걸어주는 방법
• 공유락(Shared Lock) : 다른 트랜잭션에서 읽기만 가능
• 베타락(Exclusive Lock) : 다른 트랜잭션에서 읽기, 쓰기 둘 다 불가능.
• 데드락이 발생할 수 있기 때문에 주의해야 함.
  • 데드락 : 현재 서로 원하는 자원이 상대방에 할당되어 있어서 두 프로세스는 무한정 wait 상태에 빠짐
• 데이터 정합성을 보장하는 대신에 조회할 때 매번 락을 사용하므로 데이터베이스에 부담을 줄 수 있다.
• SpringDatJpa에서 respository에 @Lock 어노테이션을 사용해 구현할 수 있음

@Lock(LockModeType.PESSIMISTIC_READ) // 공유락 : 다른 트랜잭션에서 읽기만 가능
@Lock(LockModeType.PESSIMISTIC_WRITE) // 베타락 : 다른 트랜잭션에서 읽기도 쓰기도 못함
@Query("select s from Stock s where s.id = :id")
Stock findByIdWithPessimisticLock(Long id);

쿼리를 보면 SELECT ~ FOR UPDATE  쿼리가 나가는 것을 확인할 수 있음.
즉  “데이터를 수정하려고 찾은 것이니, 다른 분들은 건드리지 마세요!” 라는 뜻

Optimistic Lock (낙관적 락)

• 실제로 Lock을 이용하지 않고 버전을 이용함으로서 정합성을 맞추는 방법
• 데이터를 읽은 후에 update를 수행할 때 현재 내가 읽은 버전이 맞는지 확인하며 update를 진행
• 즉, 자원에 Lock을 걸어서 선점하지 않고 동시성 문제가 발생하면 그때가서 처리하는 낙관적 락 방식.
• version에 변경이 감지됐을 때 재요청을 하는 로직을 직접 작성해줘야 함
• SpringDatJpa에서는 respository에 @Lock 어노테이션을 사용해 구현할 수 있음

@Lock(LockModeType.OPTIMISTIC)
@Query("select s from Stock s where s.id = :id")
Stock findByIdWithOptimisticLock(Long id);

• 또한 @Version 어노테이션을 사용해 version 필드를 Stock 객체 필드에 추가해줘야 함

@Version
private Long version;

Named Lock

• 별도의 공간에 Lock을 생성하고 반환하여 동시성 이슈를 해결함.
• Named Lock은 트랜젹션이 끝날 때 자동으로 반환되지 않기 때문에 반환 로직을 직접구현해줘야 함.

public interface LockRepository extends JpaRepository<Stock, Long>{
	
	// 3000ms 초 동안 lock 획득을 시도한다.
	@Query(value = "select get_lock(:key, 3000)", nativeQuery = true)
	void getLock(String key);
	
	@Query(value = "select release_lock(:key)", nativeQuery = true)
	void releaseLock(String key);
}

mysql에서 get_lock(), release_lock()을 통해 lock을 제어할 수 있다.

• Pessimistic , Optimistic Lock은 item에 대해서 lock을 걸었다면 named lock은 별도 MySQL 서버 메모리 공간에 lock을 건다.

Redis

두 가지 방식 (Lettuce, Redisson) 이 있음

Lettuce(Spring Data Redis는 기본 클라이언트로 Lettuce를 사용)

• Setnx 명령을 활용하여 분산락을 구현 (Set if not Exist - key:value를 set할 때, 기존의 값이 없을 때만 set하는 명령어)
• Setnx 는 Spin Lock 방식이므로 retry 로직을 개발자가 작성해줘야 함.
• Spin Lock 이란, Lock을 획득하려는 스레드가 Lock을 획득할 수 있는지 확인하면서 반복적으로 SETNX를 시도하는 방법 → redis에 많은 부하 발생 → 락 획득 요청 사이 사이마다 Thread.sleep을 통해 부하를 줄여줄 수 있음
• 자체적인 타임아웃 구현이 존재하지 않아 어플리케이션 코드 상에서 타임아웃을 직접 구현해야 함

Redisson

• Publish-Subscribe 기반으로 Lock 구현 제공
• Pub-Sub 방식이란, 채널을 하나 만들고 락을 점유중인 스데르가 락을 해제했음을 대기중인 스레드에게 알려주면 대기중인 스레드가 락 점유를 시도하는 방식
• Lettuce와 다르게 대부분 개발자가 별도의 Retry 방식을 작성하지 않아도 됨.