[Floney] 자산 데이터 동시성 이슈 해결 삽질기

🍀 https://github.com/Floney-2023

 

우리 가계부에서 자산은 가계부 내역 중 지출(-)과 수입(+)의 합을 의미한다.

이 자산이라는 개념은 설계 과정부터 어려움이 있었는데, 하나의 지출 혹은 수입이 생기면 그에 따라 해당 내역 날짜 이후로 매 달의 지출 데이터가 갱신되어야 하기 때문이다. 

 

다른 가계부 서비스를 참고해 자산이 갱신되는 특정 기간(5년)을 정해서 가계부 내역 변경 시 매 번 60개(5년 * 12달)의 자산 데이터가 갱신되도록 정하면서 이 문제는 마무리되었다.

 

문제 발생 - 의도되지 않은 자산 데이터 추가 생성

앱이 출시된 후, 가계부 내역을 수정하는 과정 중 자산 삭제 메서드에서 에러가 발생했다.

 

NonUniqueResultException으로 하나의 자산 데이터만 조회하기를 기대했으나 여러 개가 조회되며 에러가 발생한 것이다. 운영 디비에서 실제로 중복 데이터가 있는 것을 확인했고, 자산 관련 코드에서 다양한 정합성 문제가 발생할 수 있음을 알게 되었다.

 

기존 상황

 

자산 데이터

2000년 1월 X일의 한 가계부 수입 내역 금액을 1000원에서 500원으로 수정한다고 가정해보자. 이 때 2000년 1월부터 2004년 12월까지 총 60달 동안 포함되어 있던 자산 1000원을 500원으로 수정해야 한다.

 

기존 코드에서는 '가계부 내역 수정'이라는 하나의 트랜잭션에서 자산을 포함한 관련된 모든 데이터의 수정이 이루어지고 있었다. 그리고 자산 수정은 '기존 금액 삭제 → 변경 금액 추가' 순서로 이루어졌다.

 

기존 금액 삭제 후

변경된 금액 추가 후

 

굳이 한 번에 수정하지 않고 삭제와 추가라는 과정을 거치는 이유는, 가계부 내역 수정 시 해당 내역의 날짜도 수정할 수 있기 때문이다. (내가 작성한 코드는 아니지만 그럴 것이다...) JPA의 변경 감지를 이용했기 때문에 쿼리가 2배로 나가지 않으므로 성능 면에서도 괜찮았지만 Repeatable Read 격리 수준에서 갱신 손실이 발생할 수 밖에 없다.

 

하지만 이는 NonUniqueResultException이 발생한 실제 원인은 아니다. 가계부 내역을 수정한다는 것은 이미 해당 내역이 저장되었음을 의미하므로 자산 데이터가 생성될 일이 없다.

// 가계부 내역의 money를 자산에 추가
public void createAsset() {

    for (int i = 0; i < FIVE_YEARS; i++) {
        Optional<Asset> asset = assetRepository.find(날짜, 가계부);

        if (asset.isEmpty()) {
            Asset newAsset = new Asset();
            assetRepository.save(newAsset);
        } else {
            asset.get().update();
        }
    }
}

실제 원인은 '가계부 내역 추가'에 있다. 이 때만 자산 데이터가 새로 만들어지고 데이터베이스에 insert 되는 상황이 발생할 수 있다.

 

예시

위 예시와 같은 상황에서 중복 생성이 발생한다.

 

첫번째 수정 - 비관적 락 사용

운영 서버에서 발생하는 hotfix 이슈라, 최대한 코드를 적게 바꾸는 방식으로 오류를 고치고 싶었다.

바로 생각나는 건 역시나 한 번 써본 비관적 락이었다. 

// 가계부 내역의 money를 자산에 추가
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void createAsset() {

    for (int i = 0; i < FIVE_YEARS; i++) {
        Optional<Asset> asset = assetRepository.findExclusively(); // 비관적 락

        if (asset.isEmpty()) {
            Asset newAsset = new Asset();
            assetRepository.save(newAsset);
        } else {
            asset.get().update();
        }
    }
}

// 가계부 내역의 money를 자산에서 차감
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void deleteAsset() {

    BookLine bookLine = bookLineRepository.findExclusively(); // 비관적 락

    for (int i = 0; i < FIVE_YEARS; i++) {
        assetRepository.find().ifPresent(asset -> {
            asset.delete();
        });
    }
}

 

위와 같이 자산 데이터를 조회할 때 비관적 락을 걸었고, 자산 메서드를 호출할 때 새 물리적 트랜잭션을 생성하도록 해 해당 범위에서만 락이 유지되도록 설정했다.

 

눈치챘겠지만 완전히 잘못된 코드이다. 

• 트랜잭션이 분리되어 자산 메서드에 Exception이 발생해도 가계부 내역 메서드가 정상적으로 실행된다.
• 자산 데이터가 생성될 때 정합성이 유지되어야 하는데, 락으로는 insert 중복을 막을 수 없다.
• 가계부 id와 날짜로 자산 데이터를 조회하는데 가계부 id에만 인덱스가 걸려 있어 해당 가계부 id를 가진 모든 자산 데이터에 락이 전파된다.

게다가 nGrinder로 성능 테스트를 해보았더니 Vuser가 10명 정도로 매우 적을 때도 DB 커넥션이 모자라다는 에러가 발생했다. DB 커넥션 풀은 기본 설정을 사용하고 있는데 10개의 커넥션과 30초의 커넥션 timeout 시간이 있음에도 발생한 것이다. 

 

 

두번째 수정 - MySQL 쿼리 이용

첫번째 수정에서 얻은 결론은 아래와 같았다.

1. 하나의 트랜잭션 내에서 insert 중복을 해결한다.
2. 락의 범위를 자산 데이터 한 개로 줄인다.

자산 데이터를 조회하는 반복문 내에서 분산 락을 사용해야 하나 고민이 될 때, MySQL의 upsert 문법을 알게 되었다. 

 

public void createAsset() {

    for (int month = 0; month < SAVED_MONTHS; month++) {
        final LocalDate currentMonth = startMonth.plusMonths(month);
        assetRepository.upsert();
    }
}

 

unique 제약이 걸린 컬럼들을 기준으로, 해당 데이터가 있으면 update 없으면 insert를 하는 문법이다. 이를 사용해 자산 추가 메서드에서 데이터 당 한 개로 쿼리를 줄이고, 락도 사용하지 않을 수 있었다.

 

upsert 쿼리에 장점만 있는 것은 아니다. 우선 MySQL에서만 지원하는 문법이기 때문에 특정 RDBMS에 대한 의존성이 생긴다. 그리고 JPA EntityListeners 도 사용하지 못해 리스너에서 변경되는 부분을 직접 쿼리에 추가해야 한다. 

하지만 분산 락을 사용하는 대안보다는 공수가 훨씬 적게 들어 선택하게 되었다.

 

@Modifying
@Query(
        value = "insert into ASSET (date, money, book_id) values (:date, :money, :book) " +
                "on duplicate key update money = money + :money, updated_at = now()",
        nativeQuery = true
)
void upsertMoneyByDateAndBook(LocalDate date, Book book, double money);

 

자산을 제외하는 메서드에서도 JPA 변경감지 대신 update 쿼리를 사용해 락 사용 없이 정합성을 유지할 수 있다. 

 

 

새로운 문제 발생 - SQL 문법 에러

두번째 수정을 끝내고 간단한 성능 테스트까지 진행해 동시성 문제가 해결되었음을 확인했다.

그런데 해당 코드를 머지하니 또 에러가 발생했다. 😬☠️

게다가 터진 Exception은 SQLGrammarException으로 문법이 틀렸다고 해서 더욱 당황스러웠다. 

 

수정 - 테이블명 대/소문자 구분

어떤 문제인지 생각하다가, 로그에서 쿼리가 테이블명만 대문자로 찍혔던 게 떠올랐다. (이게 기억에 남아있던 걸 보면 무의식적으로 거슬렸나보다...)

@Modifying
@Query(
        value = "insert into ASSET (date, money, book_id) values (:date, :money, :book) " +
                "on duplicate key update money = money + :money, updated_at = now()",
        nativeQuery = true
)
void upsertMoneyByDateAndBook(LocalDate date, Book book, double money);

upsert 쿼리에서 단순히 가독성을 위해 테이블명만 대문자로 작성했던 것이다. 

 

MySQL 공식 문서에서 case sensitivity로 검색했더니 아래와 같은 내용을 찾을 수 있었다.

 

https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html

How table and database names are stored on disk and used in MySQL is affected by the lower_case_table_names system variable. This variable does not affect case sensitivity of trigger identifiers. On Unix, the default value of lower_case_table_names is 0. On Windows, the default value is 1. On macOS, the default value is 2.

테이블과 데이터베이스 이름이 디스크에 저장되고 사용되는 방식은 lower_case_table_names 시스템 변수에 의해 좌우된다. 이 변수는 트리거 식별자의 대소문자 구분에 영향을 주지 않는다. Unix에서 기본 값은 0이고, Windows에서는 1이며 macOS에서는 2이다.

로컬 운영체제는 macOS 이기 때문에 MySQL 서버에서 소문자로 사용해 오류가 발생하지 않았다. 

하지만 운영 데이터베이스 서버는 RDS에 있고, RDS는 Linux로 unix 계열이다. 따라서 디스크의 저장된 소문자 테이블명과 쿼리의 대문자 테이블명이 다르다고 판단해 오류가 발생했다.

 

MySQL 서버가 사용 중일 때는 해당 변수 값을 변경할 수 없으므로 코드의 대문자를 수정했다.

@Modifying
@Query(
        value = "insert into asset (date, money, book_id) values (:date, :money, :book) " +
                "on duplicate key update money = money + :money, updated_at = now()",
        nativeQuery = true
)
void upsertMoneyByDateAndBook(LocalDate date, Book book, double money);

 

근본적 원인 해결

문제를 해결하고 팀원분께 그 과정을 설명하던 중, 다음과 같은 질문을 받았다.

 

"그런데 API 실행 시간이 길어야 1초인데, 어떻게 운영 환경에서 동시성 문제가 발생했을까요?"

 

질문을 받은 당시에는 출시 직후라 이용하는 사람이 많아서 우연히 겹친 것 같다는 식으로 대답했다. 에러는 발생했고, 그에 대한 원인은 명확하니까.

 

그러다 문득 출시 전 했던 QA가 떠올랐다. 한 팀원이 앱에서 '가계부 생성하기' 버튼을 연타해서 API 요청이 여러 번 전송되었고, 결과적으로 똑같은 가계부가 여러 개 생성되어서 앱 개발자분이 연타를 막아주셨다.

 

가계부 내역 추가 API를 통해 자산 데이터가 중복 생성된 이유도 여러 명이 동시에 요청해서가 아니라 '한 명이 여러 번 요청해서'가 아닐까 싶다. 

 

해당 현상을 앱에서 막은 이후부터, 수정한 코드가 머지될 때까지 중복 데이터가 발생하지 않았던 것을 생각하면 이쪽이 신빙성이 높다.

 

흔한 동시성 이슈였지만 다양한 내용을 배우고 생각해봐서 의미있던 삽질기였다. ⛏️