Today I Learned ...
오늘은 시스템 아키텍쳐를 그리고, 본격적으로 V3 개발을 시작하였다!
🖥️ 번쩍 팀프로젝트 #12
오늘은 우리 팀에서 사용할 시스템 아키텍쳐를 그렸다!
우리 팀은 백엔드 개발과 함께 프론트엔드도 개발할 계획인데, 프론트엔드는 백엔드의 기능들을 확인하기 위한 도구 정도로만 사용하려고 한다.
그래서 프론트엔드는 쉽고 빠르게 배포를 진행하기 위해 Vercel을 사용할 예정이다.
그리고 그 외 백엔드에서 다루는 내용들은 AWS를 사용하여 배포하려고 한다.
우선은 EC2에서 도커를 통해 스프링 어플리케이션을 실행하려고 하고, 여기에 부하 분산과 무중단 배포를 위해 ALB와 오토스케일링을 추가할 것이다.
우리 서비스에서는 캐싱과 분산 락을 위해 레디스를 사용할 것이기 때문에, EC2 서버를 통해 도커로 레디스를 띄울 예정이다.
DB는 RDS를 통해 MySQL을 사용하고, 이와 더불어 채팅 내용을 저장하기 위해 MongoDB Atlas를 사용하려고 한다.
추가로 엘라스틱서치를 도입하게 되면, 이 내용 또한 EC2 서버에서 도커를 통해 엘라스틱서치를 실행하려고 한다.
AWS에서도 OpenSearch라는 같은 기능을 하는 서비스를 지원하기는 하지만, 우리는 검색 기능 외에도 로깅 기능을 사용하려 하기 때문에 AWS 서비스보다는 엘라스틱서치를 사용하기로 결정하였다.
우리의 최종 아키텍처는 위와 같다.
이후에는 본격적으로 V3 개발을 시작하였는데, 오늘은 DB에서 위치 기반 조회를 하는 내용들을 구현하기 시작했다.
MySQL에서는 위치 정보를 저장하는 Spatial을 지원하기 때문에, 이와 관련된 설정을 진행하고,
하버사인 공식으로 실제 거리를 계산하는 GeometryUtil 클래스를 생성하였다.
이 클래스를 통해서 현재 위치에서 원하는 방향, 원하는 거리만큼 떨어져있는 지점의 좌표를 계산할 수 있고, 두 좌표 간의 거리를 조회할 수도 있다.
MySQL에서는 MBRContains(ST_LINESTRINGFROMTEXT(...), ...)로 공간 데이터의 R-Tree 인덱스로 특정 영역 내에 포함되는 포인트 데이터를 검색할 수 있다.
그래서 위 하버사인 공식으로 사용자 위치 중심 5km 떨어져있는 북동쪽 좌표와 남서쪽 좌표를 계산하고,
이 좌표를 대각선으로 하는 사각형 범위로 모임을 조회하도록 구현하였다.
사실 이렇게 구현하면 원형으로 5km 내에 있는 모임들을 정확하게 조회하지는 않게 된다.
정확히 5km를 조회하기 위해서는 원을 감싸는 가장 작은 사각형으로 조회한 뒤, 서비스단에서 실제 거리 차가 5km인지 계산하고, 필터링하는 과정을 거쳐야 한다.
하지만, 내가 생각하기에 우리 서비스에서 중요한 것은 정확히 원형 5km를 계산하는 것이 아니라 판단하였다.
그래서 해당 부분에 대해 추가 로직을 작성하지는 않기로 결정하였다.
우리 팀이 작성한 코드는 깃허브를 통해 업로드해두었다.
GitHub 보러가기
🙃 오늘의 느낀점
기능 고도화를 시작하니 확실히 기능을 구현하는 것이 어려워지기 시작했다.
자료조사를 진행하면서 많이 찾아봤다고 생각했지만, 실제 구현을 시작하니 여전히 헷갈리고 어려운 부분들이 많았고, 또 다르게 구현할 수 있는 방법들이 눈에 보이고 있다.
기능 고도화인 만큼 이런 저런 방법들을 많이 찾아보면서 진행해봐야겠다.
