실전 프로젝트 22, 23일 회고(10주차 WIL)

SaGo_MunGcci·2022년 9월 18일

Practice Project WIL

항해99 WIL

목록 보기

5/6

Week do list

⦁ 실시간 채팅 기능 구현

⦁ 중간 발표

⦁ 중간 발표 후 팀 회의

WIL(이번주까지 사용한 기술 회고)

AWS EC2

서비스 배포 서버이다. 서비스 배포 서버를 AWS EC2를 선택한 이유는 배포의 경험을 해봐야 하기 때문이다. 배포의 경험이 없는 입문자인 우리에게 제공되는 정보가 많고 또한 AWS에서 제공해주는 EC2 뿐만아니라 RDS, S3버킷 redis, docker 등 AWS플랫폼을 이용하면 한번에 적용및 관리할 수 있다
무엇보다 1년 프리티어 무료부분이 너무 장점이었다.(잘못 사용하면 장점은 아니다.)
마지막으로 모니터링을 통해서 서버상태를 볼 수 잇다는 점도 우리에게 유리하다는 판단을 했다.
웹호스팅이 아닌 우리가 가지고 있는 역량 및 시간대비 배포의 효용성이 높다고 판단한것이다.

AWS RDS(MySQL)

RDS는 AWS에서 제공해주는 DB이다. RDS자체는 위의 AWS와 선택이유가 같기 때문에 MySQL에 대해서 회고 하고 싶다.

MySQL 이전 작성글 참고 : https://velog.io/@sago_mungcci/SQL%EC%9D%B4%EB%9E%80

AWS S3 bucket

AWS는 실시간으로 파일을 저장할 수 있는 서버(저장소)이다. 위에 MySQL이 텍스트만 저장할 수 있는 특성이 있기때문에 실제로는 파일을 MySQL에 저장할 수는 없다.
따라서 실제로 파일을 저장하기 위해서는 서버에 저장해야 하는데, 만약 서비스하는 서버내부에 저장한다면, 오류로 인해 서버의 데이터가 날라가거나, 개발자의 실수로 파일을 저장한 폴더를 삭제했을때 복구가 어렵다
또한 확장성에도 문제가 발생한다. 만약 서비스하는 서버(주 서버)에만 파일을 저장해 놓는다면, 세컨더리 서버에는 해당 파일이 없어 파일을 불러올 수가 없다. 따라서 똑같은 파일을 세컨더리 서버에도 똑같이 저장해야 하는 이중 작업을 진행해야 한다.
이것은 단순히 프로젝트의 규모가 작을때는 어느정도 가능하지만 중,대규모 프로젝트일때는 파일의 양은 엄청 날 것이고 그만큼 서버의 부담이 늘어날 것이다. 따라서 서버의 응답시간이 느려질 가능성이 매우 크다.
무중단 배포시에는 프라이머리 서버, 세컨더리 서버가 필수인데, 위와 같은 방법으로 프라이머리 서버 따로 세컨더리 서버 따로 파일업로드를 할 수 없다.
우리가 제공하려는 서비스는 경매이다. 경매는 실시간성을 요구하고 무중단 배포가 가능한 빠르고 정확하게 배포되어 고가용성을 띄워야한다.
그렇기 때문에 이런 파일을 저장하는 서버가 필요하고 마침 AWS에서 S3라는 버킷을 제공해준다.
이러한 이유로 S3를 사용하게 되었다.

스프링 및 JWT

시리즈 참고 : https://velog.io/@sago_mungcci/series/%EC%8A%A4%ED%94%84%EB%A7%81

socket(Stomp)

채팅 설계 설명 : https://velog.io/@sago_mungcci/%EC%8B%A4%EC%A0%84-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-20%EC%9D%BC-%ED%9A%8C%EA%B3%A0

Stomp 설명 : https://velog.io/@sago_mungcci/%EC%8B%A4%EC%A0%84-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-1415%EC%9D%BC%EC%B0%A8-%ED%9A%8C%EA%B3%A0

Retrospection

중간 발표 주요 전문

땅땅 피드백 (Backend)
9/17

Q.레포를 보면서 컨벤션 잘 지키고 있는지 궁금
1. 다른 커밋들이 많이 보였다
어떻게 팀내에서 개발하자 정하자 라고 했는지 궁금

답신 :

컨벤셔널 커밋이란게 강제적인것은 없지만 가능한 통일할 수 있는 쪽으로 한번 알아보아라.
다른 조에도 말씀 드렸던 “프리 커밋”을 쓰면 오류를 잡는데 도움이 된다.

Q. 메인 자바를 들어가보면 페이지네이션이 눈에 띄엇다. 데이터를 조회할 때 이뤄져야한다. 따로 뺀 이유가 있는지?

->저희는 기능별로 구분하는것이 조금 더 빨리 오류수정이 가능할 것이라 판단하여 따로 구분을 함.

답신 : 페이지네이션은 각 도메인 별로 들어가는 것이 나을 수도 있겟다 (멘토님의 의견) 도메인 별로 페이징을 하는것이 좋아보인다.

Q. 컨트롤러들을 보면 데이터 리퀘스트 리스폰스 하는 것을 보면 많이 다르다. 각자 다르게 했구나 라는 것을 느껴진다.

답신 : PR올릴 때 코드를 조금 더 통일 성 있게 작성하면 좋겠다.

Q. ViewCnt의 설명 요청
-> 사용자가 상세페이지를 조회했을 때 viewcount를 세어주는 단순한 메서드 입니다.

답신 : AOP로 빼주면 좋겠다.

답신 : 깃헙(소스트리)브랜치 명 수정했으면 좋겠다. 각자 작동하고 메인으로 놓고 누가 어떤것을 햇다보다 어떤 기능을 했다를 브랜치에 더 나타날 수 있게 하면 좋겠다

시스템 설계

중간 발표 후 우리조는 팀원들이 다시 모여서 중간 발표 회고 회의를 했다. 백앤드만 피드백을 정리하면 위의 피드백과 동시에 각기능에 대한 설계가 부족했다는 결론이 났다.

예를들어 우리는 Stomp를 사용해서 채팅이라는 기능 구현에만 집중했다면, 피드백해주신 내용은 전체 우리 프로젝트에서 채팅이 어떻게 시스템 적으로 설계 되었고, 이러한 설계대로 기능이 구현되었지만 좀 더 효율적인 방안을 생각 못했다는 것이다.

redis와 cache 시스템또한 구현하면서 기능에만 초점이 맞추어져있어서 db에 한번 접근하면 cache에도 저장 되고 그다음 부터는 cache 내용을 빠르게 가져올 수 있기 때문에 사용한다.

그러나 이것은 시스템 설계를 공부하고 보니 반쪽짜리 답변이 된다는 것을 알게되었다. 단순히 기능면에서만 보면 옳바른 정의라고 할 수있다. 그러나 전체 시스템적인 설계에서 보면 그래서 redis,cache를 써서 어떤 효율성이 발생하는가?(프로젝트 전체에서 redis가 어떤 역할을 하는가?) 라고 질문이 오면 답을 할 수가 없다.

즉 전체 시스템적인 설계에서 보면 그래서 redis,cache를 써서 어떤 효율성이 발생하는가?에 기능적인 정의만 답한다면 우리 프로젝트에 redis와 같은 cache를 사용하면 좋다라는 답변인것이지 왜 redis,cache시스템이 있는지는 애매한 부분이있다.

이것에 대해서 생각하면서 정말 많이 배우게 되었다.
redis는 in-memory기반의 저장시스템(cache)이기 때문에 서버를 닫거나 꺼진다면 memory에 있는 데이터는 날라가 버린다.

응답속도와 안정성이 트레이드 오프(trade-off)되는 것이다.

멘토님께서 질문하신 부분은 바로 이것이지 않을까 싶다. 경매라는 서비스는 실시간으로 사용자가 가격을 제시하면 경매물품의 가격이 변한다. 그리고 하나의 데이터의 변경은 그 데이터가 저장된 테이블 전체에 영향을 미친다. 따라서 redis를 사용함에 있어서 클라이언트-서버 통신에 어떠한 이점 혹은 영향이 있는것이냐?라고 물어보신것이다.

redis의 기능상의 이점을 설명하는 동시에 우리의 프로젝트가 경매이기때문에 사용자는 실시간으로 데이터를 안정적이고도 빠르게 볼수 있어서 경매를 집중할 수 있다.라고 말씀드렸어야 했던것이다.
(redis에는 embed와 AWS redis 서버가 있는데 수평적 확장을 위해서는 embeded redis보다 AWS redis서버를 사용하는 것이 훨씬 좋을 것이다.)
백앤드는 백앤드 로직만 생각하고 구현되면 끝이 아니라 우리가 작성한 로직과 기능으로 인해서 서버에 부담을 줄이면 결과적으로 시스템 전체가 어떻게 기능할 것인지를 생각하게 되었다. 단순히 효율적으로 실행되면 끝이 아니라, 어떻게 효율적으로 시스템이 변경되었는지 안다면 프로젝트를 확장할때 새로운 기술이 우리 현재 프로젝트에 적용 할 수 있을지 없을지, 할 수있다면 어떻게 적용할 수 있을지 그로인해서 우리 시스템이 얼마나 효율적으로 작동할 수 있고 최종적으로는 사용자에게 얼마나 도움이 되는 지 까지판단할 수 있어야 하는 것이다.