의식의 흐름대로 써보는 DB 트랜잭션 이야기

썸네일용 '-'

🎯  무결성과 정합성?

무결성(Integrity) : 흠이 없이 온전함. 데이터 값이 정확한 상태인가 혹시 손상되었거나 이상한 값이 들어가있지는 않는가?

정합성(Consistency) : 모든 트랜잭션에서 [ 같은 데이터값 ]이 모순 없이 일치한가

[ 무결성과 정합성이 대체 뭐죠? ]

은행 DB에 '홍길동' 이라는 고객의 잔액은 0원 이상이어야 한다.

 

Case1
- 주문정보 테이블에 홍길동의 잔액은 -10 이다. (무결성이 깨졌다)
- 하지만 고객정보 테이블에도 홍길동의 잔액은 -10이다. (정합성만 일치한다.) 

Case2

- 주문정보 테이블에 홍길동 잔액은 10,000 이다. (무결성은 문제없다.)

- 하지만 고객정보 테이블에서의 홍길동 잔액은 2000 이다. (정합성만 깨졌다.)

 

이러한 무결성과 정합성을, 데이터베이스에선 테이블 '제약조건'으로 막을 수 있다.
물론 제약조건을 걸면 그만큼 데이터베이스의 성능은 나빠지고, 테이블을 유연하게 변경하기 어려워진다.

 

엔티티 무결성(Entity Integrity)	엔티티는 각 인스턴스를 유일하게 식별할 수 있는 속성이나 속성 그룹을 가져야 한다.
도메인 무결성(Domain Integrity)	칼럼 데이터 타입, 길이, 유효 값이 일관되게 유지되어야 한다.
참조 무결성(Referential Integrity)	데이터 모델에서 정의된 실체 간의 관계 조건을 유지하는 것이다.
업무 무결성(Business Integrity)	다양하게 정의될 수 있는 비즈니스 규칙이 데이터적으로 일관성을 유지하는 것이다.

---

 

 

🎯  트랜잭션?

트랜잭션이란 데이터를 조작하는 ACID 한 작업 단위이다.
[ ACID 한 작업단위라는게 무슨 말이죠? ]

 Atomicity(원자성) - 작업단위, 즉 트랜잭션을 더 이상 작은 단위로 쪼갤 수 없다.

• 한 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 모두가 완벽히 수행되지 않고 어느하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다. 부분 완료는 불가능하다.
• 보통 트랜잭션 성공 연산을 Commit(커밋), 실패 연산을 Rollback(또는 Aborted) 라 부른다.
  
  

Consistency(정합성) - 트랜잭션은 언제나 같은 입력에는 같은 결과가 나와야한다.

• 시스템이 가지고 있는 고정요소(제약조건)들은 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가 같아야 한다.
  
  

Isolation(독립성,격리성) - 각각의 트랜잭션은 독립적이다. 실행 중 서로 영향끼치지 않는다.

• 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행중에 다른 트랜잭션의 연산이 끼어들 수 없다.
• 수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다.
  
  

Durablility(영속성,지속성) - 트랙잭션에 의해 처리된 데이터는 영구적으로 저장된다.

• 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다.

 

데이터베이스에서 일어나는 모든 작업은 트랜잭션이 걸린다.

하지만 모든 작업을 데이터베이스 단에서 완벽히 ACID 하게 처리하려면, 테이블 잠금이 너무 많이 걸려 성능이 안좋아진다.

그래서 데이터베이스에선 트랜잭션 격리레벨이 존재한다.

 

 

🎯 트랜잭션 격리레벨?

트랜잭션에서 일관성이 없는 데이터를 허용하는 수준. 구체적으로 말하자면 동시에 여러 트랜잭션이 처리 될 때, A 트랜잭션이 B트랜잭션에서 [변경&조회하는 데이터]를 읽을 수 있도록 허용할지 말지를 결정하는 수준을 의미한다.

1. READ UNCOMMITTED (커밋 무시하고 중간에 막 읽기)
2. READ COMMITTED (커밋된 데이터만 읽기)
3. REPEATABLE READ (한 트랜잭션에서 여러번 읽어도 동일함 보장)
4. SERIALIZABLE (순서대로 실행, 작업마다 전부 다 데이터 잠금)

트랜잭션은 원자적이면서 독립적인 수행을 해야한다.(ACID) 그래서 트랜잭션이 DB를 다루는 동안, 다른 트랜잭션이 관여 못하게 Locking을 해야하는데, 무작정 다 잠그게되면 DB의 성능이 크게 떨어진다. 어디까지 잠글 것인가 정하는 것이 트랜잭션의 격리수준이다.

 

🎯 (Lock) 잠근다는 것은?

사용중인 데이터를 읽거나 조작하지 못하게 막는다는 것이다.

• 한 테이블 전체를 잠글 수 있다.
• 테이블의 한 행(row)를 잠글 수 있다.
  - Shared Lock : 읽기용 잠금, 읽는 건 가능하지만 데이터를 수정하지 못하게 막는다.
  - Exclusive Lock : 상호베타적인 잠금, 읽고 쓰지 못하게 완전히 막는다.
  상호베타적이라는건, 둘 중 하나만 사용 가능하다는 말이다.
  
• 그 외, 데이터베이스마다 성능 향상을 위한 다양한 형태의 잠금이 존재할 수 있다.

 

 

🎯 자바에서 DB를 사용하는 방법은?

JDBC를 사용하는 방법만 존재한다. (* 물론 저수준의 TCP/IP 네트워크 통신을 직접 구현하는 방법도 있지만, 이는 제외하고)

// 참고로 Java7 이후에서는 직접 close 하지않아도, try(..)를 사용해 AutoClosable을 이용할 수 있다.
Connection conn = null;
PreparedStatement  pstmt = null;
ResultSet rs = null;

try {
    sql = "SELECT * FROM MEMBER"

    // 1. 드라이버 연결 DB 커넥션 객체를 얻음
    connection = DriverManager.getConnection(DBURL, DBUSER, DBPASSWORD);

    // 2. 쿼리 수행을 위한 Statement 객체 생성
    stmt = conn.createStatement();

    // 3. executeQuery: 쿼리 실행 후
    // ResultSet: DB 레코드 ResultSet에 객체에 담김
    rs = stmt.executeQuery(sql);
    } catch (Exception e) {
    } finally {
        conn.close();
        pstmt.close();
        rs.close();
    }
}

JDBC가 작동되는 과정. DAO는 사용자가 직접 만든 코드 (DataAccessObject)

 

 

🎯 자바에서 어떻게 트랜잭션이 걸리는가?

데이터베이스는 트랜잭션 단위로 데이터를 관리한다. Commit 되지 않았는데 오류가 발생했다면, 트랜잭션 작업을 통으로 롤백시킨다.

자바에서는 JDBC에 연결된 Connection을 이용하여 트랜잭션을 관리할 수 있다.

// 커넥션 풀에서 DB커넥션을 받아왔다고 가정
Connection connection = dataSource.getConnection();

try (connection) {
    connection.setAutoCommit(false); // 자동 커밋 off
    // ...DB 작업...
    connection.commit(); // 성공시 트랜잭션 커밋
} catch (SQLException e) {
    connection.rollback(); // 오류 발생시 트랜잭션 롤백
}

 

기본적으로 트랜잭션 자동 커밋 모드인데, 이 경우 모든 SQL문은 개별 트랜잭션으로 실행되고, 커밋된다.
참고로 대부분의 커넥션 풀은 JDBC의 AutoCommit을 끄고 직접 트랜잭션을 관리한다.

• Insert, Update, Delete 작업은 실행이 완료 되는 즉시 Commit 된다.
• Select 작업은 연결된 결과객체(ResultSet)이 닫히면 Commit 된다.
• connection.setReadOnly(true) 적용할 경우, DB 드라이버에 힌트를 제공한다. 단 트랜잭션 실행 도중에는 설정을 변경할 수 없다.

자동 커밋모드가 아닌 경우, Commit 하거나 Rollback 할 때 작업이 종료된다.

오라클 공식문서 - setAutoCommit (Java17)

참고로 Spring와 하이버네이트에서 제공해주는 @Transactional는 알아서 트랜잭션을 관리해주는 마법의 키워드가 아니다. 추상화해서 사용할 뿐이지 실제는 위의 코드처럼 JDBC 트랜잭션을 사용하여 구현한다.

 

 

🎯 여러 Select를 하나의 트랜잭션으로 묶으면 어떻게 되는가?

DB의 동시성 제어 메커니즘에 따라 다르다. 다만 대부분의 경우 READ-COMMIT 격리 수준에서 묶는 경우에는 이점은 따로 없다.
당연히 REPEATABLE-READ 의 경우, 묶는 경우와 묶지 않는 경우 데이터 결과가 다를 수 있다

반대로 너무 많이 묶어 해당 트랜잭션이 장기 실행 될 경우, 데이터베이스 성능이 안 좋아 질 수 있다.

트랜잭션이 종료 될 때 까지 테이블의 일부를 업데이트 할 수 없기때문이다. (이는 Select가 아닌 DDL, Index 변경작업도 마찬가지)

 

* 단, 서버(Java)입장에서는 Select를 시도할 때마다 DB Connection을 새롭게 생성한다면 서버 성능이 나빠지겠지만, 이는 커넥션 풀을 사용하면 해결된다.

 

 

🎯 커넥션을 미리 열어둔다는 게 정확히 무슨 의미인가?

Java 서버는 JVM 위에서 돌아가는 프로그램이고, JVM은 운영체제 위에서 돌아가는 프로그램, 정확히는 프로세스이다.

서버(프로세스)가 데이터베이스(프로세스)와 연결하기 위해서는 TCP/IP가 구현된 운영체제가 제공해주는 소켓 통신을 해야한다.

프로그램은 OS가 제공하는 소켓 라이브러리를 통해 TCP/IP 통신을 한다.

 

소켓은 1982년 BSD(Berkeley Software Distribution) 유닉스 4.1에서 처음 소개되었으며 현재 사용중인 소켓은 정확히 1986년 BSD 유닉스4.3에서 개정된 기능이다. 이후 TCP/IP 의 표준으로 채택되었다. 

소켓을 생성한 후, TCP/IP 를 이용해 연결을 한다. 그 이후 데이터를 전송/수신을 계속하다가, 더이상 필요없다면 연결을 끊는다.

 

운영체제가 제공하는 Socket 라이브러리를 이용하기 위해선, System Call 명령을 이용하여 커널 모드로 진입해야한다.

시스템콜이 뭔지 모른다면 https://limjunho.github.io/2021/05/11/SystemCall.html

어셈블리(기계어) 에서는 필요한 매개변수를 (레지스터 자체 or 레지스터에 특정 메모리 주소 기록 or 스택 메모리)에 넣은 후
인터럽트 명령(INT), 시스템접근 명령(SYSENTER), 또는 x64 이후 운영체제라면 SYSCALL 명령을 이용하여 시스템 콜을 할 수 있다.

C언어에서는 파일디스크립터를 사용하는 API를 이용하여 시스템 콜을 할 수 있고, 그 과정은 아래와 같다.
C 프로세스 -> 시스템 콜 -> 커널 -> 디스크 컨트롤러 -> 데이터 복사

 

자바에서도 크게 다르지않다. 아래의 과정으로 시스템 콜이 이루어진다.
JVM -> JNI -> 시스템 콜 -> 커널 -> 디스크 컨트롤러 -> 커널 버퍼 복사 -> JVM 버퍼 복사

 

참고로 파일 입출력이나 네트워크 입출력이나 운영체제 입장에서는 동작이 크게 다르지 않다. I/O 병목되는 것도 비슷하고.

 

 

자바에서는 이러한 소켓 통신을 java.net.Socket, java.net.ServerSocket 을 이용하여 직접 할 수 있다.

baeldung.com - 자바 소켓 통신 가이드

// 서버 소켓생성 후, 소켓을 이용한 자바 IO 스트림 생성
Socket clientSocket = new Socket("127.0.0.1", 6666);
PrintWriter out = new PrintWriter(clientSocket.getOutputStream(), true); 

// (다른 프로그램) 클라이언트 소켓 생성 후, 소켓을 이용한 자바 IO 스트림 생성
Socket clientSocket = serverSocket.accept();
BufferedReader in = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));

 

이걸로 직접 통신을 해도 되지만, 다행히 java.sql 패키지에는 데이터베이스와 소켓 통신을 쉽게 할수 있게 Connection 객체를 제공한다.

자바에서 .getConnection(..) 은 커넥션 객체 구현을 해당 JDBC 드라이버가 구현하도록 만들어놨다. 

// DataSource 인터페이스의 구현체인 JdbcRowSetImpl 의 코드
private static Connection getConnection(
       String url, java.util.Properties info, Class<?> caller) throws SQLException {
       /* ... 생략 ... */

       for (DriverInfo aDriver : registeredDrivers) {
           // If the caller does not have permission to load the driver then skip it.
           if (isDriverAllowed(aDriver.driver, callerCL)) {
               try {
                   println("    trying " + aDriver.driver.getClass().getName());
                   Connection con = aDriver.driver.connect(url, info);
                   if (con != null) {
                       // Success!
                       println("getConnection returning " + aDriver.driver.getClass().getName());
                       return (con);
                   }
               } catch (SQLException ex) {
                   if (reason == null) 
                       reason = ex;
               }

           } else 
               println("    skipping: " + aDriver.driver.getClass().getName());
       }

 

즉 커넥션을 열어둔다는 건, 데이터베이스 통신을 위한 소켓을 열어둔다는 의미다.

 

 

🎯 커넥션은 다다익선인가?

1. DB 서버 접속을 위해 JDBC 드라이버를 로드한다.
2. DB 접속 정보와 DriverManager.getConnection() Method를 통해 DB Connection 객체를 얻는다.
3. Connection 객체로 부터 쿼리를 수행하기 위한 PreparedStatement 객체를 받는다.
4. executeQuery를 수행하여 그 결과로 ResultSet 객체를 받아서 데이터를 처리한다.
5. 처리가 완료되면 처리에 사용된 리소스들을 close하여 반환한다.

여기에서 가장 시간이 오래걸리는 부분은, DB서버와 최초로 소켓 통신을 연결 Connection 객체를 생성하는 부분이다.

그렇다면 무작정 커넥션 풀의 크기를 늘린다면 좋을까? 아니. 그렇지않다.

 

결국 커넥션을 사용하는건 서버에 돌아가고 있는 Thead이다.
Thread의 개수보다 커넥션 풀의 크기가 크다면 사용하지도 않는 여유 커넥션만 많이 생겨 메모리의 낭비 하고 있을 뿐이다.

MySQL8.0 공식레퍼런스에서는 600여 명의 유저를 대응하는데 15~20개의 커넥션 풀만으로도 충분하다고 언급하고 있다. MySQL은 최대 연결 수를 무제한으로 설정한 뒤 부하 테스트를 진행하면서 최적화된 값을 찾는 것을 추천한다.

사실 이런 건 서버마다 최적의 값이 다르긴하다. 궁금하다면 배달의민족  - HikariCP Dead lock에서 벗어나기 (실전편) 글을 읽어보자.

 

 

 

🎯 스프링 데이터 JPA에서, 여러 SELECT 문을 하나로 묶는 건 어떤 차이가 있을까

@Transcational
void serviceMethod(){
    memberRepository.read()
    shopRepository.read()
    orderRepository.read()
}

@Transcational 키워드는 해당 메서드의 시작, 끝에 PlatformTranscationManager를 프록시로 삽입한다.
그리고 .begin() .doCommit() 같은 메서드를 실행시켜 트랜잭션을 걸어준다.

 

JPA의 경우에는 JpaTransactionManager 가 구현체로 삽입되는데, 코드를 보면 알겠지만 .doCommit()은 트랜잭션을 커밋한다.

JpaTransactionManager.doCommit()

 

참고로 우리가 따로 트랜잭션을 걸지 않아도 기본 구현체인 SimpleJpaRepository에서 트랜잭션이 걸려있다.

전체에 readOnly로 걸어두고, 데이터를 변경하는 메서드에만 @Transcational(readOnly=false) 가 따로 붙어있다.

 

 

---

@Transcational
void serviceMethod(){
    memberRepository.read()
    shopRepository.read()
    orderRepository.read()
}

다시 본론으로 돌아와서, 아래와 같이 조회메서드에 @Transactional을 걸게되면
- 그냥 여러 Select 들을 한 트랜잭션에 넣어버린다.
- JPA가 더티체킹(수정감지)를 한다.

DB의 동시성 제어 메커니즘에 따라 다르다. 다만 대부분의 경우 READ-COMMIT 격리 수준에서 묶는 경우에는 이점은 따로 없다.당연히 REPEATABLE-READ 의 경우, 묶는 경우와 묶지 않는 경우 데이터 결과가 다를 수 있다
반대로 너무 많이 묶어 해당 트랜잭션이 장기 실행 될 경우, 데이터베이스 성능이 안 좋아 질 수 있다.
트랜잭션이 종료 될 때 까지 테이블의 일부를 업데이트 할 수 없기때문이다. (이는 Select가 아닌 DDL, Index 변경작업도 마찬가지)

* 단, 서버(Java)입장에서는 Select를 시도할 때마다 DB Connection을 새롭게 생성한다면 서버 성능이 나빠지겠지만, 이는 커넥션 풀을 사용하면 해결된다.

 

 

그럼 아래와 같이 readOnly=true로 묶어주면 의미있는 차이가 있을까?

@Transcational(readOnly=true)
void serviceMethod(){
    memberRepository.read()
    shopRepository.read()
    orderRepository.read()
}

우선 JDBC 에서는 readOnly 에 대한 최적화는 JDBC Driver에게 위임할 뿐, 아무런 동작도 하지 않는다.

참고로 readOnly라고 해서 생성,삭제,업데이트를 막아주는 기능은 JDBC에서 없다. 그냥 readOnly 힌트만 JDBC드라이버에게 준다.

 

하지만 JPA의 구현체인 하이버네이트에서는 몇가지 최적화를 한다.

# (번외) @Transcational(readOnly = true)의 동작

- 메모리에 존재하는 영속성 컨텍스트를 플러시 하지 않는다. entityManager.setFlushMode(MANUAL) 로 강제로 바꿔버린다.

- 좀 더 쉽게말하면 더티체킹을 안한다.

- 그 외 차이점은, 연관관계가 LAZY로 걸려있다면 해당 트랜잭션 내부에서는 지연로딩을 한다는거 정도가 있겠다.

 

* 참고로 더티체킹과 flush를 안한다고 했지, 트랜잭션의 readOnly가 수정/삭제를 막는 기능이 있지는 않다.
save()를 실행해도 잘 동작하고, updated의 경우에도 직접 flush 시켜주면 실제 DB에 쿼리가 찍힌다.

 

 

즉 요약하면 데이터베이스 격리 수준이 Read Commit 인 경우 아무런 차이가 없다.
굳이 따지자면 한 트랜잭션이 길어짐 = 여러 데이터에 SharedLock이 걸려서 성능이 느려질 수 있다.

Repeatable read 의 경우, 트랜잭션을 건 것과 안건 것이 데이터 잠금 범위와 반환값이 다를 수 있기에 이는 논외로 하자.