격리 수준은 동시에 여러 트랜잭션이 실행될 때, 서로의 데이터를 어떻게 볼 수 있는지를 결정여러 트랜잭션이 동시에 같은 데이터를 읽거나 쓸 때 충돌이 생긴다 → DBMS는 이를 해결하기 위해 4단계의 격리 수준을 제공격리 수준이 높아질수록 데이터 정합성 ↑, 동시 처리 성능 ↓1. READ UNCOMMITTED아직 커밋되지 않은 데이터(Dirty Data)도 읽을 수 있음발생 가능한 문제A 트랜잭션이 바꾼 값을 B가 읽었는데 A가 롤백하면 B가 잘못된 데이터를 본 셈거의 안 씀 (정합성이 너무 약함) 2. READ COMMITTED (가장 많이 씀)커밋된 데이터만 읽음발생 가능한 문제Non-repeatable Read : 같은 데이터를 두 번 읽었는데, 그 사이에 다른 트랜잭션이 커밋해버리면 값이 달라짐..
propagation은 트랜잭션 전파(Propagation) 옵션이다.스프링의 @Transactional은 이미 진행 중인 트랜잭션이 있을 때, 새로 호출된 메서드가 그 트랜잭션에 어떻게 참여할지를 결정 1. REQUIRED(기본값)이미 트랜잭션이 있으면 → 거기에 합류없으면 → 새 트랜잭션 시작대부분의 경우 기본값으로 충분예: 서비스에서 레포지토리를 여러 번 호출해도 하나의 트랜잭션으로 묶임@Transactional(propagation = Propagation.REQUIRED) 사용 상황일반적인 서비스/DAO 호출 대부분예: 계좌 이체 서비스 → 출금 메서드, 입금 메서드 모두 같은 트랜잭션으로 묶여야 함@Transactional // REQUIRED 기본값public void transfer(....
1. 클래스 레벨 @Transactional@Service@Transactional(readOnly = true) // 클래스 레벨public class AccountService { public List list() { } public void findById(Long id) { } @Transactional // 메서드 레벨 public void transfer() { }}특징클래스 레벨에 붙이면 → 해당 클래스의 모든 public 메서드에 트랜잭션이 적용됨클래스 레벨에 설정된 속성 (readOnly = true)이 기본값이 됨메서드 별도로 @Transactional을 붙이면 그 메서드에는 메서드 설정이 우선 적용된다.위 코드에서는list() → readOnly = ..
트랜잭션이 반드시 지켜야하는 4가지 특성Atomicity(원자성)트랜잭션의 모든 작업이 전부 수행되거나(All), 전혀 수행되지 않아야 함(None)중간에 일부만 반영된 상태가 있으면 안 됨예: 계좌 이체A → B 송금할 때 A 계좌에서 돈이 빠지고 B 계좌에 입금이 동시에 완료되어야 함A에서만 돈이 빠지고 B에 입금 안 되면 원자성이 깨짐 → 롤백 필요Consistency(일관성)트랜잭션이 수행된 후에도 DB의 무결성 제약 조건이 항상 만족되어야 함즉, 데이터베이스는 유효한 상태에서 또 다른 유효한 상태로만 변해야 함예: 은행 계좌 시스템전체 계좌 잔액 합계가 트랜잭션 전후로 동일해야 함한쪽 계좌에서 빠진 만큼 다른 쪽에 반드시 더해져야 함Isolation (고립성, 격리성)동시에 실행되는 트랜잭션들이..
kkrap 프로젝트에서 EC2에 docker-compose와 docker를 사용하여 elasticsearch, postgreSQL, spring boot, redis, kafka, react/vite를 띄우고 있다. 각 프론트엔드 백엔드에서 수동으로 배포를 해서 쓰고 있었는데 자동화를 위해 CI/CD를 도입하는 과정의 문서이다. 개요무엇을 위한 기능인가?Kkrap 프로젝트는 EC2 환경에서 docker-compose를 기반으로 Elasticsearch, PostgreSQL, Spring Boot, Redis, Kafka, React/Vite 등 여러 서비스를 동시에 운영하고 있다. 지금까지는 프론트엔드와 백엔드를 각각 수동으로 빌드 및 배포했기 때문에, 배포 과정에서 많은 시간이 소요되고 환경별 일관성을..
CI(Continuous Intergration, 지속적 통합)→ 개발자들이 작성한 코드를 자주(하루에도 여러 번) 중앙 저장소에 통합하고, 자동 빌드/테스트를 거쳐 코드 충돌, 버그를 빠르게 발견하는 과정CD(Continuous Dlivery/Deployment, 지속적 제공/배포)→ CI에서 검증된 코드를 자동으로 스테이징 환경 → 운영 환경에 배포하는 과정Continuous Delivery: 자동 배포 준비까지 하고 실제 배포는 사람이 승인Continuous Deployment: 운영까지 완전 자동 배포 왜 이게 필요한가?빠른 피드백 → 코드 푸시하였을 때 버그나 성능 이슈를 즉시 확인배포 속도 향상 → 사람이 수작업으로 할 때는 실수가 잦지만 CI/CD는 코드 merge만 해도 자동으로 빌드 및 ..
