💪프로젝트에서 사용한 혹은 사용 예정인 기술 스택은 무엇인가요?

이번 주

백엔드

• Firebase Cloud Messaging - API 문서 공유
• CloudFront - 이미지 캐시
• RDS - 배포

예정

백엔드

• ElastiCache - Redis 용
• RDS - DB
• ECS - Docker
• JMeter
• Grafana

💪이번 주 진행상황

• API 개발 배포
  • API endpoint: api.training-diary.co.kr
  • Swagger 문서: https://api.training-diary.co.kr/swagger-ui/index.html
  • 회원 → 100%
  • 트레이너 → 100%
  • 운동타입 → 100%
  • 운동기록 → 100%
  • 트레이너 코멘트 → 100%
  • 예약 → 100%
  • PT계약 → 100%
  • 식단 → 100%
  • 알림 → 100%

백엔드 필요한 API는 모두 완성했습니다, 현재 QA 및 리팩토링 진행중이고요, 프로젝트 설정에 있는 최적화 및 인프라 쪽을 신경 쓰고 있습니다.

💪이번 주 트러블 슈팅

• 문제에 대한 한줄 요약(Template)

💪 멘토님께 질문사항

• 지금까지 CSRF 설정에 대해 서버에서는 disable로 한 상태로 진행했습니다. 여러 설정들이 필요하기 때문에 빠른 개발 진행을 위해서였습니다. 지금 시점에 CSRF를 설정해보는 걸 들어가도 괜찮을까요? 다들 어떤 내용인지 정확히 몰라서 공부가 필요하고, 클라이언트 측과 맞춰야할 부분도 있는 것 같습니다.
• 종 모양 (알림이 왔으면 색깔이 변함) → DB에 내가 읽었는지 확인하고 색깔을 바꾸는게 일반적인지 유저가 알림을 읽었는지 판단하는게 유저 DB에 unreadnotification이라는 필드로 다루는지 궁금합니다. 혹시 저희가 설계하는게 잘못 되었는지, 보통은 종 모양 알림 설정은 어떻게 하는지 궁금합니다.
• Docker를 써보면 좋을 것 같습니다. 지금은 EC2에서 직접 jar 파일을 실행시키도록 배포가 되어있습니다. Docker로 만든다면 ECS라는 서비스를 사용하는 게 이상적인 방법인 것 같은데, 그렇게 하려면 ALB(Application Load Balancer)를 무조건 사용해야 하는 것 같습니다. 비용적인 부분에서 ALB를 사용하지 않는 것이 낫다는 생각입니다. 그래도 Docker를 해보고 싶다면, EC2에서 직접 docker 를 실행해서 구성해도 괜찮을까요? 불필요한 오버헤드가 늘어날 것 같은데, 오버헤드가 크지 않다면 구성해보려고 합니다.
• 파일 업로드 시, 업로드 비율을 알려주면 좋을 것 같습니다. 자동으로 퍼센트 응답이 가고 있지 않는 것 같은데, 이런 내용은 어떤 식으로 구현이 되는지 궁금합니다. 별도의 SSE나 웹소켓 기술로 클라이언트에게 알려줘야 하는 걸까요? 혹은 클라이언트가 직접 전송된 비율을 알아내는 방법이 있나요?
• DB용 RDS나 혹은 Redis용 ElasticCache 같은 AWS 서비스들도 있고 그러는데, EC2에 Redis나 DB를 설치해서 실행하는것보다, 따로 서비스들을 구분해서 사용하는게 좋을까요? 현재 저희 프로젝트 규모 봐서는 굳이 안하고, 모두 EC2에다가 다 실행해도 될 듯한데, AWS 서비스들을 적극 사용하는게 좋은 연습일까요? 혹시 좋다면, 지금 저희가 구축을 하는것에 있어서 호의적이시면 고려해보겠습니다.
• 테스트 자료를 만들기 위해 여러 사용자를 sql 쿼리로 넣는 식으로 했습니다. 사용자의 경우 가입하려면 email 인증을 거치는 과정 때문에 sql로 직접 넣었습니다. 다른 샘플 자료들을 넣을 때는 sql을 사용할 수 있고, 직접 api를 호출하는 javascript를 작성할 수도 있을 것 같습니다. 직접 api를 호출해 보는 것이 api 테스트 측면에서도 더 유리할 것 같은데, 그 테스트를 계속 관리하는 비용이 걱정됩니다. sql 스크립트만으로 충분할까요?
• 성능 테스트 같은 경우에:
• 모든 호출에서 JWT 토큰을 검사하기 위해 매번 DB를 호출했습니다. 이것을 간소화하기 위해 사용자를 저장하는 캐시를 도입했습니다. 인메모리에서 더 빠르게 응답할 수 있지만, 한개의 필드가 온전한 내용으로 채워지지 않는 상태가 됩니다. unreadNotification 이라는 사용자에게 확인할 푸시 알림이 있는지 알려주는 필드입니다. 만약 설계를 수정한다면, notification의 존재 여부를 알려주는 필드를 분리하는 게 낫겠다는 생각입니다만, 지금 상황에서 해당 필드(unreadNotification)에 대한 true/false 여부를 상관하지 않고, 캐시에 저장하고, 실제 unreadNotification 필드를 사용하는 API(/api/users/info)에서만 (DB에 저장된) 실제값을 캐시에 반영하려고 합니다. 이렇게 되면 온전한 값이 아닌 객체가 캐시에 저장된 상태가 되어서 걱정입니다.