동시성(Concurrency)

여러 작업이 동시에 실행되는 것 처럼 보이는 것 EX) 하나의 CPU가 여러 작업을 번갈아 처리한다.

병렬성(Paralleslism)

하나 이상의 작업이 실제로 동시에 실행되는 것 EX) 이미지 처리 작업을 진행할 때 하나의 이미지를 여러 부분으로 분할하여 각 부분을 서로 다른 CPU가 처리한다.

교착상태(Deadlock)

둘 이상의 프로세스가 다른 프로세스가 점유하고 있는 자원을 서로 기다리고 있는 상태

데이터레이크

생성되는 데이터를 모두 저장해두는 것 (가공X)

데이터웨어하우스

생성된 데이터를 필터링/패키지화 해서 저장해두는 것

// yml 에 추가
// shutdown 엔드포인트 활성화 예시
management:
  endpoint: 
    shutdown:
      enabled: true 

스프링 actuator 노출

// yml 에 추가
// 모든 endpoints 들을 web (http) 에 노출 예시 
management:
  endpoints:
    web:
      exposure: 
        include: "*"

스프링 actuator endpoints

1. beans : 스프링 컨테이너에 등록된 스프링 빈을 보여준다.
2. conditions : condition 을 통해서 빈을 등록할 때 평가 조건과 일치하거나 일치하지 않는 이유를 표시한다.
3. configprops : @ConfigurationProperties 를 보여준다.
4. env : Environment 정보를 보여준다.
5. health : 애플리케이션 헬스 정보를 보여준다.
6. httpexchanges : HTTP 호출 응답 정보를 보여준다. HttpExchangeRepository 를 구현한 빈을 7. 별도로등록해야 한다.
7. info : 애플리케이션 정보를 보여준다.
8. loggers : 애플리케이션 로거 설정을 보여주고 변경도 할 수 있다.
9. metrics : 애플리케이션의 메트릭 정보를 보여준다.
10. mappings : @RequestMapping 정보를 보여준다.
11. threaddump : 쓰레드 덤프를 실행해서 보여준다.
12. shutdown : 애플리케이션을 종료한다. (default = 비활성화)

health

애플리케이션 헬스 정보 상세히 보기

// yml 에 추가
management:
  endpoint:
    health:
      show-details: always

info

os, java 정보 확인

// yml 에 추가
management:
  info:
    java:
      enabled: true
    os:
      enabled: true

build 정보 확인

// build.gradle 에 추가
 springBoot {
      buildInfo()
}

현재 build 된 git 정보 확인

// build.gradle 에 plugin 추가
plugins { 
        id "com.gorylenko.gradle-git-properties" version "2.4.1"
    }

loggers

실시간 로그레벨 변경 가능

post 요청을 통해 실시간으로 로그레벨을 변경 가능하다.
url : http://localhost:8080/actuator/loggers/me.jaden.actuator.controller
body(json) :
{
    "configuredLevel" : "TRACE"
}

액츄에이터 엔드포인트 접근 포트번호 변경

// yml에 추가
management:
  server:
    port: 9292

마이크로미터

마이크로미터를 통해 매트릭 등록

MeterRegistry

마이크로미터 기능을 제공하는 컴포넌트 스프링을 통해 주입받아 카운터, 게이지등을 등록한다.

• 비즈니스 로직에 직접 카운터 기능 추가

    @Override
    public void order() {
        log.info("주문");
        stock.decrementAndGet();
  
        Counter.builder("my.order")
                .tag("class", this.getClass().getName())
                .tag("method", "order")
                .description("order")
                .register(meterRegistry)
                .increment();
  
    }

• AOP 애노테이션을 활용한 카운터 기능 추가

1. CountedAspect 빈 등록

    @Bean
    public CountedAspect countedAspect(MeterRegistry meterRegistry) {
        return new CountedAspect(meterRegistry);
    }

2. 비즈니스 로직에 애노테이션 추가

    @Override
    @Counted("my.order")
    public void order() {
        log.info("주문");
        stock.decrementAndGet();
    }

프로매태우스 설정

설치 URL https://prometheus.io/download

1. application 에 의존성 추가

   //  yml에 추가
   implementation 'io.micrometer:micrometer-registry-prometheus'

2. promethus.yml 설정

    # 추가
    - job_name: "spring-actuator"
      metrics_path: '/actuator/prometheus' // 메트릭 경로 설정 
      scrape_interval: 1s // 수집주기 설정 (일반적으로 10 ~ 15s) 
      static_configs:
        - targets: ['localhost:8080'] // 타겟 서버경로

3. counter 와 gauage 값이 실시간으로 변화하는 gauage 는 그래프로 그대로 시각화 해도 의미파악이 쉽다. 그에 반해 counter 는 값이 지속적으로 증가만 함으로 그래프로 시각화 할 때는 increase(), rate() 같은 함수와 같이 사용해주어야 의미파악이 쉽게된다.

그라파나

설치 URL https://grafana.com/grafana/download

10.1.0 버전 설치 curl -O https://dl.grafana.com/enterprise/release/grafana-enterprise-10.1.0.darwin-amd64.tar.gz

그라파나 공유대시보드 (스프링) https://grafana.com/grafana/dashboards/11378-justai-system-monitor/

스토어드 프로시저 생성 방법

DELMITER $$ // 구분자 기호는 다른 기호여도 상관없다
CREATE PROCEDURE 스토어드_프로시저_이름()
BEGIN
 // SQL 코딩 
END $$
DELMITER ;

스토어드 프로시저 실행 방법

CALL 스토어드_프로시저_이름();

IF 문

IF <조건식> THEN
 SQL 문장
END IF; 

IF ELSE 문

IF <조건식> THEN
 SQL 문장
ELSE 
 SQL 문장
END IF; 

ex) 
DELIMITER %% 
CREATE PROCEDURE ifProc()
BEGIN 
 DECLARE myNum INT: // declare 예약어를 통해 myNum 변수 선언
 SET myNum = 200;   // 변수에 값 대입
   IF myNum = 100 THEN 
    SELECT '100입니다.';
   ESLSE 
    SELECT '100이 아닙니다.';
   END IF 
END %%
DELIMITER;

쿼리 결과를 변수에 대입하기

DECLARE debutDate DATE; // 변수 선언

SELECT debute_date INTO debutDate  // SELECT INTO 를 사용해 대입한다. 
FROM market_db.member
WHERE mem_id = 'APN'; 

내부조인(inner join)

가장 일반적인 형태의 join 이다. 일반적으로 그냥 join 을 한다고 하면 inner join 을 한다고 생각하면 된다.

join 을 하기 위해서는 테이블이 일대다(1:n) 관계로 연결되어 있어야 한다. 1:n 관계로 연결되어 있다는 것은 1번 테이블의 구분자를 2번 테이블이 FK로 여러개 가질 수 있다는 것을 의미한다. 예를들어, 회원과 구매테이블이 있을 때 1번 회원이 여러가지 상품을 구매할 수 있다면 회원과 구매는 1:n 관계를 가지고 있다고 할 수 있다.

다음과 같은 쿼리로 inner join 을 할 수 있다.

SELECT <열 목록> 
FROM <1번 테이블>
 INNER JOIN <2번 테이블> // INNER JOIN 대신 JOIN 이라 써도 INNER JOIN 된다.
 ON <조인될 조건> 
WHERE <검색 조건> // 생략가능

ex)
SELECT * 
FROM buy
 INNER JOIN member
 ON buy.member_id = member.member_id
WHERE buy.member_id = 'jaden'

별칭을 사용해서 쿼리를 간단하게 만들 수 있다.

ex)
SELECT * 
FROM buy b
 INNER JOIN member m
 ON b.member_id = m.member_id
WHERE b.member_id = 'jaden'

외부조인(outter join)

내부조인은 두 테이블에 모두 데이터가 있어야만 결과가 나오게 된다. 만약 한쪽에만 데이터가 있는 경우도 쿼리가 되어야 한다면 외부조인을 사용할 수 있다.

쿼리는 다음과 같다

SELECT <열 목록>
FROM <1번 테이블> <-- LEFT 테이블
 <LEFT || RIGHT || FULL> OUTER JON <2번 테이블> <-- RIGHT 테이블
 ON <조인될 조건>
WHERE <검색조건> // 생략가능

ex)
SELECT m.member_id, m.member_name, b.product_name
FROM member m 
 LEFT OUTER JOIN buy b // LEFT OUTER JOIN 은 LEFT JOIN 으로 축약가능하다 
 ON m.member_id = b.member_id
ORDER BY m.member_id;

LEFT OUTER JOIN 의 의미는 LEFT 테이블의 내용은 모두 출력되어야 한다라는 의미이다. RIGHT OUTER JOIN 도 마찬가지로 RIGHT 테이블의 내용은 모두 출력된다. FULL OUTER JOIN 은 왼쪽 및 오른쪽 테이블 어디든 한쪽에라도 데이터가 있다면 출력된다.

1. docker redis 설치

   docker run --name redis -p 6379:6379 -d redis:alpine

2. docker MySQL 설치

   docker run --name mysql-container -e MYSQL_ROOT_PASSWORD=<password> -d -p 3306:3306 mysql:latest

   3. JDK 17, spring boot 3.1.2

   4. dependecies

      dependencies {
      // spring
      implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
      implementation 'org.springframework.boot:spring-boot-starter-data-redis'
      implementation 'org.springframework.boot:spring-boot-starter-web'
      implementation 'org.springframework.boot:spring-boot-starter-cache'
      
      // db driver
      implementation 'com.mysql:mysql-connector-j'
      
      // etc
      compileOnly 'org.projectlombok:lombok'
      annotationProcessor 'org.projectlombok:lombok'
      
      // test
      testImplementation 'org.springframework.boot:spring-boot-starter-test'
      }
      

RedisCacheConfiguration 빈 등록

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cache.annotation.EnableCaching;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.cache.RedisCacheConfiguration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.RedisSerializationContext;
import org.springframework.data.redis.serializer.StringRedisSerializer;

import java.time.Duration;

@Configuration
@EnableCaching
public class RedisCacheConfig {

    @Value("${spring.redis.host}")
    private String host;

    @Value("${spring.redis.port}")
    private int port;

    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory(host, port);
    }

    @Bean
    public RedisCacheConfiguration redisCacheConfiguration() {
        return RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofSeconds(60)) // 캐시된 엔트리들의 만료 시간(TTL - Time to Live)을 설정
                .disableCachingNullValues() // null 값을 캐시로 저장하지 않도록 하는 옵션
                .serializeKeysWith(
                        RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()) // 캐시의 키를 직렬화(serialize)하는 방식을 지정
                )
                .serializeValuesWith(
                        RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()) // 캐시의 값(value)을 직렬화하는 방식을 지정
                );
    }
}

조회 시 캐싱 적용

import lombok.RequiredArgsConstructor;
import me.jaden.redisstudy.member.api.request.MemberJoin;
import me.jaden.redisstudy.member.api.response.MemberView;
import me.jaden.redisstudy.member.domain.Member;
import me.jaden.redisstudy.member.repository.MemberRepository;
import org.springframework.cache.annotation.Cacheable;
import org.springframework.dao.EmptyResultDataAccessException;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
@RequiredArgsConstructor
@Transactional
public class MemberService {

    private final MemberRepository memberRepository;

    public Long joinMember(MemberJoin memberJoin) {
        Member joinedMember = memberRepository.save(memberJoin.convertToMember());
        return joinedMember.getId();
    }

     // 캐싱적용
    @Transactional(readOnly = true)
    @Cacheable(value = "memberView", key = "#memberId")
    public MemberView findById(Long memberId) {
        Member member = findMember(memberId);
        return MemberView.convertFromMember(member);
    }

    private Member findMember(Long memberId) {
        return memberRepository.findById(memberId)
                .orElseThrow(() -> new EmptyResultDataAccessException(memberId + "에 해당하는 회원이 존재하지 않습니다.", 1));
    }
}

테스트코드

import me.jaden.redisstudy.member.api.response.MemberView;
import me.jaden.redisstudy.member.domain.Member;
import me.jaden.redisstudy.member.repository.MemberRepository;
import me.jaden.redisstudy.member.service.MemberService;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.mock.mockito.MockBean;
import org.springframework.cache.Cache;
import org.springframework.cache.CacheManager;

import java.util.Optional;

import static org.assertj.core.api.Assertions.assertThat;
import static org.mockito.BDDMockito.given;
import static org.mockito.Mockito.times;
import static org.mockito.Mockito.verify;

@SpringBootTest
public class CacheTest {
    @MockBean
    private MemberRepository memberRepository;

    @Autowired
    private MemberService memberService;

    @Autowired
    private CacheManager cacheManager;

    private static final Long MEMBER_ID = 1l;

    @AfterEach
    void removeCache() {
        Cache cache = cacheManager.getCache("memberView");
        if (cache != null) {
            cache.evict(MEMBER_ID);
        }
    }

    @Test
    void cacheTest() {
        Member member = Member.builder()
                .id(MEMBER_ID)
                .name("jaden")
                .age(29)
                .email("jaden@email.com")
                .build();

        given(memberRepository.findById(MEMBER_ID))
                .willReturn(Optional.of(member));

        MemberView cacheMiss = memberService.findById(MEMBER_ID);
        MemberView cacheHit = memberService.findById(MEMBER_ID);

        assertThat(cacheMiss).isEqualTo(MemberView.convertFromMember(member));
        assertThat(cacheHit).isEqualTo(MemberView.convertFromMember(member));

        verify(memberRepository, times(1)).findById(MEMBER_ID);
    }
}

깃헙

변수선언 및 값 대입은 다음과 같다

SET @변수이름 = 변수 값;

// examples 

SET @myVar1 = 5;
SET @myVar2 = 4.25;

SELECT @myVar1; // 5
SELECT @myVar1 + @myVar2; // 9.250000..

SET @txt = '가수 이름==> ';
SET @height = 166;

SELECT @txt, mem_name FROM member WHERE height > @height;
/* 결과값 예시
가수 이름==> 소녀시대
가수 이름==> 트와이스
*/

주의사항

1. LIMT 에서는 변수를 사용할 수 없다.

   SET @count = 3;
   SELECT mem_name, height FROM member ORDER BY height LIMIT @count; // 문법 오류

2. PREPARE, EXECUTE-USING 을 사용해 변수를 대입할 수 있다.

   SET @count = 3;
   PREPARE mySQL FROM 'SELECT mem_name, height FROM member ORDER BY height LIMIT ?';
   

EXECUTE mySQL USING @count; ```

1. TINYINT 1바이트

-128 ~ 127 2. SMALLINT 2바이트 -32768 ~ 32767 3. INT 4바이트 약 -21억 ~ +21억 4. BIGINT 8바이트 약 -900경 ~ +900경

UNSIGNED 예약어

음수를 제외시키는 예약어

CREATE TABLE member 
(
 height TINYINT UNSIGNED  // tinyint 는 -127 ~ 128 표현범위를 가지지만 UNSIGNED 예약어로 0~255를 표현한다. 
); 

문자형

1.CHAR 고정길이 문자형. CHAR(10) 에 3글자를 저장하면 7자리는 낭비하는 셈 최대 255자 장점: 성능면에서 VARCHAR 보다 빠르다. 2.VARCHAR 가변길이 문자형. VARCHAR(10) 에 3글자를 저장하면 3자리만 사용한다. 최대 16383자

대량 데이터

1.TEXT 최대 65535자 2.LONGTEXT 최대 약 42억자 3.BLOB 최대 65535 바이트 4.LONGBLOLB 최대 약 42억 바이트

TEXT와 BLOB

TEXT는 문자형 저장, BLOB은 이진 데이터 저장(사진, 동영상)

실수형

1. FLOAT 4바이트, 소수점 아래 7자리
2. DOUBLE 8바이트, 소수점 아래 15자리

날짜형

1. DATE 날짜만 저장, YYYY-MM-DD 형식
2. TIME 시간만 저장, HH:MM:SS 형식
3. DATETIME 날짜 및 시간 저장, YYYY-MM-DD HH:MM:SS

구체적으로 어떤 인스턴스를 만들지는 서브 클래스가 정하도록 하는 생성패턴

구조 (ref by.리팩토링구루)

장점

Creator 와 Product 간 결합도를 낮춰 OCP 원칙을 지키면서 확장할 수 있다.

시스템 내에서 사용 할 인스턴스를 하나만 제공할 수 있도록 하는 생성패턴

왜 필요한가?

시스템 런타임, 환경 세팅에 대한 정보등 인스턴스가 여러개가 있어서는 안되는 경우가 있다.

구현방법

1. 생성자를 외부에서 사용할 수 없도록 해야한다.

   public class Single {
    private Single() {}; // 접근제어자를 통해 외부에서 생성자 접근 못하도록 한다.
   }
   

2. 외부에서 인스턴스에 접근할 수 있는 메소드를 제공해야한다.

public class Single {

private Single() {};

// 외부에서 인스턴스에 접근 가능한 메소드 제공 public static Single getInstance() { return new Single(); }

}

3. 외부에서 인스턴스에 접근할 때 동일한 인스턴스를 제공해야한다.

public class Single {

private static Single instance;

private Single() {};

public static Single getInstance() {
    if(instance == null) {
        instance = new Single();
    }
    return instance;
}

}

4. 멀티쓰레드 환경에서도 안전하게 싱글톤 인스턴스를 제공해야 한다. 
4.1 synchronized 를 활용한다.

public class Single {

private static Single instance;

private Single() {};

public static synchronized Single getInstance() {
    if(instance == null) {
        instance = new Single();
    }
    return instance;
}

}

4.2 클래스 로딩 시점에 인스터를 생성해 사용한다.

public class Single {

private static final Single INSTANCE = new Single();

private Single() {};

public static Single getInstance() {
    return INSTANCE;
}

}

4.3 double checked locking 을 통해 synchronized 비용을 최소화한다. 
- 4.1 에서는 인스턴스 접근시 항상 syncronized 되지만, double checked locking 을 활용하면 인스턴스가 한번 생성된 상태라면 synchronized 처리가 되지 않음으로 성능상 뛰어나다

public class Single {

private static volatile Single instance;

private Single() {};

public static Single getInstance() {
    if(instance == null) {
        synchronized (Settings.class) {
            if(instance == null) {
                instance = new Single();
            }
        }
    }
    return instance;
}

}

4.4 static inner 클래스 활용 

public class Single {

private Single() {};

private static class SingleHolder() {
    private static final Single INSTANCE = new Single();
}

public static Single getInstance() {
    return SingleHolder.INSTANCE;
}

}

### 싱글톤 패턴 우회

1. Reflection 을 활용하여 싱글톤 패턴 우회

    Single single = Single.getInstance();

    Constructor<Single> declaredConstructor = Single.class.getDeclaredConstructor();
    declaredConstructor.setAccessible(true);
    Single reflectedSingle = declaredConstructor.newInstance();

    System.out.println(single == reflectedSingle); // 결과 : false

```` 2. 인스턴스를 직렬화 후 역직렬화 한다.

JPA 는 많은 기능을 지원한다. 객체간 서로 참조를 하는 부분도 양방향 연관관계를 잘 사용만 하면 큰 문제 없이 사용할 수 있다. 하지만 이런 방법을 잘 사용하는게 최선이라고는 할 수 없다. 객체간의 관계가 복잡해지면, 사용하는 입장에서 관계들을 이해하는게 어려울 수 밖에 없다. 따라서 가능하다면 연관관계를 줄이고, 필요한 경우 단방향 연관관계를 통해서 문제를 해결하도록 하자.

연관관계 Tip

@ManyToOne

실무에서 가장 많이 사용하는 N:1 연관관계이다. 테이블 입장에서 생각을 해봤을 때도 N 쪽에 FK 가 들어가는 만큼 비즈니스 코드와 그에 따른 SQL이 자연스럽게 이어질 가능성이 높다.

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class Member {

    @Id
    @GeneratedValue
    private Long id;
    private String name;
    private int age;
    @ManyToOne
    private Team team;

    public Member(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public void joinTeam(Team team) {
        this.team = team;
    }
}

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class Team {

    @Id
    @GeneratedValue
    private Long id;
    private String name;

    public Team(String name) {
        this.name = name;
    }
}

///// Member 의 ManyToOne 활용

    public static void main(String[] args) {
         EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();

        try {
            Team teamA = new Team("teamA");
              em.persist(teamA);

            Member member = new Member("jaden", 29);
            em.persist(member);

              em.flush();
            em.clear();

            Member findMember = em.find(Member.class, member.getId());

            findMember.joinTeam(teamA);
            em.persist(findMember);
            tx.commit();

        } catch (Exception e) {
            tx.rollback();
        } finally {
            em.close();
        }
        emf.close();
    }

// mfindMember.joinTeam(teamA) 쿼리 결과는 member 객체를 조작해 
// Member 테이블에 대한 update 쿼리가 발생하여 자연스럽다. 
update
    Member 
        set
            age=?,
            name=?,
            team_id=? 
        where
            id=?

@OneToMany

불가피하게 사용하게 된다면 @JoinColumn 을 사용한다. 그렇지 않으면 기본적으로 JoinTable 방식을 사용하게 되어 의도하지 않은 테이블을 생성하게 된다. 의도한 경우가 아니라면 @JoinColumn 을 사용한다. 따라서 1:n 단방향 매핑을 사용해야하는 경우라면 n:1 양방향 매핑을 고려한다.(권장한다)

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class Member {

    @Id
    @GeneratedValue
    private Long id;
    private String name;
    private int age;

    public Member(String name, int age) {
        this.name = name;
        this.age = age;
    }
}

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class Team {

    @Id
    @GeneratedValue
    private Long id;
    private String name;
    @OneToMany
    @JoinColumn(name = "member_id")
    private List<Member> members = new ArayList<>();

    public Team(String name) {
        this.name = name;
    }

    public void addMember(Member member) {
        members.add(member);
    }
}

///// team 에 OneToMany 활용
        EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();

        Member member = new Member("jaden", 29);
        em.persist(member);

        Team teamA = new Team("teamA");
        em.persist(teamA);

        em.flush();
        em.clear();

        Member findMember = em.find(Member.class, member.getId());
        Team findTeam = em.find(Team.class, teamA.getId());

        findTeam.addMember(findMember);

// findTeam.addMember(findMember) 쿼리 결과는 team 을 조작하지만
// Member 테이블에 대한 update 쿼리가 발생하여 부자연스럽다. 
// 더불어 업데이트할 member 를 조회해야 해 성능적으로도 불리하다.

Hibernate: 
    select
        members0_.member_id as member_i4_0_0_,
        members0_.id as id1_0_0_,
        members0_.id as id1_0_1_,
        members0_.age as age2_0_1_,
        members0_.name as name3_0_1_ 
    from
        Member members0_ 
    where
        members0_.member_id=?
Hibernate: 
    /* create one-to-many row me.jaden.Team.members */ update
        Member 
    set
        member_id=? 
    where
        id=?

@OneToOne

1:1 연관관계는 FK 를 원하는 테이블에 둘 수 있다. 예를들어 회원과 락커라는 엔티티가 있다면 회원 테이블에 락커ID 를 FK 로 둬도, 락커 테이블에 회원ID 를 FK로 두어도 된다. 비즈니스 적으로 회원이 주도적이라고 생각한다면, FK를 회원에 두고 사용하는 것이 편할 것이다. 예를들어 회원이 락커를 등록할 수 있다고 생각해보자.

// 회원 엔티티
@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class Member {

    @Id
    @GeneratedValue
    private Long id;
    private String name;
    private int age;
    @OneToOne
    @JoinColumn(name = "locker_id")
    private Locker locker;

    public Member(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public void registerPersonalLocker(Locker locker) {
        this.locker = locker;
    }
}

// 락커 엔티티
@Entity
@NoArgsConstructor
@Getter
public class Locker {

    @Id
    @GeneratedValue
    private Long id;
    private int number;

    public Locker(int number) {
        this.number = number;
    }
}

// 회원이 락커 등록
        EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();
        try {
            Locker firstLocker = new Locker(1);
            em.persist(firstLocker);

            Member member = new Member("jaden", 29);
            em.persist(member);

            em.flush();
            em.clear();

            Locker getLocker = em.find(Locker.class, firstLocker.getId());
            Member getMember = em.find(Member.class, member.getId());

            # 회원이 락커를 등록한다.
            getMember.registerPersonalLocker(getLocker);

            tx.commit();
       }... 

// getMember.registerPersonalLocker(getLocker); 에 대한 SQL
        update
            Member 
        set
            age=?,
            locker_id=?,
            name=? 
        where
            id=?

의도한 대로 동작하고 있는 것을 확인할 수 있었다. 하지만, DB관점에서 생각해도록 하자. 어떠한 회원은 락커를 등록하지 않을 수 도있다. 그러면 회원 테이블의 FK 에는 null 이 들어갈 것이다. 혹은, 한명의 회원이 여러개의 락커를 사용할 수 있게 비즈니스 로직을 수정해야 한다면 테이블이 수정되어야 한다. 그렇다면 FK를 락커로 옮기고 단방향으로 Member를 통해 락커를 등록할 수 있을까? 아쉽지만 JPA 는 해당 부분을 지원하기 어렵다. 대신 양방향 관계를 맺어 사용할 수 는 있다.

@Entity
@NoArgsConstructor
@Getter
public class Locker {

    @Id
    @GeneratedValue
    private Long id;
    private int number;
    @OneToOne
    @JoinColumn(name = "member_id")
    private Member owner;

    public Locker(int number) {
        this.number = number;
    }

    public void setOwner(Member owner) {
        this.owner = owner;
    }
}

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
@Setter
public class Member {

    @Id
    @GeneratedValue
    private Long id;
    private String name;
    private int age;
    @OneToOne(mappedBy = "owner")
    private Locker locker;

    public Member(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public void registerPersonalLocker(Locker locker) {
        this.locker = locker;
        locker.setOwner(this);
    }
}

// FK 는 락커테이블에 있지만 양방향관계를 통해 Member 에서 락커등록
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin();
    try {
            Locker firstLocker = new Locker(1);
            em.persist(firstLocker);

            Member member = new Member("jaden", 29);
            em.persist(member);

            em.flush();
            em.clear();


            Locker getLocker = em.find(Locker.class, firstLocker.getId());
            Member getMember = em.find(Member.class, member.getId());

            System.out.println("====");
            getMember.registerPersonalLocker(getLocker);

             tx.commit();
       }... 

#  getMember.registerPersonalLocker(getLocker); 에 대한 SQL 쿼리
         update
            Locker 
        set
            number=?,
            member_id=? 
        where
            id=?

다만, 이 경우 지연로딩(LazyLoading)을 사용할 수 없게된다.

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
@Setter
public class Member {

    @Id
    @GeneratedValue
    private Long id;
    private String name;
    private int age;
    @OneToOne(mappedBy = "owner", fetch = FetchType.LAZY) // lazyLoading 설정
    private Locker locker;

    public Member(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public void registerPersonalLocker(Locker locker) {
        this.locker = locker;
        locker.setOwner(this);
    }
}

///// 사용코드

        EntityManager em = emf.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin();
        try {
            Locker firstLocker = new Locker(1);
            em.persist(firstLocker);

            Member member = new Member("jaden", 29);
            em.persist(member);

            em.flush();
            em.clear();


            System.out.println("====");
            Member getMember = em.find(Member.class, member.getId()); // member 를 조회할 때 locker 를 lazyLoading 해오는지 확인해보자
            tx.commit();

# 쿼리 확인 
====
Hibernate: 
    select
        member0_.id as id1_1_0_,
        member0_.age as age2_1_0_,
        member0_.name as name3_1_0_,
        member0_.team_id as team_id4_1_0_ 
    from
        Member member0_ 
    where
        member0_.id=?
Hibernate: 
    /* load me.jaden.Locker */ select
        locker0_.id as id1_0_1_,
        locker0_.number as number2_0_1_,
        locker0_.member_id as member_i3_0_1_,
        member1_.id as id1_1_0_,
        member1_.age as age2_1_0_,
        member1_.name as name3_1_0_,
        member1_.team_id as team_id4_1_0_ 
    from
        Locker locker0_ 
    left outer join
        Member member1_ 
            on locker0_.member_id=member1_.id 
    where
        locker0_.member_id=?

쿼리 결과를 보면 알 수 있듯이 lazyLoading 을 설정해도 eagerLoading 을 해버린다. 이유는 JPA 가 프록시 객체를 생성할 때 Member 의 Locker 가 null 인지 아닌지 확인하기 FK가 Locker 에 있기 때문에 Locker 를 어쩔 수 없이 조회해버리기 때문이다.

@ManyToMany

@ManyToMany 는 실무에서 잘 사용하지 않는다. (연결테이블을 JPA가 관리함으로 연결테이블의 컬럼들을 컨트롤 할 수 없기 떄문) 관계형 DB 에서는 다대다 관계를 테이블 2개로는 풀어낼 수 없다. 연결테이블을 만들어 일대다+다대일 관계로 풀어내야 한다. 그래서 @ManyToMany 를 사용하면 JPA 는 매핑정보를 보고 연결테이블을 생성해 사용하게되는데, 단순 열결이 목적이라면 불필요하면 엔티티 클래스를 생성하지 않아도 된다는 장점이 있을 수 있지만, 실무에서 단순 연결만하는 경우가 극히 드물기 떄문에 일반적으로 @ManyToMany 를 사용하기 보다는 연결테이블을 엔티티로 만들어 필요한 기능들을 집어넣어 사용하게 된다.

JPA 와 프록시

LazyLoading 과 같은 기법을 사용하기 위해 JPA는 프록시 객체를 활용한다. JPA 가 프록시를 사용하기에 주의해야할 부분이 몇 가지 있는데, 비즈니스 로직에서 객체의 타입을 체크해야할 때, 해당 타입이 원본 객체일지 프록시 객체일지 명확한 구분이 힘들기에 == 대신 instance of 를 통해 타입을 비교한다.

왜 구분이 어려운가?

영속성컨택스트에 프록시객체로 저장되면 프록시객체가 반환되고, 실제객체가 저장되면 실제객체가 반환되기 때문이다. 만약 프록시 객체가 들어간 상태에서 xxxx.getClass() == xxx.class 와 같이 타입을 비교하면 false 가 나오게 되어 원하지 않는 결과를 얻게된다.

JPQL 주의사항

JPQL 을 통해 연관관계를 가진 경로를 탐색할 시 묵시적 내부 조인이 발생한다. (join 을 명시적으로 사용하지 않아도 join이 된다) 팀 전체가 JPA와 JPQL에 익숙하다면 괜찮을지 모르겠지만, 그렇지 않다면 묵시적 내부조인이 일어나는 경우에도 명시적으로 join 을 사용하도록 하자.

Fetch join 주의사항

1. 페치조인 대상에는 별칭을 줄 수 없다 하이버네이트를 사용하면 가능하지만 가급적 사용하지 않는다. (데이터 정합성 문제 발생 가능성 있음), 다만 fetch join 대상에서 fetch join 이 일어날 경우는 사용할 수 도 있다.
2. 둘 이상의 컬렉션은 페치조인 할 수 없다.
3. 컬렉션 페치조인 시 페이징을 사용할 수 없다. (데이터 뻥튀기 문제) 일대일, 다대일은 가능하다. (뻥튀기 안일어나니) 하이버네이트를 사용하면 메모리에서 페이징 처리를 애플리케이션 레벨에서 진행하는데 당연히 OOM 위험이 생기게 된다.

컬렉션 페치조인 페이징을 해결하는 방법?

1. 일대다 관계인 경우 반대방향(다대일)에서 쿼리를 날려 페이징을 한다.
2. 페치조인 없이 조회 한 후 @BatchSize 활용해 lazyLoading 을 한다. (비교적 n+1 문제에서 자유로움) batch fetch size 는 글로벌 설정도 가능하다.

변경감지와 merge()

엔티티를 수정해야하는 경우 JPA 의 변경감지 기능을 사용한다. merge() 를 사용할 경우 엔티티 전체를 변경하는 형태이기에, 변경하지 않은 필드에 null 이나 0 과같은 값이 세팅될 수 있기 때문이다.

fetchType EAGER

n+1 문제를 해결하기 위해 fetchType 을 eager 로 설정한다고 해도 JPQL 이 실행되는 경우에는 n+1 문제가 해결되지 않는다. JPQL 은 그대로 SQL 로 번역되어 DB에 결과를 가져오고 JPA가 eager 패치타입을 확인 후 아직 채워지지 않은 데이터들을 채우기 위해 n+1 select 쿼리가 발생한다. entityManager.find() 만을 사용하는 경우라면 원하는대로 join 쿼리를 JPA 가 생성해 보내지만, JPQL 을 사용하는 순간 원하지 않는 N+1 문제가 발생할 수 있음으로 fetchtype 을 EAGER 로 설정하지 않도록 하자

일대다관계 fetch join

일대다관계(컬렉션)을 조인하여 가져올 때 조회의 주체를 기준으로 데이터가 부풀려진다. (n 관계의 데이터를 조회하니 당연한 일이다.) 이를 해결하기 위해서는 distinct 를 사용해 중복을 제거해야할 필요가 있다. 다만 hibernate6 기준으로는 일대다관계를 fetch join 하는 경우 distinct 를 선언하지 않아도 적용된 데이터를 가져온다.

• distinct 는 DB 의 distinct 와는 다르다. SQL 의 distinct 는 완전한 중복일 때 중복을 제거하고, fetch join 시 JPA 가 하는 distinct 는 조회 주체의 ID를 기준으로 컬렉션을 만들어주는 개념이라고 보는게 좋다.
• 컬렉션 fetch join 시 페이징 처리를 해서는 안된다. (하이버네이트는 페이징할 모든 데이터를 메모리에 전부 가져와 어플리케이션 레벨에서 페이징을 시도한다. -> OOM 위험)
• 컬렉션 패치조인은 1개만 사용가능하다. 1:n:n -> 불가, (1:n) * 2 -> 불가

일대다관계(컬렉션)을 가져오면서 페이징이 필요한 경우에는, xxxToOne 관계는 모두 fetchJoin 을 통해 가져온 후, 컬렉션은 지연로딩을 사용하여 가져온다. 다만 이 때 batchSize 를 설정함으로써 성능최적화를 이끌어낸다.

-- yml 을 통한 global 배치사이즈 설정
spring:
 jpa: 
  properties:
   default_batch_fetch_size: 100 # 배치사이즈 100

-- @BatchSize 애노테이션 설정
    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    @BatchSize(size = 100)
    private List<OrderItem> orderItems = new ArrayList<>();

OSIV

spring.jpa.open-in-view: true (기본값) 기본값에 따라 데이터베이스 커넥션 시작 시점부터 API 응답이 끝날 때 까지 영속성 컨텍스트와 데이터베이스 커넥션을 유지한다. -> API controller 나 viewTemplate 에서 지연로딩이 가능해짐 -> 커넥션을 너무 오래물고 있어 커넥션이 부족해지는 상황을 초래한다.

OSIV 설정을 끄면 트랜잭션이 종료될 때 반환한다.

Spring Data JPA page 활용 (DTO반환)

page.map 을 활용하면 쉽게 변환 가능

    public static Page<MemberDto> pageable(Page<Member> members) {
        return members.map(member -> new MemberDto(member.getUsername(), member.getAge()));
    }

Spring 데이터 JPA 사용과 @GeneratedValue

Spring Data Jpa 를 사용하면, JpaRepository 인터페이스의 구현체 SimpleJpaRepository 를 사용하는 경우가 많다. 이 때, save() 를 확인해보면 새로운 객체인 경우 persist() 를 호출하고 기존에 있는 객체라면 merge() 를 호출하는 다음의 코드를 확인 할 수 있다.

    @Transactional
    @Override
    public <S extends T> S save(S entity) {

        Assert.notNull(entity, "Entity must not be null");

        if (entityInformation.isNew(entity)) {
            em.persist(entity);
            return entity;
        } else {
            return em.merge(entity);
        }
    }

새로운 객체의 판단여부는 id 값이 null인지(래퍼런스타입) 혹은 0인지(프리미티브타입)를 통해 판단하게 되는데, @GeneratedValue 를 사용한다면 persist 이후에 id 가 세팅되지만, 만약 직접 id 를 생성해주는 경우라면 null 이 아니기에 merge 가 호출되고 이는 성능악화(select 이후 save) 를 야기한다. 따라서 직접 id 를 세팅해주는 경우라면 Pesistable 을 엔티티에서 구현하여 isNew() 메소드를 오버라이딩해야한다. 가장 간단한 방법은 createdDate 를 사용하여 해당 필드가 null 이라면 새로운객체라고 판단하는 방법이 있다.

@Entity
public class Item implements Persistable<String> {
    @Id
    private String id;

    @CreatedDate
    private LocalDateTime createdDate;

    @Override
    public String getId() {
        return this.id;
    }

    @Override
    public boolean isNew() {
        return createdDate == null;
    }
}
```

스프링 배치 메타 데이터

스프링 배치의 실행 및 관리 목적의 도메인(Job, Step..) 정보들을 저장, 업데이트, 조회할 수 있는 스키마를 제공 DB 와 연동할 경우 필수적으로 메타 테이블이 생성되어있어야 한다.

스키마 파일 위치 : /org/springframework/batch/core/schema-*.sql

• 스키마 생성 방법 및 설정

1. 수동 생성 - 스키마 파일에서 쿼리 복사 후 직접 실행
2. 자동 생성 spring.batch.jdbc.initialize-schema 설정 (always : 스크립트 항상 실행, embedded: 내장 DB 일때만 실행, never: 스크립트 항상 실행 안함)
   • 운영환경에서는 수동생성할 것

• 스프링 배치 스키마
  1. BATCH_JOB_INSTANCE job 이 실행될 때 jobInstance 정보가 저장 job_name 과 job_key 를 합쳐 unique
  2. BATCH_JOB_EXECUTION job 의 실행정보 저장 job 생성, 시작, 종료시간, 실행상태 메시지 등을 관리
  3. BATCH_JOB_EXECUTION_PARAMS job과 함께 실행되는 jobParameter 정보 저장
  4. BATCH_JOB_EXECUTION_CONTEXT
  ****job 의 실행동안 여러가지 상태정보, 공유 데이터를 직렬화(json) 해서 저장 step 간 서로 공유 가능
  5. BATCH_STEP_EXECUTION step 의 실행정보 저장 step 생성, 시작, 종료시간, 실행상태 메시지 등을 관리
  6. BATCH_STEP_EXECUTION_CONTEXT step 의 실행동안 여러가지 상태정보, 공유 데이터를 직렬화 해서 저장. step 별로 저장되며 step 간 서로 공유할 수 없음

스프링 배치 도메인

• JobInstance

  Job 이 실행될 때 생성되는 Job 의 논리적 실행 단위 객체로 고유하게 식별 가능한 작업 실행을 나타낸다.

  Job 의 설정과 구성은 동일하지만 Job 이 실행되는 시점에 처리하는 내용이 다르기 때문에 Job 의 실행을 구분한다. (하루에 3번씩 Job 이 실행되면 3개의 JobInstance 가 생성)

• JobParameter

  Job 을 실행할 때 함께 포함되어 사용되는 파라미터를 가진 도메인 객체

  하나의 Job 에 존재할 수 있는 여러개의 JobInstance 를 구분하기 위한 용도

  생성 및 바인딩 방법

  1. 어플리케이션 실행 시 주입 java -jar LogBatch.jar requestDate=20210101

  2. 코드로 생성 JobParameterBuilder, DefaultJobParameterConverter

  3. SpEL 이용 @Value(”#{jobParameter[requestDate]}”), @JobScope, @StepScope 선언 필수

     JobParameter 를 코드에서 참조방법

     @Bean
      public Step step1() {
          return stepBuilderFactory.get("step1")
                  .tasklet((contribution, chunkContext) -> {
                                          // contribution 에서 참조
                      JobParameters jobParameters = contribution.getStepExecution().getJobParameters();
                                          // chunkContext 에서 참조해서 파라미터 값 확인
                      Map<String, Object> jobParameters1 = chunkContext.getStepContext().getJobParameters();
     
                      return RepeatStatus.FINISHED;
                  })
                  .build();
      }

• JobExecution

  JobInstance 에 대한 한번의 시도를 의미하는 객체 Job 실행 중에 발생한 정보들을 저장하고 있는 객체

  JobExecution 은 FAILED 또는 COMPLETED 등의 Job 실행 결과 상태를 가지고 있음 상태가 COMPLETED 면 재실행이 불가함 상태가 FAILED 면 재실행이 가능함

  JobExecution 의 실행 결과 상태가 COMPLETED 가 될 때 까지 JobInstance 내에서 여러 번의 시도가 생길 수 있다.

• Step

  Batch Job 을 구성하는 독립적인 하나의 단계로 실제 배치 처리를 정의하고 컨트롤하는데 필요한 정보를 가진 객체

  배치작업을 어떻게 구성하고 실행할 것인지 Job 세부 작업을 Task 기반으로 설정하고 명세해 놓은 객체

  • TaskletStep : 가장 기본이 되는 클래스로서 Tasklet 타입의 구현체들을 제어한다.
  • PartionStep: 멀티 쓰레드 방식으로 Step 을 여러 개로 분리해서 실행한다.
  • JobStep: Step 내에서 Job 을 실행하도록 한다.
  • FlowStep: Step 내에서 Flow 를 실행하도록 한다.

• StepExecution

  Step 에 대한 한번의 시도를 의미하는 객체 Step 실행 중에 발생한 정보들을 저장하고 있다. Step 이 매번 시도될 때 마다 생성되며 각 Step 별로 생성된다. Job 이 재시작 하더라도 이미 성공적으로 완료된 Step 은 재 실행되지 않고 실패한 Step 만 실행된다.

• StepContribution

  청크 프로세스 변경 사항을 버퍼링 한 후 StepExecution 상태를 업데이트하는 도메인 객체 청크 커밋 직전에 StepExecution 의 apply() 메소드를 호출하여 상태를 업데이트 ExitStatus 의 기본 종료코드 외 사용자 정의 종료코드를 생성하여 적용할 수 있다.

• ExecutionContext

  프레임워크에서 유지 및 관리하는 키/값으로 된 컬렉션으로 StepExecution 또는 JobExecution 객체의 상태를 저장하는 공유 객체

  DB 에 직렬화 한 값으로 저장됨

  공유 범위

  • Step 범위 : 각 Step 의 StepExecution 에 저장되며 Step 간 서로 공유 안됨

  • Job 범위 : 각 Job 의 JobExecution 에 저장되며 Job 간 서로 공유 안되며 해당 Job 의 Step 간 서로 공유됨

    실패한 Job 재 시작 시 이미 처리한 Row 데이터는 건너뛰고 이후부터 수행할 수 있도록 할 때 ExecutionContext 를 활용할 수 있다.

• JobRepository

  배치 작업 중의 정보를 저장하는 저장소 역할 배치 작업의 수행과 관련된 모든 meta data 를 저장

  @EnableBatchProcessing 애노테이션 선언시 JobRepository 가 자동으로 빈으로 등록

  BatchConfigurer 인터페이스를 구현하거나 BasicBatchConfgiurer 를 상속하여 JobRepository 설정 커스터마이징 가능

• JobLauncher

  배치 Job 을 실행시키는 역할을 한다. Job 과 JobParameters 를 인자로 받아 요청된 배치 작업을 수행한 후 최종 client 에게 JobExecution 을 반환

  스프링 부트 배치가 구동되면 JobLauncher 빈이 자동 생성된다.

  Job실행

  • JobLauncher.run(Job, Jobparameters)
  • 스프링 부트 배치에서는 JobLauncherApplicationRunner 가 자동으로 JobLauncher 실행
  • 동기적 실행
    • taskExecutor 를 SyncTaskExecutor 로 설정 (기본값)
    • JobExecution 을 획득하고 배치 처리를 최종 완료한 이후 Client 에게 JobExecution 반환
    • 스케쥴러에 의한 배치처리에 적합
  • 비동기적 실행
    • taskExecutor 를 SimpleAsyncTaskExecutor 로 설정
    • JobExecution 을 획득한 후 Client 에게 바로 JobExecution 을 반환하고 배치처리를 완료한다.
    • HTTP 요청에 의한 배치처리에 적합

스프링 부트 배치 설정

1. JobLauncherApplicationRunner

• BatchAutoConfiguration 에서 생성

• 애플리케이션 정상적으로 구동될 때 마다 실행됨

• 기본적으로 빈으로 등록된 모든 job 을 실행시킴

    spring:
        batch:
          job:
            enabled: true 
    # (기본값 true 사용하고 싶지 않은경우 false 설정할 것) 

2. BatchProperties

• Spring Batch 환경 설정 클래스
• Job 이름, 스키마 초기화 설정, 테이블 prefix 등의 값 설정 가능
• application.yml 파일에서 설정

3. Job 실행 옵션

• 지정한 Batch Job 만 실행하도록 할 수 있다.

    spring:
        batch:
            job:
                names: ${job.name:NONE}

  • 애플리케이션 실행 시 programArguments 로 job 이름 입력 --job.name=helloJob,simpleJob

스프링 배치가 제공하는 빌더 클래스

• JobBuilderFactory

  JobBuilder 를 생성하는 팩토릴 클래스로 get(String name) 메소드 제공

    jobBuilderFactory.get("jobName") // jobName 은 스프링 배치가 job 을 실행할 때 참조하는 job 이름

• JobBuilder

  Job 을 구성하는 설정 조건에 따라 하위 빌더 클래스를 생성하고 Job 생성을 위임한다.

  1. SimpleJobBuilder
  2. FlowJobBuilder

• StepBuilderFactory

  StepBuilder 를 생성하는 팩토리 클래스 get(String name) 메서드

• StepBuilder

  Step 을 구성하는 설정조건에 따라 5개의 하위 빌더 클래스에 Step 생성을 위임한다.

  1. TaskletStepBuilder
  2. SimpleStepBuilder
  3. PartionStepBuilder
  4. JobStepBuilder
  5. FlowStepBuilder

SimpleJob

• simpleJob 은 Step 을 실행시키는 Job 구현체로 SimpleJobBuilder 에 의해 생성=
• 여러 단계의 Step 으로 구성할 수 있으며 Step 을 순차적으로 실행시킨다.
  • 실패한 Step 이 생기면 그 이후 Step 은 실행하지 않는다.
• 모든 Step 의 실행이 성공적으로 완료되어야 Job 이 성공적으로 완료된다.
• 맨 마지막에 실행된 Step 의 BatchStatus 가 Job 의 최종 BatchStatus

TaskletStep

• 스프링 배치에서 제공하는 Step 구현체, Tasklet 을 실행시키는 도메인 객체
• RepeatTemplate 를 사용해서 Tasklet 의 구문을 트랜잭션 경계 내에서 반복 실행
• Task 기반과 Chunk 기반으로 나눠 Tasklet 실행

Task | Chunk 비교

• chunk 기반
  • 하나의 큰 덩어리를 n 개씩 나눠(chunk 단위) 실행한다는 의미로 대량 처리를 위해 설계됨
  • ItemReader, ItemProcessor, ItemWriter 를 사용하며 청크 기반 전용 Tasklet 인 ChunkOrientedTasklet 구현체 제공
• Task 기반
  • 청크 기반 작업 보다 단일 작업 기반으로 처리되는 것이 더 효율적인 경우
  • 주로 Tasklet 구현체를 만들어 사용
  • 대량 처리를 하는 경우 chunk 기반에 비해 더 복잡한 구현 필요

JobStep

• Job 에 속하는 Step 중 외부의 Job 을 포함하고 있는 Step
• 외부의 Job 이 실패하면 해당 Step 이 실패하므로 결국 최종 기본 Job 도 실패
• 모든 메타데이터는 기본 Job 과 외부 Job 별로 각각 저장
• 커다른 시스템을 작은 모듈로 쪼개고 job 의 흐름을 관리하고자 할 때 사용

FlowJob

• Step 을 순차적으로만 구성하는 것이 아닌 특정한 상태에 따라 흐름을 전환하도록 구성할 수 있다.
  • Step 이 실패 하더라도 Job 이 실패로 끝나지 않도록 해야 하는 경우
  • Step 이 성공 했을 때 다음에 실행해야 할 Step 을 구분해서 실행해야 하는 경우
  • 특정 Step 은 전혀 실행되지 않게 구성 해야 하는 경우
• Flow 와 Job 의 흐름을 구성하는데만 관여하고 실제 비즈니스 로직은 Step 에서 이루어진다.
• 내부적으로 SimpleFlow 객체를 포함하고 있으며 Job 실행 시 호출한다.

트랜지션에 활용하는 배치 상태 유형

• BatchStatus
  • JobExecution 과 StepExecution 의 속성으로 Job / Step 종료 후 최종 결과 상태 정의
  • SimpleJob ⇒ 마지막 Step 의 BatchStatus 값을 Job 의 최종 BatchStatus 값으로 반영
  • FlowJob ⇒ Flow 내 Step 의 ExitStatus 값을 FlowExecutionStatus 값으로 저장
  • COMPLETED, STARTING, STARTED, STOPPING, STOPPED, FAILED, ABANDONED, UNKNOWN
• ExitStatus
  • JobExecution 과 StepExecution 의 속성으로 Job / Step 실행 후 어떤 상태로 종료됐는지 정의
  • 기본적으로 ExitStatus 는 BatchStatus 와 동일한 값으로 설정된다.
  • SimpleJob ⇒ 마지막 Step 의 ExitStatus 값을 Job 의 최종 ExitStatus 값으로 반영
  • FlowJob ⇒ Flow 내 Step 의 ExitStatus 값을 FlowExecution 값으로 저장
  • UNKNOWN, EXECUTING, COMPLETED, NOOP, FAILED, STOPPED
• FlowExecutionStatus
  • FlowExecution 의 속성으로 Flow 의 실행 후 최종 결과 상태가 무엇인지 정의
  • Flow 내 Step 이 실행되고 나서 ExitStatus 값을 FlowExecutionStatus 값으로 저장
  • FlowJob 의 배치 결과 상태에 관여
  • COMPLETED, STOPPED, FAILED, UNKNOWN

사용자 정의 ExitStatus

• StepExecutionListener 의 afterStep() 메서드에서 Custom exitCode 생성 후 새로운 ExitStatus 반환

• Step 실행 후 완료 시점에서 현재 exitCode 를 사용자 정의 exitCode로 수정할 수 있음

    public class PassCheckingLister implements StepExecutionListener {
        @Override
        public void beforeStep(StepExecution stepExecution) {
  
        }
  
        @Override
        public ExitStatus afterStep(StepExecution stepExecution) {
            String exitCode = stepExecution.getExitStatus().getExitCode();
            if(!exitCode.equals(ExitStatus.FAILED.getExitCode())) {
                return new ExitStatus("PASS");
            }
            return null;
        }
    }

JobExecutionDecider

@Bean
    public Job batchJob() {
        return jobBuilderFactory.get("job")
                .incrementer(new RunIdIncrementer())
                .start(step1())
                .next(decider())
                .from(decider()).on("ODD").to(oddStep())
                .from(decider()).on("EVEN").to(eventStep())
                .end()
                .build();
    }

@Bean
    public JobExecutionDecider decider() {
        return new CustomDecider();
    }

==== 

public class CustomDecider implements JobExecutionDecider {

    private int count = 0;
    @Override
    public FlowExecutionStatus decide(JobExecution jobExecution, StepExecution stepExecution) {
        count++;
        if(count % 2 == 0) {
            return new FlowExecutionStatus("EVEN");
        }
        return new FlowExecutionStatus("ODD");
    }
}

@JobScope, @StepScope

• Job 과 Step 의 빈 생성과 실행에 관여하는 스코프

• code 예시

    // jobConfig 
    @RequiredArgsConstructor
    @Configuration
    public class JobConfiguration {
  
        private final JobBuilderFactory jobBuilderFactory;
        private final StepBuilderFactory stepBuilderFactory;
        private static final String ANY_STATUS = "*";
  
        @Bean
        public Job batchJob() {
            return jobBuilderFactory.get("job")
                    .incrementer(new RunIdIncrementer())
                    .start(step1(null))
                    .next(step2())
                    .listener(new JobListener())
                    .build();
        }
  
        @Bean
        @JobScope
        public Step step1(@Value("#{jobParameters['message']}") String message) {
            return stepBuilderFactory.get("step1")
                    .tasklet((contribution, chunkContext) -> {
                        System.out.println("message --> " + message);
                        System.out.println(contribution.getStepExecution().getStepName() + " has executed");
                        return RepeatStatus.FINISHED;
                    }).build();
        }
  
        @Bean
        public Step step2() {
            return stepBuilderFactory.get("step2")
                    .tasklet(tasklet(null, null, null))
                    .listener(new CustomStepExecutionListener())
                    .build();
        }
  
        @Bean
        @StepScope
        public Tasklet tasklet(@Value("#{jobExecutionContext['name']}") String name,
                               @Value("#{stepExecutionContext['name2']}") String name2,
                               @Value("#{jobParameters['message']}") String message) {
            return (stepContribution, chunkContext) -> {
                System.out.println("name --> " + name);
                System.out.println("name2 --> " + name2);
                System.out.println("message --> " + message);
                System.out.println("tasklet has executed");
                return RepeatStatus.FINISHED;
            };
        }
    }
  
    // JobListener
    public class JobListener implements JobExecutionListener {
        @Override
        public void beforeJob(JobExecution jobExecution) {
            jobExecution.getExecutionContext().put("name", "user1");
        }
  
        @Override
        public void afterJob(JobExecution jobExecution) {
  
        }
    }
  
    // StepListener
    public class CustomStepExecutionListener implements StepExecutionListener {
        @Override
        public void beforeStep(StepExecution stepExecution) {
            stepExecution.getExecutionContext().put("name2", "user2");
        }
  
        @Override
        public ExitStatus afterStep(StepExecution stepExecution) {
            return null;
        }
    }

Chunck process

• chunk 란 여러 개의 아이템을 묶은 하나의 덩어리를 의미한다
• 한번에 하나씩 아이템을 입력받아 chunk 단위로 트랜잭션을 처리한다.
• 일반적으로 대용량 데이터를 한번에 처리하는 것이 아닌 청크 단위로 쪼개서 더 이상 처리할 데이터가 없을 때 까지 반복처리

ChunckProvider

• ItemReader 를 사용해서 소스로부터 아이템을 chunk size 만큼 읽어서 Chunk 단위로 만들어 제공하는 도메인 객체
• 반복문 종료 시점
  • Chunk size 만큼 item 을 읽으면 반복문 종료하고 ChunkProcess 로 넘어간다
  • ItemReader 가 읽은 item 이 null 일 경우 반복문 종료 및 해당 Step 반복문까지 종료

ChunkProcessor

• ItemProcessor 를 사용해 Item 을 변형, 가공, 필터링 하고 ItemWriter 를 사용해 Chunk 데이터를 저장,출력
• Chunk 를 만들고 앞에서 넘어온 Chunk 의 item 을 한 건씩 처리 후 Chunck 에 저장
• ItemProcessor 는 선택사항으로 만약 없는 경우 ItemReader 에서 읽은 item 그대로 Chunk 에 저장
• ItemProcessor 처리가 완료되면 Chunck 에 있는 List 을 ItemWriter 에게 전달
• ItemWriter 처리가 완료되면 Chunk 트랜잭션이 종료되고 Step 반복문에서 ChunkOrientedTasklet 이 새롭게 생성된다