[42 Cabi] 사물함 대여/반납 동시성 문제와 해결 과정

이 글은 2022년 10월 경 42 Cabi 프로젝트에서 사물함 대여와 반납 기능 테스트 중 발생한 에러와 그를 해결하기 위한 과정을 백앤드 팀원분들과 공동으로 정리한 글입니다.

🫠 개요

🪨 문제 분석

• 대여하는 사람이 기존에 대여했는지 확인하기 위해, 대여 기록을 저장하는 테이블(lent)과, 사물함 테이블(cabinet)을 조회함.

• 대여하고자 하는 사물함이 대여중인지 확인

• 대여 기록에 대여 정보 삽입

1. 동시에 여러 사용자가 대여나 반납을 수행한다고 하더라도 동작이 서로간 중첩되어선 안된다. 먼저 들어온 요청을 모두 처리하고 난 후 다음 요청을 처리해야 한다.

2. 하나의 요청을 처리하다가 문제가 발생(대여에는 성공했는데 캐비넷의 상태 변경에 실패 등)했을 때 데이터의 무결성을 지키기 위해 해당 트랜잭션 자체를 롤백시켜야 한다.

• 클라이언트 1이 사물함을 대여 시도함. 곧바로 클라이언트 2가 동일한 사물함에 대여 시도함.

• 클라이언트 1이 대여 처리 됨. 하지만 클라이언트 2가 대여 시도를 하는 시점에서, 클라이언트 1이 대여 하기 전의 정보를 가지고 있으므로, 클라이언트 2도 대여 처리를 함.

• 따라서 정원보다 많은 클라이언트가 사물함을 대여함.

📖 트랜잭션의 원칙과 격리 수준

팀원 sichoi님께서 관련 내용을 조사하여 이슈로 남겨주셨습니다. https://github.com/innovationacademy-kr/42cabi/issues/474#issuecomment-1287243004

트랜잭션

트랜잭션의 속성 → ACID 원칙

• Atomicity 트랜잭션으로 묶인 작업이 쪼갤 수 없는 원자성을 가지고 있어야 합니다. ex) 사물함의 정원만큼 대여가 발생하면, 사물함의 상태는 반드시 사물함 정원 초과 로 설정되어야 합니다.

• Consistency 트랜잭션의 동작이 무결성을 보증하는, 일관성이 있어야 하는 원칙입니다. ex) 2명이 대여중인 사물함에 3번째 사람의 대여 요청 트랜잭션이 커밋되면 해당 사물함의 상태는 사물함 정원 초과 로 설정되어야 하고, 그 때 모든 대여자의 만료 시간이 설정되어야 합니다.

• Isolation 트랜잭션이 진행되는 도중의 데이터를 다른 트랜잭션에서 읽어 올 수 없도록 보장하는 원칙입니다. ex) 아직 대여가 진행중인데 다른 트랜잭션에서 해당 사물함을 대여중인 인원을 읽어서는 안된다.

• Durability 트랜잭션이 성공했을 경우 해당 결과의 영속성이 보장되어야 하는 원칙입니다. ex) 대여라는 트랜잭션이 성공한 경우 서비스가 갑작스럽게 멈추거나 장애가 생기더라도 디스크에 저장되어 영구적으로 저장되어야 합니다.

트랜잭션의 격리 수준

• READ UNCOMMITTED 트랜잭션 내에서 SELECT 쿼리 실행시 다른 트랜잭션에서 커밋되기 전 업데이트 된 데이터를 가져올 수 있습니다. 하지만 업데이트 되기 전의 값을 가져오기 때문에 DIRTY READ 현상이 발생할 수 있습니다.
• 장점 : 동시 처리 시에 성능이 가장 좋음.
• 단점 : 격리 관련 이슈가 발생할 확률이 가장 높음 (DIRTY READ, PHANTOM READ, NON-REPEATABLE READ)

• READ COMMITTED 트랜잭션 내에서 SELECT 쿼리 실행시 다른 트랜잭션에서 커밋이 완료된 결과만 조회할 수 있기 때문에 DIRTY READ 현상이 발생하지 않습니다. 보통 아무런 격리 수준을 걸지 않으면 이 격리 수준으로 설정됩니다.
• 장점 : 반영되지 않은 값을 함부로 가져오지 않아, DIRTY READ 가 발생하지 않음.
• 단점 : 트랜잭션 내에서 특정 테이블에 대한 값을 여러번 조회하면, 동시성 이슈가 생길 수 있음. (PHANTOM READ, NON-REPEATABLE READ)

• REPEATABLE READ 하나의 트랜잭션에서 SELECT 쿼리 실행시 그때 당시의 조회 결과를 해당 트랜잭션의 커밋이 끝날 때까지 유지합니다. 그래서 해당 트랜잭션에서 읽어오는 값은 다른 트랜잭션의 영향을 받지 않습니다. 예를 들면, 하나의 트랜잭션에서 1번 사물함을 대여중인 유저의 수를 2라고 읽었다면 몇 번을 다시 조회해도 트랜잭션이 종료되기 전까지는 2라고 읽습니다.
• 장점 : 트랜잭션 내에서 특정 테이블에 대한 값을 여러번 조회하는 경우 동일한 값을 반환함.
• 단점 : 트랜잭션이 시작될 때 가져온 값을 토대로 동작하기 때문에, PHANTOM READ 가 발생하여 동시성 이슈가 생길 수 있음.

• SERIALIZABLE 하나의 트랜잭션에서 SELECT 쿼리 실행시 그 트랜잭션이 끝날때까지 다른 트랜잭션에서 SELECT 쿼리를 실행한 테이블에 업데이트를 못하게 막습니다.
• 장점 : PHANTOM READ 도 발생하지 않아, 원자성을 가장 완벽하게 지킴.
• 단점 : 성능이 가장 낮으며, 잘못된 쿼리 작성 시 데드락이 발생할 수 있음.

🤔 1차 문제 해결 과정

🫠 대여 로직 리팩토링

🫠 SERIALIZABLE 설정과 이유

🚨 동시 대여는 괜찮지만, 동시 반납시 문제 발생

🪨 2차 문제 분석

1. 클라이언트 1이 사물함을 대여중인 인원 확인을 위해 lent 테이블에 S Lock

2. 클라이언트 2이 사물함을 대여중인 인원 확인을 위해 lent 테이블에 S Lock

3. 클라이언트 1이 lent 테이블에 insert를 하기 위해 X Lock 시도 (S Lock이 걸려있으므로 대기 상태에 빠짐)

4. 클라이언트 2이 lent 테이블에 insert를 하기 위해 X Lock 시도 (S Lock이 걸려있으므로 대기 상태에 빠짐)

5. 데드락 발생!!!

📖 RDBMS의 Lock (InnoDB 기준)

Lock

공유 Lock (Shared Lock → S Lock)

배타적 Lock (eXclusive Lock → X Lock)

Blocking

Deadlock

InnoDB의 Lock

• FOR SHARE : read 작업 시, 각 row에 S Lock을 겁니다.

• FOR UPDATE, UPDATE, DELETE : write 작업 시, 각 row에 X Lock을 겁니다.

SERIALIZABLE 의 Lock

원인은 2-Phase Locking

🤔 2차 문제 해결 시도 (Conservative 2PL)

🫠 점유 대기 부정 시도…

🚨 여전히 Deadlock 발생

User 테이블

Cabinet 테이블

Lent 테이블

1. A 트랜잭션에서 user_id=1인 유저가 빌린 lent와 cabinet 정보를 조회한다. (SELECT … FROM Lent JOIN User, Cabinet WHERE user_id = 1) 🔐 A 트랜잭션에서 Lent 테이블의 lent_id=1인 row에 X Lock을 건다. 🔐 A 트랜잭션에서 Cabiner 테이블의 cabinet_id=1인 row에 X Lock을 건다.

2. A 트랜잭션에서 cabinet_id=1인 사물함을 대여중인 lent의 개수를 조회한다. (SELECT COUNT(*) FROM Lent WHERE lent_cabinet_id = 1)
A 트랜잭션에서 lent_id=1인 값을 확인한다. (이미 X Lock이 걸려있으므로 Pass)
🔐 A 트랜잭션에서 lent_id=2인 row에 X Lock을 건다.
A 트랜잭션에서 lent_id=2인 값을 확인한다.
🔐 A 트랜잭션에서 lent_id=3인 row에 X Lock을 건다.
A 트랜잭션에서 lent_id=3인 값을 확인한다. A 트랜잭션에서 lent의 개수로 3을 얻는다.

3. B 트랜잭션에서 user_id=2인 유저가 빌린 lent와 cabinet 정보를 조회한다. (SELECT … FROM Lent JOIN User, Cabinet WHERE user_id = 2) ⛔️ A 트랜잭션에서 lent_id=2인 row에 X Lock을 걸었으므로 unlock할 때까지 기다린다.

4. C 트랜잭션에서 user_id=3인 유저가 빌린 lent와 cabinet 정보를 조회한다. (SELECT … FROM Lent JOIN User, Cabinet WHERE user_id = 2) ⛔️ A 트랜잭션에서 lent_id=3인 row에 X Lock을 걸었으므로 unlock할 때까지 기다린다.

5. A 트랜잭션에서 lent_id=1인 값을 삭제하고 반납 프로세스를 처리한 다음 commit한다. (DELETE Lent WHERE lent_id = 1) 🔓 A 트랜잭션에서 lent_id=1, 2, 3인 row에 걸었던 lock을 해제한다.  🔓 A 트랜잭션에서 cabinet_id=1인 row에 걸었던 lock을 해제한다.

6. lent_id=3인 row와 cabinet_id=1인 row에 걸린 lock이 해제되었으므로 user_id=3인 유저가 빌린 lent와 cabinet 정보를 조회하기 위해 🔐 C 트랜잭션에서 cabinet_id=1인 row에 X Lock을 건다. 🔐 C 트랜잭션에서 lent_id=3인 row에 X Lock을 건다.

7. B 트랜잭션에서 user_id=2인 유저가 빌린 lent와 cabinet 정보를 조회하기 위해 🔐 B 트랜잭션에서 lent_id=2인 row에 lock을 건다. ⛔️ C 트랜잭션에서 cabinet_id=1인 row에 X Lock을 걸었으므로 unlock할 때까지 기다린다.

8. C 트랜잭션에서 cabinet_id=1인 사물함을 대여중인 lent의 개수를 조회한다.
⛔️ B 트랜잭션에서 lent_id=2인 row에 X Lock을 걸었으므로 unlock할 때까지 기다린다.

💡 근본적인 문제 해결을 위한 해결책들

대안 1. 쿼리문 단축 → 변경할 테이블에 대해 삽입 전 조회하지 않기

• 해당 방법은 현실성이 부족합니다. 왜냐하면 현재 상태를 알아야 다음 상태를 정의할 수 있기 때문입니다.

대안 2. FOR UPDATE 키워드 활용

• 기존 대여 프로세스의 변경을 하지 않고, 적용할 수 있다는 장점이 있습니다.

• 하지만 현재 문제는 여러 테이블의 join으로 예상하지 못한 테이블에 lock이 걸려서 발생하였기 때문에, 해당 키워드가 반드시 해결을 보장해주지 않습니다.

대안 3. 트랜잭션 로직 더 간소화

• 현재는 트랜잭션 내에서 user_id를 통해 Lent 테이블에서 Cabinet 테이블을 찾아갑니다.

• 트랜잭션 외부에서 user_id를 통해 캐비넷 ID를 가져오고, 트랜잭션 내부에서 Lent 테이블과 Cabinet 테이블을 찾아갑니다.

대안 4. 불필요한 join 최소화

• 현재 문제는 예상하지 못한 row에 lock이 걸린 것이 근본적인 원인입니다. 따라서 불필요한 join을 최소화합니다.

💡 최종 해결 방법 (데드락 회피)

1. 트랜잭션 단위를 최소화 대여중인지 아닌지는 lent 테이블에서 대여중인 cabinet_id를 통해 판단하고, 판단하는 로직은 트랜잭션 밖에서 처리합니다.

2. 불필요한 테이블 조인 최소화 캐비넷 정보를 가져올 때 불필요한 user 테이블에도 조인을 하지 않도록 수정하여, 예상치 못한 Lock을 방지합니다.

3. 트랜잭션 내에서 테이블 조회 최소화 트랜잭션 내에서 딱 한 번만 조회가 발생하고, 조회를 할 때 반납에 필요한 모든 자원에 X Lock을 걸도록 합니다.

1. 동시에 여러 사용자가 대여나 반납을 수행한다고 하더라도 동작이 서로간 중첩되어선 안된다. 먼저 들어온 요청을 모두 처리하고 난 후 다음 요청을 처리해야 한다. 2. 하나의 요청을 처리하다가 문제가 발생(대여에는 성공했는데 캐비넷의 상태 변경에 실패 등)했을 때 데이터의 무결성을 지키기 위해 해당 트랜잭션 자체를 롤백시켜야 한다.

참조 문서

• http://wiki.gurubee.net/pages/viewpage.action?pageId=28606538

• https://suhwan.dev/2019/06/09/transaction-isolation-level-and-lock/