구독 중인 기술 블로그 RSS 피드 목록 이 블로그는 다양한 기술 소식을 RSS 피드로 구독하여 콘텐츠를 생성하고 있습니다. 토스 기술 블로그: https://toss.tech/rss.xml 카카오 기술 블로그: https://tech.kakao.com/feed/ 당근(Daangn) 미디엄 블로그: https://medium.com/f...

서론: 컨테이너 메모리는 Heap보다 크다 Java 프로세스의 메모리를 -Xmx 하나로만 보면 컨테이너가 OOMKilled 되는 이유를 설명하지 못한다. JVM은 객체 Heap 외에도 Metaspace, 스레드 스택, 코드 캐시, Direct Buffer, 네이티브 라이브러리 메모리를 사용한다. 운영 한도는 이들의 합이다. 1. JVM 메모리 지도...

서론: COMPLETED만으로 성공을 판단할 수 없다 프로세스가 오류 없이 끝났어도 일부 데이터가 빠지거나 금액 합계가 틀리면 배치는 실패다. 반대로 재시도 후 모든 업무 결과가 맞다면 중간 오류가 있어도 성공일 수 있다. 배치 운영은 프레임워크 상태와 업무 불변식을 함께 검증해야 한다. 1. 테스트 층위 단위 테스트: Processor의 변...

서론: 스레드를 늘리기 전에 병목을 찾자 배치가 느리면 worker 수부터 늘리기 쉽다. 하지만 병목이 DB 쓰기나 외부 API 제한이라면 동시성 증가는 대기와 락만 키운다. 대표 데이터로 단일 스레드 성능을 측정하고 CPU·I/O·DB·네트워크 중 포화 지점을 찾은 뒤 병렬화한다. 1. 가장 단순한 최적화부터 필요한 컬럼만 읽기 N+1 ...

서론: 재시도할 실패와 건너뛸 실패 네트워크 타임아웃은 잠시 뒤 성공할 수 있지만 잘못된 주민번호 형식은 백 번 재시도해도 성공하지 않는다. 모든 예외를 재시도하면 작업 시간이 폭증하고, 모든 예외를 Skip하면 데이터가 조용히 빠진다. 실패를 분류하는 것이 fault-tolerant 배치의 핵심이다. 1. 실패 분류표 일시적 인프라 오류: ...

서론: 다시 실행할 수 있어야 배치다 대량 작업은 언젠가 중간에 실패한다. 프로세스가 종료되고, 네트워크가 끊기고, 잘못된 한 행이 나타난다. 처음부터 다시 돌리는 비용이 크거나 중복 지급처럼 부작용이 있다면 재시작 가능성과 멱등성이 설계의 중심이 돼야 한다. 1. Reader·Processor·Writer의 책임 ItemReader: 처리할...

서론: 반복문이 배치 시스템이 되는 순간 DB에서 데이터를 읽어 반복문으로 처리하는 코드는 쉽게 만들 수 있다. 하지만 수백만 건 중 70%에서 실패하면 어디서 다시 시작할지, 같은 작업을 두 번 실행해도 안전한지, 처리 진행률을 어떻게 알지까지 요구되면 단순 반복문으로는 부족하다. Spring Batch는 이 운영 문제를 Job·Step·Chunk...

서론: 백업 파일이 아니라 복구 시간을 약속하라 운영 데이터베이스의 목표는 단순히 살아 있는 것이 아니다. 부하 급증에도 연결을 통제하고, 장애 때 정해진 데이터 손실과 시간 안에 서비스를 복구해야 한다. 백업 성공 로그만 있고 복원 훈련이 없다면 그 약속은 검증되지 않았다. 1. 연결 수는 한정된 자원이다 각 연결은 메모리와 백엔드 프로세스 자...

서론: 지운 행이 바로 사라지지 않는 이유 MVCC에서 UPDATE와 DELETE가 만든 이전 행 버전은 다른 트랜잭션이 볼 수 있어 즉시 제거할 수 없다. 더 이상 어떤 스냅샷에도 필요하지 않을 때 VACUUM이 공간을 재사용 가능하게 만들고 트랜잭션 ID 고갈을 막는다. VACUUM은 선택적 청소가 아니라 PostgreSQL 정상 동작의 일부다....

서론: 스키마는 가장 오래 사는 API다 애플리케이션 코드는 자주 바뀌지만 데이터는 여러 버전의 코드와 분석·배치·운영 도구가 함께 읽는다. 느슨한 스키마는 처음엔 빠르지만 잘못된 값이 쌓인 뒤 모든 쿼리와 마이그레이션의 비용으로 돌아온다. 1. 의미에 맞는 타입을 고르기 시간: 절대 시점은 timestamptz, 지역 일정은 별도 timez...