Choi's Blog

20210728

oh-yes — Wed, 28 Jul 2021 23:21:10 +0900

데이터 중심 어플리케이션 설계 - 07장 트랜잭션 읽기

격리성
- 동시에 실행되는 트랜잭션은 서로 격리된다는 것을 의미
- 고전적인 데이터베이스 용어에서는 격리성 == 직렬성의 의미를 가지기도 함
- 직렬성(serializable)이란 실제로 여러 트랜잭션이 동시에 실행됐더라도 트랜잭션 커밋의 결과가 트랜잭션이 순차 실행됐을때와 동일하도록 보장
- 직렬성(serializable) 격리는 일반적으로 성능 손해를 동반할 수 밖에 없기 때문에 거의 사용하지 않음. 실제는 보다 약한 스냅샷 격리를 구현
지속성
- 트랜잭션이 성공적으로 커밋되었다면 하드웨어 결함/데이터베이스가 죽더라도 트랜잭션에 기록한 데이터는 손실되지 않아야 함을 뜻함
예를 들어 쓰기 전 로그(write-ahead log) 혹은 비슷한 수단을 통하여 쓰기 저장소가 오염될 경우 복원 처리
- 지속성을 보장하려면 커밋 전에 쓰기/복제가 완료될 때까지 기다려야 한다.
더티 리드(Dirty Read)
- 다른 트랜잭션에서 커밋되지 않은 데이터를 읽는 현상
RDB에서는 트랜잭션을 통하여 다중 객체(ROW)에 대한 어떤 읽기 연산/쓰기 연산이 있는지 식별하게 됨.
비관계형 데이터베이스에서는 트랜잭션과 같은 연산을 묶는 방법이 없는 경우가 많은데, 대신 비슷하게 보이는 연산을 묶는 오퍼레이션을 제공하기도 함(예를 들어 레디스의 MULTI) 하지만, 원자성을 보장하는 연산은 아니라서 예를 들어 1과 2의 연산이 있을 때 1이 실패하더라도 2는 그대로 실행하게 된다.

Isolation Level	Dirty Read	Non-Repeatable Read	Phantom Read
Read Uncommitted	가능	가능	가능
Read Committed	불가능	가능	가능
Repeatable Read	불가능	불가능	가능
Serializable	불가능	불가능	불가능

고립수준은 Read Uncomitted 가 가장 낮고 Serializable이 가장 높음
동시성 수준은 위와 반대

20210727

oh-yes — Tue, 27 Jul 2021 23:28:13 +0900

블로그 정리

MINIMAL SKIN 적용
불필요 글 비공개 처리 및 태그 삭제
KotlinInAction 제네릭스 관련 글 업로드
@RequestParam 관련 요약 정리

데이터 중심 어플리케이션 설계 - 07장 트랜잭션 읽기

트랜잭션은 어플리케이션 구현 혹은 프로그래밍 모델의 난이도를 낮추기 위한 데이터 저장소의 장치
현대적 의미에서의 트랜잭션은 과거와 많은 차이가 있다.
- 분산 저장소를 지원하는 데이터베이스 고가용성과 높은 성능을 위해서 트랜잭션은 확장성을 해치는 안티테제로 여기는 믿음이 생김
- 기존 데이터베이스 벤더에서는 "값진 데이터"와 "중요 데이터"를 필수적인 요건이라고 말하고 있음
ACID의 의미 해석
- 데이터베이스별로 ACID에 대한 구현은 다음
- 상위 개념은 동일하지만 악마는 세부사항에 숨겨져 있음
- 일관성(Consistency)는 어플리케이션 종속적인 개념. 예를 들어 트랜잭션을 제대로 선언하지 않은 상황이라면 데이터베이스는 일관성을 유지 할 수 없음. 결국 데이터베이스를 사용하는 어플리케이션에서 데이터에 관한 선언이 우선되어야 함.

MVC와 WebFlux에서의 @ReqeustParam

oh-yes — Tue, 27 Jul 2021 19:50:36 +0900

MVC와 WebFlux에서의 @ReqeustParam

Spring MVC

Spring MVC에서는 기본적으로 querystring, form-data, multipart 요청에 대해 @ReqeustParam으로 매핑이 가능하다.
이는 서블릿 API에서 querystring, form-data(requestBody)를 parameters map에 같이 바인딩하기 때문이다.

RequestParamMethodArgumentResolver.resolveName을 살펴보면 간단하게 로직 확인이 가능하다.

Spring Webflux

웹플럭스에서는 querystring에서 대해서만 바인딩을 지원한다.

RequestParamMethodArgumentResolver.resolveNamedValue을 살펴보면 간단하게 로직 확인이 가능하다.

MVC에서처럼 querystring, form-data, multipart 모두 값을 받으려면 @ModelAttribute를 이용해야 한다.

참고

RequestParam (Spring Framework 5.3.7 API)

Kotlin-In-Action 9장 제네릭스

oh-yes — Tue, 27 Jul 2021 19:44:38 +0900

KOTLIN-IN-ACTION

9장 제네릭스

실체화한 타입 파라미터를 사용하면 인라인 함수 호출에서 타입 인자로 쓰인 구체적인 타입을 실행시점에 알 수 있다.
선언 지점 변성을 사용하면 기저 타입은 같지만, 타입 인자가 다른 두 제네릭 타입 Type<A>와 Type<B>가 있을 때 타입 인자 A와 B의 상위/하위 타입 관계에 따라 두 제네릭 타입의 상위/하위 타입 관계가 어떻게 되는지 지정할 수 있다.
- List<Any>를 인자로 받는 함수가 있다고 했을 때, List<Int>타입의 값을 전달할 수 있는지 여부를 선언 지점 변성을 통해 지정할수 있음.
사용 지점 변성은 같은 목표(제네릭 타입 값 사이의 상위/하위 타입 관계 지정)를 제네릭 타입 값을 사용하는 위치에서 파라미터 타입에 대한 제약을 표시하는 방식으로 달성

제네릭 타입 파라미터

제네릭 타입의 인스턴스를 만들기 위해서는 타입 파라미터를 구체적인 타입 인자(Type Argument)로 치환해야 한다.
- List 타입이 있다고 했을 때, 명확하게 문자열을 담는 리스트 = List<String>
- Map 타입은 제네릭 타입변수로 Map<K, V>형태로 선언이 되어 있고, 이를 인스턴스화 할때 Map<String, Person>처럼 구체적인 타입 인자를 넘겨 인스턴스화 할수 있다.
코틀린 컴파일러의 경우, 보통 타입과 마찬가지로 타입 인자도 추론이 가능하다

val authors = listOf("John", "Sveltna")

빈 리스트의 경우, 추론할 값이 없기 때문에 직접 타입을 명시 해줘야 한다.

val authors: List<String> = emptyList();
val authors = emptyList<String>();

제네릭 함수를 호출할 때는 반드시 구체 타입으로 타입 인자를 넘겨줘야 하는데, 대표적인 예로는 컬렉션을 다루는 함수들이 그 예시이다. 아래 List<T>의 slice 확장 함수를 예로 들면, 타입 파라미터 T가 수신객체와 반환 타입으로 사용된다. 타입 추론이 가능한 구체 타입으로 사용 시, 별도로 제네릭 지정이 불필요하다.

public fun <T> List<T>.slice(indices: IntRange): List<T>

타입 파라미터 선언은 클래스, 인터페이스, 클래스/인터페이스의 메소드, 확장 함수, 최상위 함수에서 선언이 가능하다.
코틀린에서는 아래와 같이 제네릭 확장 프로퍼티 선언이 가능하다. 확장 프로퍼티에 대해서만 가능하며 일반 프로퍼티는 타입 파라미터를 가질 수 없다.

val <T> List<T>.penultimate: T
	get() = this[size - 2]

자바와 마찬가지로 제네릭 클래스를 확장/구현하기 위해서는 하위 클래스에서 기저 클래스의 구체 타입을 명시하거나 혹은 타입 파라미터로 받은 타입을 넘겨줘야 확장/구현이 가능하다.

class StringList: List<String> { ... }
class ArrayList<T>: List<T> { ... }

타입 파리미터는 사용할 수 있는 타입을 제한할 수 있다. 타입 파라미터에 대한 상한(upper-bound) 을 지정한다고 표현하며 제네릭 타입을 인스턴스화 하는 시점에는 상한 타입이거나 혹은 상한 타입의 하위 타입만 가능하게 된다. 상한을 지정하게 되면 해당 타입의 값은 상한 타입으로 취급이 가능하게 된다.

fun <T : Number> List<T>.sum(): T // Kotlin
<T extend Number> T sum(List<T> list) // Java

두 인자값 중 큰 값을 찾는 제네릭 함수를 만든다고 할때, Comparable 인터페이스를 활용하여 코드를 작성한다고 해보자.

fun <T: Comparable<T>> max(first: T, second: T): T {
	// 코틀린 컴파일러에 의해 first.compareTo(second) > 0으로 변한다.
	return if (first > second) first else second
}

println(max("kotlin", "java")) // kotlin
println(max("kotlin", 42")) // 42의 경우 첫 번째 인자의 타입 정보와 일치하지 않기 때문에 컴파일 에러

타입 파라미터에 대해 두 가지 이상의 제약을 걸수도 있다. 아래 코드에서는 CharSequence와 Appendable 인터페이스를 구현해야 하는 제약을 건 예제이다.

fun <T> ensureTraillingPeriod(seq: T) where T: CharSequence, T: Appendable {
	if (!seq.endsWith('.')) seq.append('.')
}

아무런 상한을 정하지 않을 경우 기본적으로 <T: Any?>로 선언한 것과 같다. Nullable이 아닌 타입 파라미터를 받고자 한다면 <T: Any>로 지정해야 한다.
만약 <T:Any>로 선언해둔 타입파라미터에 String?등과 같은 널 허용 타입을 지정하게 되면 String?은 Any의 하위 타입이 아니기 때문에 컴파일 에러가 발생하게 된다.

class A<T> {
	// 타입 파라미터 T에 대해 별도의 상한을 지정하지 않았기 때문에 `Nullable`
	fun process(value: T) {
		value?.hashCode()
	}
}

class B<T: Any> {
	// 타입 파라미터 T에 대해 Any로 상한을 지정하였기 때문에 NonNull
	fun process(value: T) {
		value.hashCode()
	}
}

실행 시 제네릭스의 동작: 소거된 타입 파리미터와 실체화된 타입 파라미터

JVM에서 제네릭은 타입 소거(Type Erasure)를 사용해 구현되며 실행 시점에 제네릭 클래스의 인스턴스에 타입 인자 정보가 들어있지 않다는 뜻이 된다.

List의 인스턴스를 만들더라도 런타임엔 List라는 타입정보만 남을뿐 String 원소를 저장하는지에 대한 정보를 알수 없다. 타입 정보가 지워지는 것이 단점만 있는 것은 아니고 전반적인 메모리 사용량이 줄어들기 때문에 나름 장점도 존재한다.

val list1: List<String> = listOf("a","b")
val list2: List<Int> = listOf(1,2,3)

위 예제 코드를 통해 살펴보면, list1과 list2는 실제 런타임 시점에서는 List 타입으로만 취급되며 List의 제네릭 타입이 String인지 Int인지는 체크하는 것이 불가능하다. 다시 말해, is를 통한 타입 검사등은 할 수 없다는 이야기이다.
코틀린에서는 inline 함수를 사용해 타입 정보가 지워지지 않게 할 수 있는데 이러한 것을 가리켜 실체화(reified)라고 한다.
제네릭 타입을 알수 없을 경우 스타 프로젝션을 사용하여 포현하면 된다.
타입을 알수 없는 경우에도 as 혹은 as? 캐스팅은 가능하다. 하지만, 타입 인자가 다른 타입으로 캐스팅해도 캐스팅 자체를 성공해버리기 때문에 이점은 조심해야 한다.
아래 코드를 살펴보면 코드 자체는 컴파일에 성공하지만 인자로 넘어오는 값에 따라 여러 예외 상황을 맞이 할 수 있다. Set 인스턴스를 넘기게 될 경우 엘비스 이후에 있는 예외 코드가 실행이 되게 될것이고, List<String>의 인스턴스를 넘기게 될 경우 캐스팅은 성공하겠지만 sum() 함수를 호출하는 과정에서 ClassCastException을 만나게 될 것이다.

fun printSum(c: Collection<*>) {
	val intList = c as? List<Int> 
	?: throw IllegalArgumentException("List is Expected")
	println(intList.sum())
}

만약 컴파일 시점에 타입 정보를 추론할 수 있는 상황이라면 코틀린 컴파일러는 is 검사를 허용해준다. 아래 코드에서는 Collection<Int>로 넘어오는 인자 타입을 추론할 수 있는 상황이기 때문에 is 검사를 허용하게 해준다.
IDE에서 테스트해보면 안전하지 못한 is 체크는 금지하고 위험한 as 캐스팅은 warning을 출력한다.

fun printSumB(c: Collection<Int>) {
	if (c is List<Int>) {
		println(c.sum())
	}
}

inline 함수를 사용하여 타입 파라미터 실체화를 사용하게 되면, 실행 시점에 인라인 함수의 타입인자를 알수 있게 되는데, 만약 인라인 함수가 람다를 인자로 사용하는 상황이라면 별도의 익명 클래스나 객체가 생성되지 않기 때문에 성능상으로 좀 더 나아질 수도 있다.
컴파일러는 인라인 함수의 본문을 구현한 바이트코드를 함수가 호출되는 모든 지점에 삽입하게 되고 컴파일러는 호출한 부분의 타입 인자를 활용해 해당 함수에서 사용하는 정확한 타입 정보를 알수 있게 된다.
Iterable.filterIsInstance 표준 함수를 예시로 살펴보면, 실제 filterIsInstance를 호출하는 함수 내부에서 inline 함수를 호출하기 때문에 해당 함수 본문의 바이트코드가 호출한 부분에 채워지게 된다. 본문을 대치하게 됨으로써 실제 제네릭으로 넘어간 타입 정보 역시 런타임에서도 타입 정보가 지워지지 않고 유지된다.

fun reifiedFilterList(): List<String> {
	return listOf("one", 2, "three")
	.filterIsInstance<String>()
}

// 함수 선언부
public inline fun <reified R> Iterable<*>.filterIsInstance(): List<R>

자바코드에서 코틀린 코드를 호출할 경우, inline 함수의 실체화된 타입 파라미터는 사용할 수 없다고 한다.

자바에서는 코틀린의 함수를 보통 함수처럼 호출하기 때문에 코틀린에서처럼 인라인 함수의 본문 대치가 불가능하다.
보통 inline 함수에서는 람다를 사용한 코드가 일반적인데, 위 filterIsInstance의 경우 람다 선언이 없이 구체화된 타입 정보를 런타임에 알기 위해 사용한 것이다. 일반적으로 람다를 사용하지 않는 인라인 함수는 성능적으로 유리하지 않으며 JVM내에서도 일반 함수를 호출해도 강력하게 인라이닝할 수 있도록 기술적인 장치가 존재한다고 한다.
- baeldung_jvm-method-inlining
java.lang.Class 타입 인자를 인자로 받아서 처리하는 코드를 만들 때, inline 함수의 실체화 타입 파라미터를 사용하는 것 또한 유용하다. 클래스 타 타입 인자를 받아서 처리하는 API 중 대표적인 유스케이스로는 JDK의 ServiceLoader가 있고, 또한 자주 사용하는 jackson과 같은 직렬화/역직렬화 라이브러리에서도 클래스 타입 인자를 넘겨서 처리하는 API가 존재한다.
아래의 예제 코드처럼 타입 파라미터로 전달된 T에 대해 ::class.java 구문을 사용하여 클래스에 대한 참조를 얻는 방법도 가능하다.

inline fun <reified T: Any> getServiceLoader(): ServiceLoader<T> {
    return ServiceLoader.load(T::class.java)
}

// jackson-module-kotlin
inline fun <reified T> jacksonTypeRef(): TypeReference<T> = object: TypeReference<T>() {}

실체화 타입 파라미터의 사용 가능한 경우와 제약사항은 아래와 같다.
- 사용 가능한 경우
  - 타입 검사와 캐스팅(is, as)
  - 리플렉션 API
  - 코틀린 타입에 대응하는 자바 Class 타입 얻기(::class.java)
  - 다른 함수 호출 시, 타입 인자로 사용
- 제약 사항
  - 타입 파라미터의 인스턴스 생성
  - 타입 파라미터 클래스의 동반 객체 메소드 호출
  - 일반 타입파라미터를 실체화 타입 파라미터를 인자로 받는 함수에 넘기기
  - 클래스, 프로퍼티, 인라인 함수가 아닌 함수의 타입 파라미터를 reified로 지정
실체화 타입 파라미터를 사용하는 인라인 함수에서 람다를 사용하게 될 경우, 경우에 따라 인라이닝을 할 수 없는 경우도 발생하기도 하며, 성능 문제로 인라이닝을 안하고 싶을 수도 있다. 이럴 경우 noinline 키워드를 사용하여 인라이닝을 금지 시킬수 있다.

변성(variance)

기저 타입이 같고 타입 인자가 다른 여러 타입이 서로 어떤 관계가 있는지 설명하는 개념

List<String>, List<Any>와 같이 기저 타입이 같고 타입이 인자가 다를 경우

변성은 코드에서 위험할 여지가 있는 메소드를 호출할 수 없게 만듬으로써 제네릭 타입의 인스턴스 역할을 하는 클래스 인스턴스를 잘못 사용하는 일이 없게 방지하는 역할을 수행한다.
String의 경우 Any를 확장하기 때문에 Any타입을 받는 함수에 String타입의 인자를 넘겨도 안전하겠지만, List<String>, List<Any>의 경우 확실한 안정성을 이야기할 순 없다. 아래 예제를 보면, 문자열로 선언된 mutableList에 정수값 42가 추가되고 maxBy 함수를 호출하는 과정에서 Integer에 대해 캐스팅 익셉션이 발생하는 걸 확인할 수 있다.

fun printContents(list: List<Any>) {
	println(list.joinToString())
}

fun addAnswer(list: MutableList<Any>) {
	list.add(42)
}

val strings = mutableListOf("abc", "bac")
addAnswer(strings)

// ClassCastException: Integer cannot be cast to String
println(strings.maxBy { it.length })

어떤 함수가 만약 리스트의 값을 추가/변경하면 타입 불일치가 생길 수 있으니 List<Any> 대신 List<String>을 넘길 수 없다. 하지만, 원소의 추가/변경이 없을 경우 List<Any> 대신 List<String>을 넘겨도 안전하다. 코틀린에서는 리스트의 변경 가능성에 따라 적절한 인터페이스를 선택하게 되면 추가/변경을 막을 수 있어 안전하지 못한 호출을 막을 수 있다.
타입 =! 클래스
- 제네릭 클래스가 아닌 경우 클래스 이름을 타입으로 바로 사용할 수 있다. 단순한 예제로 val x: String가 있다.
- 제네릭 클래스에서는 상황이 복잡하다. List는 타입이 아니고 클래스이며 실제 타입 파라미터가 추가된 List<String>, List<Int> 등이 제대로 된 타입이다. 제네릭 클래스는 결국 무수하게 많은 타입을 만들 수 있게 된다.
하위 타입
- A 타입의 값을 받을 수 있는 인자에 B 타입 값이 들어갈 수 있다면 A타입은 B타입의 상위 타입, B타입은 A타입의 하위 타입 으로 정리할 수 있다. 예를 들어, Number타입의 인자를 받을 수 있는 함수에 Int값을 넘길 수 있기에 둘 사이의 관계는 Number타입은 Int타입의 상위 타입, Int타입은 Number타입의 하위 타입으로 상/하위 타입 관계를 표현할 수 있게 된다.
타입 관계의 중요성은 컴파일러가 변수 대입이나 인자 전달 시 하위 타입 검사를 매번 수행하기 때문이다. Int 타입의 인자를 받는 함수에 Number 타입 인자를 넣어 호출하게 되면 하위 타입 검사에서 Int 타입의 하위 타입이 Number가 아니기 때문에 컴파일이 되지 않게 된다.
간단한 경우 하위 타입은 하위 클래스와 같게 된다. 앞에서의 예처럼 Int 클래스는 Number 클래스의 하위 클래스이므로 Int는 Number의 하위 타입이다.
하지만 코틀린의 Nullable과 NonNull 타입의 관계를 생각해보면 이야기가 조금 더 복잡해지는데, Int? 타입 선언에는 Int타입의 값을 넣거나 변수 선언을 해도 무관하지만, 반대로 Int타입엔 Int?를 선언하는 건 불가능하기 때문에 둘 사이의 관계는 Int?타입은 Int타입의 상위 타입 혹은 Int타입은 Int?타입의 하위 타입이라고 정리할 수 있다.

val s: String = "abc"
val t: String? = s // String이 String?의 하위 타입이므로 이 대입은 가능

제네릭 타입을 인스턴스화 할때, 타입 인자에 서로 다른 타입이 들어가고 서로 하위 타입 관계가 성립하지 않은 걸 가리켜 무공변(invariant)라고 한다.
타입 A가 B의 하위 타입이면 List<A>는 List<B>의 하위 타입이며 이런 관계를 공변적(covariant)라고 한다.
공변성(covariant)
- 공변적인 관계를 표현할 때는 out 키워드를 넣어 표현한다.
```
interface Producer<out T> {
    fun produce(): T
}
```
- 클래스의 타입 파라미터를 공변적으로 만들면 함수 정의에 사용한 파라미터 타입과 타입 인자의 타입이 정확히 일치하지 않더라도 그 클래스의 인스턴스를 함수 인자나 반환 값으로 사용할 수 있다.
- 타입 파라미터를 공변적으로 지정하면 클래스 내부에서 그 파라미터를 사용하는 방법을 제한한다
  - 타입 안정성을 위해 항상 아웃(out) 위치에 있어야 한다. 클래스가 타입의 값을 생상할 수 있지만 값을 소비할 수 없다는 이야기이다.
- 클래스 맴버 선언 시, 타입 파라미터를 사용할 수 있는 지점은 out/in으로 나뉘며, out으로 선언할 경우 반환 타입(생산)에 쓰이며 in 으로 선언할 경우 값을 소비하는 역할로 한정이 된다.
```
interface Transformaer<T> {
  // t의 인자는 in 위치, 반환 타입 T는 out 위치
  fun transform(t: T): T
}
```
- 다시 정리하면, 공변성은 하위 타입 관계가 유지되며, 아웃 키워드를 통해 공변성을 표현하며 아웃으로 선언하게 되면 아웃 위치에서만 사용이 가능하다.
```
class Herd<out T: Animal> {
  val size: Int
  	get() = ...
  operator fun get(i: Int): T { ... }
}
```
- 위 클래스는 Herd 클래스에 Animal의 하위 타입을 받는 타입이며, 공변성을 표현하고 있고 타입 한정을 Animal로 지정하여 T타입은 자연스럽게 Animal 타입으로 취급된다. 또한 공변성을 표현하고 있기 때문에 반환 타입으로만 해당 타입을 지정하는 것이 가능하다.
  또한, Animal뿐만 아니라 이를 상속하는 타입이 있다면 해당 타입을 타입 파라미터로 지정하는 것이 가능하다. 예를 들어 Cat이 Animal의 하위 타입이라면 get을 호출하는 부분에서 Cat을 반환해도 아무런 문제가 없게 된다.
- 타입 파라미터는 함수 파라미터 타입이나 반환 타입으로만 쓰이지 않고, 다른 타입 파라미터의 인자로도 사용할 수 있다.
- 생성자 파라미터는 인이나 아웃 어느 쪽도 아니며 타입 파라미터가 out 으로 선언되어 있어도 그 타입을 생성자 파라미터 선언에 사용할 수 있다. 생성자는 나중에 호출할 수 있는 메소드가 아니기 때문에 위험할 여지가 없다.
- val, var 키워드를 생성자 파라미터에 사용할 경우 게터 혹은 세터를 정의하는 것고 같기 때문에 읽기 전용 프로퍼티는 아웃 위치에 그리고 변경 가능 프로퍼티는 인 위치에 해당한다.
```
class Herd<T: Animal>(var leadAnimal: T, vararg animals: T) { ... }
```
반공변성(contravariance)
- 타입 B가 A의 하위 타입인 경우, Consumer<A>가 Consumer<B>의 하위 타입인 관계가 성립하면 제네릭 클래스 Consumer
  는 타입 인자 T에 대해 반공변을 표현한다고 할 수 있다.
  - Animal의 하위 타입인 Cat이 Consumer<Animal>가 Consumer<Cat>의 하위 타입 관계가 성립될 경우 이를 반공변 관계가 성립한다고 할 수 있다.
- in이라는 키워드는 그 키워드가 붙은 타입이 이 클래스의 메소드 안으로 전달돼 메소드에 의해 소비된다는 뜻이다. 다시 말해, 오직 인 위치에서만 사용할 수 있다는 뜻이다.

공변 vs 반공변 vs 무공변

공변성	반공변성	무공변성
`Producer<out T>`	`Consumer<in T>`	`MutableList<T>`
타입 인자의 하위 타입 관계가 제네릭 타입에서도 유지된다.	타입 인자의 하위 타입 관계가 제네릭 타입에서 뒤집힌다.	하위 타입 관계가 성립하지 않음
`Producer<Cat>`은 `Producer<Animal>`의 하위 타입이다.	`Consumer<Animal>`은 `Consumer<Cat>`의 하위 타입이다.
T를 아웃 위치에서만 사용	T를 인 위치에서만 사용	T를 아무 위치에서나 사용 가능

아래 Function 인터페이스은 공변과 반공변을 설명하기 아주 좋은 예제이다. 인자로 받는 P 타입에 대해서는 반공변성을 유지하며, R 타입에 대해서는 공변성을 띄게 된다.

interface Function1<in P, out R> {
    operator fun invoke(p: P): R
}

Cat과 Animal의 예제를 위 Function1에 대입해보면 (Cat) -> Number와 (Animal) -> Int에서도 하위 타입 관계가 성립하게 된다. 위 Function1의 경우 코틀린의 표현으로 바꿔보자면 (Cat) -> Number를 받는 인자에 (Animal) -> Int의 함수 인스턴스를 넘기더라도 하위 타입 관계가 성립하기 때문에 호출에 문제가 없게 되는 것이다.

다시 정리하면 반공변의 경우 타입의 하위 관계를 반대로, 공변의 경우 타입의 하위 관계를 그대로 유지, 무공변의 경우 타입 파라미터간의 하위 타입 관계가 전혀 없는 것으로 정리할 수 있다.

변성의 종류
- 선언 지점 변성(declaration site variance): 클래스 선언에 지정하는 것을 선언 지점 변성이라 부르며, 한번의 선언만으로 변성을 추가 지정할 필요가 없으므로 코드가 간결해진다.
- 사용 지점 변성(use site variance): 자바에서처럼 타입 파라미터가 있는 타입을 사용할때 마다 해당 타입 파라미터를 하위 타입이나 상위 타입 중 어떤 타입으로 대치할 수 있는지 명시하는 방법을 사용 지점 변성이라고 한다. 자바의 한정 와일드카드 타입(bounded wildcard)을 사용하는 것을 생각하면 된다.(? extends , ? super) 물론 코틀린도 자바에서처럼 사용 지점 변성을 지원한다. 공변적이거나 혹은 반공변적인지 선언할 수 없다면 사용 지점 변성을 사용하여 타입 파라미터가 나오는 지점에 변성을 정의하면 된다.
변성을 지정하지 않은 클래스를 사용할 때 변성에 대한 지정이 가능하다. 대표적인 예제로 MutableList가 있다. MutableList는 타입 파라미터로 넘어는 값을 생산할 수도 있고 소비할수도 있게 되는데, 변성에 대한 지정을 통하여 이를 제어할 수 있게 된다.

fun <T> copyData(source: MutableList<out T>, destination: MutableList<T>) {
	for(item in source) {
		destination.add(item)
	}
}

위 예제에서 source의 타입 선언을 MutableList<out T>로 지정해뒀는데, out 키워드를 붙임으로서 무공변인 MutableList에서 공변으로 제약을 붙인 타입으로 프로젝션을 시킬 수 있게 된다. 이럴 경우 값을 소비하는 add 함수등을 사용하게 될 경우 Out-projected type ....과 같은 에러를 만나게 될 수 있다.
정리하면, 타입 선언에서 [타입 파라미터를 사용하는 위치]라면 어디에나 [변성 변경자]를 붙일 수 있으며, [파라미터 타입, 로컬 변수 타입, 함수 반환 타입] 등에 타입 파라미터가 쓰이는 경우 in이나 out 변경자를 붙일 수 있다. 이를 가리켜 타입 프로젝션(type projection)이라 부른다.
- List<out T>처럼 이미 변성 변경자가 붙어 있는 클래스에 out 프로젝션을 하는 것은 의미가 없으므로 컴파일러와 IDE가 친절하게(?) 경고를 하게 될 것이다.

Netty-In-Action - 1부, 네티 개념과 아키텍처

oh-yes — Sun, 18 Jul 2021 15:13:50 +0900

Netty-In-Action

1부, 네티 개념과 아키텍처

1장. 네티: 비동기 이벤트 기반 네트워킹 프레임워크

최초 자바 API(java.net)은 네이티브 시스템 소켓 라이브러리가 제공하는 블로킹 함수만 제공
- 다수의 클라이언트를 관리하려면 새로운 클라이언트 소켓마다 새로운 스레드를 할당해야 함.
- 여러 스레드가 입출력 데이터를 무한정 대기하는 상태가 유지될 수 있고, 이는 곧 리소스에 대한 낭비로 이어질 수 있음.
- 운영체제에 따라 다르지만 스텍의 기본 크기는 64KB ~ 1MB까지 차지할 수 있다. JVM이 많은 수의 스레드 생성을 지원하지만, 동시 접속이 한계에 이르는 순간(1만개 전후) 컨텍스트 스위칭에 따른 오버헤드가 심각한 문제가 될수 있다.
네이티브 소켓 라이브러리에는 오래전부터 네트워크 리소스 사용률을 세부적으로 제어할수 있는 논블로킹(non-blocking) 호출이 포함되어 있다.
- setsockopt() 시스템 함수를 통한 블로킹 콜에 대한 옵션 설정 가능
- 이벤트 통지 API(epoll/kqueue)를 통하여 논블로킹 소켓의 집합을 등록하면 읽거나 기록할 데이터가 준비됐는지 여부를 알수 있다. 참고
- 논블로킹 입출력을 위한 자바의 기능 지원은 1.4부터 java.nio 패키지를 통하여 이뤄졌다.

자바의 논블로킹 설계의 핵심은 바로 java.nio.channels.Selector 클래스이다. 시스템의 이벤트 통지 API를 그대로 사용하며 언제나 읽기/쓰기 작업의 완료 상태를 확인할 수 있으므로 단일 스레드로 여러 동시 연결을 처리할 수 있다.
- 적은 수의 스레드로 더 많은 연결을 처리할 수 있으므로 컨텍스트 스위칭에 따른 오버헤드와 메모리 관리가 원활해짐
- 스레드의 상태가 점유가 되어 있지 않기 때문에, 입출력 외에 다른 작업을 사용할 수 있음.
네티는 네트워킹 도메인에서 가장 유명한 자바 프레임워크로 기반 구현의 복잡성을 단순한 추상화로 감춰 개발자가 어플리케이션 구현 영역에 집중할 수 있도록 도와준다.
- 블로킹/논블로킹 방식의 모두 지원
- 코어 자바 API보다 높은 처리량과 짧은 지연 시간. 풀링/재사용을 통한 리소스 소비 감소, 메모리 복사 최소화
이벤트 기반의 비동기식으로 어플리케이션을 작성할때는 특수한 문제에 대한 고려가 필요.
- 발생하는 이벤트에 대해 언제든지/순서에 상관없이 응답을 할 수 있음, 이는 곧, 증가하는 처리량에 맞게 시스템/네트워크/프로세스의 능력을 작업량 증가에 맞게 늘리는 능력으로 정의할 수 있는 최고 수준의 확장성을 갖추는데 필수적임.
- 논블로킹 네트워크 연결은 작업 완료를 기다릴 필요가 없다. 비동기 코드는 바로 반환을 하며 완료가 되면 추후에 이를 통지하는 방식이다.
- 셀렉터는 적은 수의 스레드로 여러 연결에서 이벤트를 모니터링 할 수 있게 해줌

네티의 핵심 컴포넌트
- Channel
  하나 이상의 입출력 작업(읽기/쓰기)을 수행할수 있는 하드웨어 장치/파일/네트워크 소켓/프로그램 컴포넌트와 같은 엔티티에 대한 열린 연결, 들어오는 Inbound와 나가는 Outbound를 위한 운송수단으로 생각하자
- Callback
  콜백은 관심 대상에게 작업 완료를 알리는 가장 일반적인 방법으로 네티는 이벤트를 처리할 때 내부적으로 콜백을 이용한다. 콜백 트리거가 되면 ChannelHandler 인터페이스 구현을 통해 이벤트를 처리할수 있다.
- Future
  퓨처는 작업이 완료되면 어플리케이션에 이를 알리는 방법이다. 비동기 작업의 결과를 접근할 수 있게 해준다. JDK에서는 java.util.concurrent.Future 인터페이스를 제공하지만, 해당 구현은 작업 완료 여부 확인과 완료전까지 블록킹하는 기능만 존재한다. 네티는 이를 개선한 ChannelFuture를 사용한다. ChannelFuture에는 ChannelFutureListener 인스턴스를 하나 이상 등록할 수 있으며 완료시점에 operationComplete() 콜백 메소드가 호출이 된다. 해당 콜백 실행 시점에 완료/오류 등을 확인 가능하다.
  네티의 모든 아웃바운드 입출력은 ChannelFuture를 반환하고 진행에 블로킹 작업은 없다. 모든것은 비동기에 이벤트 기반이다.
이벤트와 핸들러
네티는 작업 상태 변화를 알리기 위해 고유한 이벤트를 사용한다. 로깅, 데이터 변환, 흐름 제어, 어플리케이션 논리 등의 동작을 포함한다. 이벤트들은 크게 인바운드와 아웃바운드 데이터 흐름의 연관성을 기준으로 분류한다.
모든 이벤트는 핸들러 클래스의 사용자 구현 메서드로 전달할 수 있다. 다시 말해, 각 핸들러 인스턴스는 특정 이벤트에 반응하여 실행하는 일종의 콜백이라고 이해하면 된다.
- 인바운드: 연결 활성화/비활성화, 데이터 읽기, 사용자 이벤트, 오류 이벤트
- 아웃바운드: 원격 피어 연결 열기/닫기, 소켓에 데이터 쓰기/플러시

2장. 첫 번째 네티 어플리케이션

책의 경우 maven 기준으로 설명을 하고 있지만, 예제는 gradle 기반의 프로젝트에서 작성했으며, 4.1.65.Final 버젼을 기준으로 실습 편의성을 위해 netty-all 디펜던시를 참조했다.
```
dependencies {
implementation 'io.netty:netty-all:4.1.65.Final'
...
}
```

EchoServer 코드 작성

아래 EchoServer 및 EchoServerHandler 코드 작성 후 기동

public class EchoServer {
    private final int port;

    public EchoServer(int port) {
        this.port = port;
    }

    public static void main(String[] args) throws InterruptedException {
        if (args.length < 1) {
            System.err.println("Usage: " + EchoServer.class.getSimpleName() + "<port>");
        }
        int port = Integer.parseInt(args[0]);
        new EchoServer(port).start();
    }

    public void start() throws InterruptedException {
        final EchoServerHandler echoServerHandler = new EchoServerHandler();
        EventLoopGroup group = new NioEventLoopGroup();
        try {
            ServerBootstrap b = new ServerBootstrap();
            b.group(group)
                .channel(NioServerSocketChannel.class)
                .localAddress(new InetSocketAddress(port))
                .childHandler(new ChannelInitializer<SocketChannel>() {
                    @Override
                    protected void initChannel(SocketChannel ch) throws Exception {
                        System.out.println("initChannel");
                        ch.pipeline().addLast(echoServerHandler);
                    }
                });
            ChannelFuture future = b.bind().sync();
            future.channel().closeFuture().sync();
        } finally {
            group.shutdownGracefully().sync();
        }
    }
}

부트스트랩 하는 코드를 포함하고 있으며, 서버 연결 요청을 수신하는 포트를 서버와 바인딩하는 코드가 있어야 한다.
NioEventLoopGroup을 통하여 새로운 연결 수락 및 데이터 읽기/쓰기와 같은 이벤트를 처리
서버가 바인딩하는 InetSocketAddress를 지정
새로운 연결을 수락하고 Channel을 생성 후 ChannelInitializer를 통하여 EchoServerHandler 인스턴스를 Channel의 ChannelPipeline으로 추가한다.
ServerBootstrap.bind() 호출하여 서버를 바인딩

@Sharable // 여러 Channel에서 공유할 수 있음을 나타나는 마커 인터페이스 
public class EchoServerHandler extends ChannelInboundHandlerAdapter {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
    final ByteBuf in = (ByteBuf) msg;
    System.out.println(
        "Server received: " + in.toString(CharsetUtil.UTF_8)
    );
    ctx.write(in);
}

@Override
public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
    ctx.writeAndFlush(Unpooled.EMPTY_BUFFER)
        .addListener(ChannelFutureListener.CLOSE);
}

@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
    cause.printStackTrace();
    ctx.close();
}
}

telnet을 통하여 Echo 메세지가 다시 telnet 클라이언트로 다시 전달이 되는지 확인하면 서버 코드 작성은 완료
서버에 들어오는 이벤트에 반응해야 하기 때문에 ChannelInboundHandler 구현체인 ChannelInboundHandlerAdapter 하위 클래스를 만들었고, 여기에 몇개 메소드를 오버라이드하여 메세지를 처리하도록 했다.
- channelRead: 메세지가 들어올때마다 호출
- channelReadComplete: channelRead()의 마지막 호출에서 현재 일괄 처리의 마지막 메세지를 처리했음을 핸들러에 통보
- exceptionCaught: 읽기 처리 중 예외가 발생하면 콜백됨, 예외 처리를 하지 않을 경우 ChannelPipeline의 마지막까지 이동 후 로깅이 되며, 가급적이면 하나 이상의 exceptionCaught를 구현하는 것이 바람직하다고 한다.
ChannelHandler는 네 가지 이벤트 유형을 제공하며, 어플리케이션은 ChannelHandler을 구현하거나 확장하여 이벤트를 후크하고 어플리케이션 로직을 제공해야 한다. ChannelHandler는 비즈니스 관심사에서 네트워크 관심사를 분리하는 것을 도와준다.

EchoClient 코드 작성

어플리케이션에서 필요한 EchoClient, EchoClientHandler 핸들러 코드는 아래와 같다.

@Sharable
public class EchoClientHandler extends SimpleChannelInboundHandler<ByteBuf> {
    @Override
    public void channelActive(ChannelHandlerContext ctx) throws Exception {
        ctx.writeAndFlush(
        Unpooled.copiedBuffer("Netty rocks!", CharsetUtil.UTF_8)
        );
    }

    @Override
    protected void channelRead0(ChannelHandlerContext ctx, ByteBuf msg) throws Exception {
        System.out.println(
                "Client received: " + msg.toString(CharsetUtil.UTF_8)
        );
    }

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
        cause.printStackTrace();
        ctx.close();
    }
}

서버와 마찬가지로 EchoClientHandler는 ChannelInboundHandler 인터페이스의 구현체인 SimpleChannelInboundHandler의 메소드를 오버라이드하여 필요한 작업을 처리한다.
- channelActive(): 서버 연결 후 콜백
- channelRead0(): 서버에서 메세지 수신 후 콜백
- exceptionCaught(): 처리 중 예외 시 콜백
channelRead0()에서 주의할 점은 전체 바이트 데이터 수신를 한 번에 수신한다는 보장이 없다. 경우에 따라 channelRead0() 메소드가 여러번 호출될 수 있다. 대신, TCP는 스트림 기반 프로토콜이므로 서버에서 보낸 순서대로 바이트 수신을 보장한다.예시) AB|CDE|FG, ABC|DE|FG, AB|CD|EFG 와 같은 형태로 바이트를 수신할 수도 있다는 이야기이다.

public class EchoClient {
    private final String host;
    private final int port;

    public EchoClient(String host, int port) {
        this.port = port;
        this.host = host;
    }

    public void start() throws InterruptedException {
        EventLoopGroup group = new NioEventLoopGroup();
        try {
            Bootstrap b = new Bootstrap();
            b.group(group)
                    .channel(NioSocketChannel.class)
                    .remoteAddress(new InetSocketAddress(host, port))
                    .handler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(SocketChannel ch) throws Exception {
                            ch.pipeline()
                        .addLast(new EchoClientHandler());
                        }
                    });
            ChannelFuture f = b.connect().sync();
            f.channel().closeFuture().sync();
        } finally {
            group.shutdownGracefully().sync();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        if (args.length < 1) {
            System.err.println(
                    "Usage: " + EchoClient.class.getSimpleName() + "<host> <port>"
            );
        }
        String host = args[0];
        int port = Integer.parseInt(args[1]);
        new EchoClient(host, port).start();
    }
}

3장. 네티 컴포넌트와 설계

Channel, EventLoop, ChannelFuture

Channel: Socket
EventLoop: 제어 흐름, 멀티스레딩, 동시성 제어
ChannelFuture: 비동기 결과 알림

Channel 인터페이스

실제 구현 클래스와 인터페이스 종류는 더 다양하다.

Channel 인터페이스는 Socket으로 직접 작업할 때의 복잡성을 크게 완화하는 API를 제공

EventLoop 인터페이스

연결 수명주기 중 발생하는 이벤트를 처리하는 핵심 추상화 인터페이스

출처: Netty-In-Action

Channel - EventLoop - Thread - EventLoopGroup 사이에서의 상호작용은 아래와 같다
- 한 EventLoopGroup은 하나 이상의 EventLoop를 포함
- 한 EventLoop는 수명주기 동안 하나의 스레드에 바인딩
- 한 EventLoop에서 처리되는 모든 입출력은 전용 스레드에서 처리
- 한 Channel은 수명주기 동안 EventLoop에 등록
- 한 EventLoop는 하나 이상의 Channel로 할당 가능

ChannelHandler와 ChannelPipeline

ChannelHandler 인터페이스
네티의 핵심 컴포넌트로 인바운드와 아웃바운드 데이터의 처리에 적용되는 모든 어플리케이션 논리를 처리하는 컨테이너 역할을 수행. 네트워크 이벤트에 의해 트리거되며 데이터를 변환하거나 예외처리하는 등의 모든 종류의 작업에 활용 가능하다.

ChannelPipeline 인터페이스
- ChannelPipeline은 ChannelHandler 체인을 위한 컨테이너를 제공.
- 체인에서 인바운드/아웃바운드 이벤트를 전파하는 API를 정의한다.
- ChannelHandler는 아래와 같은 과정으로 ChannelPipeline에 설치
  - ChannelInitializer 구현은 ServerBootstrap에 등록
  - ChannelInitializer.initChannel()을 호출하면 ChannelInitializer가 ChannelHandler의 커스텀 집합을 파이프라인에 설치
  - ChannelInitializer는 ChannelPipeline에서 자신을 제거
- 파이프라인을 통해 이벤트를 전달하는 역할은 ChannelHandler가 담당하며, 핸들러 객체는 이벤트를 수신하고 로직을 실행하며 체인상의 다음 핸들러로 데이터를 전달한다.
- 위 이미지에서 볼수 있듯이 인바운드/아웃바운드 핸들러는 같은 파이프라인에 설치가 가능하며 메세지/이벤트를 읽을 떄는 파이프라인 앞쪽에서 시작하며 체인상의 다음 ChannelInboundHandler로 데이터를 전달한다. 최종적으로 데이터가 파이프라인 뒤쪽에 이르면 모든 처리가 종료된다.
- 아웃바운드도 개념은 동일하며, 체인상에서 뒤쪽에서 시작하여 앞쪽에 이를 때까지 이동한다. Socket으로 나오는 부분에 도달하면 쓰기 작업이 트리거된다.
- 인바운드/아웃바운드 모두 ChannelHandler를 확장하지만, ChannelInboundHandler와 ChannelOutboundHandler의 구현을 구분하여 데이터 전달이 동일한 방향으로 수행되도록 보장한다.
- ChannelHandler를 하나 추가할 때 ChannelHandler와 ChannelPipeline의 바인딩을 나타내는 ChannelHandlerContext 하나가 할당된다.
- 네티에서는 메세지를 보내는 데 Channel에 직접할 기록하는 방법과 ChannelHandler와 연결된 ChannelHandlerContext 객체에 기록하는 두 가지 방법이 존재한다. 전자는 ChannelPipeline 뒤쪽에서 시작되며, 후자의 방법은 메세지가 ChannelPipeline의 다음 핸들러에서 시작된다.

ChannelHandler에 대한 고찰

네티는 비즈니스 로직을 쉽게 개발할 수 있도록 어댑터 클래스의 형태로 여러 기본 핸들러를 제공
파이프라인의 각 핸들러는 체인의 다음 핸들러로 전달해야 하는데, 어댑터 클래스는 이 작업을 자동으로 해주고 특수한 동작이 필요한 메서드와 이벤트만 재정의할 수 있다.
가장 자주 사용할 어댑터는 아래와 같다
- ChannelHandlerAdapter
- ChannelInboundHandlerAdapter
- ChannelOutboundHandlerAdapter
- ChannelDuplexHandlerAdapter

인코더/디코더

메세지를 전송/수신할 때는 데이터를 변환해야 한다. 인바운드 메세지를 바이트에서 다른 포맷(보통 객체)로 변환하는 디코딩 과정을 거친다. 아웃바운드 메세지를 반대로 현재 포맷에서 바이트로 인코딩 되는 과정을 거친다.
두 가지 변환 과정이 필요한 이유는 네트워크 데이터는 연속된 바이트여야하기 때문이다.
네티가 제공하는 인코더/디코더 어댑터 클래스는 ChannelInboundHandler와 ChannelOutboundHandler를 구현한다.
- 인바운드 데이터의 경우 인바운드 Channel에서 읽는 각 메세지에 대해 호출되는 channelRead 메세지/이벤트를 재정의한다. 이 메서드는 제공된 디코더의 decode() 메서드를 호출한 후 디코딩된 바이트를 파이프라인 다음 ChannelInboundHandler에 전달한다.
- 아웃바운드 메세지를 위한 패턴은 반대이며 인코더가 메세지를 바이트로 변환한 후 다음 ChannelOutboundHandler로 전달한다.

SimpleChannelInboundHandler 추상 클래스

어플리케이션에서 들어오는 디코딩된 메세지를 수신하고 데이터에 비즈니스 논리를 적용하는 핸들러를 많이 사용하게 되는데 이러한 핸들러를 만들때 SimpleChannelInboundHandler<T>를 확장하면 되며, T는 처리하는 메세지의 제네릭 타입이다. 하나 이상의 메소드를 오버라이드하고 모든 핸들러 매서드에 인자로 전달되는 ChannelHandlerContext에 대한 참조를 얻는다.
이 메소드에서 가장 중요한 메소드는 channelRead0(ChannelHandlerContext T)인데, 원하는대로 구현을 가능하지만 현재 입출력 스레드를 블로킹하지 않아야 한다는 요건이 있다.

부트스트랩

네티의 부트스트랩 클래스는 프로세스를 지정 포트에 바인딩(서버 부트스트랩)하거나 프로세스를 지정된 호스트의 지정된 포트에서 실행 중인 다른 호스트로 연결(클라이언트 부트스트랩)하는 등의 일을 하는 네트워크 레이어를 구성하는 컨테이너를 제공한다.

범주	Bootstrap	ServerBootstrap
네트워크 기능	원격 호스트/포트와 연결	로컬 포트로 바인딩
EventLoopGroup	1	2

Bootstrap과 ServerBootstrap은 각기 EventLoopGroup의 수가 다른걸 볼 수 있다.

서버의 경우, 첫 번째 집합은 로컬 포트와 바인됭 서버 자체의 수신 소켓을 나타내는 ServerChannel 하나를 포함하고 두 번째 집합은 서버가 수락한 연결마다 하나씩 들어오는 클라이언트 연결을 처리하기 위해 생성된 모든 Channel을 포함한다.
ServerChannel과 연결된 EventLoopGroup은 들어오는 연결 요청에 대해 Channel을 생성하는 역할을 EventLoop 하나에 할당한다. 연결이 수락되면 두 번째 EventLoopGroup이 해당 Channel에 EventLoop를 할당한다.

4장 전송

네티는 모든 전송 구현에 공통 API를 기반으로 사용하기 때문에 JDK를 직접 이용할 떄보다 변환이 훨씬 간단하다.
- 코드가 세부 구현 사항으로 오염될 우려가 적고, 광범위한 범위를 수정할 필요가 없어진다.

영속성 관리(Persistence Context, OSIV)

oh-yes — Sat, 31 Aug 2019 20:09:09 +0900

영속성관리

자바 ORM 표준 JPA 프로그래밍 13장 내용을 정리

스프링과 같은 컨테이너 환경에서 JPA를 사용하게 되면, 컨테이너 레벨에서 트랜잭션과 영속성 컨텍스트를 관리해주므로 어플리케이션 개발이 쉬워지게 되는데, 문제가 되는 부분은 내부 동작에 대한 정확한 이해가 없을 때 생기는 트러블 슈팅이 어려워 지는 부분이다. 내부동작에 대한 이해, 스프링 컨테이너에서의 기본 전략, 지연로딩, OSIV에 대한 내용을 가볍게 정리하고자 한다.

트랜잭션 범위의 영속성 컨텍스트

스프링 컨테이너의 기본 전략

스프링은 트랜잭션 범위의 영속성 컨텍스트를 기본 전략으로 사용한다.
트랜잭션 범위와 영속성 컨텍스트의 생존 범위가 동일하며, 트랜잭션 종료 시, 영속성 컨텍스트도 동일하게 종료하게 된다.

스프링 어플리케이션에서는 @Transactional을 사용하여 트랜잭션을 시작하게 되는데, 단순 호출처럼 보이는 부분도 사실 스프링의 트랜잭션 AOP가 먼저 작동하게 된다.
- 스프링 트랜잭션 AOP는 대상 메소드를 호출하기 직전에 트랜잭션을 시작하며, 호출이 정상적으로 종료되면 트랜잭션을 커밋하고 종료하게 된다.
- 트랜잭션 커밋 시, JPA는 영속성 컨텍스트를 플러시하여 변경 내용을 DB에 반영한 후 트랜잭션을 커밋하게 된다.
- 예외가 발생하게 되면, 트랜잭션을 롤백하고 종료하게 되는데, 이때는 영속성 컨텍스트를 플러시하지 않게 된다.

트랜잭션이 같을 경우, 같은 영속성 컨텍스트를 사용한다.
- 다양한 위치에서 엔티티 매니저(EntityManager)를 주입받아 사용해도 트랜잭션이 같으면 항상 같은 영속성 컨텍스트를 사용하게 된다.

트랜잭션이 다를 경우, 다른 영속성 컨텍스트를 사용한다.
- 여러 스레드에서 동시에 요청에 올 경우, 같은 엔티티 매니저를 사용한다고 하더라도 트랜잭션에 따라 접근하는 영속성 컨텍스트가 달라진다.
- 다시 말해, 스프링 컨테이너에서는 스레드별로 각기 다른 트랜잭션을 할당하게 되는데, 따라서 같은 엔티티 매니저를 호출해도 접근하는 영속성 컨텍스트가 다르기 때문에 멀티스레드 환경에서도 안전하다.

준영속/지연 로딩

조회한 엔티티가 트랜잭션 범위인 서비스, 레파지토리 레이어에서는 영속성 컨텍스트에 의해 관리가 되기 때문에 영속 상태를 유지하지만, 이 밖의 레이어에서는 준영속 상태가 된다.
영속성 컨텍스트의 관리 밖에서는 지연 로딩 및 변경 감지가 동작하지 않는다.
- 따라서, 비지니스 혹은 요구사항을 기반으로 한 변경에 대해서는 반드시 서비스/도메인 레이어에서 수행을 해야한다. 컨트롤러와 같은 영역에서 이를 수행하게 되면 레이어별로 책임이 모호해지고 어플리케이션의 유지보수성이 급격하게 떨어지게 된다.
- 지연 로딩 기능이 동작하지 않기 때문에, 생기는 이슈는 생각보다 크다. 만약 컨트롤러와 같은 레이어에서 지연 로딩 상태의 연관 엔티티나 밸류를 조회하게 될 경우, LazyIntializationException 예외가 발생하게 된다.
지연 로딩을 해결할 수 있는 방법은 아래와 같다.
- 필요한 엔티티를 미리 로딩
  1. 글로벌 페치 전략 수정
  2. JPQL 페치 조인
  3. 강제로 초기화
- OSIV(Open Sessin in View)를 사용하여 엔티티를 항상 영속 상태로 유지

OSIV의 경우 별도로 정리하는걸로 하고, 먼저 필요 엔티티를 미리 로딩하는 방법에 대해 정리하고자 한다. 말 그대로, 뷰 혹은 컨트롤러 레이어에서 필요한 데이터를 영속성 컨텍스트 범위 내에서 미리 로딩을 하는 방법을 가리키며 위에서 정리한대로 3가지 방법이 존재한다.

글로벌 페치 전략 수정 - 즉시 로딩

주문 엔티티에서 주문 상품 벨류 목록을 담고 있는 예제로 주문 상품 벨류의 경우 별도의 식별자가 필요하지 않기 때문에 @ElementCollection을 이용하여 주문 엔티티에 매핑을 했으며 글로벌 페치 전략은 즉시 로딩으로 설정해주었다.

@Entity
@Table(name = "orders")
class Order protected constructor() {

	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	var id: Long = 0L
		protected set

	@Column(nullable = false, updatable = false)
	var memberId: Long = 0L
		protected set

	@Enumerated(value = EnumType.STRING)
	@Column(length = 20, nullable = false)
	var status: OrderStatus = OrderStatus.PAYMENT_WAITING
		protected set

	@ElementCollection(fetch = FetchType.EAGER)
	@CollectionTable(
		name = "order_products",
		joinColumns = [
			JoinColumn(name = "id")
		]
	)
	@AttributeOverrides(
		value = [
			AttributeOverride(name = "productId", column = Column(name = "product_id")),
			AttributeOverride(name = "price", column = Column(name = "price")),
			AttributeOverride(name = "quantity", column = Column(name = "quantity")),
			AttributeOverride(name = "amounts", column = Column(name = "amounts")),
			AttributeOverride(name = "line_idx", column = Column(name = "line_idx"))
		]
	)
	@OrderBy(value = "line_idx")
	var orderProducts: MutableList<OrderProduct> = mutableListOf()
		protected set

	@CreationTimestamp
	@Column(nullable = false)
	var createdAt: LocalDateTime = LocalDateTime.now()
		protected set

	@UpdateTimestamp
	@Column(nullable = false)
	var updatedAt: LocalDateTime = LocalDateTime.now()
		protected set

	companion object {
		fun doOrder(
			memberId: Long,
			status: OrderStatus,
			products: List<OrderProduct>
		): Order {
			if (status !in listOf(OrderStatus.PAYMENT_WAITING, OrderStatus.PATMENT_COMPLETED)) throw IllegalArgumentException("올바른 주문 상태 값이 아닙니다.")
			if (products.isEmpty()) throw IllegalArgumentException("최소 한개 이상의 구매 상품을 포함해야 합니다.")
			return Order().also {
				it.memberId = memberId
				it.status = status
				it.orderProducts = products.toMutableList()
			}
		}
	}
}

@Service
@Transactional(read)
class OrderService(
	private val orderRepository: OrderRepository
) {
	fun getList(pageable: Pageable): Page<Order> {
		val list = orderRepository.findAll(pageable)
		return list
	}

	fun get(id: Long): Order {
		return orderRepository.findByIdOrNull(id)
				?: throw NotExistsOrderException("존재하지 않은 주문입니다.")
	}
}

서비스 레이어에서 주문 엔티티에 대한 조회를 목록/단건 조회할 수 있도록 가벼운 코드를 작성했다. 주문ID 기준의 단건 조회의 경우, 연관 콜렉션에 매핑 되어 있는 order_products테이블을 LEFT OUTER JOIN을 사용하여 바로 조회하는 것을 확인 할 수 있다.

여기까지는 문제가 없다고 생각할 수 있다. 하지만, 문제는 목록 조회 부분에서 생기게 되는데, 바로 N+1 문제이다.

단건만 조회하는 엔티티라면 문제가 없겠지만, 대부분의 어플리케이션에서 목록 조회는 기본으로 하기 때문에 즉시 로딩을 사용함으로써 아래와 같은 단점이 생길 수 밖에 없다.

불필요한 벨류/엔티티 조회
주문 엔티티에서 목록이 필요하지 않은 경우에도 매번 목록 데이터를 조회하기 때문에 DB 레벨에서의 오버헤드가 발생한다.
N+1 문제 발생
- 위 이미지를 통하여 볼 수 있듯이, 디비에 질의하는 쿼리 개수가 목록에서 반환하는 데이터 개수만큼의 IO가 발생하게 된다. 불필요한 IO 발생은 서버 어플리케이션에서는 당연히 지양해야 한다.
- JPQL을 사용하게 될 경우(ex. JpaRepository.findAll()), JPA는 SQL을 생성할 때 글로벌 페치 전략을 참고하지 않고 오직 JPQL 자체만 사용하게 된다. 아래는 SQL문을 생성하는 과정을 설명하고 있다.
  1. select o from Order o JPQL을 분석하여 select * from Order SQL을 실행
  2. 데이터베이스에서 결과를 받아 Order엔티티 목록을 생성
  3. Order.orderProducts의 글로벌 페치 전략이 즉시 로딩이므로 연관 벨류 콜렉션을 로딩해야 한다.
  4. 연관 벨류/엔티티를 영속성 컨텍스트에서 찾는다.
  5. 영속성 컨텍스트에 저장되어 있는 1차 캐싱 데이터가 없을 경우, DB에 질의하여 데이터를 가져온다. 이때, Order엔티티 목록의 개수만큼 DB에 질의를 하게 된다.

글로벌 페치 전략 수정 - 지연 로딩

위에서 겪었던 N+1 문제의 경우, 연관 벨류 콜렉션의 글로벌 페치 전략을 지연 로딩으로 변경하고, 이를 영속성 컨텍스트 범위 내에서 호출해주면 해결할 수 있다.

@Service
@Transactional(readOnly = true)
class OrderService(
	private val orderRepository: OrderRepository
) {
	fun getList(pageable: Pageable): Page<Order> {
		val list = orderRepository.findAll(pageable)
		for (order in list) {
			// 실제 값을 사용할 때 프록시 객체가 초기화 된다.
			order.orderProducts.forEach { it.amounts }
		}
		return list
	}

	fun get(id: Long): Order {
		val order = (orderRepository.findByIdOrNull(id)
				?: throw NotExistsOrderException("존재하지 않은 주문입니다."))
		// 실제 값을 사용할 때 프록시 객체가 초기화 된다.
		order.orderProducts.forEach { it.amounts }
		return order
	}
}

글로벌 페치 전략을 지연 로딩으로 변경하게 될 경우, 연관 벨류/엔티티를 실제가 아닌 프록시 객체를 대상으로 조회하게 된다.
프록시의 경우 실제 사용할 때 초기화가 진행되기 때문에, 위 코드처럼 실제 값을 호출하는 코드를 넣어줘야지 초기화가 진행된다.
위 예제 코드의 경우, ID 기준의 조회 메소드인 get에서는 지연 로딩의 이점을 충분히 잘 살려냈다고 할 수 있지만, 목록 조회에서의 경우, 강제 초기화를 진행하더라도 즉시 로딩에서처럼 초기화 시 매번 매핑한 벨류 콜렉션을 조회하는 또 다른 의미의 N+1이 발생하게 된다.
이와 같은 형태의 N+1을 피하기 위해서 사용할 수 있는 방법으로는 아래와 같다.
- 하이버네이트의 @BatchSize가 있다. @BatchSize를 사용할 경우, 프록시를 통하여 초기화 대상이 되는 연관 벨류/엔티티의 실제 값을 가져오는 DB 질의를 in절로 수정하여 N번의 DB 질의가 발생하지 않도록 해준다. 하지만, @BatchSize를 사용하더라도 실제 연관 벨류/엔티티를 초기화 해줘야 하는건 동일하기 때문에, 아래와 같이 기준을 나눠서 매핑하는 전략을 생각해볼 수 있다.
- JPQL fetch 조인을 사용하면 조회하면 시점에 SQL 조인을 사용하여 함께 로딩할 벨류/엔티티를 로딩할 수 있다. 하지만, JPQL의 페치 조인을 사용하게 되면 프레젠테이션 영역에 필요한 데이터에 맞춘 레파지토리 메소드가 늘어날 수 있다는 단점이 분명히 존재한다.
트레이드오프가 필요한 지점이다. 성능적인 최적화 혹은 높은 TPS를 처리해야 하는 어플리케이션에서 불필요한 IO는 병목지점이 될 수 밖에 없다. 연관 엔티티를 모두 조회하더라도 Cache를 적용하여 불필요하게 DB IO가 발생하지 않도록 하는 방법도 좋고, 필요한 DB IO만 발생하도록 JPQL을 사용하는 방법 모두 상황에 따라 맞는 방법이라고 생각한다.

그래서 최선의 방법은?

결국, 트랜잭션 경계 밖에서의 준영속 상태가 문제의 핵심이다.
이를 해결하기 위해서는 경계 밖에서도 영속성 컨텍스트가 살아있도록 해주는 방법을 사용하면 자연스럽게 지연로딩에서 발생할 수 있는 문제를 해결할 수 있다. 그것이 바로 OSIV이다.

OSIV

Open Session In View
영속성 컨텍스트를 프레젠테이션 레이어까지 열어둔다는 뜻이다.
하이버네이트에서는 OSIV 스프링에서는 OEIV라고 부르며, 관례상으로 OSIV라고 통칭하는 듯 하다.
하이버네이트의 OSIV와 스프링에서의 OEIV는 비슷하지만 차이점이 분명하게 존재한다. 쉽게 생각하여 하이버네이트에서의 OSIV의 단점을 개선한 것이 OEIV라고 봐도 좋다.

과거 OSIV: 요청 당 트랜잭션

초창기 OSIV는 요청 당 트랜잭션을 지원했는데 아래 그림을 참고하자
서블릿 필터 혹은 스프링 인터셉터에서 영속성 컨텍스트를 생성하며 이때부터 트랜잭션을 시작하고 요청이 끝날 때 트랜잭션과 영속성 컨텍스트를 함께 종료하게 된다.
프레젠테이션 레이어도 트랜잭션 경계내에 존재하게 됨에 따라, 지연로딩을 처리하기 위해 프록시 객체를 초기화해야 하는 과정이 필요없게 된다. 하지만, 트랜잭션의 경계가 비즈니스 레이어가 아닌 프레젠테이션 레이어부터 시작함에 따라 트랜잭션의 경계가 모호해지며 비즈니스 레이어가 아닌 곳에서 데이터 변경이 발생하는 문제가 생길 수 있다.

요청 당 트랜잭션 모델의 문제점

JDBC 커넥션 보유 시간 증가
- JDBC 커넥션은 뷰의 렌더링이 모두 완료된 후에야 커넥션 풀로 반환된다. 따라서 뷰의 렌더링 시간이 길어지면 길어질수록 개별 요청을 처리하기 위한 스레드가 JDBC 커넥션을 보유하는 시간이 길어진다.
모호한 트랜잭션 경계
- 예를 들어, 특정 컨트롤러에서 뷰에 표현하고자 하는 목적으로 엔티티를 변경한다면 요청에 마무리되는 시점에 해당 변경 사항이 영속성 컨텍스트에 변경 감지에 의해 반영이 되고 플러쉬됨에 따라 디비에 반영까지 되는 사이드 이펙트가 생기게 된다. 데이터의 변경이 도메인 계층이 아닌 이외 계층에서 이뤄진다면 유지보수성은 급격히 떨어지게 된다.
  - 뷰/프레젠테이션 레이어에서 엔티티를 변경하지 못하도록 하는 방법을 생각해볼 수 있다.
    - DTO 객체 반환
    - 세터 지양
    - 읽기 전용 인터페이스/메서드 제공
- 일반적으로 애플리케이션의 트랜잭션 경계는 애플리케이션 레이어 SERVICE 를 경계로 한다. 즉, SERVICE 메서드 호출 전에 바로 트랜잭션이 시작되고 SERVICE 메서드 호출이 종료될 때 트랜잭션이 커밋되거나 롤백되는 것이 일반적이다. 이에 비해 과거 OSIV 서블릿 필터의 트랜잭션 경계는 HTTP 요청 처리 시간의 거의 대부분을 아우른다. 결국 트랜잭션 경계에 대한 일관성 있는 뷰를 유지할 수 없으며 이로 인해 다양한 문제가 발생할 여지가 있다.

스프링 OSIV: 비즈니스 계층 트랜잭션

비즈니스 계층에서 트랜잭션을 사용하는 OSIV
뷰 렌더링 시점의 지연 로딩을 허용하면서도 일관성 있는 트랜잭션 경계를 유지하는 합리적인 절충안으로 서블릿 필터에서 Session 을 오픈하되 트랜잭션 경계는 애플리케이션 레이어 범위로 한정하는 것이다.
Spring 프레임워크에서는 FlushMode 와 ConnectionReleaseMode 의 조정을 통해 과거 OSIV 모델의 단점을 보완할 OpenSessionInViewFliter와 OpenSessionInViewInterceptor를 제공한다.
자세한 내용은 아래 내용을 참조하도록 하자
1. 클라이언트의 요청 시, 서블릿 필터/인터셉터에서 영속성 컨텍스트를 생성한다. 단, 트랜잭션은 시작하지 않음
2. 도메인 계층에서 트랜잭션을 시작할 때, 1번에서 생성한 영속성 컨텍스트를 사용하여 트랜잭션을 시작
3. 도메인 계층의 서비스가 종료되면서 트랜잭션이 커밋하고 영속성 컨텍스트를 플러쉬한다. 트랜잭션은 종료가 되지만 영속성 컨텍스트를 종료하지 않는다.
4. 영속성 컨텍스트가 도메인 레이어가 아닌 프레젠테이션 레이어에서도 유지됨에 따라, 반환하는 엔티티는 영속 상태를 유지한다.
5. 필터/인터셉터로 돌아와서 영속성 컨텍스트를 종료한다. 이때는 영속성 컨텍스트를 플러쉬하지 않는다.

트랜잭션 없는 읽기

트랜잭션 없이 영속성 컨텍스트를 플러쉬하게 되면 javax.persistence.TransactionRequiredException 예외가 발생
변경은 반드시 트랜잭션 내에서 이뤄져야 하는데, 조회의 경우 트랜잭션 없이도 가능하다. 이것을 바로 트랜잭션 없이 읽기(Nontransactional reads)라고 한다.
프록시 객체를 초기화하는 지연 로딩 역시 조회이므로 트랜잭션 없이 읽기가 가능하다.
결국 스프링 OSIV를 이용하게 되면 도메인 계층에서만 트랜잭션을 이용하여 변경이 가능하고, 이 밖의 레이어인 프레젠테이션 레이어에서는 엔티티를 변경한다고 하여도 영속성 컨텍스트를 플러쉬하지 않기 때문에 변경이 불가능하고 오직 읽기만 가능하게 되는 것이다.

스프링 OSIV 사용 시 주의점

서비스 호출 후 컨트롤러에서 반환하는 엔티티가 있다고 가정해보자.
이미 종료한 트랜잭션에서 반환한 엔티티이며 OSIV를 사용하고 있기 때문에 여전히 영속 상태를 유지하게 될 것이다. 요구사항에 의해 엔티티를 일부 값을 수정하며 바로 뷰를 반환하면 OSIV를 사용하기 때문에 문제가 전혀 없다.
하지만, 바로 뷰로 데이터를 반환하지 않고 또 다른 서비스 메서드를 호출하여 트랜잭션을 시작할 경우 문제가 발생하게 된다.
왜냐하면, 스프링 OSIV에 의하여 영속성 컨텍스트를 살아 있는 상태를 유지하기 때문에, 이전에 변경한 값이 새로 시작한 트랜잭션 커밋에 의해, 영속성 컨텍스트를 플러쉬하게 되는데 플러쉬하는 시점에 이전에 변경한 엔티티의 변경사항이 그대로 실제 데이터베이스에 반영되기 때문이다.

위와 같은 문제는 같은 영속성 컨텍스트를 여러 트랜잭션에서 공유하기 때문에 발생하는 문제로 해결하는 단순한 방법은 트랜잭션이 있는 비즈니스 로직을 모두 호출하고 나서 엔티티를 변경하면 쉽게 해결된다.
다시 말해, 선 트랜잭션 후 변경으로 요약할 수 있다.

OSIV를 사용하는 것이 만능이 아니다.

객체 그래프의 뎁스가 깊어진다면 OSIV를 사용했을 때, 성능적으로 신경써야 할 부분도 많아진다.
도메인의 요구사항 단순 엔티티만을 반환하여 끝나는 경우는 생각보다 드물다. 특히 통계 성격의 데이터를 조회해야 하는 경우가 대표적인데, 이럴 경우 차리리 JPQL을 사용하여 데이터를 조회하고 이를 DTO 객체로 바인딩하여 반환하는 것이 생각보다 쉬운 해결책일 수도 있다.
너무 복잡하거나 DB 종속적인 연산을 사용해야 할 경우도 생길 수 있는데, 이럴 경우 하이버네이트의 @SubSelect를 사용하여 별도로 조회 전용 도메인 객체를 만들어서 해결하는 방법도 존재한다. 물론 DB 종속적인 연산을 사용하게 됨에 따라 추후 DB 변경에 대한 대응이 어려워질 수 있는 부분도 분명 존재하지만, 일반적으로 사용하고 있는 데이터베이스를 변경하는 작업은 쉽게 일어나지도 않을 뿐더러 완벽하게 어플리케이션 레이어에서 변경을 쉽게 커버할 수 있는 경우 더 드물다고 생각한다.

20190810

oh-yes — Sat, 10 Aug 2019 20:48:12 +0900

1. 휴식?

회사를 그만두었기 때문에 누릴 수 있는 가장 큰 사치는 아마 늘어지게 잘 수 있는 늦잠 그리고 자유로운 시간일 것이다. 최근 한달 가량을 그렇게 보내고자 맘을 먹었지만, 불행인지 다행인지 정말로 한번쯤은 도전해보고 싶은 회사에서 공채를 시작하여 거기에 매달려 한달 가량 아니 한 3주 가량의 시간을 전력의 삶(?)을 살다보니 시간이 어느덧 8월 가량이 되었다. 사실 저번달에는 공부도하고 공채 준비도 했으니 이번달에는 전력으로 쉬고자 하는 마음이 가장 크다. 하지만 공채 결과가 어떻게 될지는 모르겠지만, 그래도 좋은 방향으로 흐르고 있는거 같아. 어쩌면 지금의 휴식이 길어지지만은 않겠구나 하는 생각도 든다.

뭐 다시 개발 이야기로 돌아와서 보자면 과제를 준비하면서 해볼 수 있는 건 모두 했다라고 생각하고 있다.
프론트엔드에 그렇게 큰 관심을 두고 있는 건 아니지만, vue.js를 이용하여 간단한 어플리케이션을 만들어 볼 수 있어 추후에 다시 한다고 하더라도 근거는 없지만 조금은 어렵지 않게 접근할 수 있겠다는 생각이 들었기 때문이다.
또한, 최근 계속 코틀린으로만 서버 어플리케이션을 작성했었는데, 다시 자바로 작성하면서 잃어버렸던 감 아닌 감을 조금은 찾을 수 있어서 좋았고, 코틀린에 맛을 들려버린 탓인지는 몰라도 이전에는 부수효과처럼 느껴졌던 롬복 같은 구현체도 이게 없으면 정말 불편하겠다 싶은 생각도 들었다.

물론 자바와 코틀린 둘다 공부를 해야 하는 상황으로 갈거 같지만, 그래도 여유를 느낄 수 있는 지금의 상황도 너무 좋다. 쉬고 싶으면 그 마음 가는대로 쉬면 그만이고, 공부하고 싶고 책이 읽고 싶으면 내 마음 가는대로 할 수 있는 지금의 자유가 너무 좋은거 같다. 길어질거 같진 않지만 그래도 지금을 즐기고 충분하게 휴식하자!

2. 그래서 뭘 공부하지?

못했던 공부에 대해 어느정도 TODO 리스트는 작성하는 것이 좋을거 같다. 물론, 휴식기간 동안 다 못할 수 있다. 하지만, 4개 파트 중 두개... 아니 하나만 제대로 한다면 그거 나름대로의 의미가 있다고 생각한다.

DDD Start 나머지 파트 정리
- 책을 다 읽었지만, 정리 못한 부분이 존재함
JPA
- JPA 심화 파트 부분을 공부
- JPQL, 2차 캐시 등
코틀린
- 기본 확장 함수, JVM 상호 운용
- 코루틴
- Spring, JPA를 함께 사용하면서 꼭 알아야 할 내용
쉘 스크립트
- 이건 이번에 반드시 공부한다.

20190714

oh-yes — Sun, 14 Jul 2019 21:11:33 +0900

20190714

1. DDD Start 다 읽음

간만에 끝까지 다 읽은 책이다. 책 내용이 너무 흡입력이 좋았다. 기존에 API를 개발하면서 늘 고민하던 설계적인 부분 혹은 구현 패턴에 대한 100%까지는 아니지만 어느정도의 답을 준거 같아서 나름 만족스러운 독서였다고 평하고 싶다. 마지막 부분이라 크게 기억이 남는 것인지는 몰라도 도메인 이벤트 처리하는 방법이나 CQRS에 대한 부분 그리고 락(선점, 비선점, 오프라인)에 대한 구현과 소개도 너무 좋았었다. 이제 내용을 정리해서 마크다운과 블로그에 올리는 일만 남았는데, 3장까지밖에 정리하지 못해서 할일이 많이 남은거 같아 이거도 일종의 기술부채인가 하는 생각이 들었다.

2. MySQL 5.7

MySQL 5.7 관련 신간이 출시하기도 했고, 스터디에서 해당 책을 가지고 공부하자는 의견이 나와서 리플리케이션 부분은 일주일정도해서 짬짬이 읽고 내용을 정리했다. 결과적으로 내용 이해를 많이 못했다. 내부 구현에 대한 부분이라 지루하기도 했고 모르는 용어와 옵션들이 많이 보여서 아무래도 집중력 있게 하지 못한거 같아 시간을 들여서 다시 읽는 작업을 해야 될거 같다.

20190622

oh-yes — Sun, 14 Jul 2019 21:10:52 +0900

20190622

1. DDD Start 8장 읽기

애그리거트 트랜잭션 처리에 대한 내용으로 애그리거트 수정이 동시에 발생했을 경우, 이를 어떻게 처리 할지에 대한 내용을 담고 있다. DB 레벨에서의 선점 락과 선점 락으로 인해 발생할 수 있는 문제(데드락)을 회피하기 위한 비선점 락에 대한 전략(JPA-Hibernate의 @Version을 활용한 업데이트 전략) 그리고 오프라인 락을 통하여 락에 대한 선점을 미리 하는 방법까지 간단하게 학습할 수 있었다.

다시 읽어보면서 내용 정리를 해보고 좀 더 깊게 생각해봐야겠지만, 실제 업무에서는 대부분 DB 레벨에서의 선점 락을 사용하는 경우가 많았는데, 디비 레벨에서의 선점 락을 사용할 경우, 락을 대기하는 스레드가 발생하여 실제 동시성에 크게 영향을 주면서 개발을 할 수 밖에 없었다. 하지만, 비선점 락을 잘 연구해보고 활용할 수 있다면 굳이 선점 락을 사용하지 않고도 Update 성격의 데이터 처리를 할 수 있겠다라는 생각이 들었다.

이번 장을 읽으면서 좀 더 와닿은 예제는 아틀라시안 컨플루언스의 사례였다. 회사에서도 컨플루언스를 사용하면서 실제 같은 페이지를 수정하는 경우가 종종 있는데 여기서 적용된 락에 대한 정책이 바로 오프라인 락 정책이었다는 사실에 내가 모르고 못 보는 여러 개발에서 실제 책에서 본 그런 내용들이 적용되어 있음에 스스로가 아직 한참 멀었구나 하는 생각이 들었다.

2. 백기선님 REST API 강좌 듣기

그런 REST API로 괜찮은가을 보고 내가 여태까지 개발해놓고 스스로 REST라고 불렀던 API들은 사실 그냥 WEB API 혹은 HTTP API 정도가 되는 것을 알게 되었다. 사실 이전에 REST라고 하면 그저 자원을 URI로 식별하고 자원에 대한 행위를 HTTP METHOD로 하며 HTTP 명세에 있는 헤더 값을 잘 활용하는 정도라고 생각했는데, 내가 생각 정의한 내용은 말그래도 REST 모델에서 아주 일부분에 불과한 사실...

그래서 좀 더 내가 만든 API 그리고 앞으로 개발할 내용에서 보다 충실한 REST한 API를 만들고 싶다는 생각이 들어서 강의나 리소스를 찾아보다가 발견한 것이 백기선님 강의이다. 사실 Spring Boot에 대한 내용보다는 실제 REST한 구현에 필요한 방법론이나 접근 방식이 더 궁금해서 강의를 구매한 이유가 더 컸다. 7강까지 들었는데 서두에서 예제로 보여줬던 다양한 API들(네이버, 카카오, Github)의 예시를 들었던 것도 좋았고 컨퍼런스에서 발표하셨던 내용을 한번 복기 해주는 것도 좋았다.

시간이야 늘 없다지만, 짬짬히 듣고 예제코드까지 완성해야겠다.

DDD - #3 애그리거트(Aggregate)

oh-yes — Wed, 10 Jul 2019 17:21:48 +0900

DDD_#3

DDD Start의 3장 내용을 정리

애그리거트(Aggregate)

도메인 모델에 대한 파악과 애그리거트

상위 수준에서의 접근과 개별 객체 혹은 구현 단위에서의 접근으로 나눌 수 있다. 상위 수준에서의 이해가 없는 상태에서 개별 객체에 대해 모델링을 하거나 개발을 하게 되면 상위 수준에서의 도메인 간의 관계가 어려워지게 된다.

상위 수준에서 올바른 이해를 바탕으로 개별 객체에 대한 모델링을 진행해야지 전체 모델링을 망가트리지 않으면서 추가 요구사항을 수행할 수 있기 때문에 큰 그림에서의 도메인 모델에 대한 이해는 필수이다.
애그리거트 단위로 묶어서 상위 모델을 바라보면 상위 수준에서 도메인 모델 간의 관계를 쉽게 파악할 수 있다.

graph LR subgraph 주문 Address --- ShippingInfo ShippingInfo --- Order Order --- Orderer ShippingInfo --- Receiver Receiver --- Orderer OrderLine --- Order DeliveryTracking --- OrderLine OrderLine --- Order DeliveryTracking --- Order end subgraph 회원 Orderer --- Member Member --- MemberGrade end subgraph 결제 Order --- PaymentInfo end subgraph 카테고리 Category end subgraph 리뷰 Review end subgraph 상품 Product Review --- Product Category --- Product Product --- OrderLine end

애그리거트 단위로 모델링을 하게 되면 좀 더 일관성 있는 구조를 가질 수 있게 되며, 일관성이 확보되는 만큼 복잡한 도메인 모델을 단순하고 확장에 용이한 구조로 가져갈 수 있게 된다.
구현 모델에서 즉, 실제 애그리거트 단위로 객체를 만들게 되면 연관 객체(벨류, 엔티티)를 함께 생성하고 이에 대한 라이프사이클도 동일하게 가져가게 될 가능성이 높다.
위 도표에서도 볼 수 있는 내용이지만, 애그리거트는 경계를 가지게 된다. 경계를 정하는 기준은 도메인 규칙과 요구사항을 기준으로 하면 된다. 기준에 따라 함께 생성되는 객체나 요소들은 애그리거트로 묶일 가능성이 높게 된다.
생성하고 변경하는 주체가 다르다면 같은 애그리거트로 묶이기 힘들 수 있다. 좋은 예가 바로 상품/리뷰의 관계이다. 상품은 담당자가 생성/변경하고 리뷰의 경우 실제 고객이 생성/변경하기 때문이다.

상품과 리뷰를 동시에 조회해야 하는 요구사항이 생긴다면 별도로 조회 전용에 대한 도메인(DAO)을 만들어서 구현하면 된다. 보통의 경우, 응용 영역에서 개별 애그리거트를 조회하여 이를 조합하는 형식이면 된다고 생각한다.

애그리거트 루트

애그리거트를 대표하는 엔티티 객체이며 루트 엔티티라고 부르기도 한다. 애그리거트에 속한 객체는 루트 엔티티에 직접/간접적으로 속하게 된다.
애그리거트는 여러 객체로 구성되기 때문에 특정 객체만 만들어지는 상황이 생기면 안된다. 도메인의 규칙과 요구사항을 충실하게 지키기 위해서는 애그리거트에 속한 객체가 온전히 정상 상태를 가질 수 있어야 한다. 이러한 일관된 상태/일관성를 유지하기 위해서는 담당/관리할 객체가 필요하게 된다. 이것이 바로 애그리거트 루트이다.
일관성을 유지해야 하기 때문에, 애그리거트 루트는 연관 객체들의 상태에 대한 제어권을 가지게 되며 도메인 기능에 대한 실제 구현을 담당하게 된다.
애그리거트 루트가 아닌 외부에서 애그리거트에 속한 객체에 대한 직접적인 접근을 못하도록 해야 한다.
도메인에 대한 구현을 응용 영역에서 담당할 수도 있지만, 이는 곧 여러 응용 클래스에서 도메인에 대한 중복 구현이 발생하게 되는 원인이 되게 된다. 가급적이면 응집성 있게 도메인 클래스에서 구현을 담당하도록 해야 하며 이를 지키기 위해서는 세터 사용 지양 그리고 벨류 타입에 대한 불변 클래스 적극적 활용하는 방법을 습관화 시켜야 한다.

세터를 외부에서 접근하게 되면, 엔티티의 상태 변화 제어가 어려워진다. 다시 말해, 상태 변경에 대하여 왜/어떻게 변했는지에 대한 추적이 어려워진다.
실제 어플리케이션 코드를 작성하다보면 이를 지키지 않고 습관적으로 게터/세터를 만들어 쓰는 것을 너무 많이 구경해왔다. 실제 초기 단계에서는 도메인에 대한 구현이나 요구사항이 복잡하지 않아 생기는 문제가 적겠지만, 추후 도메인과 비즈니스가 확장됨에 따라 변경이 발생하고 코드 베이스가 길어지면 관리하기 힘들어 지는 것이 자명한 사실이다. 코드 베이스가 길어지면 어쩔 수 없는 일이라고 생각하는 사람도 있겠지만 길어지더라도 변경에 대한 이유와 근거가 명확한 것이 추후 유지보수성이나 확장에 유리하다고 생각한다.
이러한 차원에서 가급적이면 세터 사용을 지양하고 도메인 클래스 혹은 도메인 서비스에서 상태 변경을 제어하도록 하여 일관성 있는 구현을 유지하는 것이 중요하다고 할 수 있다.
엔티티 클래스 예시

@Embeddable
data class ArticleContent (
    val content: String = "",
    val contentType: String = ""
)


@Entity
@Table(name = "article")
@SecondaryTable(
    name = "article_content",
    pkJoinColumns = [PrimaryKeyJoinColumn(name = "id")]
)
class Article private constructor() {
    companion object {
        fun create(
            title: String = "",
            content: ArticleContent = ArticleContent()
        ) = Article().apply {
            this.title = title
            this.content = content
        }
    }

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    var id: Long = 0L
        protected set

    var title: String = ""
        protected set

    @Embedded
    @AttributeOverrides(
        value = [
            AttributeOverride(
                name = "content", column = Column(table = "article_content")
            ),
            AttributeOverride(
                name = "contentType", column = Column(table = "article_content")
            )
        ]
    )
    var content: ArticleContent = ArticleContent()
        protected set

    fun modifyContent(content: ArticleContent) {
        this.content = content
    }

}

위 클래스는 코틀린으로 작성한 JPA 엔티티 클래스이다. 여러 어노테이션을 사용해서 다소 복잡한 부분이 있긴 하겠지만, 애그리거트에 대한 충실한 구현을 한 클래스라고 생각한다.

세터 사용 제한
세터에 대한 접근 제한을 protected 로 지정하여 외부에서 프로퍼티에 대한 상태 변경을 하지 못하도록 함
불변 객체 사용
ArticleContent의 경우 코틀린의 데이터 클래스를 활용하였으며 실제 벨류 객체가 가지고 있는 값은 불변 프로퍼티(val)로 해당 값을 변경하기 위해서는 애그리거트에 있는 content값을 수정해야 한다. 세터에 대한 접근을 외부에서 할수 없기 때문에, 결국 애그리거트 클래스의 메서드를 활용하여 변경해줘야 하는데 변경은 modifyContent라는 메서드를 통하여 가능하다. 세터를 사용할때보다 좀 더 의미가 명확하다고 할 수 있다.

애그리거트 루트의 기능 구현

애그리거트 루트는 내부의 연관 객체를 조합하여 기능을 완성하게 된다.
도메인 규칙상 직접 기능 구현이 어려운 경우 기능 실행을 연관 객체에 위임할 수도 있다.

주문 엔티티 예시

주문 목록 벨류 객체들을 참조하여 총 주문 금액을 구하는 예시

@Entity
@Table(name = "purchase_order")
@Access(AccessType.FIELD)
class Order protected constructor() {
    // ... 생략

    @Column(name = "total_amounts")
    @Convert(converter = MoneyConverter::class)
    var totalAmount: Money = Money()
        protected set

    @ElementCollection
    @CollectionTable(
        name = "order_line",
        joinColumns = [
            JoinColumn(name = "order_number")
        ]
    )
    @OrderBy(value = "line_idx")
    var orderLines: MutableList<OrderLine> = mutableListOf()
        protected set

    private fun calculateTotalAmounts() {
        this.totalAmount = Money(
            totalAmount = this.orderLines
                .asSequence()
                .map { it.price.totalAmount * it.quantity }
                .sum()
        )
    }
}

트랜잭션

트랜잭션의 범위는 작을수록 좋기 때문에, 가급적이면 애그리거트 단위로 트랜잭션을 제한하는 것이 좋다.
한 트랜잭션에서 하나의 애그리거트만을 수정한다는 이야기는 결국 다른 애그리거트를 트랜잭션의 범위에 포함시키지 않겠다는 이야기와 같다. 애그리거트간의 의존이 생기기 시작하면 결국 결합도가 높아지게 되고 이는 곧 수정 비용이 증가하게 되므로 가급적이면 트랜잭션의 범위는 하나의 애그리거트로 제한하는 것이 좋다.
만약, 여러 애그리거트를 수정해야 하는 상황이 생긴다면 도메인 이벤트를 구현하는 방법을 고려해보는 것이 좋다. 도메인 이벤트 구현을 사용하면 애그리거트간의 트랜잭션을 분리할수도 있으며 또한 구현 자체를 나눠서 할 수 있기 떄문에 코드에 대한 복잡성 역시 낮아지게 된다.

레파지토리와 애그리거트

애그리거트는 하나의 도메인 모델을 표현하고 있으므로, 도메인 모델의 영속성을 처리하는 레파지토리 또한 하나만 존재하는 것이 맞다.
- 물리적으로 별도의 테이블에 저장한다고 해서, 별도의 레파지토리를 각각 만들지는 않는다.
레파지토리는 최소 저장(save) 및 식별자 조회(findById)를 구현해줘야 한다. Data-JPA를 사용하게 되면 레파지토리에서 기본적으로 제공해야 하는 대부분의 기능을 커버하고 있기 때문에 구현이 어렵지 않다.
애그리거트는 개념적으로 하나이기 때문에, 애그리거트 전체를 저장소에 영속화해야 한다.
- 만약 연관 엔티티/벨류 중 일부만 반영되면 일관성이 깨지므로 문제가 된다.

ID를 이용한 애그리거트 참조

하나의 애그리거트에서 다른 애그리거트를 참조할 떄, 애그리거트의 관리 주체가 애그리거트 루트이므로 다른 애그리거트 루트를 참조한다는 이야기와 같다.
다른 애그리거트를 참조하는 방법은 연관관계를 활용하는 방법도 있지만, 경계가 불분명해지고 확장 및 성능에 대한 이슈가 생길 수 있기 때문에 지양하는 것이 좋고, ID를 활용하여 다른 애그리거트를 참조하는 것이 그나마 나은 방법이다.
- 연관 관계를 매핑하게 되면 객체 그래프가 복잡해짐에 따라 트랜잭션에 대한 범위를 지정하는 것이 애매해질 수 있다.
- 결합도가 높아짐에 따라 수정/변경이 어려워진다. 또한, 서브도메인별로 시스템을 확장하거나 분리해야 할 경우, 애그리거트간에 관계 매핑때문에 변경하고 수정해야 할 부분이 많아질 수 밖에 없다.
- 애그리거트를 직접 참조하게 되면 패치 전략에 대한 판단도 해줘야 한다. 부가적으로 N+1에 대한 체크도 해줘야 하기 때문에 여러모로 손이 갈 수밖에 없다고 생각한다.
ID 참조를 활용하게 되면, 애그리거트 단위별로 경계가 명확해질 수 있으며 또한 하나의 애그리거트가 다른 애그리거트를 수정할 수 있는 문제를 원천적으로 막을 수 있게 된다. 또한, 애그리거트별로 다른 구현 기술을 사용할 수 있다. 트랜잭션이 중요한 애그리거트에는 RDBMS를 사용하고 조회/삽입/삭제 성능이 중요한 애그리거트에는 NoSQL(MongoDB, DynamoDB)등을 활용하는 전략을 사용할 수 있게 된다.
- 구현 기술이 달라지면 한 번의 쿼리로 해결을 할 수 없기 때문에, 별도의 캐시를 적용하거나 조회 전용 저장소를 구현하여 대응하면 된다.
ID 참조를 이용하게 되었을 떄, 문제가 되는 부분이 하나 있는데 조인을 사용해야 하는 조회 관련 도메인에 대한 구현이다. 해당 구현은 직접 코드로 해결하는 방법도 있지만 별도의 조회 전용 도메인을 작성하는 방법을 사용하는 것이 적절하다. JPA/Hibernate에서도 이런 조회 전용 도메인을 구현하는 방법을 제공해주고 있는데 바로 @Subselect를 이용하는 방법이다. 별도로 서브쿼리절을 사용하기 싫다면 Native쿼리를 매핑하여 사용하는 방법도 존재한다.

애그리거트 간 집합 연관

애그리거트간에 1:N, N:M의 관계를 정의하게 되면 주로 콜렉션을 활용하여 매핑을 하게 된다.
보통 1:N의 경우, 성능상의 이슈가 있기 때문에 구현하는 경우가 드물다. 하지만 N에 해당하는 데이터 개수가 고정적이고 많지 않은 상황이라면 충분하게 사용할 수 있다고 생각한다. 또한 이런 경우에 모든 데이터를 패치해오는 것이 아닌 나눠서 쿼리하여 매핑할 수 있도록 하이버네이트에서는 @BatchSize와 같은 어노테이션을 제공해주고 있다.
카테고리와 상품 애그리거트의 예를 들어 설명해보자면, 일반적인 조회 구현에서 하나의 카테고리에 속한 모든 상품을 조회하는 경우는 드물기 때문에, 먼저 조회해야 하는 카테고리의 식별자를 구하고 해당 식별자를 기준으로 상품 애그리거트를 조회하는 로직을 만드는 경우가 많다.
M:N의 경우, RDBMS를 이용하여 엔티티를 매핑해야 할 경우 보통 조인 테이블 전략을 많이 사용하게 된다. 아래 상품과 카테고리의 예를 살펴보면 쉽게 이해할 수 있는데, 상품 하나가 반드시 하나의 카테고리에만 속하는 것이 아니라 N개의 카테고리에 속할 경우를 생각해보면 매핑 데이터를 영속화 시킬 테이블이 필요하게 된다. 이 경우 조인테이블로 PRODUCT_CATEGORY를 사용하게 되는 것이다.

graph LR PRODUCT ---|1:N| PRODUCT_CATEGORY PRODUCT_CATEGORY ---|N:1| CATEGORY

아래는 상품 애그리거트 기준으로 조인 테이블 매핑 예시를 보여주고 있다.

@Entity
@Table(name = "product")
class Product protected constructor() {
	@EmbeddedId
	lateinit var id: ProductId
		protected set

	@ElementCollection
	@CollectionTable(
		name = "product_category",
                joinColumns = [JoinColumn(name = "product_id")]
	)
	lateinit var categoryIds: MutableSet<CategoryId>
		protected set
}

애그리거트를 팩토리로 사용하기

애그리거트 객체를 생성할 떄, 도메인의 요구사항에 따라 처리 로직이 필요한 경우 이를 응용 레이어에서 구현하는 경우를 쉽게 볼 수 있는데, 이런 구현 방법도 틀리진 않았지만 중요 로직 처리가 응용 레이어에 노출됨에 따라 추후에 중복 가능성이 생기게 된다. 보통 이런 경우 애그리거트에서 해당 기능을 구현하게 되면 응집성 있는 코드 구현이 가능하고 또한 연관 엔티티를 참조하여 풍부하게 도메인의 요구사항을 표현할 수 있게 된다.
애그리거트에 구현하기 힘들다면 별도로 도메인 서비스를 구현하거나 팩토리 클래스를 구현하는 방법을 생각해보는 것도 좋다.

20190609

oh-yes — Mon, 10 Jun 2019 08:24:44 +0900

20190610

DDD Start 3,4장 학습

1~2장을 통하여 DDD와 관련된 주요 개념과 키워드들을 살펴보았고, 3장부터는 도메인의 영역을 큰 그림을 통하여 세부 그림을 이해하는 법부터 시작하여 애그리거트를 구성하는 방법과 주의해야 할 부분이 대하여 조금 더 깊게 볼 수 있어서 좋았다. 4장에서는 실제 JPA를 이용하여 엔티티 매핑과 벨류 매핑을 직접 실습 해볼 수 있었는데, 자바로 되어 있는 매핑 코드를 코틀린 베이스로 옮겨서 작성해야 하니 생각보다 걸리는 지점이 있어서 조금 시간을 소모 할수 밖에 없었다. JPA를 공부하고 바로 이 책을 봤었더라면 좀 더 업무 코드에서도 의미 있는 엔티티 구성과 로직을 만들어 낼 수 있었겠다는 아쉬움도 들긴 하지만, 지금이라도 모자란 부분이 무엇인지 확인해볼 수 있는 좋은 기회인거 같아 나름 수확이 있다고 할 수 있다.

3장
- 트랜잭션 범위 지정: 애그리거트 단위로 지정
- 레파지토리/애그리거트
  - 레파지토리는 애그리거트 단위로 작성
  - 레파지토리의 인터페이스는 도메인 레이어에 그리고 이를 구현하는 클래스는 인프라스트럭처 레이어로 배치
- 애그리거트 간 연관 관계 참조 전략
  - 필드 매핑의 경우, 경계가 애매해질 수 있음
  - ID값을 매핑하는 전략을 사용할 경우 조금 더 명료해짐
- 애매한 경계에서의 요구사항일 경우, 별도의 조회 도메인을 작성하는 것도 좋다.
4장
- 루트 엔티티(애그리거트 루트) 매핑
- 레파지토리의 주요 역할
- 다양한 매핑 방법
  - ID값 매핑(@EmbeddedId)
  - 컬렉션 데이터 매핑(컬럼, 테이블)
  - @Convert, AttributeConvert를 활용한 데이터 컨버터 생성 및 적용
- 벨류 객체에 대한 매핑 전략
  - 같은 라이프사이클 내에 존재하는 연관 객체라면 벨류 객체 매핑을 통하여 충분히 해결이 가능하다.
  - @Embeddable, @Embedded을 사용한 불변 객체 활용 및 @AttributeOverrides, @AttributeOverride를 활용한 컬럼 데이터 재지정 및 매핑
  - 도메인 상황에 따른 엔티티 객체로 매핑
    - 연관 객체라고 하여 모든 것을 엔티티로 매핑 할 이유는 없다. 객체의 라이프사이클이 엔티티로 지정 해야 할 라이프사이클인지 그리고 확실하게 애그리거트내에 존재해야 하는지 도메인 상황에 맞는 정확한 판단을 해야 한다.
  - @ElementCollection, @CollectionTable을 별도 테이블 벨류 매핑
- 로딩 전략(Eager/Lazy)
  - N+1
  - Eager와 Lazy를 사용해야 할 시점에 대한 고민
  - Lazy 사용 시, 트랜잭션 범위 내에서 사용
- 영속성 전파/식별자 생성 전략
  - Cascade, orphanRemoval

DDD - #2 아키텍처

oh-yes — Sat, 8 Jun 2019 20:55:19 +0900

DDD-2

DDD Start의 2장 내용을 정리

아키텍처 / 네 개의 영역? / 계층 구조 아키텍처

아키텍처를 구성하는 요소는 크게 4가지로 나뉠 수 있다. 표현, 응용, 도메인 및 인프라스트럭처로 나뉠 수 있으며, 각 계층별로 가져야 할 책임은 위 다이어그램을 통하여 확인이 가능하다.

표현 레이어의 경우, 사용자 혹은 외부 클라이언트의 요청을 받는 첫 관문이며, 해당 레이어에서는 요청에 대한 유효성 검사 및 응용 레이어 호출을 위한 객체 생성 및 변환 작업이 주로 이뤄진다.
응용 레이어는 도메인 서비스를 호출하며 대부분의 경우 응용 서비스에 대한 트랜잭션이 시작되는 지점이다. 도메인에 필요한 구현을 직접 수행하진 않으며, 도메인 영역의 객체에 이를 위임하게 된다
도메인 레이어는 도메인에 필요한 데이터를 표현하고 도메인과 관련된 구현을 담당하게 된다.
인프라스트럭쳐 레이어는 실제 구현을 담당하게 되는데, 구현 기술과 아주 밀접한 연관이 있는 레이어이다. 응용 레이어 및 도메인 레이어는 구현기술과 관련된 부분은 인프라스트럭처 레이어에 의존하게 된다.

각 계층은 표현 -> 응용 -> 도메인 -> 인프라스트럭쳐 순으로 의존하게 하게 되지만, 구현의 편리함을 위하여 응용 -> 인프라스트럭쳐 혹은 도메인 -> 인프라스트럭쳐를 참조하는 방식으로 의존할 수도 있다.

응용, 도메인 계층이 직접적으로 인프라스트럭처 레이어에 의존적이게 되면 실제 구현 부분에 대한 변경이 어려워지며, 테스트하기 어려워지는 문제점이 발생하게 된다. DIP를 이용하면 저수준의 구현 모듈이 고수준의 모듈에 의존하도록 변경하여 위에서 발생하는 문제를 해결할 수 있는 실마리를 제공해준다.

DIP

객체지향 원칙 SOLID에서의 DIP
추상을 매개(인터페이스)로 메시지를 주고 받음(메서드 호출)으로써 관계를 최대한 느슨(인터페이스를 사용함에 따라 구현에 대한 변경이 용이)하게 만드는 원칙

나무위키, 객체 지향 프로그래밍 원칙 중 DIP

Nextree, DIP

DIP를 적용하게 되면 아래와 같이 구현 기술과 관련된 종속성을 쉽게 제거할 수 있는데, 저수준의 모듈이 고수준의 모듈을 참조하도록 구성하는 방법. 즉 인터페이스를 참조하게 되면 실제 인터페이스의 구현 부분에서 사용하는 구현 기술이 어떤 종류의 것인지와 상관없이 도메인에서 필요한 기능 자체에만 집중한 표현이 가능하다.

graph LR CalculateDiscountService --> RuleDiscounter RuleDiscounter --> RDB/JPA RuleDiscounter --> SearchEngine

위 이미지에서 볼 수 있듯이 실제 구현이 RDB로 되어 있던지, 검색엔진을 통하여 되어 있던지 이는 중요하지 않고 실제 구현하고자 하는 가격할인이라는 목적에만 집중 할 수 있다.
인터페이스를 사용함에 따라 실제 테스트 코드 작성 시, 쉽게 목(Mock) 구현을 할 수 있으며 또한 구현 변경에 따른 부담이 줄게 될 것이다.

위 설명에서 말하는 저수준과 고수준을 나누는 기준은 구현 기술에 좀 더 특화되어 있는 모듈이라면 저수준으로 판단하며, 응용 혹은 도메인 영역에서 사용하는 모듈은 고수준으로 분류한다.
실제 도메인에서 표현하는 추상화 된 응용 혹은 도메인 계층을 고수준의 모듈이라고 보는 것이 타당하다고 생각한다. 다시 말해, 실제 도메인이 해결해야 할 문제에 대한 추상화가 이뤄지는 구간정도로 요약하면 좋을꺼 같다.

DDD Start 59P 중 일부
인프라스트럭처에 위치한 클래스가 도메인이나 응용 영역에 정의한 인터페이스를 상속받아 구현하는 구조가 되므로 도메인과 응용 영역에 대한 영향을 주지 않거나 최소화하면서 구현 기술을 변경하는 것이 가능하다.

도메인 영역의 구성요소는?

요소	설명
엔티티	식별자를 가지는 객체. 라이프 사이클을 가진다.
벨류	완전한 하나의 값을 표현. 도메인의 속성을 표현하는 목적으로 주로 사용한다.
애그리거트	연관 객체의 집합을 가리킨다. 다시 말해, 관련된 엔티티와 벨류 객체를 개념적으로 하나로 묶어 놓은 것이다.
레파지토리	도메인 모델의 영속성을 처리한다.
도메인 서비스	특정 엔티티에 종속적이지 않은 도메인의 로직을 제공

위에서 설명한 내용을 간단하게 패키지 구조로 표현하면 아래와 같이 표현할 수 있다.

|-- order
    |-- domain
        |-- Order(Aggregate, Root-Entity)
        |-- OrderLine(Entity)
        |-- Orderer(Entity)
        |-- OrderRepository(Repository)
        |-- Address(Value)

DB 테이블의 엔티티 vs 도메인 모델의 엔티티
가장 큰 차이점은 바로 도메인 모델 엔티티는 데이터와 도메인의 기능을 함께 표현하는 것이다. 테이블의 엔티티는 말 그대로 테이블의 데이터만을 표현하게 되는데, 비슷하면서 미묘하게 다른 지점이 생기는데, 여기서 반드시 중심을 잡고 알아야 할 사실은 바로 도메인 모델은 데이터와 도메인의 기능을 함께 표현한다는 점이다.

도메인 모델의 엔티티를 집중하여 살펴보면 위에서 말한대로 도메인의 데이터 담고 있으며 또한 도메인의 관점에서 기능을 구현해놓은 객체이다. 데이터에 대한 변경을 철저하게 도메인 관점에서 구현해야 하며 임의로 해당 엔티티의 상태 값이 변경되도록 하면 안된다. 이를 달성하기 위해서는 아래와 같은 점을 명심하면 좋을거 같다.

세터(setter)의 지양, 무분별한 상태 변경은 지양해야 하며, 객체의 세터를 만들더라도 private 접근자를 할당하며 외부에서 접근이 안되도록 해야 한다.
도메인 엔티티 생성 시, 정적 팩토리 매서드 혹은 팩토리 클래스를 사용, 도메인 객체의 생성은 반드시 완전한 상태로 이뤄져야 한다. 객체의 생성 규칙 일정하다면 정적 팩토리 메서드를 활용하는 방법이 좋고, 만약 객체를 생성하는 규칙이 다양하면 별도의 팩토리 클래스를 구현하는 방법도 좋다.
의미 혹은 개념적으로 하나로 표현할 수 있는 상황이라면 벨류(Value) 객체를 적극적으로 활용하는게 좋다. 이에 대한 구현은 불변(Immutable)한 접근을 통하여 객체 자체를 완전히 교체하는 전략을 취하자

애그리거트(Aggregate)

비슷한 도메인 모델을 상위 수준에서 접근. 다시 말해, 연관/관련 객체를 하나로 묶은 군집.
예를 들어, 주문이라는 도메인 모델은 배송지, 주문자, 주문 목록 등의 하위 모델로 구성되는데 이 모든 모델을 하나의 군집 형태로 표현하여 주문이라는 상위 개념으로 표현할 수 있게 된다.
애그리거트는 연관된 객체/도메인 모델을 관리하는 루트 엔티티를 가지게 되는데, 루트 엔티티는 연관 객체와 벨류 등을 사용하여 도메인에서 표현해야 할 혹은 구현해야 할 기능을 제공하게 된다.
하위 객체 혹은 벨류에 대한 접근은 루트 엔티티를 통하여 간접적으로 이뤄져야 하며, 실제 구현을 내부로 숨길 수 있게 됨에 따라 애그리거트 단위로 캡슐화할 수 있도록 돕는다.

레파지토리(Repository)

구현을 위한 도메인 모델로 도메인 객체를 영속성 있게 즉, 지속적으로 사용하려면 별도의 보관이 필요하게 된다. 이런 보관을 위하여 존재하는 것이 바로 레파지토리이다.
저장은 주로 RDB, NoSQL 등의 구현 기술을 사용하게 된다.
주로, 에그리거트 단위로 객체를 저장하고 조회하는 기능을 구현하게 된다.
레파지토리 인터페이스는 주로 도메인 영역에 속하게 되며, 해당 인터페이스의 구현체는 실제 구현 기술을 사용하게 됨에 따라 인프라스트럭처 영역에 속하게 된다.
응용영역과 밀접한 관련이 있으며, 응용 영역에서는 필요한 도메인 객체를 조회하거나 저장 할때 레파지토리를 참조하게 된다. 또한, 응용 영역의 트랜잭션 관리는 레파지토리를 구현하는 기술에 영향을 받을 수 밖에 없다.

인프라스트럭처

표현, 응용, 도메인을 영역을 지원하는 역할을 수행
위에서 설명한 DIP처럼, 인프라스트럭처 레이어의 기능을 바로 사용하는 것이 아니라 인터페이스를 통하여 참조/구현하는 것이 테스트 하기 쉽게 만들어주며 변경에 용이하게 해준다.

모듈 구성/패키지 구조는?

영역별로 구성

응용/도메인 모듈에서는 연관 서비스/엔티티끼리 묶어서 다시 패키징을 할 수 있다.

|-- presentation
|-- domain
    |-- order
    |-- member
|-- application
    |-- order
    |-- member
|-- infrastructure

도메인별로 구성

도메인이 크다면 서브 도메인(하위 도메인)별로 나뉘는 전략

|-- order
    |-- presentation
    |-- domain
    |-- application
    |-- infrastructure
|-- member
    |-- presentation
    |-- domain
    |-- application
    |-- infrastructure

Spring 프로젝트에서의 일반 구조는?

위에서 정리한 패키지 구조/명칭을 그대로 따라는 것도 좋은 접근이지만 여태까지 겪어봤던 구조도 한번 다시 정리해보는 것이 좋을거 같아 아래에 기술해봤다.

레이어 패키지 단위 구조

레이어 단위로 구성하는 방법
개인적으로 적절한 팀에서의 가이드가 존재하지 않는다면 선호하지 않는 방법이다. 왜냐하면, 무분별한 DI가 쉽게 발생 할 수 있으며, 각 레이어에서 개별 모듈이 관심사가 다른 레이어의 모듈이나 객체를 쉽게 참조할 수 있게 되기 때문이다.

|-- controller
|-- service
|-- repository
|-- model
|-- config
|-- Application.java

도메인 단위의 패키지 구조

관심 도메인별로 패키지 구조를 작성
위에서도 언급한 내용대로 개별 도메인별로 타입의 개수가 늘어나거나 관심사별로 다시 분리해야 할 경우 도메인 패키지내에서 다시 분리하는 전략도 취해볼 수 있다.

|-- order
    |-- OrderController.java
    |-- OrderService.java
    |-- OrderRepository.java
    |-- Order.java
    |-- OrderLine.java
    |-- Orderer.java
|-- member
|-- config
|-- Application.java

결국 레이어 단위로 두느냐 아니면 도메인 단위로 두느냐는 같이 프로젝트를 수행하는 구성원들의 호불호에 의해서도 달라질 수 있고, 도메인별로 상호간에 참조가 아예 안되는 상황인지 아닌지 유무도 중요하게 된다. 무분별하게 어떤 접근이 맞다는 의견보다는 상황과 요구사항 그리고 팀원들의 이해도에 집중하여 접근하는 것이 중요하다고 할수 있다.

DDD - #1 도메인

oh-yes — Sat, 8 Jun 2019 20:54:25 +0900

DDD_#1

DDD Start의 1장 내용을 정리

도메인

소프트웨어로 해결하려고 하는 문제의 영역.

하나의 도메인은 다시 하위 도메인으로 나눌 수 있는데, 이렇게 나눠놓은 하위 도메인끼리 연동하여 완전한 기능을 제공하게 된다.
이렇게 문제의 영역을 해결하는 과정에서 꼭 모든 기능을 소프트웨어로 구현해야 할 필요는 없다. 즉, 해당 도메인에서 필요한 기능을 외부 업체 또는 기능을 활용하여 연동 할 수도 있다.

도메인 모델

문제 영역을 개념적으로 표현

도메인에 대한 모델을 여러 이해 당사자가 이해할 수 있는 개념적 모델링을 할 수 있다.
- 단순히 구현 수준에서의 모델이 아닌, 여러 이해 당사자가 이해할 수 있는 모델로서 작성하는 것이 의미가 있다.
표현하는 방법은 해당 도메인에 따라, 달라질 수 있다
- UML, 그래프 등 가장 상황에 알맞는 표현을 사용하는 것이 좋다.
구현 모델은 개념 모델과 달라질 수 있는데, 개념 모델을 최대한 따르도록 작성하는 것이 좋다.

도메인은 여러 하위 도메인으로 구성 될 수 있는데, 하위 도메인이 다루는 영역별로 같은 혹시 비슷한 용어도 다르게 해석될 수 있다. 다시 말해, 여러 하위 도메인을 하나의 표현 모델로 모델링하면 혼선이 발생할 수 있기 때문에 좋지 않은 방법이라고 할 수 있다.

도메인 모델 패턴

표현(Presentation)
사용자의 요청을 처리, 여기서 사용자는 실 사용자 혹은 외부 시스템이 될 수도 있다.
응용(Application)
요청 받은 기능을 실행, 업무 로직을 직접 구현하지 않으며, 도메인 계층을 조합하여 기능을 실행
도메인(Domain)
도메인을 규칙을 실행
인프라스트럭쳐(Infrastructure)
저수준에서의 즉, 데이터베이스 혹은 메시징과 같은 시스템 종속적인 부분을 처리

엔티티/벨류

엔티티와 벨류를 제대로 구분해야 도메인을 올바르게 설계하고 구현할 수 있기 때문에 구분하여 사용하는 것은 매우 중요하다.

엔티티

class Order(
	val orderNumber: String, // 식별자
	...
)

고유의 식별자를 가진다.
- 식별자를 위한 고유의 벨류 값을 만들어서 사용 할수도 있다.
엔티티의 식별자를 생성하는 시점은 도메인의 특징 혹은 사용하는 기술에 따라 달라질 수 있다.
- 도메인의 유의미한 규칙을 사용
  - 비슷한 도메인 상황이더라도, 사용하는 식별자 생성 규칙이 달라질 수 있다.
- UUID
- 값을 직접 입력
  - 회원가입에서 사용하는 이메일 혹은 아이디일 경우
- 일련번호 사용
  - 데이터베이스의 시퀀스(오라클 등) 혹은 자동증가 값을 사용하는 경우

벨류

class OrderLine(
	var product: Product,
	var price: Int,
	var quantity: Int,
	var amounts: Int
)

값을 표현하는 클래스/객체로서 개념적으로 완전한 하나를 표현할 떄 사용
일반적으로 하나 이상의 필드/멤버 값을 포함하는 경우가 많으나, 반드시 하나 이상을 포함해야 하는 것은 아니다. 의미를 좀 더 명확하게 사용하기 위해 사용하는 경우도 있다. 또한, 벨류 타입을 위한 기능을 추가할 수 도 있다.
벨류 객체의 데이터를 변경 할때는 기존 데이터를 변경하는 방식(세터를 이용하는 방식 등)보다는 새로운 벨류 객체를 생성하는 방식을 선호한다.(Immutable한 접근)

세터를 이용하는 방식을 사용할 경우, 참조 투명성과 관련된 문제가 생길 수 있다. 즉, 참조 값이 바뀌지 않은 상태에서 상태 값에 대한 변경이 의도하지 않은 상황에서 생길 수 있다.

도메인 모델에 세터를 사용하지 않기

세터를 사용하는 방식은 도메인의 핵심 개념이나 의도를 명확하게 표현하기 힘들게 한다
도메인 객체를 생성하는 시점에 완벽한 상태가 아닐 수 있게 되므로, 잠정적인 에러 가능성을 가질 수 밖에 없다.
이를 막기 위해서는, 객체를 생성하는 시점에 완벽한 상태 값을 주입해주는 것이다. 즉, 생성자 혹은 팩토리 매소드 등을 활용하여 필요한 객체 혹은 데이터를 모두 받아야 한다.

class Order private constructor (
	val orderNumber: OrderNo,
	val totalAmount: Money,
	val shippingInfo: ShippingInfo
	val orderLine: List<OrderLine>,
	val orderState: OrderState = OrderState.PAYMENT_WAITING,
	val createdAt: LocalDateTime = LocalDateTime.now(),
	val updatedAt: LocalDateTime = LocalDateTime.now()
) {
	companion object {
		fun create(
			orderNumber: OrderNo,
			totalAmount: Money,
			shippingInfo: ShippingInfo
			orderLine: List<OrderLine>
		) = Order(
			orderNumber = orderNumber,
			totalAmount = totalAmount,
			shippingInfo = shippingInfo,
			orderLine = orderLine,
			orderState = OrderState.PAYMENT_WAITING,
			createdAt = LocalDateTime.now(),
			updatedAt = LocalDateTime.now()			
		)
	}
}

Kotlin의 기본값 할당(Default Value Assignment)을 활용하면 필수 값과 옵션 값을 나눠서 할당 받을 수 있어서 편리하다.

도메인 용어

도메인의 용어를 코드에서 충분하게 반영하지 않으면, 개발자들은 코드에 대한 의미 해석에 부담을 주게 된다.

// 이게 뭔말이야...
emum class OrderState {
	STEP1, STPE2, STEP3 ...
}

실제 도메인에 맞는 유의미한 단어 선택을 통하여, 코드를 해석하는 과정을 줄이는 것이 중요하다. 이를 위해서는 적절한 단어 선택을 위한 이해 관계자들의 노력이 필요하다.

emum class OrderState(val statement: String) {
	PAYMENT_WAITING("입금대기"),
	PREPARING("배송준비"), 
	SHIPPED("출고"), 
	DELIVERING("배송중"), 
	DELIVERY_COMPLETED("배송완료")
}

20190603

oh-yes — Mon, 3 Jun 2019 22:50:07 +0900

20190603

1. H2 데이터베이스 사용 중 소소한 삽질

신규 서비스 API 개발에 H2 데이터베이스를 적극적으로 사용하고 있는데, 컬럼명에 예약어를 사용하여 생각보다 오랜 시간 삽질을 하게 되었다. 실제 에러 스택트레이스에 예악어라는 메세지가 보이질 않아서 더 해맨 부분도 있었던거 같다.

Keywords / Reserved Words

2. DDD 1장 ~ 2장 학습

DDD Start 책을 읽으면서 내용을 계속 정리하고 있다. 책이 참 좋다고 생각이 들었는데, 실제 구현 코드도 같이 예제 형식으로 보여주고 있어서 실제 JPA-Hibernate를 주로 사용하는 나로서는 참 공감이 가면서도 부족한 부분이 무엇인지 정확하게 알게 해주는거 같아 좋았다.

엔티티 vs 벨류
무분별한 세터는 무조건 지양
의미 있는 도메인 용어 선정 그리고 이를 코드에 충분히 표현
계층 구조 아키텍처
DIP
도메인 영역의 주요 키워드
- 엔티티
- 벨류
- 애그리거트
- 레파지토리
- 도메인 서비스

일단 공부한 내용이라 키워드 위주로 나열해봤는데, 기존 코드에 대한 리팩토링을 진행하면서 책에서 봤던 내용을 일부 적용해보면 좀 더 의미 있는 접근이 가능할거 같아 나름 수확이 있다고 생각하고 있다 😃

20190528

oh-yes — Tue, 28 May 2019 21:27:35 +0900

20190528

1. @Transactional

회사 업무 중, 테스트 환경에서 적절하게 @Transactional을 부여하지 못해서 실수한 부분이 있어서 메모하려고 한다.

Repository를 의존하고 있는 서비스 레이어에서 명시적으로 @Transactional을 서비스 매서드에 마킹 해놓지 않은 상태에서 해당 서비스 메서드의 호출이 종료된 시점에 @OneToMany(FetchType.Lazy)로 마킹된 하위 모델 엔티티가 조회를 시도하게 되면서 생기는 문제였다.

기본적으로 Data JPA에서의 Repository는 CRUD 오퍼레이션에 대해 트랜잭션을 가져가게 되는데, 문제가 되는 상황은 엔티티에서 FetchType.Lazy를 사용했을 때, 즉 지연 로딩을 사용할 때가 문제가 되는 듯 했다. 만약 레파지토리에서의 트랜잭션을 재정의하고 싶다면 아래와 같이 재정의를 하면 되고, 또한 readOnly 와 같은 속성을 사용하여 Replication 구조상에서 해당 트랜잭션이 Read Replication을 참조하도록 변경하는 것도 가능하다.

public interface UserRepository extends CrudRepository<User, Long> {

  @Override
  @Transactional(timeout = 10)
  public List<User> findAll();
}

또한, 만약 클래스 레벨에서의 @Transactional의 속성 값이 readOnly=true로 지정되어 있고, 매서드가 READ 오퍼레이션이 아닌 CUD 오퍼레이션을 취한다면 아래와 같이 @Modifying을 붙여서 트랜잭션을 재정의 하는 것이 가능하다고 한다.

@Transactional(readOnly = true)
public interface UserRepository extends JpaRepository<User, Long> {

  List<User> findByLastname(String lastname);

  @Modifying
  @Transactional
  @Query("delete from User u where u.active = false")
  void deleteInactiveUsers();
}

@JsonView와 @JsonFilter를 사용하여 Partial response 구현하기

oh-yes — Mon, 27 May 2019 09:33:17 +0900

PartialReseponse

@JsonView와 @JsonFilter를 사용하여 Partial response 구현하기

개요

JSON HTTP API를 구현할 때, 페이징만 구현하는 경우를 쉽게 볼 수 있는데, 여기서 한 걸음 더 나아가 조금 더 나은 퍼포먼스를 위하여 클라이언트가 필요한 필드만 골라서 받을 수 있도록 구현하는 것이 필요할 수 있다. 예를 들어 아래와 같은 상황을 예를 들어 볼 수 있다.

HTTP Reqeust

HTTP/1.1 GET /books/1?fields=isbn,title

HTTP Response

{
    "isbn": "978-3-16-148410-0",
    "title": "Book Title"
}

책 데이터를 조회하는 JSON API가 있다고 했을 때, 헤당 API에서 제공하는 정보 중 일부 정보만을 클라이언트에서 필요한 경우에 fields 쿼리스트링에 필요한 키 값을 콤마 베이스로 나열하여 요청하는 예시이다. 클라이언트가 필요한 응답만을 제공하는 동시에 조금 더 나은 네트워크 레벨에서의 퍼포먼스를 가져갈 수 있다. 이런 부분적인 응답 값을 반환하는 것을 Partial Response라고 부르며 REST와 관련된 문서에서 심심찮게 발견할 수 있는 내용이다.

구현하는 언어와 환경에 따라 이를 구현하는 방법에는 차이가 존재하는데, 일반적으로 Spring Framework, Boot 환경에서는 JSON 데이터에 대한 처리를 GSON 혹은 Jackson 라이브러리가 담당하게 되는데 그 중에서도 Jackson을 사용하는 환경에서 간단하게 partial response를 구현하는 예제를 작성해보려고 한다.

개발 환경

Kotlin 1.3.31
Spring Boot 2.1.5 RELEASE
- WEB

1. @JsonView를 사용한 예제

@JsonView 어노테이션을 활용하면 계층적인 부분 렌더링이 가능하다. @JsonView에 대한 계층 정의 예와 유저에 대한 예제 엔티티는 아래와 같다.

interface Views {
    interface List
    interface Get: List
}

class User(
    @JsonView(Views.List::class)
    val id: UUID = UUID.randomUUID(),
    @JsonView(Views.List::class)
    val email: String,
    @JsonView(Views.List::class)
    val name: String,
    @JsonView(Views.Get::class)
    val createdAt: LocalDateTime = LocalDateTime.now(),
    @JsonView(Views.Get::class)
    val updatedAt: LocalDateTime = LocalDateTime.now()
)

위와 같이 선언할 경우, @JsonView(Dto.Views.List::class)로 데이터를 처리하게 되면 모든 데이터를 유저 엔티티에서 id, email, name만을 Jackson 라이브러리가 serialize하게 된다. 반대로, @JsonView(Dto.Views.Get::class)으로 지정해놓게 되면 유저 엔티티의 모든 데이터가 serialize된다.

Spring Mvc에서는 요청 컨트롤러 매핑 메서드에 @JsonView를 명시해주면 해당 뷰로 Serailize 할 수 있도록 지원하고 있다.

@RestController
@RequestMapping
class BookController {
    private companion object {
        val user = Dto.User(
            name = "Park",
            email = "park@gmail.com"
        )
    }

    @GetMapping("/get")
    @JsonView(Dto.Views.Get::class)
    fun jsonViewGet() = user

    @GetMapping("/list")
    @JsonView(Dto.Views.List::class)
    fun jsonViewList() = listOf(user)
}

@JsonView를 통하여 제대로 결과가 반환되는지 테스트 코드를 간단하게 작성해보면 아래와 같다. 테스트코드는 스프링 부트의 통합테스트 환경을 그대로 사용했으며, jsonPath 라이브러리를 사용하여 해당 키 값이 제대로 존재하는지 그리고 타입이 정확한지 유무까지 테스트를 해봤다.

테스트코드

@RunWith(SpringRunner::class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
class MvcJacksonviewApplicationTests {

    @Autowired
    private lateinit var mockMvc: MockMvc

    @Test
    fun `JsonView_Get_Test`() {
        mockMvc.perform(
            get("/get")
        )
        .andDo(print())
        .andExpect(status().isOk)
        .andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8))
        .andExpect(jsonPath("id").exists())
        .andExpect(jsonPath("id").isString)
        .andExpect(jsonPath("email").exists())
        .andExpect(jsonPath("email").isString)
        .andExpect(jsonPath("name").exists())
        .andExpect(jsonPath("name").isString)
        .andExpect(jsonPath("createdAt").exists())
        .andExpect(jsonPath("createdAt").isString)
        .andExpect(jsonPath("updatedAt").exists())
        .andExpect(jsonPath("updatedAt").isString)
    }

    @Test
    fun `JsonView_List_Test`() {
        mockMvc.perform(
            get("/list")
        )
            .andDo(print())
            .andExpect(status().isOk)
            .andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8))
            .andExpect(jsonPath("[0].id").exists())
            .andExpect(jsonPath("[0].id").isString)
            .andExpect(jsonPath("[0].email").exists())
            .andExpect(jsonPath("[0].email").isString)
            .andExpect(jsonPath("[0].name").exists())
            .andExpect(jsonPath("[0].name").isString)
            .andExpect(jsonPath("[0].createdAt").doesNotExist())
            .andExpect(jsonPath("[0].updatedAt").doesNotExist())
    }

    @Test
    fun `JsonFilter_single`() {
        mockMvc.perform(
            get("/json-filter")
                .param("fields", "isbn")
        )
            .andDo(print())
            .andExpect(status().isOk)
            .andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8))
            .andExpect(jsonPath("isbn").exists())
            .andExpect(jsonPath("isbn").isString)
            .andExpect(jsonPath("title").doesNotExist())
            .andExpect(jsonPath("content").doesNotExist())
            .andExpect(jsonPath("createdAt").doesNotExist())
            .andExpect(jsonPath("updatedAt").doesNotExist())
    }
}

2. @JsonFilter를 사용하는 예제

위에서 본 @JsonView의 경우, 딱 지정해놓은 계층 구조 혹은 뷰가 아닐 경우 필드에 대한 선택 자체가 불가능하다. 결국 서버 어플리케이션에서 정해놓은 구조로만 부분 뷰를 응답 받을 수 있는 구조인데, 실제 요청에 부합하는 응답 값만 전달하기 위해서는 Jackson의 @JsonFilter 어노테이션과 Spring MVC의 MappingJacksonValue를 활용하면 해당 구현이 가능하다.

@JsonFilter("bookFilter")
class Book (
    val isbn: String,
    val title: String,
    val content: String,
    val createdAt: LocalDateTime = LocalDateTime.now(),
    val updatedAt: LocalDateTime = LocalDateTime.now()
)

class GetReq {
    var fields: List<String> = emptyList()
}

@RestController
@RequestMapping
class BookController {
    private companion object {
        val book: Dto.Book = Dto.Book(
            isbn = UUID.randomUUID().toString(),
            title = "Title",
            content = "Content"
        )
    }

    @GetMapping("/json-filter")
    fun jsonFilter(reqDto: GetReq) = MappingJacksonValue(book).apply {
        filters = SimpleFilterProvider().also {
            it.addFilter("bookFilter",
                if (reqDto.fields.isNotEmpty()) SimpleBeanPropertyFilter.filterOutAllExcept(reqDto.fields.toSet())
                else SimpleBeanPropertyFilter.serializeAll()
            )
        }
    }
}

테스트코드

@RunWith(SpringRunner::class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
class MvcJacksonviewApplicationTests {

    @Autowired
    private lateinit var mockMvc: MockMvc

    @Test
    fun `JsonFilter_single`() {
        mockMvc.perform(
            get("/json-filter")
                .param("fields", "isbn")
        )
            .andDo(print())
            .andExpect(status().isOk)
            .andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8))
            .andExpect(jsonPath("isbn").exists())
            .andExpect(jsonPath("isbn").isString)
            .andExpect(jsonPath("title").doesNotExist())
            .andExpect(jsonPath("content").doesNotExist())
            .andExpect(jsonPath("createdAt").doesNotExist())
            .andExpect(jsonPath("updatedAt").doesNotExist())
    }

    @Test
    fun `JsonFilter_comma_separator`() {
        mockMvc.perform(
            get("/json-filter")
                .param("fields", "isbn,title")
        )
            .andDo(print())
            .andExpect(status().isOk)
            .andExpect(content().contentType(MediaType.APPLICATION_JSON_UTF8))
            .andExpect(jsonPath("isbn").exists())
            .andExpect(jsonPath("isbn").isString)
            .andExpect(jsonPath("title").exists())
            .andExpect(jsonPath("title").isString)
            .andExpect(jsonPath("content").doesNotExist())
            .andExpect(jsonPath("createdAt").doesNotExist())
            .andExpect(jsonPath("updatedAt").doesNotExist())
    }
}

간단하게 @JsonView와 @JsonFilter를 사용하여 partial response에 대한 구현을 해볼 수 있었는데, 여기서 조금 더 나아가 복잡한 조건이나 구조에서의 구현이 필요할 경우 Squiggly Filter와 같은 구현체를 사용하는 것도 좋은 선택이 될 수 있을거 같다.

예제는 링크를 통하여 확인 가능합니다.

참고

20190526

oh-yes — Sun, 26 May 2019 21:15:44 +0900

20190526

1. Rx에 대한 공부 일단 중지!

최근 약 한달 가량 틈틈히 Rx에 대한 공부를 지속해왔다. 결론부터 말하자면 당분간은 Rx가 아닌 다른 공부에 집중해야 할거 같다. 물론 Rx 자체도 쓰임새가 무척 좋은 생태계라는 점은 부정 할 수 없다. 하지만, 당장 모자란 기본에 대한 공부나 업무와 관련된 학습에 좀 더 투자하는 것이 앞으로 더 크게 도움이 되리라 생각했다. 그만 두는 이유를 간단하게 써보면 아래와 같다.

RDB에 대한 지원 부실, 추후에 R2DBC에 대한 생태계가 충분하게 확보되면 그때 시작해도 늦지 않다고 생각했다.
Kotlin Coroutine으로도 Rx에서의 처리를 충분히 보완할 수 있다! 역시 비동기와 관련된 코드는 async~await가 최고가 아닐까라고 생각한다. coroutine 자체가 제공해주는 강력한 서포트가 있다면 굳이 Rx가 필요 없을 수 있다!

2. DDD에 대한 공부를 시작해보자

DDD Start! 1장, 도메인 모델 시작

아마 DDD를 처음 들어본건 몇 년전의 일인거 같다. 꼭 한번은 책을 읽어보고 업무에서도 어느 정도 적용을 해봐야지 하는 생각만 가지고 있었지 실제로 행동으로 옮기진 못했었다. 책은 DDD Start라는 책을 구매했고, 1장을 정독했는데 책이 어렵지 않고 잘 읽혀서 좋았다. 특히, 도메인 이라는 단어 자체에 대한 이해도가 좀 더 높아져서 좋았고 실제 이를 코드 레벨로 조금씩 구현해보는 책의 전개가 특히 맘에 들었다. 물론, 용어에 대한 정리도 잘되어 있다! 당분간은 관련 개념을 적용하여 포스팅을 작성해볼 생각이고, 이해가 안되는 부분은 별도로 자료를 찾아서 보완하는 방식으로 공부를 진행하면 좋겠다는 생각이 들었다.

MapStruct 맛보기

oh-yes — Sun, 26 May 2019 20:58:18 +0900

mapStruct

Summary & Why?

타입 세이프하게 bean 매핑을 도와주는 어노테이션 프로세서
보통 JPA 기반의 어플리케이션을 개발하게 되면 만나게 되는 DTO 변환 작업은 대부분이 반복적인 작업이 대부분
ModelMapper와 같은 매핑 구현체가 존재하지만, ModelMapper의 경우 리플렉션 기반으로 동작하기도 하고 퍼포먼스에 대한 이슈가 많은편
도메인 객체를 풍부하게 사용하면서, 반환 데이터가 달라지게 될 경우 이를 적절하고 큰 힘을 들이지 않고 매핑할 수 있도록 도와주는 것이 바로 mapStruct
mapStruct 역시 메뉴얼에서 확인할 수 있듯이, 편하게 사용하려면 어느정도의 학습 기간을 거쳐야 편하게 사용할 수 있는듯하다.

Simple Usage

개발 환경

Kotlin 1.3.31
Spring BOOT 2.1.5 RELEASE(WEB, DATA-JPA)
H2

import org.jetbrains.kotlin.gradle.tasks.KotlinCompile

plugins {
    val kotlinVersion = "1.3.31"
    id("org.springframework.boot") version "2.1.5.RELEASE"
    id("io.spring.dependency-management") version "1.0.7.RELEASE"
    id("org.jetbrains.kotlin.jvm") version kotlinVersion
    id("org.jetbrains.kotlin.plugin.spring") version kotlinVersion
    id("org.jetbrains.kotlin.plugin.jpa") version kotlinVersion
    id("org.jetbrains.kotlin.kapt") version kotlinVersion
}

group = "me.daniel"
version = "0.0.1-SNAPSHOT"
java.sourceCompatibility = JavaVersion.VERSION_1_8

repositories {
    mavenCentral()
}

noArg {
    annotation("javax.persistence.Entity")
    annotation("javax.persistence.MappedSuperclass")
    annotation("javax.persistence.Embeddable")
}
allOpen {
    annotation("javax.persistence.Entity")
    annotation("javax.persistence.MappedSuperclass")
    annotation("javax.persistence.Embeddable")
}

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-data-jpa")
    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation("com.fasterxml.jackson.module:jackson-module-kotlin")
    implementation("org.jetbrains.kotlin:kotlin-reflect")
    implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
    runtimeOnly("com.h2database:h2")
    testImplementation("org.springframework.boot:spring-boot-starter-test")
    // map-struct
    // map-struct Annotation Processor
    implementation("org.mapstruct:mapstruct:1.3.0.Final")
    kapt("org.mapstruct:mapstruct-processor:1.3.0.Final")
    kaptTest("org.mapstruct:mapstruct-processor:1.3.0.Final")

}

tasks.withType<KotlinCompile> {
    kotlinOptions {
        freeCompilerArgs = listOf("-Xjsr305=strict")
        jvmTarget = "1.8"
    }
}

@Mapper
interface UserMapper {
    fun toUser(req: CreateDTO): User
    fun fromUser(user: User): ResponseDTO
}

kapt를 활용하여 매퍼 클래스에 대응하는 Java 구현체를 생성해주는데, 도메인 객체와 DTO 객체간의 1:1 매핑을 지원하며, 1:1 매핑이 원활하게 되기 위해서는 Source 쪽의 타입 선언와 Target쪽의 타입 선언이 똑같아야 자연스럽게 매핑을 처리할 수 있다.

@Mapper
public interface AddressMapper {

    @Mapping(source = "person.description", target = "description")
    @Mapping(source = "address.houseNo", target = "houseNumber")
    DeliveryAddressDto personAndAddressToDeliveryAddressDto(Person person, Address address);
}

1:1 매핑이 아니라고 추가적인 매핑을 진행해야 하는 경우, 위와 같이 매핑에 대한 룰을 지정해주면 된다.

@Mapper(componentModel = "spring")
interface UserMapper {
    @Mapping(source = "roles", target = "_roles", qualifiedByName = ["toUserRole"])
    fun toUser(req: CreateDTO): User
    fun fromUser(user: User): ResponseDTO

    @Named("toUserRole")
    fun toUserRole(roles: List<UserRole.Role>) = roles.map {
        UserRole().apply {
            this.role = it
        }
    }
}

추가적인 매핑말고도 조금 복잡한 매핑 룰이 필요한 경우 인터페이스의 default 메서드를 선언하여 이를 활용할 수 있다.(코틀린에서는 바로 method를 선언해두면 이게 default 메서드 역할을 수행해준다.) 이 때 사용하는 어노테이션이 바로 @Named 어노테이션으로 선언해놓은 값을 qualifiedByName에 매핑해주면 된다.
생성한 매퍼에 대해 컴포넌트 모델을 지정 할 수 있다.
- default: 컴포넌트 모델을 생성하지 않으며, Mappers#getMapper(Class)로 선언해두었던 매퍼 인터페이스의 타입으로 객체를 가져올 수 있다.
- spring, jsr330: 컴포넌트 모델을 스프링 어플리케이션 컨텍스트에서 컴포넌트 스캔을 통하여 DI 받을 수 있다. 실제 선언해둔 코드 일부를 살펴보면 아래와 같다.
- cdi

Tip & 사용 시 주의점

source측과 target측의 클래스 선언에서 기본 생성자가 반드시 선언되어 있어야 한다.
Kotlin, SpringBoot, Data-JPA와 함께 사용하게 될 경우, kotlin-jpa 플러그인을 활용하여 no-argument-consturctor에 대해 코드를 생성해주는 방식으로 기본 셋팅을 해놓고 진행하는데, 기본 생성자에 대해 바이트코드 레벨에서 Generation을 해주기 때문에 결국 기본 생성자를 명시적으로 선언해줘야 하는 불편함이 존재하는거 같다.

@Entity(name = "T_USER")
class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    var id: Long = 0L

    @Column(name = "name", length = 20)
    var name: String = ""

    @Column(name = "email", length = 100)
    var email: String = ""

    @Column(name = "gender", length = 10)
    var gender: UserGender = UserGender.MALE

    @OneToMany(mappedBy = "user", cascade = [CascadeType.ALL], fetch = FetchType.LAZY)
    @BatchSize(size = 30)
    var _roles: MutableList<UserRole> = mutableListOf()

    @Column(name = "foreigner", length = 10)
    var foreigner: Boolean = false

    @CreatedDate
    @Column(name = "createdAt", columnDefinition = "DATETIME")
    var _createdAt: LocalDateTime = LocalDateTime.now()

    @LastModifiedDate
    @Column(name = "updatedAt", columnDefinition = "DATETIME")
    var _updatedAt: LocalDateTime = LocalDateTime.now()

    enum class UserGender {
        MALE, FEMALE
    }

    constructor(name: String = "", email: String = "") {
        this.name = name
        this.email = email
    }

}

간단한 엔티티 코드 예제인데, 위 코드와 같이 별도의 생성자 선언을 안해두고 사용했을 경우 기본 생성자만 포함이 된다. 만약 별도의 생성자 선언이 필요한 경우 코드 가장 하단과 같이 필요한 선언을 해두면 되며 Kotlin의 Argument Default Value를 적극적으로 활용하여 필수 인자값과 그렇지 않은 값을 분리하는 전략을 취하는 것이 좋을거 같다.

컬럼과 매핑되는 프로퍼티가 아닌 값을 매핑하게 될 경우가 생길 수 있는데, 이럴 때 사용하면 좋은 것이 Lazy Delegate이다. 관계 매핑에 사용되는 것이 아닌 해당 도메인 객체의 상태를 유연하게 유연하게 표현할 수 있으며 바인딩한 프로퍼티를 바로 mapStruct 바인딩으로 넘길 수 있어서 실제 예제 코드를 작성해보니 편리함을 느낄 수 있었다.

class User {
    ...생략...

    @get:Transient
    @delegate:Transient
    val roles: MutableList<String> by lazy {
        this._roles.map { it.role.name }.toMutableList()
    }

    @get:Transient
    @delegate:Transient
    val createdAt: LocalDateTime by lazy {
        this._createdAt
    }

    @get:Transient
    @delegate:Transient
    val updatedAt: LocalDateTime by lazy {
        this._updatedAt
    }
}

Generation 해주는 코드는 기본적으로 세터 기반의 데이터 바인딩을 해주고 있는 것을 확인 할수 있는데,이를 빌더 기반으로 변경하는 것도 가능하다고 한다. 빌더 구현체로는 유명한 Lombok, AutoValue 등이 사용 가능하다고 메뉴얼에 명시되어 있다.
- 참고 링크
- 하지만, 코틀린 기반으로 사용하게 될 경우 보통 lombok과 같은 빌더 구현을 대체 해주는 구현이 없어서 당분간은 세터 기반의 주입을 사용해야 될듯

예제 코드는 링크를 통하여 확인 할 수 있습니다.

20190507

oh-yes — Tue, 7 May 2019 21:51:24 +0900

20190507

1. RxJava 리액티브 프로그래밍 읽기/실습

4장, RxJava 연산자

RxJava와 RxKotlin는 Reactive Stream 구현체에 해당하는 Flowable과 Observable을 생성할 수 있는 다양한 연산자를 제공하고 있는데, 생성하는 연산자뿐만 아니라 변환, 필터, 결합, 상태 통지, 집계 등의 다양한 연산자를 제공하고 있다. 다양한 연산자는 메서드 체인(MethodChain) 혹은 FluentAPI 방식으로 실제 소비자에게 전달해야 하는 최종 형태의 데이터로 쉽게 변환이 가능하다. 연산자의 종류별로 기본적으로 실행하는 스레드가 달라질 수 있으며, 이에 대한 지정은 별도 스캐줄러 지정을 통하여 변경이 가능하다.

1~3장을 통하여 Flowable/Observable을 생성하는 연산자 예제 코드를 통하여 실습을 하나도 안 빼놓고 해봐서 그런지 4장 첫 부분인 Flowable/Observable을 생성하는 연산자까지는 크게 막힘이 없었다. 변환 연산자를 다루는 부분부터 신경 써서 봐야 할 부분이 많이 보인다. 특히 flatMap 연산자를 다루는 여러 가지 방법들 그리고 concatMap과 concatMapEager의 처리 방식은 비슷하지만 내부 메커니즘은 버퍼를 사용하냐 안하냐로 생각보다 크게 다름을 알 수 있었다. 책에서 설명을 일부러 갈게 안달아 놓은 부분은 잘 안쓰이나? 이런 생각도 들었지만 어차피 한땀 한땀 예제를 작성한다고 해도 실제 업무나 코드를 작성할 때는 까먹는 일이 다반사이니 일단 예제 코드 하나씩 다 타이핑해보면서 개념이랑 감을 익히는게 중요할거 같다.

2. 테이블 설계

한 달 전에 테이블 설계를 할 일이 있어서 작성했던 스키마와 시퀀스 문서를 보면서 급함으로 발생한 오타와 실제 설계를 하면서 놓친 부분에 대해서 수정하여 github에 다시 올려두었다. plantuml을 사용하면서 느끼는 거지만, 편리하면서도 실제로 복잡한 도메인을 그릴 때는 이게 코드를 작성하는 거나 크게 다름이 없음을 매번 느끼곤 한다. 그래도 마우스로 일일이 그리는 수고를 덜어주니 그것만으로도 얼마나 감사한 일인가!

설계를 해놓고 나서 보니, 히스토리 성격의 데이터에 대해 JSON serialize 후 단일 레코드로 보관하는 설계 방법을 선택한 부분이 마음에 걸린다. 차라리, JSON 컬럼을 활용해서 써보는 건 어땠을까 하는 생각도 든다.

RxJava, RxKotlin #1 ReactiveStream/기본개념

oh-yes — Mon, 6 May 2019 18:09:40 +0900

Rx#1

Reactive Programming

데이터가 통지되면 이에 반응하여 데이터를 처리 하는 방식의 프로그래밍 모델. 즉, 프로그램에서 필요한 데이터를 직접 가지고와서 처리하는 방식(pull)이 아닌 데이터를 받은 시점에 처리하는 방식(push).
이를 구현하기 위해 데이터를 만들어내는 생산자와 이를 소비하게 되는 소비자로 역할을 나눠 처리하는 프로세스를 가지게 된다.
소비자와 생산자의 역할이 분리되어 있으므로, 생산자는 데이터를 생산하여 전달하는 역할까지 수행하며, 소비자는 데이터를 받아서 처리하는 역할만을 수행한다. 즉, 생산자와 소비자는 각각의 역할만 충실하게 수행하면 되고, 반대편에서 어떤 처리를 하는지에 대해서는 관심 밖의 일이다.

이처럼, 역할이 분리됨에 따라 쉽게 비동기 구현이 가능

Reactive Stream

데이터 스트림을 비동기로 처리 할 수 있는 공통 메커니즘/인터페이스.
Reactive Stream은 인터페이스만 제공하고 상세 구현은 각 라이브러리/프레임워크에서 책임을 가져간다.

구현체

위키피디아 참고

데이터스트림

Collection과 같이 이미 생성한 데이터를 포함하여 앞으로 생성할 데이터 혹은 발생 가능성이 있는 데이터까지 포함하는 개념.
키보드 혹은 마우스 같은 UI상에서의 이벤트가 발생 했을 때, 해당 이벤트가 발생하는 시점의 데이터까지 포함하는 개념으로 볼 수 있다.
데이터스트림의 소스 종류들은?
- SQL 쿼리들
- GUI 이벤트
- HTTP 기반 서비스
- TCP 소켓
- 파일 시스템
- Kafka같은 메시지 큐들
- 기타 등등

구성

Reactive Stream은 Publisher와 Subscriber로 구성되며, Subscriber가 Publisher를 구독하면 Publisher가 통보하는 데이터를 받을 수 있음

구독(subscribe)가 발생하면 이에 대한 Subscription이 생성된다.
Subscriber가 Publisher를 구독하지 않으면 이후 단계는 진행되지 않는다.
onComplete, onError와 같이, 확정 Action이 발생하면 소비자에게 통보한다.
Subscriber는 Publisher에게 받을 데이터 개수를 요청 할 수 있으며, 요청 받은 Publisher는 다시 데이터를 생산하여 Subscriber에게 전달(onNext)한다.
받을 데이터 개수를 요청하는 것은 생산자측의 처리 속도와 소비자측의 처리 속도가 다를 수 있기 때문에, 이를 제어 할 수 있는 적절한 수단이 필요하기 때문

표준 인터페이스

인터페이스	설명
Publisher	데이터 생성/통보
Subscriber	데이터 처리
Subscription	데이터 요청/ 구독 해지 가능
Processor	Publisher & Subscriber의 역할을 모두 가지고 있음

위 표준 인터페이스를 보면 알 수 있듯이, 분명하게 역할 분리가 되어 있음을 알 수 있다. 이는 곧 처리 단위 별로 개별 책임을 가져 갈 수 있음을 뜻함.

규칙

Reactive Stream은 인터페이스를 통하여 데이터를 통지하는 구조이며, Reactive Stream에서 정해놓은 규약을 충분하게 지켜야 구조가 제대로 동작한다.

구독 시작 통지(onSubscribe)는 구독에서 한 번만 발생
데이터 통지는 순차적으로 이뤄진다.
null을 통지하지 않는다.
Publisher는 처리 완료(onComplete) 혹은 에러(onError)를 통하여 종료한다.

[주의] 같은 인스턴스를 활용하여 구독(subscribe)를 할 경우, Publisher/Subscriber의 내부 상태를 초기화하지 않으면 의도하지 않은 결과로 이어질 수 있다. 왜냐하면, onComplete 혹은 onError의 통지가 이뤄진 이후 시점에는 Publisher는 처리가 끝마친 것으로 판단하기 때문이다.

RxJava,Kotlin에서 꼭 알아야 할 구조는?

생산자/소비자/구독

ReactiveStream 지원 유/무	생산자	소비자	관계
O	Flowable	Subscriber	Subscription
X	Observable	Observer	Disposable

지원 유무의 가장 큰 차이점은 배압(Backpressure)의 적용 유무, 배압이 적용되어 있지 않기 때문에, 별도로 소비자측에서는 데이터를 요청하지 않음. 배압 외에는 처리 모델은 거의 똑같다.

연산자

map, flatMap 및 filter 등과 같이 기존 Stream을 다루거나 함수형 라이브러리에서 제공해주는 연산자를 비슷하게 제공해주고 있음. 연산자별로 생성되는 Flowable/Observable의 성격이 상이한 부분이 존재하며, 또한 실행순서에 영향을 주는 연산자도 존재함.

순차 처리의 예

    Flowable.just(1,2,3,4,5,6,7,8,9,10)
        .filter { it % 2 == 0 }
        .map { it * 100 }
        .subscribe { println("${Thread.currentThread().name}, data: $it") }

[결과]
main, data: 200
main, data: 400
main, data: 600
main, data: 800
main, data: 1000

순차 처리가 안되는 예

Flowable.just("A", "B", "C")
	.flatMap {
		Flowable.just(it).delay(1000L, TimeUnit.MILLISECONDS)
	}.subscribe {
		println("${Thread.currentThread().name}: $it")
	}

[결과]
RxComputationThreadPool-3: C
RxComputationThreadPool-1: A
RxComputationThreadPool-1: B

비동기 처리

생산자와 소비자는 별도의 지정이 없을 경우, 메인스레드 혹은 실행 스레드에서 순차 처리 됨.

하지만 시간 관련 Flowable/Observable 생성자의 경우, 별도의 스레드에서 실행이 되는 경우도 있음. 비동기 처리를 지정해야 할 경우 생산자 측(subscribeOn())과 소비자 측(observeOn())에 스레드 스캐줄러를 지정하면 되며, 스캐쥴러(Schedulers)의 종류는 io, computation 등이 있다.

외부 자원에 대한 참조는?

생산자/소비자는 여러 스레드에서 실행이 될 수 있기 때문에, 공유 자원에 대해서 동기화 작업을 반드시 수행해줘야 한다. 이런 동기화를 피하는 가장 좋은 방법은 아래와 같다.

순수 함수(함수형 인터페이스)의 사용
- 외부 자원 참조 X
- 함수 단위로 코드를 전개하여 처리 안정성을 확보
- 불변 객체의 사용, 큰 오버헤드가 존재하지 않으면 객체는 복사를 하여 사용하는 것이 좋다.

여러 개의 생산자/소비자가 존재 할 경우는 merge등의 연산자를 통하여 해당 생산자/소비자를 실행하는 스레드가 공유 자원에 대해 동기화하여 접근 할 수 있도록 할 수 있다.

공유 자원에 대한 잘못된 접근의 예

아래의 2개의 생산자/소비자의 구조에서 2개의 소비자 모두 변수 num에 접근하여 값을 수정하고 있는데, 이는 각각의 소비자에서 스레드에 대한 적절한 동기화 없이 접근하는 안티패턴의 가장 좋은 예라고 할 수 있다.

var num = 0
Flowable.range(1, 100_000)
	.subscribeOn(Schedulers.computation())
	.observeOn(Schedulers.computation())
	.subscribe(
		{ ++num },
		{ println("에러=$it") },
		{ println("counter.get()= $num") }
	)

Flowable.range(1, 100_000)
	.subscribeOn(Schedulers.computation())
	.observeOn(Schedulers.computation())
	.subscribe(
		{ ++num },
		{ println("에러=$it") },
		{ println("counter.get()= $num") }
	)

merge 연산자를 사용한 예

위에서 보았던 안티패턴을 Rx에서는 스레드에 대한 동기화 처리를 진행해주는 merge 연산자를 사용하여 해결이 가능하다. 여러 생산자에서 발행하는 데이터의 타임라인을 하나로 만들어주며, 발행하는 순서를 아래의 그림과 같이 시간순 혹은 실행순으로 만들 수 있다.

[요약] 여러 Observable의 출력을 결합하여 단일 Observable처럼 작동하도록 할 수 있다.

var num = 0
val source1 = Flowable.range(1, 100_000)
	.subscribeOn(Schedulers.computation())
	.observeOn(Schedulers.computation())


val source2 = Flowable.range(1, 100_000)
	.subscribeOn(Schedulers.computation())
	.observeOn(Schedulers.computation())

Flowable
.merge(source1, source2)
.subscribe(
	{ ++num },
	{ println("에러=$it") },
	{ println("counter.get()= $num") }
)

Flowable vs Observable 어떤걸 써야 하는거지?

Flowable

대량 데이터를 처리 할 경우
네트워크 통신/파일 등 IO를 처리 할 경우

Observable

GUI 이벤트
소량의 데이터를 처리 할 경우
자바의 Stream을 대신하여 사용할 경우

대량의 데이터와 더불어 IO를 처리 해야 할 경우에는 Flowable을 사용하여 적절한 배압 정책을 적용하는 것이 유리하다. 반면에 GUI의 이벤트 처리 혹은 소량의 데이터를 처리 할 경우 배압이 없는 Observable을 사용하는 것이 유리하다고 한다. Observable은 배압 기능이 없는 만큼 Flowable에 비하여 오버헤드가 적은 것이 특징이다.

배압 기능을 사용하면, 쏟아지는 데이터 대한 적절한 제어 뿐만 아니라 에러 처리도 할 수 있다. 물론, 다루는 데이터의 성격에 따라 달라질 수 있는 부분이지만 생산자와 소비자간의 처리 속도 차이에 따라 발생하는 데이터 유실에 대한 부분도 반드시 고려해서 배압 정책을 적용한 코드를 작성해야 한다.

20190504

oh-yes — Sat, 4 May 2019 19:30:20 +0900

20190504

1. RxJava 리액티브 프로그래밍 읽기/실습

3장, RxJava 메커니즘

에러처리에 대한 부분부터 배압(Backpressure)까지 학습을 하였고, 에러 처리에 대한 매커니즘부터 배압까지 자연스럽게 내용이 연결되어 있어서 이해하는데에는 크게 무리가 없었다. 다만, 책을 읽으면 읽을수록 봐야 할 API와 구현체에 대한 개수가 늘어나는거 같아서, 책에서만 제공해주는 예제 외에도 실제 구현을 어떻게 하는지에 대해서는 깃헙을 돌아다니면서 코드를 좀 살펴봐야 좀 더 이해가 높아질 수 있을거 같았다.

여러개의 생산자와 소비자가 공유 객체를 가질 경우에는?
- merge 연산자를 사용하여 다수의 생산자/소비자가 순차접근을 할 수 있도록 동기화 처리 해야 한다.
에러처리
- 에러처리에 대한 통보
- 재시도(retryXX Method)
- 대체 데이터 통보(onErrorXX Method)
배압 정책/전략 지정
- Flowable/Observable 생성 시 지정
- 매소드로 지정
- 생산자측, 스캐줄러 지정 시(observeOn()) 버퍼 사이즈를 지정
배압 정책의 종류
- BUFFER
- DROP
- LATEST
- ERROR
- NONE

2. Effective-Java-3e 읽기/실습

아이템 26, Raw Type은 사용하지 말아라

제네릭을 사용했을 때, 반드시 알아야 할 개념에 대해 소개해주고 있어서, 다른 문서나 글을 읽었을 때 몰랐던 여러 개념을 파악 할 수 있어서 좋았다. 그리고 RawType의 컬렉션 사용에 대한 자바의 히스토리에 대해 알 수 있었고, 제네릭이 도입됨에 따라 가질 수 있는 컴파일 타임의 타입 안전성과 런타임에서의 타입소거 등에 대해서도 예제와 설명를 통하여 확인 할 수 있어서 좋았다. 아래는 책에 나와 있는 내용을 일부 발췌하여 나중에라도 까먹을 경우(??)에 다시 보고자 기록을 해둘려고 한다.

용어	예
매개변수화 타입(Parameterized Type)	`List<String>`
실제 타입 매개변수(Actual Type Parameter)	`String`
제네릭 타입(Generic Type)	`List<E>`
정규 타입 매개변수(Formal Type Parameter)	`E`
비한정적 타입 매개변수(Bounded Type Parameter)	`List<?>`
로우 타입(Raw Type)	`List`
한정적 타입 매개변수(Bounded Type Parameter)	`List<E extends Number>`
재귀적 타입 한정(Recursive Type Bound)	`<T extends Comparable<T>>`
한정적 와일드카드 타입(Bounded Wildcard Type)	`List<? extends Number>`
제네릭 매서드(Generic Method)	`static <E> List<E> asList(E[] a)`
타입 토큰(Type Token)	`String.class`

20190501

oh-yes — Wed, 1 May 2019 15:04:04 +0900

1. 유럽여행

3월 중순부터 4월 초까지 여행을 다녀왔었다. 1년 가까이 쌓였던 업무 관련 스트레스 때문에 쉴 타이밍이라고 생각했고, 과감하게 20여 일의 시간을 유럽여행으로 시간을 보냈다. 직업병인지는 몰라도 여행을 다니면서도 공부를 안 하면 생기는 일종의 불안한 감정 같은게 없진 않았으나, 그래도 재충전의 시간을 보내고 돌아오니 한결 마음이 가볍다.

2. RxJava, RxKotlin

여행을 다녀오고 공부의 방향성에 대해 생각을 해봤다. 부족한 기본기에 대한 공부도 중요하지만, 내가 흥미를 가지고 지속적으로 할 수 있는 공부 역시 중요하다고 생각했다. 그래서 흥미를 가질 수 있는 주제에 대해 고민을 해보다 Reactive 관련 공부를 해보는 게 좋을 거 같아서 책을 바로 구매했다.

RxJava 리액티브 프로그래밍

Kotlin을 주력으로 사용하고 있긴 하지만, 실제 JVM에서 돌아가기 때문에 자바에 대한 공부도 빼놓을 수 없다고 늘 생각해왔다. 이러한 연장선상에서 Reactive Stream 구현체인 RxJava를 공부하고 이를 확장하여 Reactor까지 공부하면 좋겠다고 생각했다.

이전에도 Rx에 대한 서적을 안 읽은 것은 아니지만, 이번에 공부하고 있는 책은 아직까지 내용이 꽤 알찬 느낌이다. Publisher/Subscriber 모델에 대한 설명도 꽤 자세하게 해주는 편이고, Reactive Stream 표준 규약부터 이를 구현한 구현체에 대한 상세한 설명까지 덧붙여주고 있어서 나 같이 이쪽 공부를 막 시작한 사람들에게는 많은 도움이 되리라 생각한다.

Spring-Boot Logging And ELK Logstash Format

oh-yes — Wed, 1 May 2019 14:42:17 +0900

SpringBoot Logger

사내에서 최근 ELK 도입을 준비하고 있는 과정에서 로깅 포맷을 지정하고 사용해야 하는 Needs가 생겨서 이번 작업을 시작하게 되었다. 스프링 부트에서는 로깅 설정을 프로파일별로 다르게 지정 할 수 있으며, 또한 로깅 구현체에 대한 유연한 변경(log4j2 등)이 가능하므로 작업 자체의 난이도가 높지는 않다고 할 수 있다.

다시 보는 로깅 레벨

출처: 구글 이미지 검색

Hibernate Logging 관련 이슈

로깅 작업 중 Hibernate 관련 로깅이 slf4j에 제대로 적용이 안되는 이슈가 생겼었다. 이와 관련된 문서를 뒤져보다 링크를 통하여 해당 문제를 해결 할 수 있었다.

링크의 내용을 요약하자면, 하이버네이트 로깅 설정이 초기화 되는 구간에서 실제 slf4j에서 사용하는 로거 설정이 적용되며 자바 프로세스 실행 시 -Dorg.jboss.logging.provider=slf4j 혹은 코드에서 System.setProperty("org.jboss.logging.provider", “slf4j") 명시적으로 slf4j를 사용하도록 설정을 해줘야지 hibernate에서 발생하는 쿼리 로깅이 slf4j를 사용하여 실행되는 것을 확인할 수 있었다.

    // LoggerProviders.class
    private static LoggerProvider findProvider() {
        final ClassLoader cl = LoggerProviders.class.getClassLoader();
        try {
            // Check the system property
            final String loggerProvider = AccessController.doPrivileged(new PrivilegedAction<String>() {
                public String run() {
                    return System.getProperty(LOGGING_PROVIDER_KEY);
                }
            });
            if (loggerProvider != null) {
                if ("jboss".equalsIgnoreCase(loggerProvider)) {
                    return tryJBossLogManager(cl, "system property");
                } else if ("jdk".equalsIgnoreCase(loggerProvider)) {
                    return tryJDK("system property");
                } else if ("log4j2".equalsIgnoreCase(loggerProvider)) {
                    return tryLog4j2(cl, "system property");
                } else if ("log4j".equalsIgnoreCase(loggerProvider)) {
                    return tryLog4j(cl, "system property");
                } else if ("slf4j".equalsIgnoreCase(loggerProvider)) {
                    return trySlf4j("system property");
                }
            }
        } catch (Throwable t) {
            // nope...
        }
        // ... 이하 생략

public void logStatement(String statement, Formatter formatter) {
    if ( format ) {
        if ( logToStdout || LOG.isDebugEnabled() ) {
            statement = formatter.format( statement );
        }
    }
    LOG.debug( statement );
    if ( logToStdout ) {
        System.out.println( "Hibernate: " + statement );
    }
}

기타 참고 링크

프로파일별 설정

Profile-specific Configuration

스프링 부트에서는 프로파일별로 로깅 설정을 지정 할수 있도록 설정 할수 있다. 프로파일별로 달라지는 설정값은 <springProperty> 태그를 활용하여 분기 처리를 할 수 있다. 설정 값은 실행하는 프로파일의 application.properties의 값을 참조하게 된다.

Logstash-logback-encoder

로깅 포맷을 지정하는 과정에서, logback의 JsonLayout을 선 적용하여 설정을 했었는데, 어차피 ELK에서 사용하는 목적이 크기 때문에 포맷 자체를 ELK에서 Offical하게 사용하는 포맷을 사용하는 것이 더 나으리라 생각했다. 그래서 Logstash-logback-encoder 구현체를 사용하는 것으로 판단을 내렸고, 적용은 아래 내용을 참고하면 누구나 쉽게 할 수 있으리라 생각한다. 로컬 개발 환경에서는 굳이 해당 레이아웃을 적용할 필요가 없기 때문에, 스프링 부트에서 제공해주는 기본 로거 설정을 사용하도록 하였다.

로그는 logstash-logback-encoder에서 제공해주는 TcpAppender를 사용하여 Logstash에 바로 보낼 수 있도록 설정하였으며, TCP를 사용하기 때문에 연결에 대한 reconnection, KeepAlive 설정을 추가로 적용했다. 일단 적용 후 추후 로그에 대한 유실 유무를 판단하여 FileBeat를 사용하는 등 개선점에 대해서는 모니터링 후 판단하기로 결정을 내렸다.

로깅 프로퍼티의 경우, 현재 개발 환경에 Spring-Cloud-Sleuth를 사용하고 있어서 해당 문서를 일정 부분 참고했다.

build.gradle

    /**
     * logstash-logback
     */
    compile('net.logstash.logback:logstash-logback-encoder:5.3')

resources/logback-spring.xml

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

    <!-- FILE Appender -->
    <springProperty scope="context" name="LOG_DIR"        source="logging.path"      defaultValue="/var/log/tomcat8" />
    <springProperty scope="context" name="LOG_PATH_NAME"  source="logging.file-name" defaultValue="${LOG_DIR}/server-application.log" />
    <springProperty scope="context" name="LOG_STASH_ADDR" source="logging.log-stash" defaultValue="{IP_ADDRESS}" />
    <springProperty scope="context" name="APP_NAME"       source="spring.zipkin.service.name" defaultValue="DEFAULT_APP_NAME" />

    <appender name="file" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_PATH_NAME}</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${LOG_PATH_NAME}.%d{yyyyMMdd}</fileNamePattern>
            <maxHistory>60</maxHistory>
        </rollingPolicy>

        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
            <providers>
                <timestamp>
                    <pattern>yyyy-MM-dd'T'HH:mm:ssZ</pattern>
                    <timeZone>UTC</timeZone>
                </timestamp>
                <version/>
                <logLevel/>
                <threadName/>
                <loggerName/>
                <message />
                <pattern>
                    <pattern>
                        {
                        "service": "${APP_NAME:-}",
                        "traceId": "%X{X-B3-TraceId:-}"
                        }
                    </pattern>
                </pattern>
            </providers>
        </encoder>
    </appender>

    <!-- Logstash Appender -->
    <appender name="stash" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
        <destination>${LOG_STASH_ADDR}</destination>
        <keepAliveDuration>5 minutes</keepAliveDuration>
        <reconnectionDelay>15 second</reconnectionDelay>

        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
            <providers>
                <timestamp>
                    <pattern>yyyy-MM-dd'T'HH:mm:ssZ</pattern>
                    <timeZone>UTC</timeZone>
                </timestamp>
                <version/>
                <logLevel/>
                <threadName/>
                <loggerName/>
                <message />
                <pattern>
                    <pattern>
                        {
                        "service": "${APP_NAME:-}",
                        "traceId": "%X{X-B3-TraceId:-}"
                        }
                    </pattern>
                </pattern>

            </providers>
        </encoder>
    </appender>
    

    <appender name="async-file" class="ch.qos.logback.classic.AsyncAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>DEBUG</level>
        </filter>
        <!-- 
        발신자의 정보 (class명, 줄번호 등)가 추가되어 수집 서버로 전송여부를 결정합니다.
        true 설정 시, 성능 저하를 일으킬 수 있습니다.        
         -->
        <param name="includeCallerData" value="false"/>
        <!-- 
        - blocking queue의 최대 수용 갯수로 기본값은 256입니다.
        - 대기열 용량의 20 % 미만이 남아있을 때 AsyncAppender는 WARN 및 ERROR 이벤트 만 유지하면서 TRACE, DEBUG 및 INFO 수준의 이벤트를 삭제합니다
        -->        
        <param name="queueSize" value="2048"/>
        <!-- 
        false로 설정한 경우 큐가 가득찬 상황에서 appender는 메세지 유실을 방지하기 위해 application을 block 합니다. 
        true로 설정된 경우 application을 멈추지 않기 위해 메세지를 버립니다.
        -->                
        <param name="neverBlock" value="true"/>
        <!-- 
        LoggerContext가 정지하면 AsyncAppender의 stop 메소드는 작업 스레드가 timeout 될때까지 대기합니다.
        maxFlushTime를 사용하면, timeout 시간을 밀리초로 설정할 수 있습니다.
        해당 시간안에 처리하지 못한 이벤트는 삭제됩니다.
         -->
        <param name="maxFlushTime" value="60000"/>
        <appender-ref ref="file" />
    </appender>


    <appender name="async-stash" class="net.logstash.logback.appender.LoggingEventAsyncDisruptorAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>DEBUG</level>
        </filter>
        <waitStrategyType>sleeping</waitStrategyType>
        <appender-ref ref="stash" />
    </appender>

    <!-- Logger -->
    <logger name="org.hibernate.SQL" level="DEBUG" />
    <logger name="org.hibernate.tool.hbm2ddl" level="DEBUG"/>
    <logger name="org.hibernate.stat" level="DEBUG" />
    <logger name="org.hibernate.type.BasicTypeRegistry" level="DEBUG" />
    <logger name="org.hibernate.type.descriptor.sql" level="INFO" />


    <!-- Profile -->
    <springProfile name="default | dev">
        <include resource="org/springframework/boot/logging/logback/base.xml" />
    </springProfile>

    <springProfile name="stage">
        <root level="INFO">
            <appender-ref ref="async-stash"/>
            <appender-ref ref="async-file"/>
        </root>
    </springProfile>

    <springProfile name="live">
        <include resource="org/springframework/boot/logging/logback/base.xml" />
    </springProfile>

</configuration>

참고

https://docs.toast.com/ko/Analytics/Log & Crash Search/ko/logback-sdk-guide/

Alternatives to JPA

oh-yes — Wed, 1 May 2019 14:33:42 +0900

같이 근무했던 시니어 개발자분께서 내용이 좋다면서 추천해주셔서 링크를 통하여 동영상을 시청했다. 분량은 대충 1시간 가량 되는데, JPA를 사용하면서도 하이버네이트에 대한 충분한 학습을 하지 못해서 겪었던 지난 1년간의 많은 시행착오들이 생각이 났고, Kotlin을 메인으로 사용했을때의 다양한 선택지에 대해서 고민을 해볼 수 있었던거 같아서 매우 유익했다고 할 수 있다.

Alternatives to JPA

데이터를 표현하는 관점에 따라 달라 질 수 있다.
- Relational
- OOP
두 가지 관점 중 어디를 중점으로 설계 하느냐에 따라 방향이 크게 달라질 수 있다.
데이터 중심(data-centric)의 경우, OOP적인 설계가 크게 맞지 않을 수 있고, 요즘 ORM을 사용하는 것이 유행인것 마냥 흘러가고 있어서 이에 대한 진지한 고민이 필요해보인다.
Hibernate가 커버하는 SQL은 약 95프로에 가까운데, 나머지 5프로에 대해서는 커버를 못하기 때문에 실제로 하이엔드 성능을 요구하는 상황에서는 ORM이 맞지 않다고 볼 수 있다.

JPA의 장단점?

장점

비즈니스 레이어에 대해 DB 중심적인 사고가 아닌 어플리케이션 레이어에서 이를 처리해본 사람들은 NoSQL을 사용했을 때의 접근이 수월했다.
디비 벤더 종속적으로 개발을 하지 않아도 된다.
SQL문장에 대해 크게 학습을 하지 않아도 된다.
- 문장으로 쓰느냐 vs 코드(API)로 이를 표현하느냐?
- API로 사용하는 것이 Type-safe한 전개가 가능하기 때문에 안정적이다.
Stateful, Statless에 대한 지원단점
SQL에 친숙한 사람들의 경우, JPQL에 대한 반감 혹은 적응이 힘들 수 있다. 두 가지 접근 방법에 대해 상이한 부분이 존재하며 결국 둘다 배워야 하는 점이 생긴다.
Hibernate에 대한 러닝커브가 상당히 높다.
Bulk Operation의 성능이 좋지 않다.
JPA Vendor에서 제공해주는 기능에 대해서 학습 비용이 발생한다.
- HQL, @DynamicInsert, @LazyCollection
- 2nd Cache(recommend JCache(JSR-305))

그래서 쿠팡은 어떻게?

성능보다는 생산성을 위주로 사용했으며, 오픈 후 성능이 나오질 않아서 JPA에 대한 학습도 진행하고 튜닝하는 등의 작업을 진행했었다.
Not Deep Dive
- Missing Override(hashCode, equals and toString)
- No Using @NatualId: 비즈니스적인 필요에 의해 @NatualId가 필요한 경우가 있다.
Best Practice가 존재하질 않아 제대로 사용하지 못한 케이스가 많았다.
퍼포먼스가 나오질 않다보니 비용 측면에서도 충분히 줄일 수 있는 부분이 많은데, 제대로 학습을 하지 못해서 생긴 이슈 아닌 이슈가 많았다고 한다.

그래서 JPA에 대안이 될 수 있는 솔루션들은?

단점은 버리고 장점을 취할 수 있는 다른 대안들은 뭐가 있을까?
Design Principle
- OOP 기반의 Multi-DB Vendor
- No Need stateful for Reference Object
- Support association, inheritance, converter in JPA
Performance
- Speed up to Plain SQL
- Stateless
- Support Asynchronous or Reactive
- Support Bulk or Batch Operation

Slick

Database Access Library
ORM => Functional Relational Mapping
Relational Model to Scala OOP
Natural fit
Stateless
Matures(Slick version 3)(Non-Blocking DBIO)

jOOQ

가장 도입하기 쉽고 러닝커브가 낮음

SQL과 유사하게 API를 사용할 수 있으며, Type-Safe한 성격은 그래도 가져갈 수 있다.
DB-First, DB Schema로부터 자바의 엔티티 클래스를 만들어야 하는 단점이 존재한다.
Stateless
Need DBMS Owner Authority

Requery

No Refelection - apt code generation
Fast Startup & Performance
Schema Generation
Non-Blocking
upsert
compile time entity validation
Support alomost JPA Annotations

Exposed - Kotlin SQL Framework

Lightweight SQL Framework
Two Layers of data access
- Typesafe SQL wrapping DSL
- Lightweight Data Access Object
Not Mature...

그래서 적합한 대안은?

기존 레거시 데이터베이스가 존재하는 경우? 자바만 하는 경우?
- jOOQ, requery
Scala만 사용하는 경우?
- Slick
Kotlin Only?
- requery, Exposed
언어와 상관 없다면?
- requery
Reactive Programming?
- requery with kotlinx-requery
- kotlinx-rxjava2-jdbc

Requery Overview

안드로이드에서만 쓰이는 것이 아니다.
충분히 서버 어플리케이션에서도 사용이 가능하다.
하이버네이트의 Proxy 개념이 없다. 즉, Lazy Initialize라는 개념 자체가 없다. Mybatis랑 비슷한 개념으로 생각해도 좋다. 속도가 생각보다 빠르다.
부가적으로 라이브러리는 필요없다.
Upsert 기능이 굉장히 매력적이다.
Compile Time Entity/Query Validation
Entity is stateless
Thread에 제한을 받지 않음(vs JPA EntityManager)
Support RxJava, Async Operations on Java8

Why Requery?

Provide Benefit of ORM
- Entity Mapping
- Schema Generation
- Compile Time Error Detecting

Bulk Operation은 JPA에 비해서 거의 100배 가량 빠르다고 한다. REST API 호출에서 퍼포먼스 Checking을 했을 때는 약 10배 가량 JPA를 사용했을때보다 빠르다고 한다. Upsert 기능이 제공되고 레이지한 로드(프록시를 사용한 접근이 아닌 특정 컬럼만 일부 Fetch하고 추후에 필요한 데이터를 가져오는 방식)도 가능하다.

Define Entity - Java, Kotlin

JPA와 Hibernate보다는 간결한 기능을 제공하고 있다. 간결한 기능을 제공한다는 것은 JPA와 Hibernate보다는 기능적인 가지 수가 좀 적을 수 있다는 이야기이다.

EntityDataStore

FindByKey
select/insert/update/upsert/delete
where/eq,lte,lt,gt,gte,like,in,not
groupBy / having / limit / offset
support SQL Functions
- count, sum, avg, upper, lower ...
raw query

CoroutineEntityDataStore

코틀린에서는 코루틴을 통하여 비동기 프로그래밍이 가능하다. JDBC가 블록킹 구간이 존재하지만 엔티티를 ResultSet으로부터 인스턴싱하는 과정을 비동기로하면 CPU를 좀 더 효율적으로 사용할 수 있다.
requery는 자바의 CompletableFuture를 사용

spring-data-requery

운영 시스템은 아니더라도 개인 프로젝트에 적용해본다면 별 문제 없겠지만, 운영시스템에 이걸 적용한다면 ..... 상황을 겪을 수 있다. 그래서 만든 것이 spring-data-requery 프로젝트라고 한다.
RequeryOperations
RequeryTransactionManager for TransactionManager
- Support Spring @Transactional
Better performance than spring-data-jpa
- exists, paging할때, 매번 연관된 엔티티를 모두 조회하지 않는다.
Repository build in SQL
ByPropertyName Auto Generation Methods
@Query, Native SQL Query
Query By Example
Not Support
- 조인에 대해서는 개발자가 명시를 해줘야 한다. Annotation Path에 대한 자동으로 Query를 만들어 주지는 않는다.
- Named Parameter의 경우 현재 지원하지 않지만, 추후 지원이 가능 할거라고 한다.Query By Example
검색 조건에 대한 Predicate를 작성하는 거랑 비슷함Query By Property
JPA의 가장 강력한 부분인데, 이에 대한 지원은 하고 있는데, Association에 대한 지원은 위에서 말한대로 현재 없다고 한다.
JPA의 findXXX 매소드 시그니처를 사용 하듯이 사용하면 된다.

Exists

현재 JPA에서는 ExistExecution에서 모든 조회 결과를 가져오고 이에대한 존재 유무를 체크하게 된다고 한다.
spring-data-requery에서는 ExistExecution 처리 시, 조회 결과를 단건만 가져와서 조회 조건에 대한 존재 유무를 체크한다고 한다.

Delete in JPA

연관 관계가 어떻게 되는지 모두 파악 후 Delete에 대한 실행이 진행된다.
연관 관계에 대한 모든 파악을 진행 후 진행해야 하기 때문에 결국 Read 작업이 선행될 수 밖에 없다.
Bulk Operation의 경우, 성능상 손실이 많이 발생한다.
Bulk Operation의 원래 의도는 Set 방식으로 바로 지우는 것을 원하게 되는데, 이렇게 Read 액션이 먼저 발생하게 되면 성능적으로 느려질 수 밖에 없는 상황이다. Set 방식으로 움직여야 하는 것은 Direct로 SQL 구문을 사용하여 처리 할 수 있도록 가이드를 해주는 것이 중요하다. 깊게 이해하여 사용하는 것이 너무 중요하다.
작게는 3배 많게는 100배 가량 퍼포먼스 차이가 발생할 수 있다고 한다.

Future Works

Named Parameter
@Param in Spring Data
Complicated Aggregation Operations
Requery for Apache Phoenix(Hbase)
CoroutineEntityStore

QnA

MySQL에서 넘어가는 이유가 뭔가요?
- Money!!
- AWS RDS Aurora가 비용이 너무 비쌈...ㅠㅠ
- 벤치마크 했을 때, 포스트그래가 생각보다 성능이 좋았다.
- JPA를 쓴 것이 성능이 느려서 고생을 했었는데, DB 벤더를 바꿈으로서 얻게 되는 이점이 생각보다 많이 있을 거라고 생각하여 변경을 하게 됐다.

20190311

oh-yes — Mon, 11 Mar 2019 23:03:04 +0900

1. 함께 자라기 애자일로 가는길

링크
회사 교육비로 구매한 책이다. 매번 기술 서적만 목을 매어 읽어왔는데, 이번에는 기술 서적이 개발과 관련된 여러 가지 이야기가 담긴 책을 읽어보고 싶었다. 그래서 선택한 책이다. 책은 반 정도 읽은 거 같은데, 나 말고 주변 다른 사람들과 함께 잘 성장하는 방법 그리고 의식적인 학습을 어떻게 잘 할 것인가에 대해 써놓은 글이 매우 인상 깊었다. 두꺼운 책은 아니라서 끝까지 읽는 것에는 부담이 크게 없을 거 같으니 틈틈이 읽어 봐야겠다.

2. JPA And Database Lock

회사 업무 중 복잡한 데이터 처리 과정이 담긴 API를 개발하고 있다. 기존 레거시 시스템을 개선하는 작업이기도 하고 신규 솔루션과 연동해야 하는 업무라서 은근 골치가 아프다. 특히 Lock을 제어해야 하는 코드가 생기고 있는데, 여태까지 데이터베이스를 쓰면서 크게 락에 대한 고민이나 학습을 깊게 안하고 코딩을 했었던 것 같아 스스로에게 반성을 많이 했던 하루였다.
현재 회사에서 데이터베이스에 대한 접근을 JPA + QueryDsl 조합으로 사용하고 있는데 Lock에 대한 접근을 데이터베이스에서의 Read Lock, Write Lock 정도의 구분으로 접근하는 것이 아니라 `낙관적인 락` 그리고 `비관적인 락`으로 크게 나누어서 분류하고 있으며, 이에 대한 세부 구현도 달라지는 것을 오늘 처음 알았다.
영속성 컨텍스트가 관리해주는 락도 존재하고 있었는데, 이 부분에 대해서는 좀 더 깊게 공부를 해봐야 할거 같다. JPA를 사용하면서 이것저것 재미있게 공부해볼 수 있는 주제가 많은 거 같아서 기쁜 마음도 들지만 한편으로 해야 할 공부가 점점 많아지는 거 같아 괜스레 마음이 더 무거워진다.

20190305

oh-yes — Tue, 5 Mar 2019 19:11:16 +0900

1. Effective-Java-3e 읽기/실습

아이템 20. 추상 클래스보다는 인터페이스를 우선하라
아이템 21. 인터페이스는 구현하는 쪽을 생각해 설계하라

자바8의 디폴트 메소드에 대한 언급과 더불어 추상화를 위한 구현 방법으로 인터페이스 단독으로 사용하는 경우와 추상클래스를 인터페이스의 구현으로 사용하고 조금 더 확장성 있는 클래스 구조를 가질 수 있도록 설명하는 구절이 인상적이었다. 인터페이스 역시 앞에서의 아이템 설명처럼 충분히 문서화하고 구현에 설명을 자세히 써주는 것이 중요한 구절 역시 보면서 무릎을 탁!

2. @JsonView

class LoanContractViews {
    interface Simple
    interface Detailed : Simple
}

json 반환 데이터를 다이나믹하게 해줘야 할 요구사항이 생겼는데, 이를 처리 하려고 생각하다보니 이전에 사용했던 @JsonView가 얼핏 생각나서 기억을 꺼내서 다시 사용해봤다. 역시 편리하다

3. @ReqeustBody Setter 관련

링크를 읽고 새삼 반성하는 부분이 많았다. 당연히 getter/setter를 만들어서 작업했었고, 이에 대한 값 바인딩이 당연히 setter 기준으로 진행되리라 생각하고 있었는데, 실제로 @ReqeustBody에 대해서는 세터 주입이 안일어나고 Jackson2HttpMessageConverter를 이용한 값 바인딩이 이뤄진다는 사실을 알았다. 근데, Get 요청에 대한 QueryParameter에 대해서는 반드시 setter가 필요하다 by WebDataBinder

20190304

oh-yes — Mon, 4 Mar 2019 22:54:06 +0900

1. Effective-Java-3e 읽기/실습

아이템 18. 상속보다는 컴포지션을 사용하라
아이템 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

2. 함수형 코틀린

11장. 코틀린에서 스트림 작업
- Collection vs Stream
- Stream vs Observable
- Push Model vs Pull Model
- 코틀린에서 Stream 생성
- Termianl Method
12장. 애로우 시작
- 함수 합성(Compose)
- 부분 적용
- Pipe
- Curry
- Arrow 구현체를 활용한 불변객체 lense 방법

3. Bean Validation 2.0

@RequestBody를 활용한 요청 본문 Validation 중 해당 구현에 대해 조금 더 살펴보고자 링크를 살펴보게 되었다.
API 개발을 하면서 모르는 내용을 틈틈히 읽어보고 이렇게 글로 남기는 것이 중요한거 같다.

코틀린의 코루틴(`Coroutine`)을 어떻게 이해할것인가?

oh-yes — Sat, 2 Mar 2019 20:13:01 +0900

본 글은 How to make sense of Kotlin coroutines을 읽고 발번역(?)한 내용입니다. 영어에 유창한 분들은 링크를 참고해주세요.

코루틴은 완벽하게 읽고 유지 보수가 가능한 비동기 코드를 작성하는 좋은 방법이다. Kotlin은 단일 언어 구문으로 비동기 프로그래밍의 기본 요소를 제공하는데, 바로 suspend 키워드이다. 이 키워드와 함께 라이브러리 함수가 빛을 발합니다.

What is a coroutine?

Kotlin팀은 Coroutine을 경량 스레드: Light-Weighted-Thread로 정의했습니다. 그것들은 실제 스레드가 실행 할 수 있는 일종의 작업입니다. Kotlinlang.org의 배너는 다음과 같습니다.

가장 흥미로운 점은 스레드가 특정 "정지 지점"에서 코루틴 실행을 중지하고 다른 작업을 수행 할 수 있다는 것이다. 나중에 코루틴을 다시 시작하거나 다른 스레드가 처리 할 수 있습니다.

따라서 정확성을 높이기 위해 하나의 코 루틴은 정확하게 하나의 "작업"이 아니라 오히려 특정 보장 된 순서로 실행되는 "하위 작업"의 순서입니다. 코드가 하나의 순차 블록에 있는 것처럼 보이더라도 정지 기능에 대한 각 호출은 동시 루틴 내의 새로운 "하위 작업"의 시작을 제한합니다.

이는 우리에게 suspending functions에 관련된 주제를 다시 던져준다.

Suspending functions

당신은 어쩌면 kotlinx의 delay 또는 Ktor의 HttpClient.post와 같은 함수를 발견 했을 수도 있는데, 이 함수들은 반환되기 전에 무언가를 기다리거나 집중적으로 작업해야하며 suspend 키워드로 표시되어있을 수 있습니다.

suspend fun delay(timeMillis: Long) {...}
suspend fun someNetworkCallReturningValue(): SomeType {
 ...
}

우리가 위에서 본 것처럼 이를 suspending function이라고 합니다.

일시 중단 함수는 현재 스레드를 차단하지 않고 현재 코루틴의 실행을 일시 중단 할 수 있습니다.

다시 말해, 당신이 보고 있는 코드가 suspending function을 호출하는 순간에 실행을 중지 할 수 있으며 나중에 다시 시작 될 수도 있다는 이야기이다. 그러나, 그 동안 현재 쓰레드가 무엇을 할 지에 대해서는 아무 말도 하지 않는다.

그 시점에서 또 다른 coroutine을 실행하는 것으로 돌아갈 수 있으며, 나중에 우리가 남긴 coroutine을 다시 실행할 수 있습니다. 이 모든 것은 일시 중지되지 않는 함수 세계에서 일시 중지 함수를 호출하는 방법에 의해 제어되지만 함수 일시 중단에 대해 본질적으로 비동기는 없습니다.

일시 중단 기능은 명시 적으로 사용되는 경우에만 비동기식입니다.

우리는 나중에 이것을 보게 될 것이다. 그러나 지금 당장은 함수를 일시 정지하는 것으로 생각하면 잠시 시간을내어 선언하는 특수 함수로 간주 할 수 있습니다. 그리고 그들은 암시적으로 스레드의 복잡성과 파견에 대해 걱정할 필요없이 함수를 하위 작업으로 암시 적으로 분할한다는 점을 명심하십시오. 그것이 실제로 그들이 훌륭한 이유입니다. 여러분이 내부에있을 때 걱정할 필요가 없습니다.

The suspending world is nicely sequential

아마 suspending function에 특별한 반환 유형이 없는 것을 알아차렸을 수 있다. Java의 Future 또는 JavaScript의 Promise과 같은 래퍼가 필요하지 않습니다. 이것은 Promise을 반환하는 JavaScript의 비동기 함수와 달리 일시 중단 함수가 비동기 적이라는 사실을 강조합니다.

내부 정지 함수로부터, 함수 호출에 대해 순차적으로 추론 할 수 있습니다.

이것이 바로 비동기식 소재를 Kotlin에서 쉽게 추론 할 수 있게 하는 이유이다. suspending function 내에서 다른 suspending function에 대한 호출은 일반 함수 호출과 같이 작동합니다. 우리는 반환 값을 얻고 나머지 코드를 실행하기 전에 호출 된 함수의 실행을 기다릴 필요가 있다.

suspend fun someNetworkCallReturningSomething(): Something {
    // some networking operations making use of the suspending mechanism
}

suspend fun someBusyFunction(): Unit {
    delay(1000L)
    println("Printed after 1 second")
    val something: Something = someNetworkCallReturningSomething()
    println("Received $something from network")
}

이것이 나중에 복잡한 비동기 코드를 간단한 방법으로 작성할 수 있게 해줍니다.

Bridging the normal world and the suspending world

일반 함수에서 suspending function을 직접 호출하면 컴파일 할 수 없다. 이에 대한 일반적인 설명은 coroutines 만 일시 중단 될 수 있기 때문에 이라고 설명하고 있다. 이런 설명을 통해 우리는 suspending function을 수행 할 coroutine을 생성해야 한다는 결론을 내릴 수 있다.

개념적으로 함수를 일시 중단하는 것은 선언에서 "실행하는 데 약간의 시간이 걸릴"수 있습니다. 자신이 일시 중지 기능이 아니라면 다음 두 가지 중 하나를 명시 적으로 수행해야합니다.

기다리는 동안 실제로 스레드를 차단합니다 (일반적인 함수 호출과 같이).
비동기로 시작하여 즉시 수행하고 (여러 가지 가능한 방법으로 수행 할 수 있음)

선택을 표현하는 방법으로 코 루틴 (coroutine)을 생성하는 것을 볼 수 있습니다. 명시 적이어야합니다 (그리고 이것은 대단합니다!) 이것은 coroutine 빌더라고하는 함수를 사용하여 수행됩니다.

Coroutine builders

Coroutine Builder는 주어진 suspending function을 실행하는 새로운 Coroutine을 작성하는 간단한 함수입니다. 이러한 Coroutine Builder는 suspending function이 아닌 일반 함수에서 호출될 수 있는데, 왜냐하면 이러한 빌더 함수들은 suspending function이 아니기 때문입니다. 마치 일반 함수와 suspending function 함수 세계와의 가교 역할을 수행한다고 생각하시면 편합니다.

Kotlin 표준 라이브러리에는 여러 가지 Coroutine Builder가 포함되어있어 다양한 작업을 수행 할 수 있습니다. 다음 하위 절에서 몇 가지를 볼 것입니다.

Block the current thread with “runBlocking”

코틀린의 일반 함수에서 suspending function을 다루는 가장 간단한 방법은 현제 실행 중인 스레드를 블록하고 기다리는 방법입니다. 현재 스레드를 블록하는 Coroutine Builder 함수는 바로 runBlocking입니다.

fun main() { 
    println("Hello,")
    
    // 주어진 suspending lambda function을 실행하는 코루틴을 만들 수 있으며
    // 그리고 현재 실행중인 스레드를 해당 함수의 실행이 마무리 될떄까지 블락합니다.
    runBlocking {
        // coroutine 함수 내부, 함수는 2초동안 정지상태로 유지됨.
        delay(2000L)
    }
    
    // 아래 코드는 2초 뒤에 실행됨
    println("World!")
}

runBlocking의 컨텍스트에서 주어진 suspending function과 호출 계층 구조에 있는 자식은 실행이 끝날 때까지 현재 스레드를 효과적으로 차단합니다. runBlocking에 전달 된 함수는 서명에서 알 수 있듯이 runBlocking 자체가 일시 중지되지 않고 (스레드 블로킹 인 경우에도) 일시 중단 함수입니다.

main() 함수에서 일종의 최상위 코루틴을 제공하고 JVM을 활성 상태로 유지하는 데 종종 사용됩니다 (구조화 된 동시성에 대한 섹션에서 볼 수 있습니다).

Fire-and-forget with “launch”

일반적으로 coroutine의 핵심은 스레드를 블록하는 것이 아니라 비동기 작업을 시작하는 것입니다. launch이라는 Coroutine Builder는 백그라운드에서 coroutine을 시작하고 그동안 계속 작업 할 수 있게 합니다.

Kotlin 문서를 통해 아래와 같은 예제를 확인 할 수 있다.

fun main() { 
    GlobalScope.launch { // 새로운 코루틴을 백그라운드에서 실행하고 이후 단계를 진행한다.
        delay(1000L)
        println("World!")
    }
    println("Hello,") // main thread continues here immediately    
    runBlocking {     // 그러나 이 표현식은 현제 실행중인 스레드를 블락한다.
        delay(2000L)  // 우리가 2초 가량 대기하는 동안에도 JVM은 살이 있는 상태를 유지한다.        
    } 
}

의견은 스스로에 대해 말해야합니다. 그러면 "Hello"가 즉시 인쇄되고 두 번째 후에 "World!"가 추가됩니다. 이 예제의 목적을 위해라도 어찌되었던간에 메인 함수를 블록해야 launch에서 무슨 일이 발생하는지 확인 할 수 있습니다. 그래서 JVM을 계속 유지하기 위해 runBlocking을 여기에서 다시 사용하고 있습니다.

Get a result asynchronously with “async”

다음은 값을 반환하는 비동기 작업을 수행 할 수 있는 async라는 또 다른 Coroutine Builder입니다.

fun main() {
    val deferredResult: Deferred<String> = GlobalScope.async {
        delay(1000L)
        "World!"
    }
    
    runBlocking {
        println("Hello, ${deferredResult.await()}")
    }
}

지연 값의 결과를 얻으려면 async가 편리한 Deferred 객체를 반환합니다. 이는 자바의 Future 또는 자바스크립트의 Promise와 같습니다. 지연 값에 대해 await를 호출함으로써 결과를 기다리고 획득 할 수 있습니다.

await는 일반적인 블록킹 함수가 아닌 suspending function입니다. 이말인 즉슨, 메인 함수에서 호출 할 수 없다는 것을 의미합니다. 결과를 기다리기 위해 실제 main 함수를 블록해야 해야 되며 그래서 여기서 runBlocking을 사용하여 호출을 대기시킵니다.

날카로운 눈빛을 가진 사람들은 GlobalScope를 다시 보았을 수 있습니다. 그래서 이제 GlobalScope에 대해 이야기 하려고 합니다.
GlobalScope란 coroutines의 계층을 만들 수 있는 도구라고 볼 수 있습니다. Kotlin팀은 이를 구조화 된 동시성(structured concurrency)이라 부르고 있습니다.

Structured concurrency

만약 위에서 봤던 예제들을 잘 따라왔다면, 고전적인 "블록을 완료하고 내 코루틴이 끝날 때까지 기다리는" 패턴을 알아야 할 필요가 있음을 눈치 챘을 것이다.

Java에서는 위에서와 같은 패턴을 구현하는 방법으로 대개 스레드에 대한 참조를 유지하고 모든 스레드를 기다리는 동안 주 스레드를 블록하기 위해 스레드에 대한 참조를 유지하고 모든 스레드에 대한 join을 호출하여 결과를 얻습니다. 우리는 Kotlin의 coroutine을 이용하여 비슷한 일을 할 수 있습니다. 그러나 이것은 전혀 관용적이지 않습니다.

Kotlin에서는 coroutines을 계층 구조로도 생성 할 수 있습니다. 이 계층 구조를 사용하면 부모 coroutine이 자동으로 자식 coroutines의 수명주기를 관리 할 수 있습니다. 예를 들어, 하위 코루틴의 실행이 완료 할 때까지 기다리는 일도, 그 중 하나에서 예외가 발생하는 경우 모든 하위 코루틴의 실행을 취소 할 수 있습니다.

Creating a hierarchy of coroutines

coroutine에서 호출하면 안되는 runBlocking을 제외하고 모든 Coroutine Builder는 CoroutineScope 클래스의 확장 함수 형태로 선언되어 있는데, coroutine을 구조화하도록 권장합니다.

fun <T> runBlocking(...): T {...}
fun <T> CoroutineScope.async(...): Deferred<T> {...}
fun <T> CoroutineScope.launch(...): Job {...}
fun <E> CoroutineScope.produce(...): ReceiveChannel<E> {...}
...

Coroutine을 생성하려면 GlobalScope (최상위 수준, Top-Level Coroutine) 또는 이미 존재하는 CoroutineScope (해당 범위의 자식 Coroutine)에서 이러한 빌더를 호출해야합니다.

In fact, if you write a function that creates coroutines, you should declare it as an extension of the CoroutineScope class too
사실, coroutine을 만드는 함수를 작성한다면 CoroutineScope 클래스의 확장으로 선언해야합니다. 이는 관례적으로 Coroutine Builder를 쉽게 호출 할 수 있게 해주는데, 왜냐하면 Coroutine Scope에 대한 참조를 this를 통하여 할 수 있기 때문입니다.

Coroutine Builder의 매소드 시그니처를 살펴보면 매개 변수로 사용하는 suspending function이 CoroutineScope 클래스의 확장 기능으로 정의되어 있음을 알 수 있습니다.

fun <T> CoroutineScope.async(
    ...
    block: suspend CoroutineScope.() -> T
): Deferred<T> {
    ...
}

이는 수신자를 지정하지 않고도 그 함수의 내부에서 다른 Coroutine Builder를 호출 할 수 있음을 의미합니다. 그리고, 암시적인 수신자는 현재 코루틴의 자식 스코프가 될 수 있습니다. 이때 현재 코루틴은 부모로서의 역할을 수행하게 됩니다.

이전 예제를 보다 관용적인 방식으로 구조화 하는 방법은 아래와 같습니다.

fun main() = runBlocking {
    val deferredResult = async {
        delay(1000L)
        "World!"
    }
    println("Hello, ${deferredResult.await()}")
}

fun main() = runBlocking { 
    launch {
        delay(1000L)
        println("World!")
    }
    println("Hello,")
}

fun main() = runBlocking {
    delay(1000L)
    println("Hello, World!")
}

범위가 wrapping runBlocking 호출에 의해 제공되기 때문에 더 이상 GlobalScope가 필요하지 않습니다. 또한 자식 Coroutine이 끝날 때까지 기다릴 필요가 없습니다. runBlocking은 모든 자식이 자신의 실행을 완료하기 전에 완료 될 때까지 기다릴 것이므로 주 스레드는 runBlocking에 의해 블록 상태를 유지합니다.

The coroutineScope builder

runBlocking을 사용하는 것은 coroutine 내부에서 권장하지 않을 수 있음을 알 수 있을 것이다. 이는 Kotlin팀이 coroutine 내부에서 현재 스레드가 블록되지 않길 원하기도 했고, 대신 suspending function을 사용하길 권하고 있습니다. runBlocking에 해당하는 중단은 coroutineScope 빌더입니다.

coroutineScope는 모든 자식 코루틴이 실행을 완료 할 때까지 현재의 coroutine을 일시 중단합니다. 다음은 Kotlin 문서에서 직접 취한 예제입니다:

fun main() = runBlocking { // this: CoroutineScope
    launch { 
        delay(200L)
        println("Task from runBlocking")
    }
    
    coroutineScope { // Creates a new coroutine scope
        launch {
            delay(500L) 
            println("Task from nested launch")
        }
    
        delay(100L)
        println("Task from coroutine scope") // This line will be printed before nested launch
    }
    
    println("Coroutine scope is over") // This line is not printed until nested launch completes
}

Beyond the basics

여기에서 설명하는 기본 구성 요소는 실제로 코 틀린의 coroutines 개념의 가장 큰 측면이 아닙니다. 우리는 channel, producer 및 consumer 등을 사용하여 동시성이 필요한 것을 정말 멋지게 표현하기 위해 coroutine을 사용할 수 있습니다. 그러나 우리는 먼저 이러한 빌딩 블록을 이해해야하며 그 위에 더 높은 추상화를 만들기 시작해야한다고 생각합니다.

coroutine에 관해서는 많은 이야기가 있습니다.이 기사는 물론 표면적인 내용이 많긴 하지만, 이 글이 코루틴과 suspending function을 더 잘 이해하는데 도움이 되기를 바랍니다.

특정 부분에 대해 더 궁금하거나 이 글이 도움이 된다면 저에게 알려주시면 좋을꺼 같습니다. 만약 자잘한 실수가 보이면 망설이지 말고 알려주시구요.

Very helpful resources

조금 시간을 할애 할 수 있다면, Kotlin Conf에서 Roman Elizarov가 발표했던 코루틴 관련 영상을 보시길 추천합니다.

Coroutines in practice

이 강연에서 Roman은 코루틴에 대해 아주 빠르게 요약하고 이어서 channels, actors 등을 사용하여 코루틴을 아주 잘 사용하는 방법을 설명하고 있습니다.

KotlinConf 2018 - Kotlin Coroutines in Practice by Roman Elizarov

Kotlin conf 2017

2017 Kotlin conf에서 발표했던 내용 역시 여전히 유용합니다.

Introduction to Coroutines : 이것은 기본적으로 내 기사의 내용이지만 보다 정확하고 나은 설명이 포함되어 있습니다
Deep Dive into Coroutines : 함수 및 coroutine을 실제로 중단시키는 방법에 대한 세부 정보를 설명합니다. 매우 계몽적인

Kotlin With Spring Boot

oh-yes — Sat, 2 Mar 2019 19:57:38 +0900

현재 재직중인 회사에서 코틀린을 주력으로 사용하고 있는데, 지난 1년 정도 코틀린과 스프링부트를 사용해보면서 겪었던 삽질이나 좋았던 점을 스터디를 통하여 한 번 정리하면 좋겠다하는 마음에서 정리하게 됬다.
시작하기 어렵지 않다. Spring Intializer에서 Kotlin 프로젝트를 쉽게 생성 할 수 있으며, 물론 버젼의 제약이 있긴 하겠지만 기존 자바 기반으로 운영하고 있더라도 쉽게 Koltin을 통한 추가 기능 개발이 가능하다.
현재 코틀린은 1.3.21 버젼까지 사용할 수 있으며 SpringFramework 5.X, SpringBoot 2.X부터는 공식적으로 코틀린에 대한 지원을 시작했다.
SpringFramework 5.2 부터는 코틀린의 협력적 멀티테스킹을 수행할 수 있는 `코루틴`에 대한 지원이 들어갈 예정.
Reference Document
example
기존 자바로 개발을 하던 사람이라면 누구나 쉽게 코틀린에 접근을 할 수 있다고 생각한다. 필자 역시 작년 4월부터 코틀린으로 개발을 시작했을 때, 생각보다 시작할 때의 러닝 커브가 높지 않았고 기존 자바 + 스프링에 대한 경험이 있었던 덕분인지 큰 어려움까지는 없었다.

코틀린을 쓰면서 편리하거나 좋은 점

Null에 대한 편리한 판단, Null 안정성

person.name ?: "Daniel"
person.name ?: throw IllegalArgumentException()
person.name?.toUpperCase() ?: "UPPERCASE"
person.name?.let {
    println("Null이 아닐때 실행되요")
} ?: "Null이면 여기에요"

엘비스 연산자(?:)와 안전한 호출 연산(?)를 활용하면 Null이 될 수 있는 값에 대한 기본 값 지정 및 별도의 표현식을 지정 할 수 있다.

data class

data class AddressDto(
	val street: String, 
	val zipCode: String,
	val city: String
)

자동으로 구현해주는 equals와 hashCode가 있어서 기존 자바에서 구현 시 직접 구현해주거나 autoValue 혹은 lombok과 같은 별도의 구현체를 사용하지 않아서 편리하다.

다양한 확장 함수

기본으로 제공해주는 다양한 확장 함수가 존재한다. 기존 자바로 개발했을 때는 Array를 Collection으로 변환하여 필터 혹은 Map을 하는 등 복잡한 단계가 필요했었는데, 코틀린에서는 이를 확장 함수 형태로 호출 할 수 있도록 기본 API를 제공해주고 있어서 편리하다.

편리한 람다 사용 & 중위 연산자

람다에 대한 선언을 변수에 편리하게 지정 할 수 있고 람다를 넘길 수 있는 고차 함수에 편리하게 해당 선언을 넘길 수 있다. 또한 람다에 대한 성능이 걱정된다면 inline 함수를 사용하여 이를 최적화 할 수도 있다. 코틀린에서 제공해주는 기본 함수 중 상당수가 inline 함수의 형태로 선언되어 있다.
중위 연산자(infix)를 활용하면 코드가 깔끔하게 표현할 수 있다. 아래는 Pair 선언을 하는 중위 연산자 표현이다.

val pair = 10 to 10
val pairList = listOf(
	10 to 10,
	10 to 10,
	10 to 10
)

람다와 중위 연산자를 잘 활용하면 간단한 DSL을 쉽게 작성 할 수 있다. 아래는 kotlinx에서 제공해주는 html dsl 관련 예제 코드이다.

body {
	div {
        a("https://kotlinlang.org") {
            target = ATarget.blank
            +"Main site"
        }
	}
}

겪었던 삽질에 대한 공유 혹은 알아야 하는 내용은?

Null이 아니지만 Null인 경우가 있다.

public class Bus {
    private final int no;
    private final String title;

    private Bus(int no, String title) {
        this.no = no;
        this.title = title;
    }

    public int getNo() {
        return no;
    }

    public String getTitle() {
        return title;
    }

    public static Bus getNullObject() {
        return new Bus(10, null);
    }
}

val busTitle: String = Bus.getNullObject().title
println(busTitle.toUpperCase()) // throw Runtime Exception

Java로 정의 · 선언된 참조 타입을 Kotlin에서는 Platform Type 타입이라고 부른다.
특히 JPA를 사용하면서 null값이 들어가 있는 멤버 변수를 활용하다가 삽질을 겪었던 경험도 있다. 아무튼 상호운용과 관련하여 각별한 주의가 필요한 부분이다.
이를 피하기 위해서는 @Nullable 혹은 @NotNull 어노테이션을 자바 코드에 명시 해줘야 코틀린쪽 컴파일러에서 이를 인지하여 처리할 수 있다. 아래는 비슷한 효과를 내는 어노테이션들 목록이다.
- @Nullable
  - org.jetbrains.annotations.Nullable
  - android.support.annotation.Nullable
  - com.android.annotations.Nullable
  - org.eclipse.jdt.annotation.Nullable
  - org.checkerframework.checker.nullness.qual.Nullable
  - javax.annotation.Nullable
  - javax.annotation.CheckForNull
  - edu.umd.cs.findbugs.annotations.CheckForNull
  - edu.umd.cs.findbugs.annotations.Nullable
  - edu.umd.cs.findbugs.annotations.PossiblyNull
- @NotNull
  - org.jetbrains.annotations.NotNull
  - edu.umd.cs.findbugs.annotations.NonNull
  - android.support.annotation.NonNull
  - com.android.annotations.NonNull
  - org.eclipse.jdt.annotation.NonNull
  - org.checkerframework.checker.nullness.qual.NonNull
  - lombok.NonNull

With JPA

기존 자바에서 JPA를 경험했던 개발자라면 크게 사용상 어려움은 없으리라 생각한다. 하지만 아래에서 설명하는 기본 설정 관련된 부분에 대해 초기에는 신경 쓸 부분이 존재한다. 아래 내용은 JPA 사용 관련하여 알고 있어야 하는 내용 몇개를 정리해봤다.

엔티티의 클래스의 경우 인자가 없는 생성자가 필수이기 때문에 이를 코드로 직접 생성해줘야 하는 번거로움이 있다.(자바할때는 당연한거였는데...) 이를 피하기 위해서는 빌드 경로에 kotlin-noarg 컴파일러 플러그인을 넣으면 Hibernate 엔티티에 대해 인수가 없는 생성자가 생성된다.

buildscript {
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-noarg:$kotlin_version"
    }
}

apply plugin: "kotlin-jpa"

Kotlin 클래스는 기본적으로 Final 클래스이다. 엔티티의 지연로드를 사용하는 경우 엔티티 클래스는 Final로 선언되어 있으면 안된다. kotlin-allopen 플러그인을 사용하여 아래와 같이 엔티티 타입의 클래스에 대해서는 final이 아닌 open 형태로 선언되도록 해야 한다.

buildscript {
    dependencies {
        classpath("org.jetbrains.kotlin:kotlin-allopen:${kotlinVersion}")
    }
}
allOpen {
    annotation("javax.persistence.Entity")
    annotation("javax.persistence.MappedSuperclass")
    annotation("javax.persistence.Embeddable")
}

JPA에 한정된 내용은 아니지만 AnnotationProcessor 사용 시 kotlin-kapt 플러그인을 사용하면 된다. 특히 회사에서 queryDsl을 공통으로 사용하고 있었기 때문에 해당 설정을 해줬어야 했다.

apply plugin: 'kotlin-kapt'
idea {
    module {
        def kaptMain = file('build/generated/source/kapt/main')
        sourceDirs += kaptMain
        generatedSourceDirs += kaptMain
    }
}
....
dependencies {
	...
    implementation("com.querydsl:querydsl-jpa:${queryDslVersion}")
    kapt("com.querydsl:querydsl-apt:${queryDslVersion}:jpa")
	
}

기존 node.js를 주력으로 서버 어플리케이션 개발을 많이 해왔던 나로서는 코틀린의 유연하고 편리한 구문과 문법은 큰 매력적으로 다가왔고 지금도 이를 잘 알고 활용하고 싶은 마음이 크다. 우스게 소리로 팀원들과 이제 자바로 못돌아가겠다라는 이야기를 자주 하곤 한다. 이 만큼 코틀린으로 개발하는 것이 주는 재미와 더불어 걍력한 생산성이 매력적이라는 이야기이다.

코틀린과 관련된 생태계나 관련 구현체를 찾을 때는 awesome Kotlin을 참고하면 많은 도움이 된다. 그리고 주 단위로 발행해주는 Kotlin-Weekly의 기사를 참고하는 것도 역시 많은 도움이 된다.

이펙티브자바3판 - [2장] 모든 객체의 공통 메서드

oh-yes — Mon, 18 Feb 2019 23:00:21 +0900

ch3

[2장] 모든 객체의 공통 메서드

Objects는 객체를 만들 수 있는 구체 클래스면서 기본적으로 상속하여 사용이 가능
equals, hashCode, toString, clone, finalize 모두 재정의를 염두로 두고 설계
일반 규약에 맞도록 재정의(overriding)해야 하며, 잘못 구현하면 오작동을 발생 시킬 수 있음

ITEM 10 - equals는 일반 규약을 지켜 재정의하라

일반 규약에 맞도록 재정의 하지 않을꺼면 재정의를 안하는 것이 최선.
아래 항목이 해당하는 경우 재정의를 하는 것이 크게 의미가 없을 수 있음.
- 각 인스턴스는 본질적으로 고유
- 인스턴스의 논리적 동치성을 검사할 일이 없는 경우
- 상위 클래스에서 정의한 equals가 하위 클래스에 딱 들어맞는 경우
- 클래스가 private이거나 package-private일 경우, equals를 호출할 일이 없음
그럼 언제 재정의 해야 할까?
- 객체 간 논리적 동치성을 확인해야 하는데 상위 클래스의 equals가 이를 비교하도록 정의되지 않았을 경우에 재정의 해야 함.
- 주로 값 클래스일 경우가 해당 함.
equals의 일반 규약은 아래와 같다.
- 반사성: 자기 자신과 같아야 함.
- 대칭성: x가 y와 같다면, y도 x와 같아야 한다.
- 추이성: x가 y와 같고, y가 z와 같다면, x는 z와 같아야 한다.
- 일관성: x와 y가 같다면, 영원히 같아야 함.
- null-아님: null과 비교하는 것은 의미가 없음.
구체 클래스를 확장해 새로운 값을 추가하면서 equals 규약을 만족 시킬 방법은 존재하지 않음.
- Point 클래스를 상속한 ColorPoint클래스와 Point클래스의 인스턴스를 비교할 수 없음, Why?
- 객체의 동등성 비교 시, 한쪽만 true인 결과를 얻을 수 있기 때문. equals의 대칭성 규약을 지킬 수 없다.
상속이 아닌 컴포지션을 사용하면 우회하여 값을 비교하는 equals를 재정의 하는 것이 가능하다.
equals 메서드를 구현하는 일반적인 방법은 아래와 같다.
1. == 연산자를 사용하여 자기 자신의 참조 확인
2. instanceof 연산자로 올바른 타입인지 체크
3. 2번 단계에서 확인한 타입으로 타입 캐스팅
4. 입력 객체와 자기 자신의 대응되는 핵심 필드들이 모두 일치하는지 검사
값 혹은 참조를 비교하는 방법은?
- float, double을 제외한 기본 타입의 필드는 == 연산자로 비교
  - float, double은 Float.compare(float, float), Double.compare(double, double)로 비교
  - Float.equals 및 Double.equals는 오토박싱을 수반하므로 성능상 좋지 않음
- 참조 타입 필드는 해당 타입의 equals를 이용하여 비교
- 배열 전체를 비교 할 경우, Arrays.equals를 사용

public final class PhoneNumber {
    private final short areaCode, prefix, lineNum;

    public PhoneNumber(short areaCode, short prefix, short lineNum) {
        this.areaCode = areaCode;
        this.prefix = prefix;
        this.lineNum = lineNum;
    }

    private static short rangeCheck(int val, int max, String arg) {
        if (val < 0 || val > max) throw new IllegalArgumentException(arg + ": " + val);
        return (short) val;
    }

    @Override
    // 인자의 타입은 `Object` 타입을 사용하도록 하자
    public boolean equals(Object o) {
        // 1. 자기 자신과 같은지 확인
        if (o == this) return true;
        // 2. 타입이 같은 체크
        if (!(o instanceof PhoneNumber)) return false;
        // 3. 타입 캐스팅
        PhoneNumber pn = (PhoneNumber)o;
        // 4. 주요 필드 값에 대해 비교 연산 수행
        return pn.lineNum == lineNum && pn.areaCode == areaCode && pn.prefix == prefix;
    }
}

equals를 구현하고 체크해야 할 세가지
- 대칭적인지?, 추이성을 만족하는지?, 일관적인지?
- equals를 재정의할 경우 반드시 hashCode도 재정의하자
- 인자의 타입은 Object 타입을 사용하도록 하자. 만약 구체 타입으로 인자를 받을 경우 아래 그림과 컴파일이 되지 않는다. @Override 어노테이션을 일관되게 사용하면 이런 일련의 실수를 예방할 수 있다.

ITEM 11 - equals를 재정의하려거든 hashCode도 재정의하라

equals를 재정의 할 경우 반드시 hashCode도 재정의 해야 한다.
- 그러지 않으면, HashSet 혹은 HashMap과 같은 콜랙션 구현체에서 사용 시 문제가 발생한다.
아래는 Object 명세의 일부이다.
- equals 비교에 사용되는 필드 값이 변경되지 않았다면, 매번 같은 hashCode를 반환해야 한다.
- [중요] equals에서 두 객체가 같다고 판단했다면, hashCode도 같은 값을 반환해야 한다.
- equals에서 두 객체가 다르다고 판단했더라도, 두 객체가 다른 hashCode값을 반환할 필요는 없다.
- [중요] 하지만, 다른 객체에 대해서는 다른 hashCode 값을 반환해야 해시테이블의 성능이 좋아진다.
해시코드 반환을 올바르게 하지 않을 경우, 수행 시간의 계산이 최대 O(n)까지 늘어날 수 있다.아래는 O(n)까지 늘어나는 사용 금지 해시 코드 구현이다.
```
@Override
public int hashCode() { return 42; }
```
좋은 해시 함수는 결국 서로 다른 객체 혹은 인스턴스에 대해 다른 해시코드를 반환해야 한다. 이상적인 해시 함수는 인스턴스들을 32비트 정수 범위에 균일하게 분배해야 한다.
hashCode를 작성하는 요령은?
1. 첫 번째 핵심 필드에 대해 hashCode를 생성. 이를 변수 result에 할당.
2. 나머지 필드에 대해 아래와 같이 해시코드를 구하도록 하자.
- 해시코드 c를 아래와 같은 원칙으로 구해보자.
  - 기본 타입 필드일 경우, 해당 타입의 박싱 클래스 타입의 Type.hashCode(f)를 수행
  - 참조 타입 필드일 경우, 해당 클래스의 필드 값들에 대해 hashCode를 재귀적으로 호출하고 복잡해질꺼 같으면 필드의 표준형을 만들어 호출하자. 필드 값이 null이면 0을 사용한다.
  - 필드가 배열일 경우, 핵심 원소에 대해 각각 필드와 같이 다뤄준다. 핵심 원소가 없을 경우 0으로 다뤄주자.
- 첫 번째 단계에서 구한 해시코드 값을 아래와 같이 갱신하도록 하자.
```
result = 31 * result + c
```
1. hashCode의 반환 값으로 result를 반환.
2. 작성 후 동치 인스턴스에 대해 같은 해시코드 값을 반환하는지 테스트 코드를 작성하도록 하자.
```
@Override
public int hashCode() {
	int result = Short.hashCode(areaCode);
	result = 31 * result + Short.hashCode(prefix);
	result = 31 * result + Short.hashCode(lineNum);
	return result;
}
```
```
// with Junit
@Test
public void hashCodeTest() {
    short areaCode = 10, prefix = 5, lineNum = 1;
    PhoneNumber p1 = new PhoneNumber(areaCode, prefix, lineNum);
    PhoneNumber p2 = new PhoneNumber(areaCode, prefix, lineNum);
    assertEquals(p1.hashCode(), p2.hashCode());
}
```
해시 충돌이 더 적은 구현을 원한다면 guava의 Hashing 구현을 참고하자.
Objects 클래스의 hash 메서드를 이용하면 해쉬 값을 쉽게 구할 수 있으나, 안타깝게도 해당 메서드는 박싱과 언박싱의 과정이 길어서 속도가 더 느리다고 한다.
만약 클래스가 불변인 상황에서 해시코드를 구하는 과정이 길거나 오래걸린다면 캐싱하는 방식을 고려해보면 좋다.
성능 고려한다고 해시코드 계산 시 핵심 필드를 생략하면 안된다. 해당 필드를 생략할 경우 해시 품질이 나빠져 특정 영역으로 몰릴 수 있기 때문이다.
해시코드 생성 규칙을 외부 사용자(API 사용하는)에게 알리지 않아야 추후에 변경이 발생했을 경우에 유연하게 변경이 가능하다.

ITEM 12 - toString을 항상 재정의하라

별도로 toString()을 재정의하지 않으면 클래스명@16진수의 해시코드가 반환된다. toString의 일반 규약에서는 간결하고 읽기 쉬운 형식의 정보를 반환해라라고 명세되어 있다고 한다. 또한, 모든 하위 클래스에서 toString을 재정의 하라고 말하고 있다.
쉽게 접할 수 있는 디버깅을 하는 상황이라고 생각해봐도 toString()을 재정의하여 유의미한 정보를 보면서 디버깅 하는 것과 그렇지 않은 경우는 많이 다르다. 결국 유의미한 정보를 반환하는 것이 관례이자 규약이라고 하면 이를 지키는 것이 좋을 것이다.

객체가 가지고 있는 정보는 가급적 전부 반환하는 것이 좋다.
반환하는 포맷에 대한 고민도 해봐야 한다.
- 포맷의 고정 유무와 상관 없이 유의미한 정보를 반환하고 의미를 분명하게 하는 것은 중요하다.

책의 예제에서는 앞의 PhoneNumber 클래스에서 toString()을 재정의한 예시를 보여주고 있는데, 참고하기 좋은 주석과 내용을 담고 있는 듯 하다.

    /**
     * 이 전화번호의 문자열 표현을 반환한다.
     * 이 문자열은 "XXX-YYY-ZZZZ" 형태의 12글자로 구성된다.
     * XXX는 지역 코드, YYY는 Prefix, ZZZZ는 가입자 번호다.
     * 각각의 대문자는 10진수 숫자 하나를 나타낸다.
     *
     * 전화번호의 각 부분의 값이 너무 작아서 자릿수를 채울 수 없다면,
     * 앞에서부터 0으로 채워나간다. 예컨대 가입자 번호가 123이라면
     * 전화번호의 마지막 네 문자는 "0123"이 된다.
     * @return
     */
    @Override
    public String toString() {
        return String.format("%03d-%03d-%04d", areaCode, prefix, lineNum);
    }

Google.AutoValue 프레임워크에서는 toString을 생성해준다고 하는데, Lombok을 사용했을 때랑 어떻게 차이가 나는지는 직접 해보지 않아서 잘 모르겠다.

ITEM 13 - clone 재정의는 주의해서 진행하라

Cloneable는 마커 인터페이스로 이를 구현한 객체는 복제가 가능한 객체임을 명시하는 용도로 사용한다.
Cloneable 인터페이스를 구현한 클래스의 인스턴스에서 clone을 호출하면 필드 전체를 복사한 객체를 반환한다. 만약 인터페이스를 구현하지 않을 경우 CloneNotSupportedException을 반환한다.
[중요] 메서드 하나 없는 Cloneable은 실상 Object.clone의 동작 방식을 결정하는데, 이례적인 사용으로 보이는 것이 인터페이스를 구현한 것만으로 상위 클래스 메서드 행위의 변경을 가하고 있기 때문이다.
Cloneable 인터페이스를 구현함으로써, 해당 객체를 사용하는 사용자 측에서는 clone() 메서드가 public으로 제공되며 이를 통해 복제를 할 수 있으리라 판단할 수 있다.
클래스의 계층 구조를 가지는 상황에서 하위 클래스가 만약 final 클래스라면 더 이상의 하위 클래스 상속은 발생하지 않기 때문에 관례는 무시해도 되겠지만, 만약 final 클래스의 clone 구현이 super.clone()을 호출하지 않는다면 Cloneable 인터페이스를 구현할 이유가 없다. 왜냐하면, 이는 위에서도 설명한대로 Cloneable 인터페이스가 Object.clone의 동작 방식을 결정하기 때문이고 이런 동작 방식 자체에 기댈 필요가 없기 때문이다.

    @Override
    public PhoneNumber clone() {
        try {
            return (PhoneNumber) super.clone();
        } catch (CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }

위 예제에서는 상위 타입에서 반환하는 Object타입이 아닌 PhoneNumber타입을 반환하고 있다. 이는 공변 반환 타이핑(covariant return typing)을 나타내고 있다. 다시 말해, 재정의한 메서드의 반환 타입은 상위 클래스의 메서드가 반환하는 타입의 하위 타입일 수 있다는 이야기이다.
clone() 메서드는 사실상 생성자와 같은 효과를 나타낸다. clone() 재정의 시 주의해야 하는 부분은 원본 객체에 변경이나 사이드 이펙트가 전달되지 않도록 복제된 객체의 불변성을 보장해야 한다.
clone() 재정의 시, 클래스에 배열 필드가 있다면 clone()을 호출해도 런타임 타입과 컴파일타임 타입 모두가 원본 배열과 똑같은 타입의 배열을 반환한다. 하지만, 깊은 복사가 진행되는 것이 아니기 때문에 주의해야 한다.

    @Test
    public void cloneTest() {
        short areaCode = 10, prefix = 5, lineNum = 1;
        PhoneNumber[] arr = new PhoneNumber[]{
            new PhoneNumber(areaCode, prefix, lineNum),
            new PhoneNumber(areaCode, prefix, lineNum)
        };
        PhoneNumber[] cloneArr = arr.clone();
        // Reference Check
        assertSame(arr[0], cloneArr[0]);
    }

위의 예제와 같이, 깊은 복사가 필요할 경우 재귀호출을 통하거나 혹은 배열의 요소를 일일이 순회/반복하여 복제하는 작업이 필요하다.
생성자에서는 일반적으로 하위 클래스에서 재정의 가능한 매서드를 호출하지 않는 것이 일반적인데, clone도 마찬가지이다. 재정의 시 변경되는 내용에 의해 원본 객체의 상태가 달라질 가능성이 크기 때문이다.
clone을 사용하는 것보다 복사 목적으로 사용하는 정잭 팩토리 메서드 혹은 복사 생성자를 사용하는 방법도 있다. 복사 생성자와 팩토리 메서드는 인터페이스 타입의 인자를 받을 수 있기 때문에, 객체 복사 시 유연한 타입 변경이 가능해진다.
[결론] clone()의 객체 생성 메카니즘은 위험천만하다. 차라리 복사 정적 팩토리 메서드 혹은 복사 목적의 생성자를 사용하자.

ITEM 14 - Comparable을 구현할지 고려하라

Comparable.compareTo()는 동치성 비교 및 순서까지 비교 가능하다.
Object.equals()와 마찬가지로 반사성, 대칭성, 추이성을 충족해야 한다. 또한, 해당 원칙을 제대로 지키지 않으면 equals와 마찬가지로 해당 구현을 이용하는 다른 클래스에서 예상하지 못한 결과를 반환할 수 있다.
Comparable을 구현하지 않은 필드나 표준이 아닌 순서로 비교하고 있는 상황이라면, Comparator를 대신 사용하자.
compareTo()에서 기본 타입을 비교 할때, 해당 기본 타입의 래퍼 타입의 compare()를 사용하여 비교하자. <, > 등의 연산자는 거추장스럽고 오류를 유발할 수 있다.
필드가 여러개 있는 클래스의 경우, 핵심 필드부터 차례대로 비교하도록 하자

    @Override
    public int compareTo(PhoneNumber o) {
        // 첫 번째 핵심 필드
        int result = Short.compare(areaCode, o.areaCode);
        if (result == 0) {
            // 두 번째 핵심 필드
            result = Short.compare(prefix, o.prefix);
            if (result == 0) {
                // 세 번째 핵심 필드
                result = Short.compare(lineNum, o.lineNum);
            }
        }
        return result;
    }

Comparator를 사용하는 방식은 FluentAPI 형식을 사용할 수 있어서 코드 자체가 우아하게 전개되지만, 성능 로스가 있다고 한다.
Comparator는 보조 메서드를 여러개 제공하고 있다. int보다 작은 타입의 경우 comparingInt를 사용하면 되고 float의 경우는 comparingDouble을 이용하면 된다.

스프링 부트 배치 #2 - ItemReader

oh-yes — Fri, 4 Jan 2019 00:27:48 +0900

SPRING_BATCH_#2

스프링 부트 배치 #2 - ItemReader

2.1 ItemReader

스프링 배치에서는 상황에 맞는 ItemReader 구현체를 제공
ItemReader는 쓰레드 세이프하지 않기 때문에(Non-Thread-Safe) 쓰레드 간 경합이 발생하지 않도록 주의해야 한다.
- 스프링 배치에서는 이를 보완하기 위해, SynchronizedItemStreamReader 구현체를 제공하며, 이를 생성할 수 있는 빌더 구현체인 SynchronizedItemStreamReaderBuilder 또한 제공한다.
Flat-File, Message-Queue(AMQP), Database(RDBMS, Mongodb) 등의 ItemReader 구현체들이 존재하며, 스프링 배치에서 제공하고 있는 구현체들은 링크를 통해 확인 가능하다.
스프링 배치에서 제공하지 않은, Custom ItemReader가 필요한 경우, ItemReader 인터페이스를 상속하게 ItemReader 구현체를 작성하면 된다.

2.2 ListItemReader

    @Bean
    @StepScope
    public ListItemReader<User> itemReader() {
        List<User> oldUsers = userRepository.findByUpdatedDateBeforeAndStatusEquals(
            LocalDateTime.now().minusYears(1), UserStatus.AVTIVE
        );
        return new ListItemReader<>(oldUsers);
    }

ListItemReader를 사용하면, 읽어온 리스트 데이터를 메모리에 올려두고 ItemReader.read()를 사용하여 하나씩 처리 작업을 수행한다.
하지만, 전체 데이터를 메모리에 올려두고 사용하는 것은 비효율적이기 때문에, 이를 나눠서 처리 할 수 있는 PagingItemReader 구현체를 사용 할 수 있다.

2.3 Database Readers

데이터베이스를 기준으로 ItemReader의 구현체를 나눌 때, Cursor Based ItemReader과 Paging Based ItemReader으로 나눌 수 있다.

Cursor Based ItemReader

관계형 데이터베이스에서 데이터를 Streaming 해오는 전통적인 방법으로 ResultSet을 통하여 커서를 유지하여 row 단위로 데이터를 가져오게 하는 방법을 많이 사용한다.
Spring Batch에서 Cursor Based ItemReader 구현은 초기화 시 커서를 열고 모든 호출에 대해 커서를 한 행 앞으로 이동시킨다. 커서 이동은 read()를 호출하면서 일어난다.
Spring Batch에서는 JdbcCursorItemReader 구현체를 제공하며 DataSource로부터 얻은 연결을 통하여 SQL 문을 실행하고 이를 ResultSet을 이용하여 커서 기반으로 데이터를 가져온다. JdbcCursorItemReader은 JdbcCursorItemReaderBuilder을 통하여 생성 할 수 있으며 예제 코드는 아래와 같다.

    @Bean
    public JdbcCursorItemReader<CustomerCredit> itemReader() {
            return new JdbcCursorItemReaderBuilder<CustomerCredit>()
                            .dataSource(this.dataSource)
                            .name("creditReader")
                            .sql("select ID, NAME, CREDIT from CUSTOMER")
                            .rowMapper(new CustomerCreditRowMapper())
                            .build();

    }

이 밖에도 아래와 같은 ItemReader 구현체도 스프링 배치에서 제공하고 있다. 상황에 맞게 구현하면 된다.
- HibernateCursorItemReader
- StoredProcedureItemReader

Paging Based ItemReader

Cursor 기반의 ItemReader의 경우, 데이터베이스 커넥션을 지속적으로 독점으로 사용하여 처리가 완료되는 시점까지 커넥션을 놓아주지 않기 때문에, 경우에 따라 성능상에 영향을 줄 수 있다. 처리 해야 할 데이터가 크다면 Cursor 기반이 아닌 Pagination 기반의 구현을 사용하는 것이 유리하다.
Pagination 기반의 ItemReader의 구현체는 JdbcPagingItemReader, JpaPagingItemReader이 있다.

JdbcPagingItemReader

JdbcPagingItemReader을 사용할 때, SQL 쿼리를 제공 PagingQueryProvider가 필요
데이터베이스마다 페이징을 처리하는 구문과 전략이 다르기 때문에 이를 지정해줘야 한다. 지원되는 각 데이터베이스 유형마다 다른 PagingQueryProvider를 사용해야합니다
또한 사용중인 데이터베이스를 자동으로 검색하고 적절한 PagingQueryProvider 구현을 결정하는 SqlPagingQueryProviderFactoryBean이 있다. SqlPagingQueryProviderFactoryBean은 select절, from절 및 sortKey 구문을 반드시 지정해야하며, where절은 필수가 아닌 옵션으로 설정 할 수 있다.

@Bean
public JdbcPagingItemReader itemReader(DataSource dataSource) {
        Map<String, Object> parameterValues = new HashMap<>();
        parameterValues.put("status", "NEW");

        return new JdbcPagingItemReaderBuilder<CustomerCredit>()
                                           .name("creditReader")
                                           .dataSource(dataSource)
                                           .queryProvider(queryProvider())
                                           .parameterValues(parameterValues)
                                           .rowMapper(customerCreditMapper())
                                           .pageSize(1000)
                                           .build();
}

@Bean
public SqlPagingQueryProviderFactoryBean queryProvider() {
        SqlPagingQueryProviderFactoryBean provider = new SqlPagingQueryProviderFactoryBean();

        provider.setSelectClause("select id, name, credit");
        provider.setFromClause("from customer");
        provider.setWhereClause("where status=:status");
        provider.setSortKey("id");

        return provider;
}

JpaPagingItemReader

JpaPagingItemReader를 통하여 지정한 페이지 사이즈만큼 데이터를 가져와서 처리 가능하다.
조회한 데이터는 JPA 영속성 컨텍스트상에서 DETACH상태이기 때문에, 영속성 컨텍스트의 관리 대상에서 벗어나게 된다.
JpaPagingItemReaderBuilder를 통하여 생성 가능하며, JpaPagingItemReader를 직접 생성하는 것도 가능하다.

    // JpaPagingItemReaderBuilder를 통한 생성
    @Bean
    public JpaPagingItemReader itemReader() {
            return new JpaPagingItemReaderBuilder<CustomerCredit>()
                                            .name("creditReader")
                                            .entityManagerFactory(entityManagerFactory())
                                            .queryString("select c from CustomerCredit c")
                                            .pageSize(1000)
                                            .build();
    }

    // 직접 생성
    @Bean(destroyMethod = "")
    @StepScope
    public JpaPagingItemReader<User> itemReader() {
        JpaPagingItemReader<User> jpaPagingItemReader = new JpaPagingItemReader<User>()
        jpaPagingItemReader.setQueryString(
            "select u from User as u where u.updatedDate < :updatedDate and u.status = :status"
        );
        HashMap<String, Object> map = new HashMap<>();
        map.put("updatedDate", LocalDateTime.now().minusYears(1));
        map.put("status", UserStatus.ACTIVE);
        jpaPagingItemReader.setParameterValues(map);
        jpaPagingItemReader.setEntityManagerFactory(entityManagerFactory);
        jpaPagingItemReader.setPageSize(CHUNK_SIZE);
        return jpaPagingItemReader;
    }

JpaPagingItemReader 내부에서 EntityManager를 할당 받아서 사용한다. EntityManagerFactory를 통하여 생성한 EntityManager에서 지정한 크기대로 데이터를 가져오기 때문에 예를 들어 10개씩 [읽기] -> [처리] -> [쓰기]를 하는 Step이 있다고 했을 때, 처음 이후의 처리에 대해 데이터 건너뛰기가 발생 할 수 있다.

청크 단위로 데이터를 가져오도록 기본 구현이 되어 있기 때문에 5개의 아이템을 건너 뛰게 되는 상황이 생길 수 있다. 실제 두 번째 단계에서 올바른 데이터를 가져오기 위해서는 OFFSET 5을 빼놓고 SQL문을 질의해야 한다.
OFFSET 적용을 피하기 위해서는 아래와 같이 JpaPagingItemReader의 getPage를 오버라이드하여 매번 첫 번째 페이지만 참조할 수 있도록 변경하면 된다.

JpaPagingItemReader<User> jpaPagingItemReader = new JpaPagingItemReader<User>() {
    @Override
    public int getPage() {
        return 0;
    }
};

RepositoryItemReader

PagingAndSortingRepository룰 활용한 ItemReader 구현체
RepositoryItemReader를 직접 생성하는 방법과 빌더 구현체인 RepositoryItemReaderBuilder를 통하여 RepositoryItemReader 인스턴스를 생성하는 방법이 있다.
구현 시, 주의해야 할 점은 Repository에서 Pageable 타입 혹은 하위 타입을 반환해야 하는점과 매소드 마지막 인자에 Pageable 인자를 포함해야 하는 점이다. 아래 예제 코드를 참고하자.

public interface UserRepository extends JpaRepository<User, Long> {
    // 1. Pageable 타입을 반환해야 하며, 인자 마지막에 Pageable 타입의 인스턴스를 포함해야 함.
    Page<User> findByUpdatedDateBeforeAndStatusEquals(LocalDateTime localDateTime, UserStatus status, Pageable pageable);
}

@Bean
@StepScope
public RepositoryItemReader<User> itemReader() {
    return new RepositoryItemReaderBuilder()
        .repository(userRepository)
        .methodName("findByUpdatedDateBeforeAndStatusEquals")
        .pageSize(CHUNK_SIZE)
        .maxItemCount(CHUNK_SIZE)
        .arguments(Arrays.asList(LocalDateTime.now().minusYears(1), UserStatus.ACTIVE))
        .sorts(Collections.singletonMap("idx", Sort.Direction.ASC))
        .name("repositoryItemReader")
        .build();
}

RepositoryItemReader도 마찬가지로 JpaPagingItemReader와 같이 지정해놓은 pageSize에 의거하여 건너뛰는 SQL 구문이 포함됨을 확인할 수 있었다. 이를 회피하기 위해서는 doPageRead 메소드를 오버라이드하여 첫 번째 페이지만 호출되도록 수정하면 된다. 아래 이미지의 주석 내용을 살펴보도록 하자

실무에서는 JPA를 원활하게 사용하기 위해, querydsl 혹은 Specification API를 사용하게 되는데, 이를 사용하기 위해서는 결국 Custom ItemReader를 구현해서 사용하는 방법밖에 없는거 같다.

참고

스프링 부트 배치 #1 - 개요/주요개념

oh-yes — Tue, 1 Jan 2019 21:50:57 +0900

SPRING_BATCH_#1

스프링 부트 배치 #1 - 개요/주요개념

개요

백엔드의 배치 처리 기능을 구현하는 데 사용하는 프레임워크.
부트 배치의 경우, 스프링 배치의 설정 요소들을 간편화시켜 스프링 배치를 빠르고 쉽게 사용할 수 있도록 구성.
- 배치란, 순차적으로 자료를 처리한다는 뜻으로 일괄 처리와 같은 뜻

Why Spring Batch?

대용량 처리 최적화되어 있고, 고성능을 발휘
로깅. 통계 처리, 트랜잭션 관리 등 필수 기능 지원
예외 및 비정상 동작에 대한 방어 기능
개발자는 Spring Batch 프로그래밍 모델을 사용하여 비즈니스 로직에 집중하고 프레임워크가 인프라를 관리하도록 함.

주의사항

복잡한 구조와 로직을 피해야 함
데이터를 직접 다루는 코드가 많으므로, 무결성을 유지할 수 있는 방어적인 방법을 사용해야 함.
I/O 사용을 최소화 해야 한다. 잦은 I/O 발생은 배치 어플리케이션 성능에 영향을 줄 수 있기 때문이다.
- Minimize system resource use, especially I/O. Perform as many operations as possible in internal memory.
스프링 부트 배치는 별도의 스캐줄링 기능을 제공하지 않는다. 이에 따라, 별도의 스케줄링 구현체를 사용해야 한다.
- 쿼츠, 스프링 스캐줄러 등을 사용해야 함.
실제 환경과 비슷한 데이터 볼륨을 가지고 테스트를 함으로써, 처리 안정성을 높히는 것이 좋다.

배치 처리 절차

읽기: 데이터베이스, 파일 등에서 데이터를 읽는다.
- Reads a large number of records from a database, file, or queue.
처리: 읽은 데이터를 처리/가공
- Processes the data in some fashion.
쓰기: 처리/가공한 데이터를 별도의 저장소에 저장
- Writes back data in a modified form.

Job과 Step은 1:N의 관계로, 하나의 Job에 여러 개의 Step으로 처리하는 프로세스를 가진다. 각각 Step은 ItemReader, ItemProcessor, ItemWriter를 가지고 있으며, Step과는 1:1 관계를 가진다.

1. Job

처리 과정 하나를 가리키는 객체로 여러 개의 Step을 포함할 수 있다. Step들의 컨테이너 역할을 수행한다.
Job 객체를 만드는 빌더 클래스는 여러 개 있으며, 여러 빌더를 통합한 JobBuilderFactory를 통하여 원하는 Job을 쉽게 생성할 수 있음.

@Bean
public Job footballJob() {
	return this.jobBuilderFactory.get("footballJob")
				.start(playerLoad())
				.next(gameLoad())
				.next(playerSummarization())
				.end()
				.build();
}

JobBuilderFactory.get()을 호출하게 되면, 새로운 JobBuilder 인스턴스를 반환함. JobBuilder를 생성하는 과정에서 JobRepository를 주입받게 되는데, JobBuilderFactory에서 생성되는 모든 JobBuilder가 동일한 JobRepository를 사용하게 된다.
JobBuilerFactory에서 JobBuilder를 생성하며 생성한 빌더를 통하여 Job을 생성할 수 있다.
JobBuilder는 직접 Job을 생성하는 것이 아니라, 별도의 구체적인 JobBuilder를 통하여 Job을 생성하게 된다. Job을 생성할 수 있는 여러 상황을 고려하여 이렇게 구현되어 있는듯 보이며, 매소드 체이닝을 통하여 원하는 내용을 명시하면 쉽게 처리 할 수 있다.

@Autowired
private JobBuilderFactory jobBuilderFactory;

@Bean
public Job simpleJob() {
		// 1. simpleJob 이라는 이름을 가진 Job을 생성할 수 있는 JobBuilder 인스턴스 반환
	return jobBuilderFactory.get("simpleJob")
		// 2. Step을 주입, Step혹은 Flow를 파라메터로 받아서 구체적인 빌더를 생성할 수 있다.
		.start(simpleStep())
		// 3. build()를 호출하여 "simpleJob"의 이름을 가지는 Job을 생성
		.build();
}

1.1 JobInstance

하나의 Job의 실행 단위, JobExecution을 여러개 가질 수 있음

1.2 JobExecution

JobInstance에 대한 한 번 실행을 나타내는 객체. Job 실행에 대한 정보를 담고 있는 도메인 객체로 JobInstance, 실행 상태, 시작 시간, 종료 시간, 실패 메세지 등 정보를 담고 있음.

1.3 JobParameter

Job이 실행될 떄 필요한 인자를 Map 타입으로 저장하는 객체. JobInstance와 1:1 관계이며, 사용 할 수 있는 데이터 타입은 Long, String, Date, Double 등이 있다.
JobInstance를 구분하는 기준으로 사용될 수 있다.
- JobInstance = Job + identifying JobParameters

2. Step

실질적인 Job 처리를 담당. 필요한 정보를 담고 있는 도메인 객체이며 모든 Job은 여러 개의 Step을 가질 수 있다.

2.1 StepExecution

Job에 JobExecution이 있듯이, Step에도 이에 대응하는 StepExecution이 존재한다. 해당 Step의 실행 정보를 담고 있다.

3. JobRepository

JobRepository는 배치 처리 정보를 담고 있는 객체로, Job의 실행 횟수 및 시간 정보 등의 메타 정보를 가지고 있다. Step의 실행정보를 담고 있는 StepExecution도 가지고 있으며, 전체 메타 데이터를 가지고 있는 객체라고 생각하면 된다.

4. JobLauncher

Job, JobParameter와 함께 배치를 시작하는 인터페이스로 사용. 인터페이스의 매소드는 run()만 존재함.

5. ItemReader

Step에서 데이터를 읽어오는 역할을 수행. FILE, DB, QUEUE 등에서 데이터를 읽어 올 수 있다.

6. ItemProcessor

읽어온 데이터를 처리하는 인터페이스. Input과 Output에 대한 타입 명시가 가능

7. ItemWriter

이전 단계에서 처리한 데이터를 저장하는 인터페이스. List 인터페이스를 통하여 지정한 타입의 데이터를 받아오며 CHUNK 단위로 데이터를 받아온다.

참고자료

[JavaScript] 프로토타입 && 프로토타입 체이닝

oh-yes — Sun, 17 Jul 2016 22:50:14 +0900

prototype

JavaScript_Prototype & Prototype Chainning

자바스크립트는 프로토타입 기반의 객체지향 언어로 일반적인 객체 지향 언어와 다른 특성을 가지고 있다.

특히, 자바스크립트는 기본적으로는 원시타입과 참조타입으로 데이터 타입을 나눌 수 있지만, 엔진 내부에서는 원시타입 역시 객체로 오토박싱(AutoBoxing) 을 시켜서 객체형으로 변환하여 변수를 관리한다.(즉, 원시타입도 어떤 생성자 함수의 인스턴스이다.)

암묵적인 프로토타입 링크(implicit prototype link)

자바스크립트의 모든 객체는 프로토타입 (링크)객체를 가지고 있다. 프로토타입 객체란, 자신을 생성한 생성자 함수의 프로토타입 객체를 가리키는 일종의 링크 객체로 자바스크립트에서 상속을 구현하는 핵심 메카니즘이라고 할 수 있다.

ECMA 표준에서는 이를 암묵적인 프로토타입 링크 라고 명칭한다.

function Person(name){
    this.name = name;
}
var foo = new Person('Choi');
 
foo.__proto__ === Person.prototype

위 코드에서 foo 객체(인스턴스)의 프로토타입 링크는 foo 객체의 생성자인 Person 함수 객체의 [프로토타입] 영역을 가리키가 된다. 즉, 생성자 함수의 프로토타입 영역이 인스턴스의 프로토타입 링크가 가리키게 되는 객체가 되는 것이다.

Chrome에서는 proto 라는 프로퍼티가 프로토타입 링크 역할을 하는 객체 프로퍼티가 된다. 즉, 숨겨진 프로토타입 링크 역할을 수행하게 되는 것이다.

생성자 함수로 생성된 객체뿐만 아니라, 객체 리터럴도 프로토타입 링크를 가지게 되는데 왜냐하면 객체 리터럴 역시 내부적으로는 Object() 생성자 함수의 객체(인스턴스)이기 때문에, Object.Prototype 영역을 가리키는 암묵적인 프로토타입 링크를 가지게 된다.

// 객체 리터럴 생성 
var obj = {};
 
// 객체 리터럴도 Object 생성자 함수의 인스턴스이기 때문에 가리키는 프로토타입 링크와 프로토타입 영역은 동일한 객체를 바라보게 된다. 
obj.__proto__ === Object.prototype

결과적으로, 기억해야 할 부분은 바로 객체리터럴 역시 Object() 생성자 함수의 인스턴스 라는 점이다.

프로토타입 체인(Prototype Chainning)

자바스크립트에서 객체의 속성이나 매소드를 참조할 때, 객체에 해당 속성과 매소드가 없을 경우 프로토타입 링크 를 따라 프로토타입 객체의 프로퍼티를 차례대로 찾아가는 것을 프로토타입 체인 이라고 한다.

객체의 속성을 읽거나 매소드를 호출(실행)할 때 프로토타입 체인이 작동한다

var myObj = {};
myObj.name = "Choi";
 
myObj.hasOwnProperty('name'); // true 
myObj.hasOwnProperty('age'); // false

위 코드에서 hasOwnProperty() 매소드를 사용할 수 있는 근거도 위에서 말한대로 객체 리터럴 역시 Object() 생성자 함수의 인스턴스이기 때문에, 객체의 프로토타입 링크는 Object() 생성자 함수 객체의 프로토타입 영역을 참조하게 된다. 그래서 기존 Object() 생성자 함수의 프로토타입 영역에 정의되어 있는 매소드인 hasOwnProperty(Native 영역의 함수)를 사용할 수 있는 것이다.

String.prototype.__proto__ === Object.prototype
Number.prototype.__proto__ === Object.prototype

이 밖에도, Number, String, Function 등의 생성자 함수들도 각자 프로토타입 영역을 가지고 있는데 프로토타입 영역은 곧 객체 이기 때문에 객체의 프로토타입 링크를 가지고 있게 된다. 이때 프로토타입 링크가 바라보게 되는 곳이 바로 Object()의 프로토타입 영역이기 때문에 실질적으로 모든 객체(인스턴스)에서 Object.prototype에 정의한 매서드들을 사용할 수 있는 것이 된다.

프로토타입 && this

프로토타입 객체의 속성(프로퍼티)가 매서드인 경우, 결과적으로 this 키워드는 매서드를 호출한 객체를 바라보게 된다. 말이 어려운데 아래 예제를 살펴보면 쉽게 이해할 수 있을 것이다.

function Animal(name){
    this.name = name;
}
 
Animal.prototype.sayHello = function(msg){
    return alert(this.name + "이 말합니다. " + msg);
}
 
var tiger = new Animal('타이거');
tiger.sayHello('난 호랭이야!'); // 타이거가 말합니다. 난 호랭이야!

sayHello를 호출한 객체는 바로 tiger 객체이기 때문에, sayHello 매서드 내부의 this 키워드가 가리키는 것은 바로 tiger 객체 자체를 참조하게 된다.(이것은 일종의 자바스크립트의 법칙과도 같다.) 즉, 호출한 객체의 자체를 바라보게 되는 것인데 살짝 예제를 틀어서보면 재밌는 부분을 발견할 수 있다.

Animal.prototype.name = "강아지";
// 강아지가 말합니다. 난 강아지인데?!!! 
Animal.prototype.sayHello('난 강아지인데?!!!');

첫 번쨰 예제와 두 번쨰 예제의 차이점은 sayHello() 매서도를 호출한 객체가 달라졌다는 부분이다. 다시 말해, 첫 번째 예제에서 sayHello()를 호출한 객체는 tiger 객체이기 때문에 this 키워드가 가리키는 객체는 tiger 객체가 되는 것이고, 두 번째 예제에서 sayHello()를 호출한 객체가 Animal.prototype 객체이기 때문에 this가 가리키는 녀석이 바로 Animal.prototype이 되는 것이다.

정리해서, 객체의 속성(프로퍼티)가 매소드일 경우 이를 호출한 this는 호출한 객체에 바인딩된다 가 결론이다.

디플트 프로토타입 링크

함수를 작성하면 기본적으로 디폴트 프로토타입 영역이 생성이 된다. 이 디폴트 프로토타입 영역은 constructor 라는 속성을 가지는데 constructor 단어 그 자체의 의미처럼 작성한 함수 객체를 참조하는 프로퍼티이다. 그런데 재밌는 부분은 이 디폴트 프로토타입 객체는 개발자에 의해서 변경이 가능하다는 점이다. 그렇기 때문에 프로토타입 객체의 참조 관계를 임의로 개발자가 변경하여 사용하는 것이 가능하다.

function Weapon(name){
    this.name = name;
}
var machineGun = new Weapon('머신건');
 
// 1번 문제 
machineGun.__proto__.constructor === Weapon.prototype.constructor
 
Weapon.prototype = {
    sayWeaponName : function(){
        return this.name;
    }
}
 
var newGun = new Weapon('뉴건');
 
// 2번 문제 
machineGun.__proto__ === newGun.__proto__

첫 번째 문제의 경우, Weapon 생성자 함수의 인스턴스인 machineGun의 프로토타입 링크는 Weapon 생성자 함수 객체의 프로토타입 영역을 가리키고 있기 때문에 두 객체의 constructor 는 동일한 녀석인 Weapon 생성자 함수를 가리키게 된다.

두 번째 문제의 경우, machineGun의 프로토타입 링크가 끊어지지 않은 상태에서 Weapon 함수 객체의 프로토타입 영역을 다른 객체로 대체했다. 이렇게 되면 기존 machineGun의 프로토타입 링크는 그대로 유지되는 반면에 새롭게 생성되는 newGun 객체의 프로토타입 링크는 새롭게 정의된 프로토타입 객체를 바라보게 되면서 2번 문제의 경우 다른 객체를 바라보게 됨에 따라 "false"인 결과가 나오게 된다.

참고

[Node.js] PM2_프로세스 관리 도구

oh-yes — Fri, 15 Jul 2016 14:54:01 +0900

pm2.md

PM2

Node.js 애플리케이션용 프로덕션 프로세스 관리자
로드 밸런서 기본 제공
앱을 항상 작동 상태로 유지
시스템 가동 중단 없이 앱을 다시 로드
- MAX MEMORY RESTART 기능을 제공하는데 커맨드라인/JSON/코드(JS) 등으로 설정 가능하다.
일반적인 시스템 관리 태스크를 쉽게 처리 가능
애플리케이션 로깅, 모니터링 및 클러스터링을 관리
- 클러스터 모드의 경우, 여러개의 프로세스를 생성해놓고, 이를 PM2에서 자동으로 로드밸런싱으로 지원해주기 때문에, 앞단 웹 서버(Nginx, Apache Server 등)에서 프록시 설정만 간단히 해줘도 된다.

설치

$ [sudo] npm install pm2 -g

기본 사용

앱을 시작할때 즉시 백그라운드로 보내진다.

$ pm2 start app.js

메뉴얼을 읽으면서 가장 괜찮다고 생각한 부분이 바로 다른 스크립트 언어도 같이 지원하는 부분이었다.

$ pm2 start echo.pl --interpreter=perl
 
$ pm2 start echo.coffee
$ pm2 start echo.php
$ pm2 start echo.py
$ pm2 start echo.sh
$ pm2 start echo.rb

어플리케이션 설정 파일 사용

JSON, YML 포맷으로 만들어진 파일을 일종의 시작 프로파일로 사용할 수 있다.

$ pm2 start start.yml(start.json)

start.yml

apps:
  - script   : app.js
    instances: 4
    exec_mode: cluster
  - script : worker.js
    watch  : true
    env    :
      NODE_ENV: development
    env_production:
      NODE_ENV: production

start.json

{
      "apps" : [
            {
            "name"       : "bash-worker",
            "script"     : "./a-bash-script",
            "exec_interpreter": "bash",
            "exec_mode"  : "fork_mode"
            },
            {
            "name"       : "ruby-worker",
            "script"     : "./some-ruby-script",
            "exec_interpreter": "ruby",
            "exec_mode"  : "fork_mode"
            }
      ]
}

CheatSheat

출처 : PM2 공식 홈페이지

# Fork mode 
$ pm2 start app.js --name my-api # 프로세스 네임 지정 
 
# Cluster mode 
$ pm2 start app.js -i 0     # 가용한 CPU 갯수만큼 클러스터 확장 
$ pm2 start app.js -i max   # 위 설정과 동일하지만 곧 Deprecated 예정? 
 
# Listing 
$ pm2 list               # 모든 프로세스 리스트/상태 확인 
$ pm2 jlist              # 모든 프로세스 리스트/상태 확인(JSON) 
$ pm2 prettylist         # 모든 프로세스 리스트/상태 확인(Beatiful JSON) 
 
$ pm2 describe 0         # 특정 프로세스 정보 확인 
$ pm2 monit              # 모든 프로세스 모니터링 
 
# Logs 
 
$ pm2 logs [--raw]       # Display all processes logs in streaming 
$ pm2 flush              # Empty all log file 
$ pm2 reloadLogs         # Reload all logs 
 
# Actions 
 
$ pm2 stop all           # Stop all processes 
$ pm2 restart all        # Restart all processes 
 
$ pm2 reload all         # Will 0s downtime reload (for NETWORKED apps) 
$ pm2 gracefulReload all # Send exit message then reload (for networked apps) 
 
$ pm2 stop 0             # Stop specific process id 
$ pm2 restart 0          # Restart specific process id 
 
$ pm2 delete 0           # Will remove process from pm2 list 
$ pm2 delete all         # Will remove all processes from pm2 list 
 
# Misc 
 
$ pm2 reset <process>    # Reset meta data (restarted time...) 
$ pm2 updatePM2          # Update in memory pm2 
$ pm2 ping               # Ensure pm2 daemon has been launched 
$ pm2 sendSignal SIGUSR2 my-app # Send system signal to script 
$ pm2 start app.js --no-daemon
$ pm2 start app.js --no-vizion
$ pm2 start app.js --no-autorestart

참고

[Node.js] Express.js 기본 개념 및 내용 정리

oh-yes — Wed, 6 Jul 2016 19:07:40 +0900

readme.md

Express.js

HTTP 요청에 대하여 라우팅 및 미들웨어 기능을 제공하는 웹 프레임워크

라우팅(routing) 은 기본적으로 어플리케이션 서버에서 경로를 제어하는 목적

목적지까지 갈 수 있는 여러 경로 중 한 가지 경로를 설정해 주는 과정.
미들웨어(middleware) 는 중간에 껴넣는다는 의미로 부가적인 기능이나 처리를 제공하는 목적

이기종의 환경을 연결해주는 소프트웨어를 가리킴

▶ Express.js에서 사용할 수 있는 중간처리 목적의 소프트웨어/모듈
▶ 최종 요청 핸들러 이전의 Express 라우팅 계층에 의해 호출되는 함수

설치

npm init
npm install express --save

Express Generator

npm install express-generator -g

express -h

기본적인 어플리케이션 골격 생성
handlebars, hogan, jade 등 템플릿 엔진 추가 가능
css, .gitignore 등 옵션 추가 가능

기본 라우팅 & 핸들러

라우팅(Routing) 이란 URL(URI) 요청에 따라 어플리케이션이 응답하는 방법을 결정.

var express = require('express');
var app = express();
 
/**
 * METHOD : Http Method(GET, POST, PUT, DELETE, PATCH 등)
 * PATH : [경로]
 * HANDLER : [경로 접근 시, 처리 핸들러]
 */
app.METHOD(PATH, HANDLER)

라우팅 형태

라우팅 URL 패스는 기본적으로 문자열뿐만 아니라 문자열 패턴 혹은 정규식으로 표현이 가능하다.(path-to-regexp)

// Sample 
app.get('/home', function(req, res){
      res.send("Hello World");
})
 
// abcd, abbcd 및 abbbcd 
app.get('/ab+cd', function(req, res) {
      res.send('ab+cd');
});
 
// abcd, abxcd, abRABDOMcd 
app.get('/ab*cd', function(req, res) {
      res.send('ab*cd');
});
 
// abe 및 abcde 
app.get('/ab(cd)?e', function(req, res) {
      res.send('ab(cd)?e');
});

라우팅 핸들러(콜백 함수)는 하나 이상으로 설정이 가능하다.(next 인자를 반드시 설정해야 한다.) 라우팅에 대한 핸들링을 2개 이상을 등록하여 사용할 수 있기 때문에 굳이 하나의 핸들러에 모든 로직이나 코드를 넣어서 처리할 이유가 전혀 없다.

var cb0 = function (req, res, next) {
      console.log('CB0');
      next();
}
 
var cb1 = function (req, res, next) {
      console.log('CB1');
      next();
}
 
app.get('/example/a', [cb0, cb1], function (req, res, next) {
      console.log('the response will be sent by the next function ...');
      next();
}, function (req, res) {
      res.send('Hello from A!');
});
 
app.get('/example/b',
function (req, res, next) {
      console.log('first handler');
      next();
},
function (req, res) {
      console.log('second handler');
      res.send('Hello from B!');
});

모듈식으로 등록하는 개념으로 express.Router 매소드를 활용하여 파일 단위로 모듈화를 시켜서 라우팅을 등록할 수 있다.

// [birds.js] 
var express = require('express');
var router = express.Router();
 
// middleware that is specific to this router 
router.use(function timeLog(req, res, next) {
      console.log('Time: ', Date.now());
      next();
});
// define the home page route 
router.get('/', function(req, res) {
      res.send('Birds home page');
});
// define the about route 
router.get('/about', function(req, res) {
      res.send('About birds');
});
 
module.exports = router;

위에서 작성된 bird.js을 하단과 같이 로드하면 /birds/, /birds/about 으로 라우팅이 등록되어 사용할 수 있다. 모듈 단위(파일)로 작성하여 등록하는 방식이기 때문에, 라우팅 관리가 편하며 추후에 라우팅을 추가한다고 해도 확장성이 있어 보인다.

var birds = require('./birds');
app.use('/birds', birds);

미들웨어

Application
- 어플리케이션 전체 영역 에서 처리 가능. 앱에 대한 Request가 발생할 떄 마다 실행

Router

라우터 단위 로 Request가 발생하면 실행

var app = express();
var router = express.Router();
 
router.use(function (req, res, next) {
      console.log('Time:', Date.now());
      next();
});

위에서 설명했던 라우팅 방식 중 모듈 단위(파일) 라우팅 시 사용하면 유용

Error Handling

기본적으로 4개의 인자가 필요(인자의 숫자로 오류 처리 미들웨어 판별)

app.use(function(err, req, res, next) {
      console.error(err.stack);
      res.status(500).send('Something broke!');
});

Basic(Default)

express.static(root, [options])

어플리케이션 정적 자원 설정(CSS,HTML,JS) 등
2개 이상의 정적 디렉토리 설정 가능

var options = {
  dotfiles: 'ignore',
  etag: false,
  extensions: ['htm', 'html'],
  index: false,
  maxAge: '1d',
  redirect: false,
  setHeaders: function (res, path, stat) {
    res.set('x-timestamp', Date.now());
  }
}
 
app.use(express.static('public'));
app.use(express.static('uploads'));
app.use(express.static('files'));

Third-Party
- Application Level 및 Router Level에 서트파티 미들웨어 설정이 가능하다
- 대표적인 미들웨어 종류를 참고하여 설정하자.
- Express의 경우, 초기버젼과 다르게 대부분 서드파티 미들웨어 사용을 권고하고 있다. 그렇기 때문에, 자주 사용하는 조합을 찾아놓고 사용하는 것이 개발 속도면에서나 안정성면에서나 유리하다.

Request & Response

Express 어플리케이션 처리 흐름

미들웨어를 선 처리
개별 라우팅 주소 값에 맞는 라우팅 핸들러를 실행
HTTP 요청에 대한 응답을 실행

기본적으로, Request 및 Response는 객체이며 HTTP 요청과 응답과 관련된 매서드와 프로퍼티(상태값 등)을 가지고 있다. Query String, Parameter, Body, HTTP Header 기타 등등 심지어 xhr 요청 유무까지 확인 가능한 프로퍼티가 있다. 너무 많기에 관련된 내용은 하단 링크를 통하여 확인하도록 하자

요청 프로퍼티 & 매소드

응답 프로퍼티 & 매소드

Template Engine

// Setting 
app.set('view engine', 'jade');

// Router 
app.get('/', function (req, res) {
      res.render('main', {msg : "HelloWorld!"});
});

express에서 자주 사용하는 뷰 템플릿 엔진은 하단과 같다.

React같이 View만을 전문적으로 처리하는 라이브러리가 유행이고, 동형(Isomorphic) 처리라고 하여 서버 사이드에서도 클라이언트 사이드(브라우저)와 같이 뷰를 렌더링하자 라는 테마가 요즘 유행이다.(하지만 나에게는 너무 어렵다…어려워…) 마지막으로 배우고 익혔던 AngularJS도 좋지만 이 녀석은 사용해야 할 성격이 분명히 존재하는거 같다(SEO가 필요한 사이트에서는 쥐약인듯)

아무튼 express에서 뷰 렌더링이 필요하다면 위 3개정도가 가장 현실적으로 사용할만한 템플릿 엔진인것은 분명하다. 만약 뷰단까지 같이 셋팅이 되어 있는 프로젝트가 필요하다면 Yeoman이나 Mega Boilerplate에서 필요한 리소스를 확보하면 된다.

참고

[Sublime Text 3] 다시 설치하기.

oh-yes — Mon, 30 May 2016 14:39:11 +0900

기존 서브라임 텍스트2에서 지원 안되는 플러그인이 많기 때문에,

(서브라임 2나오고 계속 썼으니 대충 1년은 넘게 사용하다가 신규 버젼으로 설치)

새로이 서브라임 텍스트 3버젼으로 셋팅했음.

1. 최신 빌드 버젼으로 설치

- Portable 버젼을 추천함.

https://www.sublimetext.com/3

2. Package Control 설치

- view > show console 을 누르면 하단에 콘솔 입력창에 뜸. 해당 입력창에 하단 URL에서 제공하는 파이썬 코드를 입력하면 됨.

https://packagecontrol.io/installation

3. 플러그인 및 필요 패키치 설치

- SidebarEnhancements

- Material Theme(http://equinusocio.github.io/material-theme/)

- ConvertToUTF8(인코딩 깨짐 설정)

- IMEsupport(한글 입력 관련)

- Babel(ES6 highlighting)

4. 단축키 설정(Preferences > key bindings - user)

※ 본인에게 필요한 단축키 값은 여기에 넣어놓으면 됨.

{"keys": ["ctrl+alt+m"], "command": "toggle_menu"} // Reindent(재정렬)

{"keys": ["ctrl+alt+m"], "command": "toggle_menu"} // Menu Toggle(상단 메뉴 Toggle)

※ 설정 예시

1
2
3
4
5
[
   { "keys": ["ctrl+shift+i"], "command": "reindent"}, // Reindent
   { "keys": ["ctrl+alt+m"], "command": "toggle_menu"} // Menu Toggle    
]
 
Colored by Color Scripter
cs

5. 기타 유저 설정

※ Material 테마 설치 후 사이드바 테마 적용이 안되는 문제가 있다.(문제까지는 아니고 설정을 변경을 안해놓는게 디폴트인거 같다.)

"theme": "Material-Theme.sublime-theme"

-> 상단 json 내용을 넣어줘야지 사이드바까지 제대로 적용이 됨.

-> 정상 테마 적용 후 화면

※ 설정 예시

- Material theme 설정은 하단 참고 URL에 있으니, 가서 본인에게 맞는 설정으로 변경하면 됨.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
{
    "always_show_minimap_viewport": true,
    "bold_folder_labels": true,
    "color_scheme": "Packages/Material Theme/schemes/Material-Theme-OceanicNext.tmTheme",
    "font_face": "Monaco",
    "font_options":
    [
        "gray_antialias",
        "subpixel_antialias"
    ],
    "font_size": 13,
    "ignored_packages":
    [
        "Vintage"
    ],
    "indent_guide_options":
    [
        "draw_normal",
        "draw_active"
    ],
    "line_padding_bottom": 3,
    "line_padding_top": 3,
    "material_theme_accent_blue": true,
    "material_theme_accent_cyan": true,
    "material_theme_accent_indigo": true,
    "material_theme_accent_lime": true,
    "material_theme_accent_orange": true,
    "material_theme_accent_pink": true,
    "material_theme_accent_purple": true,
    "material_theme_accent_red": true,
    "material_theme_accent_yellow": true,
    "material_theme_bold_tab": true,
    "material_theme_compact_panel": true,
    "material_theme_compact_sidebar": true,
    "material_theme_contrast_mode": true,
    "material_theme_disable_fileicons": true,
    "material_theme_disable_folder_animation": true,
    "material_theme_disable_tree_indicator": true,
    "material_theme_panel_separator": true,
    "material_theme_small_statusbar": true,
    "material_theme_small_tab": true,
    "material_theme_tabs_autowidth": true,
    "material_theme_tabs_separator": true,
    "overlay_scroll_bars": "enabled",
    "theme": "Material-Theme.sublime-theme"
}
 
Colored by Color Scripter
cs

6. 참고

http://equinusocio.github.io/material-theme/

http://www.slideshare.net/webzealer/sublime-text-editor-3-v14

http://stackoverflow.com/questions/27931448/why-do-sublime-text-3-themes-not-affect-the-sidebar

https://laracasts.com/discuss/channels/general-discussion/sublime-text-sidebar-styling

https://www.sitepoint.com/essential-sublime-text-javascript-plugins/

[Maven] 주요 개념 / 내용 정리

oh-yes — Tue, 19 Apr 2016 17:12:26 +0900

# Ant vs Maven

1. Ant는 비교적 자유도가 높은 편

(Ant : 전처리 / 컴파일 / 패키징 / 테스팅 / 배포 가능)

2. Maven은 정해진 라이프사이클에 의하여 작업 수행하며, 전반적인 프로젝트 관리 기능까지 포함하고 있음.

(Build Tool + Project Management)

# Maven Pattern

1. Build : Source/Test Code Compile

▼

2. Package : WAR/JAR ETC package

▼

3. Test : Unit Test, Test Result Check

▼

4. Report : Build, Package, Test 결과 정리 및 문서화(Report 생성)

▼

5. Release : Build 후 생성된 결과물(Artifact)를 Local / Remote 환경(저장소)에 배포

# Maven Key Concept / Keyword

[MAIN]

1. Plugin : Goal의 집합(Goals) / 메이븐에서 실질적인 실행을 담당

2. LifeCycle : 기본 라이프사이클 / Clean 라이프 사이클 / Site 라이프사이클

3. Dependency : 라이브러리 의존성 관리(의존성 전이 / 스코프 등)

4. Profile : 배포 환경 정의(환경에 따른 배포 내용 정의 가능)

5. POM(Project Object Model)

[그 밖에]

1. Archetype : Template Project를 지칭

2. Phase : 라이프사이클의 각 단계를 지칭

(compile / test / package / install / deploy)

## Maven Project Structure Example

| |--resources

| |--test
|- pom.xml

# Maven Plugin Reference URL

(http://maven.apache.org/plugins/index.html)

- resource : http://maven.apache.org/plugins/maven-resources-plugin/
- clean : http://maven.apache.org/plugins/maven-clean-plugin/

- site : http://maven.apache.org/plugins/maven-site-plugin/

- install : http://maven.apache.org/plugins/maven-install-plugin/

- compiler : http://maven.apache.org/plugins/maven-compiler-plugin/
- deploy : http://maven.apache.org/plugins/maven-deploy-plugin/

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#########################################
## Maven CommandLine Interface Example ##
#########################################
 
1. 기본 실행
mvn [option] [phase] [plugin:goal]
 
- 기본적으로 option, phase, plugin 등 조합하여 사용 가능
  ex) mvn clean test
      mvn clean package
      mvn clean install
      mvn clean dependency:copy-dependencies package
 
 
2. clean 라이프사이클, clean phase 실행
mvn clean
 
3. 기본 라이프사이클
- 각 phase는 이전 단계 및 관련 플러그인의 실행과 관련있음.
mvn compile
    test
    package
    install
    deploy
 
 
4. 최상위 pom.xml 내용 확인
- 기본적으로 최상위 pom.xml의 내용을 모두 상속받기 때문에, 확인 필요함.
mvn help:effective-pom
 
 
5. 의존 라이브러리 리소스 복사(PROJECT#1/targer/dependency)
mvn dependency:copy-dependencies
 
6. 의존성 트리 내용
mvn dependency:tree

7. eclipse 플러그인 사용 예제
   mvn eclipse:eclipse   : .classpath, .project 파일 생성(이클립스 import 가능)
   mvn eclipse:clean     : 위 파일 삭제

# 기타 참고 내용
- pom.xml -> <repositories> 설정에서 <snapshots>, <release> 쪽 설정을 적절하게 바꿔주지 않으면 새로 올려오는 스냅샷이나 릴리즈
를 기본적으로 가져오기 때문에, 의도치 않은 오류가 발생할 수 있다.

[예시]

<repositories>
    <repository>
        <id>you-snapshots</id>
        <url>http://host/repo/snapshots</url>
        <snapshots>
            <updatePolicy>always / daily / never</updatePolicy>
        </snapshots>
        <releases>
            <updatePolicy>always / daily / never</updatePolicy>
        </releases>
    </repository>
</repositories>

참고 : http://maven.apache.org/ref/3.2.2/maven-settings/settings.html

[Mybatis] Stored Procedure 호출 샘플

oh-yes — Mon, 29 Feb 2016 17:38:34 +0900

1. mapper.xml Sample

{ call sp_test_procedure(

#{p1},

#{p2,jdbcType=VARCHAR},

#{p3},

#{p4,jdbcType=VARCHAR},

#{p5,jdbcType=VARCHAR}

)

}

</update>

- statementType 속성 값에 "CALLABLE"을 지정

- SELECT, INSERT, DELETE, UPDATE, SELECTKEY 구문에서 사용 가능.

- 리턴 받는 내용이 있으면, #{} 안 내용을 하단과 같이 기술

"#{p1, mode=OUT, jdbcType=CURSOR, javaType=ResultSet, resultMap=test}"

※ reseultmap 구문 지정해줘야 함.

ex) "<resultMap id="procTestMap" type="HashMap"></resultMap>"

2. Java Code Sample(DAO)

Map testMap = new HashMap<String, Object>();

testMap.put("p1", 378);

testMap.put("p2", "01001");

testMap.put("p3", "100");

testMap.put("p4", "테스트");

testMap.put("p5", "SYSTEM");

MySql.update("mapper.testProc", testMap);

System.out.println(testMap);

3. 참고

- http://www.mybatis.org/mybatis-3/ko/sqlmap-xml.html

[Intellij] 01. 인텔리J 시작하기(맥)

oh-yes — Mon, 22 Feb 2016 00:09:31 +0900

01. Setting & Guide

01-01 키 셋팅 & 키 바인딩

기본적으로 나는 이클립스 & 윈도우 유저로 새롭게 맥북에서 적응하는 것도 중요하지만... 무엇보다 나의 돈벌이(?)와 관련이 있는 개발툴 단축키가 무엇보다 중요하다.

그래서 일단 인텔리J 설치 후(설치는 어렵지 않습니다. 공식 홈페이지를 참고해주세요.) 바로 키 바인딩 셋팅부터 들어갔다.

하단 이미지는 일단 이클립스와 인텔리J에서 사용하는 주요 용어의 차이점을 보여주는 도표이다.

https://www.jetbrains.com/idea/help/discover-intellij-idea.html#UserInterface

(역시 공식 레퍼런스가 최고다! 이건 웹페이지에서 제공해주는 키 바인딩 관련 튜토리얼)

: But! 제공해주는 내용중 버젼과 동일하지 않은 키가 있음. 버젼에 해당하는 녀석은 설정(Preference)에서 찾아서 확인하면서 익히도록 한다.

간단하게 따라하면서 진행하는 것을 추천한다. 직접 프로젝트 생성 후 간단한 소스 입력 후 진행!

https://resources.jetbrains.com/assets/products/intellij-idea/IntelliJIDEA_ReferenceCard_mac.pdf

(키 맵 관련 PDF)

: PDF로 제공해주는 키 바인딩 관련 문서이다. 영어 능력이 좋고 배움이 빠르신 분들은 바로 여기서 키 내용을 확인 후 직접 적용해보시면 되겠다.

키 바인딩 및 키맵 설정을 보면서 발견한 문서가 있었는데, 이클립스와 비교하여 단축키를 설명하는 페이지였다.

https://www.jetbrains.com/help/idea/2016.1/eclipse.html?origin=old_help

기존에 이클립스에서 자주 사용하던 키와 인텔리J에서 제공하는 키의 비교문서라 그런지 더 읽기가 편했다.

특히 인상 깊었던 부분이 바로 템플릿 사용 부분이었다. 윈도우 - 이클립스 환경에서 sysout, main 등 템플릿화 시켜서 쓰는 키워드들이 많았는데 인텔리J 역시 기본으로 제공하는 템플릿 키워드가 여러개 있었는데 몇번 예제 코드를 작성하다보니 꽤 쓸만하고 오히려 더 편리하게 느껴졌다.

[Mac Life] 창 이동하기 / 무료 앱

oh-yes — Fri, 19 Feb 2016 23:55:21 +0900

맥 프로를 구매하고 (무려 300만원 가까이 지출을 했다.)... 사실 제대로 활용을 못하고 있다.(회사에서 맥을 사용하지 않다보니 빠르게 친해지지가 않는다 하....)

그래도 집에서는 간단한 샘플 소스라도 셋팅해놓고 짜고 있으니....그나마 다행이라고 할 수 있다.

맥에서 작업하다보니 윈도우에서 아무 생각없이 사용했던 단축키를 사용하지 못하는 불편함이 있다. 특히!! 창을 줄이고 키우는 단축키를 윈도우에서는 즐겨 사용했었는데, 맥에는 요런 녀식이 없나해서.. 찾아봤다.

http://spectacleapp.com

무료앱으로 간단하게 사이트 접속 후 다운을 받고 실행 시키면 끝!

(설정은 맞춰줘야 하며, login at launch를 해줘야지 재부팅 상황에도 적용이 된다.)

단축키의 경우 앱을 실행시키면 볼 수 있으니 참고하면 되겠다.

( 풀 사이즈 단축키의 경우 control + command + f -> 요 녀석은 지원이 안되니 이거는 그냥 사용하면 될듯)

참고로 나 같은 경우에는 다른 단축키(개발툴)에서 단축키와 겹치는 문제가 발생했는데, 이런 경우에는 한쪽(스팩타클 혹은 개발툴이나 기타 툴)에서 키 바인딩을 바꿔줘서 겹치지 않도록 하는 것이 좋겠다. 물론 나같이 맥 허접들은.... 손에 익은 툴보다는 덜 익숙한 툴에 있는 키를 바꾸는 것이 유리하겠지만.....

[MAC] JDK Version 변경

oh-yes — Thu, 14 Jan 2016 10:13:07 +0900

Apple Java_home 관련 문서

https://developer.apple.com/library/prerelease/mac/documentation/Darwin/Reference/ManPages/man1/java_home.1.html

IntelliJ에서 Java와 Gradle 버전 설정하기 (Spring Boot)

: ~/.bash_profile 설정, $JAVA_HOME 변경 처리

- http://blog.saltfactory.net/java/setting-java-and-gradle-version-in-intellij.html

terminal) cd

terminal) sudo nano ~/.bash_profile

terminal) source ~/.bash_profile

JDK VersionChanger

- http://javakorean.com/?p=1993

- http://www.guigarage.com/2013/02/change-java-version-on-mac-os/

Shell Script 작성하여 JDK 버젼 변경하기

- http://stackoverflow.com/questions/21964709/how-to-set-or-change-the-default-java-jdk-version-on-os-x

[Spring Security] 4장 내용 정리

oh-yes — Sat, 2 Jan 2016 23:23:48 +0900

1. 데이터베이스를 사용한 인증 적용

- 기본 스키마 적용 / 사용할 DB 설정

<jdbc-user-service>에 datasource를 참조하도록 하여 security.xml파일 수정

- 기본 예제와 다른 점은 UserDetailService에 대한 구체적인 구현 내용

(JdbcDaoImpl를 상속하여 Custom UserDetailService 클래스를 생성)

- 스프링 시큐리티에서는 JDBC 데이터베이스와 관련 일반적인 CRUD 기능을 제공함.

(JdbcUserDetailsManager 빈 선언 및 CRUD 기능을 제공하는 UserDetailManager 인터페이스 매소드를 구현하여 실질적인 유머와 관련된 CRUD 작업 내용으로 작성)

- JdbcDaoImpl의 주요 기능 중 하나는 GratedAuthority를 그룹으로 분류, 간접 레벨을 두어 개별 그룹에 대해 권한 부여가 가능함. => Group-Based-Access Control, GABC)라고 함.

- UserInfo, User, Group, GroupPermission, Permission 스키마를 사용하여 JdbcDaoImpl을 수정

userByUsernameQuery, authoritiesByUsernameQuery, groupAuthoritiesByUsernameQuery 등의 쿼리명을 사용하여 사용자, 권한 및 그룹 권환을 반환(JdbcUserService XML 설정에 해당 퀴리의 내용을 삽입하여 적용)

2. 보안 비밀번호 설정

- 비밀번호 적용 규칙

-> 비밀번호는 텍스트로 저장해서는 안됨

-> 사용자가 제공한 비밀번호와 저장소에 저장된 값과 비교하는 과정이 있어야 함.

-> 비밀번호는 바로 제공되어서는 안됨

- Password Encoder 사용

PlaintextPasswordEncoder : 일반 텍스트 인코딩 처리

Md4PasswordEncoder : MD4 해리 알고리즘을 사용, 안전한 알고리즘이 아님

Md5PasswordEncoder : MD5 단방향 인코딩 알고리즘 사용

ShaPasswordEncoder : 단방향 인코딩 알고리즘 사용, 인코딩 레벨을 설정할 수 있는 기능이 있음.

LdapShaPasswordEncoder : LDAP 인증 저장소, 9장에서 자세히

- 비밀번호 인코딩은 해당하는 클래스 빈을 설정하여 XML 설정을 진행.

(해당 빈 설정 후, SQL에서 로드한 비밀번호를 인코딩 처리, initMethod 지정)

3. 비밀번호 솔트 제공

- 저장소에 존재할 수 있는 동일한 인코딩 값은 잠재적인 보안 문제로 이어질 수 있음.

- 솔팅(Salting 적용)(인코딩된 데이터에 약간의 데이터 추가를 하는 개념)

사용자 생성 시점의 날짜 데이터, 랜덤 텍스트 등

- SaltSource 빈 생성, PasswordEncoder설정에 Salt-Source를 추가하여 빈 설정 완료

4. SSL을 사용한 사이트 보안

- HTTPS(SSL / TLS) 적용

- SSL 사용을 위한 톰캣 설정 및 키 저장소 생성

- 톰캣 SSL 커넥터 생성 및 <http> 설정에서의 채널로 https 설정(https, any, http)

(보호된 영역과 보호되지 않는 영역에 따라서 해당 require-channel 설정 처리)

- 포트 맵핑(80/443) 이외에 명시적으로 다른 포트를 사용할 수 있음.( <port-mappings>설정 )

[Spring Security] 3장 내용 정리

oh-yes — Tue, 22 Dec 2015 23:34:18 +0900

[스프링 시큐리티 3장 정리]

스프링 시큐리티는 기본 Security 네임스페이스 설정을 사용하더라도 기본적인 로그인, 인증, 권한부여의 기능 구현이 가능함.

1. 로그인 / 로그아웃 이해
- 헤더/푸터 페이지 구성(태그 라이브러리를 활용)

- 폼 액션의 경우, UsernamePasswordAuthentification 서블릿 필터에서 설정한 액션과 일치해야 함.

폼의 기본 액션 값은 j_spring_security

- <intercept-url>태그 설정을 통하여 로그인 페이지로 접근할 수 있는 URL 및 액세스 권한을 설정해야 함

▶︎ 스프링 시큐리티의 모든 URL 요청에 대해 위에서 아래로 내려오는(top to bottom) 순서대로 권한부여 규칙을 해석해 적용

▶︎ ex)

<intercept-url pattern="/login.do" access="permitAll">

<intercept-url pattern="/*" access="hasRole("ROLE_USER")"

- 로그아웃은 일반적으로 사이트에서 보호되지 않은 영역으로의 이동/리다이렉트를 뜻함.

▶︎ 모든 URL 요청은 서블릿 요청으로 리졸브되기 전에, 항상 필터 체인을 통과함.(중요)

▶︎ ex)

<logout invalidate-session="true"

logout-sucess-url="/"

logout-url="/j_spring_security_logout" />

: /j_spring_security_logout의 경우, 컨트롤러 및 서블릿에 맴핑된 실제 주소가 아닌, 가상의 url

logout-success-url 속성의 경우, 로그아웃이 정상적으로 수행된 후 리다이렉트 될 주소에 대한 설정

▶︎ 로그아웃은 크게 3단계로 이뤄짐 -> 세션 무효화 / SecurityContext초기화 / logout-sucess-url에 지정된 url redirect

▶︎ LogoutHandler 구현이 직접 가능하며, 세션 초기화 및 사용자 인증 관련 정보가 남지 않도록 할 수 있다.

2. Remember Me 기능 구현

- 쿠키를 암호화하고, 사용자 브라우저에 저장해 재방문하는 사용자를 기억하는 기능

: rememberMe 쿠키 값을 가지고 있으면, 별도의 인증 절차를 거치지 않고 로그인 및 인증 처리

- 기본 설정

<remember-me key='jbcpPetStore'>

▶︎ key : 쿠기에 대한 고유값 / token-validity-seconds : 시간 범위를 설정, 설정 시간에만 유효(초단위)

- 동작 원리

▶︎ 사용자명 / 쿠기 만료 일자 / 만료 일자, 사용자명, 비밀번호에 대한 MD5 해시값 / remember-me태그 기본 key 값

: 기본적으로 base64 인코딩 처리 => 임의 길이를 갖는 압축된 텍스트로 반환(다이제스트)

▶︎ 입력이 된 값의 인코딩된 값과 저장되어 있는 인코딩값과 비교 검증을 통하여 일치 유무 판단

: 쿠키 값을 디코딩 후 검증

- 완전히 인증된 세션과 rememberMe를 이용한 세션의 구분이 분명하게 필요

▶︎ rememberMe 세션에 대해서는 완전한 인증(fullyAuthenticated)을 받도록 해야 함.

: <intercept-url> 설정 및 내부의 SpEL 표현식의 조합을 통하여 설정 가능

- IP주소를 인식하는 rememberMe 서비스 개발

▶︎ 클라이언트의 IP 주소를 기반으로 하여, MD5 해시값을 생성하여 http 통신 중에 발생할 수 있는 악의적인 접근에 대해서

차단이 가능함.

▶︎ TokenBasedRememberMeServices 부모 클래스를 상속, onLoginSuccess, makeTokenSignature, setCookie 및

processAutoLoginCookie 매서드를 오버라이드하여 IP주소를 받아오고 이를 적절하게 변환처리하여 rememberMe 쿠키값에

저장할 수 있도록 오버라이드 메소드 로직을 구성.

▶︎ 위에서 작성된 rememeberMe 서비스에 대해서는 빈을 등록하여 (위에서 작성한 클래스에 설정자 초기화를 통하여) 이를

<remember-me> 설정에서 참조할 수 있도록 service-ref 속성값을 지정.

▶︎ 추가적으로 <remember-me> 속성값 설정을 통하여 폼에서 넘어오는 remember_me 값에 대해서 사용자가 지정이 가능

3. 비밀번호 찾기 및 사용자 관리 기능 개선,추가

- UserDetailService 인터페이스 구현체를 상속하여 기본 기능 제공

(인메모리 기반으로 디비 및 저장방식에 얽매이지 않고 프레임워크에서 제공하는 확장 기능의 흐름과 설계에만 집중)

(하드코딩된 사용자 목록을 사용하여 단위 테스트를 작성할떄 주로 사용)

- InMemoryDaoImpl 인메모리 크리덴셜 저장소를 사용하여 UserDetails를 저장

▶︎ InMemoryChangePasswordDaoImpl을 사용하여 InMemoryDaoImpl 상속 및 시큐리티 설정

[Github] README.md 쉽게 작성하기

oh-yes — Tue, 8 Dec 2015 16:26:01 +0900

Github을 시작하면서 마스터 브랜치를 가지고 지속적으로 커밋을 날리고 있다. 물론 로컬에서 브랜치를 따로 만들어서 작업을 해보기도 했었지만, 아직 SVN에 더 익숙해서 git 명령어나 예외상황을 좀 더 지켜본 뒤 브랜치를 여러개를 만들어서 실험적(?)인 작업을 해볼 생각이다.

그전에 올린 소스에 대해서 쫌 세세하게 이력? 혹은 요약을 하고 싶은 생각에 README.md라는 녀석을 수정해보려고 하는데 요녀석(?)이 그냥 마크업 문법이 아닌 다른 문법을 가지고 있는 것이었다.

물론 시간을 투자해서 공부하면 편리하게 사용하겠지만, 그 시간에 차라리 코드 한줄 더 짜보고, 다른 개발환경 셋팅해서 다른 역량을 기르는게 맞다고 생각한다. 아무튼, 추천할만한 에디터가 두 개정도 되는거 같다

1) StackEdit(https://stackedit.io/editor)

웹 기반 에디터로 접속하게 되면, 간단한 영어로 튜토리얼을 진행한다.(레이어 팝업 형식으로) 사용법은 간단하고, 인트로 페이지에 사용법에 대한 내용도 나와 있으니 참고하도록 하자.

2) MarkdownPad(http://www.markdownpad.com/)

설치형/포터블 둘 중에 선택할 수 있으며, 위에 있는 StackEdit와 둘다 써본 결과, 요녀석이 좀 더 편하다는 생각이 들었다.(웹으로 접속안하고, 포터블버젼을 다운받아서 사용하기 때문에 편리한듯?) 단축키에 대한 설명도 간단하게 인트로 페이지에 나와 있어서 금방 적응하여 사용 가능하다.

※ 라이센스가 존재한다! 상업용으로 사용할 경우에는 제한이 있으니, 확인하고 사용하자.

SVN(SubVersion) 백업 및 이관

oh-yes — Mon, 5 Oct 2015 13:17:18 +0900

- VisualSVN 사용 기준(2.1.2)

- 운영체제 : Windows Server 2008 R2 Standard

방법 1) svnadmin dump를 이용한 방법

: SVN 로그 및 리비젼을 모두 dump 뜨는 방식인거 같은데 이번에 이관 작업은 서버에 있던 데이터를
모두 옮기는 작업이라서 이렇게 할 필요가 없었음. 방법은 아래와 같음

○ 백업

: SVN 이 설치된 폴더 콘솔(설치경로\bin)에서 'svnadmin dump C:\Repositories\Project > Project.dump' 명령어를 실행하여 덤프파일을 생성한다.

○ 백업 복구 방법

- 복구할 저장소를 먼저 생성한다. (방법은 2가지이다.)

- VisualSVN Server Manager를 이용하여 Project 저장소를 만들어도 됨.

- 'svnadmin create C:\Repositories\Project' 명령어를 실행하여 Project 저장소를 생성하여도 된다.

○ 복구

- 'svnadmin load C:\Repositories\Project < Project.dump' 명령어를 실행하여 덤프 파일을 SVN 서버에 복구

- VisualSVN Sever Manager을 refresh하여 복구된 Repositories를 확인한다.(그냥 누르기도 귀찮으면 재시작 하자)

○ 참고자료

: http://ppusari.blogspot.kr/2015/02/svn.html

: https://www.visualsvn.com/support/svnbook/reposadmin/maint/

(뭐니뭐니 해도 공식 메뉴얼이 짱인거 같음, 대신 머리부터 발끝까지 조선 사람들은 힘들 수 있음)

방법 2) Full BackUp(추천)

: 방법1) 같은 경우에는 운영체제가 다른 경우(Windows -> Unix 계열 등)으로 옮길때 사용해야 할듯 싶고,
동일한 운영체제의 경우 풀백업을 사용하는 것이 빠르고 안전한거 같다.

○ 백업 및 복구 방법

- 백업할 데이터(일반적으로 C:\Repositories)를 복사

- 이관하는 서버쪽에 동일한 버젼의 VisualSVN을 설치

(나의 경우 동일한 버젼으로 설치하였음,)

: 설치 방법은 매우 간단하므로 생략

(포트번호도 기존에 사용하던 것을 그대로 사용하는게 다른 사람들의 연동을 위해서 좋지 않나 생각이 듬

- 복사한 Repositories 폴더를 이관하는 서버쪽에 동일하게 붙여넣기 한다.

- VisualSVN을 실행하여 보면 유저 데이터 및 리비젼 데이터가 기존에 사용하던 SVN 서버와 동일하게 보일 것이다.

: Repositories 폴더에 authz, authz-windows, htpasswd 파일이 동일하게 복사되므로, User도 동일하게 복구 됨

- 다른 툴은 어떻게 될지 모르겠지만 Eclipse의 경우, 기존 레파지토리 메뉴 중 Relocate 메뉴를 선택하여 바뀐 주소로 변경을 처리할 수 있다.(주소 값만 바꾸면 되니깐 편리하다)

○ 백업 중 발생한 오류 및 이슈

- 백업 완료 후, 커밋 테스트를 진행하는데 발생한 오류가 있었다. 아래와 같음(OOOO는 폴더명)

svn: Can't open file 'C:\Repositories\OOOO\db\txn-current-lock': 액세스가 거부되었습니다.

svn: MKACTIVITY of '/svn/OOOO/!svn/act/OOOOOOOOO': 500 Internal Server Error (http://IP주소:포트)

- 검색을 해보니, Repositories 폴더의 권한과 관련이 있는 이슈로, 해당 폴더의 User 계정 셋팅을 다시 해주면 되는 것으로 해결할수 있었다.(권한 설정은 읽기, 쓰기, 수정이 모두 가능한 것으로 바꾸면 된다. 운영체제마다 설정하는 방법이 상이하므로 나머지는 검색을 통하여 해결하도록 하자)

이클립스 속도 향상 (eclipse.ini 수정)

oh-yes — Wed, 14 Jan 2015 17:29:51 +0900

주력 통합개발환경인 이클립스 환경 설정에 관련된 포스팅을 남겨본다. PC환경이 조금이라도 안좋은 경우(예를 들어 램이 모자라거나 CPU 사양이 낮거나.... 혹은 SSD를 사용 안하거나...)는 진짜 이클립스 쓰기에 뻑뻑한게 현실이다. 이럴 경우 이클립스에서 사용하는 JVM쪽 설정을 조금 다시 셋팅하여 사용하는 것이 그나마 속도 개선이 좋은 부분이 있기 때문에 평소 사용하는 설정 부분을 포스팅하려고 한다.

<eclipse.ini> // STS의 경우 STS.ini

1
2
3
4
5
6
7
8
9
10
11
12
 
####################### eclipse.ini #################################
 
-vmargs-Dosgi.requiredJavaVersion=1.6
-Xverify:none-XX:+UseParallelGC-XX:
-UseConcMarkSweepGC
-XX:PermSize=128M
-XX:MaxPermSize=128M
-XX:MaxNewSize=128M
-XX:NewSize=128M
-Xms512m
-Xmx512m

★ 설명

-Dosgi.requiredJavaVersion=1.6 → JDK 1.6 이상을 설치했을 경우에 1.6으로 설정하면 속도가 빨라짐

-Xverify:none → 클래스의 유효성을 검사 생략. 시작 시간이 단축되어 빨라진다.

-XX:+UseParallelGC → 병렬 가비지 컬렉션(병렬처리로 속도 향상) 사용.

-XX:+AggressiveOpts → 컴파일러의 소수점 최적화 기능을 작동(왜 빨리지는지는 설명이 안된다.)

-XX:-UseConcMarkSweepGC → 병행 mark-sweep GC 수행하여 이클립스 GUI의 응답을 빠르게한다.

-XX:+CMSIncrementalMode=true → 점진적인 GC

-XX:PermSize=128M → Permanent Generation(영구 영역) 크기(Out Of Memory 에러시 크기 조절)

-XX:MaxPermSize=128M → 최대 Permanent Generation 크기

-XX:NewSize=128M → New Generation(새 영역) 크기

-XX:MaxNewSize=128M → New Generation(새 영역) 의 최대 크기

-Xms512m : 이클립스가 사용하는 최소 Heap 메모리

-Xmx512m : 이클립스가 사용하는 최대 Heap 메모리

최소와 최대를 같은 값으로 설정하면 오르락 내리락 하지않아 빨라진다.

메모리 설정의 경우, 본인의 PC 환경에 맞게끔 다시 설정해주면 좋다. 하지만 무작정 메모리 크기를 크게 잡는다고 속도에는 크게 영향을 주는 부분이 없기 때문에 적당량을 배정해주는 것이 좋을 것이다. 또한, 설정 후 이클립스가 죽는(?) 일이 생길수도 있으니 기존 eclipse.ini를 백업한 후 작업하는 것이 베스트!!

[ 참고 ] JVM

JVM 은 3가지 메모리 영역을 관리함. GC와도 관련이 있는 부분임.

1. Permanent(영구) : JVM 클래스와 메소드를 위한 공간. = PermSize

2. New/Young : 새로 생성된 개체들을 위한 공간. = NewSize

3. Old : 만들어진지 오래된 객체들의 공간.(New 영역에서 이동)

[출처] 이클립스 속도 향상 (eclipse.ini 수정)|작성자 메멘토

[Oracle] 결합 컬럼 인덱스 / 조인(Join)문의 종류와 성능

oh-yes — Wed, 23 Jul 2014 17:34:44 +0900

1. 결합 컬럼 인덱스를 생성할 때 선행 컬럼을 결정하는 기준에 대해 자세히 설명하시오.

ex.1) CREATE INDEX I_EMP_DATE_DEPTNO ON BIG_EMP(HIREDATE, DEPTNO)

ex.2) CREATE INDEX I_EMP_DATE_DEPTNO ON BIG_EMP(DEPTNO, HIREDATE)

SELECT DEPTNO, COUNT(*), SUM(SAL)

FROM BIG_EMP

WHERE HIREDATE BETWEEN TO_DATE('1983-01-01','YYYY-MM-DD')

AND TO_DATE('1984-12-31','YYYY-MM-DD')

AND (DEPTNO = 70 OR DEPTNO = 80 OR DEPTNO = 90)

GROUP BY DEPTNO

ORDEY BY SUM(SAL) DESC

위 두 가지 인덱스를 적용한 후 실행한 SELECT문의 처리과정과 실제로 READ해야 하는 BLOCK의 개수는 크게 차이가 난다. 원인으로는 불필요한 검색범위가 줄고 이에 따라 실행계획이 변경이 되기 때문이다. 이처럼 결합 컬럼 인덱스를 생성할 때 정하는 DRIVING COLUMN이 어떤 컬럼이 되느냐에 따라 실행하는 SQL문의 성능에 크게 영향을 미칠 수 있는 요소이다. 경우에 따라서는 생성한 인덱스를 두고 FTS 스캔을 하는 경우도 발생할 수 있는 등 성능과 관련되어서는 반드시 고려해야 할 요소임에 틀림없다.

- WHERE절에서 자주 검색되는 선행 컬럼이 되어야 함.

- 분포도가 좋은 컬럼이 선행 컬럼이 되어야 함.

: 분포도 = 조건을 만족하는 행수/전체행수 * 100

보통 10% 내외가 가장 이상적

- 데이터양이 적은 컬럼을 선행으로 사용.

- BETWEEN, > AND <, LIKE 연산자로 검색하지 않는 컬럼을 선행 컬럼으로 사용.

2. 조인문의 종류에 대해 설명하고 조인문의 성능에 영향을 주는 요소와 작성 방법에 대해 설명하시오.

SORT-MERGE JOIN

NESTED-LOOPS JOIN

CLUSTER JOIN

HASH JOIN

1. SORT-MERGE JOIN

두 개 이상의 테이블이 공통 컬럼을 기준으로 결합 될 때(EQUI-JOIN), 각각의 컬럼에 인덱스가 전혀 없는 상태에서 조인이 되는 방법. FTS(FULL TABLE SCAN)에 의한 검색이기 때문에 성능이 매우 떨어짐.

2. NESTED-LOOPS JOIN

두 개 이상의 테이블이 공통 컬럼을 기준으로 결합 될 때(EQUI-JOIN), 둘 다 혹은 둘 중 하나의 컬럼에 인덱스가 존재하는 검색방법. 가장 보편적으로 사용됨. 데이터 스캔 범위를 줄일 수 있어 SORT-MERGE JOIN보다 빠른 성능을 기대할 수 있음.

3. HASH JOIN

두 개 이상의 테이블이 논리적으로 결합될 때(EQUI-JOIN) 공통 컬럼을 기준으로 메모리 상에서 여러개의 파티션 영역을 나누어 결합하는 조인 기법. 일반적으로 HINT(USE_HASH)를 사용하여 처리하고, 주로 처리량이 많은 전체범위를 처리하는 경우에 사용하면 효율적이다. 이에 따라 효과적인 검색 및 결합이 되기 위해서는 인덱스 구성이 중요함.

4. CLUSTER JOIN

2개 이상의 테이블이 자주 조인되어 실행될 때, 일반적인 조인문의 실행과정처럼 블록으로부터 각각 읽혀져서 결합되는 것이 아닌, 처음부터 블록구조 내에 조인되어 결합된 형태로 저장되는 기법.

조인문 성능에 영향을 주는 요소

- DRIVING TABLE(선행 테이블)

조인에 참여하는 각 테이블은 데이터의 양과 분포도가 다르기 때문에 일반적으로

데이터 범위가 좁은 테이블을 선행 테이블로 결정하는 것이 성능상 유리함.

1. 조인에 참여하는 컬럼에 모두 인덱스가 있거나 / 모두 없는 경우(동등조건)

: 가장 오른쪽에 배치된 테이블이 선행 테이블로 결정됨.

2. 개발자에 의해 조인 순서를 결정하는 경우

: 옵티마이저가 최적의 실행계획을 결정하지 못하는 경우에 사용함.

- 테이블의 조인 순서

1. 조인에 참여하는 테이블들의 인덱스의 종류에 따라서 실행 순서가 바뀔 수 있다.

2. 구동테이블이 결정되고 나면, 나머지 테이블들 중 순서가 결정이 되는데 우선순위

가 적용이 된다.

: 모두 인덱스가 존재하는 경우(싱글<결합, NON-UNIQUE<UNIQUE)

- 검색되는 테이블의 데이터량에 따라 성능이 좌우

: 넓은 범위가 아닌 좁은 범위 / FTS보다 INDEX SCAN

- 조인 시, INDEX의 사용여부

: 동일한 조인문장이더라도, 인덱스가 존재하지 않는 SORT-MERGE JOIN과

NESTED LOOPS JOIN의 결과는 다른 성능을 나타나게 됨. 일반적으로 INDEX

사용한 NESTED-LOOPS 조인이 성능이 우수하지만, 경우에 따라 SORT-MERGE JOIN

이 유리한 경우도 있다.

[Oracle] Rule-Based-Optimizer vs Cost-Based-Optimizer

oh-yes — Mon, 21 Jul 2014 17:23:25 +0900

1. RBO의 실행계획 결정원리와 예외 조건들에 대해 설명하시오.

RBO 내장규칙	FROM절에서의 테이블 위치
WHERE절에서의 순서변경	INDEX 생성 및 삭제

- 우선 순위가 빠른 인덱스를 선정함.

- 우선 순위가 같고 동등(Equal) 조건에 의한 검색은 인덱스가 모두 사용됨.

- 우선 순위가 같지만 동등조건이 아닌 경우, 나중에 생성된 인덱스를 사용함.

- 같은 칼럼에 대한 검색 조건 중, 조건이 함수 등에 의해 변형되면 둘 중

나쁜 실행계획이 선택되어 실행됨.

- AND. OR 조건에서 우선 순위를 결정

(AND는 조건절에서 정방향으로 조건을 읽음 / OR는 조건절에서 역방향으로)

2. CBO의 문제점에 대해 설명하고 그 대처 방안에 대해 설명하시오.

- 통계가 있는지 없는지에 대한 유무가 중요함

1. (SELECT TABLE_NAME, LAST_ANALYZED FROM USER_TABLES) 등의 쿼리를 통하여

날짜 정보가 있으면 통계정보가 존재, 없으면 통계정보가 없음.

2. DBMS_STATS를 활용하여 통계정보에 대한 BACKUP / RECOVERY 가능

(DBMS_STATS + DBMS_JOB을 동시에 사용)

3. 최신의 통계정보를 기반으로 하는 것이 원칙이나, 반드시 최신의 통계정보가

우수한 성능을 보장하는 것이 아님(데이터 분포도 관련 문제)

=> 부정확한 통계정보를 기반으로 한 CBO는 성능상 효율이 떨어짐

이러한 현상은 골고루 분산되어 있는 데이터라는 전제 때문에 발생함.

1. 히스토그램(HISTOGRAM)을 통하여 DISTINCT-KEY의 수를 지정하는 등의 방법을 사용

2. 힌트(Hint)설정을 통하여 사용자가 파악한 최적의 실행계획을 수행하도록 SQL문 작성

STOURED OUTLINE을 활용하여 RBO/CBO 모두 튜닝 시

실행계획을 재사용하는 방법도 있음.

[Android] Switch문 case expressions must be constant expressions

oh-yes — Sun, 8 Jun 2014 23:22:08 +0900

R.java에 선언되어 있는 아이디 값을 switch문에서 읽지를 못해서 생기는 오류인데

R.java를 임의로 수정하려 하였으나 수정을 이클립스에게 거부당했다( ^^;;;;;;;)

더 찾아보니

switch ~ case문 대신 If-else를....사용하라는....문서를 발견했고

또한 이클립스에서 Ctrl+1을 누르면 쉽게 수정이 된다는 사실을 발견!

(switch문에 커서 올려놓으시고 Ctrl+1만 누르면 쉽게 해결)

SQL전문가 가이드 - join 부분

oh-yes — Fri, 6 Jun 2014 16:45:32 +0900

--조인

SQL에서 데이터를 처리할 때는 단 두개의 집합 간에만 조인 처리되고,

2개의 테이블이 조인되어서 처리된 새로운 테이블이 나열되었더라도 특정 2개의 테이블만

먼저 조인 처리되고, 2개의 테이블이 조인되어서 처리된 새로운 데이터 집합과 남은 한 개의 테이블이 다음 차례로 조인되는 것

(((A join B)join C)join D)

--(1) 등가(equi) 조인

select player.player_name 선수명, team.team_name 소속팀명

from player, team

where player.team_id = team.team_id;

select player.player_name 선수명, team.team_name 소속팀명

from player inner join team

on player.team_id = team.team_id; --inner join

select player.player_name, player.back_no, player.team_id,

team.team_name, team.region_name

from player, team

where player.team_id = team.team_id;

select player.player_name, player.back_no, player.team_id,

team.team_name, team.region_name

from player inner join team

on player.team_id = team.team_id;

--테이블명에도 alias를 사용하여 가독성 및 코드의 길이를 줄일 수 있음.

select p.player_name, p.back_no, p.team_id,

t.team_name, t.region_name

from player p, team t

where p.team_id = t.team_id;

select p.player_name 선수명, p.back_no 백넘버, t.region_name 연고지,

t.team_name 팀명, p.position

from player p, team t

where p.team_id=t.team_id

and p.position = 'GK'

order by p.back_no;

select team.region_name, team.team_name, team.stadium_id,

stadium.stadium_name, stadium.seat_count

from team, stadium

where team.stadium_id = stadium.stadium_id;

--(2) 비등가(Non-equi) 조인 //자료가 읍슴 ㅠㅠ

select e.name, e.job, e.sal, s.grade

from emp e, salgrade s

where e.sal between s.losal and s.hisal;

--(3) 3개 이상 TABLE JOIN

select p.player_name 선수명, p.position 포지션,

t.region_name 연고지, t.team_name 팀명,

s.stadium_name 구장명

from player p, team t, stadium s

where p.team_id = t.team_id

and t.stadium_id = s.stadium_id

order by 선수명;