Spring Framework
-
JPA Repository 기본 postfix로 인한 순환참조 해결Spring Framework 2023. 7. 30. 19:40
1) 서론 요즈음 스프링 프레임워크를 사용한다면 Spring Data JPA는 기본적으로 사용하게 되는데요. ORM 프레임워크는 RDB의 테이블을 객체로서 나타내고 맵핑할 수 있게 합니다. 애플리케이션에서 테이블에 질의할 때 쿼리와 데이터 중심이 아닌 객체로서 바라보는 것이 가능해졌습니다. 객체지향적인 설계에 큰 도움을 주게 됩니다. 이외에도 메서드를 활용하여 자동완성 되는 쿼리를 손쉽게 사용할 수 있는데요. 하지만 JDBCTemplate 같은것을 활용하여 쿼리를 날리는 것에 비해 주의해야 할 점이 많이 생겼습니다. 영속성 컨텍스트를 이해하지 못하거나 트랜잭션의 관리가 잘 되지 않는다면 예상치 못한 문제들이 발생할 수도 있는데요. 이번에는 Repository를 정의하고, 이에 대한 순환참조가 발생한것을 ..
-
식탁위의 메뉴판, Local cache invalidateSpring Framework 2023. 5. 10. 23:47
1) 배경 설명 햄버거 가게에 들어갑니다. 그리고 각 식탁에 놓인 메뉴판을 보려고 하는데요. 메뉴판은 각 테이블에서 쉽게 볼 수 있어야 합니다 한 번 생성된 메뉴판은 거의 변경되지 않습니다 특정 테이블만 변경전 메뉴판 사용하더라도 심각한 문제는 아닙니다. 점원이 안내 후 새 메뉴판을 전달합니다. 2) 메뉴판을 조회합니다 DB에 저장된 메뉴 조회 (= 점원이 직접 메뉴판을 가져다주는 행위) 현재는 테이블에 메뉴판이 없습니다. 손님이 메뉴판을 보내는 방법은 이렇습니다. 손님은 점원을 불러야 합니다 점원은 메뉴판을 가지러 가야 합니다 점원은 메뉴판을 가지고 와야 합니다 손님은 메뉴판을 보기 위해 대기해야 합니다 만약 식사 중 메뉴판을 보기 위해서 다시 반복해야 합니다 메뉴판을 보기 위해서 위의 과정을 거쳐야..
-
Spring Cloud Sleuth + logback 적용기Spring Framework 2023. 2. 1. 20:06
1) 서론 기존의 단일 모듈로 구성되어 있던 것을 MSA로 분리하면서 로그 추적이 매우 힘들어진 것을 경험했습니다. 이전에는 하나의 클라이언트 요청에 대해서 하나의 서버에서만 처리를 담당했습니다. 다연히 트랜잭션을 잘 확인한다면 전체 로그 추적이 어렵지 않았는데요. MSA로 분리하게 되면서 하나의 클라이언트 요청에 대해 서버 - 서버 통신이 아주 많이 발생하고 있습니다. 여러개의 서버를 요청하여 하나의 클라이언트 응답으로 만들어 주는 경우가 늘어났습니다. 위와 같이 여러 서버를 통신했을 때 각 서버의 요청은 별도의 트랜잭션으로 동작합니다. 이 때문에 하나의 서버에서 오류가 발생했을 때 전체 흐름을 추적하기 힘들어집니다. 특히 멀티 쓰레드를 활용하여 다수의 요청이 발생하게 되면 더더욱 파악하기 어려워집니다..
-
스프링에서 재처리를 위한 @Retryable 사용하기Spring Framework 2022. 8. 22. 23:10
1) 서론혹시 어떠한 일을 할 때 배보다 배꼽이 더 커졌던 경험이 있으신가요? 예전에 문득 해물탕이라는 요리가 너무 먹고 싶었고, 집 근처에서 해물탕 가게를 찾을 수 없었습니다. 그래서 직접 해물탕을 만들겠다는 생각을 했었는데요. 하지만 해물탕 한 그릇을 먹기 위해 비싼 해산물들을 구매해야 했습니다. 그리고 구매한 해산물들을 다듬는 시간은 꽤 오래 걸렸는데요. 혹시 잘 못 해감을 해서 모래가 씹히지 않을까, 이 부분은 먹어도 되는 걸까? 고민을 했었습니다. 어찌어찌 요리 후 맛있게 먹었습니다. 하지만 여전히 남는 아쉬움은 있었습니다. 15분 만에 먹고 끝내는 이 한 그릇을 위해서 이렇게 많은 돈과 정성을 쏟는 것이 정말로 효율적인 건가? 식당을 찾아가서 먹거나, 추가의 배달비를 내고 배달을 시키는 것이..
-
Junit 테스트 병렬 수행으로 빌드 시간 단축하기Spring Framework 2022. 8. 16. 01:14
1) 서론혹시 무언가를 기다리는 시간이 지루하게 느껴진 경험이 있으신가요?저는 놀이기구를 타기 위해 기다리는 시간이 참 지루하다고 느껴집니다. 대기열에서 약 1시간씩 기다리다 보면, 자유이용권을 구매했지만 몇 개 못 타는 경험을 하기도 하는데요. 가끔 대기열이 전혀 없고, 실컷 탈 수 있었으면 하는 상상도 해봅니다.최근 문득 애플리케이션의 build 시간이 지루하고, 아깝다는 생각이 들었는데요.특히 테스트 코드가 증가하게 되면, 빌드 시간도 계속해서 지연됩니다. Githbub actions를 사용해서 PR 생성 혹은 commit 시 자동으로 build가 동작하거나, 배포를 위해 build 할 때도 마찬가지입니다.만약총 10명의 개발자가하루에 5번 build 하고1분씩 아낄 수 있다면 총 50분이라는 소중..
-
Querydsl cross join 개선 하기Spring Framework 2022. 6. 18. 19:48
1) 서론 회사에서 Spring Data JPA는 서버 개발의 공통 기술 스택입니다. 그리고 당연하게 where 절을 많이 사용하는데요. 이때 만난 문제점을 개선하고 이를 공유하고자 합니다. Querydsl 뿐만 아니라, Spring Data JPA를 사용해보셨다면 이미 알고 계신 내용일 수도 있는데요. 그런 분들은 이번 글은 skip 하셔도 좋을 것 같습니다. 2) Querydsl where절의 문제점 ORM 프레임워크 상 혹은 SQL 쿼리를 직접 사용할 때 where절은 숨 쉬듯 자연스럽게 사용됩니다. 하지만 이러한 where절이 문제점을 일으킬 것이라고는 생각하지 못했었는데요. 어떤 문제가 있을까요? @Table(name = "book", schema = "test") @Entity class B..
-
FK 없는 OneToOne 즉시 로딩 개선하기Spring Framework 2022. 6. 7. 00:08
1) 서론 이번 글에서는 업무 중 발견한 레거시 코드의 문제점을 개선한 것을 공유하고자 합니다. 다양한 로직에서 빈번히 조회되고 있던 엔티티가 있었는데요. 특별히 문제가 발생하지 않았기 때문에 실제로 발생하는 쿼리를 주의 깊게 보지 않았었습니다. 하지만 우연히 지나치게 많은 쿼리가 발생하고 있는 것을 발견했습니다. 최초의 설계 의도는 지연 로딩을 하고자 했던 것 같지만, 실제로는 즉시 로딩이 되고 있었습니다. N+1 문제가 발생하고 있었는데요. 적은 스펙의 IDC 환경에서 돌아가는 애플리케이션을 운영하는 입장에서 불필요한 쿼리 개선 하나하나가 소중한 상황입니다. 이러한 레거시 코드를 개선하고, 변경한 내용을 공유합니다. 2) DB schema 모든 테이블 구조 및 로직은 재현을 위해 임의로 만들었습니다..
-
처음으로 해본 리팩토링 후기Spring Framework 2022. 3. 24. 02:40
1) 서론 일이 바쁘다는 핑계로 사용한 물건을 집안 곳곳에 아무렇게나 방치한 경험이 있나요? 당시의 나는 일단 물건을 어딘가에 두고, 씻고 잠자는 것이 더 편하고, 우선이라고 생각했을 것 같습니다. 하지만 시간이 흐르고 이러한 것들이 쌓이게 된다면, 물건을 찾기는 더더욱 불편해집니다. 어쩌다 새로운 가구를 구매라도 하게 되면, 어디에 놓아야 할지 엄두가 나지 않습니다. 왜냐하면 정리되지 않은 물건들로 공간은 가득할 테니까요. 이런 순간이 되면 미리미리 치워놓을걸 하는 후회와 함께, 이 짐들을 어디로 옮기고, 새로운 가구는 어떻게 배치할 것인지 고민이 될 것입니다. 아마도 우리가 작성하는 코드도 비슷할 거라고 생각합니다. 처음에는 빠르게 개발하는 것이 중요했을 것이고, 그것이 실제로 중요한 시기였을 것입니..