실전프로젝트 1주차 회고

💣 크롤링

---

정말 많은 시행착오를 겪으면서 우리의 목표대로 데이터는 순조롭게 들어가고 있다.

특히 Not Found Error가 발생하면서 정말 많은 시행착오를 겪었다.

우리는 너무 답답해서 여기저기 수소문을 해보기도하고 멘토님께 질문을 드려보았는데

결론은

많은 시행착오와 트러블슈팅을 통해 웹 크롤링시 무분별하게 반복적인 요청은
서비스에 과도한 부하를 줄 수 있기 때문에 그에 대한 처리를 해두었을 가능성도 고려해보아야 하지만
우리가 어느정도까지 처리했을지를 알 수 있을 가능성은 적으므로 시행착오를 겪으며
알아내야 한다는 답변을 받았다.

 

우리가 정말 다행이라고 생각했던 것은 우리의 방식이 틀리지 않았구나 다른 더 좋은 방법이 있는데

우리가 찾지 못한것이 아니라 그냥 단지 크롤링의 단계를 밟고 있는것이구나 라는 마음이 들었던 것이었다.

많은 시행착오 끝에 손실율이 30%에서 40%에 달했던 수치를 0%까지 내리는데 성공했다.

즉 Not Found Error는 한건도 발생하지 않았다.

추가 멘토님 질의응답시간에 크롤링에 대한 부분도 대화를 나눴는데

우리가 이런식으로 한다면 정말 우리가 필요하고 유효한 데이터는 100만건 정도 쌓일듯한데

그정도로는 좀 부족할거같다는 의견을 조심스레 내놓으셨다.

정말 pc방에 가서 크롤링을 돌릴까도 고민했지만 그것보다는 유효한 더미데이터를 채우는것에 집중하자는

의견으로 좁혔고 우리가 확보한 공공데이터의 csv를 정제하여서 이것을 더미데이터로 활용할 계획이다.

크롤링에 대한 고민들은 1주차때 모두 마무리 했다.

https://www.notion.so/Pin-Pin-e1c93222b60f49a7b445b0d7dec11027?p=9ec37cc4600545e7972663f4d9d06364&pm=s

크롤링시 404 Not Found 발생 현상

 

🗺 지도 API 구현

---

네이버에서 지도 API를 가져와서 구현했고 추후에 우리가 사용할 핵심 기능이었고

아직 다른 기능들이 완성되지 않은 기초단계였기에 로직을 잘 짜놓것이 중요했다.

DB에 있는 가게정보를 비교해서 카테고리에 따라 분류한 뒤 분류가 완료된 가게의 위도와 경도를

가져와서 지도로 뿌려주어야했는데 이 부분은 Service단에서 처리해야한다고 판단해

Controller단에서 구현되어 있던 내용을 Service로 옮겨서 구현했다

하지만 문제는 그렇다면 어떻게 service에서 찾은 위도 경도값을 지도로 던져줄수 있을까라는 고민을

많이 했다

JSP도 고려했지만 Thymeleaf를 적용해서 위도 경도 값을 넘겨줬다

이유는 JSP보다 Thymeleaf가 패키지 구조를 해치지 않았고 팀원들이 훨씬 더 이해하기 쉬운 코드가

될것이라는 판단을 했기 때문이다.

https://www.notion.so/API-85bfb55518174ddabdbc9511a837733b

네이버 지도 API 적용

 

👻 아키텍처 설계 및 우리와 맞는 기술스택 고려하기

---

우리의 1차로 설계된 아키텍처이다.

기술스택을 고려하면서 redis와 ElasticSearch에 대한 고민을 정말 많이 했던거 같다

아무래도 고민을 더 많이 했던 이유는 실제로 구현을 해보진 않았기때문에 고민이 많아질수밖에 없었다.

ElasticSearch를 사용해서 검색성능을 개선하는 것은 필수적인 것이었는데 redis를 사용하면 그보다 더 개선되지 않을까라는

고민을 했다.

ex) 첫번째 사용자가 성수 맛집을 검색한다면 ElasticSearch 검색엔진을 통해 빠르게 조회해 맛집 리스트를 사용자에게 보여줄 것이고

그 데이터는 redis 메모리에 등록한다

그렇다면 두번째 사용자가 성수 맛집을 검색한다면 ElasticSearch 검색엔진을 거치는 것보다 더 빠르게 데이터를 가져올 수 있을것이다.

일단 내 접근방식이 맞다 저런 방식으로 redis를 거친다면 훨씬 더 빠를 것이라는 멘토님 답변을 받았다

하지만 동시에 고려해야할 부분도 짚어주셨다.

 

바로 redis Cache hit rate

예를 들어본다면 초밥 맛집 감자탕 맛집 성수 맛집 강남 맛집 등의 정보를 redis에 저장을 했다

그리고 이 정보를 자주 사용한다면 redis를 100% 아주 잘 활용하는 것이다

하지만 사용하지 않는 정보도 분명히 있을 것이다

즉 초밥 맛집이 10번 사용될 동안 감자탕 맛집은 단 한번도 사용되지 않을 수 있고

사용하지 않는 만큼 그대로 손해로 돌아 올 것이다

과연 그렇다면 어떻게 많이 쓰는 것만을 골라서 Redis에 넣을 수 있을까 라는 고민을 하게 되는데

쉽진 않을것이다 라는 답변을 받았다.

하지만 redis를 구현해보는 것은 좋다고 하셨다 구현해보기로 했다.

 

 

https://cat-corleggy-5cd.notion.site/ElasticSearch-da3b0f9e61f74540919bf1706002c165

ElasticSearch

https://cat-corleggy-5cd.notion.site/Redis-7f55557661db41dea994750f66c7c4a2

Redis

 

😂 기획 수정

---

전면적으로 기획을 수정했다

이유는 멘토님께서 우리의 MVP는 너무 기능이 적다고 했고 다른 문제점들도 많이 짚어주셨다.

https://www.notion.so/3-1-eb50ccaa8844497988083d9d8c90ba14

https://www.notion.so/3-1-ef973c8886fd4f4d9410c92d5993b566

https://www.notion.so/3-1-96543602b6cb4eb08709bbc90ab32e1f

3조 1차 기술 멘토링 사전 노트

3조 1차 기술 멘토링 피드백 기록 노트

3조 1주차 멘토링 숙제 [기획안 수정]

 

 

참조링크 https://medium.com/prosple-engineering/debugging-drupal-redis-cache-hit-rate-11fe16d5c34f