클라이언트 개발자분과
프로필 업데이트와 사진 업데이트, 프로필 등록과 사진 등록 API를 분리하지말고 하나로 합쳐야할지를 정하면서
Rollback의 범위가 길어지는 게 문제가 될지? 의문이 생겼다.
프로필과 사진 각각 비즈니스 로직이 복잡하다보니
유효성 검사에서 튕겨나가 롤백되는 경우가 꽤 많다.
만약, 두개를 합쳐버리면
프로필쪽 유효성 검사를 다 통과하고
프로필 사진을 등록하는 유효성 검사에서도 마지막 단계에서 튕겨나가 롤백이 될 수 있는 것이다.
그러면, 롤백되는 범위가 너무 길어지지 않을까? 하는 게 내 생각이었다.
내가 알기론 롤백도 결국엔 DB에 반영은 하돼, 롤백하는 순간 이걸 다 지워버리는 방식이다.
그만큼 DB 부하와 무관하지 않을 것이라고 추측했다.
10.5.2 Optimizing InnoDB Transaction Management 공식문서를 보면
Avoid performing rollbacks after inserting, updating, or deleting huge numbers of rows. If a big transaction is slowing down server performance, rolling it back can make the problem worse, potentially taking several times as long to perform as the original data change operations. Killing the database process does not help, because the rollback starts again on server startup.
트랜잭션이 커지는 거 자체가 DB 퍼포먼스에 영향을 줄 수 있을뿐더러, 이것들을 롤백하는 건 더 많은 시간이 걸릴수 있다고 한다. 원래 데이터를 복구하는 과정까지 필요하기 때문이다.
InnoDB는 MVCC를 사용하는데, 데이터에 변화가 있을 때마다 실제로 DB에 변화가 생긴다. 커밋을 하면, 이 데이터들이 실제로 변경된 상태가 저장이 되는 것이고, 롤백이 되는 건 이 변경 내용을 다 지운다는 뜻이다.
즉, 롤백은 변경된 내용을 모두 없애고, 기존 데이터를 다시 디스크에 저장하는 과정까지 필요하다. 수백만개의 데이터를 지운다고 해보자. 나중에 배치 처리를 하기 위해서 트랜잭션을 중간에 종료했다고 할때, 롤백으로 시간이 몇 시간이 더 걸릴 수 있다고 한다.
롤백 시간은 트랜잭션이 수행한 쓰기 작업의 수에 직접적으로 비례하고, 트랜잭션이 활성화된 시간에 간접적으로 영향을 받는다고 한다. (더 정확히는 다른 동시 트랜잭션들이 얼마나 많은 변경을 했는지, 즉 전역적인 undo 로그의 크기에 따라 다르다)
트랜잭션이 커지는건?
InnoDB는 멀티 버전 스토리지 엔진이라고 한다. 즉, 변경되는 데이터의 old version들을 갖고있고, 이를 통해 롤백을 지원한다. 이러한 정보는 언두 테이블에 저장이 된다.
그래서, 트랜잭션은 너무 길게 가져가지 않고 주기적으로 커밋을 하는 게 권장된다. 그렇지 않으면, 이러한 언두 로그들을 계속 저장하고 있어야 하기 때문이다.
참고자료
