[DB] 낙관적 락, 비관적 락, Redis 동시성 이슈 성능 테스트

2024. 12. 22. 16:19·Data Infra/etc

0. 들어가기 전

현재 진행 중인 프로젝트에는 SNS 기능이 있으며, 게시물에 조회 수와 좋아요 기능이 포함되어 있습니다. 조회 수는 데이터의 신뢰성이 크게 중요하지 않다고 생각되지만, 좋아요 수는 사용자 경험에 큰 영향을 미칠 수 있어 동시성 문제를 해결하며 성능을 최적화하려고 합니다. 이를 위해 낙관적 락, 비관적 락, 레디스가 떠오르는데, 개인적으로 낙관적 락 < 비관적 락 < 레디스 순으로 성능이 더 좋을 것 같다고 예상하지만 성능 테스트를 통해 직접 직접 확인해 보는 것이 좋을 것 같아 확인해보려 합니다.

 

Jmeter로 성능 테스트를 진행할 예정입니다.

 

👉 Redis 고려 이유

  1. In-Memory DB이다.
    Redis는 In-Memory DB이기 때문에 IO 작업이 훨씬 빠를 것이라 생각했습니다.
  2. Redis 6.0부터는 Network IO가 추가되었다.
    Redis 6.0에서는 IO만 담당하는 Thread가 3개 추가되었기 때문에 성능이 훨씬 빠를 것이라 생각했습니다.
  3. Single Thread이다.
    Redis는 Single Thread이고 수를 증가시키는 것은 원자적 연산으로 들어가기 때문에 데이터 신뢰성 보장을 해줄 것이라 생각했습니다.

 

👉 테스트 환경

  • 테스트해볼 게시물
    낙관적 락은 id가 1번, 비관적 락은 id가 2번, 그리고 Redis는 id가 3번으로 설정하여 테스트를 진행할 예정입니다.

  • HTTP Request
    500명의 사용자가 1초에 1개씩 요청을 보내고 100번 반복합니다. 총 50000번의 요청이 서버에 보내집니다.
    Same user on each iteration을 통해 각 사용자의 쿠키나 세션 등이 동일한 상태를 유지한 채로 반복 실행합니다.

 

 

1. 성능 테스트

 

a. Optimistic Lock

  • Database
    50000개 중 5826개만 정확히 들어간 것을 확인할 수 있습니다.
    낙관적 락에서 소요 시간을 고려하여 100번 이상 반복되는 테스트는 에러 처리를 했기 때문에 데이터가 많이 튕겨 나간 것을 확인할 수 있습니다.

 

  • Summary Repor
    테스트에 총 32초가 소요되었습니다. 단순히 생각해도 오래 걸린 것을 확인할 수 있습니다.
    Error는 88.35%가 나왔고 초당 Throughput은 1554.3이 나온 것을 확인할 수 있습니다.
    역시 데이터의 신뢰성을 보장할 수 없다는 것을 확인할 수 있었습니다.

 

  • TPS Graph
    HTTP Request 요청의 성공과 실패가 불안정한 것을 볼 수 있습니다.
    성공 요청은 그나마 일정한데 실패 요청이 불안정하게 많아졌다가 확 줄어드는 모습이 있습니다.

 

b. Pessimistic Lock

  • Database
    50000개 모두 정확히 들어간 것을 확인할 수 있습니다.
    비관적 락은 순차적으로 모든 데이터가 충돌을 일으키지 않기 때문에 데이터의 신뢰성이 보장되는 것을 확인할 수 있습니다.

 

    • Summary Report
      테스트에 총 20초가 소요되었습니다. 낙관적 락보다 12초 정도 빠른 것을 확인할 수 있습니다.
      낙관적 락보다는 충돌이 많이 예상될 때는 사용하는 방법이기 때문에 테스트 환경과 같이 충돌이 많이 발생하는 환경에서 더 효율적인 모습을 보여주는 것 같습니다.
      Error는 0%가 나왔고 초당 Throughput은 2465.7이 나온 것을 확인할 수 있습니다.
      데이터의 신뢰성을 보장하고 성능적인 우수함도 가져오고 있습니다.

 

  • TPS Graph
    HTTP Request 요청의 성공이 일정하게 유지되는 것을 확인할 수 있습니다.
    확실히 낙관적 락보다 충돌이 많은 상황에서 안정적인 것을 확인할 수 있습니다.
    요청이 2100 ~ 2600 사이로 폭이 조금 크지만 그래도 성공이 일정한 그래프를 그리며 유지되고 있습니다.

 

C. Redis

Single Thread에 In-Memory DB인 Redis를 사용하여 테스트해 보겠습니다.

  • Database
    50000개 모두 정확히 들어간 것을 확인할 수 있습니다.
    Redis 또한 Single Thread로 순차적으로 모든 데이터가 충돌을 일으키지 않기 때문에 데이터의 신뢰성이 보장되는 것을 확인할 수 있습니다.

 

  • Summary Report
    테스트에 총 9초가 소요되었습니다. 비관적 락보다 대략 2배정도 빠른 것을 확인할 수 있습니다.
    Redis는 Single Thread지만 In-Memory DB로 데이터베이스 통신 비용이 적게 들고 Redis 6부터는 네트워크 IO를 위한 Thread 3개가 생겼기 때문에 더 성능이 우월한 거 같습니다.
    Error는 0%가 나왔고 초당 Throughput은 5404.2가 나온 것을 확인할 수 있습니다.
    데이터의 신뢰성을 보장하고 성능적인 우수함도 가져가고 있습니다.

 

  • TPS Graph
    HTTP Request 요청의 성공이 일정하게 유지되는 것을 확인할 수 있습니다.

 

2. 정리

처음에 예상했던 대로 낙관적 락 < 비관적 락 < 레디스 순으로 성능이 좋은 것을 확인했습니다.

낙관적 락에서 레디스를 사용할 때는 성능이 247.8% 개선되었고

비관적 락에서 레디스를 사용할 때는 성능이 119.1% 개선되었습니다.

 

'Data Infra > etc' 카테고리의 다른 글

[Etc] Elasticsearch를 통해 검색 시간 단축하기 (1)  (0) 2025.01.13
'Data Infra/etc' 카테고리의 다른 글
  • [Etc] Elasticsearch를 통해 검색 시간 단축하기 (1)
chanyoungdev
chanyoungdev
chanyoungdev
  • chanyoungdev
    Young Code
    chanyoungdev
  • 전체
    오늘
    어제
    • 분류 전체보기 (28)
      • Programming (12)
        • Java (0)
        • Spring (10)
        • etc (2)
      • Data Infra (5)
        • Database (1)
        • Redis (2)
        • etc (2)
      • DevOps (4)
        • CI CD (1)
        • Nginx (2)
        • Docker (0)
        • Aws (0)
        • etc (1)
      • Algorithm (6)
      • etc (1)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

    • First Tech Blog
    • Github
  • 공지사항

  • 인기 글

  • 태그

    junit
    Infra
    elasticsearch
    JWT
    Algorithm
    공통 응답
    캐시
    domain
    Virtual Thread
    infra architecture
    lock
    단위 테스트
    cache
    ssl
    OAuth
    Redis
    spring security
    Spring Batch
    nginx
    Mockito
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.0
chanyoungdev
[DB] 낙관적 락, 비관적 락, Redis 동시성 이슈 성능 테스트
상단으로

티스토리툴바