Spring MVC 요청 처리 과정, JPA Flush, 인덱스 최적화까지 한 번에 정리

Spring MVC에서 요청이 처리되는 과정

웹사이트에서 버튼을 클릭하면, 우리 눈에는 그냥 화면이 바뀌는 것처럼 보이지만, 실제로는 여러 가지 과정이 일어납니다. Spring MVC에서는 DispatcherServlet, HandlerMapping, HandlerAdapter가 중요한 역할을 합니다.

 

1. DispatcherServlet (배달부 역할)

사용자가 웹 요청을 보내면, 가장 먼저 DispatcherServlet이라는 배달부가 요청을 받습니다.

• "이 요청을 어디로 보내야 하지?" 고민하며 적절한 곳으로 전달해 줍니다.

2. HandlerMapping (주소록 역할)

배달부는 HandlerMapping이라는 주소록을 참고해서

• "이 요청은 어디로 가야 하는구나!" 하고 컨트롤러(요청을 처리하는 곳)를 찾습니다.

3. HandlerAdapter (배달 도우미 역할)

목적지가 정해지면, HandlerAdapter가 "이 요청을 실행하는 방법은 이거야!" 하면서 요청을 컨트롤러로 넘겨줍니다.

 

4. ViewResolver (화면 결정)

컨트롤러에서 응답할 데이터를 준비하면, ViewResolver가 "이 데이터를 어떤 화면으로 보여줄까?"를 결정합니다.

 

5. 최종 응답!

최종적으로 정해진 화면이 사용자에게 보여지고 요청이 끝납니다.

JPA의 flush란? 언제 발생할까?

JPA는 데이터를 데이터베이스(DB)에 바로 저장하지 않고, 한 번에 모아뒀다가 저장하는 방식을 사용합니다. 이 과정을 lush(플러시)라고 합니다.

 

1. 트랜잭션이 끝날 때 (commit)

• "이제 저장해도 되겠다!" 싶을 때 한 번에 저장됩니다.

2. JPQL을 실행하기 직전

• 데이터를 조회하는 쿼리를 실행하기 전에, "변경된 내용이 있다면 먼저 DB에 반영해야 해!" 하고 flush가 발생합니다.

3. 개발자가 직접 flush()를 호출할 때

• "지금 당장 저장해!" 하고 명령하면 flush가 발생합니다.

인덱스를 너무 많이 만들면 안되는 이유

인덱스는 책의 차례(목차)랑 비슷합니다. 차례가 있으면 원하는 내용을 빠르게 찾을 수 있지만, 너무 많으면 오히려 불편하다.

 

1. INSERT, UPDATE, DELETE가 느려짐

• 새로운 데이터를 추가할 때마다 모든 인덱스도 함께 업데이트해야 하므로 성능이 저하됩니다.

2. 디스크 공간을 많이 차지함

• 차례가 많으면 책이 두꺼워지는 것처럼, 인덱스가 많으면 저장 공간을 많이 사용합니다.

3. 잘못된 인덱스를 사용하면 더 느려짐

• 차례가 많아서 빠르게 찾을 수 있을 줄 알았는데, 오히려 더 헷갈리는 상황이 발생할 수 있습니다. (쿼리 옵티마이저의 부하 증가)

📌 그래서 꼭 필요한 인덱스만 만들어야 합니다!