[Solitour] 비용과 성능의 트레이드오프

프로젝트 개발 하면서 고민사항에 대한 글이다 

https://www.solitourist.com

Solitour - 새로운 나를 찾는 여행

 

 

전에 고민 했던 점이랑 이어지는 고민 이다 

https://hyeonni.tistory.com/90

[Solitour] 성능 vs. 코드 가독성의 갈림길

 

위 글을 먼저 보고 오자 

 

결국 2개의 쿼리를 작성하자는 판단을 했지만 계속 머리 속에서는 좀 더 나은 방법이 없을까라는 생각이 멤돌고 있었다 

그러는 도중 

코드를 수정 하면 되지 않을까? 라는 생각을 해보았다 

 

 

다른 계층에서 처리 하면 되지 않을까?

 

전에는 데이터를 가져오고 페이지객체로 만들어주는 작업을 repository 계층에서 해주었다 

하지만 전체 데이터를 repository에서 가져오고 page 객체로 변환하는 것을 service 계층에서 하면 되지 않을까?

 

이렇게 하면 전체 데이터를 가져오는 쿼리를 한개만 작성하고 데이터베이스 호출을 2번에서 1번으로 줄일수 있을 것 같다고 생각 했다 

그리고 여러 장점이 있다 

1. 구현 간편성
2. 유연성
3. 단순한 트랜잭션 관리

 

그래서 다시 고민을 하였다 

 

각각의 쿼리를 2번 작성하냐 vs 전체 데이터 조회 후 serivce 계층에서 로직 처리

 

성능 및 효율성

 

메모리 사용

• 쿼리 2번 : 한번에 많은 데이터를 가져오지 않으므로 메모리 사용이 상대적으로 적음
• 전체 조회 후 페이지네이션 : 전체 데이터를 메모리에 로드하기 때문에 메모리 사용량이 증가할 수 있습니다. 데이터셋이 크면 메모리 부족 문제나 GC 오버헤드가 발생 할 수 있다

-> 데이터의 크기와 메모리 용량에 따라 선택이 달라질 수 있다. 메모리가 넉넉하면 서비스 계층에서 페이지네이션을 처리하는 방법도 가능하지만, 그렇지 않다면 위험할 수 있다

 

 

데이터베이스 부하 

 

• 쿼리 2번: 데이터베이스에 2번의 쿼리를 날리지만, 각각의 쿼리는 필요한 최소한의 데이터만을 요청한다. 데이터베이스에서 페이징 처리와 카운트를 효율적으로 처리할 수 있다.
• 전체 조회 후 페이지네이션: 한 번의 쿼리로 모든 데이터를 가져오지만, 대량의 데이터를 처리할 경우 데이터베이스와 네트워크, 애플리케이션 메모리에 모두 부하가 걸릴 수 있다.

→ 데이터베이스가 감당할 수 있는 부하 수준을 고려해야 한다. 쿼리가 최적화되면 두 번의 쿼리 방식이 더 안정적일 수 있다.

 

 

네트워크 트래픽

• 쿼리 2번: 필요한 데이터만 네트워크를 통해 전송하므로, 트래픽이 최적화 된다.
• 전체 조회 후 페이지네이션: 전체 데이터를 가져오므로, 네트워크 트래픽이 증가할 수 있다. 특히, 대규모 데이터셋의 경우 이는 성능 저하로 이어질 수 있다.

-> 네트워크 비용을 줄이는 것도 중요한 경우가 많다. 특히 클라우드 환경에서는 데이터 전송량이 요금과 성능에 큰 영향을 줄 수 있다

 

 

구현의 간편성과 유연성

 

• 쿼리 2번: SQL이나 JPA의 기능을 적극 활용하므로 페이징 및 필터링 처리가 간편하다.

• 전체 조회 후 페이지네이션: 구현이 더 직관적이고, 복잡한 비즈니스 로직을 서비스 계층에서 처리할 수 있는 유연성을 제공한다.

 

→ 단순한 로직이라면 데이터베이스에서 처리하는 편이 좋지만, 비즈니스 로직이 복잡하면 서비스 계층에서 처리하는 것이 더 적합할 수 있다.

 

 

확장성

• 쿼리 2번: 데이터셋이 커져도 성능이 크게 저하되지 않으며, 데이터베이스와 네트워크 부하를 최소화할 수 있어 확장성이 좋다.
• 전체 조회 후 페이지네이션: 데이터셋이 커질수록 성능이 저하될 가능성이 높아지고, 시스템 확장성에 문제가 발생할 수 있다

→ 데이터셋이 커질 가능성이 있는 경우에는 쿼리 2번 방식을 사용하는 것이 더 적절하다.

 

 

 

 

결론

 

작자는 결국 쿼리 2번 사용하는 방식을 택했다 

 

이유는

 

1. 메모리 효율성 

• 전체 데이터를 한 번에 메모리에 올리면 예상치 못한 메모리 부족 문제나 GC 오버헤드가 발생할 수 있다.
• 특히, 데이터가 점점 많아질 가능성을 고려했을 때 메모리 효율을 유지하는 것이 중요했다.

 

2. 데이터베이스 부하 최적화

• 두 번의 쿼리지만 각각 필요한 최소한의 데이터만 요청하므로 데이터베이스와 네트워크 부하를 효과적으로 줄일 수 있다.
• 또한, 데이터베이스는 페이징 및 카운트 처리에 최적화된 경우가 많기 때문에 성능 측면에서 유리했다

 

3. 네트워크 트래픽 감소

• 쿼리 2번 방식은 필요한 데이터만 네트워크를 통해 가져와 트래픽을 줄인다.
• 이는 클라우드 환경에서 비용 최적화와도 연결되며, 대규모 데이터를 처리할 때 성능 저하를 예방할 수 있다.

 

4. 확장성 확보

• 프로젝트가 성장하며 데이터셋이 커질 것을 예상했다.
• 데이터가 많아지더라도 최소한의 데이터만 쿼리로 가져오면 확장성 문제가 덜 발생하기 때문에 장기적인 운영 측면에서 더 유리하다고 판단했다.

 

 

결국 나는 안정성과 확장성을 우선시하여 선택을 하였다 

더 안정적인 서비스를 운영 하는게 더 중요시 하기 때문에 데이터베이스 부하와 메모리 사용을 최소화 하는 방법을 택했다

 

향후 데이터가 늘어날 경우에도 성능 저하 없이 서비스가 유지될 수 있도록 미리 대비한 것이며, 이는 프로젝트의 장기적인 성공을 위해 중요하다고 판단했다.

 

 

이번 선택을 통해 모든 문제를 한 번에 해결할 수 있는 완벽한 방법은 없다는 점도 깨달았다.

 

개발 과정에서 발생하는 고민들은 결국 트레이드오프를 이해하고 상황에 맞는 최선의 결정을 내리는 것임을 다시금 느꼈다.