WIL(Weekend Ingwang Learned

WIL) 2023-01-16~2023-01-22

김코식 2023. 1. 25. 20:03

이번주 학습 요약

실전 프로젝트

1. MVP 기능 구현

이번주에 back-end의 MVP 기능 구현이 모두 끝났다!

MVP 기능

1. 로그인 / 회원가입

일반 로그인 (Jwt , SpringSecurity 사용)

소셜 로그인 (카카오톡)

 

2. 게시판

게시글 CRUD

댓글 CRUD

대댓글 CRUD

게시글 태그별 조회

인기 게시글 조회

3. 식물 찾아보기

태그별 식물 조회

검색별 식물 조회 (query dsl , Full Text Search)

식물 상세보기

4. 나만의 반려식물 찾기

식집사 테스트

테스트 결과에 따른 성격유형, 추천식물 출력

식집사 가이드

가이드 식물중 선택하여 가이드 식물 성장 (그래프 작성)

5. 식물일지

식물 추가 (물양, 일조량 , 물 주기, 분갈이 주기 등 데이터 저장)

식물 일지 보기 (물 주기, 분갈이 주기 등의 수행 달성도에 따른 그래프 출력) (scheduler 사용)

6. 서버

Https 적용

Swagger 적용

CI/CD (github Action 사용)

 

 

2. 중간 발표

1. 발표 자료

https://www.notion.so/262262a168dd4bbc986259135795331a

 

중간 발표

프로젝트 소개

www.notion.so

2. 질문과 질문에 대한 답변 

무중단 배포를 위하여 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를 이용한 이미지 리사이징 순서
  1. 사용자가 웹페이지에서 이미지를 업로드
  2. 로컬 서버에서 이미지 요청을 받고 S3 버킷 original/ 경로에 업로드
  3. S3에 오브젝트 업로드 이벤트가 발생
  4. S3 트리거가 발생되어 람다 함수 실행
  5. 클라우드 프론트에 훅을 연결시키는것으로 알고 있다
  6. 람다에서 버킷 original/ 에 있는 이미지를 가져오고 이미지 리사이징 작업한뒤 다시 버킷 thumb/ 경로 에 리사 이징된 이미지 업로드
  7. 로컬 서버는 원본과 리사이징 이미지 url을 클라이언트에 응답

Full Text Search 를 위한 솔루션으로 어떤것들을 고려하고 있는지

Elastic Search를 사용하는 것이 성능은 더 좋겠지만 사용법을 따로 익혀야 하기 때문에 MySQL에서 FullText Index를 적용하고 n-gram 인덱싱을 적용하였다. (설정이 더 간단하다)

match 함수를 사용하기 위해 full text search를 구현한 MySQL8DialectCustom 클래스를 생성한뒤

queryRepository에서 querydsl로 작성한 기존 코드를 리펙토링하여 구현

3. 답변에 대한 피드백

 

https://www.notion.so/b005d9c7c9144d3997ca3bf021d8e0ac

중간 발표가 끝났다 . 중간발표 전에는 배포를 했어야만 했는데 일정이 밀리다보니 배포를 못하는 치명적인 실수를 범했다.

멘토님께서 시간안에 기능을 먼저 보여주는 것이 우선이라고 말씀하셨고 그 말에 나도 동의를 한다.

물론 백엔드에서는 기능 구현을 모두 마쳤지만 프론트의 일정을 조율하지 못햇던 나의 잘못이 크다고 생각했다.

앞으로는 좀더 잦은 회의를 통해 서로의 일정을 공유하고 데드라인에 맞춰 가능할만한 작업인지 먼저 생각해 봐야겠다.

 

Back-end에서 앞으로 더 추가할 작업

nginx 사용하여 무중단 배포

image-resizing을 통해 메모리 낭비 최소화

sse 알림기능 추가

refreshToken 구현