스프링 DB 1편 - 데이터 접근 핵심 원리 섹션 4 수강

+) 22. 09. 03. 정리 추가!!

섹션 4. 스프링과 문제 해결 - 트랜잭션 수강 완료!!

애플리케이션 구조

프레젠테이션 계층

• UI와 관련된 처리를 담당한다.
• 웹 요청과 응답을 담당한다.
• 사용자 요청을 검증한다.
• 주 사용 기술: 서블릿과 HTTP 같은 웹 기술, 스프링 MVC

서비스 계층

• 비즈니스 로직을 담당한다.
• 주 사용 기술: 가급적 특정 기술에 의존하지 않고 순수 자바 코드로 작성한다.

데이터 접근 계층

• 실제 데이터베이스에 접근하는 코드다.
• 주 사용 기술: JDBC, JPA, File, Redis, Mongo 등

순수한 서비스 계층
여기서 가장 중요한 곳은 핵심 비즈니스 로직이 들어있는 서비스 계층이다. 비즈니스 로직은 최대한 변경없이 유지되어야 한다.
이렇게 하려면 서비스 계층을 특정 기술에 종속적이지 않게 개발해야 한다. 위와 같이 계층을 나눈 이유도 서비스 계층을 최대한 순수하게 유지하기 위한 목적이 크다.
정리하자면 서비스 계층은 가급적 비즈니스 로직만 구현하고 특정 기술에 직접 의존해서는 안 된다. 이렇게 하면 향후 구현 기술이 변경될 때 변경 영향 범위를 최소화할 수 있다.

MemberServiceV1

@RequiredArgsConstructor
public class MemberServiceV1 {

    private final MemberRepositoryV1 memberRepository;

    public void accountTransfer(String fromId, String toId, int money) throws SQLException {
        Member fromMember = memberRepository.findById(fromId);
        Member toMember = memberRepository.findById(toId);

        memberRepository.update(fromId, fromMember.getMoney() - money);
        memberRepository.update(toId, toMember.getMoney() + money);
    }
    
}

MemberServiceV1은 특정 기술에 종속적이지 않고 순수한 비즈니스 로직만 존재한다. 특정 기술과 관련된 코드가 거의 없어서 코드가 깔끔하고 유지보수하기 쉽다.
하지만 여기에도 남은 문제가 있다. 바로 SQLException이라는 JDBC 기술에 의존한다는 점이다.
그리고 MemberRepositoryV1이라는 구체 클래스에 직접 의존하고 있다. 이것은 MemberRepository 인터페이스를 도입하여 MemberService의 코드 변경 없이 다른 구현 기술로 손쉽게 변경할 수 있다.

MemberServiceV2

public class MemberServiceV2 {

    private final DataSource dataSource;
    private final MemberRepositoryV2 memberRepository;

    public void accountTransfer(String fromId, String toId, int money) throws SQLException {

        Connection con = dataSource.getConnection();

        try {
            con.setAutoCommit(false); //트랜잭션 시작
            //비즈니스 로직
            bizLogic(con, fromId, toId, money);
            con.commit(); //성공 시 커밋

        } catch (Exception e) {
            con.rollback(); //실패 시 롤백
            throw new IllegalStateException(e);

        } finally {
            release(con);

        }
    }
}

트랜잭션은 비즈니스 로직이 있는 서비스 계층에서 시작하는 것이 좋다.
그러나 문제는, 트랜잭션을 사용하기 위해 javax.sql.DataSource, java.sql.Connection, java.sql.SQLException 같은 JDBC 기술에 의존해야 한다는 점이다.
결과적으로 비즈니스 로직보다 JDBC를 사용해서 트랜잭션을 처리하는 코드가 더 많다. 핵심 비즈니스 로직과 JDBC 기술이 섞여 있어서 유지보수하기 어렵다.

트랜잭션 문제

• JDBC 구현 기술이 서비스 계층에 누수되는 문제

  • 구현 기술을 변경해도 서비스 계층 코드는 최대한 유지할 수 있어야 한다. 그래서 데이터 접근 계층에 JDBC 코드를 다 몰아두는 것이다. (데이터 접근 계층은 인터페이스를 제공하는 것이 좋다.)
  • 트랜잭션을 적용하면서 결국 서비스 계층에 JDBC 구현 기술의 누수가 발생했다.

• 트랜잭션 동기화 문제

  • 같은 트랜잭션을 유지하기 위해 커넥션을 파라미터로 넘겨야 한다.
  • 똑같은 기능도 트랜잭션용 기능과 트랜잭션을 유지하지 않아도 되는 기능으로 분리해야 한다.

• 트랜잭션 적용 반복 문제

  • 트랜잭션 적용 코드를 보면 반복이 많다. (try, catch, finally...)

예외 누수 문제

• 데이터 접근 계층의 JDBC 구현 기술 예외가 서비스 계층으로 전파된다.

JDBC 반복 문제

• MemberRepository 코드는 유사한 코드의 반복이 많다. (try, catch, finally...)
• 커넥션을 열고 PreparedStatement를 사용하고, 결과를 매핑하고... 실행하고 커넥션과 리소스를 정리한다.

트랜잭션 추상화

구현 기술에 따른 트랜잭션 사용법

• JDBC: con.setAutoCommit(false)
• JPA: transaction.begin()

트랜잭션 추상화 인터페이스

public interface TxManager {
   begin();
   commit();
   rollback();
}

TxManager 인터페이스를 기반으로 각각의 기술에 맞는 구현체를 만들면 된다.

• JdbcTxManager: JDBC 트랜잭션 기능을 제공하는 구현체
• JpaTxManager: JPA 트랜잭션 기능을 제공하는 구현체

트랜잭션 추상화와 의존관계

서비스는 특정 트랜잭션에 기술에 직접 의존하는 것이 아니라, TxManager라는 추상화된 인터페이스에 의존한다. 이제 원하는 구현체를 DI를 통해 주입하면 된다.

스프링의 트랜잭션 추상화

우리는 스프링이 제공하는 트랜잭션 추상화 기술을 사용하면 된다.

스프링의 트랜잭션 추상화

스프링 트랜잭션 추상화의 핵심은 PlatformTransactionManager 인터페이스이다.

PlatformTransactionManager 인터페이스

public interface PlatformTransactionManager extends TransactionManager {

	TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException;
    
	void commit(TransactionStatus status) throws TransactionException;
	void rollback(TransactionStatus status) throws TransactionException;
}

• getTransaction() : 트랜잭션을 시작한다.
• commit() : 트랜잭션을 커밋한다.
• rollback() : 트랜잭션을 롤백한다.

트랜잭션 동기화

스프링이 제공하는 트랜잭션 매니저는 크게 2가지 역할을 한다.

• 트랜잭션 추상화
• 리소스 동기화
  트랜잭션을 유지하려면 트랜잭션의 시작부터 끝까지 같은 데이터베이스 커넥션을 유지(동기화)해야 한다.

트랜잭션 매니저와 트랜잭션 동기화 매니저

스프링은 트랜잭션 동기화 매니저를 제공한다. 이것은 ThreadLocal을 사용해서 커넥션을 동기화 해준다. 트랜잭션 매니저는 내부에서 트랜잭션 동기화 매니저를 사용한다.
커넥션이 필요하면 트랜잭션 동기화 매니저를 통해 얻으면 된다.

참고
스레드 로컬을 사용하면 각 스레드마다 별도의 저장소가 부여된다. 따라서 해당 스레드만 데이터에 접근할 수 있다.

DataSourceUtils.getConnection()
DataSourceUtils.getConnection()는 트랜잭션 동기화 매니저가 관리하는 커넥션이 있으면 해당 커넥션을 반환한다.
트랜잭션 동기화 매니저가 관리하는 커넥션이 없는 경우 새로운 커넥션을 생성해서 반환한다.

DataSourceUtils.releaseConnection()
DataSourceUtils.releaseConnection()을 사용하면 커넥션을 바로 닫지 않는다.
트랜잭션을 사용하기 위해 동기화된 커넥션은 닫지 않고 그대로 유지해준다.
트랜잭션 동기화 매니저가 관리하는 커넥션이 없는 경우 해당 커넥션을 닫는다.

트랜잭션 템플릿

트랜잭션을 사용하는 로직을 살펴보면 같은 패턴이 반복되는 것을 볼 수 있다.
트랜잭션을 시작하고, 비즈니스 로직을 실행하고, 성공하면 커밋하고, 실패하면 롤백한다.
이런 형태는 각각의 서비스에서 반복된다. 달라지는 부분은 비즈니스 로직뿐이다.
이럴 때 템플릿 콜백 패턴을 활용하면 반복 문제를 해결할 수 있다.

TransactionTemplate

public class TransactionTemplate {
   private PlatformTransactionManager transactionManager;
   public <T> T execute(TransactionCallback<T> action){..}
   void executeWithoutResult(Consumer<TransactionStatus> action){..}
}

• execute() : 응답 값이 있을 때 사용한다.
• executeWithoutResult() : 응답 값이 없을 때 사용한다.

트랜잭션 AOP 이해

지금까지 트랜잭션 추상화도 도입하고, 반복적인 트랜잭션 로직을 해결하기 위해 트랜잭션 템플릿도 도입했다. 하지만 서비스 계층에 순수한 비즈니스 로직만 남긴다는 목표는 아직 달성하지 못했다.
이럴 때 스프링 AOP를 통해 프록시를 도입하면 문제를 해결할 수 있다.

---

토픽 1개 - System Call

시스템 콜은 사용자 공간의 코드에서 커널 서비스(함수)를 요청하는 과정을 말한다.

시스템 호출(System Call)은 운영체제의 커널이 제공하는 서비스에 대해, 응용 프로그램의 요청에 따라 커널에 접근하기 위한 인터페이스이다.
보통 C나 C++과 같은 고급 언어로 작성된 프로그램들은 직접 시스템 호출을 사용할 수 없기 때문에 고급 API를 통해 시스템 호출에 접근하게 하는 방법이다.

커널 콜(kernel call), 트랩(trap)이라고도 부르며, 응용 프로그램이 커널 기능을 활용하도록 제공한다.
시스템 호출 라이브러리를 통해 그 기능을 사용할 수 있다.

우리가 개발하는 프로그램은 일반적으로 유저 모드(User Mode)에서 실행한다. 프로그램 실행 중 인터럽트(Interrupt)가 발생하거나 시스템 콜(System Call)을 호출하게 되면 커널 모드(Kernel Mode)로 전환된다.

커널 모드로 전환될 때에는 실행 중이던 프로그램의 현재 CPU 상태를 저장한다. 그리고 커널이 인터럽트나 시스템 콜을 직접 처리한다. 처리가 완료되면 중단됐던 프로그램의 CPU 상태를 다시 복원한다.

OS 커널이 제공하는 서비스를 프로그램이 이용하고 싶을 때 시스템 콜을 이용한다. 시스템 콜이 발생하면 해당 커널 코드가 커널 모드에서 실행된다.

하드웨어 혹은 시스템 관련 기능은 어떤 프로그램이라도 반드시 시스템 콜을 통해서만 사용 가능하다.
하지만 우리는 개발할 때 직접 OS 시스템 콜을 사용한 적이 없다. 그럼에도 우리는 지금까지 파일 I/O, 네트워크 I/O, 프로세스, 스레드 관련 작업을 잘 해왔다.

이게 어떻게 가능했던 것일까?

우리가 사용하는 프로그래밍 언어들이 시스템 콜을 포장(wrapping)하여 간접적으로 사용할 수 있도록 제공했기 때문이다.

Thread thread = new Thread();
thread.start();

스레드를 만드는 것은 시스템 콜을 필요로 하는 작업이다. 그럼 위 코드는 어떻게 동작할까?

start() 코드로 들어가 보면 private native void start0(); 코드를 볼 수 있다. 즉, Java Native Interface를 통해 OS의 시스템 콜을 호출하게 되는 것이다.

시스템 콜의 종류

• 프로세스 제어 (Process control)
• 파일 관리 (File management)
• 장치 관리 (Device management)
• 정보 유지 관리 (Information maintenance)
• 통신 (Communications)
• 보호 (Protection)

시스템 콜은 어떻게 구현할까?

• eax 레지스터에 시스템 콜 번호를 넣고,
• ebx 레지스터에는 시스템 콜에 해당하는 인자값을 넣고,
• 소프트웨어 인터럽트 명령을 호출하면서 0x80 값을 넘겨줌.

  mov eax, 1
  mov ebx, 0
  int 0x80 //소프트웨어 인터럽트 명령

  • CPU는 사용자 모드를 커널 모드로 바꿔줌.
  • IDT(Interrupt Descriptor Table)에서 0x80에 해당하는 주소 함수를 찾아서 실행함.
  • system_call() 함수에서 eax로부터 시스템 콜 번호를 찾아서, 해당 번호에 맞는 시스템 콜 함수로 이동.
  • 해당 시스템 콜 함수 실행 후, 다시 커널 모드에서 사용자 모드로 변경하고, 다시 해당 프로세스의 다음 코드를 진행한다.

---

시스템 호출

• 운영체제가 제공하는 서비스에 대한 프로그래밍 인터페이스(interface)
  • 하드웨어의 상세한 동작을 추상화 (프로그래밍 편의성)
  • 운영체제를 통해서만 하드웨어 자원에 접근 (보호)
• 일반적으로 C, C++ 언어로 작성되어 함수 호출 형태로 제공

Application Program Interface(API)

• 시스템 호출을 활용하여 높은 수준의 함수 집합을 제공
• 일반적인 API의 예
  • Win32 API, POSIX API(UNIX, Linux), Java API
• 응용 프로그래머들이 실제로 사용하는 프로그래밍 인터페이스
  • 프로그램의 호환성이 높다.
  • 시스템 호출의 사용이 복잡하거나 어려운 경우가 있다.

---

필요한 기능이나 시스템 환경에 따라 시스템 콜이 발생할 때 좀 더 많은 정보가 필요할 수 있다. 이러한 정보가 담긴 매개변수를 운영체제에 전달하기 위해서는 다음과 같은 방법이 있다.

1. 매개변수를 CPU 레지스터 내에 전달한다.
   이 경우, 매개변수의 개수가 CPU 내의 총 레지스터 개수보다 많을 수 있다.

2. 위와 같은 경우, 매개변수를 메모리에 저장하고 메모리의 주소가 레지스터에 전달된다.

3. 매개변수는 프로그램에 의해 스택(stack)으로 전달(push)될 수도 있다.
   2, 3번 방법의 경우 전달되는 매개변수의 개수나 길이에 제한이 없기 때문에 몇몇 운영체제에서 선호하는 방식이다.
   

---

참고 자료

1. DR-Kim, “[OS] 시스템 호출(System Calls)”, https://dar0m.tistory.com/264

2. 쉬운 코드, “인터럽트와 시스템 콜을 설명합니다!”, https://youtu.be/v30ilCpITnY

3. Young Hyun Bae, “03-3 시스템호출과 라이브러리”, https://youtu.be/bjGIf_AKtAc

4. 패스트캠퍼스, “컴퓨터공학 올인원패키지 - 시스템 프로그래밍, 시스템콜과 API”, https://youtu.be/SuovfEG9XZw

---

코테 1문제

---

내일 온라인으로 발표할 거 준비!!