좋아요 기능을 통해 살펴보는 동시성 이슈 (synchronized)

안녕하세요, 이번 포스팅에서는 동시성(Concurrency)에 대해 살펴보겠습니다.

(예제 코드는 깃허브에서 확인하실 수 있습니다.)

 

 

동시성(Concurrency) 개념

네이버 사전에 검색해본 동시성은 다음과 같습니다.

어떤 두 사건이 같은 시간에 일어나는 것을 이르는 말

대부분의 웹 서버는 여러 개의 요청(클라이언트)을 동시에 수행할 수 있고, 이는 작성한 코드가 동시에 수행될 수 있다는 의미와 동일한 맥락입니다.

 

이러한 동시성 문제를 살펴보기 위해 게시글에서 클라이언트가 동시에 좋아요를 했을 때 발생할 수 있는 문제에 대해 살펴보겠습니다.

위 그림에 대한 설명은 다음과 같습니다.

• User A가 게시글 1에 좋아요를 클릭했을 때 likeCount 조회 (likeCount = 0)
• User B도 게시글 1에 좋아요를 클릭했을 때 likeCount 조회 (likeCount = 0)
  • B는 A가 클릭한 작업이 처리되기 전의 값을 조회했으므로 카운트는 0
• User A가 클릭에 대해 commit을 하고, 조회 수 + 1 증가 (likeCount = 1)
• User B도 클릭을 통해 commit을 하고, 조회 수 + 1 증가 (likeCount = 1)

두 명의 사용자가 좋아요를 클릭했기 때문에 최종 count는 2가 되어야 하지만, 각 유저가 count를 +1 하기 위해 조회했을 때의 값은 모두 0이기 때문에 2가 아닌 1이 증가되고, 최종 결과는 +1이 증가하여 1이 되는 동시성 문제가 발생합니다.

 

위와 같은 상황을 경쟁 조건(race condition)이라고 합니다.

경쟁 조건(race condition)
 - 여러 프로세스 및 스레드가 동시에 동일한 데이터(공유 데이터)를 조작할 때 타이밍이나 접근 순서에 따라 예상했던 결과가 달라질 수 있는 상황을 의미합니다.

참고: https://www.youtube.com/watch?v=vp0Gckz3z64&t=3s

사용자가 좋아요를 클릭하는 과정을 CPU level에서 봤을때 Read-Modify-Write(조회-수정-쓰기) 과정을 통해 이루어지게 됩니다.

• likeCount를 Register로 Load하고 (Read)
• Register = Register + 1 (Modify)
• Register를 likeCount에 Store 합니다. (Write)

 

 

동시성(Concurrency) 이슈의 문제점

위와 같은 동시성 이슈에는 어떠한 문제점들이 존재할까요?

대략적으로 아래와 같은 문제점들이 존재할 것 같습니다.

• 공유 데이터에 대해 예상 결과가 다르지만 오류가 발생하지 않습니다.
• 코드를 작성할 때는 로컬에서 개발하기 때문에 파악하기가 힘듭니다.
• 비정형적으로 발생하기 때문에 디버깅이 힘들 수 있습니다.

 

 

코드로 살펴보는 동시성 문제

전체 코드는 깃허브에 존재하며, 간단한 주요 로직만 살펴보면 다음과 같습니다.

 

Post id = 1인 게시글의 현재 값입니다.

 

curl 명령어로 다음과 같이 두 개의 요청을 보냅니다.

실행된 쿼리를 보면 update 쿼리는 총 두 개이지만, 이전에 살펴본 상황처럼 최종 결과는 +1만 되었습니다.

 

 

동시성 문제 해결 - 1. synchronized

기존에 동시성 문제와 관련해서 해결할 수 있는 방법 중 하나로 메서드에 synchronized 키워드를 생각해봤습니다.

 

메서드에 synchronized를 적용하면 동시성 문제는 발생하지 않을까요? 테스트를 해보겠습니다.

(Service나 Domain이나 어디에 synchronized를 추가하든 결과는 동일하기에 위치는 크게 상관은 없을 것 같습니다.)

이전과 동일하게 두 번의 요청을 보냈으나 여전히 동시성 문제는 발생하였고, 최종 결과는 위와 마찬가지로 1만 증가했습니다. 🧐

그럼 synchronized가 동시성 문제를 해결할 수 없다는 결과인데요, 어떻게 된 걸까요?

 

위에 대한 문제는 아래 Stackoverflow에서 찾아볼 수 있습니다.

• https://stackoverflow.com/questions/41767860/spring-transactional-with-synchronized-keyword-doesnt-work
• https://stackoverflow.com/questions/29427021/synchronized-transactional-method-in-spring

 

위 포스팅의 내용을 종합해보면 다음과 같습니다.

• 트랜잭션(@Transactional)과 동기화(synchronized)는 서로 다른 개념
• 트랜잭션은 Begin - 로직 실행(count + 1) - Commit의 순서로 진행되는데, 하나의 트랜잭션이 커밋 되기 전 다른 트랜잭션이 실행될 수 있고, 이로 인해 동시성 이슈가 발생
• synchronized 키워드는 메서드가 한 번에 하나의 스레드에서만 실행할 수 있도록 Locking

 

synchronized가 처리되는 과정을 low-level에서 살펴보면 모니터(Monitor)라는 개념을 통해 동기화 과정이 이루어지게 됩니다.

 

Monitor(모니터)는 공유 자원에 대한 접근을 제어하는 객체로, 한 번에 하나의 스레드만 리소스에 접근할 수 있도록 공유 리소스에 대한 접근을 동기화하는데 사용되는 기술입니다.

트랜잭션과 synchronized의 동시성 발생 이슈(Monitor)

Monitor의 처리 과정은 위와 같이 스레드 단위로 메서드를 실행하는 시점에서 모니터 락을 획득(acquire) 및 반환(release) 합니다.

Monitor에 대한 자세한 개념은 아래 영상에 자세히 나와있으니 궁금하시면 영상 & 포스팅을 참고해주세요 🙂
  - https://youtu.be/Dms1oBmRAlo
  - https://happy-coding-day.tistory.com/8

 

따라서 Thread A의 트랜잭션 내에서 likePost() 메서드가 수행된 후 트랜잭션이 커밋 되기 전 Thread B의 likePost() 메서드가 실행이 되기 때문에 예상했던 바와 달리 synchronized 키워드를 통해 동시성 문제를 해결할 수 없습니다.

(커밋이 되기 전 Thread B가 조회를 했기 때문에 언두(Undo) 영역에 존재하는 count가 증가하기 이전 값을 가져오게 됩니다.)

* 언두(Undo)
언두 영역은 UPDATE 문장이나 DELETE와 같은 문장으로 데이터를 변경했을 때 변경되기 전의 데이터(이전 데이터)를 보관하는 곳입니다. 예를 들어 다음 쿼리를 살펴보겠습니다.
MySQL > UPDATE member SET name = '이주현' WHERE member_id = '5';
 
위문장이 실행되면 트랜잭션을 커밋 하지 않아도 실제 데이터 파일 내용은 "이주현"으로 변경이 됩니다. 그리고 변경되기 전의 값이 "홍길동"이라면 언두 영역에는 "홍길동"이라는 값이 백업이 되는 것입니다. 이 상태에서 만약 사용자가 커밋을 하게 되면 현재 상태(이주현)가 그대로 유지되고, 롤백을 하게 된다면 언두 영역의 백업된 데이터(홍길동)를 다시 데이터 파일로 복구합니다.
 
이러한 언두의 데이터는 크게 두 가지 용도로 사용이 됩니다.
1) 트랜잭션의 롤백 대비용
2) 트랜잭션의 격리 수준을 유지하면서 높은 동시성을 제공

위 문제를 해결하려면 트랜잭션이 적용되기 전 단계에서 synchronized 키워드를 적용하거나, @Transactional 제거를 통해 동시성 이슈를 해결할 수 있을 것 같습니다. 별로 좋은 방법은 아닌 것 같지만, 테스트해봅시다.

 

 

1. 트랜잭션이 적용되기 전 synchronized 적용하기

원하는 대로 동시성 이슈는 해결이 되었지만, 성능이 매우 비효율적일 듯 합니다. (아래 2번 참고)

 

 

2. @Transactional 제거

위의 코드처럼 @Transactional 어노테이션을 제거하면 예상했던 결과가 나오긴 하지만, synchronized로 인해 메서드의 모든 동작에 대해 Lock을 걸어 하나의 스레드만 접근이 가능하기 때문에 많은 오버헤드가 발생합니다.

 

약 1000번의 요청만 발생하더라도 대략 11초가 넘는 시간이 소요됩니다.. 😱

synchronized 키워드는 또 다른 문제가 존재하는데요 이는 동일한 프로세스 내의 스레드 단위에서만 동시성을 보장합니다.

즉, 단일 서버라면 동시성 이슈가 발생하지 않겠지만 실질적으로 웹 환경과 같이 여러 대의 서버를 활용하면 동시성을 보장할 수 없습니다.

 

 

3. 트랜잭션의 격리 수준을 SERIALIZABLE으로 변경

성능은 매우 떨어지겠지만, 격리 수준이 가장 높은 SERIALIZABLE를 설정하면 해결되지 않을까? 라고 생각하여 테스트를 해보았습니다.

(트랜잭션의 격리 수준에 대해서는 해당 포스팅을 참고해 주세요.)

하지만 Deadlock이 발생하는데요, 이는 SERIALIZABLE의 특징을 생각해보면 이해할 수 있습니다.

 

SERIALIZABLE의 격리 수준은 SELECT 쿼리가 사용되는 레코드(RECORD)에 대해 읽기 락(Shared Lock)이 걸리게 됩니다.

SELECT * FROM performance_schema.data_locks WHERE LOCK_TYPE = 'RECORD';

Shared Lock은 Lock을 얻은 세션에서 읽기만 가능하며 쓰기(Insert, Update, Delete) 등의 작업을 수행할 수 없습니다.

 

두 트랜잭션이 동일한 데이터(게시글 1)에 대해 읽기 락(Shared Lock)을 걸고, 그 후 서로 쓰기 락(Exclusive Lock)을 걸기 때문에 Deadlock이 발생합니다. (S-lock, X-lock의 경우 서로 양립할 수 없기 때문입니다.)

두 트랜잭션은 쓰기 락을 걸기 위해 서로 Lock이 해제되기를 무한히 기다리며 Deadlock이 발생하게 됩니다.

 

 

정리

이상으로 좋아요 기능을 통해 동시성 이슈와 예제 코드, Java의 synchronized 키워드 등에 대해 살펴보았습니다.

synchronized 키워드를 통해 동시성 이슈를 해결하는 방법도 존재하지만, 여러 대의 서버를 활용하는 웹 환경에서는 사용하기가 힘들 것 같습니다.

 

다음에는 데이터베이스에서 제공하는 낙관적 락(Optimistic Lock) 및 비관적 락(Pessimistic Lock)을 통해 동시성을 제어하는 방법에 대해 살펴보겠습니다.

 

 

📄 참고

• https://stackoverflow.com/questions/41767860/spring-transactional-with-synchronized-keyword-doesnt-work
• https://stackoverflow.com/questions/29427021/synchronized-transactional-method-in-spring
• http://wannte.tistory.com/18
• https://hudi.blog/troubleshooting-of-category-role-concurrency-issue/