사부작사부작

Custom ItemReader/ItemWriter 구현방법 알아보기

민철킴 — Mon, 9 Dec 2024 23:51:42 +0900

진행중인 배치 스터디를 학습하며 작성한 글입니다.

[SpringBatch 연재 09] 입맛에 맞는 배치 처리를 위한 Custom ItemReader/ItemWriter 구현방법 알아보기

devocean.sk.com

스프링 배치가 ItemReader, ItemWriter를 제공해주지만, 보다 딱 맞는 배치를 수행하기 위해서는 커스터마이징이 필요합니다.

### Custom ItemReader

이번 학습에선 QueryDSL을 이용한 QueryDslPagingItemReader를 구현할 예정입니다.

QueryDSL은 스프링 배치에서 공식적으로 지원하는 ItemReader가 아닙니다. 그렇기에 AbstractPagingItemReader을 이용하여 커스텀 ItemReader를 만들어 볼 것입니다. Querydsl은 이용하면 데이터를 효율적으로 읽을 수 있으며 동적 쿼리 지원으로 런타임 시에 조건에 맞는 쿼리 생성이 가능해집니다.

AbstractPagingItemReader 클래스를 먼저 보겠습니다.

public abstract class AbstractPagingItemReader<T> extends AbstractItemCountingItemStreamItemReader<T>
		implements InitializingBean {

	protected Log logger = LogFactory.getLog(getClass());

	private volatile boolean initialized = false;

	private int pageSize = 10;

	private volatile int current = 0;

	private volatile int page = 0;

	protected volatile List<T> results;

	private final Lock lock = new ReentrantLock();

	public AbstractPagingItemReader() {
		setName(ClassUtils.getShortName(AbstractPagingItemReader.class));
	}

	@Nullable
	@Override
	protected T doRead() throws Exception {

		this.lock.lock();
		try {

			if (results == null || current >= pageSize) {

				if (logger.isDebugEnabled()) {
					logger.debug("Reading page " + getPage());
				}

				doReadPage();
				page++;
				if (current >= pageSize) {
					current = 0;
				}

			}

			int next = current++;
			if (next < results.size()) {
				return results.get(next);
			}
			else {
				return null;
			}

		}
		finally {
			this.lock.unlock();
		}

	}

	...	

	abstract protected void doReadPage();

	...

	@Override
	protected void doClose() throws Exception {

		this.lock.lock();
		try {
			initialized = false;
			current = 0;
			page = 0;
			results = null;
		}
		finally {
			this.lock.unlock();
		}

	}

	...
}

이 클래스를 상속받아 구현할 QueryDslPagingItemReader는 doRead() 메서드에서 호출중인 doReadPage() 를 구현해야 합니다.

public class QuerydslPagingItemReader<T> extends AbstractPagingItemReader<T> {

    private EntityManager em;
    private final Function<JPAQueryFactory, JPAQuery<T>> querySupplier;
    private final Boolean alwaysReadFromZero;

    public QuerydslPagingItemReader(EntityManagerFactory entityManagerFactory, Function<JPAQueryFactory, JPAQuery<T>> querySupplier, int chunkSize) {
        this(ClassUtils.getShortName(QuerydslPagingItemReader.class), entityManagerFactory, querySupplier, chunkSize, false);
    }

    public QuerydslPagingItemReader(String name, EntityManagerFactory entityManagerFactory, Function<JPAQueryFactory, JPAQuery<T>> querySupplier, int chunkSize, Boolean alwaysReadFromZero) {
        super.setPageSize(chunkSize);
        setName(name);
        this.querySupplier = querySupplier;
        this.em = entityManagerFactory.createEntityManager();
        this.alwaysReadFromZero = alwaysReadFromZero;
    }

    @Override
    protected void doClose() throws Exception {
        if (em != null)
            em.close();
        super.doClose();
    }

    @Override
    protected void doReadPage() {
        initQueryResult();
        
        JPAQueryFactory jpaQueryFactory = new JPAQueryFactory(em);
        long offset = 0;
        if (!alwaysReadFromZero) {
            offset = (long) getPage() * getPageSize();
        }

        JPAQuery<T> query = querySupplier.apply(jpaQueryFactory).offset(offset).limit(getPageSize());

        List<T> queryResult = query.fetch();
        for (T entity: queryResult) {
            em.detach(entity);
            results.add(entity);
        }
    }

    private void initQueryResult() {
        if (CollectionUtils.isEmpty(results)) {
            results = new CopyOnWriteArrayList<>();
        } else {
            results.clear();
        }
    }
}

생성자를 보면 chunkSize는 페이지 사이즈, 즉 한번에 읽어올 아이템 수를 나타내고

name은 ItemReader를 구분하기 위한 이름입니다.

alwaysReadFromZero는 페이징을 0부터 시작할지 여부를 나타내는 플래그입니다.

Function<JPAQueryFactory, JPAQuery>는 JPAQuery 형태의 queryDSL 쿼리를 반환합니다.

public QuerydslPagingItemReader(String name, EntityManagerFactory entityManagerFactory, Function<JPAQueryFactory, JPAQuery<T>> querySupplier, int chunkSize, Boolean alwaysReadFromZero) {
        super.setPageSize(chunkSize);
        setName(name);
        this.querySupplier = querySupplier;
        this.em = entityManagerFactory.createEntityManager();
        this.alwaysReadFromZero = alwaysReadFromZero;
    }

편의를 위한 빌더 클래스

public class QuerydslPagingItemReaderBuilder<T> {

    private EntityManagerFactory entityManagerFactory;
    private Function<JPAQueryFactory, JPAQuery<T>> querySupplier;

    private int chunkSize = 10;

    private String name;

    private Boolean alwaysReadFromZero;

    public QuerydslPagingItemReaderBuilder<T> entityManagerFactory(EntityManagerFactory entityManagerFactory) {
        this.entityManagerFactory = entityManagerFactory;
        return this;
    }

    public QuerydslPagingItemReaderBuilder<T> querySupplier(Function<JPAQueryFactory, JPAQuery<T>> querySupplier) {
        this.querySupplier = querySupplier;
        return this;
    }

    public QuerydslPagingItemReaderBuilder<T> chunkSize(int chunkSize) {
        this.chunkSize = chunkSize;
        return this;
    }

    public QuerydslPagingItemReaderBuilder<T> name(String name) {
        this.name = name;
        return this;
    }

    public QuerydslPagingItemReaderBuilder<T> alwaysReadFromZero(Boolean alwaysReadFromZero) {
        this.alwaysReadFromZero = alwaysReadFromZero;
        return this;
    }

    public QuerydslPagingItemReader<T> build() {
        if (name == null) {
            this.name = ClassUtils.getShortName(QuerydslPagingItemReader.class);
        }
        if (this.entityManagerFactory == null) {
            throw new IllegalArgumentException("EntityManagerFactory can not be null.!");
        }
        if (this.querySupplier == null) {
            throw new IllegalArgumentException("Function<JPAQueryFactory, JPAQuery<T>> can not be null.!");
        }
        if (this.alwaysReadFromZero == null) {
            alwaysReadFromZero = false;
        }
        return new QuerydslPagingItemReader<>(this.name, entityManagerFactory, querySupplier, chunkSize, alwaysReadFromZero);
    }
}

샘플 코드를 이용해서 확인해보겠습니다.

먼저 코드와 처리하려는 데이터입니다.

@Slf4j
@Configuration
public class QueryDSLPagingReaderJobConfig {

    /**
     * CHUNK 크기를 지정한다.
     */
    public static final int CHUNK_SIZE = 2;
    public static final String ENCODING = "UTF-8";
    public static final String QUERYDSL_PAGING_CHUNK_JOB = "QUERYDSL_PAGING_CHUNK_JOB";

    @Autowired
    DataSource dataSource;

    @Autowired
    EntityManagerFactory entityManagerFactory;

    @Bean
    public QuerydslPagingItemReader<Customer> customerQuerydslPagingItemReader() {
        return new QuerydslPagingItemReaderBuilder<Customer>()
                .name("customerQuerydslPagingItemReader")
                .entityManagerFactory(entityManagerFactory)
                .chunkSize(2)
                .querySupplier(jpaQueryFactory ->
                        jpaQueryFactory
                        .select(QCustomer.customer)
                        .from(QCustomer.customer)
                        .where(QCustomer.customer.age.gt(20))
                )
                .build();
    }

    @Bean
    public FlatFileItemWriter<Customer> customerQuerydslFlatFileItemWriter() {

        return new FlatFileItemWriterBuilder<Customer>()
                .name("customerQuerydslFlatFileItemWriter")
                .resource(new FileSystemResource("./output/customer_new_v2.csv"))
                .encoding(ENCODING)
                .delimited().delimiter("\t")
                .names("Name", "Age", "Gender")
                .build();
    }


    @Bean
    public Step customerQuerydslPagingStep(JobRepository jobRepository, PlatformTransactionManager transactionManager) throws Exception {
        log.info("------------------ Init customerQuerydslPagingStep -----------------");

        return new StepBuilder("customerJpaPagingStep", jobRepository)
                .<Customer, Customer>chunk(CHUNK_SIZE, transactionManager)
                .reader(customerQuerydslPagingItemReader())
                .processor(new CustomerItemProcessor())
                .writer(customerQuerydslFlatFileItemWriter())
                .build();
    }

    @Bean
    public Job customerJpaPagingJob(Step customerJdbcPagingStep, JobRepository jobRepository) {
        log.info("------------------ Init customerJpaPagingJob -----------------");
        return new JobBuilder(QUERYDSL_PAGING_CHUNK_JOB, jobRepository)
                .incrementer(new RunIdIncrementer())
                .start(customerJdbcPagingStep)
                .build();
    }
}

6개의 데이터가 있고 QueryDSL 을 이용해 where 절에 age가 20보다 큰 조건을 줬습니다. 그렇다면 5개의 데이터를 읽어와야 정확히 동작한다고 볼 수 있습니다.

먼저 로그를 보면 청크 사이즈, 즉 페이지 크기가 2인 만큼 해당 과정은 3번의 쿼리를 보내서 처리한걸 볼 수 있습니다.

그리고 결과를 봐도 5개의 데이터만 가져온걸 확인할 수 있습니다.

그러면 age 조건을 40보다 크게 변경해보겠습니다.

이 때는 하나의 데이터만 조건에 해당되니 쿼리를 한 번만 보내서 데이터를 읽어온 걸 확인할 수 있습니다.

### Custom ItemWriter

위와 비슷하게 CustomItemWriter 는 ItemWriter 인터페이스를 구현한 클래스이다. 인터페이스가 가지는 write() 메서드를 유연하게 원하는 기능을 추가하여 구현하면 된다.

@Slf4j
@Service
public class CustomService {

    public Map<String, String> processToOtherService(Customer item) {

        log.info("Call API to OtherService....");

        return Map.of("code", "200", "message", "OK");
    }
}

@Slf4j
@Component
public class CustomItemWriter implements ItemWriter<Customer> {

    private final CustomService customService;

    public CustomItemWriter(CustomService customService) {
        this.customService = customService;
    }

    @Override
    public void write(Chunk<? extends Customer> chunk) throws Exception {
        for (Customer customer: chunk) {
            log.info("Call Porcess in CustomItemWriter...");
            customService.processToOtherService(customer);
        }
    }
}

@Slf4j
@Configuration
public class MybatisItemWriterJobConfig {

    /**
     * CHUNK 크기를 지정한다.
     */
    public static final int CHUNK_SIZE = 100;
    public static final String ENCODING = "UTF-8";
    public static final String MY_BATIS_ITEM_WRITER = "MY_BATIS_ITEM_WRITER";

    @Autowired
    DataSource dataSource;

    @Autowired
    SqlSessionFactory sqlSessionFactory;

    @Autowired
    CustomItemWriter customItemWriter;

    @Bean
    public FlatFileItemReader<Customer> flatFileItemReader() {

        return new FlatFileItemReaderBuilder<Customer>()
                .name("FlatFileItemReader")
                .resource(new ClassPathResource("./customer.csv"))
                .encoding(ENCODING)
                .delimited().delimiter(",")
                .names("name", "age", "gender")
                .targetType(Customer.class)
                .build();
    }

    @Bean
    public Step flatFileStep(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
        log.info("------------------ Init flatFileStep -----------------");

        return new StepBuilder("flatFileStep", jobRepository)
                .<Customer, Customer>chunk(CHUNK_SIZE, transactionManager)
                .reader(flatFileItemReader())
                .writer(customItemWriter)
                .build();
    }

    @Bean
    public Job flatFileJob(Step flatFileStep, JobRepository jobRepository) {
        log.info("------------------ Init flatFileJob -----------------");
        return new JobBuilder(MY_BATIS_ITEM_WRITER, jobRepository)
                .incrementer(new RunIdIncrementer())
                .start(flatFileStep)
                .build();
    }
}

간단한 예제를 통해서 작동과정을 확인해 볼 수 있습니다.

커스텀 writer의 사용성이 궁금해서 GPT에게 예시를 요청해봤습니다.

public class RestApiItemWriter implements ItemWriter<MyData> {

    private final RestTemplate restTemplate;
    private final String apiEndpoint = "https://api.example.com/data";

    @Autowired
    public RestApiItemWriter(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    @Override
    public void write(List<? extends MyData> items) throws Exception {
        for (MyData item : items) {
            try {
                // 외부 API로 데이터 전송
                restTemplate.postForObject(apiEndpoint, item, Void.class);
                System.out.println("Successfully sent data: " + item.getId());
            } catch (Exception e) {
                // 에러 핸들링 로직
                System.err.println("Failed to send data: " + item.getId() + " - " + e.getMessage());
                // 필요에 따라 예외를 던져 배치 작업을 중단하거나 재시도할 수 있습니다.
                throw e;
            }
        }
    }
}

read, process를 거친 데이터를 외부 api에 전송하는 코드입니다. 이 밖에도 이메일 전송, s3등 클라우드 스토리지에 쓰는 등의 예시를 알 수 있었습니다.

JpaPagingItemReader, JpaItemWriter

민철킴 — Tue, 12 Nov 2024 17:37:32 +0900

https://devocean.sk.com/blog/techBoardDetail.do?ID=166902

［SpringBatch 연재 06］ JpaPagingItemReader로 DB내용을 읽고, JpaItemWriter로 DB에 쓰기

devocean.sk.com

해당 블로그 글을 기반으로 공부한 글입니다.

JpaPagingItemReader

소개 : 해당 클래스는 스프링 배치에서 제공하는 ItemReader 구현체 중 하나입니다. JPA를 이용해서 데이터베이스로부터 페이징 단위로 데이터를 읽어올 때 사용합니다.

주요 구성 요소 :

EntityManagerFactory: JPA 엔티티 매니저 팩토리를 설정합니다.
JpaQueryProvider: 데이터를 읽을 JPA 쿼리를 제공합니다.
PageSize: 한 번에 읽어올 데이터의 개수 즉, 페이지 크기를 설정합니다.
SkippableItemReader: 오류 발생 시 해당 아이템을 건너뛸 수 있도록 설정합니다.
ReadListener: 읽기 시작, 종료, 오류 발생 등의 이벤트를 처리할 수 있도록 설정합니다.
SaveStateCallback: 잡 중단 시 현재 상태를 저장하여 재시작 시 이어서 처리할 수 있도록 설정합니다.

특징 :

페이징 처리 : 지정된 페이지 크기만큼 나눠서 데이터를 읽어오기 때문에 메모리 사용량을 줄일 수 있습니다. 청크 크기와 한 번에 읽어올 페이지 크기를 같게 맞춰주는게 일반적입니다.

JPQL, 네이티브 쿼리 : JPQL을 사용하여 엔티티 기반의 쿼리를 작성할 수도 있고, 네이티브 SQL 쿼리를 사용할 수도 있습니다.

jpaPagingItemReader.setQueryString("SELECT c FROM Customer c WHERE c.age > :age order by id desc");
jpaPagingItemReader.setParameterValues(Collections.singletonMap("age", 20));

네이티브 쿼리네이티브 쿼리를 사용할 경우 setUseNativeQuery(true) 설정을 해줘야 합니다. 여기서 setPreparedStatementSetter() 메서드는 파라미터에 값을 바인딩하는 방식을 설정합니다. 쿼리의 '?' 위치에 20 이라는 값을 바인딩하게 됩니다.

jpaPagingItemReader.setQueryString("SELECT * FROM customer WHERE age > ? ORDER BY id DESC"); 
jpaPagingItemReader.setUseNativeQuery(true); 
jpaPagingItemReader.setPreparedStatementSetter(new ArgumentPreparedStatementSetter(new Object[]{20}));

실습 :

간단한 코드로 실습해 보겠습니다.

@Entity
@Table(name = "customer")
@NoArgsConstructor
@AllArgsConstructor
@Data
public class Customer {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private int id;
    private String name;
    private int age;
    private String gender;
}

@Slf4j
@Configuration
public class JpaPagingReaderJobConfig {

    /**
     * CHUNK 크기를 지정한다.
     */
    public static final int CHUNK_SIZE = 2;
    public static final String ENCODING = "UTF-8";
    public static final String JPA_PAGING_CHUNK_JOB = "JPA_PAGING_CHUNK_JOB";

    @Autowired
    DataSource dataSource;

    @Autowired
    EntityManagerFactory entityManagerFactory;

    @Bean
    public JpaPagingItemReader<Customer> customerJpaPagingItemReader() throws Exception {
        JpaPagingItemReader<Customer> jpaPagingItemReader = new JpaPagingItemReader<>();
        jpaPagingItemReader.setQueryString(
                "SELECT c FROM Customer c WHERE c.age > :age order by id desc"
        );
        jpaPagingItemReader.setEntityManagerFactory(entityManagerFactory);
        jpaPagingItemReader.setPageSize(CHUNK_SIZE);
        jpaPagingItemReader.setParameterValues(Collections.singletonMap("age", 20));
        return jpaPagingItemReader;
    }

    @Bean
    public FlatFileItemWriter<Customer> customerJpaFlatFileItemWriter() {

        return new FlatFileItemWriterBuilder<Customer>()
                .name("customerJpaFlatFileItemWriter")
                .resource(new FileSystemResource("./output/customer_new_v2.csv"))
                .encoding(ENCODING)
                .delimited().delimiter("\t")
                .names("Name", "Age", "Gender")
                .build();
    }


    @Bean
    public Step customerJpaPagingStep(JobRepository jobRepository, PlatformTransactionManager transactionManager) throws Exception {
        log.info("------------------ Init customerJpaPagingStep -----------------");

        return new StepBuilder("customerJpaPagingStep", jobRepository)
                .<Customer, Customer>chunk(CHUNK_SIZE, transactionManager)
                .reader(customerJpaPagingItemReader())
                .processor(new CustomerItemProcessor())
                .writer(customerJpaFlatFileItemWriter())
                .build();
    }

    @Bean
    public Job customerJpaPagingJob(Step customerJdbcPagingStep, JobRepository jobRepository) {
        log.info("------------------ Init customerJpaPagingJob -----------------");
        return new JobBuilder(JPA_PAGING_CHUNK_JOB, jobRepository)
                .incrementer(new RunIdIncrementer())
                .start(customerJdbcPagingStep)
                .build();
    }
}

db의 데이터와 로그들입니다. 나이가 20살이 넘는 고객만 조회해오기 때문에 2개의 데이터에 대한 로그만 존재합니다.

실행 결과로 생성된 csv 파일입니다.

JpaItemWriter

소개 : 해당 클래스는 스프링 배치에서 제공하는 ItemWriter의 구현체 중 하나입니다. JPA를 이용해서 데이터를 데이터베이스에 저장할 때 사용됩니다.

주요 구성 요소

EntityManagerFactory: JPA EntityManager 생성을 위한 팩토리 객체
JpaQueryProvider: 저장할 엔터티를 위한 JPA 쿼리를 생성하는 역할

실습 :

간단한 코드로 실습해 보겠습니다.

CSV 파일의 데이터를 읽어와, customer 테이블에 데이터를 저장해보겠습니다.

읽어올 CSV 파일입니다.

@Slf4j
@Configuration
public class JpaItemJobConfig {

    /**
     * CHUNK 크기를 지정한다.
     */
    public static final int CHUNK_SIZE = 200;
    public static final String ENCODING = "UTF-8";
    public static final String JPA_ITEM_WRITER_JOB = "JPA_ITEM_WRITER_JOB";

    @Autowired
    EntityManagerFactory entityManagerFactory;

    @Bean
    public FlatFileItemReader<Customer> flatFileItemReader() {

        return new FlatFileItemReaderBuilder<Customer>()
                .name("FlatFileItemReader")
                .resource(new ClassPathResource("./customer.csv"))
                .encoding(ENCODING)
                .delimited().delimiter(",")
                .names("name", "age", "gender")
                .targetType(Customer.class)
                .build();
    }

    @Bean
    public JpaItemWriter<Customer> jpaItemWriter() {
        return new JpaItemWriterBuilder<Customer>()
                .entityManagerFactory(entityManagerFactory)
                .usePersist(true)
                .build();
    }


    @Bean
    public Step flatFileStep(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
        log.info("------------------ Init flatFileStep -----------------");

        return new StepBuilder("flatFileStep", jobRepository)
                .<Customer, Customer>chunk(CHUNK_SIZE, transactionManager)
                .reader(flatFileItemReader())
                .writer(jpaItemWriter())
                .build();
    }

    @Bean
    public Job flatFileJob(Step flatFileStep, JobRepository jobRepository) {
        log.info("------------------ Init flatFileJob -----------------");
        return new JobBuilder(JPA_ITEM_WRITER_JOB, jobRepository)
                .incrementer(new RunIdIncrementer())
                .start(flatFileStep)
                .build();
    }
}

jpaItemWriter() 코드를 보시면 엔티티 매니저를 통해 아이템을 persist하는 것을 보실 수 있습니다.

그러면 customer 테이블의 결과를 보겠습니다.

기존의 데이터에 읽어온 CSV파일의 데이터가 추가된걸 확인할 수 있습니다.

JdbcPagingItemReader와 JdbcBatchItemWriter

민철킴 — Tue, 5 Nov 2024 17:54:27 +0900

JdbcPagingItemReader 클래스

먼저 JdbcPagingItemReader와 flatfileItemReader의 상속 관계를 비교해보겠습니다.

### JdbcPagingItemReader

AbstractItemStreamItemReader<T> (implements ItemStream, ItemReader<T>)
└── AbstractItemCountingItemStreamItemReader<T>
└── AbstractPagingItemReader<T>
└── JdbcPagingItemReader<T>

### flatfileItemReader

AbstractItemStreamItemReader<T> (implements ItemStream, ItemReader<T>)
└── AbstractItemCountingItemStreamItemReader<T>
└── FlatFileItemReader<T>

AbstractItemCountingItemStreamItemReader<T> 는 아이템 수를 카운트하고 기본적인 상태관리 기능을 제공해주는 클래스입니다. 이 클래스를 바로 상속받아 csv 등의 flat 파일 형태의 데이터를 읽어오는 책임을 담당하는 클래스가 flatfileItemReader<T> 입니다.

이와 비슷하게 AbstractPagingItemReader<T> 는 AbstractItemCountingItemStreamItemReader<T> 를 상속받아서 페이징 기능을 추가하여 대용량 데이터를 읽어오게 추상화한 클래스입니다. JdbcPagingItemReader<T>는 AbstractPagingItemReader<T> 클래스를 상속해서 JDBC를 통해 데이터베이스에서 페이징 단위로 데이터를 읽어오는 구체 클래스입니다.

간단히 말하면 JdbcPagingItemReader<T>는 JDBC를 통해 데이터를 페이징 단위로 읽어오는 역할을 담당하게 됩니다.

### JdbcPagingItemReader의 주요 구성요소

DataSource: 데이터베이스 연결 정보를 설정한다.
PagingQueryProvider: 데이터를 읽을 SQL 쿼리를 설정한다.
RowMapper: SQL 쿼리 결과를 도메인 객체(Item)로 변환하는 역할을 한다.
PageSize: 한 페이지에 포함될 아이템 수를 설정한다.
FetchSize : 한 번에 읽어올 레코드 수를 지정하여 성능을 관리한다
ReadListener: 읽기 시작, 종료, 오류 발생 등의 이벤트를 처리할 수 있도록 한다.
SaveState : 리더의 상태를 저장할지 여부를 설정하여 배치 작업의 재시작 가능성을 지원한다.

JdbcPagingItemReader 클래스

JdbcBatchItemWriter<T>는 Spring Batch에서 제공하는 ItemWriter 구현체입니다. 주로 데이터베이스에 대량의 데이터를 삽입하거나 업데이트할 때 사용합니다. JDBC를 기반으로 동작하며, SQL 문을 통해 데이터베이스에 데이터를 추가합니다.

### JdbcBatchItemWriter의 주요 구성요소

DataSource: 데이터베이스 연결 정보를 지정한다.
SqlStatementCreator: INSERT 쿼리를 생성하는 역할을 한다.
PreparedStatementSetter: INSERT 쿼리의 파라미터 값을 설정하는 역할을 한다.
ItemSqlParameterSourceProvider: Item 객체를 기반으로 PreparedStatementSetter에 전달할 파라미터 값을 생성하는 역할을 한다.

스프링 배치 3주차

민철킴 — Tue, 22 Oct 2024 01:05:38 +0900

이번 주차의 스터디 주제는 Chunk Model 과 TaskletModel 입니다 .

먼저 들어가기 앞서 단어 뜻을 찾아보겠습니다.

chunk 는 ‘덩어리’ 라는 뜻을 나타냅니다. tasklet 에는 한글 뜻이 없어서 번역해보면 ‘운영체제에서의 간단한 작업’ 라고 해석할 수 있습니다.

그리고 스터디의 주제인 batch 는 아래의 뜻을 가지고 있습니다.

배치는 ‘일괄적으로 묶은 한 회분’ 의 뜻을 가지고 있습니다.

Chunk의 뜻을 더 찾아보니 여기서 말하는 ‘덩어리’는 특정 큰 단위에서 나온 덩어리를 의미합니다. 단어 뜻 대로 청크모델은 배치 작업을 한 번에 모두 처리하지 않고 일정한 크기(청크)로 나누어 처리하는 방식입니다. 이에 반해 taskletModel은 단일 작업 단위로 배치를 수행하는 방밥입니다.

단어 뜻에서도 느껴지듯이 스프링은 대규모 데이터를 다루기위한 ChunkModel과 간단한 배치작업을 위한 TaskletModel을 제공하고 있습니다. 이를 더 살펴 보겠습니다.

Chunk

Spring Batch의 Step은 Chunk, Tasklet 2가지 나눠지고 Chunk인 경우, ItemReader -> ItemProcessor -> ItemWriter로 프로세스가 진행됩니다. 개별 데이터 row 단위로 읽고 가공한 뒤, row를 덩어리로 모아서 쓰는 과정으로 진행됩니다. 해당 과정은 아래 그림과 같습니다.

이 과정에 대한 예시 수도 코드입니다.

List items = new Arraylist();
for(int i = 0; i < commitInterval; i++){
    Object item = itemReader.read();
    if (item != null) {
        items.add(item);
    }
}

List processedItems = new Arraylist();
for(Object item: items){
    Object processedItem = itemProcessor.process(item);
    if (processedItem != null) {
        processedItems.add(processedItem);
    }
}

itemWriter.write(processedItems);

이 과정에서 사용되는 ItemReader, ItemProcessor, ItemWriter 구현체들은 특정한 용도와 상황에 맞게 설계되었습니다.
예를 들면 ItemReader 의 경우 다양한 읽기 소스에 대한 구현체가 존재합니다. CSV, 텍스트 파일의 읽기용 구현체(FlatFileItemReader), Jpa페이징 방식 읽기용 구현체(JpaPagingItemReader) 등의 여러 구현체를 제공해줍니다. ItemProcessor의 경우엔 입력된 데이터를 확인하는 구현체(ValidatingItemProcessor), 여러 개의 프로세서를 조합해서 사용하는 구현체(CompositeItemProcessor) 등을 제공해줍니다. 또한 ItemWritrer 의 경우에도 CSV, 텍스트 파일의 데이터를 쓰는 구현체(FlatFileItemWriter), JPA를 사용해서 데이터를 쓰는 구현체(JpaItemWriter) 등이 존재합니다.

Chunk 모델은 데이터를 나눠서 처리함으로써 여러 이점을 가져갑니다.

트랜잭션 관리 및 재시도 용이

배치로 처리할 데이터가 아주 많은 상황을 생각해봅겠습다. 스프링 배치는 배치 작업 과정에서 트랜잭션을 관리해줍니다. 배치 처리 중에 오류가 발생해 작업이 진행된 수많은 데이터의 롤백이 발생할 수 있습니다. 이 때 데이터를 특정 단위로 나눠서 반복 처리를 한다면 안정적인 작업과 효율성을 보다 보장할 수 있습니다.

성능 최적화

청크 단위로 데이터를 읽고, 처리하고, 쓰는 과정을 병렬로 수행할 수 있습니다.

처리할 데이터의 규모 뿐만 아니라 처리할 상황도 어떤 배치 모델을 선택할지 고려사항 중 하나입니다. 만약 외부 api 호출이나 db 업데이트 sql 처리가 필요한 상황을 생각해봅시다. 이 때 reader, processor, writer 로 구성된 청크 모델을 사용한다면 writer는 작동하지 않게 됩니다. 그렇기에 간단한 작업이 필요한 경우에도 tasklet을 사용합니다.

Tasklet

package org.springframework.batch.core.step.tasklet;

import org.springframework.batch.core.StepContribution;
import org.springframework.batch.core.scope.context.ChunkContext;
import org.springframework.batch.repeat.RepeatStatus;

/**
 * Callback interface to be implemented by classes that perform single tasks within a Step.
 */
public interface Tasklet {

    /**
     * Execute the task.
     *
     * @param contribution the current step execution context
     * @param chunkContext the current chunk context
     * @return the status indicating whether processing is finished or should continue
     * @throws Exception in case of any error that should stop the step
     */
    RepeatStatus execute(StepContribution contribution, ChunkContext chunkContext) throws Exception;
}

execute 메서드는 Tasklet의 핵심 메서드로, 실제 작업 로직이 구현됩니다. 반환타입의 enum은 2가지 상태를 표시해줍니다.

package org.springframework.batch.repeat;

public enum RepeatStatus {
    FINISHED,
    CONTINUABLE
}

작업이 완료되었음을 나타내는 FINISHED를 반환하거나, 추가적인 처리가 필요할 경우 CONTINUABLE을 반환하게 됩니다. 이때 반환값으로 CONTINUABLE을 반환하면 태스크는 재실행되어 반환값이 FINISHED가 나올때까지 반복하게 됩니다. 그렇기에 무한루프에 빠지지 않기 위해선 적절한 처리가 필요합니다.

Tasklet도 Chunk방식처럼 다양한 구현체를 제공하고 있습니다. 시스템 명령어를 실행하는 구현체(SystemCommandTasklet), 지정된 파일을 삭제하는 구현체( FileDeletingTasklet) 등이 존재합니다.

스프링 배치 스터디 2주차

민철킴 — Mon, 14 Oct 2024 23:23:48 +0900

배치 아키텍처를 살펴보면 위와 같습니다. 이 구성 요소들을 포함하여 레이어 단위로 나눠서 간단히 알아보겠습니다.

1. Application Layer

개발자가 직접 작성하는 부분으로, 배치 애플리케이션의 비즈니스 로직과 배치 작업의 흐름을 정의합니다.

주요 구성 요소:

Job: 배치 작업의 전체 흐름을 정의하는 엔티티로, 하나 이상의 Step으로 구성됩니다.
Step: 배치 작업의 단위 실행을 나타내며, Tasklet 또는 Chunk 로 나눠집니다.
- Tasklet: 단일 작업을 수행하는 경우에 사용합니다.
- Chunk: 대용량 데이터를 chunk(청크)로 나누어 처리하며, ItemReader, ItemProcessor, ItemWriter를 사용합니다.
  - ItemReader: 데이터 읽기
  - ItemProcessor: 데이터 가공
  - ItemWriter: 데이터 쓰기

역할:

비즈니스 로직 구현: 배치 처리에 필요한 구체적인 로직을 작성합니다.
배치 작업 흐름 정의: Job과 Step의 순서 및 조건을 설정하여 전체 배치 프로세스를 구성합니다.

2. Batch Core Layer

Spring Batch의 핵심 기능을 제공하는 부분으로, 배치 작업 실행과 관리를 담당합니다.

주요 구성 요소:

JobLauncher: 배치 Job을 실행시키는 인터페이스로, Job을 시작할 때 사용합니다.
JobRepository: Job과 Step의 메타데이터 및 실행 정보를 저장하고 관리합니다.
JobExecution: Job 실행의 상태와 결과를 나타내는 클래스입니다.
StepExecution: Step 실행의 상태와 결과를 나타냅니다.
JobBuilder, StepBuilder: Job과 Step을 생성하고 구성하는 빌더 클래스입니다.

역할:

배치 작업 실행 제어: Job과 Step의 실행 흐름을 제어하고 관리합니다.
상태 관리: 실행 중인 Job과 Step의 상태 정보를 유지하여 재시도나 재시작 기능을 지원합니다.

3. Batch Infrastructure Layer

배치 처리에 필요한 인프라 기능을 제공합니다. 데이터베이스나 파일 시스템과의 데이터 입출력, 트랜잭션 관리 등을 담당합니다.

주요 구성 요소:

DataSource: 데이터베이스 연결을 관리하고 제공하는 구성 요소입니다.
TransactionManager: 트랜잭션 경계를 정의하고 관리하여 데이터의 일관성을 유지합니다.
JobRepository: Job과 Step의 메타데이터를 실제로 저장하고 조회하는 구현체로, 주로 데이터베이스를 사용합니다.
Resource Management: 파일 시스템, 메시징 시스템 등 외부 리소스와의 연동을 지원합니다.
Partitioner, Remote Chunking: 분산 처리 및 병렬 처리를 지원하는 구성 요소입니다.

역할:

외부 시스템과의 통합: 데이터베이스, 파일, 메시지 큐 등과 상호 작용하여 데이터를 읽고 씁니다.
트랜잭션 및 리소스 관리: 안정적인 배치 처리를 위해 필요한 인프라스트럭처 서비스를 제공합니다.

위 처리 흐름 그림에서 보이듯 Batch Core Layer 에 속하는 JobLauncher가 배치 Job을 실행시킵니다. 이 Job은 1:N 으로 구성된 Step을 실행시키게 됩니다. 이 Step은 tasklet 또는 chunk로 구성되며 그리에서는 chunk로 구성된 예시를 보여주고 있습니다. 이 Chunk들은 데이터를 읽고, 가공하고 쓰는 과정을 거치며 chunk는 기본적으로 반복해서 수행하게 됩니다. (Chunk와 tasklet에 대해서는 다음 글에서 더 자세히 다루겠습니다.) 해당 Job과 Step에 관한 정보는 JobRepository 인터페이스에 저장,관리됩니다. 위 그림에서보면 Application Layer는 Batch Core Layer의 기능을 사용해서 배치 작업을 정의하고 실행하고 있습니다. 그림에 자세히 나오진 않았지만 Batch Infrastructure Layer는 데이터베이스 접근, 트랜잭션 관리 등을 통해서 배치 처리에 필요한 인프라를 제공하고 있습니다. 이를 통해 레이어 구성요소의 관계를 통해 배치 처리 흐름을 파악할 수 있습니다.

@OneToOne 관계에서 Lazyloading 이슈는 왜 발생할까

민철킴 — Thu, 22 Jun 2023 15:49:19 +0900

틀린 부분이 존재할 수 있습니다. 감사합니다.

객체는 그래프로 연관된 객체들을 탐색한다. 그런데 객체가 데이터베이스에 저장되어 있으므로 연관된 객체를 마음껏 탐색하기는 어렵다 - 김영한

JPA는 연관된 객체들을 탐색하는 것을 도와준다. JPA는 직접 쿼리를 날려서 연관된 객체의 데이터를 가져온다. 예를 들어 고객과 주문으로 이루어진 1:N 구조에서 1번 고객이 3건의 주문을 한 데이터가 있다고 하자. 이 상태에서 1번 고객에 연관된 주문 객체들을 가져올 때, 주문 3건에 대해 각각 쿼리를 날려서 가져온다. 그렇기에 흔히 말하는 N+1 쿼리가 발생한다.

그렇다면 JPA는 왜 쿼리를 N번이나 날려서 연관된 객체들을 조회해올까? 왜 JPA는 조인을 통해 고객을 조회할 때 연관된 주문 데이터들을 가져오지 않을까?

만약 1번 고객의 전화번호 필드만 조회를 한다면 주문 데이터들은 미리 가져올 이유가 없다. 그렇기에 JPA는 지연로딩과 즉시로딩을 제공해 필요한 상황에 쿼리를 날려 연관된 객체들을 가져온다. 여기에 조인을 통해 연관된 객체들을 가져오는 페치 조인 방식도 제공해준다.

@OneToOne 관계에서 지연로딩을 살펴보자. Member와 Locker를 일대일 양방향 관계로 설정해뒀다. 연관관계의 주인은 Locker인 상태다.

@Entity
public class Member {

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @OneToOne(mappedBy = "member",  fetch = FetchType.LAZY)
    private Locker locker;
}

@Entity
public class Locker {

    @Id
    @GeneratedValue
    private Long id;

    private String description;

    @OneToOne(fetch = FetchType.LAZY)
    private Member member;
}

이 상태에서 먼저 Locker를 조회해보자.

lockerRepository.findAll();

lockerRepository.findAll();

Locker를 조회했다. 그와 연관된 Member 객체는 지연로딩 설정을 해뒀기에 아직 쿼리를 보내지 않는다.

memberRepository.findAll();

이젠 반대의 Member를 조회한 경우다. 여기선 지연로딩 설정을 해둔 Locker를 지연로딩하지 않고 바로 쿼리를 날려서 Locker객체를 조회해오고 있다.

같은 양방향 관계인데 왜 차이가 날까?

먼저 지연로딩으로 적용된 필드 자리에는 무언가 대신 자리를 채우고 있어야한다. JPA는 여기에 프록시 객체를 사용한다. JPA는 지연로딩으로 처리되는 객체들은 프록시 객체가 대신하고 있다가, 해당 객체들을 실제 사용하는 시점에 초기화시킨다. 여기서 초기화는 데이터베이스를 조회해서 영속성 컨텍스트에 실제 객체가 생성된다는 말이다. 초기화가 되도 프록시 객체를 통해서 실제 객체를 호출해서 결과를 반환하는 식으로 작동한다.

하지만 지연로딩을 할 객체가 실제 null이라면 어떨까? 실제 데이터가 null 이라면 프록시가 아니라 null이 들어가게 된다. 그렇기에 JPA는 지연로딩할 객체의 자리에 null을 넣어야할지 프록시를 넣어야할지 선택의 순간이 온다.

양방향 관계에서 외래키를 가지고 있는 연관 관계의 주인 엔티티는 지연로딩으로 설정해둔 객체 필드에 null을 넣어줄지 프록시객체를 넣어줄지 알고 있다. 하지만 외래키가 존재하지 않는, 주인이 아닌 객체는 이 판단이 불가능하다. 그렇기에 위의 경우처럼 쿼리를 하나 더 보내서 연관된 엔티티를 조회하는 과정이 필요하다. 조회를 해서 null인 경우엔 null을 넣고, 객체가 있다면 이 때는 프록시를 만들지 않고 방금 조회한 실제 객체를 바로 사용한다. 그렇기에 즉시 로딩처럼 작동한다. 이러한 이유로 @OneToOne 양방향 연관관계의 주인이 아닌 상황이라면 지연로딩을 적용해도 원하는 결과를 얻을 수 없다.

그렇다면 @OneToMany 컬렉션에서는 ?

그렇다면 연관 관계의 주인이 아닌 @OneToMany 컬렉션 필드도 지연로딩이 불가능할까? 하지만 그렇지 않다. 여기선 지연로딩이 가능하다. 왜냐면 데이터가 없는 컬렉션은 null이 아니라 Empty로 표현이 가능하기 때문이다. 그렇기에 empty collection proxy가 생성되고 지연로딩이 가능하다.

(참고 : www.inflearn.com/questions/224187)

해결책

JPA는 N+1 문제에서 N번 발생할 쿼리를 묶어 보내는 방식으로 최적화를 도와준다. 그 옵션이 Batchsize 설정이다. 지정한 size만큼 in절에 묶어서 조회를 하는 식이다. 하지만 batchsize 를 걸어줘도 일대일 관계에서는 null인지 확인하는 과정이 필요하기에 조회쿼리는 여전히 발생했다.

그렇다면 이젠 페치 조인을 적용시키서, 조인을 통해 연관된 객체를 가져오자.

이처럼 페치조인을 이용하면 연관된 객체를 조인방식으로 가져올 수 있다.

정리

JPA는 N번의 쿼리를 날리는 방식, 조인으로 가져오는 방식으로 연관된 객체를 가져올 수 있다.
연관된 객체가 null일 수 있는 경우에는 프록시를 바로 만들 수 없어서, 연관된 객체를 탐색하는 쿼리가 발생한다. (즉시로딩처럼 동작하게 된다.)
2번의 경우가 @OneToOne 양방향 연관관계에서 관계의 주인이 아닌 경우에 해당한다.
이 경우에 페치조인을 걸어준다면, 연관된 객체를 탐색하는 쿼리를 줄일 수 있다.

참고

책 - <자바 ORM 표준 JPA 프로그래밍>

www.inflearn.com/questions/224187

OSIV와 더티 체킹

민철킴 — Tue, 30 May 2023 21:34:12 +0900

OSIV 를 default 값인 true인 상태로 개발을 하다가, false로 바꾸고 이에 따른 더티 체킹이 작동하지 않는 문제를 겪었습니다. OSIV에 대한 설명과 개선해 간 과정을 적은 글입니다. 틀린 부분이 있을 수 있습니다.

먼저 OSIV를 모르는 상태로 기능을 구현하는 중이였다. 그러다가 동욱님의 블로그 글(jojoldu.tistory.com/272)을 읽다가 OSIV라는 단어를 접했고, 이걸 false로 변경하기로 했다.

OSIV (Open-Session-In-View)

OSIV는 Hibernate 세션(DB작업을 수행하기 위한 논리적 트랜잭션 컨텍스트)을 뷰까지 열어두는 패턴을 의미한다. 스프링에서 이 패턴을 구현한 클래스로는 OpenSessionInViewInterceptor 클래스가 있다. 이 클래스의 인스턴스가 Spring MVC의 인터셉터 레지스트리에 등록되어 해당 패턴을 사용한다.

public void preHandle(WebRequest request) throws DataAccessException

Open a new Hibernate Session according and bind it to the thread via the TransactionSynchronizationManager.

public void afterCompletion(WebRequest request, @Nullable Exception ex) throws DataAccessException 

Unbind the Hibernate Session from the thread and close it.

공식문서를 보면 해당 클래스는 위의 메서드들을 가지고 있다. 풀어보면 클라이언트에서 요청이 도착하면 이 인터셉터는 Hibernate 세션을 시작한다. 기본적으로는 트랜잭션 시작되면 세션이 시작되고, 트랜잭션이 끝나면 세션도 종료된다. 하지만 이 패턴에서는 요청이 시작되는 순간부터 세션이 열리고 뷰 렌더링 시점까지 같은 세션이 유지되는 특징을 가진다.

baeldung 에서도 OSIV를 논란이 많고(Controversial) 양날의 검(double-edged sword)이라고 소개하고 있다. 그러면 왜 논란이 많은지 장단점을 알아보자.

https://www.baeldung.com/spring-open-session-in-view

OSIV On&Off 장단점

먼저 장점은 지연로딩이다.

프레젠테이션 레이어에서 연관 관계가 지연 로딩이 설정된 엔티티에 접근하는 경우에 LazyInitializationException 이 발생한다. 영속성 컨텍스트가 끝난 상태에서 지연 로딩으로 생성된 프록시 객체에 접근할 경우, 이 프록시 객체가 데이터베이스에서 실제 객체의 데이터를 가져올 수 없기 때문에 해당 에러가 발생한다.

OSIV를 활성화시켜서 영속성 컨텍스트를 계속 유지한다면 이러한 에러 없이 지연로딩이 가능해진다.
즉, 이 장점 때문에 사용하는 것이다. 뷰 렌더링 단계까지 세션을 열어두어 LazyInitializationException 없이 지연로딩을 허용할 수 있기 때문에 OSIV를 사용한다.

하지만 단점은

여러 트랜잭션이 하나의 영속성 컨텍스트를 공유해서 사용한다는 점이다. 이로 인해 의도치 않은 데이터가 저장될 수 있다.
한 번 획득한 DB 커넥션을 뷰 렌더링이 끝날 때까지 유지한다. 이로 인해 커넥션이 모자라 성능 이슈의 원인이 된다.

이러한 단점들로 OSIV를 off 하기로 했다.

하지만 문제가 발생했다.

@RequiredArgsConstructor
@Component
public class MemberArgumentResolver implements HandlerMethodArgumentResolver {
		
		// ...

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        return parameter.hasParameterAnnotation(LoginMember.class);
    }

    @Override
    public Object resolveArgument(
            MethodParameter parameter, ModelAndViewContainer mavContainer,
            NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {

        HttpServletRequest request = webRequest.getNativeRequest(HttpServletRequest.class);

        String token = authExtractor.extract(request);
        if (tokenService.getBlackList(token) != null) {
            return new InvalidAccessTokenException();
        }

        String oAuth = Optional.ofNullable(token)
                .filter(t -> jwtTokenProvider.validateToken(t))
                .map(t -> jwtTokenProvider.getPayload(t))
                .orElseThrow(InvalidAccessTokenException::new);

		Member member = memberRepository.findByOAuth(oAuth);
		return member;
    }
}

먼저 나는 accessToken에서 oauth를 꺼내오고 그걸로 Repository를 호출해서 멤버 엔티티를 조회해 @LoginMember 어노테이션에 바인딩해주고 있다.

그리고 이 어노테이션을 컨트롤러 파라미터로 사용중이다. 아래처럼 말이다.

public ResponseEntity<?> changePosition(@LoginMember final Member member) {
	memberService.changePosition(member);
	...
}

또한 서비스단에서 상태 변경을 더티 체킹에 의존하게 코드를 짰다. 하지만 OSIV 를 off 시키니 더티 체킹이 더 이상 이루어지지 않았다.

원인은 다음과 같다.

더티 체킹은 영속성 컨텍스트 안에서 엔티티들의 변경 사항을 감지하는 기술이다. 이 영속성 컨텍스트에 해당하려면 2가지 경우에만 가능하다. 트랜잭션 범위 내에서 엔티티를 조회해 온 경우이거나 save 한 엔티티만 가능하다.

즉, 파라미터로 전달받은 엔티티는 영속성 컨텍스트에 들어가지 못한다. 그렇기에 변경 감지 대상이 아니고 더티 체킹은 이뤄지지 않는다.

OSIV가 활성화된 상태라면, 클라이언트의 요청 시작 시점부터 영속성 컨텍스트의 범위에 해당한다. 그렇기에 컨트롤러 단에서 넘겨받은 객체도 더티체킹이 가능했다. 그렇다면 OSIV가 off인 상황에서 어떻게 해결할 수 있을까?

더티 체킹 안 하기
더티 체킹을 하지 않고 비지니스 로직이 끝나기 전에, 직접 JpaRepository의 save() 메서드를 호출할 수 있다. 하지만 비지니스 로직과 영속성 로직이 함께 존재하게 된다.
서비스단에서 엔티티 조회하기
ArgumentResolver에서 엔티티를 직접 조회해서 바인딩 시키지 않고, 엔티티를 조회할 수 있는 값으로 바인딩시킨다. 컨트롤러에서 해당 값을 서비스 로직으로 보내고 거기서 엔티티를 조회하게 바꾼다.

나는 2번째 방법을 선택했다.

String oAuth = Optional.ofNullable(token)
            .filter(t -> jwtTokenProvider.validateToken(t))
            .map(t -> jwtTokenProvider.getPayload(t))
            .orElseThrow(InvalidAccessTokenException::new);

return new LoginMemberDto(oAuth);

LoginMemberDto라는 oAuth 값만 가지는 DTO 클래스를 만들고 이를 @LoginMember에 바인딩시켜 주는 방법으로 해결했다.

이 방법을 선택한 이유는 먼저 기존에 사용하던 더티 체킹을 유지하고 싶었다. 또한 컨트롤러단(ArgumentResolver)에서 Repository단으로 멤버를 조회하지 않기에 의존성을 줄일 수 있다는 점과 서비스단에서 엔티티를 조회하는 게 레이어 간의 역할에 더 바람직하다고 느꼈기 때문이다.

AOP를 활용한 공통 기능 구현

민철킴 — Thu, 25 May 2023 01:23:54 +0900

본 글은 AOP로 기능 구현한 내용을 다루는 글입니다. 개념적인 설명이 미흡할 수 있고, 틀린 부분이 존재할 수 있습니다. 피드백 해주시면 정말 감사하겠습니다 :)

어플리케이션 전반에 퍼져있는 공통된 부가 기능들을 관심사(Aspect)라고 한다. 우리가 널리 쓰고 있는 트랜잭션이 Aspect의 예다. 트랜잭션이 필요한 메서드마다 트랜잭션을 얻고 커밋과 롤백 등의 로직을 구현해야 한다면, 코드가 복잡해질 것이다. 이처럼 비지니스 로직과 달리 부가적으로 들어간 기능을 관심사(Aspect)라고 정의하고 이를 비지니스 로직에서 분리시킬 것이다.

Aspect Oriented Programming(AOP)
OOP는 비즈니스 로직의 중복을 제거하기 위함이고 AOP는 인프라 로직 중복을 제거하기 위함이다. 여기서 인프라 로직은 트랜잭션 로직, 로깅, 성능 측정을 예로 들 수 있다. 위의 트랜잭션의 경우처럼 인프라 로직인 많은 중복 코드를 양산할 뿐아니라, 가독성과 유지보수를 어렵게 한다. AOP를 활용해 인프라 로직의 중복을 제거함으로써 개발자는 비즈니스 로직에 집중할 수 있다.

AOP 사용하는 용어
target : 부가 기능을 부여할 대상
advice : 부가 기능을 정의한 메서드
pointcut : advice가 적용될 target을 지정하는 것을 의미

더 많은 용어들이 있지만, 이 3개의 용어를 중점으로 구현한 코드를 설명하려고 한다.

나는 처리율 제한장치와 분산락을 AOP로 구현했다.
먼저 처리율 제한장치를 구현한 코드다.

@Aspect  
@Component  
@RequiredArgsConstructor  
public class RateLimitAspect {  
    private final RateLimiter rateLimiter;  

    @Pointcut("@annotation(org.springframework.web.bind.annotation.GetMapping) || @annotation(org.springframework.web.bind.annotation.PostMapping)")  
    public void rateLimitPointcut() {}  
  
    @Around("rateLimitPointcut()")  
    public Object rateLimitAround(ProceedingJoinPoint joinPoint) throws Throwable {  
        ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();  
        HttpServletRequest request = attributes.getRequest();  
        String identifier = getClientIpAddr(request);  
        String methodName = joinPoint.getSignature().getName();  
        
        if (!rateLimiter.isAllMethodAllowed(identifier,5,50)) {  
            throw new TooManyRequestException();  
        }  
        return joinPoint.proceed();  
    }  
}

@Component  
public class RateLimiter {  
  
    private final RedisTemplate<String, Integer> rateLimiterTemplate;
    
	@Autowired  
	public RateLimiter(  
            @Qualifier("rateLimiterRedisTemplateBean") RedisTemplate<String, Integer> rateLimiterTemplate  
	) {  
		this.rateLimiterTemplate = rateLimiterTemplate;  
	}
	
	public boolean isAllMethodAllowed(String identifier, int second, int limit) {  
        String key = identifier;  
        Long count = rateLimiterTemplate.opsForValue().increment(key, 1);  
        rateLimiterTemplate.expire(key, second, TimeUnit.SECONDS);  
        return count <= limit;  
    }  
}

클래스 위에 @Aspect 어노테이션으로 해당 클래스가 AOP 관련 advice와 pointcut을 정의하는 클래스임을 나타내고 있다.

@Pointcut 어노테이션으로 부가 기능의 대상이 될 타겟 어노테이션을 설정해 주고 있다. @GetMapping, @PostMapping 이 붙은 메서드가 타겟이 되는 것이다.

@Around는 위 @Pointcut 어노테이션이 적용된 rateLimitPointcut() 메서드를 적용 대상으로 설정한다.
return 문에 작성된 joinPoint.proceed()는 대상 메서드를 실행하는 역할을 한다. 그 위에 들어가는 ratelimiter 관련 로직이 advice에 해당하는 로직이다. 처리율 제한 로직이라는 부가 기능을 구현한 것이다.

이렇게 적용을 하면, @PostMapping 또는 @GetMapping 어노테이션이 붙은 컨트롤러 메서드는 실제 메서드가 실행되기 전에 위의 adivce로직이 실행된다. 위 경우엔 같은 ip로 5초 동안 50번 넘게 요청한 경우에 429(TooManyRequest) 에러를 내며, 대상 메서드는 실행되지 않게 된다.

advice 를 적용하는 부분은 @Around, @Before, @After 가능하다. 각각은 대상 메서드 실행 전과 후에 advice 로직을 적용하는 걸로 구분이 되며, 위의 내 경우엔 대상 메서드 실행 전에만 advice 로직이 적용됨으로 @Before 를 써도 무방하다. 또한 메서드의 예외 지점에도 pointcut을 적용할 수 있다(@AfterThrowing).

@Aspect  
@Component  
@RequiredArgsConstructor  
@Slf4j  
public class LockAspect {  
  
    private final RedissonClient redissonClient;  
    private final Transaction4Aop transaction4Aop;  
  
    @Around("@annotation(com.project.book.common.config.aop.DistributedLock)")  
    public Object lock(final ProceedingJoinPoint joinPoint) throws Throwable {  
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();  
        Method method = signature.getMethod();  
        DistributedLock annotation = method.getAnnotation(DistributedLock.class);  
  
        String key = annotation.key();  
        RLock lock = redissonClient.getLock(key);  
  
        try {  
            boolean available = lock.tryLock(annotation.waitTime(), annotation.leaseTime(), annotation.timeUnit());  
  
            if (!available) {  
                return false;  
            }  
  
            return transaction4Aop.proceed(joinPoint);  
        } catch (InterruptedException | IOException e) {  
            log.error("DistributedLock error : " + e.getMessage());  
            throw new RuntimeException();  
        } finally {  
            if (lock.isHeldByCurrentThread() && lock.isLocked()) {  
                lock.unlock();  
            }  
        }  
    }  
}

이젠 분산락을 적용한 AOP 로직을 보겠다. 위의 rateLimit와 다른 부분은 따로 @Pointcut 어노테이션을 사용하지 않고, @Around에 Pointcut 표현식으로 적용될 어노테이션을 직접 입력해 줬다.

위의 rateLimitAspect처럼 pointcut 지정 메서드를 만들어 동일한 pointcut을 참조해야 하는 경우에 재사용에 유리하게 구성해도 되고, LockAspect 클래스처럼 별도의 @Pointcut 없이 @Around 어노테이션에 직접 지정할 수도 잇따.

그리고 여기선 transaction4Aop.proceed(joinPoint); 로 대상 메서드를 호출하는데 호출 전, 후에 로직이 들어가니 @Before나 @After 가 아닌 @Around가 적절하다.

인텔리제이에서는 만들어준 Aspect가 어디에 적용되는지 쉽게 확인할 수 있다.

프록시 패턴

Spring AOP는 프록시 패턴을 기반으로 동작한다. 부가 기능을 프록시로 감싸서 실행을 하는 방식이다. 여기서 부가 기능이 advice다.
런타임 시에 스프링은 Aspect 클래스를 검색한다. 그리고 타겟 클래스를 감싼 프록시 객체를 생성하는데 여기엔 정의된 advice를 포함해서 프록시 객체가 만들어진다. 프록시 객체는 타겟 클래스의 모든 메서드를 포함하고 있는건 아니다. pointcut에 매칭되는 타겟 메서드에 대해서만 감싸지며, 타겟 메서드가 아니라면 프록시 객체에 포함되지 않는다. 이렇게 pointcut으로 지정된 메서드들의 요청은 프록시 객체에 먼저 전달되어, 프록시 객체는 개발자가 구현한 어드바이스 로직을 처리한 후에 타겟 객체의 메서드를 실행한다. advice가 @Before를 제외한 다른 종류인 경우, 타겟 객체의 메서드가 실행된 후에 반환값을 프록시로 전달되어 추가 로직 등의 작업을 거친 후에 클라이언트로 반환된다.

참고
https://gmoon92.github.io/spring/aop/2019/01/15/aspect-oriented-programming-concept.html
https://tecoble.techcourse.co.kr/post/2021-06-25-aop-transaction/

분산락을 이용한 동시성 이슈 해결

민철킴 — Sun, 14 May 2023 14:00:21 +0900

분산락이 필요한 상황 설명

유저들이 검색한 검색어를 Redis의 Sorted Set에 저장하고, 그걸 바탕으로 인기 검색어를 구현했다. 검색될 때마다 Redis에 저장시켰는데, 통신부하를 줄여보기 위해서 검색어를 서버에 리스트 안에 모아서 100개가 되면 Redis에 보내게 바꿨다.

지금 내 토이프로젝트 상황으로는 검색어 100개를 모으려면, 100일은 더 걸릴 것이다. (사용하는 유저가 없다..ㅠ) 그렇기에 100개가 안 되더라도 Redis에 저장시키기 위해서, 스케줄러로 하루에 2번씩 모아진 검색어를 저장시키게 했다.

하지만 문제가 발생했다! 왜냐하면 난 2대의 서버를 운영중이기 때문이다. 2대의 서버가 동시에 레디스로 데이터를 보내는데 여기서 동시성 이슈가 터졌다. 검색한 검색어 일부가 Redis에 저장이 안 된걸 확인했다.

분산락이란

분산 환경에서 동시성 이슈를 처리하기 위해 등장한 방법인 분산 락은 여러 서버 또는 프로세스에서 공유 리소스(여기선 Redis)에 대한 액세스를 조정하는 기술이다. 내 경우에서도 분산락을 적용하면 해결이 가능해보였다. Redis를 이용해 분산락을 적용했다.

서버들은 락을 획득하기 위해서, Redis에 특정 키 생성을 시도한다. 키가 존재하지 않는다면 지정된 시간동안 락을 획득하고 공유 리소스에 대한 접근 권한을 얻는다. 만약 키가 존재한다면 락을 획득하려는 시도는 실패한다. 공유 리소스에 대한 작업이 끝난다면 Redis에서 해당 키를 삭제해서 락을 해제한다. 그러면 대기하던 서버가 락을 획득하게 되는 것이다.

그렇다면 서버는 락이 해제되었는지 어떻게 알게 될까? 하나는 서버가 Redis에 주기적으로 확인하는 방식이고, 다른 하나는 pub/sub 방식으로 락이 해제되면 메세지를 받는 방식이다. 첫 번째 방식은 해제를 확인하기 위해서 많은 트래픽이 발생될 여지가 있기에 두 번째 방식으로 구현했다.

구현

두 번째 방식은 Redisson 라이브러리를 사용해 구현이 가능하다.기존에도 Redis를 사용중이기에 의존성만 추가해주면 사용이 가능하다. Redis를 사용하고 있지 않았다면, port나 호스트 주소 등을 설정해서 빈으로 등록시켜줘야 한다.

implementation 'org.redisson:redisson-spring-boot-starter:3.17.6'

LockService

@Service
public class LockRankingService {
    private static final String LOCK_KEY ="RANKING_LOCK";
    private static final int WAIT_TIME = 10;
    private static final int LEASE_TIME = 5;

    private final RedissonClient redissonClient;
    private final RankingService rankingService;

    public LockRankingService(RedissonClient redissonClient, RankingService rankingService) {
        this.redissonClient = redissonClient;
        this.rankingService = rankingService;
    }

    public void record() {
        RLock lock = redissonClient.getLock(LOCK_KEY);

        try {
            boolean available = lock.tryLock(WAIT_TIME, LEASE_TIME, TimeUnit.SECONDS);

            if (available) {
                rankingService.searchKeywordToRedis();
            }

        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        } finally {
            if (lock.isHeldByCurrentThread() && lock.isLocked()) {
                lock.unlock();
            }
        }
    }
}

Lock을 위해서 별도의 서비스를 만들고 RedissonClient를 주입받는다.

“Ranking_Lock”이라는 키로 락을 생성해서 락을 얻는다. 락을 얻는 것에 성공한다면 Redis에 검색어를 저장시키는 searchKeywordToRedis() 메서드가 실행된다. 마지막으로 unlock()을 통해 락을 해제한다.

여기서 waitTime은 락 획득을 하기위해 대기할 최대 시간을 나타내고, leaseTime은 락의 유효 시간을 나타나며 leaseTime이 지나면 락은 자동 해제된다.

@Service
@RequiredArgsConstructor
public class SchedulerRankingService {

    private final LockRankingService lockRankingService;

    @Scheduled(cron = "0 0 11,23 * * *")
    public void scheduleSearchKeywordToRedis() {
        lockRankingService.record();
    }
}

구현한 분산락을 적용해서 데이터가 누락되는 이슈를 해결할 수 있었다.

내 토이프로젝트에서는 책을 등록하는 메서드가 존재한다. 평점 등의 정보도 같이 입력해서 유저가 읽은 책을 등록할 수 있게 해준 기능이다. 만약 같은 책에 대해서 여러 요청이 동시에 들어온다면, 데이터의 정합성이 깨질 우려가 있다. 그러면 여기에도 분산락을 적용해보려 한다.

LockRankingService와 같은 로직을 매번 만들기는 번거롭다.락을 걸어주는 로직은 비지니스 로직과는 관련없는 코드다. 그렇기에 AOP를 적용해 락에 관한 로직을 분리시키려한다.

분산락을 적용할 메타 어노테이션

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface DistributedLock {
    String key();
    long waitTime() default 10L;
    long leaseTime() default 5L;
    TimeUnit timeUnit() default TimeUnit.SECONDS;
}

메타 어노테이션이 수행되는 AOP 클래스

@Aspect
@Component
@RequiredArgsConstructor
@Slf4j
public class LockAspect {

    private final RedissonClient redissonClient;
    private final Transaction4Aop transaction4Aop;

    @Around("@annotation(com.project.book.common.config.aop.DistributedLock)")
    public Object lock(final ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        DistributedLock annotation = method.getAnnotation(DistributedLock.class);

        String key = annotation.key();
        RLock lock = redissonClient.getLock(key);

        try {
            boolean available = lock.tryLock(annotation.waitTime(), annotation.leaseTime(), annotation.timeUnit());

            if (!available) {
                return false;
            }

            return transaction4Aop.proceed(joinPoint);
        } catch (InterruptedException | IOException e) {
log.error("DistributedLock error : " + e.getMessage());
            throw new RuntimeException();
        } finally {
            if (lock.isHeldByCurrentThread() && lock.isLocked()) {
                lock.unlock();
            }
        }
    }
}

메타 어노테이션에 설정한 key를 바탕으로 락을 획득하는 로직을 구현했다. 위의 LockService 로직과 같다.

@Component
public class Transaction4Aop {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public Object proceed(final ProceedingJoinPoint joinPoint) throws Throwable {
        return joinPoint.proceed();
    }
}

AOP를 적용할 메서드의 트랜잭션 처리를 위해서 별도의 클래스를 만들었다. 만약 1번 락의 트랙잭션이 커밋되지 않은채로 락이 해제되고, 다음 락이 작업에 들어간다면 데이터의 정합성을 보장할 수 없다.

이를 방지하기 위해서 획득한 락 안에서 새로 트랜잭션을 생성해준다. proceed() 메서드가 완료되고, 즉 트랜잭션이 커밋되고 finally 블록에서 락이 해제되기에 데이터 정합성을 지킬 수 있게 된다.

@Service
@RequiredArgsConstructor
public class SchedulerRankingService {

    private final RankingService rankingService;

    @Scheduled(cron = "0 0 11,23 * * *")
    @DistributedLock(key = "ranking")
    public void scheduleSearchKeywordToRedis() {
        rankingService.searchKeywordToRedis();
    }
}

AOP를 적용해 변경한 로직이다. watiTime,leaseTime은 원하는 값을 @DistributedLock에 파라미터로 넣어주면 된다. 여기선 설정해둔 디폴트 값으로 실행된다.

페이지네이션 구현과 성능 개선

민철킴 — Sat, 6 May 2023 02:26:18 +0900

페이지네이션 구현

페이지네이션은 데이터를 페이지 단위로 나누어 화면에 보여주는 기능이다. 전체 데이터가 아니라 필요한 페이지의 데이터만 불러오기 때문에 성능을 향상시킬 수 있다. 물론 사용자 경험도 훨씬 좋다.

밑의 화면처럼 페이지네이션을 화면에 만들기 위해선 토탈 페이지 카운트를 알아야한다. 그렇기에 페이지네이션이 이루어지려면 페이지당 몇 개의 데이터를 보여줄건지와 토탈 페이지 카운트를 알려줘야 한다.

<페이지네이션>

내 프로젝트의 프론트엔드는 <v-pagination> 컴포넌트를 이용해서 페이지네이션을 구현했다. 여기서 보다시피 length 속성으로 토탈 페이지 카운트를 입력받고 있다.

<v-pagination
      :length="getPageCount"
      ...
    />

프론트엔드에서 전체 데이터 개수로 토탈 카운트를 구할 수 있지만, 백엔드에서 토탈 카운트를 보내주는게 일반적이다.

백엔드에서는 Pageable 인터페이스를 구현한 PageRequest 클래스를 사용해서 요청을 입력받고 Page 인터페이스를 구현한 PageImpl 클래스로 응답을 해줬다.

Pageable는 페이지 번호, 페이지 크기, 정렬 기준 등의 요청 정보를 캡슐화한 인터페이스다. 반면 Page 인터페이스는 페이지 번호, 토탈 페이지 카운트, 페이지 내의 데이터 등의 응답 정보를 캡슐화한 인터페이스다.

public Page<?> getAllBook(final AllBookFilterDto condition, Pageable pageRequest) {
        ...
        List<AllBookResponseDto> allBooks = bookRepository.getAllBooks(condition, pageRequest);
        Long totalCount = fetchTotalCount(condition);

        return new PageImpl<> (allBooks, pageRequest, totalCount);
    }

요청에 맞는 페이지 당 데이터, 전체 데이터 수, 페이지 요청 객체를 사용하여 PageImpl 객체를 생성하고 이를 반환해주고 있다.

Limit과 Offset을 이용해서 쿼리를 보내고, 페이지 당 데이터를 가져온다. Limit은 한 페이지에 표시할 데이터의 수를 지정하는 것이며, Offset은 검색을 시작할 데이터의 위치를 지정하는 것이다. 그렇기에 Offset은 (현재 페이지 - 1) x (Limit)으로 계산됩니다.

예를 들어 10개씩 보여주는 화면에서 4페이지를 눌렀다면, Offset은 (4-1) x 10 으로 30이 되며, 30번째 데이터부터 39번째 데이터까지 가져온다.

개선점

1. Offset → No-Offset

Offset 기반 페이지네이션은 뒤 페이지로 갈수록 처리 시간이 증가하게 된다. 예를 들어, n번째 페이지를 눌렀다고 하자. 그러면 1페이지부터 n페이지까지의 전체 데이터를 스캔하고 n페이지에 해당하는 데이터만 읽어온다. 즉, Full Scan 방식으로 offset + limit 에 해당하는 레코드를 모두 읽은 뒤, 그 중 마지막 limit 수의 레코드만 가져오는 것이다.

그렇다면 이 단점을 보완한 No-Offset 방식도 있다. 가져올 데이터의 시작 부분을 인덱스로 찾아서 매번 Limit 수의 레코드만 읽는 방식이다.

SELECT *
FROM book
WHERE 조건문
AND id < 마지막 조회 id
LIMIT 페이지 사이즈

이처럼 특정 위치를 지정해서 매번 같은 사이즈의 데이터를 읽어온다.

처음에 페이지네이션 구현할 때, No-Offset 방식인 무한 스크롤을 가장 먼저 시도했었다. 하지만 내 경우엔 책 마다 차트를 포함하고 있다. 차트는 <canvas> 태그를 이용해서 그려준다. 무한 스크롤로 새로운 데이터를 렌더링 해줄 때, 이미 차트를 그릴 Canvas 태그가 사용 중이어서 렌더링이 안되는 에러가 발생했다. 백엔드에서 보내준 데이터는 잘 전달이 됬지만, 차트가 그려지지 않았다. 아래 사진처럼 <이순신>까지가 첫 페이지 데이터고 엑박 뜬 부분이 무한 스크롤로 불러온, 쉽게 말하면 2페이지 데이터다. 차트가 안 뜨면서 다른 데이터들도 화면에 제대로 나타나지 않았다. 여러 블로그를 참고해가며 수정하려 했지만 결국 차트를 그리지 못 했다.

그렇기에 No-Offset 방식의 페이지네이션은 구현하지 못 했고, Offset 방식의 페이지네이션을 사용하게 됐다.

2. Count 쿼리 최적화

Offset 방식은 데이터를 조회하는 쿼리와 count 쿼리가 동시에 발생한다. count 쿼리는 전체 데이터를 확인하기 때문에 데이터가 많아질수록 응답 시간은 늘어난다.

그렇다면 매번 count 쿼리가 필요할까?

첫 페이지 요청때 백엔드에서 넘겨준 토탈 카운트를 프론트에서 캐싱하고 있다가 2번째 페이지 요청부터는 토탈 카운트를 같이 백엔드에 보내게 변경을 했다.

프론트엔드 코드

백엔드 응답값에서 토탈 카운트를 저장한다.

그리고 페이징 요청시 카운트도 함께 보내게 변경했다.

백엔드 코드(condition안에 토탈 카운트 포함)

public Page<?> getAllBook(final AllBookFilterDto condition, Pageable pageRequest) {
        ...

        List<AllBookResponseDto> allBooks = bookRepository.getAllBooks(condition, pageRequest);
        Long totalCount = fetchTotalCount(condition);

        return new PageImpl<> (allBooks, pageRequest, totalCount);
    }

// 카운트 가져오는 메서드
private Long fetchTotalCount(AllBookFilterDto condition) {
        if (condition.getTotalCount() == null) {
            return bookRepository.countAllBooks(condition);
        }
        return condition.getTotalCount();
    }

이렇게 변경해서 첫 페이지 외의 요청에서 count쿼리를 호출하지 않게 된다.