🚩최종 프로젝트 - 동시성 제어

동시성 제어

기존 코드의 문제점

@Transactional
public LikeResponseDto createScheduleLike(Long scheduleId, User user) {
    Schedule foundSchedule = scheduleService.findById(scheduleId);

    if (likeRepository.existsByUserAndSchedule(user, foundSchedule)) {
        throw new CustomException(ErrorCode.ALREADY_LIKED);
    }

    Like like = new Like(user, foundSchedule);
    likeRepository.save(like);
    foundSchedule.addLikeCount();

    return new LikeResponseDto(like, true);
}

• 여러 사용자가 동시에 createScheduleLike 메서드를 호출하면 같은 scheduleId에 대해 동시에 여러 인스턴스가 foundSchedule을 가져와서 같은 스케줄을 업데이트하려고 시도할 수 있음. DB에 대한 경쟁 상태가 발생할 가능성이 있음

• 사용자가 좋아요를 눌렀을 때 코드가 먼저 likeRepository.existsByUserAndSchedule(user, foundSchedule)를 호출하여 사용자가 이미 좋아요를 눌렀는지 확인함.

• 여러 사용자가 동시에 좋아요를 눌러 검사를 수행하면 완료된 후 각 사용자가 existsByUserAndSchedule 의 결과가 false라고 잘못 판단할 수 있음. 이로 인해 중복된 좋아요가 발생할 수 있음.
• 트랜잭션이 ACID원칙에 따르기 때문에 동시에 여러 트랜잭션이 실행되더라도 각 트랜잭션은 격리되어 처리됨. 하지만 여전히 애플리케이션 레벨에서의 경쟁 상태와 락 부족으로 인해 원하는 결과를 보장하기 어려울 수 있음.
• foundSchedule.addLikeCount() 호출 후, 실제 좋아요 수가 일관되지 않거나 중복된 좋아요가 DB에 저장될 수 있음.

• 실제로 원래 코드로 테스트 해 본 결과 : 좋아요 수가 정확히 반영되지 않음.
• 분산 락을 사용하지 않으면 동시에 여러 사용자가 같은 자원에 대해 좋아요를 누를 때 중복된 좋아요나 데이터 일관성 문제를 겪을 수 있음. 분산락을 적용하면 이러한 문제를 예방할 수 있음. 따라서 이 문제를 해결하기 위해 분산락을 사용하여 경쟁 상태를 방지하려고 함.

---

• Redisson의 분산 락은 Redis를 활용하여 락을 관리하는 방식임. Redisson 자체가 별도의 데이터 저장소를 사용하는 것이 아니라 Redis를 분산 락의 상태 저장소로 활용함.
• Redisson은 Redis의 키-값 저장소를 사용하여 락의 상태를 저장함. 락을 얻으려는 클라이언트는 Redis에 특정 키를 설정하여 락을 요청함

Redisson의 분산 락 저장소

• 키-값 저장 : Redisson의 분산 락은 Redis의 메모리 내에서 키-값 저장소를 사용하여 락 상태를 관리함. Redis의 키-값 저장소에 락 정보를 저장하고 이 정보는 Redis 메모리에서 실시간으로 관리됨.

• RDB(Redis Database) : Redis는 주기적으로 메모리의 데이터를 스냅샷으로 저장하여 dump.rdb 파일에 저장할 수 있음. 이 파일은 Redis의 메모리 상태를 디스크에 저장하여 재시작 후에도 데이터를 복구할 수 있게 함

Redisson의 역할은 무엇인가?

• Redisson을 통해 분산 락을 설정하면, 여러 프로세스나 서버가 동시에 같은 리소스에 접근할 때 오직 하나의 프로세스만이 리소스에 접근할 수 있도록 보장함.

• 사용자가 좋아요를 누를 때 Redisson의 분산 락을 통해 한 프로세스만이 좋아요를 처리할 수 있도록 함. 다른 프로세스는 락이 해제될 때까지 대기하게 됨.

• 좋아요 데이터는 Redis의 메모리 내 DB에 저장됨. Redis는 인메모리 DB로 데이터가 메모리에서 즉시 읽고 쓸 수 있어 높은 성능을 제공함.

  영속성 옵션:

  • RDB (Redis Database): 주기적으로 메모리의 데이터를 디스크에 스냅샷으로 저장하여, Redis가 재시작될 때 데이터 복구를 지원함. dump.rdb 파일에 저장됨.

  • AOF (Append-Only File): 모든 쓰기 명령을 로그로 기록하여, 데이터의 추가적인 영속성을 보장함. appendonly.aof 파일에 저장됨.

좋아요 처리과정 정리

• 사용자가 좋아요를 누르면 Redisson을 통해 분산 락을 획득하여 해당 일정에 대한 좋아요 처리를 진행함. 다른 사용자는 락이 해제될 때까지 대기하거나, 락을 획득한 프로세스가 좋아요 처리를 완료할 때까지 기다림.

• 좋아요가 처리되면 Redis의 메모리 내 DB에 저장됨. 이 데이터는 즉시 메모리에서 읽을 수 있음. Redis는 높은 성능을 위해 메모리 기반 저장소를 사용함.
• Redis는 설정에 따라 RDB 또는 AOF 방식을 통해 데이터를 디스크에 저장하여 서버 재시작시 데이터 복구를 지원함. 이를 통해 데이터의 손실을 방지할 수 있음.

Redis와 관계형 데이터베이스의 차이

• Redis:
  • 주로 캐싱, 세션 저장, 실시간 데이터 처리 등의 용도로 사용됨.
  • 데이터를 메모리에 저장하여 빠른 읽기/쓰기 성능을 제공함.
  • RDB와 AOF를 통해 데이터를 디스크에 저장하여 영속성을 보장하지만, 주로 메모리 기반으로 운영됨.
• 관계형 데이터베이스:
  • 데이터가 디스크 기반의 테이블에 저장되며, 데이터의 무결성과 복잡한 쿼리 처리를 지원함.
  • 데이터 영속성 보장이 기본적으로 제공되며, 디스크 기반으로 작동함.

---

적용시킨 부분

• Redis를 사용하여 여러 서버 인스턴스에서 동시에 같은 자원에 대한 접근을 제어함. redissonClient.getLock(lockKey)를 사용하여 분산 락을 획득하고 락을 이용해 작업이 동시에 수행되지 않도록 보장함.

• createScheduleLikeTransactional 메서드에서 좋아요을 추가하고 scheduleRepository.saveAndFlush(foundSchedule) 를 통해 DB에 변경 사항을 저장함.

동작 흐름

1. 분산 락 획득: createScheduleLikeWithLock 메서드에서 Redis를 통해 분산 락을 획득함. 이 과정에서 다른 서버 인스턴스가 동일한 자원에 접근하지 못하도록 함. 락을 획득하지 못하면 CustomException을 던짐.

2. 데이터베이스 작업: 락을 성공적으로 획득하면, createScheduleLikeTransactional 메서드를 호출하여 실제 데이터베이스 작업을 수행함. 이 작업에는 좋아요의 저장 및 일정의 좋아요 수 증가가 포함됨.

3. 락 해제: 데이터베이스 작업이 완료되면, 락을 해제함. 락 해제는 finally 블록에서 수행되며, 이로 인해 다른 요청이 락을 획득할 수 있게 됨.

• 결과적으로 Redis는 분산 락을 관리하여 동시성 문제를 방지하고 DB는 영속적인 데이터 저장을 담당함.

Redisson을 고른 이유?

Redis와의 통합

• Redis 클라이언트: Redisson은 Redis 클라이언트 라이브러리로, Redis와의 통합이 원활하며 Redis의 모든 기능을 활용할 수 있음. Redis가 이미 환경에 도입되어 있다면, Redisson을 추가하여 복잡한 동기화 문제를 해결할 수 있음.

  쉽게 설명 : 이미 EC2에 Redis가 배포되어 있는 상황(이메일 인증 등)에서 Redisson을 추가적으로 사용하여 분산 락 기능을 구현하는 게 가능함! 따라서 Redisson의 복잡한 동기화 문제를 해결할 수 잇음!

• 빠른 성능: Redisson은 Redis의 성능을 그대로 활용할 수 있으며, Redis의 속도와 확장성을 바탕으로 높은 성능을 제공함. Redis의 메모리 기반 데이터 저장소 덕분에 높은 속도를 유지함.

최종 결과 비교

• 분산 락 적용 전 (여러 번 실행 해 봄)

• 분산 락 적용 후 (여러 번 실행 해 봄)

• 코드 분석

  @Service
  @RequiredArgsConstructor
  @Slf4j
  public class LikeService {
      
      private final LikeRepository likeRepository;
      private final ScheduleService scheduleService;
      private final UserRepository userRepository;
      private final ScheduleRepository scheduleRepository;
      private final RedissonClient redissonClient;
      
      private static final String LOCK_KEY_PREFIX = "like_lock_";
      
  		// 분산 락 적용 전 원래 코드
      @Transactional
      public LikeResponseDto createScheduleLike(Long scheduleId, User user) {
          // 일정 ID로 스케줄을 찾아옴
          Schedule foundSchedule = scheduleService.findById(scheduleId);
      
          // 사용자와 일정에 대해 이미 좋아요를 눌렀는지 확인
          if (likeRepository.existsByUserAndSchedule(user, foundSchedule)) {
              // 이미 좋아요를 눌렀으면 예외를 던짐
              throw new CustomException(ErrorCode.ALREADY_LIKED);
          }
      
          // 좋아요를 생성하고 저장
          Like like = new Like(user, foundSchedule);
          likeRepository.save(like);
      
          // 스케줄의 좋아요 수를 증가시킴
          foundSchedule.addLikeCount();
      
          return new LikeResponseDto(like, true);
      }
      
      public LikeResponseDto createScheduleLikeWithLock(Long scheduleId, User user) {
          // 락 키를 생성 (일정 ID를 기반으로)
          String lockKey = LOCK_KEY_PREFIX + scheduleId;
          RLock lock = redissonClient.getLock(lockKey);
          // 구체 설명 : redissonClient.getLock(lockKey)를 사용하여 분산 락을 획득하고 락을 이용해 작업이 동시에 수행되지 않도록 보장함.
      
          try {
              // 락을 시도 (20초 대기 후 30초 동안 유지)
              boolean isLocked = lock.tryLock(20, 30, TimeUnit.SECONDS);
              if (!isLocked) {
                  // 락을 획득하지 못했으면 예외를 던짐
                  throw new CustomException(ErrorCode.LOCK_ACQUISITION_FAILED);
              }
      
              try {
                  // 락을 획득한 후 트랜잭션을 수행하여 좋아요 생성
                  return createScheduleLikeTransactional(scheduleId, user);
              } finally {
                  // 락을 해제
                  if (lock.isHeldByCurrentThread()) {
                      lock.unlock();
                  }
              }
          } catch (InterruptedException e) {
              // 락 획득 중 인터럽트가 발생하면 스레드 상태를 복원하고 예외를 던짐
              Thread.currentThread().interrupt();
              throw new RuntimeException("Lock acquisition interrupted", e);
          }
      }
      
  		// 원래 코드와 거의 동일
      @Transactional
      public LikeResponseDto createScheduleLikeTransactional(Long scheduleId, User user) {
          // 일정 ID로 스케줄을 찾아옴
          Schedule foundSchedule = scheduleService.findById(scheduleId);
      
          // 사용자와 일정에 대해 이미 좋아요를 눌렀는지 확인
          if (likeRepository.existsByUserAndSchedule(user, foundSchedule)) {
              // 이미 좋아요를 눌렀으면 예외를 던짐
              throw new CustomException(ErrorCode.ALREADY_LIKED);
          }
      
          // 좋아요를 생성하고 저장
          Like like = new Like(user, foundSchedule);
          likeRepository.save(like);
      
          // 스케줄의 좋아요 수를 증가시킴
          foundSchedule.addLikeCount();
      
          // 변경 사항을 즉시 데이터베이스에 반영
          scheduleRepository.saveAndFlush(foundSchedule);
      
          return new LikeResponseDto(like, true);
      }
      
      		
  		// 아직 적용 안 함
      @Transactional
      public LikeResponseDto deleteScheduleLike(Long likeId, User user) {
          // 락 키를 생성 (좋아요 ID를 기반으로)
          RLock lock = redissonClient.getLock(LOCK_KEY_PREFIX + likeId);
           
      
          try {
              // 락을 시도 (10초 대기 후 60초 동안 유지)
              boolean isLocked = lock.tryLock(10, 60, TimeUnit.SECONDS);
              if (!isLocked) {
                  // 락을 획득하지 못했으면 예외를 던짐
                  throw new CustomException(ErrorCode.LOCK_ACQUISITION_FAILED);
              }
      
              try {
                  // 좋아요 ID로 좋아요를 찾아옴
                  Like foundLike = likeRepository.findLikeWithSchedule(likeId);
      
                  if (foundLike == null) {
                      // 좋아요가 존재하지 않으면 예외를 던짐
                      throw new CustomException(ErrorCode.LIKE_NOT_EXIST);
                  }
      
                  // 좋아요에 연결된 스케줄을 찾아옴
                  Schedule foundSchedule = foundLike.getSchedule();
      
                  // 사용자가 좋아요를 눌렀는지 확인
                  if (!user.getId().equals(foundLike.getUser().getId())) {
                      // 사용자가 다른 사람의 좋아요를 취소하려고 하면 예외를 던짐
                      throw new CustomException(ErrorCode.CANNOT_CANCEL_OTHERS_LIKE);
                  }
      
                  // 좋아요를 삭제하고 스케줄의 좋아요 수를 감소시킴
                  likeRepository.delete(foundLike);
                  foundSchedule.minusLikeCount();
      
                  return new LikeResponseDto(null, false);
              } finally {
                  // 락을 해제
                  lock.unlock();
              }
          } catch (InterruptedException e) {
              // 락 획득 중 인터럽트가 발생하면 스레드 상태를 복원하고 예외를 던짐
              Thread.currentThread().interrupt();
              throw new RuntimeException("Lock acquisition interrupted", e);
          }
      }
      
      public LikeResponseDto getLike(Long scheduleId, User user) {
          // 일정 ID로 스케줄을 찾아옴
          Schedule schedule = scheduleRepository.findById(scheduleId)
                  .orElseThrow(() -> new CustomException(ErrorCode.PLACE_NOT_FOUND));
      
          // 스케줄과 사용자에 대해 좋아요를 찾아옴
          Like like = likeRepository.findByScheduleAndUser(schedule, user)
                  .orElseThrow(() -> new CustomException(ErrorCode.ALREADY_INVITED));
      
          return new LikeResponseDto(like, false);
      }
      
  }
      
      
  

  • 결론적으로 분산 락은 여러 서버가 공유 데이터를 제어하기 위한 기술로 락을 획득한 프로세스 혹은 스레드만이 공유 자원에 접근할 수 있도록 하는 것. 서버 분산 환경에서도 프로세스들의 원자적 연산이 가능하다는 장점이 있음. 여기서 공유자원 자체에 락을 거는 것이 아니라 어떤 행위가 발생하는 임계 구역에 락을 거는 방식!

  • Lock을 당장 획득할 수 없으면 대기

  • Lock이 획득 가능할 경우 Redis에서 클라이언트로 획득 가능함을 알림!