[항해플러스 7기 백엔드] 2주차 회고 (2) - 트랜잭션 격리수준, 공유 락과 배타 낙관적 락과 비관적 락

1주차 과제의 미션이 멀티 스레드 환경에서의 동시성 이슈를 해결하는 것이었다면, 2주차 과제의 미션은 멀티 인스턴스 환경에서의 동시성 이슈를 해결하는 것이었다. (DB는 MySQL 또는 MariaDB 사용하기,,)

멀티 인스턴스 환경에서 동시성 이슈를 해결하기 위한 방법 중 하나는 DB 레벨에서 Lock을 사용하는 것이다.

 

MariaDB의 트랜잭션 격리수준(transaction isolation) 기본은 "REPEATABLE READ"이다. 

---

트랜잭션 격리수준(Isolation Level)

1. Read Uncommitted (Level 0)

•  어떤 트랜잭션의 내용이 커밋이나 롤백과 상관없이 다른 트랜잭션에서 조회가 가능하다.
•  정합성의 문제가 많은 격리 수준으로 RDBMS 표준에서는 격리수준으로 인정하지 않는다.
• SELECT문이 실행되는 동안 해당 데이터에 Shared Lock이 걸리지 않는다. (Dirty Read 발생)

Dirty Read
- 아직 커밋되지 않은 다른 트랜잭션의 데이터를 읽는 것.

2. Read Commited (Level 1)

• 한 트랜잭션의 변경 내용이 커밋되어야만 다른 트랜잭션에서 조회가 가능하다.
• 대부분의 RDBMS에서 기본적으로 사용하는 격리수준이다.
• SELECT문이 실행되는 동안 Shared Lock이 걸린다. 조회 시에는 실제 테이블 값이 아닌 Undo 영역에 백업된 레코드 값을 가져온다. (Non-repeatable Read 발생)

Non-repeatable Read
 - 다른 트랜잭션이 커밋한 데이터를 읽을 수 있는 것.
 - 한 트랜잭션에서 같은 쿼리로 2번 이상 조회했을 때 그 결과가 상이한 상황.
 - 하나의 트랜잭션에서 동일한 SELECT문을 실행했을 때 항상 같은 결과를 가져와야 하는 REPEATABLE READ의 정합성에 어긋난다. 

3. Repeatable Read (Level 2)

• 트랜잭션이 시작되기 전에 커밋된 내용에 대해서만 조회가 가능하다.
• MySQL, MariaDB에서 기본으로 사용하며 Non-repeatbale Read가 발생하지 않는다.
• 트랜잭션이 완료될 때까지 SELECT문이 사용하는 모든 데이터에 Shared Lock이 걸린다. 이는 트랜잭션 범위 내에서 조회한 데이터의 내용이 항상 동일함을 보장한다.
• Phantom Read가 발생할 수 있다.

Phantom Read
다른 트랜잭션이 커밋한 데이터가 있더라도 자신의 트랜잭션에서 읽었던 내용만을 사용하는 것.
즉, 한 트랜잭션에서 같은 쿼리를 2번 이상 조회했을 때 없던 결과가 조회되는 상황.
보통 데이터의 삽입이 발생했을 경우에 발생한다.

4. Serializable (Level 3)

• 가장 단순하면서 엄격한 격리수준이다. 하지만 성능 측면에서는 동시 처리성능이 가장 낮다.
• Phantom Read가 발생하지 않는다.
• 트랜잭션들이 동시에 일어나지 않고, 순차적으로 실행되는 것처럼 동작한다.
• 하지만, 거의 사용되지 않는다.

---

공유 락(Shared Lock) vs. 배타 락(Exclusive Lock)

공유 락 (Shared Lock)

• 공유 락(Shared Lock)은 읽기 락(Read Lock)이라고도 불린다.
• 공유 락이 걸린 데이터에 대해서는 읽기 연산(SELECT)만 실행 가능하며, 쓰기 연산은 실행 불가능하다.
• 공유 락이 걸린 데이터에 대해 다른 트랜잭션도 공유 락을 획득할 수 있으나 배타 락은 획득할 수 없다.
• 공유 락을 사용하면, 조회한 데이터가 트랜잭션 내내 변경되지 않음을 보장한다.

배타 락 (Exclusive Lock)

• 배타 락(Exclusive Lock)은 쓰기 락(Write Lock)이라고도 불린다.
• 데이터에 대해 배타 락을 획득한 트랜잭션은 읽기 연산과 쓰기 연산을 모두 실행할 수 있다.
  (다른 트랜잭션은 읽기 작업과 쓰기 작업을 모두 수행할 수 없다.)
• 배타 락을 획득한 트랜잭션은 해당 데이터에 대한 독점권을 갖는 것이다.

---

낙관적 락(Optimistic Lock) vs. 비관적 락(Pessimistic Lock)

낙관적 락(Optimistic Lock)

• 트랜잭션이 데이터를 읽을 때 데이터가 변경되지 않았다고 가정하고, 실제 데이터를 업데이트하거나 커밋할 때만 충돌 여부를 검사한다.
• 일반적으로 낙관적 락에서는 version의 상태를 기반으로 현재 데이터가 읽은 시점 이후에 변경되었는지 확인을 통해 충돌을 확인한다.
• 비관적 락과 달리 DB 레벨이 아닌 애플리케이션 레벨에서 처리된다.
• 락을 사용하지 않아 성능 측면에서 이점이 있지만 충돌이 빈번하게 발생하는 환경에서는 효율이 떨어질 수 있다.

비관적 락(Pessimistic Lock)

• 트랜잭션이 데이터를 읽거나 변경하기 전에 공유 락 또는 배타 락을 걸어 두는 방식이다.
• 트랜잭션끼리의 충돌이 발생한다고 가정하고 일단 락을 건다.
• 비관적 락은 Repeatable Read 또는 Serializable 정도의 격리성 수준을 제공하여 데이터의 무결성을 보장하는 수준이 높아 충돌이 자주 발생하는 환경에서는 성능 측면에서 유리할 수 있다.
• 하지만 데이터 자체에 락을 걸기 때문에 데드락의 가능성과 성능 저하의 위험성을 고려해야 한다.

---

이번 과제에서 내가 사용한 방식은 비관적 락을 이용한 방식이었다.

비관적 락의 쓰기 잠금 방식을 사용해 다른 트랜잭션이 해당 데이터에 대해 읽기와 쓰기 작업을 수행하지 못하도록 하여 동시성 이슈를 제어할 수 있도록 하였다.

 

JPA에서 비관적 락은 메서드에 @Lock 어노테이션을 선언하여 간단하게 사용할 수 있다.

@Lock(LockModeType.PESSIMISTIC_READ) : 공유 락을 걸어 다른 트랜잭션이 읽기는 가능하지만, 쓰기는 불가능
@Lock(LockModeType.PESSIMISTIC_WRITE) : 배타 락을 걸어 다른 트랜잭션에서는 읽기와 쓰기 모두 불가능

 

테스트는 1주차와 동일한 방식으로 ExecutorService와 CountDownLatch를 이용해서 작성했다.

---

2주차 과제를 진행하면서 클린 아키텍처에 대한 이해와 멀티 인스턴스 환경에서의 동시성 제어를 하는 방법을 학습할 수 있었다.

그리고 테스트 코드를 작성하는 게 점점 익숙해지고 있다. 현업에서도 코드를 작성하면서 테스트 코드를 메서드마다 함께 작성하고 있는데 테스트 코드를 작성하기 용이하게끔 로직을 구현하려는 나의 모습을 발견할 수 있었다.😮✨

 

그리고 이번 과제에서는 따봉 👍을 받았다..

 

지난 토요일부터 시작된 3주차부터는 3주 동안 마일스톤과 설계부터 시작해 하나의 서버를 구축하는 과제를 진행한다,,

2주차에서도 ERD 설계를 진행하였지만 이번 주차는 시퀀스 다이어그램도 그려야한다,,

그래도 2주차에서 ERD를 그려봐서인지 설게 단계에 큰 부담은 없다,, (걱정은 있다,,)

항해 과정을 진행하면서 항해 커리큘럼이 섬세하게 잘 짜여져 있다고 느낀다. 주차별로 내용이 확장되는 느낌이다. 

매주 매주 정말 많이 배우고 있다.❤ 남은 과정도 화이팅,,