항해플러스 6주차 회고 (WIL)

🚀 돌아온 6주차 회고!

이번 주차에서 가장 고민이 되었던 부분은 아무래도 '동시성을 어떻게 제어할 것인가?'였다.

동시성을 제어하는 방법에는 데이터베이스 락을 이용하는 방법과 외부 시스템을 이용하는 방법이 있다.

여러가지 방법 중에서 각각의 기능에 부합한 락을 선택하여 자료로 정리하는게 이번 주 목표였다.

문제

이번 주차를 지나며 겼었던 문제점

여기서 동시성을 제어해야 하는 유즈케이스는 무엇이 있을까?

1. 좌석 예약
2. 결제
3. 포인트 충전

각각의 유즈케이스에서 동시성을 제어하기 위해 어떻게 해결할 건지, 그리고 벤치마킹은 어떻게 진행할 건지? 이런 것들이 고민이었다.

각각의 유즈케이스마다 적절한 동시성 제어 방법을 찾는 것,
각 제어 방법에 따른 벤치마킹을 수행해야 한다.

시간은 한정적이고.. 어떻게 해야 좋은 방법일까?

시도

우선 유즈케이스마다 적합한 방법에 대해 가설을 세워 보았다.

유즈케이스 분석

1. 좌석 예약: 대기열 시스템을 통해 한 번 걸러서 들어오기 때문에.. 그리고 예약에 실패했을 때 그대로 실패로 이어진다.
2. 결제: 좌석 예약한 사용자가 5분 이내에 결제해야 한다.
3. 포인트 충전: 동시에 충전할 가능성이 있음. 충전에는 실패하는 경우는 없다.

그리고 가설에 적합한 해결 방법은 무엇일지 생각해보았다.

유즈케이스별로 동시성 문제 해결 방안

1. 좌석 예약: Optimistic Lock
2. 결제: Optimistic Lock
3. 포인트 충전: Distributed Lock

이제 구현하여 벤침마킹을 실시하면 된다. 그 전에 동시성 테스트 코드를 작성하여 내가 세운 가설이 맞는지 검증하는 과정을 거쳤다.

해결

각각의 유즈케이스마다 낙관락, 비관락, 분산락 등을 구현하여 벤치마킹을 하지는 못했다.
하지만, 테스트 코드를 통해 내가 세운 가설을 검증하였다. 그리고 해결 방안에 따른 낙관락과 분산락을 구현한 후 테스트 코드로 벤치마킹을 실시하였다.

가설을 세운다. 그리고.. -> 테스트 코드 작성 -> 검증 -> 해결 -> 벤치마킹

깨달음

이러한 방법을 통해 Optimistic Lock, Pessimistic Lock, Distributed Lock을 모두 경험해 볼 수 있었다.

이러한 경험을 통해 다음과 같은 사실을 깨달았다.

1. 낙관락은 동시성이 생긴다는 것을 낙관적으로 생각하여 문제가 발생했을 때 해결하는 방법이다.
2. 낙관락보다 비관락이 더 빠르다. 그 이유는 비관락은 DB에서 Lock을 취득하기 위해 계속 대기하고 있기 때문이다.
3. 비관락은 락을 취득하기 위해 계속 대기하고 있기 때문에 어떻게든 락을 취득한다. 즉, 락 취득에 실패가 API 요청에 실패로 이어지면 안되는 API에 적합하다.
4. 반대로, 비관락은 이러한 이유 때문에 데드락 이슈가 발생한다. (이러한 특징을 잘 생각해서 사용해야 한다.)
5. 분산락(Redis를 이용)은 말 그대로 분산환경을 위한 Lock을 사용하는 방법이다. 다른 락에 비해서 성능적으로 우수하지 못하다.