주식회사 사리추가의 최종프로젝트 1차 발표 후기
팀원
조혜연
이현경
박해리
전창민
임수영
발표 준비 : 기술적 의사 결정 & 트러블 슈팅
- 전 팀원이 회의에 참여를 하면서 프로젝트 진행 사항과 방향에 대한 고민을 하고, 진심으로 참여하여 정확한 이해와 적절하게 사용을 위해 노력함.
- 코드 변수명을 카멜 케이스로 통일했으며, 각 기능별 명칭에 대해 통일성을 유지할 수 있도록 몇 차례 회의를 거쳤고, 그 회의 결과를 준수함.
- 특히 깃 관리에 있어 브랜치 분리를 잘했고, 정기적으로 진행된, 꾸준한 리뷰와 PR을 통해 충돌을 예방하려고 노력함.
- 카테고리 구현 : 하위 카테고리를 구현하기로 결정했을 당시 셀프참조 카테고리로 구성할 것인지, 하위 카테고리를 만들어서 해결할 것인지에 대한 고민이 있었고, 셀프참조 카테고리를 구현할 경우, 무한정 늘어날 수 있고, 이는 셀렉트 쿼리가 많이 발생할 수 있기 때문에 비효율적이라고 판단하여 하위 카테고리로 구성하도록 결정함.
- 로그아웃을 레디스를 사용한 이유 : 리프레시 토큰을 통해 로그아웃 구현 시 장점이 있고, 읽고 쓰기가 MySQL 보다 훨씬 빠른 속도를 자랑하기 때문에 사용하도록 결정함.
- 백 오피스의 생성 : 서버와 백오피스 분리를 할 것인지, 분리하지 않을 것인지에 대한 고민이 있었고, 보안 이슈를 고려해 분리하도록 결정함. 결정 시에도 관리자를 어떻게 지정할 것인지, 그리고 관리자의 권한을 어떻게 부여할 것인지에 대한 고민이 있었으며 이를 멘토링과 의사결정으로 해결.
- OAuth 로그인만 구현한 이유 : 일반 로그인의 경우, DB 관리가 쉽지 않고, 비용적인 측면에서 과도한 비용이 발생할 수 있기때문에 지양함.
- 마감기한의 설정 : 스케줄링을 사용하지 않고, if문을 통해 해결했으며 이는, 스케줄링을 사용할 경우 앞으로 데이터가 쌓여 나간다면 차차 시간이 밀려 언젠간 시간이 밀리는 현상이 발생할 수 있고, 마감기한처럼 시간을 준수해야 하는 기능에 알맞지 않을 것이라고 여겨졌기 때문임.
- 채팅 내역 보관기간 설정 : 채팅이 주된 목적이 아니고 공모전을 위한 간단한 채팅정도가 목적이기 때문에 채팅 내역을 영구적으로 보관하는 방법(Redis + Mysql 두 곳에 채팅 내역을 저장) 보다는 Redis에 일정기간에 보관하여 저장하는 방법으로 설계하기로 결정하였다. ( 보관 기간 : 60일 )
발표 후 피드백
👉 마감기한의 설정 : 스케줄링을 사용하지 않고, if문을 통해 해결했으며 이는, 스케줄링을 사용할 경우 앞으로 데이터가 쌓여 나간다면 차차 시간이 밀려 언젠간 시간이 밀리는 현상이 발생할 수 있고, 마감기한처럼 시간을 준수해야 하는 기능에 알맞지 않을 것이라고 여겨졌기 때문임.
이넘 필드를 사용하고 있다고 하더라도, 결국 스케줄러의 도움은 필요할 것이다. 또한, 많은 공고가 쌓여 있을 경우, 현재 채용중인 공고를 띄우고자 하면 몇 만개 대상으로 비교문 쿼리를 날려야 한다. 이는 쿼리 수행시간이 길어지고, 부하가 과중될 것이다.
피드백에 대한 개선 안건
테이블 2개로 나누기 위해서 스케줄러를 사용한다는 전제가 필요하며 첫번째 테이블을 새로 생성된 공모전과 마감기한이 도래하지 않은 공모전의 정보를 담도록 구현한 다음, 스케줄러를 이용해서 일정 시간이 도래하면 다른 테이블로 정보를 이동할 수 있도록 상태 코드 변경을 한다.
마감 기한이 지난 공모전을 모으는 두번째 테이블을 두고, 그 테이블 내에서 정보를 찾아서 가져올 수 있도록 한다.
개선 안건에 대한 튜터님 피드백
- 스케쥴러를 이용한 호출은 필요할 것이고, 이를 통해 Status가 업데이트를 할 수 있도록 할 수 있게 구현하는 것을 제안(Scheduler/Spring batch).
- 데이터가 많아 지는 것을 걱정한다면 차차 sharding/partitioning하는 방법을 선택.
- 오래된 DB를 일정 기간이 지나면 다른 테이블로 넘어갈 수 있도록 구현할 수도 있기 때문에 염려 사항이 되지 않음.
👉 채팅 내역 보관기간 설정 : 채팅이 주된 목적이 아니고 공모전을 위한 간단한 채팅정도가 목적이기 때문에 채팅 내역을 영구적으로 보관하는 방법(Redis + Mysql 두 곳에 채팅 내역을 저장) 보다는 Redis에 일정기간에 보관하여 저장하는 방법으로 설계하기로 결정하였다. ( 보관 기간 : 60일 )
지정해둔 보관기간이 너무 길고, 그로 인해 용량 부족의 문제에 직면할 수 있다. 레디스 저장 공간을 늘리기 위해서 서버를 닫았다 연다는 것도 무의미하고, 비효율적이다. 저장 공간이 부족해졌을 때 어떻게 처리하려는 생각 갖고 있는가?
피드백에 대한 개선 안건
레디스에 10분 정도 설정값을 두고 저장해두는 것과 함께 MySQL도 저장하는 방법. 스케줄러를 통해 MySQL에 저장된 데이터가 일정 기간을 두고 삭제될 수 있도록 구현할 수 있는가?
개선 안건에 대한 튜터님 피드백
- 60일이 정말 긴 것일까? 예측된 데이터를 바탕으로 레디스의 보관 문제를 발생하지 않을 수도 있다.
- 그러나 이 예측된 데이터를 바탕으로 판단하더라도 레디스의 보관 문제가 발생할 수 있다고 판단되었을 경우, DB로 백업할 수 있게 개선할 수 있음을 피력한다.
- 데이터를 캐싱해서 사용하는 방법으로 레디스를 활용할 것인가 또는, 저장 공간으로 사용을 할 것인가를 선택할 수 있을 것이다.
- 저장 가능 기간을 점진적으로 줄여 나가는 방법을 선택할 수 있다.
- 휘발성 메모리란 것은 맞지만, 레디스를 내린다고 해서 저장된 데이터가 날아가는 것은 아니다.
전달받은 참고자료
https://hoooon-s.tistory.com/25
https://redis.io/docs/management/persistence/
