N+1 문제 해결에 대한 질문

Question

4&#43;N 개의 쿼리문이 나가는 것을 1개의 쿼리문이 나가도록 N&#43;1 문제를 해결했습니다.하지만, N&#43;1 문제를 해결해도 API 응답 시간이 줄지 않고, 오히려 더 증가했습니다.테스트는 여러 사용자가 해당 API를 반복 요청하는 것이 아닌, 1명의 사용자가 딱 1번 요청하도록 시나리오를 만들어 테스트했습니다. 단순히 해당 API에 대한 성능을 체크해보고자 했습니다. (1명의 사용자가 요청하기에, 병목 현상은 고려하지 않아도 된다고 생각합니다만 제가 잘못 인지하고 있다면 말씀해주시면 감사하겠습니다)저는 사용자의 입장에서 좋은 API는 결국 응답 시간이 빠른 API 라고 생각됩니다. N&#43;1 문제를 해결해서 서버에서 DB로 요청되는 부하가 줄어들 순 있겠지만, 결국은 응답 속도가 빨라야 한다고 생각해요.CPU 사용량이나 네트워크 환경도 테스트에 영향을 미치는 요소이지만, 한 장소에서 동일 컴퓨터로 여러 번 테스트해보았습니다. 연관된 모든 엔티티를 함께 조회하는 fetch join 방법으로 해결했기에, N&#43;1 문제를 해결하긴 했지만 매우 최적화된 쿼리로 해결했다고 볼 순 없습니다. (응답 데이터에 필요하지 않은 필드까지 함께 조회하기 때문입니다)API의 응답 속도를 위해 N&#43;1 문제를 그대로 두는 것, N&#43;1 문제를 해결하되 좀 더 고도화된 방법으로 쿼리를 최대한 최적화되게 개선하는 것. 고민이 되는 부분입니다. 선배님들의 의견 부탁드리겠습니다 ㅠ 쿼리를 개선한다면, 불필요한 필드는 조회하지 않고 꼭 필요한 필드만 가져오는 식으로 다시 작성할 것 같은데, 불필요한 필드 때문에 속도가 느린건지는 잘 모르겠습니다. 만약 필요한 필드만 가져와서 응답 dto와 매핑한다면 쿼리 반환 타입을 dto로 해주어야 하는지 고민도 되네요.. 현재는 mapstruct를 사용해서 자동 매핑해주고 있습니다만, 필요한 필드만 가져오게 된다면 전체 매핑 로직을 수정해줘야 하는지..

kotliner · Accepted Answer

실제 서비스 운영에서 극단적인 latency 개선은 아무런 이득이 없습니다. 10초를 1초로 줄이는건 효과적이지만 50ms -> 20ms로 바꾼다고 해서 들이는 공수대비 효과는 전혀 없다시피 합니다. 1명의 사용자에게 10ms의 응답시간을 만들어도 1000명이 접속할때 100초가 걸린다면 아무런 의미가 없습니다. latency는 적당한 선에서 정리하고 다른 부분에 집중하는것이 훨씬 이득입니다. 정리하면 병목을 확인하지 않는 동시유저 1명의 테스트는 부하테스트가 아닌 단순 call을 테스트하는것이며 이는 실제 성능과 거의 무관합니다.java를 쓰면서 극단적으로 응답시간을 줄이고 싶다면 라이브러리 안쓰고 직접 db에 붙어서 문자열로 쿼리하면 됩니다. 그렇게하면 쿼리문의 string 크기도 작아지고 불필요한 객체 매핑과정도 사라져서 응답시간을 극단적으로 줄일 수 있습니다. 다만 확장성이나 유지보수성은 떨어져서 하나의 crud를 작성하는데에 몇십배의 시간을 쓰고 관리가 안되겠죠. 현대의 개발과정은 추상화를 통한 에코 시스템을 최대한으로 활용하는데에 집중하며 바퀴를 재발명하지 않도록 발전했습니다. 그 과정에서의 오버헤드는 위에 적은것처럼 10ms -> 20ms같은 거의 미미한 차이에 불과합니다.

집킨 · Answer

단순히 쿼리에서만 원인을 찾고자 한다면해결 전후의 쿼리랑 ERD랑 테이블에 들어있는 데이터 갯수를 보여주셔야..

N+1 문제 해결에 대한 질문

2개의 답변

Q&A 목록