[TIL] 78일차

1. 트러블 슈팅 세션

• 기술용어 습득 -> 개발자 소통
• 프로젝트 진행하면서 익숙한 부분부터 CS 공부(웹 기술) -> 점차 확장
• 트러블 슈팅의 각 요소(도입 이유, 문제 상황, 해결 방안, 의견 조율, 의견 결정) 명확히 제시
  • a를 통해 b의 결과가 나타남
    • a가 무엇이고(개념), 왜 사용 했는지
    • b가 무엇이고, a로 인해 b 이외의 부작용은 없는지
  • 테스트한 내역도 있으면 좋음
• isolation
• 터널비전 피하는 전략
  • 페어 프로그래밍
  • 디버깅 시간 정해놓기
  • 팀원과 공유
• 중간 회고
  • 더 나은 방법은 없었나
• 최종 회고

2. 파이썬 스케줄러

스프링으로 수익률 계산 로직을 고민하던 중에, 현재 파이썬으로 스케줄러를 이용해 짧은 시간마다 갱신하는 방식이 좋지 않을 수 있겠다는 생각이 들었다

 

레디스를 활용한 현재가 정보나, 하루마다 자동으로 추가되어야 하는 일봉 데이터, 그리고 1년마다 갱신되는 재무제표를 제외한 데이터는 사용자의 요청에 따라 파이썬 모듈을 통해 그때그때마다 데이터를 추출하는 것이 나아보였다.

 

사용되지도 않을 수 있는 수많은 데이터를 위해 스케줄러가 열심히 구동되고 있을거란 생각이 들었고, 이런 방식의 구현으로 인해 EC2를 프리티어 이상으로 올렸었는데, 필수적인 부분에서만 스케줄러를 활용해서 같은 자원으로 더 좋은 성능을 만들어 낼 수 있지 않았을까 싶었다.

 

+ 10.21)

멘토링에 관련 사항을 언급했는데, 모듈의 서버나 내 서버가 다운되었을 때를 생각한다면 요청마다 api를 호출하고 db에 저장하지 않는 것은 위험할 수도 있다는 이야기를 들었다. 레디스로 캐싱 계층을 두어 속도를 향상하면 어떤가 하는 의견을 추가로 들었다.

 

3. 스프링 회원 탈퇴

회원 탈퇴 시에 그 사용자가 작성한 글, 댓글, 좋아요, 싫어요 등 관련 엔티티가 다 같이 사라질 때의 상황이다.

 

Post(게시글) 엔티티에 필드로 commentNum, likes, dislikes의 이름으로 누군가 댓글을 추가 및 삭제하거나 추천/비추천을 등록하면 관련된 필드 및 db의 컬럼에 반영하여 갯수를 세고 있는데, 어떤 회원이 탈퇴를 했을 때는 책정되지 않기 때문에 방법이 필요했다.

 

그래서 연관관계로 불러온 comments, likePosts, dislikePosts 리스트의 크기로 갯수를 계산하는 방식을 생각했었는데, 이는 사용 빈도수가 굉장히 높을 게시글 조회 api에서 너무나도 많은 쿼리가 나가 너무 비효율적이라고 생각이 들었다.

 

따라서 누군가 회원탈퇴하는 시점에 Member 엔티티 삭제 전, 그 사용자가 등록한 모든 댓글, 추천, 비추천을 DB에서 select 하고 반복문을 통해 해당되는 게시글의 필드에 미리 반영을 해주었다. 이때는 그 엔티티들이 실제 삭제되는 것은 아니고, 게시글 필드 값만 미리 바뀌는 것이다. 마치 그 사용자가 탈퇴 전 자신이 활동했던 것들을 직접 일일히 원래대로 복구해놓고 탈퇴하는 것과 같은 효과이다.

 

회원탈퇴 api는 그 회원으로써는 사용하는 동안 1번밖에 일어나지 않는 비교적 훨씬 덜 사용되는 api이기 때문에 비효율적인 쿼리들이 나간다고 하더라도 이전 방법보다는 훨씬 나을것으로 판단했다.