SA : https://docs.google.com/spreadsheets/d/1JBQ1iAl9BINJq8oehd-nAWLhO557RTj0O0C3cUAFJQA/edit#gid=0
📌 2022. 11.04 ~ 2022. 12.15
| 사용기술 | 기술설명 |
|---|---|
| CloudFront | 사용자에게 제공되는 정적 컨텐츠의 전송 속도를 높이고 HTTPS를 적용시키기 위해 사용되었다. |
| Tanstack-query | 캐싱, 에러 핸들링(예외 처리), 코드 길이 단축 및 가독성 등의 편의성과 효율적인 비동기 처리를 위해 사용하였다. |
| Recoil | 비교적 가벼운 데이터를 전역적으로 관리하기 위하여 러닝커브가 낮고, 코드길이를 단축할 수있어서 사용하였다. |
| 카카오 지도/주소 API | 매물 상담과 발품 기록의 주소를 단순 텍스트로 기입하는 것이 아닌, API를 활용하여 정확한 주소와 지도상의 위치를 표기하기 위해 사용하였다. |
| @toast-ui/react-editor | 사용자가 이미지와 텍스트를 원하는데로 편집하여 게시글을 구성할 수 있도록 사용하였다.메뉴한글지원 유무, 이미지 지원 유무, XSS 보안취약점 강화 등의 사항을 고려하여 결정하였다. |
| Swiper | 이미지 활용이 많은 프로젝트의 특성상 UI/UX 개선과 성능 향상을 위해 사용하였다. |
| Amazon RDS | db에 저장하는 데이터들을 정형화하고 테이블 간 관계를 중점적으로 보기 위해 사용했다. |
| elastic beanstalk | elastic beanstalk을 사용하면 각 인프라에 대해 자세히 알지 못해도 AWS 클라우드에서 애플리케이션을 신속하게 배포하고 관리할 수 있다. 우리 서비스 같은 경우 RDS(mysql), Elasticache(redis), load balancer, auto scaling, cloud watch, lambda 등 aws의 여러 서비스를 사용해서 아키텍처를 구성할 예정이다. 각 서비스별 복잡한 설정 과정을 건너뛰고 손쉽게 연동하고 서버를 배포할 수 있기 때문에 사용하기로 결정했다 |
| load balancer, Auto Scaling | Auto Scaling을 사용하면 트래픽이 과도하게 많아질 때 서버를 자동으로 증설해준다. 병목 지점에 도달했을 때 ELB를 사용하면 접근을 여러 대의 EC2 인스턴스로 분산할 수 있다. 인스턴스를 분산함으로써 부하를 분산할 수 있다. 또한 1대의 인스턴스에 에러가 발생해도 다른 인스턴스에서 트래픽을 처리할 수 있기 때문에 가용성이 보장되고 예기치 않은 트래픽 증가에 대비하기 위해서 적용하게 되었다. |
| queryDsl | HQL(Hibernate Query Language) 쿼리를 타입에 안전한 방식으로 실행하기 위해 사용한다. HQL 쿼리를 작성하다보면 String 연결을 이용하게 되고, 결과적으로 읽기 어려운 코드를 만든다. String을 이용해서 도메인 타입과 프로퍼티를 참조하다 보면 오타 등으로 잘못된 참조를 할 수 있다. 도메인 변경이 직접적으로 쿼리에 반영되고 쿼리 작성과정에서 코드 자동완성을 사용함으로써 더 빠르고 안전하게 만들 수 있기 때문에 사용하기로 결정했다. |
| lambda | • 이미지 리사이징 목적 : 우리 서비스 같은 경우에 각 매물당 최대 30장의 이미지가 들어갈 수 있다. 원본 크기의 이미지를 그대로 불러오게 되면 고화질 이미지일수록 이미지 처리 속도가 길어지게 된다. 또한 이미지 생성과 삭제가 많아질수록 이미지 작업에 따른 비용도 늘어난다. 고화질 사진을 썸네일에 그대로 사용할 경우 화질이 깨지는 현상이 발생한다. 따라서 사용자가 S3에 업로드한 사진을 썸네일 크기에 맞춰 리사이징하면 화질이 깨지는 현상이 해결되고, 이미지 작업에 따른 비용이 감소된다. |
| github action | 짧은 개발 기간상 템플릿이 많고 환경 구축이 쉬운 시스템을 사용하는 게 맞다고 생각했다. 일반적으로 많이 사용되는 CI/CD 서비스인 Jenkins와 github action을 두고 봤을때, github action은 별도의 서버 설치가 필요 없고 github 마켓 플레이스를 통해 workflow 정보를 쉽게 확인할 수 있으므로 비교적 Jenkins에 비해 처음 CI/CD를 구축하는 사람 입장에서 접근하고 환경 구축하기가 쉽다고 판단했다. |
- 공인중개사와의 부동산 관련문서 해석 상담 요청
- 상담 내용에 있는 주소 정보를 카카오맵 마커로 시각화
- 의뢰인의 상담 목록 조회 및 검색 기능
- 상담에 대한 만족도 표현 가능
- 공인중개사 프로필 수정 (닉네임, 프로필 사진, 소개메세지)
- 공인중개사가 상담했던 의뢰 목록을 마이페이지에서 무한스크롤로 조회 가능
- 관리자 계정 별도 운영 / 인증 메일 발송
예시주소입니다. 실제와 무관함을 알려드립니다.
| 1. 일반회원가입 및 동시로그인 | 2. 발품기록 | 3. 검색 및 목록조회 |
|---|---|---|
 |
 |
 |
| 4. 상담신청 | 5. 캐로셀 및 목록 조회 | 6. 마커 클릭시 상세페이지 모달 |
 |
 |
 |
| 7. 공인중개사 회원가입 | 8. 인증되지 않은 접근 | 9. 관리자계정 승인과정 |
 |
 |
 |
| 10. 거부된 아이디 접근 | 11. 공인중개사 답변달기 | 12. 일반회원 답변확인 |
 |
 |
 |
| 13. 승인 메일 안내 |
|---|
 |
✔️ 프론트단에서 이미지 압축하여 서버로 전송
문제상황
1. 백엔드에서 이미지 리사이징 기능구현이 준비되지 않은 상황
2. 이미지를 30장씩 주고 받아야 하는 상황에서 딜레이로 인한 사용자의 불편사항 발생 우려
3. 사용자가 과도한 크기의 이미지파일을 전송할 상황 방지
의견 조율
1. 프로트엔드 인원 3명이 모두 사용하여야하기 때문에 로직이 간단한 라이브러리 적용
2. 이미지가 깨지거나, 잘리는 등의 상황을 최대한 방지
의견 결정
1. browser-image-compression 이라는 라이브러리를 사용하기로 결정
2. 압축 후 반환되는 blob 파일을 이미지 깨짐이나, 짤림을 방지하기 위해 안전한 문자로(Base64)로 바꿔서 서버로 보내기로 결정
개선 결과
-
개선 전
- 사용자가 휴대폰의 사진을 업로드한다고 가정하고 테스트했을때 대략 70MB ~ 80MB의 사진을 백엔드로 보내게 된다.
- 이때 Request 지연시간만 6s ~ 8s 가량이 걸리는 것으로 확인되었고, Response 지연시간은 15s ~ 25s 정도로 확인되었다.
-
개선 후
- 파일 압축 적용 후 파일용량은 2.5MB ~ 3MB 정도로 압축되었다.
- Request 지연시간은 200ms ~ 500ms 로 대폭 감소하였고, Response 지연시간도 2s ~ 3s로 줄어들었다.
남은과제
30장을 한꺼번에 보내다보니 여전히 지연시간이 긴 편이라서, 첨부와 동시에 미리 한장씩 서버로 보내고 응답을 받아 미리보기를 구현하면 훨씬 빠르게 될 것 같다.
✔️ 리사이징으로 썸네일 이미지 생성
요구사항
한번의 Request를 통해 최대 30장 이상의 S3에 요금 부담 절충안 필요
선택지
1안) 여러 API로 분할하여 유저가 필요시에만 해당 URL을 통해 이미지를 업로드 할 수 있게 함
2안) 클라이언트에서 이미지를 압축해서 전달해주기 + S3에 이미지가 업로드 될때마다 serverless 프레임 워크를 사용해 S3요금 절감함
의견 조율
프로젝트의 특성상 많은 이미지 데이터를 주고 받아야함과 동시에 많은 요금이 부가될 것을 전망하여 AWS lambda를 도입해 serverless 프레임 워크를 사용하기로 함
의견 결정
AWS Lambda를 사용하여 S3 bucket을 분리하였음, 리사이징된 썸네일 사진과 원본을 따로 저장하고 Lambda에 cloud watch를 통해 이미지 데이터의 송수신을 수시로 모니터링하기로 함
✔️ 이메일 Sender 로딩 성능 개선
요구사항
공인중개사 회원 가입 승인시 java email sender api로 이메일을 보낼 때 대기 시간이 김
선택지
1안) 동보 발송 형태 (connection을 개발자가 직접 연 뒤에 보낼 내용을 한번에 전송하는 방식)
2안) 비동기 실행
의견 조율
속도 측면에서 ‘동보 발송’ 형태는 성능 개선의 부분에 있어 좋지만 대상자가 많아 질 수록 스팸처리 되는 부분인 단점이 있을 뿐더러 현 프로젝트에 있어서 다른 내용을 각각의 인원에게 보내야 하는 경우가 아니라고 판단해 1안 보다 2안을 채택하기로 함
의견 결정
멀티 쓰레드로 비동기 환경을 구성해 이메일 전송하는 로직과 사용자에게 응답을 보내는 로직을 비동기 실행
결과
12.22s가량 소요되었던 응답시간을 12ms로 감소시킴
✔️ Query문 검색 기능 성능 개선 중
요구사항
유저가 최근에 검색했던 검색어 및 자동완성 기능 요구
선택지
1안) 새로운 Entity를 생성해 DB에 검색했었던 keyword를 저장하고 자동으로 불러오기
2안) Querydsl 과 fulltext search로 개선
의견 조율
배포되어있는 검색 기능 부분에서 속도 개선 위주로 생각해 JPA를 사용했었지만 동적 SQL을 사용해 다양한 기능을 사용해 유저의 서비스 개선 고려
의견 결정
현재 JPA Query DSL을 환경설정 후 동적 SQL을 사용하여 유저의 서비스를 위한 다양한 시도 중
| 조병민 | 김성욱 | 김하나 | 장경원 | 조정우 | 정규재 | 손하영 |
|---|---|---|---|---|---|---|
| FE(팀장) | FE | FE | BE(부팀장) | BE | BE | Designer |
| 🔗 | 🔗 | 🔗 | 🔗 | 🔗 | 🔗 |
