[고민 조각 모음] 05. 동시성 제어

실전에 들어오면서 처음으로 겪어보고 많이 고민했던 부분인 동시성 제어 🤔

어떨때 동시성 제어가 필요하고, 어떻게 제어해야할까?!에 대해 엄청나게 많이 고민했던 것 같다.

---

동시성 제어 왜 필요한데? 💁

 

핀테이블은 예약과 스토어 정보 조회 등 여러 기능을 제공하는데, 

이중에서 대기자 등록과 스토어 정보 갱신 부분에서 동시성 오류가 발생하였다.

 

동시성 오류는 어떠한 공유 자원에 동시에 작업이 이루어질 때(insert, update, delete 등) 실행 순서가 뒤죽박죽이 되면서

오류가 생기는것이였는데 동시성 제어를 통해 여러 트랜잭션들이 성공적으로 동시에 실행될 수 있도록 해주어야했다.

 

---

그럼 공유자원을 쓰는곳에는 다 Lock을 걸면 되는거 아니야? 🙅🏻

 

동시성 오류가 발생하는 부분에 모두 Lock을 걸어서 동시성을 제어한다면 성능이 저하될것이고, Lock에 대한 비용이 증가할것이다.

그래서 꼭 필요한 부분에만 Lock을 걸도록 해야하고 여러가지 방법 중 알맞는 방법으로 적용해야한다.

---

기술적 선택  ✅

🔻 비관적락
: 트랜잭션의 충돌이 발생한다고 가정하고 하나의 트랜잭션이 자원에 접근시 락을 걸고, 다른 트랜잭션이 접근하지 못하도록 함

 

1. Shared Lock

• 접근한 트랜잭션이 작업중일 때 다른 트랜잭션에서는 읽기만 가능하고, Exclusive Lock 적용이 불가능하다.

2. Exclusive Lock

• 접근한 트랜잭션이 작업중일 때 다른 트랜잭션에서는 읽기/쓰기가 모두 불가능하고 Shared/Exclusive Lock 적용이 추가적으로 불가능

public interface BoardRepository extends JpaRepository<Board, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select b from Board b where b.id = :id")
    Board findByIdForUpdate(Long id);
}

*/ LockMode 종류

LockModeType.PESSIMISTIC_WRITE
- 일반적인 옵션. 데이터베이스에 쓰기 락
- 다른 트랜잭션에서 읽기도 쓰기도 못함. (Exclusive lock)

LockModeType.PESSIMISTIC_READ
반복 읽기만하고 수정하지 않는 용도로 락을 걸 때 사용
다른 트랜잭션에서 읽기는 가능함. (Shared Lock)

LockModeType.PESSINISTIC_FORCE_INCREMENT
Version 정보를 사용하는 비관적 락

3. 장점과 단점:
충돌이 자주 발생하는 환경에서 롤백의 횟수를 줄일 수 있고, 데이터 무결성을 보장하는 수준이 매우 높음!

---

🔻  낙관적락:

트랜잭션이 충돌이 발생하지 않을것이라는 가정을 하여 충돌을 막지않고 충돌이 난것을 감지하면 그때 처리
=> version의 상태를 보고 충돌을 확인하며 충돌이 확인된 경우 Rollback 하는 방식으로 처리

@Entity
public class Board {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    @Version// 엔티티를 수정할 때 마다 버전이 증가함private Long version;
}

1. 장점과 단점
: 잦은 충돌이 일어나는 경우 롤백 처리에 대한 비용(요청이 실패할 경우 개발자가 직접 롤백처리를 해야함) 이 많이 들어 손해 발생
: 트랜잭션을 커밋하기전에는 충돌 여부를 알 수 없음
: 충돌이 나지 않는다는 가정하에 동시 요청에 대해 처리 성능이 좋음

 

---

🔻 Synchronized :

• Synchronized를 메소드에 명시해주면 하나의 스레드만 접근이 가능하다.
• 멀티스레드 환경에서 스레드간 데이터 동기화를 시켜주기 위해서 자바에서 제공하는 키워드이다.
• Java에서 지원하는 synchronized는, 현재 데이터를 사용하고 있는 해당 스레드를 제외하고 나머지 스레드들은 데이터 접근을 막아 순차적으로 데이터에 접근할 수 있도록 해준다.

 

🧨  Synchronized의 문제점

• Java의 Sychronized는 하나의 프로세스 안에서만 보장이 된다.
• 즉, 서버가 1대일때는 문제가 없지만 서버가 2개 이상일 경우 데이터에 대한 접근을 막을 수 없다.

⇒ Synchronized는 우리 시스템 환경(이중화 환경)에서는 사용할 수가 없다.

---

🔻 ReentrantLock

• Java의 제일 대표적인 기법인 synchronized lock은 검색 시 synchronized block 에 진입 및 탈출 자체에 비용이 소모되기 때문에 남발하게 될 경우 성능 상에 문제가 될 수 있고, 세세한 작업(특정 시간을 기다리고, 그 안에 처리가 안될 경우 패스 혹은 lock을 잡는 순서를 보장 등) 또한 어려움이 있다.
• Syncronized를 사용할 경우 나의 Thread가 상태 정보를 얻을 수 없고, Syncronized 구문을 마주했을 때 누군가 해당 객체의 Locking을 Release 하기까지 무한히 기다리는 수 밖에 없다.
• ReentrantLock의 경우 위의 단점을 보완하여 비교적 간편하게 구현이 가능하다.

 

🧨  ReentrantLock의 문제점

• Synchronized와 동일하게 ReentrantLock도 어플리케이션 내에서 멀티스레드가 동시에 진입하는것을 막는것만 가능하고,
• 다수의 서버가 작동하고 있을 때 각 서버의 스레드의 동시 접근은 막을 수 없기 때문에 우리 서비스에서는 사용할 수 없다.

---

🔻 Redisson Lock

• Redisson Client의 분산락 기법 :
  • Lock에 타임아웃을 지정할 수 있어서 무한정 대기 상태로 빠질 수 있는 위험이 없음
  • pub/sub기능을 사용하여 스핀락을 사용하지 않음<aside> 🌟 pub/sub 기능을 이용한 Redisson의 Lock 획득 프로세스2.1 락 획득에 실패하면 다시 락 해제 메세지를 기다림 2.2 타임아웃시까지 위 프로세스를 반복하다가 타임아웃 시간이 지나면 최종적으로 false를 반환하고 락 획득에 실패했음을 알림
  • </aside>
  • 1. tryLock을 호출하여 락 획득에 성공하면 True를 반환 2. Pubsub를 이용하여 메세지가 올 때 까지 대기하다가 락이 해제되었다는 메세지가 오면 대기를 풀고 다시 락 획득을 시도
  • ⇒ 락이 해제되면 락을 subscribe하는 클라이언트에게 락이 해제되었다는 신호를 보내기 때문에 클라이언트들은 락 획득 확인 요청을 redis로 보내지 않음

✅ Redisson으로 선택한 이유

• Redisson은 TryLock 메서드에 타임아웃이 구현되어 있음 ⇒ 타임아웃을 설정하여 데드락을 방지
• 스핀락을 사용하지 않아서 Redis에 많은 부하를 가하지 않음 ⇒ pub/sub(발행/구독) 시스템을 이용하여 스핀락을 사용하지않음
• 다수의 서버의 환경에서 동시성 문제 해결을 위해서 DB Lock 기법을 사용하여야했고 Redis를 이미 구축하여 사용하고 있기 때문에 이를 활용하여 동시성 문제를 해결하기로 함

---

Lock 외에 비동기적으로 해결할수는 없을까? 📗

 

Spring Batch + Scheduler를 이용한 비동기 업데이트 처리!

• 리뷰 등록시 스토어 정보가 갱신되어야 하는 프로세스
• 매번 리뷰가 작성될 때 마다 스토어 정보가 업데이트가 될 경우 리뷰 작성 행위가 많이 발생하는 환경에서는 서비스에 부담 과중
• 리뷰 등록 시 락을 사용하지않고 업데이트가 된 항목들을 Redis Cache에 저장하고 있다가 일괄적으로 처리하도록 변경

 

1️⃣. 리뷰 작성 시 Database에 리뷰를 저장하고, Redis Cache에는 리뷰가 작성된 스토어ID를 저장한다

 

2️⃣. 일정시간마다 스케줄러가 동작하면서 Redis Cache에 저장된 스토리 ID를 읽고, 배치 파이프라인을 통해 스토어 정보를 갱신한다.
→ https://www.notion.so/With-Redis-6ecbacdfa5fc450081528e56ef5e1d83

스토어 정보 갱신 방법(With.Redis)❓

3️⃣. 데이터베이스에 정보가 업데이트되면 Logstash가 변경된 정보를 추적하여 Elastic Search에 데이터를 업데이트한다.

 

 

---

 그 외 😎

이밖에도 동시성 이슈 관련 내용은 아래의 노션을 참조해주세요~! 

 

https://www.notion.so/PIN-TABLE-721fb45b91454dda8255e0de4ac757ca

[PIN-TABLE] 동시성 제어