Connection Pool 크기와 타임아웃 설정

기본개념

1. Connection Pool의 역할

• Connection Pool은 애플리케이션이 데이터 베이스와 통신하기 위해 미리 연결을 생성 해 두는 저장소.
• 연결을 매번 생성/해제 하면 성능이 저하되므로 재사용 가능한 연결 풀을 통해 성능을 최적화한다.

2. 주요 파라미터

• Maximum Pool Size: 동시에 사용할 수 있는 최대 연결 수.
• Minium Idle Connections: 사용되지 않을 때 유지할 최소 연결 수.
• Connection Timeout: 연결 요청 시 대기 할 최대 시간.

Connection Pool 크기 설정

왜 중요하가?

• 연결 풀 크기가 너무 작으면 요청이 대기 상태가 되어 처리 속도가 느려짐.
• 연결 풀 크기가 너무 크면 DB서버에 과부하가 발생하여 성능이 저하된다.

단계별 설정

1. 트래픽 분석
   • 애플리케이션의 동시 사용자 수와 요청 패턴을 분석.
   • ex: 애플리케이션 초당 평균 100개의 요청이 발생하고 각 요청이 50ms동안 연결을 유지한다

     = 100 * 0.05
     = 5(최소 연결 필요) 

2. DB서버의 제한 확인
   • DB서버가 지원할 수 있는 최대 연결 수를 확인.
   • ex: MySQL SHOW VARIABLES LIKE 'max_connections' ;
3. 기본 설정
   • 최소 연결 수는 트래픽 분석 결과의 80%로 설정
   • 최대 연결 수는 DB 서버의 최대 연결 수의 80%를 넘지 않도록 설정.
4. 로드 테스트
   • JMeter, Gating 등의 도구로 예상 트래픽을 시뮬레이션 하여 성능 확인.
   • 연결 풀 부족 시 대기시간이 늘어나는지 확인.

Connection Timeout 설정

1. 왜 중요한가?
   • 타임아웃을 짧게 설정하면 불필요한 대기 없이 오류를 빠르게 감지할 수 있다.
   • 너무 길게 설정하면 장애 원인 파악이 어려워진다.
   • 너무 짧게 설정하면
     • 네트워크가 느리거나 서버가 과부하일 경우 요청이 처리되기 전 연결이 끊어질 수 있다.
     • 재시도 과정에서 네트워크 대역폭과 서버리소스가 불필요하게 소비된다.
2. 설정 단계
   1. 요청 응답시간 확인
      • 평균적 DB응답 시간은 수십ms에서 수백ms 수준.
      • ex: 쿼리가 200ms 내외로 완료된다면 타임아웃을 500ms ~ 5000ms 로 설정
   2. Connection Timeout 설정
      • HicariCP의 connection-timeout은 견결을 기다릴 최대 시간이다. (default: 3000ms)
      • 실무에서는 보통 2000~10000ms 사이로 설정한다.
   3. Validation Timeout 추가.
      • 연결 유효성을 검사하는 시간. 일반적으로 1000~5000ms 설정
   4. 실패시 재시도정책
      • 타임아웃 발생 시 재시도를 설정하거나 Circuit Breaker를 사용한다.

성능 최적화

1. 모니터링 도구를 활용한다.
   • Actuator의 /metrics 엔드포인트에서 hicaricp.connections.*지표를 확인.
   • 그라파나, 프로메테우스와 통합하여 커넥션 풀 상태 모니터링
2. 쿼리 효율성 확인.
   • 슬로우쿼리가 풀을 점유하지 않도록 주기적으로 쿼리 성능 분석.
   • mysql의 경우 slow_query_log 활성화
3. 스케일링 전략
   • 트래픽이 지속적으로 증가할 경우 DB와 애플리케이션 인스턴스 수를 증가시킨다.

JVM의 Garbage Collection(GC)

• Garbage Collection(GC)은 JVM(Java Virtual Machine)에서 동정으로 생성된 객체의 메모리를 자동으로 관리하는 메커니즘. GC는 애플리케이션의 메모리 누수를 방지하고, 더 이상 사용되지 않는 객체를 제거해 메모리를 효율적으로 사용하도록한다.

기본개념

1. GC의 역할

• JVM이 힙 메모리(Heap Memory)에 생성된 객체 중 더 이상 사용되지 않는 객체를 식별하고 제거한다.
• 이를 통해 애플리케이션의 메모리 누수를 방지하고, 수동 메모리 관리의 필요성을 제거한다.

2. GC가 관리하는 영역

• Heap Memory
  • Youg Generation (Eden, Survivor Space)
  • Old Generation (Tenured)
• Metaspace
  • 클래스 메타데이터를 저장하는 공간.

JVM Heap Memory 구조

1. Young Generation

• 새로 생성된 객체가 저장됨.
• 크기가 작고, 객체의 생존 시간이 짧은 경우가 대부분.
• 구성요소
  • Eden Space: 새로운 객체가 처음 생성되는 공간.
  • Survivor Space: Eden에서 살아남은 객체가 복사되는 공간.

2. Old Generation

• Young Generation에서 오래 살아남은 객체가 이동.
• 크기가 크거나 생존 시간이 긴 객체가 저장됨.

3. Metaspace

• 클레스 로더와 메타데이터 정보를 저장.

GC 동작 과정

1. Minor GC

• Young Generation에서 발생.
• 동작 원리
  1. Eden에서 객체가 생성.
  2. Eden이 가득차면 Minor GC가 실행
  3. Eden에서 살아남은 객체가 Survivor Space로 이동.
  4. 여러번의 Minor Gc를 통해 Survivor Space에서 생존한 객체가 Old Generation으로 이동.
• 특징
  • 실행 속도가 빠르며, Young Generation 크기에 다라 성능이 좌우됨.
  • Stop-The-World qkftod

2. Major GC(Full GC)

• Old Generation에서 발생
• 동작 원리
  1. Old Generation이 가득 차면 실행
  2. 사용되지 않는 객체를 제거하고 힙 메모리를 정리
• 특징
  • 실행 시간이 길고 Stop-The-Wold가 발생
  • Minor GC보다 성능에 더 큰 영향을 미침.

3. GC의 실행 과정(가비지 식별, 처리 과정)

• Mark: GC는 모든 객체를 순회하며 현재 참조되고 있는 객체를 식별하고 마크 함
• Sweep: 마크되지 않은, 즉 참조되지 않는 객체를 메모리에서 제거함.
• Compact(압축): 객체를 제거하고 남은 메모리 조각들을 모아 연속된 공간을 확보함. 힙메모리 단편화를 해소하는데 도움을 줌.

GC의 종류

JVM은 다양한 GC 알고리즘을 제공한다. 각각의 알고리즘은 GC성능과 애플리케이션 요구사항에 따라 다르다.

1. Serial GC

• 단일 스레드에서 작동
• 특징
  • 작은 애플리케이션(싱글 스레드)에 적합.
  • Full GC중 애플리케이션이 멈추는 "Stop-The-Wold"시간이 길다.

2. Parallel Gc(Throughput GC)

• 여러 스레드를 사용해 GC를 수행
• 특징
  • 처리량(Throughput) 지향.
  • 적절한 애플리케이션 성능과 낮은 GC비용을 제공.

3.G1 GC

• Java 9 이후의 기본 GC
• 특징
  • 힙을 Region으로 나누어 관리.
  • Yong/Old Generation을 따로 구분하지 않고 필요에 따라 Region을 재배치.
  • 짧은 응답 시간과 적은 Stop-The-World 시간을 제공.

4. ZGC

• 매우 낮은 지연시간을 목표로 설계
• 특징
  • 대규모 힙을 지원 (최대 16TB)
  • 애플리케이션 중단 시간이 10ms 이내

5. Shenandoah GC

• 낮은 지연시간을 제공.
• 특징
  • GC 작업과 애플리케이션 작업을 병렬로 수행.
  • ZGC 보다 짧은 지연시간 제공.

GC 튜닝과 모니터링

1. JVM옵선을 통한 설정

1. GC 종류 선택
   • -XX:+Use{GCNAME}
   • ex: G1GC -XX:+UseG1GC
2. Heap 크기 설정
   • Xms: 초기 힙 크기 (ex: Xms512m)
   • Xmx: 최대 힙 크기 (ex: Xmx1024m)
3. GC로그 활성화
   • -Xlog:gc

2. 주요 GC메트릭 모니터링

• GC 횟수와 시간: 애플리케이션 성능에 얼마나 영향을 주는지 확인.
• 힙 사용량: Minor GC및 Major GC 후의 메모리 상태
• 툴 사용: VisualVM, JConsole, Prometheus && Grafana

3.최적화를 위한 설정

1. 적절한 Heap크기 설정
   • 너무 작은 힙 크기는 잦은 GC유발
   • 너무 큰 힙 크기는 GC시간이 오래걸림
2. 객체 생명 주기 관리
   • 불필요한 객체 생성 줄이기
   • 전역 변수 사용 최소화
3. GC 로그를 통한 분석
   • GC로그를 주기적으로 분석 하여 병목현상을 파악.
   • 애플리케이션 패턴에 따라 GC알고리즘 선택
4. 메모리 누수 감지
   • 정적 코드 분석 툴을 사용하여 메모리 누수 방지.

JVM 메모리 구조에 대해 설명해보자

• JVM 메모리 구조는 JVM에서 프로그램이 실행될 때 데이터를 효율적으로 관리하기 위해 나누어진 영억이다. 각 영역은 특정한 역할과 특징을 가지마 애플리케이션의 안정적 실행을 보장한다.

1. Method Area

• 메소드 영역은 클래스와 관련된 메타데이터, 즉 프로그램의 구조적 정보를 저장하는 영역이다.
• JVM이 실행되는 동안 공유 메모리 영역으로 사용된다.
• 저장 내용
  • 클래스 메타데이터: 클래스 이름, 부모 클래스 정보, 인터페이스, 메소드, 필드 등.
  • Static 변수: 클래스 로드 시 초기화되는 정적 변수.
  • Constant Pool(상수 풀): 문자열 상수나 메소드/필드 참조와 같은 상수 정보를 저장.
  • 바이트코드: 각 메소드의 실제 실행 코드.
• 특징
  • 모든 Thread에서 공유함.
  • JVM이 시작될 때 초기화되고, 종료될 때까지 유지된다.

  ---

2. Heap Area

• 객체와 배열이 동적으로 생성되고 저장되는 메모리 영역.
• JVM에서 가장 큰 메모리 영역. Garbage Collector에 의해 관리됨.
• 저장 내용
  • 객체: new 키워드로 생성된 객체.
  • 인스턴스 변수: 객체가 가지고 있는 멤버 변수.
  • 클래스읜 런타임 데이터
• 구조
  • 힙은 크게 Young Generation 과 Old Generation 으로 나뉜다.
    1. Young Generation
       • 새로 생성된 객체가 저장되는 영역.
    2. Old Generation
       • Young Generation에서 오래 살아남은 객체가 이동됨.
       • 메모리에서 가장 크고, 주로 긴 생명주기를 가진 객체가 저장됨.
    3. Metaspace(Optional)
       • Java 8 이후 부터 클래스 메타데이터를 관리하는 메모리 공간.
• 특징
  • 모든 Thread에서 공유함.
  • 메모리가 부족하면 Garbage Collection이 실행됨

3.Stack Area

• 각 쓰레드마다 독립적으로 생성되는 메모리 영역, 메소드 호출과 관련된 데이터를 관리함.
• 저장 내용
  • Stack Frame: 메소드 호출 시마다 생성되는 단위.
    • 지역변수: 메소드 내에서 선언된 변수.
    • 매개변수: 메소드 호출 시 전달된 값.
    • 연산 중간 값: 연산 결과 저장.
• 구조
  • LIFO(Last In, First Out)로 작동
  • 메소드 호출 시 스택 프레임 생성 -> 메소드 종료 시 제거.
• 특징
  • 각 Thread 마다 독립적으로 생성.
  • 메모리 할당과 해제가 빠름.

4.PC Register

• 현재 실행 중인 명령어의 조소를 저장하는 메모리 영역
• JVM의 모든 명령은 순차적으로 실행되기 때문에 이 정보가 필요함
• 저장 내용
  • 명령어 주소 : 현재 실행중인 JVM 명령어의 메모리 위치
• 특징
  • 각 Thread 마다 독립적으로 생성
  • Java code 와 Native code 모두에 적용됨.

5. Native Method Stack

• Java 코드가 아닌, JVM 이 실행하는 네이티브 코드(C, C++)와 관련된 메모리를 관리.
• JNI(Java Native Interface)를 통해 호출되는 네이티브 메소드에서 사용.
• 저장 내용
  • 네이티브 메소드의 호출 정보와 실행에 필요한 데이터.
• 특징
  • 각 쓰레드마다 독립적으로 생성

정리

1. Method Area: 클래스 메타데이터, static 변수 저장
2. Heap Area: 객체와 인스턴스 변수 저장
3. Stack Area: 메소드 호출과 관련된 데이터 저장
4. PC Register: 현재 실행중인 명령어의 주소 저장.
5. Native Mtehod Stack: 네이티브 코드 실행과 관련된 메모리.

[Kotlin] data class와 주의사항

데이타 클래스(data class)란

• Kotlin에서 데이터를 저장하는 목적으로 사용되는 특별한 종류의 클래스. 데이터 클래스는 일반 클래스와 달리 몇가지 유용한 기능을 자동으로 제공함.

데이타 클래스의 특징

1. 간단한 선언: data 키워드를 사용하여 쉽게 선언

   data class Person(val name: String, val age: Int) 

2. 자동 생성 메소드: 컴파일러가 아래의 메소드를 자동으로 생성

   • toString()
   • equals()
   • hashcode()
   • componentN() 함수들

3. 불변성: 주 생성자의 파라미터를 val로 선언하여 불변 객체를 만들 수 있음

   • var로 선언하는 경우 해시 기반 컬랙션에서 예상치 못한 동작이 발생할 수 있다.

4. Destructuring (구조분해): 데이터 클래스의 속성을 쉽게 분해할 수 있다.

   val persion = Person("Alice", 30)
   val (name, age) = person 
   

data class 사용 예시

data class User(val name: String, val id: Int) 

fun main(){ 
  val user1 = User("John", 1) 
  val user2 = User("John", 1) 

  println(user1) // User(name=John, id=1)
  println(user1 == user2) //true

  val user3 = user1.copy(name = "Jane")
  println(user3) // User(name=Jane, id=1) 

user1 == user2 에서 자동 생성된 equals method 가 사용 되는데, 이때 객체 비교를 메모리 주소로 하는것이 아니라 값을 기준으로한다.

data class의 제한 사항

• Primary Constructor(주 새성자)는 최소 하나의 파라미터를 가져야한다.
• 모든 Primary Constructor는 val 또는 var로 표시되어야한다.
• data class는 abstract, sealed, inner class가 될 수 없다.

data class가 자동 생성하는 메소드

toString()

• data class는 모든 프로퍼티를 포함하는 가독성 좋은 문자열 표현을 제공한다.
• Primary Constructor에 정의된 프로퍼티를 표시해준다.
• 필요하다면 override해서 사용할 수 있다.

data class User(val name:String, val age: 25) 

val user1 = User("Alice", 25)
println(user1.toString()) 
// output: User(name=Alice, age=25) 

hashCode()

• Primary Constructor에 정의된 모든 프로퍼티를 사용하여 해시코드를 계산한다.
• 필요한 경우 override해서 커스터 마이징 할 수 있다. 하지만 이 경우 equals() 메소드와의 일관성 유지가 필요하다.

  val user1 = User("John", 1) 
  val user2 = User("John", 1)
  val user3 = User("Alice", 2) 

  println(user1.hashCode()) // ex: 421124123
  println(user2.hashCode()) // ex: 421124123 user1과 같은 값 
  println(user3.hashCode()) // ex: -127486178 user1과 다른  값 

  val userSet = hashSetOf(user1, user2, user3)
  println(userSet.size) // 2 user1과 user2는 동일한 것으로 간주됨

equals()

• 구조적 동등성을 판단한다 : 객체의 내용을 비교하여 동등성을 판단한다. 모든 프로퍼티의 값이 같으면 동등하다고 간주한다.
• Primary Constructor에 정의된 모든 프로퍼티를 비교에 사용한다.
• type safe : 비교하는 객체의 타입을 먼저 확인한다.
• null safe : null에 대한 안전한 비교를 수행한다.
• hashCode()와 일관성: equals()가 true르 반환하는 두 객체는 반드시 같은 hashCode()를 가져야한다.

  val person1 = Person("Alice", 30)
  val person2 = Person("Alice", 30)
  val person3 = Person("Bob", 25)

  println(person1 == person2) // true
  println(person1 == person3) // false
  println(person1.equals(person2)) // true
  println(person1.equals(person3)) // false

copy()

• 불변성 유지: 원본 객체를 변경하지 않고 새로운 객체를 생성.
• 선택적 파라미터: 변경하고자 하는 속성만 지정할 수 있음
• type safe: 컴파일시 타입체크가 이루어짐
• 모든 프로퍼티 복사 : 명시적으로 변경하지 않은 프로퍼티는 원본 객체의 값을 그대로 유지

  data class Person(val name: String, val age: Int, val city: String)

  val alice = Person("Alice", 30, "New York")

  // 나이만 변경
  val olderAlice = alice.copy(age = 31)
  println(olderAlice) // Person(name=Alice, age=31, city=New York)

  // 도시만 변경
  val aliceInLondon = alice.copy(city = "London")
  println(aliceInLondon) // Person(name=Alice, age=30, city=London)

  // 여러 속성 변경
  val bobInParis = alice.copy(name = "Bob", age = 25, city = "Paris")
  println(bobInParis) // Person(name=Bob, age=25, city=Paris)

copy의 주의사항

• copy():는 shallow copy를 수행한다. 중첩된 객체나 컬랙션은 참조만 복사된다.

• 복사를 너무 많이하면 성능에 악영향이 있을 수 있다.

• 변경되지 않은 값은 그대로 사용한다.

  • 파라미터로 전달된 값만을 변경하고, 변경되지 않은 필드는 원본 객체 값을 그대로 사용한다.
  • 이 방식으로 불필요한 객체 생성 작없을 회피한다.

    data class User(val name: String, val age: Int)
  
    val user1 = User("Alice", 25)
    val user2 = user1.copy(age = 30)
  
    println(user1.name === user2.name) // true, name 필드는 그대로 재사용

  
    data class LargeData(val id: Int, val name: String, val description: String)
  
    val large1 = LargeData(1, "Test", "This is a large data object.")
    val large2 = large1.copy(description = "Updated description.")
  
    println(large1.id === large2.id)        // true, id 필드는 그대로 재사용
    println(large1.name === large2.name)    // true, name 필드도 그대로 재사용
    println(large1.description === large2.description) // false, 변경된 description만 새로 생성

  `* == 값 동등성 비교 / === 참조 동등성 비교

@Transactional 메소드 내에서 @Transactional(propagation = Propagation.REQUIRED_NEW) 메소드를 실행하게되면 어떤 일이 발생할까

트랜잭셔널 메소드에서 새로운 트랜잭션을 시작하면 어떤일이 발생하는지 알아보자.

1. 애플리케이션 시작 시 작업

1-1. 트랜잭션 관리자 등록

• 애플리케이션 시작 시 트랜잭션 관리자가 등록된다.
• 트랜잭션 전파 정책(Propagation)을 처리할 수 있도록 AOP 프록시가 생성된다.

1-2. AOP 프록시 생성

• @Transactional이 적용된 메소드에 대해 프록시가 생성된다.
• 각각의 메소드가 호출될 때 전파 정책을 해석하도록 설정된다.

2. 부모 매소드 실행(@Transactional, REQUIRED 전파 정책)

2-1. 트랜잭션 시작

• 부모 메소드가 호출되면 프록시가 트랜잭션 관리자를 통해 트랜잭션을 시작
• 트랜잭션 전파 정책 Propagation.REQUEIRED의 기본 동작에 따라 기존 트랜잭션이 없으면 새 트랜잭션을 시작.
• 데이터베이스 연결이 확보되고, auto-commit이 비활성화됨

2-2. 비지니스 로직 실행 중 자식 메소드 호출

• 부모 메소드 내에서 Propagation.REQUIRED_NEW가 적용된 자식 메소드가 호출됨.

3.자식 메소드 실행(@Transactional, Propagation.REQUIRED_NEW)

3-1. 부모 트랜잭션 일시 중단

• 자식 메소드가 호출되면 부모 트랜잭션이 일시중단 상태로 변경됨.
• 일시 중단된 트랜잭션은 컨텍스트에 보관되며, 자식 메소드가 끝날때까지 대기.

3-2. 새로운 트랜잭션 시작

• 자식 메소드는 항상 별도의 트랜잭션에서 실행
  • 트랜잭션 관리자가 새로운 데이터베이스 연결을 확보하거나 기존 연결을 재사용 하여 별도 트랜잭션을 시작.
  • 새로운 트랜잭션은 부모 트랜잭션과 독립적으로 커밋 또는 롤백될 수 있다.

3-3. 비지니스 로직 실행

• 자식 메소드의 비지니스 로직이 새로운 트랜잭션 내에서 실행됨.
• 데이터베이스 작업은 자식 트랜잭션의 컨텍스트에서만 적용됨.

3-4. 자식메소드 종료

• 자식 메소드 실행이 끝나면 아래와 같은 동작 발생
  • 정상종료시, 커밋
  • 예외 발생시 자식 트랜잭션롤백

4. 부모 메소드 재개

4-1. 부모 트랜잭션 복구

• 자식 메소드 실행이 끝난 후, 무보 트랜잭션이 일시중단 상태에서 복구됨.
• 부모 트랜잭션은 자식 트랜잭션과는 독립적으로 계속 진행됨.

4-2. 부모 메소드 비지니스 로직 실행(남은 작업)

• 부모 메소드의 나머지 비지니스 로직 실행.
• 데이터베이스 작업은 부모 트랜잭션 컨텍스트에 반영.

4-3 부모 메소드 종료

• 부모 메소드 종료되면 아래와 같은 동작 발생
  • 정상 종료시 커밋
  • 예외 발생시 부모 트랜잭션 롤백

5. 특이 케이스

5-1. 자식 트랜잭션 커밋 후 부모 트랜잭션 롤백

• 부모 트랜잭션이 나중에 롤백 되더라도 자신 트랜잭션은 독립적으로 커밋 되었기 때문에 영향을 받지 않는다.

5-2. 자식 트랜잭션 롤백 후 부모 트랜잭션 정상 종료

• 자식 트랜잭션이 실패하면 부모 트랜잭션은 이를 감지할 수 없다.
  • 단, 예외를 명시적으로 처리한다면 감지시킬 수 있다.
  • 부모 트랜잭션은 독립적으로 커밋 또는 롤백된다.

정리:

1. 부모 메소드(@Transactional, Propagation.REQUIRED)가 호출되며 트랜잭션이 시작됨.
2. 자식 메소드(@Transactional, Propagation.REQUIRED_NEW)가 호출되면 부모 트랜잭션 일시중단.
3. 자식 메소드는 새로운 트랜잭션에서 실행되며 독립적으로 커밋 또는 롤백됨
4. 자식 메소드 실행 후, 부모 트랜잭션이 북구되어 남은 로직 실행
5. 자식과 부모 트랜잭션은 서로 독립정이며, 서로의 성공 여부에 영향을 주지 않음.

이런 구조로 트랜잭션간의 독립성이 보장되며, 필요 시점에 새로운 트랜잭션을 생성해 데이터 무결성을 관리하는데 도움이 된다.

@Transactional 어노테이션이 있는메소드, 스프링 시작부터 메소드 시작까지의 작업

@Transactional 어노테이션이 있는 메소드가 실행될때 어떤 일이 일아날까.
스프링 시작부터 메소드가 실행되고 종료될때까지 어떤일 일어나는지 알아보자.

1.어플리케이션 시작시 작업

1-1.트랜잭션 관리자 등록

• Spring Boot는 자동 설정(Auto Configuration)을 통해 적절한 트랜잭션 관리자를 등록한다.
  • 에를들어, JPA를 사용하는 경우 JpaTransactionManager를 기본으로 등록한다.
• 이 관리자는 트랜잭션의 시작, 커밋, 롤백 등을 담당함.

1-2.AOP 프록시 생성

• @EnableTransactionManagement 또는 자동 설정에 의애 트랜잭션 메소드가 AOP프록시로 감싸진다.
• 스프링은 빈 스캐닝 중 @Transactional이 붙은 메소드를 확인하고, 해당 메소드가 실행될 때 트랜잭션 관리가 적용되도록 프록시 객체를 생성한다.
  • 기본적으로 CGLIB 또는 JDK 동적 프록시를 사용한다.

2.메소드 실행 시 작업

2-1.프록시를 통한 메소드 호출

• 트랜잭션 메소드를 호출하면 실제 메소드를 실행하기 전에 프록시 객체가 인터셉트한다.
• 프록시는 트랜잭션 설정과 관리작업을 수행한 후 실제 메소드를 호출한다.

2-2.트랜잭션 동작 정의 확인

• 프록시는 메소드에 선언된 @Transactional 속성을 확인한다.
  • 트랜잭션 전파(Porpagation)
  • 격리수준(Isolation Level)
  • 읽기 전용(Read-only)
  • Timeout
  • 롤백 정책(Rollback Rules)

2-3.트랜잭션 시작

• 트랜잭션 관리자는 트랜잭션을 시작한다.
  • 트랜잭션 전파 전책에 따라 새 트랜잭션을 생성하거나 기존 트랜잭션에 참여한다.
• 데이터베이스 커넥션을 확보하고(필요시), auto-commit이 비 활성화 된다.

3.실제 메소드 실행

3-1.비지니스 로직 실행

• 트랜잭션 컨텍스트 내에서 실제 메소드가 실행됨.
• 데이터베이스의 CRUD 작업이 발생하면, 변경 사항은 트랜잭션 컨텍스트 내에 보류됨

3-2.예외 처리

• 메소드 실행 중 예외가 발생하면, 프록시는 롤백 정책을 참조하여 트랜잭션 롤백 여부를 결정.
  • 기본적으로 RuntimeException 과 Error 가 발생하면 롤백됨.
  • checked exception은 명시적으로 롤백 설정이 없으면 커밋됨.

4.메소드 실행 완료 후 작업

4-1. 트랜잭션 커밋 또는 롤백

• 메소드 실행이 성공적으로 끝나면 트랜잭션 관리자는 트랜잭션을 커밋한다.
  • 데이터베이스 변경 사항이 확정되고, 커넥션이 반환된다.
• 예외가 발생한 경우 롤백 작업이 수행된다.
  • 변경된 데이터는 폐기되며, 트랜잭션이 중단됨.

4-2.리소스 정리

• 트랜잭션이 종료되면 사용된 데이터베이스 커넥션 및 기타 리소스가 pool로 반환된다.
• 트랜잭션 컨텍스트와 관련된 쓰레드 로컬 데이터가 정리된다.

5.애플리케이션 종료 시 작업

• 트랜잭션 관리자는 애플리케이션 종료 시 등록된 리소스를 정리하며, 사용중인 데이터베이스 연결이나 트랜잭션 관련 매니저를 닫는다.

정리

1. 애플리케이션 시작 : 트랜잭션 관리자 설정, AOP프록시 생성
2. 메소드 호출시 :
   • 프록시가 트랜잭션을 시작, 트랜잭션 속성 확인
   • 메소드를 실행하며 예외 여부에 따라 커밋 또를 롤백을 결정
3. 메소드 실행 후 : 트랜잭션이 종료되고 리소스 반환
4. 애플리케이션 종료시 : 트랜잭션 관련 리소스 정리

스프링 부트 어플리케이션이 실행되면 어떤 일들이 일어나는가.

Spring Boot Application이 시직되면 내부에서 일어나는 일에 대해 정리한다.

1.JVM 및 Main 메서드 시작

• JVM 이 애플리케이션을 실행하며 main메서드를 호출
• Spring Boot 애플리케이션은 @SpringBootApplication 어노테이션이 붙은 클래스의 main메서드를 시작점으로 잡는다.

2.SpringApplication 초기화

• SpringApplication.run() 메서드가 호출되며 스프링 애플리케이션 컨텍스트가 초기화됨
• 주요 작업
  • 애플리케이션 타입 결정(Servlet, Reactive, None)
  • 배너 출력 여부 설정
  • 기본 프로퍼티 및 환경 로딩

3.Environment 생성 및 설정

• Environment 객체가 생성되어 시스템 속성, 환경 변수, 프로파일 등이로그됨
• 외부설정(ex: application.properties, application.yml)이 읽혀지고 환경 변수와 병합됨.

4.Application Context 생성

• Spring Boot 는 실행 모드에 따라 적절한 컨텍스트를 선택함.
  • AnnotationConfigServletWebserverApplictionContext (웹 어플리케이션)
  • AnnotationConfigReactiveWebServerApplicationContext (리액티브 어플리케이션)
  • AnnotationConfigApplictionContext (비 웹 어플리케이션)
• 이 컨택스트는 어플리케이션의 모든 빈(bean) 및 설정을 관리함

5.CommandLineRunner 및 ApplicationRunner등록

• ApplicationContext 초기화 중에 CommandLineRunner와 ApplicationRunner 인터페이스를 구현한 빈들이 등록됨
• 이 빈들은 애플리캐이션 초기화가 완료된 후 추가 작업을 실행할 수 있음.

6.자동설정(Auto Configuration)

• Spring Boot는 @EnableAutoConfiguration을 통해 여러 자동 설정 클래스(AutoConfiguration)을 활성화함.
• 자동 설정은 클래스 패스 및 환경 변수를 기반으로 애플리케이션에 필요한 빈을 자동으로 구성함.
  • Ex) DB Connection 설정, Web server 설정, Spring Security 설정 등

7.빈(Bean) 등록 및 DI(의존성 주입)

• 스프링 애플리캐이션 컨텍스트 내에서 모등 @Component, @Service. @Repository, @Controller 등의 빈을 스캔하여 등록
• 등록된 빈들 간의 의존성을 주입(생성자, 세터, 필드 기반)
• 프로파일 조건에 따라 특정 빈만 활성화될 수도 있음.

8.내장 웹서버 시작(Optional)

• 웹 어플리케이션인 경우, Spring Boot는 내장된 톰캣, 제티, 언더토우 등을 통해 HTTP서버를 시작
  • HTTP 포트, SSL설정 등이 적용됨.
• 서블릿 컨테이너가 초기화 되고 DispatcherSErvlet이 설정됨.

9.Spring MVC 또는 WebFlux 설정(웹 애플리케이션인경우)

• DispatcherServlet을 통해 요청을 처리하는 기본 매핑을 설정
• HandlerMapping,HandlerAdapter,ViewReolver등을 초기화 하여 웹 요청에 필요한 구성요소를 준비

10.이밴트 발행 및 리스너 실행

• Spring Boot는 애플리케이션 실행 과정에서 여러 이벤트를 발행함.
  • ApplicationStartingEvent
  • ApplicationEnvironmentPreparedEvent
  • ApplicationPreparedEvent
  • ApplicationStartedEvent
  • ApplicationReadyEvent
• 위 이벤트를 통해 특정 시점에 사용자 정의 작업을 실행할 수 있음.

11.애플리케이션 준비 완료

• 애플리케이션 컨택스트 초기화가 완료되고, 모든 빈이 생성되고 초기화됨
• CommandLineRunner 및 ApplicationRunner구현체가 실행됨.
• ApplicationReadyEvent 가 발행되며 애플리케이션이 요청을 처리할 준비가 완료됨

12.애플리케이션 실행 상태 유지

• Spring Boot는 실행 상태를 유지하며 HTTP요청을 대기하거나 비웹 애플리케이션에서는 작업을 지속함.
• 내부적으로 애플리케이션 컨택스트는 필요에 따라 라이프 사이클을 관리함.

13.애플리케이션 종료

• 애플리캐이션 종료시 Spring Boot는 ApplicationContext를 닫으며 빈의 destroy() 메서드 호출 및 리소스 정리를 수행
• ApplicationFailedEvent 가 발행될 경우 애플리케이션 시패를 기록

Spring Boot Application으 LifeCycle에 대해 간략하게 정리 해 보았다.
Spring 기반의 서비스를 운영 / 개발 하는 회사라면 자주 나오는 질문이니 숙지하고 있으면 좋다.
세부 내용까지는 힘들더라도 1~12번 넘버링 되어있는 순서만이라도 기억하면 좋다.

Jetbrain Blog의 번역 글입니다. 원본은 아래 주소에 접속하여 확인 해 주세요 
https://blog.jetbrains.com/kotlin/2023/11/kotlin-multiplatform-development-roadmap-for-2024/ 

Kotlin Multiplatform Development Roadmap for 2024

최근 완성된 코틀린 멀티플랫폼의 안정성 덕분에, 세계의 많은 개발팀들은 이제 장애물 없이 코플린 멀티 플랫폼을 프로덕션에 자신있게 적용할 수 있게 되었다.  하지만 이는 단지 KMP(Kotlin Multiplatform)과 에코시스템을 시작하는것일 뿐이다. 최고의 크로스 플랫폼 개발을 경험을 갖추게 하기 위해서, 2024년에 JetBrains는 핵심 코틀린 펄티플랫폼기술, 컴포즈 멀티 플랫폼, KMP도구와 라이브러리 같은 미래의 발전을 주도할것이다. 이 분야에서 무엇을 배워야하고, 어떤 순서로 배뭐야할지 알아보자. 

우리는 컴포즈 멀티플랫폼을 만들기 위해 헌신했다. 컴포즈 멀티플랫폼은 우리가 지원하는 모든 플랫폼에서 어플리케이션이 동일하게 동작하고 동일하게 보이도록지원해주는 아름답고 효율적인 프레임워크이다. 지금 당장 우리가 집중하고 있는것은 iOS를 위한 컴포즈 Beta 버전이다. 하지만 우리는 다른것들도 진행하고있다. 아래는 우리의계획이다. 

• 모든 Jetpack Compose 코어API와 멀티플랫폼 컴포넌트 제작
• iOS에서의 랜더링 퍼포먼스 향상
• iOS 앱용 컴포즈에서의 스크롤링, 문자 수정(text edting) 동작을 iOS네이티브 앱과 동일하게 만들기
• 모든 타입의 리소스를 공유할 수 있는 공통API 구현
• iOS와 데스크탑의 접근성 API 통합
• 멀티플렛폼 네비게이션을 위한 소루션 제공

앞서 말한 많은 개선사항은 컴포즈 for 데스크탑에도 역시 도움이 된다. 더욱이, 우리는 제품 사용자들의 피드백을 통해서 안정성 향상과 새로운 기능 향상 작업도 진행하고있다.

우리는 또한 컴포즈 for Web, 특히 Wasm에 대한 작업도 지속하고있다. 우리의 가장 가까운 목표는 컴포트 for Web을 알파 버전으로 만드는 것이다. 알파버전엔 다음이 포함된다. 

• 이미 존재하는 앱들의 포팅기능, 공통코드의 재사용 기능.
• 다양한 화면 사이즈(size, orientation, densitie) 지원,
• 마우스, 터치스크린, 키보드, 스크린 키보드 지원
• 퍼포먼스와 용량 향상.
•  

We’re committed to providing a great IDE experience for Kotlin Multiplatform. That means not only investing in the core platform and, for example, migrating Kotlin IDE plugin to K2 compiler frontend, but also providing a single tool (Fleet) for all Kotlin Multiplatform targets and codebases where you integrate it, eliminating the need to constantly switch between different IDEs.

We plan to quickly iterate over your feedback about using Fleet for Kotlin Multiplatform development  to make sure that we have everything you need for your development experience to be great. Among other things, we’re going to deliver in the following areas:

• Enhanced support for Compose Multiplatform, including live preview for common code and visual debugging tools.
• The IDE helping you with project configuration.
• Unified and enhanced debugging experience for all parts of your Multiplatform project.

우리는 Kotlin Multiplatform을 위한 훌륭한 IDE 환경을 제공하기 위해 최선을 다하고 있습니다. 이는 Kotlin IDE plugin을 K2 compiler frontend 마이그레이팅 하는것 같은 코어 플랫폼 뿐만 아니라 개발자들이 통합하게 될 모든 Kotlin Multiplatform 타겟과 코드베이스를 위한 싱글툴(Fleet)을 제공하여 끊임없는 IDE변경을 제거한다는 의미입니다. 

우리는 Fleet for Kotlin Multiplatform development의 사용성에 대한 피드백을 빠르고 반복적으로 처리하여 개발자들에게 훌륭한 개발 경험을 제공하려고 합니다. 이런 행위들 사이에서 우리는 아래와 같은것들을 제공할 것 입니다.

• 공통 코드를 위한 라이브 프리뷰와 시각적 디버깅 툴을 포함한 컴포즈 멀티플랫폼 서포트 증가
• IDE의 프로젝트 configuration 도움
• 멀티플랫폼 프로젝트의 모든 부분에서 통합되고 향상된 디버깅 경험 제공.

Kotlin Multiplatform의 가장 유명한 시나리오 중 하나는 iOS 타겟괴 코드를 쉐어 하는 것 이다. 코드 베이스에서 코틀린 멀티플랫폼 프레임워크를 사용하는 iOS개발자의 경험에 중점을 두고 있다. 

이 분야에서의 주요 계획은 Kotlin-to-Swift의 직접 번역(direct export)이다.  이를 통해 Object-C 보틀렉을 제거와 광범위한 Swift언어 지원, 자연스러운 API exporting이 가능해진다. 더욱이, 우리는 코틀린 라이브러리 개발자들을 위한 도구(tool)들을 만들었다. 이 도구들은 Swift로 export될 때  Kotlin API의 호환성과 사용자친화성을 개선하도록 디자인 되다. 우리는 툴링(tooling)에도 세심한 주의를 기울이고 있다. IDE와 빌드 시스템은 개발자 경험의 중요한 부분입니다. 우리의 목표는 Swift Export를 부드럽게 만드는 것 이다. 

우리의 또 다른 우선순위는 Kotlin/Native 컴파일의 속도 증가, CocoaPods의 강화, SwiftPM을 사용한프레임워크 exporting 서포트 소개 를 포함하고 있다. 

우리는 또한 코틀린 멀티 플랫폼 어플리케이션의 빌드 셋업 향상을 위한 방법도 지속적으로 탐험할 계획이다. Kotlin1.9.20애서 우리는 Gradle Multiplatform DSL의 거대한 향상을 릴리즈하여 읽고, 쓰기 쉽게 만들었다. 우리는 계속적으로 향상시킬 예정이다. 더욱이 우리는 Amper라는 실험을 하고있다. Amper는 사용성, 온보딩, IDE서포트에 초점을 맞춘 새로운 프로젝트 configuration tool이다. 

코틀린 멀티플랫폼의 에코시스템이 빠르게 성장함에 따라 라이브러리들의 이전 버전과의 호환성이 중요해졌다. 호환성을 위해서 JetBrains 팀과 라이브러리 제작자들은 함께 일해야만한다. 아래는 우리의 계획이다. 

• klib format 발전으로 라이브러리 크리에이터들이 그들의 JVM라이브러리 빌드 지식을 향상시킬 수 있다.
• 코틀린 멀티플랫폼의 code-inlining 행동이 JVM에서의 행동과 동일하도록 구현한다. 
• 멀티플랫폼 라이브러리의 퍼블릭 API들이 호환되지 않는 방향으로 변경되지 않게 하는 도구를 제공한다. 

우리는 또한 KMP라이브러리의 퍼플리싱 프로세스 향상할 것이다. 특히, 아래와 같은 계획이다. 

• Mac 없이 KMP라이브러리를 빌드하고 배포할 수 있게 만든다.
• KMP라이브러리를 생성하고, 배포하기 위한 템플릿과 광범위한 가이드라인을 제공한다. 

• Kotlin Multiplatform Is Stable and Production-Ready
• Compose Multiplatform 1.5.10 – The Perfect Time To Get Started
• Amper – Improving the Build Tooling User Experience
• Welcome Fleet with Kotlin Multiplatform Tooling
• Kotlin roadmap

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다

문서화, 모든 개발자의 숙제이다. 필요한 이유는 알고있지만 하기 싫고 귀찮은 작업 중하나이다. 소프트웨어 개발 산출물 중 하나이기도 하고 다른 개발자 혹은 미래의 자신을 위해서 필요한 작업이기도하다. 

필요성을 인지하고 있기때문에 모두 작성을 하려고하긴 하지만 어떻게 작성해야하는지를 잘 모른다. 책의 서두에도 나오는 '지식의 저주' 때문에 '이런것은 이미 알고있겠지' 혹은 '이렇게 자세히 쓰면 아무도 안읽을거야' 같은 생각을 하게된다. 

사실 이책의 내용의 대부분은 이미 알고 있는 이야기였다. 그럼에도 이 책은 나에게 도움이 되었다. 왜냐면 "왜?"에 대한 답을 주기 때문이다. 문서화를 하다가 동료팀원에게 보완점을 이야기 했을때 "왜 그렇게 해야하죠?" 라는 말에 대답을 못하는 경우가 있다. 왜냐면 내 기준에선 당연한 이야기 이기 때문이다. 물론 '당연히 그렇게 해야죠'라는 말을 하면 싸움밖에 안날것이기때문에 당황하는 경우가 있었는데 이 책은 왜 그렇게 해야하는지에대해 알려주기 때문에 속이 시원해지는 경험을 했다.

이미 알고는 있지만 왜인지 몰랐던 문서에 대한 이야기들은 큰 도움이 되었다. 물론 내가 몰랐던 이야기들도 있었고, 문서화 방향에 대한 가이드이기 때문에 큰 도움이 되었다. 

내용이 어렵지도 않고 술술 잘 읽히니 시간이 날때 카페에서 커피 한잔과 함께 가볍게 읽어보면 좋은 책이다. 

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다

AWS가 처음 나왔을때를 생각 해 본다. 온프레미스 서버의 연장선이다. 아니다, 이건 혁신이다. 이렇게 두가지로 이야기가 나뉘었던거같다. 훅자의 의견을 가진 개발자들은 앞다투어 AWS를 공부했고, 활용했다. AWS는 혁신이었다. 그들이 제공해주는 서비스는 개발에만 집중 할 수 있게 만들어 주었고, 버튼 몇번으로 인스턴스가 늘어나고, 프로토타이핑한 코드를 바로 운영서버에 적용시켜보고, 등등 여러가지 일을 할 수 있게 해줬다. 아이러니하게도 이런 AWS의 유용한 기능 덕분에 개발자는 AWS를 공부 할 필요가 없어지게 되었다. 너무 유용하고 다양한 기능을 제공해 주었고, 그 다양하고 유용한 기능들을 잘 활용하기 위해서는 전문가가 필요해졌기 때문이다. 개발자는 더이상 AWS를 공부 할 필요가 없어졌고, AWS는 DEVOPS 엔지니어, 인프라스트럭처 엔지니어같은 전문가들의 영역이 되었다.

 그런데 정말 개발자는 더이상 AWS를 공부 할 필요가 없어졌을까? 아니다. 개발자는 AWS가 제공해주는 서비스를 어떻게 설정하는지, 정책을 어떻게 잡아야하는지 등의 세부사항은 알 필요가 없어졌지만 그래도 어떤기능을 제공하는지, 어떤 정책을 적용할 수 있는지 는 여전히 알고 있어야한다. 결국 시스템을 설계하고 운영하는것은 개발자의 일이기 때문이다. 내가 만들서비스의 특성에 따라 AWS가 제공해주는 기능을 효율적으로 사용하려면 결국 어떤 기능을 제공 해 주는지, 그 한계는 무엇인지 정도는 명확히 알고 있어야한다. 물론 설정은 전문가가 해주겠지만 말이다. 그런 점에서 업무에 바로 쓰는 AWS 입문은 개발자가 AWS를 공부할때 매우 적절한 도서이다. AWS가 제공 해 주는 기능들에 대한 설명도 충분히 들어있고, 직접 사용 해 보면서 장/단점에 대해서도 알려준다. 일단 이 책을 읽어보게된다면 AWS를 사용하는 시스템을 설계할 때 효율적이고, 수월하게 설계를 할 수 있을것이다.

국내에는 많은 AWS관련 서적이 나와있다. 대부분 내용은 대동소이하며 꼭 필요하고 중요한 내용으로 가득 차있다. 솔직한 말로 서점에서 AWS로 검색한 후 아무 책이나 보더라도 AWS를 공부하는 내용에서는 큰 차이가 없을것이다. 그럼에도 불구하고 '업무에 바로 쓰는 AWS입문'을 추천하는 이유가 있다. AWS는 매우 빠른 배포주기를 가지고 많은 업데이트가 일어나는 서비스이다. 때문에 이왕 공부하기 위해선 가급적 최근에 출판된 책을 이용하는것이 유리하다. 또한, 대부분 AWS책은 실습을 도와주기 위한 service UI 캡처 화면이 제공되는데 이 UI도 제법 자주 변경되기 때문에 실습을 따라하는 입장에서 최근에 출판된 도서가 훨씬 편하다. 

이왕 AWS를 공부하거나 훑어볼 생각이라면 '업무에 바로 쓰는 AWS 입문'을 추천한다.