TIL) 2023-01-20(실전 프로젝트)
오늘은 내일 있을 중간 발표를 준비했다
사전 질문에 대한 답변
Back - End
무중단 배포를 위하여 Nginx 를 채택한 이유? Reverse Proxy 와 Proxy 의 차이? 왜 AWS Load Balancer (ELB) 를 쓰지 않는지
- 무중단 배포를 위하여 Nginx 를 채택한 이유? nginx는 별도의 인스턴스를 구성할 필요가 없기 때문에 사용
- Reverse Proxy 와 Proxy 의 차이? 프록시 포워드 프록시 서버는 클라이언트 앞에 존재 클라이언트가 서버로 요청할 때 직접 요청하지 않고 먼저 프록시 서버를 통해 요청하는 방식 서버에게 클라이언트가 누구인지 감추는 역할 서버가 응답받은 IP는 포워드 프록시 서버의 IP이기 때문에 클라이언트가 누군지 알 수 없다
리버스 프록시 리버스 프록시 서버는 웹서버 앞에 존재 클라이언트가 프록시 서버를 호출하여 내부망에 있는 서버를 호출하는 방식 리버스 프록시는 서버가 누구인지 감추는 역할 클라이언트는 리버스 프록시 서버를 먼저 호출하게 되기 때문에 실제 서버의 IP를 알 수 없다
- 왜 AWS Load Balancer (ELB) 를 쓰지 않는지 ELB의 경우 별도의 loadBalancer 인스턴스를 생성해야되고 서버가 계속 유지되는동안 비용이 발생 프로젝트의 규모가 크다면 가용성을 위해 ELB를 사용해야하지만 프로젝트 규모가 크지 않기 때문에 nginx의 설정만으로도 대체가 될 것이라고 생각
AWS Lambda 와 이미지 프로세싱을 어떻게 연결할 것인지 전략이 있다면 어떻게?
AWS Lambda 사용 이유
- 단순히 이미지 크기를 조절하는 것은 리소스가 많아질 수록 용량이 늘어나게 되고, 결국 로딩 시간에 영향을 줍니다
- 이미지 리사이징 작업은 CPU와 메모리를 많이 사용하기 때문에 로컬 서버에서 작업을 돌려버리면 다른 사용자의 요청을 못 받는 현상이 생길 수 있다.
- Lambda를 이용해 독립적이 서버에서 함수를 실행시킨다면, 로컬 서버의 부담을 줄일 수 있을 뿐만 아니라 온 디멘드(on-demand)형식이라 쓴 만큼 요금을 지불하기 때문에 항상 컴퓨팅을 실행시키는 자원 낭비를 줄일 수 있다.
- 따라서 Lambda는 서버 관리에 많은 시간과 노력을 쏟지 않으면서 간단한 코드로 실행 가능한 서비스를 만드는 경우에 적합하기 때문에 Lambda를 이용해 이미지 리사이징을 해봐야 겠다고 생각을 하게 되었다.
Lambda를 이용한 이미지 리사이징 순서
- 사용자가 웹페이지에서 이미지를 업로드
- 로컬 서버에서 이미지 요청을 받고 S3 버킷 original/ 경로에 업로드
- S3에 오브젝트 업로드 이벤트가 발생
- S3 트리거가 발생되어 람다 함수 실행
- 클라우드 프론트에 훅을 연결시키는것으로 알고 있다
- 람다에서 버킷 original/ 에 있는 이미지를 가져오고 이미지 리사이징 작업한뒤 다시 버킷 thumb/ 경로 에 리사 이징된 이미지 업로드
- 로컬 서버는 원본과 리사이징 이미지 url을 클라이언트에 응답
- 장점
- (관리) 서버 사양, 개수 등 관리에 필요한 고민 불필요
- (관리) 서버 상태 모니터링 및 Scaling 불필요(Auto Scaling 지원)
- - Auto Scaling : 손쉽게 여러 서비스에서 여러 리소스에 대해 규모 조정을 설정
3. (비용) 밀리 초 단위로 함수를 사용한 만큼만 과금
- (비용) 프리티어일 경우, 1GB 메모리 환경에서 월 100만건, 월 40만 초의 실생시간 무료 제공
- 단점
- (속도) 함수 호출 시 Cold Start 문제로 초기 지연시간 발생
- - AWS EC2에 비해 약 1ms 만큼 지연
- (성능) 러닝타임이 최대 15분 이므로 이를 넘어가는 Task 수행 불가
Full Text Search 를 위한 솔루션으로 어떤것들을 고려하고 있는지
Elastic Search를 사용하는 것이 성능은 더 좋겠지만 사용법을 따로 익혀야 하기 때문에 MySQL에서 FullText Index를 적용하고 n-gram 인덱싱을 적용하였다. (설정이 더 간단하다)
match 함수를 사용하기 위해 full text search를 구현한 MySQL8DialectCustom 클래스를 생성한뒤
queryRepository에서 querydsl로 작성한 기존 코드를 리펙토링하여 구현
오류가 발생했을 때는 공통 Response 를 보내는데 Controller 레벨에서 공통 Response 가 아니라 Service 에서 공통 Response 로 래핑한 이유
질문의 의도를 정확하게 이해하지 못했지만
이해 한대로 말하자면 오류가 발생하는 이유가 여러가지 있기 때문에 이러한 경우의 예외처리를 하려면 서비스단에서 예외를 처리ㅎ해하고 controller에서는 요청에 대한 응답만 보내는 것이 맞다고 생각하여 서비스단에서 처리를 했다
if-else 구문이 많다는 것은 절차적으로 프로그래밍 했다는 의미 즉, Java 를 Native C 처럼 작성했다는 의미, 로직 분기의 기준을 깊은 Service 에 전파하지 말고 프론트 엔드에서 끊는 것이 어떨지
백엔드에 비해 프론트엔드에서 할 일이 많다고 생각을 했고 백엔드에서 정보를 주면 프론트에서 가공할 필요 없이 바로 내보내 주는게 할 일을 줄여주는 것이라고 생각이 들었다.
성능적으로 차이가 많이 난다면 유지보수 기간에 프론트와 상의를 하여 변경할것이다.
발표 자료
https://www.notion.so/262262a168dd4bbc986259135795331a
중간 발표
프로젝트 소개
www.notion.so
중간 발표 마무리 하길
