서론: 재시도할 실패와 건너뛸 실패 네트워크 타임아웃은 잠시 뒤 성공할 수 있지만 잘못된 주민번호 형식은 백 번 재시도해도 성공하지 않는다. 모든 예외를 재시도하면 작업 시간이 폭증하고, 모든 예외를 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...

서론: 인덱스를 추가하기 전에 계획을 읽자 느린 쿼리를 보면 조건 컬럼마다 인덱스를 만드는 경우가 많다. 하지만 Planner는 데이터 분포·통계·예상 비용을 바탕으로 순차 스캔, 인덱스 스캔, 조인 순서를 고른다. 인덱스가 있어도 많은 행을 읽어야 하면 순차 스캔이 더 빠를 수 있다. 1. EXPLAIN과 EXPLAIN ANALYZE EXPLA...

서론: 읽기와 쓰기가 서로를 보는 방식 PostgreSQL 성능과 장애를 이해하려면 MVCC(Multi-Version Concurrency Control)에서 시작해야 한다. 행을 수정할 때 기존 값을 즉시 덮어쓰는 대신 여러 버전을 만들고, 각 트랜잭션이 자신의 스냅샷에 보이는 버전을 읽는다. 이 덕분에 읽기와 쓰기의 충돌이 줄지만 오래된 행 버전...

서론: 보안은 로그인 기능으로 끝나지 않는다 Day 1~4에서 인증 상태와 권한 경계를 만들었다. 하지만 브라우저가 자격 증명을 자동 전송하는 특성, 다른 출처의 스크립트, 잘못 노출된 관리 엔드포인트가 이 경계를 우회할 수 있다. 마지막 날은 보안 설정을 공격 방어와 운영 절차까지 확장한다. 1. CSRF는 자동 전송되는 자격 증명을 노린다 사...

서론: 로그인했다고 모든 데이터가 내 것은 아니다 인증은 사용자의 신원을 확인하고, 인가는 그 사용자가 특정 행동을 해도 되는지 판단한다. 관리자 URL을 막는 것만으로는 부족하다. 일반 사용자도 다른 사용자의 주문 ID를 추측해 조회할 수 있다면 객체 수준 인가가 깨진다. 1. URL 규칙은 첫 번째 문이다 http.authorizeHttpRe...