Repeat 스프링 배치는 특정 조건이 충족될 때까지 Job 또는 Step을 반복하도록 배치 애플리케이션을 구성할 수 있습니다. 스프링 배치에서는 Step과 Chunk의 반복을 RepeatOperation을 사용해 처리하고 있습니다. 기본 구현체로 RepeatTemplate을 제공합니다. 구조 Step은 RepeatTemplate을 사용해 Tasklet을 반복적으로 실행합니다. ChunkOrientedTasklet은 내부적으로 ChunkProvider를 통해 ItemReader로 데이터를 읽어올 것을 지시합니다. ChunkProvider는 내부적으로 RepeatTemplate을 갖고 있고 이를 이용해 반복적으로 ItemReader에게 반복적으로 데이터를 읽어오도록 처리합니다. FaultTolerant 스..

ItemProcessor 데이터를 출력하기 전에 데이터를 가공 및 필터링 역할을 하는 인터페이스입니다. ItemReader 및 ItemWriter와 분리되어 비즈니스 로직을 구현할 수 있습니다. ItemReader로부터 받은 아이템을 특정 타입으로 변환해서 ItemWriter에 넘겨줄 수 있습니다. Itemreader로부터 받은 아이템들 중 필터과정을 거쳐서 원하는 아이템들만 ItemWriter로 넘겨줄 수 있습니다. ChunkOrientedTasklet 실행 시 선택적 요소기 때문에 필수 요소는 아닙니다. O process() I 제네릭은 ItemReader에서 받을 데이터 타입 O 제네릭은 ItemWriter에게 보낼 데이터 타입 아이템을 하나씩 가공 처리하며 null을 리턴할 경우 해당 아이템은 C..

ItemWriter Chunk 단위로 데이터를 받아 일괄 출력 작업을 위한 인터페이스입니다. 플랫 파일 - csv, txt XML, Jsono Database Message Queuing 서비스 Mail Service Custom reader 다수의 구현체들이 itemReader와 같은 맥락으로 itemWriter와 ItemStream을 동시에 구현하고 있습니다. 하나의 아이템이 아닌 아이템 리스트를 전달받아 수행합니다. ChunkOrientedTasklet 실행 시 필수적 요소로 설정해야 합니다. void write() 출력 데이터를 아이템 리스트로 받아서 처리합니다. 출력이 완료되고 트랜잭션이 종료되면 새로운 Chunk 단위 프로세스로 이동합니다. 위와 같이 다양한 구현체들을 제공하고 있습니다. Jd..

ItemReader itemReader는 다양한 입력으로부터 데이터를 읽어서 제공하는 인터페이스입니다. 플랫 파일 - csv, txt XML, Json Database Message Queuing 서비스 Custom reader 다수의 구현체들이 ItemReader와 ItemStream 인터페이스를 동시에 구현하고 있습니다. ItemStream은 파일 스트림 연결 종료, DB 커넥션 연결 종료 등의 장치 초기화 등의 작업에 사용됩니다. ExecutionContext에 read와 관련된 여러 가지 상태 정보를 저장해 두고 재시작 시 참조됩니다. ChunkOrientedTasklet 실행 시 필수적 요소로 설정해야 합니다. T read() 입력 데이터를 읽고 다음 데이터로 이동합니다. 아이템 하나를 리턴하며..

Chunk 여러 개의 아이템을 묶은 하나의 덩어리를 의미합니다. 한 번에 하나씩 아이템을 입력받아 Chunk 단위의 덩어리로 만든 후 Chunk 단위로 트랜잭션을 처리합니다. Chunk 단위로 Commit과 Rollback Chunk Chunk, Chunk Chunk ItemReader로 읽은 하나의 아이템을 Chunk 크기만큼 반복해서 저장하는 타입 Chunk ItemReader로부터 전달받은 Chunk 를 참조해서 ItemProcessor에서 적절하게 가공한 뒤 ItemWriter로 전달되는 타입 여기서 O는 Processor가 없다면 ItemReader로부터 전달받는 타입, Processor가 있다면 Processor로부터 전달받는 타입입니다. 아키텍처 ItemReader가 Source를 한 건씩 ..

배치 애플리케이션이란? 배치(Batch)는 일괄처리란 뜻을 갖고 있습니다. 쇼핑몰에서 매일 전날의 매출 데이터를 집계해야 한다고 가정해 보겠습니다. 매출 데이터가 대용량이라면 하루 매출 데이터를 읽고, 가공하고, 저장한다면 해당 서버는 순식간에 CPU, I/O 등의 자원을 다 써버려서 다른 작업을 할 수 없게 됩니다. 집계 기능은 하루에 1번만 수행된다면 이를 위해 API를 구성하는 것은 낭비가 될 수 있고, 데이터 처리 중에 실패했다면 처음부터가 아니라 실패시점부터 다시 처리하고 싶을 수 있습니다. 이런 단발성으로 대용량의 데이터를 처리하는 애플리케이션을 배치 애플리케이션 이라고 합니다. 배치 애플리케이션은 다음 조건을 만족해야 합니다. 대용량 데이터 - 배치 애플리케이션은 대량의 데이터를 가져오거나,..

출처(Origin)이란? 출처(Origin)은 Scheme(protocol), Host, Port로 구성되어 있습니다. http, https의 경우에는 프로토콜이 포트 번호를 포함하고 있기 때문에 생략 가능하지만, 만약 포트를 명시함다면 포트번호까지 일치해야 출처가 같다고 볼 수 있습니다. 즉, scheme, host, port가 모두 일치하는 경우를 동일한 출처로 봅니다. # 기준이 되는 origin https://www.backtony.github.io # 같은 origin https://www.backtony.github.io/about https://www.backtony.github.io/about?q=hello https://user:password@www.backtony.github.io #..

Nginx 기본 구성 worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; server { listen 80; server_name localhost; access_log logs/host.access.log combined; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; loca..

NginX란? NginX는 웹 서버이며, 리버스 프록시, 로드 밸런서, HTTP 캐시로 등으로 쓰일 수 있는 소프트웨어입니다. 요청에 응답하기 위해 이벤트 기반 구조를 채택하여 자원을 효율적으로 사용합니다. 등장 배경 최초의 웹서버 NCSA에 수많은 버그로 인해 이를 보완한 아파치 서버가 등장합니다. 아파치 서버는 요청이 들어오면 커넥션을 형성하기 위해 프로세스를 생성하는 방식으로 새로운 클라이언트 요청이 들어올 때마다 새로운 프로세스를 생성합니다. 프로세스를 만드는 작업은 오래 걸리므로 미리 프로세스를 만들어 놓는 prefork 방식을 사용합니다. 만약 미리 만들어 놓은 프로세스가 모두 할당되었다면 추가로 프로세스를 만들게 됩니다. 이런 구조로 인해 개발자는 다양한 모듈을 만들어 빠르게 기능을 추가할 ..

order by 처리(using filesort) 정렬을 처리하는 방법은 인덱스를 이용하는 방법과 쿼리가 실행될 때 Filesort라는 별도의 처리를 이용하는 방법으로 나눌 수 있다. 인덱스 이용 장점 insert, update, delete 쿼리가 실행될 때 이미 인덱스가 정렬돼 있어서 순서대로 읽기만 하면 되므로 매우 빠름 단점 insert, update, delete 작업 시 부가적인 인덱스 추가/삭제 작업이 필요하므로 느리다. 인덱스 때문에 추가 디스크 공간이 필요하고 늘어날수록 innoDB의 버퍼 풀을 위한 메모리가 많이 필요하다. filesort 이용 장점 인덱스를 생성하지 않아도 되므로 인덱스를 이용할 때의 단점이 장점으로 바뀐다. 정렬해야 할 레코드가 많지 않으면 메모리에서 filesort..

쿼리튜닝을 위한 인덱스 특징(innoDB, B-Tree) 인덱스는 정렬되어 있다. 왼쪽 컬럼인 column_1 순으로 먼저 정렬되고, column_1이 같다면 column_2 순으로 정렬된다. 따라서 인덱스를 기준으로 조회한 데이터는 인덱스 컬럼 순으로 정렬되어 있다. 인덱스는 스캔하는 방식으로 처리된다. 중간중간 데이터를 읽는 것이 아니라, 시작지점을 잡고 종료지점까지 쭉 스캔한다. 인덱스는 메모리 위에 존재한다. column_1 = 'A'인 레코드 중에 column_3 이 필요하다면? 실제 column_1 = 'A'인 레코드를 모두 가져온 다음 물리 주소를 파악해서 물리 주소를 기반으로 디스크에서 값을 가져온다. 모든 컬럼 값을 인덱스에 올려놓을 수는 없기 때문에 성능적으로 타협하면서 세팅해야 한다...

datasource spring boot 2.x.x 기준에서 사용 가능한 connection pool은 3가지가 있습니다. hikariCP tomcat pooling datasource common dbcp2 spring boot 1.x.x에서는 tomcat이 default였으나 2.0.0부터 hikaricp가 default가 되었습니다. 그래서 spring-boot-starter-jdbc, spring-boot-starter-data-jpa를 사용하면, HikariCP(가장 높음) -> Tomcat pooling -> Commons DBCP2의 순위로 지정됩니다. 위의 우선순위를 무시하고 spring.datasource.type에 값을 통해 설정할 수도 있습니다. spring.datasource.typ..