데브코스

Boltter 서비스는 익명으로 편지를 주고받을 수 있는 서비스입니다. 작성된 편지는 여러 사람들에게 추천되기 때문에 하나의 편지는 많은 사용자에게 전송될 수 있습니다. 이러한 도메인 규칙에 의해 편지 작성 요청보다 편지를 조회하는 요청이 더 많다고 판단하여, 개발 기간이 종료되었지만 받은 편지 조회 성능을 개선해보고자 합니다.실제 서비스에서는 사용자와 편지를 주고받는 데이터의 양이 적기 때문에 조회 요청에 대한 응답이 빠르게 이루어집니다. 따라서, 테스트를 위한 데이터를 삽입하여 편지 조회 성능을 개선해보도록 하겠습니다.주고받은 내역이 저장된 테이블의 row는 약 380만 건으로 설정하였습니다.다른 팀원이 개발한 파트라 기존 기능을 최대한 유지하며 기능을 개선하였습니다.📌 기존 내용기존에 받은 편지 ..

보틀러 프로젝트에서 알림이 보내지는 경우는 총 6가지입니다.계정 일시정지계정 경고키워드 편지 도착타겟 편지 도착답장 편지 도착키워드지도이 6가지의 기능에서 알림 보내기를 실패했을 때, 해당 기능도 실패해야 하는지에 대해 의문이 들었습니다.알림 전송은 2가지 단계가 존재합니다.알림 저장알림 푸시이때, 알림의 주요사항은 다음과 같습니다.알림 전송에 실패해도, 알림을 호출한 기능에 영향을 주면 안 된다.알림 저장에 실패해도, 알림을 호출한 기능에 영향을 주면 안 된다.알림 푸시에 실패해도, 알림 저장에 영향을 주면 안 된다.알림 푸시 실패포스트맨에서 생각한 비즈니스 로직 상 알림 푸시에 실패하더라도, 알림을 저장하는 데에 영향을 주지 않도록 결정하였습니다.사용자 정지 시, 알림을 요청하는 기능은 다음과 같습니..

이전에 서버가 알 수 없는 이유가 내려가는 상황이 발생해서 이에 대한 방안으로 swapfile을 추가하고 모니터링 서버를 구축하기로 하였습니다. 모니터링을 하기 위해서 Spring Actuator + Prometheus + Grafana를 사용하였습니다.📌 Actuator + Prometheus + Grafana?Actuator서버를 운영하면 서버의 CPU, 메모리, 쓰레드 수 등 다양한 지표가 존재합니다. 그런데 모니터링 툴 마다 측정 방식이 다르다면 교체 시 측정 코드 또한 변경할 수 밖에 없습니다. 이를 위해 마이크로미터가 존재합니다.마이크로미터는 모니터링 툴에서 사용되는 기능들을 추상화하고 각각의 모니터링 툴에 맞는 구현체들을 가지고 있습니다. 스프링에서 이를 손쉽게 사용하는 방법은 Spring..

4차 프로젝트에서 추천 편지나 타겟 편지 등 다양한 알림을 보내야 하는 상황이 있었습니다. 이때 저희는 단순히 알림 페이지 내에서 관리하는 것뿐만 아니라, 사용자에게 푸시 알림을 보내는 방법에 대해 고민하였습니다. 앱이 아닌 웹 환경이므로 어떻게 할지 고민하다가 FCM을 이용하기로 하였습니다.📌 FCM이란?FCM은 Firebase Cloud Messaging으로, 무료로 메시지를 보낼 수 있는 크로스 플랫폼 메시징 솔루션입니다. FCM은 Google의 클라우드 메시징 서비스이고, 토큰을 이용해 사용자를 식별하고 푸시 메시지를 보낼 수 있습니다.📌 어떻게 사용자는 푸시 알림을 받게되는걸까?사용자는 알림을 허용하면 FCM의 고유한 토큰을 발급받습니다. 이때 이 토큰을 이용하여 푸시 알림이 이루어지게 됩니..

데브코스 4차 프로젝트 백엔드팀은 초기에 도메인 주도 설계를 도입하기로 하였습니다. DDD(Domain Driven Design)에서는 유비쿼터스 언어 사용하고, 도메인 모델에 집중하며, 소프트웨어 Entity와 도메인 간 개념을 일치시켜야 한다고 합니다. 하지만 팀원 모두가 DDD에 대해 미숙하고 러닝 커브가 높다고 판단하여 DDD 도입은 하지 않는 방향으로 정해졌습니다.그러다 프론트엔드와 백엔드 간의 도메인 이해도가 다른 부분이 꽤 존재하여, 소통하는 데에 문제가 발생하였습니다. 따라서 기존에 DDD를 하려고 할 때 하려고 했던 이벤트 스토밍을 진행하기로 하였습니다. 저희 팀에서는 프론트팀, 백엔드팀, 디자이너팀이 있는데, 소통 문제를 해결하기 위해 팀들 간의 공통된 이해와 도메인에 대한 깊은 이해를..