항해 11주차 WIL

이번 주는 프론트엔드가 아직 기능 개발 중에 있기 때문에 처음 프로젝트 기획할 때 고려하던 기능을 추가하는 것은 포기하기로 했다. 프론트엔드는 혼자 하시기 때문에 절대적으로 시간이 부족했다. 프로젝트 제출 기한에 맞추기 위해서는 현재 완성된 부분에 집중하는 것이 맞는 것이라는 생각이 들었다. 16일 배포를 목표로 했지만 테스트를 하면서 에러가 너무 많아 당장 배포하는 것은 무리라는 판단이 들어 배포를 늦추기로 했다. 

 

1. 식당등록 방식 변경

1.16일,  프론트엔드 서버와 처음 연결해봤다.  테스트해보니 사용성이 불편한 점들이 있었다. 특히, 식당등록부분에서 사용자가 식당을 등록하기 위해서는 등록하고자 하는 떡볶이집의 정확한 주소를 알고 있어야 위치를 등록할 수있다. 주소 검색 API를 사용하고 있다보니 서울역, 오정동 등과 같이 장소명이나 간략한 주소로 위치 등록을 할 수 없었다. 정확한 주소를 검색하는 과정을 한 번 더 거쳐야 했기 때문에 사용성이 너무 떨어진다는 판단이 들어 식당 등록 UI를 변경할 것을 제안했다. 현재 쓰고 있는 주소 검색 API 대신 카카오에서 제공하는 MAP API로 변경해서 사용자가 대략적인 지역명이나 장소로 위치를 검색할 수 있게 하고, 단순히 텍스트로 주소를 노출하던 것 대신 지도에서 핀을 움직여 사용자가 등록하고자 하는 정확한 떡볶이 집의 위치를 선택할 수 있게 해서 편의성을 높이기로 했다. 

2. MAP상에서 사용자가 위치를 이동할 때마다 근처 식당의 목록을 불러오는 API를 호출하고 있다. 현재 디바운싱이라는 것을 이용해서 유저가 커서를 놓았을 때 마지막 요청만 들어가도록 해두었는데 이 부분 때문에 지도를 확대/축소할 때 에러가 발생했다. 

디바운싱을 하지 않으면 너무 많은 API 요청이 되기 때문에 버벅거리는 현상이 일어났다. 

확대를 하는 경우에는 백엔드에게 API요청을 하지 않도록 수정해봤지만 지도를 움직이는 카카오 API 요청은 계속 보내야하기 때문에 버벅거리는 현상은 나아지지 않았다. 확대/축소를 아예 막는 방법을 제시해주셨는데 사용성이 너무 떨어져서 어떻게 결정해야할 지 잘 모르겠다.

 

3. 성능 테스트 후 캐시 적용

성능 테스트를 진행하고 있다. 캐시 적용 전 비교 데이터가 있어야 하기 때문에 성능 테스트가 끝나면 캐싱을 적용하려고 한다. 

현재 위치 검색 시 API요청이 너무 빈번하고 이는 DB테이블 전체를 훑도록 되어있어서 상당히 무거운 요청이다. 또한, 메인페이지 이기 때문에 로딩 시간이 오래 걸린다면 사용자 이탈가능성이 있기 때문에 이 부분을 먼저 캐싱을 적용해보려고 한다. 

Redis 도입을 고려해봤지만 설정 자체가 복잡했고 cache 기능으로써만 이용할 것이기 때문에 Redis 복잡한 설정을 대신 해주는 AWS에서 제공하는 Elasticache 서비스를 이용하기로 했다. 

• 즉시 캐쉬를 생성해서 사용할 수 있다.
• 캐쉬의 성능과 수량을 유연하게 변경할 수 있다.
• 사용한 만큼만 지불하면 된다.
• 모니터링 제공

로컬 테스트상에서만 redis 캐싱을 적용해봤기 때문에 성능테스트가 끝나면 서버에 캐싱을 적용해서 결과를 비교분석해봐야 할 것 같다.

 

다음 주

* 성능 테스트 결과 분석

* Elasticache 적용: 서비스 특성을 이용해서 어느 부분까지 cache 처리할 지 고민..

* DB 부하 테스트 -> 오토 스케일링 도입 이전에 DB 쿼리 확인하고 개선 예정. 현재 인덱스 적용안해서 table full scan 하고 있음...

* log : 배포하면 log를 볼 수 없어서 cloudwatch 서비스 알아보고 있는 중..