잘못되는 것은 꼭 잘못되기 마련이다.

개발자 머피의 법칙

U사에서 출판한 책에서 다음과 같은 문구를 읽었습니다.

저는 이커머스 회사에 계약직으로 재직중입니다. 저희 앱의 비즈니스 특성 상 재고의 개수가 엄밀하게 관리될 필요는 없습니다. 예상했던 개수 기준으로 혹여나 몇 개가 더 팔리더라도 해당 개수만큼 고객에게 제공해줄 수 있는 사업 모델을 가지고 있었습니다.

따라서 재고 개수를 느슨하게 관리하고 있었습니다. 작성해 놓은 재고의 개수를 넘겨도 무작정 구매를 할 수 있게 만들지는 않았지만, '찰나의 순간' 동일한 옵션의 상품을 구매할 때에는 마르지 않는 샘물처럼 제한된 재고 개수를 넘어서도 결제가 가능한 구조였습니다.

이 문제는 그저 미래에 해결할 일로 남겨놓았었습니다. 결제 트래픽이 동시성 문제를 고려할 정도로 크지 않았기 때문입니다. 그런데..

잘못됐다!!

새로운 이벤트가 발생하여 예상보다 많은 트래픽이 발생하였습니다. 결국 결제 이벤트 핸들러가 0.001초 간격으로 메시지를 수신하였고, 해당 메시지에는 동일 옵션의 상품이 있었습니다. 아니나 다를까 두 쓰레드는 같은 수의 재고를 읽어들였고, 두 번째 업데이트만이 DB에 반영되었습니다. 약 6개 가량의 재고가 초과로 주문되었습니다.

그나마 다행인점은 결제가 발생하고 2시간 정도만에 문제를 파악했다는 것입니다. 예상치 못한 트래픽에 혹시나 하여 주문들을 조사하는 과정에서 발견되었습니다. 빠르게 사실을 알리고 문제와 연관된 고객님들에게 대응하는 시간을 가졌습니다. 마무리된 시간은 오전 1시였습니다.

앞으로 이런 문제가 재발하지 않게 대응해놓을 필요가 있었습니다.

Firestore 경합 관리

Firestore은 클라이언트 측 라이브러리와 서버 측 라이브러리가 분리되어 있습니다. 클라이언트 측 라이브러리로 DB 작업을 할 때에는 Rule에 규제를 받아 권한이 있는 문서들에 대해서만 읽고 쓸 수 있습니다. 반면 서버 측 라이브러리는 어드민 라이브러리로 취급되어 규칙에 상관하지 않고 작업을 수행할 수 있습니다.

트랜잭션은 클라이언트 라이브러리와 서버 라이브러리가 서로 다른 매커니즘을 가지고 동작합니다.

클라이언트 라이브러리의 트랜잭션은 낙관적 락Optimistic Lock 방식으로 동작합니다. 트랜잭션이 시작된 이후 조회한 문서가 커밋된 시점에 최신 버전이 아니라면, 트랜잭션을 재실행합니다. 일정 횟수 이상 실패하는 경우 재실행을 멈추고 에러를 반환합니다.

클라이언트 라이브러리는 경합 문제 발생 시 코드 블록을 재시도한다는 점을 유의해야 합니다. 트랜잭션과 관련된 코드들은 항상 다시 실행될 수 있음을 인지하고, 반복 실행에 따른 부작용이 없도록 작성되어야 합니다. 잘못 작성된 코드는 외부 변수를 여러 번 바꾸어 예상치 못하게 동작할 수도 있습니다.

서버 라이브러리의 트랜잭션은 비관적 락Pessimistic Lock 방식으로 동작합니다. 트랜잭션 내에서 조회한 문서들은 잠금이 걸리며, 다른 트랜잭션에서 해당 문서를 읽기 위해서는 대기해야 합니다.

서버 라이브러리에서는 한 트랜잭션의 실행이 다른 트랜잭션을 대기하게 만든다는 점을 유의해야 합니다. 트랜잭션 내에서 동기적으로 외부 API를 호출하거나, 처리 시간이 긴 경우 처리율이 낮아질 수 있습니다.

또한 Firestore은 문서를 단위로 잠금을 수행하며, 이는 데드락을 발생시킬 수도 있다는 것을 인지해야합니다. 아래와 같이 서로 잠금을 획득하고자 하는 문서가 순환 구조를 이루는 경우 시스템은 데드락 타임아웃 기간 동안 동작하지 못합니다. 아래와 같은 상황을 대비하기 위해서 여러 문서를 조회할 때에는 항상 같은 정렬 순서로 동작하게 만들 필요가 있습니다.

1. 쓰레드 A에서 문서 a 조회 (잠금 획득)
2. 쓰레드 B에서 문서 b 조회 (잠금 획득)
3. 쓰레드 A에서 문서 b 조회 (대기)
4. 쓰레드 B에서 문서 a 조회 (대기)

저는 서버 애플리케이션을 담당하고 있으므로, 서버 라이브러리의 특징에 유의하여 코드를 보완했습니다.

이벤트 핸들러의 동작은 쿼리, 외부 API 호출, 계산 등을 포함하는 약 8가지 스텝으로 나누어져 있습니다. 이 중 재고 감소 로직을 트랜잭션 내에서 수행하기 위해 각 스텝의 위치를 조정할 필요가 있었습니다.

기존에는 재고 조회 쿼리와 재고 감소 쿼리 사이에 주문 관련한 쿼리가 존재했습니다. 이 스텝을 뒤로 옮김으로써, 재고 조회와 재고 감소 쿼리 사이에는 단순한 CPU 처리만 남게 되었고 해당 구간에 트랜잭션을 수행하기에 적합한 상태가 되었습니다.  

데드락에 대한 고민은 할 필요가 없었는데, 이는 Firestore이 where 절로 가져오는 문서들에 대해서 ID 순서로 잠금을 걸기 때문입니다.

이러한 방법으로 재고 개수의 무결성을 유지할 수 있었습니다.

새로운 마음가짐으로

애플리케이션의 신뢰성은 고객들에게 매우 중요한 요소입니다. 이번 경험을 통해 제가 담당하는 비즈니스, 로직, 코드에 대한 책임감을 느끼게 되었습니다. 

앞으로는 단순히 동작하는 코드를 넘어 예상 가능한 모든 상황에 선제적으로 대응하는 개발자가 되었으면 좋겠습니다.