Day 66. 일단 Pending은 pending이요

처음에는 SSE 기능을 도입한 뒤로 주기적으로 프론트단에서 pending이 나타났고 백에서 확인할 수 있었던 문제는 HIkari pool DeadLock 이었다. sse 기능을 위해 subscribe를 한 뒤 계속해서 db에 요청이 가는 것 같았고 그로 인해 닫히지 않은 pool이 많아지니 임계값인 20을 넘어서면 db에 lock이 걸려 pending이 나타나고 있었다. 그래서 우리가 찾은 해결책은 SSE 관련 데이터 저장을 rds로 하지말고 다른 db로 옮기자는 거였다.

 

카산드라란?

[Cassandra] 아파치 카산드라란?

 

그런데 카산드라로 옮겨도 여전히 pending 현상이 나타나고 있었다. 하.. 도대체 뭐가 문제였는지 아직도 완전히 해결을 하지는 못했으나 결국 해결을 본 것은 OSIV 설정을 끄는 것이었다. 이 OSIV가 무엇이길래 이걸 끄고서 된건지 정리해보겠다.

 

전에 JPA 스터디를 하면서 한 번 들어봤었던 OSIV. 이것은 jpa를 연동하고 스프링부트를 실행하면 warning 문구로도 매번 등장했었다. 다만 관심을 갖지 않고 봤을 뿐..

일단 OSIV는 Open Session In View의 약자로 말그대로, 세션을 뷰에서도 열겠다는 의미임. 여기서 말하는 세션이라는 것이 영속성 컨텍스트를 이르는 말인 것 같다. 그러니까 영속성 컨텍스트를 뷰까지 열어서 영속 상태를 유지하겠다는 것이고 그렇다는 것은 뷰단에서도 지연 로딩을 사용할 수 있다는 것이다.

영속성 컨텍스트를 통해 지연로딩이 되니까 캐시 메모리에서 데이터를 조회할 수 있고 그러면 당연히 db에 부하가 줄어들텐데, 보통 이 영속성 컨텍스트는 트랜잭션 단위로 움직이기 때문에 service - repository 계층을 관리하고 controller - view 계층은 관리하지 않는다. 보통 준영속 상태인 controller-view 에서는 지연로딩이 안되기때문에 예외가 발생할 수 있다. 

이를 해결하는 방법 중에 하나가 OSIV를 켜놓는 것. 이 녀석을 설정해놓음으로 뷰단에서도 영속 상태를 유지할 수 있게 되고 db에 계속해서 접근하지 않아도 되니 효율적

but  장점만 있는 것은 아니고 너무 오랜시간 동안 db 커넥션 리소스를 사용할 수 있고 트랜잭션이 종료되었을 때 롤백 문제가 생기는 등 문제가 생길 수 있으니 맹신은 금물임.

https://ttl-blog.tistory.com/183

[JPA] OSIV 란?

 

아무튼 이 OSIV 설정을 꺼줌으로써 영속성 컨텍스트를 닫아주고 DB 커넥션을 반환하니 기존에 sse로 인해 구독을 물고 있던 연결에서 락이 걸리지는 않음. 하지만.. 이로 인해 데이터에 변경점이 생겼을 때마다 (ex, update해줘야하는 간단한 수정 사항 적용할 때) db에 따로 접근을 해서 일일히 적용해주어야 한다는 것.. 

 

뭐가 맞는지는 모르겠는데 일단 pending 현상은 이것으로 해결이 되었다. 이게 완전한 해결책인지 조금 더 두고봐야하겠지만 계속해서 탐구해볼 예정이다.

 

++ 고객 서비스 기반의 트래픽이 많은 실시간 API 에서는 OSIV를 끄고 ADMIN 같이 커넥션을 많이 사용하지 않는 곳에서는 OSIV를 켠다고 하네.. 음 어쩌면 이게 답이 되었을지도..?

https://dodeon.gitbook.io/study/kimyounghan-spring-boot-and-jpa-optimization/04-osiv

OSIV와 성능 최적화 - dodeon

https://velog.io/@tco0427/HikariCP-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0

HikariCP 설정하기