EATceed 서비스에서는 사용자가 이메일 인증을 시도할 때 인증 코드를 사용합니다. 이 과정에서 보안을 위해 인증 코드를 암호화/복호화하고 있는데, 여기서 지연 문제가 발생했습니다. 암호화/복호화를 할 때마다 시간이 너무 오래 걸리고, CPU 부하가 크게 증가하는 것이었습니다. 문제를 분석한 결과, 원인은 Cipher 클래스를 사용하는 방식에 있었습니다. 본격적인 해결 방법을 설명하기 전에, 먼저 Cipher 클래스에 대해 간단히 소개하겠습니다. Cipher 클래스란? Cipher 클래스는 데이터를 암호화하거나 복호화하는 Java에서 제공하는 주요 클래스입니다. 이 클래스는 다양한 암호화 알고리즘과 작동 모드, 그리고 패딩 방식을 제공하여 다양한 보안 요구사항을 충족할 수 있도록 설계되었습니다. 하지만..

EATceed의 핵심 기능 중 하나는 사용자 개개인의 신체 정보와 식단 기록을 기반으로, 매일 목표에 도달했는지를 월별 캘린더 형식으로 시각화하는 것입니다. 하지만 기존 API 구조는 모든 데이터를 실시간으로 계산하여 비효율적이라는 문제가 있었습니다. 이번 포스팅에서는 이러한 API를 개선한 과정을 상세히 설명하려고 합니다. 기존 방식 기존에는 모든 요청에 대해 월 단위로 데이터를 실시간으로 계산하고 분석 결과를 반환하는 방식이었습니다. 즉, 과거, 현재, 미래의 데이터를 모두 동일하게 처리하면서 불필요한 쿼리 요청이 발생하는 비효율적인 구조였습니다.그러나 과거 데이터는 변하지 않는다는 점에 착안해, 다음과 같이 로직을 개선했습니다.  예시 코드@Servicepublic class GetMonthlyAn..

EATceed 프로젝트를 진행하며, 회원가입 API에 아래와 같은 요구사항이 추가되었습니다. 이메일 인증을 하지 않은 회원이 회원가입 하였을 경우에 "이메일 인증을 해주세요" 라는 응답과 함께 딥링크(with 인증코드)가 담긴 메일을 발송하라 이메인 인증 미완료시 이메일 재발송하기 EATceed에서는 이메일 인증을 완료하지 않은 사용자가 회원가입을 다시 시도할 경우, 이메일을 재전송하고, "이미 존재하는 이메일입니다. 이메일 인증을 해주세요"와 같은 응답을 반환해야합니다. 이메일 재전송 API를 만들 수도 있었지만 사용자 경험 저하 및 AOS 측 이메일 저장 문제로 인해 회원가입 API에서 "이메일 재전송"을 추가하기로 하였습니다.  이벤트를 사용해서 해결하기기존에 AlreadyEmailException..

DDD Entity와 JPA Entity 구분의 고민 EATceed 프로젝트에서는 JPA의 Entity와 도메인 주도 설계(DDD)의 Entity를 구분하여 코드를 작성하고 있습니다. 하지만, 몇몇 JPA 엔티티와 DDD 엔티티들이 구조적으로 거의 흡사하여, 이 둘을 구분하는 것이 옳은 선택인지 고민이 생겼습니다.제가 생각하는 장점과 단점은 아래와 같습니다.장점명확한 책임 분리DDD Entity는 비즈니스 로직과 도메인 모델링에 집중하고, JPA Entity는 데이터베이스와의 매핑에만 집중하게 되어 각 클래스의 책임이 명확해집니다. 이를 통해 코드를 더 이해하기 쉽고 유지보수하기 용이하게 만듭니다.도메인 모델의 순수성 유지DDD Entity는 데이터베이스에 의존하지 않고, 순수한 도메인 로직만을 포함하게..

현재 상황앱을 출시하기 전 “앱 출시 6개월 후 활발하게 활동하는 회원이 100명 정도라 가정”하고 쿼리 테스트를 진행하였습니다. 초기 데이터 회원 100명이 6개월 동안 아침, 점심, 저녁, 간식을 모두 섭취한다고 가정하면, 총 72,000개의 식사가 이루어집니다. 이는 아래와 같이 계산할 수 있습니다100명 * 6개월 * 30일 * 4끼 = 72,000끼그러나, 유저가 회원가입한 시기를 고려하여 프로시저를 사용해 각 테이블에 데이터를 삽입한 결과, 실제 기록된 식사 횟수(MEAL_COUNT)는 67,400개로 나타났습니다.또한, 한 끼당 4가지 음식을 섭취한다고 가정하였습니다. 정확한 쿼리 테스트를 위해 쿼리 캐시 Off SHOW VARIABLES LIKE 'query_cache_type'; 아직 실..

https://rasony.tistory.com/190 헥사고날 아키텍처 회고EATceed 프로젝트에서 헥사고날 아키텍처를 사용해보며, 고민해본 점을 서술해보려고 합니다.먼저, 헥사고날 아키텍처를 도입한 이유입니다. 헥사고날 아키텍처를 도입한 이유 계층형 아키텍처rasony.tistory.com 프로젝트를 진행하며, 외부 서비스를 이용해야하는 기능들이 점점 더 생기기 시작하였습니다. 구체적으로, AWS의 S3와 SES 서비스를 이용하고, 데이터베이스로는 MariaDB와 Redis를 사용하게 되었습니다.또한, 특정한 트리거로 인한 스케줄링 기능을 사용하기 위해 Quatz를 도입하였습니다. 이에 아래와 같은 패키지가 추가되었습니다.  현재 패키지 구조는 도메인기반으로 패키지 구조를 나누고 있었습니다.하지만,..