발자국남기기

최근들어 근무시간에 틈이 날때마다 서버 모니터링을 습관화하려고 모니터링 솔루션을 이용해 자주 들여다보곤한다. 우리가 기대하는 서버의 히트맵은 아래와 같지만, 특정 API, 특정 로직, 특정 쿼리에 병목지점이 있다면 아래와 같이 히트맵이 위로 튀곤한다. 이걸 분석해서 병목지점을 해소하고 원인을 파악하는 재미가 은근 쏠쏠하다고 느꼈다. 대부분의 경우에는 정말 간단한 휴먼 에러의 경우가 많은 것 같은데, 이런 것들을 잡아내기 어려운 이유가 간헐적으로 발생하며 서버 모니터링을 주기적으로 하지 않는 이상 병목 지점이라는 것조차 느끼기 힘든 것 같다. 서버에 대해 에러 응답 비율이 높아지면 알림을 받을 수 있도록 별도의 설정을 하더라도 간헐적으로 발생하기 때문에 방치되는 경우가 많다. 실제로 모니터링 중 발견한 간..

현재 Spring Security를 사용하여 로그인, 로그아웃을 구현한 상태이고 인증(로그인)하지 않은 사용자는 게시판에 접속할 수 없도록 구현해놓았다. Controller 파라미터로 page(페이징 변수), category(카테고리별 조회), myPost(내 게시물 보기), searchDto(검색창)를 받는다. 1. page page는 defaultValue를 0으로 설정하였기 때문에 값을 설정하지 않으면 0페이지부터 보여준다. 만약 다음 페이지 버튼을 누르게 되면 현재 페이지에서+1을 한 값이 page 변수에 담기고, 이전 페이지 버튼을 누르면 현재 페이지에서 -1을 한 값이 담긴다. 2. category required 속성을 false로 지정해놓았기 때문에 category 값을 주지 않으면 nul..

현재 게시물 CRUD 기능은 구현이 되어있는 상태이다. 스프링 데이터 JPA를 사용하여 굉장히 편리하게 구현하였다. 조회수 기능 조회수 기능의 구현 로직은 굉장히 간단하다. 그냥 해당 게시물을 조회할 때 조회수 필드를 +1 시켜주면 된다. 프로젝트를 진행할 때에는 Setter를 사용하여 값을 변경하는 습관은 매우 좋지 않은 습관이다. 그 외에 따로 조회수 필드를 변경할 수 있는 메서드를 만들어서 진행하였다. 이는 서비스 계층에서 호출되어 사용된다. JPA의 Dirty Checking 기능을 사용하여 조회수를 1씩 올려주는 식으로 구현하였다. 서비스 계층의 클래스 레벨에서 @Transation(readOnly=true)로 설정해놓고 생성, 수정이 일어나는 메서드 레벨에서 위와 같이 @Transaction을..

JPQL을 사용하여 회원 이름으로 조회하기 Querydsl을 사용하여 회원 이름으로 조회하기 JPAQueryFactory에 EntityManager 객체를 넣어줌. 훨씬 더 직관성이 있고 알아보기 쉽다. 파라미터 바인딩을 해주지 않아도 알아서 처리해준다. Querydsl은 JPQL 빌더 JPQL: 문자(실행 시점 오류), Querydsl: 코드(컴파일 시점 오류) JPQL: 파라미터 바인딩 직접, Querydsl: 파라미터 바인딩 자동 처리 EntityManager, JPAQueryFactory 모두 동시성 문제가 발생하지 않게 설계가 되어 있다. 따라서 EntityManager 처럼 JPAQueryFactory도 필드 레벨에서 선언하여 사용하여도 문제없다. 스프링 프레임워크는 여러 쓰레드에서 동시에 같..

Spring Data JPA 구현체 분석 공통 인터페이스(JpaRepository)의 구현체 ==> org.sprigframework.data.jap.repository.support.SimpleJpaRepository SimpleJpaRepository 클래스 내에 CRUD를 하는 여러 메서드(save, findAll....)등을 구현해놓았다. SimpleJpaRepository는 @Repository 애노테이션이 붙어있는데 여기에는 두가지 의미가 있다. 1. 컴포넌트 스캔의 대상이 되어 스프링이 읽어 컨테이너에 스프링 빈으로 등록 2. JPA(JDBC도 마찬가지)에서 발생한 예외와 같은 영속성 계층의 예외들을 Spring 예외로 바꿔준다. 서비스 계층이나 컨트롤러 계층에 예외를 넘길 때 JPA나 JD..

JPA Hint JPA 쿼리 힌트 ==> SQL 힌트가 아니라 JPA 구현체에게 제공하는 힌트 우리가 JPA에서 수정을 위해 사용되는 변경 감지 기능에 대해 먼저 얘기해보자. 위와 같이 변경감지를 사용한다면, 내부적으로 member1을 변경을 감지하기위해 바뀌기 전 데이터와 바뀐 후의 데이터 총 두개를 가지고 있어야한다. 이는 비효율적이다(메모리를 더 잡아먹음). ㅓPA는 엔티티를 영속성 컨텍스트에 보관할 때 최초 상태를 복사해서 저장해두는데 이를 스냅샷 이라 한다. 개발자가 수정을 하길 원하는 것이 아니라 단순히 조회만하여도 JPA는 내부적으로 스냅샷 만들어준다.(변경 감지를 위해) 실제 변경감지 기능을 사용한다면 어쩔 수 없겠지만, 만약 조회만 하고 변경 감지 기능을 사용하지 않는다면 이를 최적화할 ..

Member와 Team이 다대일 관계로 매칭되어 있고, 지연로딩으로 설정되어있다고 생각해보자. 지연로딩의 특성상 Member를 가져올 때 Team에 대한 정보는 가져오지 않고 proxy 객체를 만들어놓고 Team에 대한 접근이 들어올 때 진짜 Team에 대한 정보를 가져온다. 이렇게 코드가 작성되어 있을 때, 쿼리가 어떻게 나갈까? 먼저 findAll에 의해 한번에 모든 Member에 대한 조회가 이루어질 것이다. 그 후에 우리가 작성한 member의 이름을 출력하였다. 이 때 쿼리문을 살펴보면 team에 관한 데이터는 하나도 가져오지 않은 것을 볼 수 있는데 이것이 바로 proxy객체로 가져오기 때문이다. 즉, findAll이 실행되면 일단 Member만 DB에서 가져온다. 팀의 이름을 가져오기 위해 ..

JPA에서 변경에 사용하는 변경감지 기능은 한건한건씩 진행한다. 만약 전 직원의 연봉을 10% 인상해야한다면? 모든 직원을 하나하나 조회하여 Dirty Checking으로 변경하는 것은 매우 비효율적이다. 이런 경우에는 DB에 update쿼리를 날려 한번에 모두 변경하고 commit을 하는 것이 더 효율적일 것이다.이를 JPA에서 벌크성 수정 쿼리라고 한다. 먼저 JPA를 사용하여 벌크성 수정 쿼리를 작성해보자. 파라미터로 넘어온 나이보다 나이가 많은 모든 사람의 나이를 한살 증가시켜주는 update쿼리를 작성하였다. 이를 스프링 데이터 JPA로 작성해보자. @Query 애노테이션을 사용하여 JPQL을 작성하고 @Param으로 파라미터를 바인딩해준다. @Modifiying은 JPA에서의 excuteUpd..

먼저 순수 JPA로 페이징과 정렬을 하는 법을 다시 한번 살펴보자. 검색 조건 : 나이가 10살 정렬 조건 : 이름으로 내림차순 페이징 조건 : 첫 번째 페이지, 페이지당 3개 totalpage = totalcount / size JPQL을 작성하는데 offset 몇번째부터 limit 몇번째까지 데이터를 가져올 것인지 페이징을하고, 이름순으로 정렬하였다. 또한 전체 데이터의 수를 알기위해 totalcount메서드도 같이 작성 junit 테스트 작성 원하는 대로 페이징이 성공한 것을 확인할 수 있다. 이번에는 스프링 데이터 JPA를 사용하여 페이징과 정렬을 해보자. 정렬 ==> org.springframework.data.domain.Sort 페이징 ==> org.springframework.data.do..

1. 메서드 이름으로 쿼리 생성 2. 메서드 이름으로 JPA NamedQuery 호출 3. @Query 애노테이션을 사용해서 Repository 인터페이스에 쿼리 직접 정의 메서드 이름으로 쿼리 생성 스프링 데이터 jpa 맛보기할 때 잠깐 봤던 내용이다. 회원을 조회하는 메서드가 존재한다고 가정해보자. 이 메서드는 이름과 나이를 매개변수로 받아 이름이 동일하고 매개변수로 들어온 나이보다 더 많은 회원을 조회한다. 순수한 JPA를 사용하여 메서드를 만든다면 다음과 같이 만들 수 있다. 하지만 스프링 데이터 jpa를 사용한다면 구현없이 위와같이 메서드 인터페이스를 만드는 것만으로도 끝이난다. 테스트 또한 성공하는 것을 확인할 수 있다. 어떻게 이것이 가능한 것인지 살펴보자. findBy을 보고 스프링 데이터..