멋사 Backend Plus 34일차 🦁

오늘도 오전 오후시간 동안 프로젝트를 진행하였고, 상품 재고에 대한 비관적 락을 적용하였다.

오전

Index 란

Index 란 별도의 추가적인 작업을 통해서 테이블의 조회 속도를 향상 시켜주는 역할을 합니다. 책이나 잡지를 볼때 책갈피 역할을 Index 가 하는 것 입니다.

Index 사용시 주의점

조회 성능의 향상을 기대하고, 무조건 Index 를 사용하는 방법은 옳지 않은 방법 이라고 합니다.

조회 과정을 수행하지 않는 : Insert 쿼리

조회 과정을 수행하지 않는 Insert의 경우에는 추가적인 연산이 필요 하므로 성능 저하를 일으킬수 있습니다.

조회 과정을 수행하는 : Select, Delete, Update

Select, Delete, Update는 조회로 시작하며, 조회에 대한 성능은 향상 됩니다.

Index를 사용하면 좋은 경우

• 외래 키 관계에서는 자주 사용되는 컬럼에 인덱스를 생성하여 JOIN 연산의 성능을 향상시킬 수 있습니다.

• ORDER BY나 GROUP BY 절에서 사용되는 컬럼에 인덱스를 추가하면 정렬 및 그룹화 작업이 빨라질 수 있습니다.

Spring Entity에서의 적용

@Entity
@Getter
@Table(name = "product_cart", indexes = {
        @Index(name = "idx_member_id", columnList = "member_id")
})
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Cart {

	@Id
    @GeneratedValue(strategy = IDENTITY)
    private Long id;

    @OneToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id")
    private Member member;

    @Column(name = "item_count_in_cart")
    private Integer totalCount;
}

Member 엔티티 클래스에 대한 외래키를 가지고 있으며 간단한 Cart(카트) 엔티티 클래스 입니다.

@Table(indexes = { @Index(name = "인덱스 이름", columnList = "데이터 베이스의 삽입될 이름, 여기서는 컬럼 이름")})
➡ Index는 여러개 생성이 가능하며, 여러개의 컬럼을 사용해서 만들 수 있습니다.

오후

• 이전 블로그를 참고하게 되면, 상품의 재고를 동시에 담았을때 동시성 문제를 확인 하였습니다.

이런 동시성 문제에 대해 해결 할수 있는방법이 여러가지 이지만, 여러 블로그를 찾아보며 저는 락 (Lock)을 적용 해야겠다고 생각 하게 되었습니다.

이 글에서는 락의 개념, 비관적 락을 선택한 이유, 락 사용 방법에 대해서 정리 해보겠습니다.

락 (Lock) 의 개념

락은 대표적인 동시성 제어 기법 중 하나로, 트랜잭션의 순차적 진행을 보장 할수 있는 직렬화 장치 입니다.

• 일반적으로 "동시에" 같은 데이터를 접근 하는 것을 방지
• 동시에 발생하는 즉 같은 시간의 동시 요청을 해결할 때 사용

락 사용 이유

간단한 예시로 상품의 재고를 예시로 들겠습니다.

➡ 예를 들어, A 사용자가 상품의 재고를 5개로 조회하고, B 사용자도 "동시에" 5개로 조회한 후에 두 사용자가 동시에 1씩 감소시키면,
실제로는 -1개의 재고가 될 수 있습니다.
즉 한개의 트랜잭션 요청만 반영이 된다는 것 입니다.

➡ 추가적인 예시로 A 사용자가 5개의 재고를 4개로 감소시키고, B 사용자가 동시에 5개에서 3개로 감소시키면, B 사용자의 업데이트가 반영되고
A 사용자의 업데이트는 손실될 수 있습니다.
즉 마지막에 업데이트한 값만 반영되고 나머지는 손실될 수 있습니다.

비슷한 상황으로 또 어떤게 있을까 ?

• 수강신청 시스템 (좌석 시스템) 에서 정원이 1명이 남았을때, 두명이 동시에 신청해서 정원이 1명뿐인 조건에 두명이 신청 하게 되었을 때

위와 같은 데이터의 일관성과 무결성을 지키기 위해 락을 사용하여 해당 문제의 동시성 제어 문제를 사전에 방지 할수 있습니다.

낙관적 락 비관적 락

낙관적 락

• 낙관적, 즉 트랜잭션의 충돌은 일어나지 않을 것을 가정 하는 방법 입니다.

• JPA 에서는 일반적으로 @Version 어노테이션을 사용하며, 반환 타입으로는 Long, Integer 등으로 사용합니다.
• 읽어올때 Version과 수정 후 트랜잭션이 커밋 (commit) 되는 시점에 Version이 다르면 충돌이 발생하게 됩니다.
• update 쿼리 발생시 verison 필드의 데이터 값이 1씩 증가 합니다.

➡ 수정할 데이터를 조회시, 자원을 선점하지 말고, 커밋을 할때 동시성 문제가 발생하면 그때 처리 하자는 방식

비관적 락

• 비관적, 즉 트랜잭션의 충돌은 일어난다고 가정하는 방법 입니다.

• 트랜잭션의 충돌이 무조건 있다고 가정하여, 데이터를 조회 할때 부터 락을 거는 방법 입니다.
• SQL 쿼리문이 select for update 로 발생하게 되며,
  데이터를 수정하기 위해 찾은 것 이다.
• 비관적 락을 사용하게 되면, 트랜잭션이 대기하는 동안 무한히 기다릴수 없으므로, 타임아웃 시간을 걸어 둘수 있습니다.

➡ 데이터 조회시부터 락을 걸어 동시성 문제가 발생하지 못하게 미리 처리 하자는 방식

---

상품 재고처리에 대해서 비관적 락을 선택한 이유

상품 재고에 대한 로직이 다양하겠지만, 상품의 재고가 0개 밑으로 떨어지게 된다면 심각한 문제이고 동시에 여러명의 사용자의 요청
즉 상품의 재고를 담았을때 낙관적인 락 인 경우 먼저 요청에 성공한 사람인 경우 이외의 나머지의 요청들은 충돌이 발생하는데, 그 모든 충돌을 예외처리와 롤백을 실행 해야 합니다.
그 비용이 훨씬 더 비쌀 것 같다는 생각을 하였고,
그에 반해 비관적 락 은 수정된 즉시에 재고가 0개로 보이게 됨으로 로직적으로 0개이면 구매를 할수 없게 막기만 한다면, 다른 추가적인 비용이 들 것 같지 않아 비관적 락 을 사용 하였습니다.

락 사용 방법

• 낙관적 락 사용 방법

엔티티 클래스 필드에 @Version 어노테이션을 사용하여 엔티티의 "버전"을 관리할수 있습니다.

주의 사항으로는 각 엔티티 클래스에는 하나의 버전 속성만 있어야 합니다.

그 다음으로 설정할 것은 @LockModeType 을 통한 락 옵션을 설정 해줄수 있습니다.
(@LockModeType.PESSIMISTIC_WRITE는 간단하게 락을 걸어 조회는 가능한데, 수정하거나 삭제하는 것을 방지)

다양한 락 옵션이 존재하는데 필요에 따라 정의를 찾아보며 적용 하면 좋을 것 같습니다.

• 비관적 락 사용 방법

비관적 락은 낙관적 락과 달리 @Version 어노테이션을 사용하지 않고
@Lock 과 @LockModeType 을 사용합니다.

비관적 락 테스트

아래는 상품을 저장하고 장바구니에 담는 행동인 removeStock 메소드에 동시 요청에 대한 비관적 락 테스트 입니다.

@SpringBootTest
public class ItemCartPessimisticLockTest {
    @Autowired
    private ProductRepository productRepository;
    @Autowired
    private ItemCartServiceImpl itemCartService;

    private Product product;

    @BeforeEach
    void init() {
        product = Product.builder().productName("강아지 사료")
                .price("25_000")
                .content("유통기한 1년 남은 사료입니다.")
                .count(1000) // 상품의 재고 1000개 저장
                .category(Category.PET_FEED)
                .status("Y")
                .build();
        productRepository.save(product);
    }

    @Test
    public void 동시에_1000개_요청() throws InterruptedException {
        int threadCount = 1000; // 1000번의 요청

		// 20개의 쓰레드풀 생성
        ExecutorService executorService = Executors.newFixedThreadPool(20);
        CountDownLatch latch = new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; i++) {
            executorService.submit(() -> {
                try {
                    itemCartService.removeStock(product.getId(), 1);
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    latch.countDown();
                }
            });
        }
        latch.await();

        Product updatedProduct = productRepository.findById(product.getId()).orElse(null);
        Assertions.assertThat(updatedProduct).isNotNull();
        Assertions.assertThat(updatedProduct.getCount()).isEqualTo(0);
    }
}

위의 테스트 코드를 실행 하게 되면은 동시성 요청에도 순차적으로 상품의 재고의 갯수가 줄어들어 0개 로 수렴하여 테스트를 통과 하였습니다.

---

select for update 쿼리가 1000개가 발생하게 되고, 이러한 쿼리는 @LockModeType.PESSIMISTIC_WRITE 을 옵션으로 설정함으로써 쓰기 잠금을 했다는 것을 알수 있습니다.

테스트가 23초 가량 걸린 것을 알 수있는데, 다른 팀원분의 맥으로 실행하였을때는 3초 밖에 걸리지 않았다.

🤔 노트북을 바꿀때가.....