[Team-22][BE][Lee&벅픽] - 프로젝트 초기 설정 및 Mockup API 제공, 숙소 검색 기능

[bugpigg]

안녕하세요 Jack!
Team-22 Lee & 벅픽 입니다.

📙작업내역

• 스프링 부트 프로젝트 초기 설정
• 포스트 맨을 활용한 Mockup API 제공
  • Mockup Docs
• 숙소 검색 기능 초기 구현

❓질문사항

• 숙소 검색 기능을 구현하면서, 검색 조건이 여러 개이다 보니 JPA를 통해 필터링하는 것은 DB 접근이 너무 많아질 것이라 생각해 Repository에서 모든 숙소 정보를 List로 받아온 후에 자바 코드 단에서 필터링하는 로직으로 구현하였는데요. 필터링 로직 등도 다소 복잡한 느낌입니다. 추후 엘라스틱 서치 등을 사용하면 여러 조건으로 깔끔하게 검색을 구현할 수 있게 되는지 궁금합니다!

• 숙소에서 예약된 날짜를 DB에 저장할때, 어떤 방식을 활용하여 저장해야하는지 궁금했습니다.
  현재는 자바의 Map 컬렉션을 통해 해당 날짜의 예약 가능 여부를 저장하고 있습니다.

앞으로 잘 부탁드립니다. 감사합니다~!

[guswns1659]

안녕하세요 : )
이번 프로젝트 리뷰어를 맡은 Jack입니다.
리뷰는 더 나은 방향을 결정하기 위해서 하는 것이지 결코 정답은 없습니다 ㅎㅎ 잘 취사선택 해주세요 👍
여러분과 제가 많은 것을 얻어가는 리뷰가 되길 바라겠습니다.

제가 리뷰를 하면서 몇 가지 단어를 사용할텐데 아래와 같은 의미를 담고 있습니다.

• ask : 의미대로 의문점이 생겼을 때 주로 사용하며, 반드시 답변할 필요는 없습니다 .상황에 맞게 답변해주시면 됩니다.
• nit : 사소한 포인트에 대한 리뷰이며, 이 방법도 좋은 것 같습니다 와 같은 의미.
• ditto : 이전에 한번 나온 동일한 내용의 리뷰지만 반복되는 경우 간략하게 표현할 때 사용.

[guswns1659]

수고하셨습니다.
남긴 코멘트들 한번 고민해보시고 취사선택해서 다음 P.R에 반영해주세요 👍

[guswns1659]

이곳이군요 : )

숙소 검색 기능을 구현하면서, 검색 조건이 여러 개이다 보니 JPA를 통해 필터링하는 것은 DB 접근이 너무 많아질 것이라 생각해 Repository에서 모든 숙소 정보를 List로 받아온 후에 자바 코드 단에서 필터링하는 로직으로 구현하였는데요. 필터링 로직 등도 다소 복잡한 느낌입니다. 추후 엘라스틱 서치 등을 사용하면 여러 조건으로 깔끔하게 검색을 구현할 수 있게 되는지 궁금합니다!

질문 답변 여기서 할게요.
우선 잘하셨습니다 👍 내가 처한 상황에서 어떻게든 우선 요구사항 구현하는게 중요합니다.

JPA로 필터링을 한다는 게 반드시 DB 쿼리 요청 횟수가 늘어나진 않습니다. N+1과 같은 케이스라면 쿼리가 많아 질 수 있지만, 이에 대한 대응도 존재합니다. fetch join 등..
만약 조회 쿼리가 복잡하다면 @query 어노테이션을 이용해 직접 쿼리를 작성할 수 있고 이런 경우는 하나의 쿼리만 요청하도록 조정할 수 있습니다. 그래서 직접 쿼리를 작성해보는 것도 어떨까요?

애플리케이션 서버에서 필터로직을 처리하면 아래와 같은 단점이 존재합니다.
데이터가 많아지면 초기에는 1개 요청에 1초 이내 였지만 추후 1개 요청에 10초씩 걸릴 수 있죠. 이 의미는 한 개 쓰레드가 처리하는 속도가 느려진다는 의미입니다. 그러면 스프링mvc에서는 쓰레드의 개수를 정해놓고 요청을 처리하기 때문에 금방 쓰레드가 고갈되고 요청은 많이 밀릴겁니다. 이런 현상을 쓰레드 풀 헬 현상이라고 부르기도 합니다.

---

엘라스틱 서치는 지금처럼 숙박을 여러 조건으로 필터해서 조회할 때보다는 숙박을 검색할 때 장점이 크게 발휘합니다. 엘라스틱 서치는 예를 들어, 구글에서 내가 키워드를 넣어서 엔터치면 그 단어를 포함한 컨텐츠를 보여줄 때와 같은 상황 주로 사용합니다. 본문 검색의 의미라 생각하시면 됩니다. 이번 프로젝트에서는 숙박의 설명이나 키워드만으로 특정 숙박들을 검색하고 싶을 대 사용하시면 됩니다.

예를 들어, "제주도 오션뷰" 라고 검색하면 이런 키워드를 가진 숙박 목록이 뜨는 기능.

질문하신 필터를 걸어서 조회를 깔끔하게 하고 싶다면 QueryDsl도 하나의 방법인데, 지금은 JPA 사용하시는 게 맞습니다. 추후에 한번 검색해보세요 ; )

[bugpigg]

상세한 코멘트 감사합니다~!
관련하여 두 가지 질문이 있습니다!

• 만약 DB에 접근하여 필터링 하는 과정도, Application Sever의 필터링 과정과 같은 시간이 걸린다면 이와 같은 상황도 쓰레드를 계속 점유하고 있는 것 같은데 그렇다면 이도 쓰레드 풀 헬 현상에 취약한것이 아닌지 궁금합니다.
• 쿼리를 날린다면 지금 생각하기로는 아무래도 where 절에 조건을 병렬하는 형태이지 않을까 싶은데요.
  저희가 고민했던 부분은 쿼리의 개수 자체보다는 인원수, 가격, 예약 등 Accommodation의 여러 컬럼들의 정보를 가지고 where 절에 and로 병렬해서 검색하다 보면, 이 컬럼들이 primary key 값들이 아니니 결국 where 절의 각 조건마다 DB 풀 스캔을 하게 되는 건가… 싶은 부분이었습니다.
  그래서 DB 검색을 최소화하고 어플리케이션에서 나머지 필터링을 처리하려고 했던 것이고요!
  DB 수업 때 얕게만 이해한 것이라 실제로는 어떤지 잘 모르겠네요... where 절에 조건을 여러 개 주더라도 검색 효율에 큰 지장이 없을까요?

[guswns1659]

@bugpigg

질문 좋네요 👍

만약 DB에 접근하여 필터링 하는 과정도, Application Sever의 필터링 과정과 같은 시간이 걸린다면 이와 같은 상황도 쓰레드를 계속 점유하고 있는 것 같은데 그렇다면 이도 쓰레드 풀 헬 현상에 취약한것이 아닌지 궁금합니다.

네네 맞습니다. 만약 DB의 필터링도 늦어진다면 쓰레드가 밀리니 쓰레드 풀 헬 현상이 발생합니다. 다만, 그런 일이 발생하지 않도록 ㅎㅎ 인덱스나 파티션 등을 잘 이용해야겠죠. 그래서 현재와 달리 데이터가 상당히 많은 상황이라 가정해보면 "앱 서버에서 필터링 한다" vs "DB에서 필터링 한다" 조건에서 DB를 추천한다는 코멘트였고, 사실 저라면 DB한테 조회 쿼리 맡길 거 같아요 : ) DB가 데이터 조회하라고 만들어진 제품이니까 ㅎㅎ

쿼리를 날린다면 지금 생각하기로는 아무래도 where 절에 조건을 병렬하는 형태이지 않을까 싶은데요. .....

먼저 드는 생각은 DB 풀스캔 한다고 걱정하실 필요 없을 거 같아요. ㅎㅎ 현재 프로젝트 요구사항이 성능을 개선하라는 것보단 숙박 예약 업소를 구현이니까요. 지금은 당연히 인덱스가 없으니 풀스캔을 할겁니다. mock 데이터 양이 어느정도 일지 모르겠지만 DB한테 맡겨보는 게 어떨까 싶습니다.
만약 제 조언대로 DB 쿼리로 필터하도록 변경했는데 성능이 느리다면 인덱스를 추가하는 방법을 고민하거나 다시 애플리케이션 로직에서 처리하도록 변경할 수 있겠죠 ㅎㅎ
저는 DB라는 제품이 데이터를 쌓고 조회하도록 만들어진 제품이니까 우선 그 역할에 맞게 써보는 걸 추천드립니당.
물론 애플리케이션에서 처리하셔도 됩니다! 팀원끼리 합의한 대로 하세요 : )

+) 요즘 다른 팀 P.R 알람도 엄청와서 제가 놓칠 수 있으니 만약 답장이 늦어지면 슬랙으로 연락주세용