이번 포스팅에서는 여러 번 반복되는 HTTP 요청을 비동기로 처리해 응답 속도를 단축시키는 과정을 담았습니다.문제이전 포스팅 마지막에서 다뤘던 문제는 반복문 안에서 HTTP 요청을 보내는 것이었습니다. 기존 코드public void preCreateDailyReport(UUID userId, LocalDate startDate, LocalDate endDate) { // 편지 서비스에게 `분석 가능한 편지들` 찾기 위임 List analyzableLetters = letterService.findAnalyzableLettersInRange(userId, startDate, endDate); for (DailyLetters dailyLetters : analyzableLetters) { ..

이전 포스팅에서는 객체들의 책임이 올바르게 할당되지 않았던 문제를 다뤘습니다.그러다 보니 거대한 몬스터 메서드들이 생겨났고, 이로 인해 유지보수와 확장이 어려웠었죠. 이 문제를 해소하기 위해 책임의 재할당을 다뤘었는데요, 이번 포스팅에서도 객체 지향 관점에서 책임의 재할당을 다룹니다.책임의 재할당 과정에서 트랜잭션에서 외부 API 호출 로직을 분리하고, 데이터 주도 협력 관계에서 책임 주도 협력 관계로 나아가는 과정을 담았습니다.의미 있는 타입으로 묶기이전 포스팅에서 책임 재할당의 결과왼쪽은 `편지 서비스`가 해야 할 책임이 `데일리 리포트 서비스`에 있었던 부분입니다. (코드 20줄)오른쪽은 `편지 서비스`에게 책임을 재할당하고, 해당 서비스에게 요청을 보내는 부분으로 개선된 코드입니다. (코드 1줄)..

문제 상황간략한 위클리 리포트 서비스 소개위클리 리포트 서비스는 이름대로 한 주 동안 유저가 작성한 편지(또는 일기)에 대한 분석을 제공합니다.서비스 정책 안에서 왕성히 활동한 유저의 7일 치 글을 모두 합치면 최대 16만 글자가 넘을 수 있습니다. 현실적으로 16만 글자를 생성형 AI에게 전달하는 것은 비용 문제와 서비스 품질 문제로 이어질 수 있기 때문에 `데일리 리포트`를 이용하는데요, `데일리 리포트`에 하루치가 요약되어 있는 내용을 이용해 `위클리 리포트`를 생성합니다.서비스 정책 간략 소개`위클리 리포트`는 절대적으로 `데일리 리포트`에 의존하기 때문에 반드시 `데일리 리포트`가 존재해야 합니다.위의 의존성 문제 때문에 우리 서비스의 정책은 유저가 한 주간 편지를 작성만 하고 `데일리 리포트`..

이번 포스팅은 올려 올려 라디오 프로젝트의 도메인 모델 개선에 대해 다룹니다.현재 도메인 모델의 문제점을 짚어보고, 더 나은 도메인 모델을 제시하면서 그 근거를 정리하겠습니다. 시작하기 앞서, 프로젝트 리팩토링 과정을 잘 이해하기 위해 우리 프로젝트가 어떻게 동작하는지 간단하게 짚고 넘어가겠습니다.프로젝트 동작 구조답장 서비스 동작 구조위 그림은 우리 프로젝트의 첫 번째 MVP인 `답장 서비스`가 동작하는 구조입니다.유저가 `편지`를 써서 전달하면 생성형 AI가 `답장`을 생성해 응답합니다.우리 프로젝트는 유저가 작성한 `편지`와 `답장`을 각각 별개의 엔티티로 관리합니다.두 엔티티 간 관계는 1:1 관계를 갖고 있습니다. 데일리 리포트 서비스 동작 구조우리 프로젝트의 두 번째 MVP인 `데일리 리포트..

데이터 주도 설계에서 책임 주도 설계로프로젝트를 유지보수하고 새로운 기능을 개발할 때마다 `데이터 주도 설계`를 해오고 있다는 느낌을 지울 수 없었습니다.해커톤 기간은 10일만 주어졌고, 이 기간 동안 개발하던 프로젝트가 한 번 엎어져 남은 기간이 6일밖에 안 됐던지라 객체 지향적인 협력 관계를 고려하지 못한 채 개발을 이어나갔습니다. 해커톤 종료 후 고도화 기간 동안 설계를 재점검하지 않고 유지보수와 새 기능들을 개발했는데, 코드를 읽을 때마다 여기저기 중복된 코드와 제각기 다른 구현 방식 때문에 코드 읽기가 힘들었습니다.원인은 객체의 행동이 아닌 상태에 초점을 둔 데이터 주도 설계 때문이라고 생각되어 문제 해결을 위해 조영호 님의 오브젝트를 다시 읽었습니다. 이번 포스팅을 시작으로 `책임 주도 설계`..

이번 포스팅은 이전 포스팅에 이어서 코드로 구현하는 과정을 담았습니다.구현 목표모놀리식 아키텍처에서 MSA로 전환하는 작업의 초석이 되도록 서비스 간 결합도를 낮추기외부 API 호출 응답을 받으면 이벤트를 발행하는 방식으로 서비스 간 결합도를 낮춥니다.`편지 서비스`는 `처리율 제한기 서비스`에 대한 의존성을 제거하고, 편지를 저장하는 책임만 집니다.`답장 서비스`는 `외부 API 호출 서비스`에 대한 의존성을 제거해 트랜잭션에서 분리하고, 답장을 저장하는 책임만 집니다.다만, 데이터베이스에 저장하는 로직은 하나의 트랜잭션에서 처리할 수 있도록 상위 계층에서 편지와 답장을 저장하도록 설계합니다. ⇒ 이벤트 발행의 주체를 퍼사드 서비스로 구현합니다.이벤트에 상태(Status)를 추적할 수 있도록 하기Spr..

이 포스팅에서는 프로젝트에서 기존 비즈니스 로직의 문제점을 확인하고, Spring Events를 활용해 비즈니스 로직을 원자적으로 처리하는 내용을 다룹니다. 제목에 "모놀리식 아키텍처"를 붙인 이유는 MVP 개발부터 채택한 모놀리식 아키텍처를 그대로 유지하면서 최소한의 변경으로 문제를 해결하는 과정을 강조하기 위함입니다.현재 서비스 규모가 작고, 이용자 수가 많지 않은 상황에서 오버 엔지니어링을 하지 않고 개선해 보겠습니다.문제의 발단: 클로바 스튜디오 서비스의 장애1월 13일 오후 9시 45분경 클로바 스튜디오에 장애가 발생했습니다.우리 서비스의 첫 MVP였던 달토의 답장 서비스는 클로바 스튜디오에 의존하고 있었는데, 팀에서는 10시 30분이 지나서야 장애 발생을 인지했습니다. 문제 발단은 클로바 스튜..

이전 포스팅에서 톰캣 스레드 풀을 늘리기 전에, 병목 지점은 데이터베이스 커넥션을 획득하는 부분에 있다는 것을 파악했었습니다.이번 포스팅에서는 데이터베이스 커넥션 풀의 크기를 조절과 캐시를 적용하는 각각의 과정을 담았습니다.데이터베이스 커넥션 풀 크기 조절하기HikariCP 설정 값 변경하기커넥션 풀 크기를 조절하는 방법은 이미지처럼 `application.yml`에서 간단하게 설정할 수 있습니다.hikariCP 설정 옵션에 대한 설명입니다.maximum-pool-size: 커넥션 풀의 최대 크기를 지정합니다. 커넥션 풀 크기만큼 커넥션이 담기면 idle 상태의 커넥션은 존재하지 않게 된다고 합니다.minimum-idle(default: same as maximumPoolSize): 커넥션 풀에 idle..