0425 ~ 0501

# 0425 ~ 0501

# 0425 - Given-When-Then Pattern

# Given-When-Then Pattern?

Given-When-Then Pattern은 BDD(Behaviour-Driven Development) 중 하나로, Test Code 스타일을 표현하는 하나의 방식이라고 볼 수 있다.

# Given (테스트 전의 상태)

테스트에서 구체화하고자 하는 행동을 시작하기 전에 테스트 상태를 설명하는 부분
즉, 시나리오 진행에 필요한 값을 설정하고 테스트의 상태를 설정한다

# When (테스트 행위)

구체화하고자 하는 행동
즉, 시나리오 진행 필요 조건 명시, 테스트하고자 하는 행동을 명시한다

# Then (테스트 검증)

특정 행동으로 인해 발생할 것으로 예상되는 변화에 대해 설명하는 부분
즉, 시나리오를 완료했을 때 보장해야 하는 결과를 명시하고 예상되는 변화를 설명한다

@Test
void hasSkill_AlwaysTrue() {
    // given
    given(skills.hasSkill()).willReturn(true);

    // when
    boolean actual = person.hasSkill();

    // then
    assertThat(actual).isTrue();
}

# 0426 - @Modifying

# @Query이란

Spring Data JPA에서는 기본적으로 JpaRepository의 기본 메서드와, 메서드 네이밍만을 통해서 쿼리를 실행할 수 있도록 기능을 제공한다. 하지만, 쿼리를 직접 작성하여 사용하고 싶을땐 @Query annotation을 사용한다. JPQL 및 nativeQuery=true 옵션으로 네이티브 쿼리도 사용 가능하다.

# @Modifying이란

@Query Annotation으로 작성 된 변경, 삭제 쿼리 메서드를 사용할때 필요하다. 즉, 조회 쿼리를 제외하고, 데이터 변경이 일어나는 INSERT, UPDATE, DELETE, DDL에서 사용한다. 주로 벌크 연산시에 사용된다.
JPA Entity LifeCycle을 무시하고 쿼리가 실행되기 때문에 해당 annotation을 사용할 때는 영속성 콘텍스트 관리에 주의해야 한다. 앞으로 설명할 clearAutomatically, flushAutomatically를 통해 간단하게 해결할 수 있다.

# 벌크연산이란

벌크 연산이란 단건 UPDATE, DELETE를 제외한 다건의 UPDATE, DELETE 연산을 하나의 쿼리로 처리하는 것을 의미한다. JPA에서 단건 UPDATE 같은 경우에는 Dirty Checking을 통해서 수행되거나 save()로도 가능하다. DELETE의 경우에는 다건, 단건 모두 쿼리 메서드로 제공된다.
@Query에 벌크 연산 쿼리를 작성하고, @Modifying을 붙이지 않으면, InvalidDataAccessApiUsage exception이 발생한다.

# clearAutomatically

이 Attribute는 @Modifying이 붙은 해당 쿼리 메서드 실행 직 후, 영속성 컨텍스트를 clear 할 것인지를 지정하는 Attribute이다. defalut 값은 false다. true시 벌크 연산 직 후 자동으로 영속성 컨텍스트를 클리어 해준다.

# 0429 - JPA - OSIV

# OSIV(Open Sessio In View)

OSIV는 영속성 컨텍스트를 뷰까지 열어두는 기능이다. 영속성 컨텍스트가 유지되면 엔티티도 영속 상태로 유지된다. 뷰까지 영속성 컨텍스트가 살아있다면 뷰에서도 지연 로딩을 사용할 수가 있다.

JPA에서는 OEIV(Open EntityManage In View), 하이버네이트에선 OSIV(Open Session In View)라고 한다. 하지만 관례상 둘 다 OSIV로 부른다.

# OSIV 동작 원리

OSIV의 동작 방식에 대해서 Spring Framework가 제공하는 OSIV를 통해 보면, 스프링이 제공하는 OSIV 클래스는 서블릿 필터에서 적용할지 스프링 인터셉터에서 적용할지에 따라 원하는 클래스를 선택해서 사용하면 된다.

JPA OEIV 서블릿 필터: org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter (opens new window)
JPA OEIV 스프링 인터셉터: org.springframework.orm.jpa.support.OpenEntityManagerInViewInterceptor (opens new window)

스프링 프레임워크가 제공하는 OSIV는 비지니스 계층에서 트랜잭션을 사용하는 OSIV다. 영속성 컨텍스트는 사용자의 요청 시점에서 생성이 되지만, 데이터를 쓰거나 수정할 수 있는 트랜잭션은 비즈니스 계층에서만 사용할 수 있도록 트랜잭션이 일어난다.

spring.jpa.open-in-view : true 기본값

Spring Boot JPA의존성을 주입 받아 어플리케이션을 구성할 경우 spring.jpa.open-in-view의 기본값인 true로 지정되어 있어 OSIV가 적용된 상태로 어플리케이션이 구성된다.

동작원리는 다음과 같다.

클라이언트의 요청이 들어오면 서블릿 필터나, 스프링인터셉터에서 영속성 컨텍스트를 생성한다. 단 이 시점에서 트랜잭션은 시작하지 않는다.
서비스 계층에서 @Transactional로 트랜잭션을 시작할 때 1번에서 미리 생성해둔 영속성 컨텍스트를 찾아와서 트랜잭션을 시작한다.
서비스 계층이 끝나면 트랜잭션을 커밋하고 영속성 컨텍스트를 플러시한다. 이 시점에 트랜잭션은 끝내지만 영속성 컨텍스트는 종료되지 않는다.
컨트롤러와 뷰까지 영속성 컨텍스트가 유지되므로 조회한 엔티티는 영속 상태를 유지한다.
서블릿 필터나, 스프링 인터셉터로 요청이 돌아오면 영속성 컨텍스트를 종료한다. 이때 플러시를 호출하지 않고 바로 종료한다.

서비스 계층에서 트랜잭션이 끝나면 컨트롤러와 뷰에는 트랜잭션이 유지되지 않는 상태이다. 엔티티를 변경하지 않고 단순히 조회만 할 때는 트랜잭션이 없어도 동작하는데, 이것을 트랜잭션 없이 읽기(Nontransactional reads)라 한다. 하여 만약 프록시를 뷰 렌더링하는 과정에 초기화(Lazy loading)가 일어나게 되어도 조회 기능이므로 트랜잭션이 없이 읽기가 가능하다.

영속성 컨텍스트는 기본적으로 트랜잭션 범위 안에서 엔티티를 조회하고 수정할 수 있다.
영속성 컨텍스트는 트랜잭션 범위 밖에서 엔티티를 조회만 할 수 있다. 이것을 트랜잭션 없이 읽기(Nontransactional reads)라 한다.

만약 트랜잭션 범위 밖인 컨트롤러와 뷰에서 엔티티를 수정하여도 영속성 컨텍스트의 변경 감지에 의한 데이터 수정이 다음 2가지 이유로 동작하지 않는다.

영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하려면 영속성 컨텍스트를 플러시(flush)해야 한다. 스프링이 제공하는 OSIV는 요청이 끝나면 플러시를 호출하지 않고 em.close()로 영속성 컨텍스트만 종료시켜 버린다.
프레젠테이션 계층에서 em.flush()를 호출하여 강제로 플러시해도 트랜잭션 범위 밖이므로 데이터를 수정할 수 없다는 예외가 일어난다. (javax.persistence.TransactionRequiredException)

# OSIV 사용시 주의점

2021-01-18 21:54:44.750 WARN 36808 --- [ restartedMain] JpaBaseConfiguration$JpaWebConfiguration : spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning

spring.jpa.open-in-view의 값을 기본값(true)으로 어플리케이션을 구동하면, 어플리케이션 시작 시점에 위와 같은 warn 로그를 남기게 된다.
그런데 위 동작 방식처럼 프록시를 초기화하는 작업을 Service 계층에서 끝내지 않고도 렌더링 시 자동으로 해결하게 해주는 장점이 있는 OSIV전략에 왜 경고를 줄까?

OSIV 전략은 트랜잭션 시작처럼 최초 데이터베이스 커넥션 시작 시점에서 API 응답이 끝날 때 까지 영속성 컨텍스트와 데이터베이스 커넥션을 유지한다. 그래서 View Template이나 API 컨트롤러에서 지연 로딩이 가능하다.
지연 로딩은 영속성 컨텍스트가 살아있어야 가능하고, 영속성 컨텍스트는 기본적으로 데이터베이스 커넥션을 유지한다. 이것 자체가 큰 장점이다.

그런데 이전략은 너무 오랜시간동안 데이터베이스 커넥션 리소스를 사용하기 때문에, 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자랄 수 있다. 이것은 결국 장애로 이어진다.
예를 들어서 컨트롤러에서 외부 API를 호출하면 외부 API 대기 시간 만큼 커넥션 리소스를 반환하지 못하고, 유지해야 한다. -> OISV의 치명적인 단점, 커넥션을 영속성 컨텍스트가 종료될 때까지 1:1로 계속 물고 있다.

[ OSIV OFF ]

spring.jpa.open-in-view: false (OSIV 종료)

OSIV를 끄면 트랜잭션을 종료할 때 영속성 컨텍스트를 닫고, 데이터베이스 커넥션도 반환한다. 따라서 커넥션 리소스를 낭비하지 않는다. OSIV를 끄면 모든 지연로딩을 트랜잭션 안에서 처리해야 한다. 따라서 지금까지 작성한 많은 지연 로딩 코드를 트랜잭션안으로 넣어야 하는 단점이 있다. 그리고 view template에서 지연로딩이 동작하지 않는다. 결론적으로 트랜잭션이 끝나기 전에 지연 로딩을 강제로 호출해 두어야 한다.

# 커맨드와 쿼리 분리

실무에서 OSIV를 끈 상태로 복잡성을 관리하는 종은 방법이 있다. 바로 Command와 Query를 분리하는 것이다.

보통 비즈니스 로직은 특정 엔티티 몇 개를 등록하거나 수정하는 것이므로 성능이 크게 문제가 되지 않는다. 그런데 복잡한 화면을 출력하기 위한 쿼리는 화면에 맞추어 성능을 최적화 하는 것이 중요하다. 하지만 그 복잡성에 비해 핵심 비즈니스에 큰 영향을 주는 것은 아니다.
그래서 크고 복잡한 애플리케이션을 개발한다면, 이 둘의 관심사를 명확하게 분리하는 선택은 유지보수 관점에서 충분히 의미 있다.

예)
OrderService

OrderService : 핵심 비즈니스 로직
OrderQueryService : 화면이나 API에 맞춘 서비스 (주로 읽기 전용 트랜잭션 사용)

보통 서비스 계층에서 트랜잭션을 유지한다. 두 서비스 모두 트랜잭션을 유지하면서 지연 로딩을 사용할 수 있다.

# OSIV 정리

특징

OSIV는 클라이언트 요청이 들어올 때 영속성 컨텍스트를 생성해서 요청이 끝날 때까지 같은 영속성 컨텍스트를 유지한다. 하여 한 번 조회된 엔티티는 요청이 끝날 때까지 영속 상태를 유지한다.
엔티티 수정은 트랜잭션이 있는 계층에서만 동작한다. 트랜잭션이 없는 프레젠테이션 계층은 지연 로딩을 포함해 조회만 할 수 있다.

단점

영속성 컨텍스트와 DB 커넥션은 1:1로 물고있는 관계이기 때문에 프레젠테이션 로직까지 DB 커넥션 자원을 낭비하게 됨.
OSIV를 적용하면 같은 영속성 컨텍스트를 여러 트랜잭션이 공유하게될 수도 있다.
프레젠테이션에서 엔티티를 수정하고 비즈니스 로직을 수행하면 엔티티가 수정될 수 있다.
프레젠테이션 계층에서 렌더링 과정에서 지연 로딩에 의해 SQL이 실행된다. 따라서 성능 튜닝시에 확인해야 할 부분이 넓어진다.

# 0430 - DAU, PU, PV

# DAU / WAU / MAU

1일, 1주, 1달 동안 활성 사용자(Active User)의 수를 의미

# DAU (Daily)

하루 동안 방문한 순수 사용자 수를 집계
게임, 메신저 등 사용빈도가 높은 앱의 주요 지표로 활용됨
서버 부하를 비롯한 트래픽 관련 변동비 추정 및 최적화와 연관이 깊음

# WAU (Weekly Active User)

일주일(7일) 동안 방문한 순수 사용자 수를 집계
매일 접속할 필요 없는 모바일 은행과 같은 앱에서 주로 활용되는 지표

# MAU (Monthly Active User)

월 간(30일) 방문한 순수 사용자 수를 집계
수치가 크기 때문에 비즈니스를 설명하는 데에 주로 인용됨
하지만 실제적인 유저의 활성화 정도를 파악하기 어려운 단점이 있음

# PU / ARPU / ARPPU

# PU (Paying Users)

유료 유저 수 (결제한 유저 수)

# ARPU (Average Revenue Per Users)

유저별 평균 매출
ARPU = 총매출/총 유저수
쉽게 말해 '객단가', 한 명의 유저가 평균 얼마를 지출했는지 알 수 있는 지표

# ARPPU (Average Revenue Per Paying Users)

유료 유저별 평균 매출
ARPPU = 총매출/총 유료 서비스 구매 유저
쉽게 말해 '결제자 객단가', 한 명의 유로 유저가 평균 얼마를 지출했는지 알 수 있는 지표

# Entrance, PV, UV

# Entrance (방문 수)

웹 사이트 방문에서 이탈까지 수행하는 통합 단위

# PV (Page View)

사이트 안에서 페이지를 조회한 횟수

ex) 1명이 블로그 글 2개를 읽는다면?
= PV는 2로 집계

# UV (Unique Visitors)

순방문자. 최초 세션을 일으킨 방문자
웹페이지에 방문한 사람의 수 의미
일반적으로 IP를 기준으로, 30분 단위로 쪼개서 계산

ex) 1명이 블로그 글을 여러번 본다면?
= UV는 1로 집계

ex) 1명이 블로그 글을 읽고, 30분 뒤에 한 번 더 본다면?
= UV는 2로 집계

# 0501 - Spring Bean vs Static method 언제 어느걸 사용해야할까?

먼저 여기서 말하는 static 함수 모음 class란 Apache Commons Lang StringUtils (opens new window)처럼 순전히 static 함수만을 가지고 있고, 객체를 생성하지 않고 사용하는 클래스를 의미한다.

static 함수 모음 클래스의 모든 함수는 인자가 동일할 경우 항상 동일한 결과를 리턴해야 한다. 이규칙을 지킬 수 없으면 POJO Bean으로 만들라.

이것이 이뤄지려면 함수 안에서는 외부 자원(Resource)에 대해 하나도 의존하면 안된다는 선결 조건을 충족해야 한다. 외부 자원은 그 실행 결과의 일관성을 보장할 수 없기 때문이다.

이에 가장 잘 들어맞는 예는 StringUtils (opens new window), CollectionUtils (opens new window) 같은 것들이다.

0418 ~ 0424 0502 ~ 0515