pessimisticLock 이 발생하는 곳을 찾아 확인해보니 insert 쿼리에서 슬로우 쿼리가 발생했다.
이 부분의 insert 는 천 번부터 많게는 몇 만번까지도 발생할 수 있는 로직이다.
해당 문제는 insert 를 하다가 타임아웃이 발생했다.
로직에서는 row 단위로 데이터를 저장하고 있다.
row 단위로 저장하던 것을 json 데이터로 저장을 하면 문제가 발생하지 않을 것이다.
하지만, 이미 몇 십억건의 데이터가 쌓인 상황에서 그렇게 변경하기에는 불가능하다.
현재 상황에서 고려할 수 있는 상황은
1. JPA id 전략을 identity 에서 sequence 전략으로 변경하는 것
-
identity 는 키 생성을 DB에게 위임한다. (mysql 인 경우 auto_increment)
auto_increment 는 데이터가 insert 된 후 id 값을 알 수 있기 때문에 쓰기 지연을 사용할 수 없다. -
7천개 데이터 삽입 시 시간
| identity | sequence |
|---|---|
| 60초 | 2.5초 |
- 하지만, sequence 로 변경하는데 생성된 auto_increment 를 삭제 해야한다.
그리고 sequence 테이블 생성을 해야하고 sequence 전략을 사용하기 위해 아래 설정을 해야 쓰기 지연이 발생한다.
order_inserts: true
order_updates: true- 그리고 allocationSize 를 설정해줘야 한다. sequence 는 데이터 삽입 전 id 를 할당한 후 데이터를 넣고 id 값을 조회해온다. 그러면 DB 통신이 2번이 발생하기 때문에 성능이 좋지 않다. 그래서 allocationSize 를 설정해 미리 id 값을 할당하도록 설정하여 최적화한다.
- jdbctemplate 변경
- jdbctemplate 으로 변경하는 것이 구글링을 해보면 가장 좋은 성능이라고 나와있다.
그리고 identity 전략을 그대로 사용할 수 있다.
jdbcTempalte 의 bulk insert 는 batchUpdate 를 사용한다.
bulk insert 는 여러 개 Row 를 한번의 쿼리로 insert 하는 방식이다.
MySql 은 bulk insert 방식을 통해 batch insert가 가능하다.
AS-IS
INSERT INTO TABLE(~~) VALUES(~~)
INSERT INTO TABLE(~~) VALUES(~~)
TO-BE
INSERT INTO TABLE(~~) VALUES(~~), (~~), (~~)- 하지만 위에서 얘기했듯이 identity 전략은 데이터가 커밋된 이후에 id 값을 알 수 있기 때문에 데이터를 넣고 laster_insert_id 를 통해 첫번째 넣은 id 값을 알 수 있다.
그 id 값을 데이터를 넣은 수만큼 + 해줘서 최종 id값을 확인해 다음 insert 시 에 사용할 수 있다. (link)
우리 팀원 분들은 1번과 2번에서 의견들이 많았다.
1번을 주장하는 분은 간단하게 DB 설정을 변경해서 해결할 수 있는데, jdbcTemplate 으로 코드 레벨 수준까지 변경해 많은 사이드 이펙트가 생기진 않을지 염려를 했다. 그리고 jpa 를 쓰지 않고 native query 를 사용하는 것이 모니터링할 때도 더 힘들다는 의견이었다.
2번을 주장하는 분은 코드 레벨에서 해결이 가능한데 DB 설정까지 변경해야 하는지, 그렇게 변경을 해도 똑같이 사이드 이펙트가 생기는 건 마찬가지이고 해당 테이블을 sequence 로 변경했을 때 다른 곳에서 사용할 때도 이를 고려해야 한다는 의견이였다.
나도 2번이 더 좋은 것 같다.
- 격리 수준도 확인해봤지만 중요한 것은 아니였음.
개발은 read-committed 로 설정이 되어있었고, 운영은 repeatable-committed 로 되어있었다.
개발의 격리수준을 올려 운영과 맞춰주었지만 현 상황에서 별로 중요한 것은 아니었다.
결론은 jdbcTemplate 으로 bulk insert 를 사용해 문제를 해결했다.
pessimisticLock 은 더이상 발생하지 않았고 처리 속도도 100%로 향상되었다.
