날씨 알리미 : "오늘 오후 8시에 비가 오니 우산을 챙겨요!"

사용자가 미리 설정한 날씨 조건을 충족하면 알림을 보내주는 서비스입니다.(ex. "오늘 오후에 비가 오니까 우산을 챙겨가세요")A4 - 27 (3)외부 API 활용 (기상청 공공API)스레드를 할용한 비동기 처리메시지큐 활용SpringBatch를 활용한 배치 작업체계적

알림을 더 빠르게 생성하기 위해 다양한 부분으로 고민했습니다. 일단 배치를 통해 DB와 캐시에 미리 데이터를 불러놓아 알림 생성 시 날씨API 요청을 할 필요없게 만들었습니다. 그리고 알림메시지를 캐싱해놓음으로써 성능을 237% 개선했고, 비동기적으로 알림을 생성하는

이 서비스는 매 10분마다 알림메시지를 생성해 유저들에게 보냅니다. 메시지를 생성하는 스레드와 사용자에게 메시지를 전송하는 스레드를 구분하는 게 작업도 분리되고 빠를 것이라고 생각해, 메시지큐를 사용했습니다. 메시지큐 엔진을 사용할 수도 있겠지만, 앱서버 내에 직접 빈

SpringBatch에선 ItemReader, ItemProcessor, ItemWriter을 사용해 배치처리를 chunkSize 단위로 수행합니다. 그런데 으레 사용되는 방식과는 다른 구현체가 필요해져 ItemWriter를 직접 구현한 커스텀 클래스를 만들어 사용했습

이 서비스는 공공API로부터 주기적으로 날씨 데이터를 얻어와야 합니다. 그런데 공공API 서버에 문제가 있거나 간헐적으로 문제가 발생해 응답이 오지 않는 경우에 대비해야한다고 생각되었습니다. 그래서 특정 시간 동안 응답이 오지 않으면 재시도하는 로직과 최대 재시도 횟수

모킹과 TDD, BDD로 유닛 테스트를 실행했음은 물론이고, @ParameterizedTest를 적극 활용해 다양한 시나리오의 테스트를 1개의 테스트 메서드로 테스트해 중복 코드를 줄이고 테스트 코드 관리를 쉽게 했습니다. 🔗 다양한 조건별로 다르게 생성되는 비 알

실제 DB에 저장된 걸 확인해야하는 테스트에선 @Transactional을 적용하지 않아, 테스트 코드에서 저장된 엔티티를 지우는 rollback 과정이 필요했습니다. h2같은 인메모리 테스트 DB를 쓰면 지울 필요가 없겠지만, 실제 DB로도 테스트 하게 될 수도 있을

자주 쓰이는 요청의 Full-table 스캔을 막기 위해 where절에 쓰이는 칼럼에 복합인덱스를 적용하고, 실행계획을 보며 인덱스를 타는지 확인하며 시행착오를 거쳤습니다. 10만건의 더미데이터를 만들어 테스트 한 결과, 수행시간이 0.04초에서 0.00041초로 줄었

리스트 데이터를 조회해 forEach처리하는 로직에서 1개의 조회 쿼리 이외에 N개의 조회 쿼리가 발행되는 문제가 있었습니다. 디버그모드로 확인한 결과, 롤백을 위해 사용했던 deleteAll 메서드가 delete를 N번 실행하는 게 문제였습니다. 각 delete는 해

saveAll 메서드를 사용하니 N개의 Insert문이 발생했습니다. 이는 Id가 Auto Increment인 엔티티의 Insert를 수행할 때 발생하는 문제임을 인지했고, Id가 Auto Increment가 아닌 엔티티에서라도 Batch Insert가 나가도록 설정했

프로젝트를 진행하다보면 엔티티의 필드가 기본형이 아닌 커스텀한 객체가 될 때가 있습니다. 그게 엔티티를 관리하거나 비지니스 코드를 작성하기 쉽기 때문에 그렇게 하는 경우가 많았습니다. 예를 들면 아래의 '날씨 데이터 타입'이 있습니다. enum 인스턴스나 커스텀 클래스

전 혼자 개발했지만, 미래에 원활한 팀작업을 위해 깃 브랜치 관리를 알아두어야한다고 생각했습니다. 그래서 git flow 브랜치 관리전략에 따라 기능들을 추가해나갔습니다. git flow는 여러명의 개발자가 병렬적으로 개발하는 내용을 간단하게 머지할 수 있는 깃 브랜치