장애 발생 및 발견8월 24일 서버 정기점검이 이루어지던 새벽정기점검 대상이 아닌 서버의 특정 인스턴스에 인입된 요청들이 'SQLException : Connection Closed' 오류로 모두 500처리가 되는 이슈가 발생하였다. 24일 3시 43분에 처음 발생한 이슈는 오전 9시 45분에 이슈사항으로 확인되었고 전사에 전파 및 담당자인 나에게 전달되게 되었다.( 약 6시간의 장애 시간의 텀은 너무 부끄러운 장애대응이다.. ) 장애 대응오전 9시 45분, 전사 장애 대응 채널에 내이름이 멘션되어 호출되기 시작했고, 해당 시스템은 팀내에서 개발한것이 아닌 외주업체에서 관리하고 있었기에 담당 업체에 연락하여 원인 파악 및 조치를 요청하였다. 오전 10시 03분, 담당 외주 업체에서의 조치 이전에 인프라팀..
이슈org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushingJPA 연관관계를 이용해 저장하려던 중 위와 같은 오류 발생 원인연관관계에 놓인 두 엔티티를 저장하려 할때, 부모 엔티티의 FK가 영속되지 않아 발생한 오류나의 경우 다대다 관계에 대한 테스트중 자식 엔티티를 바라보는 부모 엔티티의 필드 값이 영속 시점에 적절히 저장되지 않아 발생한 이슈 해결연관관계 엔티티를 함께 저장하기 위해서 Cascade 옵션을 통해 부모 엔티티가 저장될때 자식 엔티티가 함께 저장되도록 처리한다. @ManyToMany(cascade = C..
구글 OAuth2.0을 이용한 소셜 로그인 구현 구글에서 제공하는 OAuth2.0을 이용해야 하기에, 관련 로그인 기능 사용 신청을 위해 구글 계정 로그인후 구글 클라우드 플랫폼 콘솔로 이동한다. https://console.cloud.google.com/ Google 클라우드 플랫폼 로그인 Google 클라우드 플랫폼으로 이동 accounts.google.com 구글 클라우드 플랫폼에서 새로운 프로젝트를 생성한다. 프로젝트 생성 완료이후, API 및 서비스 탭의 OAuth 동의 화면으로 이동하여 필요한 설정을 진행한다. OAuth 동의 화면에서 앱 이름, 이메일등 필수 값을 입력후 '저장 후 계속' 버튼을 클릭한다. API 및 서비스 - 사용자 인증 정보 탭으로 이동하여 OAuth2.0 클라이언트를 생..
JPA 연관관계 다대다(N:M) 실무에선 보통 사용하지 않는것을 권장한다. 관계형 데이터베이스에서 정규화된 2개의 테이블로 다대다를 표현할 수 없다. 관계형 데이터베이스에서 다대다를 표현하기 위해서는 중간 테이블을 통해 일대다, 다대일로 나누어서 표현해야한다. JPA에서는 관계형 데이터베이스가 중간 테이블을 만드는 것과 달리 @ManyToMany 어노테이션을 통해 별도의 중간 테이블에 해당하는 엔티티를 만들지 않고도 다대다를 표현할 수 있다. 단방향 다대다 다대다 관계를 JPA를 통한 단방향 구현시 아래와 같이 코드 작성이 가능하다. Member (연관관계의 주인) @Entity @Table(name = "member") @Getter public class MemberEntity { @Id @Gener..
JPA 1:1(일대일) 관계 일대일 관계는 주 테이블혹은 대상 테이블 중에 외래 키를 넣을 테이블 선택이 가능하다. 일대일 관계에서는 반대도 일대일 관계가 된다. 다대일 관계에서는 다(N)에 해당하는 곳이 외래 키를 가지고 있지만(연관관계의 주인) 일대일 관계에서는 주 테이블이나 대상 테이블에 외래 키를 둘 수 있어서 선택 해야 한다. 일대일 관계에서는 외래 키를 주 테이블에 둘지, 대상 테이블에 둘지에 따라 약간의 차이가 있다. 1. 주 테이블에 외래 키가 있는 경우 주 테이블에 외래 키를 둘 경우, 주 테이블에 매핑되는 주 객체에도 객체 참조를 두는 구조를 만들게 된다. 일대일 단방향 주 테이블 Parent에 단방향 일대일 관계에 해당하는 Child 객체필드를 만든후, @OneToOne 어노테이션 선..
개요 N+1 문제와 해결 방법 JPA를 이용해 별도의 옵션 없이 엔티티를 조회할 경우, 엔티티에 연결되어 있는 연관관계들이 함께 조회된다. 함께 조회되는 시점에 부모 엔티티를 조회 하는 쿼리(1) + 연결되어 있는 연관관계 엔티티들에 대한 조회 쿼리(N)가 DB 요청으로 날아가게 된다. 예를들어 4개의 연관관계를 가지고 있는 엔티티 100개를 조회할 경우 100 + 400, 총 500회의 조회 쿼리가 날아가게 됨으로 성능에 큰 영향을 미치게된다. 이런 문제는 완벽하지는 않으나 Fetch Join, Entity Graph, Batch_Size를 통해 해결 할 수 있다. 보통 연관관계 엔티티들에 대해 FetchType을 통해 연관관계 엔티티를 즉시 조회(Eager)할지, 지연 조회(Lazy)할 지 정할 수 ..
DTO Entity 변환을 위해 자주 사용하는 MapStruct를 사용하며 겪은 주의 사항들을 정리 1. MapStruct는 Getter, Setter, Builder 기반으로 동작 MapStruct가 클래스간 매핑 코드를 만들때 타겟 클래스의 Getter, Setter를 기반으로 코드를 생성한다. 다만 MapStruct 사용을 위해 클래스에 Setter를 만드는것이 꺼림칙 하다면, Builder로 대체할 수 있다ㅡ. 2. Spring에서 Mapper 생성시 @Mapper 옵션으로 componentModel = "spring" 선언으로 해당 Mapper가 Bean으로 등록될 수 있도록 해야 동작한다. @Mapper(componentModel = "spring") public interface Member..
Redis는 뛰어난 성능과 유연성을 제공하는 인메모리 데이터베이스로, 다양한 애플리케이션에서 필수적으로 사용됩니다. 하지만 Spring 환경에서 Redis를 다룰 때는 두 가지 접근 방식인 RedisTemplate과 Redis Repository 중 하나를 선택해야 합니다.어떤 선택이 더 적합할까요? 이는 프로젝트의 요구사항과 Redis를 활용하는 방식에 따라 달라질 수 있습니다. RedisTemplate은 저수준 API로 세밀한 제어와 유연성을 제공하지만, 복잡한 작업과 설정이 필요합니다. 반면, Redis Repository는 고수준의 추상화를 통해 간단하고 직관적인 개발 경험을 제공하지만, 제한된 유연성과 고급 기능 부족이라는 단점이 있습니다.이번 글에서는 RedisTemplate과 Redis Re..
