본문 바로가기

Diary/TIL

2024-04-22) 동시성 이슈 공부

대부분의 서비스들의 경우 동시성 문제가 발생하지 않지만, 한정된 자원에 신청하는 티케팅, 좌석 예약 등의 서비스의 경우 필연적으로 다수의 사람이 하나의 자원을 얻으려고 하게 된다. 그렇기 때문에 db에 같은 부분에 값을 변경하려는 요청이 들어오려고 하게 되고, 이는 곧 데드락과 같은 교착상태를 생성하여 프로그램의 성능을 저하시킨다. 그렇기에 이 부분에 대하여 우선 순위를 정하게 하여 사람들이 접근할 수 있도록 해야되는데, 그 기법을 spring에서는 보통 락 이라고 한다.

 

전공때 배웠던 지식으로는 이를 해결하기 위한 방법으로 뮤텍스, 세마포어를 제시했었는데, 뮤텍스는 단일 자원에 대하여 접근을 제한하는 것이라면 세마포어는 자원에 여러명이 접근 가능하되, 접근 가능한 수를 제한하는 기법이었다.

 

spring에서는 찾아보고 배운 바로는 크게 4가지의 해결 방법이 있다고 하는데 db에 락을 걸어주는 비관적 락, 낙관적 락, 분산락이 있으며, db에 락을 걸어주는 대신 메시지큐에 순서대로 값을 넣어주고 순서대로 값을 빼주는 방식으로 db에 최대한 부하를 덜 주려고 한다. 아래는 더 자세하게 찾아보면서 각각 어떤 장단점이 있는지를 찾아보았다.

 

  1. 비관적 락 (Pessimistic Lock)
    비관적 락은 자원에 접근할 때마다 락을 걸어 다른 트랜잭션이 접근하지 못하게 한다. 이는 충돌을 피할 수 있지만, 규모가 커질수록 데이터베이스에 걸리는 부하가 증가하여 성능 저하를 초래할 수 있다. 대용량 트래픽에서는 피하는 것이 좋다.
  2. 낙관적 락 (Optimistic Lock)
    낙관적 락은 트랜잭션이 종료될 때 충돌을 체크하여 재시도하게 한다. 이는 성능 면에서 유리하지만, 충돌이 빈번하면 재시도로 인해 부하가 증가할 수 있다. 대규모 트래픽에서는 충돌이 적은 상황에서 유리하다.
  3. 분산 락 (Distributed Lock)
    분산 락은 Redis와 같은 분산 캐시 시스템을 이용하여 여러 애플리케이션 인스턴스 간에 자원 접근을 조율한다. 이는 분산 환경에서 동시성 문제를 해결하는 데 유용하며, 고가용성과 확장성을 제공한다.
  4. 메시지 큐 (Message Queue)
    메시지 큐는 대용량 트래픽을 처리하는 데 매우 효과적이다. 메시지 큐를 사용하면 작업을 큐에 쌓아 비동기적으로 처리할 수 있어 시스템의 부하를 분산시키고 성능을 향상시킬 수 있다. 대표적인 메시지 큐 시스템으로는 RabbitMQ, Apache Kafka 등이 있다.

'Diary > TIL' 카테고리의 다른 글

2024-05-08) MySQL DB Indexing 고찰  (0) 2024.05.24
2024-04-29) DB Connection pool 검색  (0) 2024.05.22
2024-04-19) 멀티스레드 공부  (0) 2024.05.22
2024-04-18) 로드밸런싱 공부  (0) 2024.05.22
2024-04-17) Redis 캐시 적용  (0) 2024.05.22