1010 ~ 1016

1011 - 생성자 바인딩(Constructor Binding)로 프로퍼티(Properties) 설정 값 불러오기

[ 생성자로 바인딩하기(@ConstructorBinding) ]

• 설정파일

spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.url=jdbc:h2:mem:db;DB_CLOSE_DELAY=-1
spring.datasource.username=h2test
spring.datasource.password=h2test

• 생상자를 이용해 properties의 값을 바인딩하도록 @ConstructorBinding 어노테이션을 추가

@Getter
@RequiredArgsConstructor
@ConfigurationProperties(prefix = "spring.datasource")
@ConstructorBinding
public class DataSourceProperties {

	private final String driverClassName;
	private final String url;
	private final String username;
	private final String password;

}

1012 - 불변 객체(Immutable Object) 및 final을 사용해야 하는 이유

1. 불변 객체(Immutable Object) 및 final을 사용해야 하는 이유

[ 불변 객체(Immutable Object)란? ]

불변 객체란 객체 생성 이후 내부의 상태가 변하지 않는 객체이다. 불변 객체는 read-only 메소드만을 제공하며, 객체의 내부 상태를 제공하는 메소드를 제공하지 않거나 방어적 복사(defensive-copy)를 통해 제공한다. Java의 대표적인 불변 객체로는 String이 있다.

String name = "Old";
name.toCharArray()[0] = 'E';

Java의 String은 불변 클래스이기 떄문에 위와 같이 String 내부의 char형 배열을 얻어 수정하여도 반영되지 않는다. Java에서는 배열이나 객체 등의 참조(Reference)를 전달한다. 그렇기 때문에 참조를 통해 값을 수정하면 내부의 상태가 변하기 때문에 내부를 복사하여 전달하고 있는데, 이를 방어적 복사(defensive-copy)라고 한다. String의 toCharArray는 다음과 같이 복사하여 전달하고 있다.

public char[] toCharArray() {
    // Cannot use Arrays.copyOf because of class initialization order issues
    char result[] = new char[value.length];
    System.arraycopy(value, 0, result, 0, value.length);
    return result;
}

[ 불변 객체 및 final을 사용해야 하는 이유 ]

Thread-Safe하여 병렬 프로그래밍에 유용하며, 동기화를 고려하지 않아도 된다.

• 멀티 쓰레드 환경에서 동기화 문제가 발생하는 이유는 공유 자원에 동시에 쓰기(Write) 때문이다. 하지만 만약 공유 자원이 불변이라면 항상 동일한 값을 반환하기 때문에 동기화를 고려하지 않아도 된다. 이는 안정성을 보장할 뿐만 아니라 동기화를 하지 않음으로써 성능상의 이점도 가져다준다.

실패 원자적인(Failure Atomic) 메소드를 만들 수 있다.

• 가변 객체를 통해 작업을 하는 도중 예외가 발생하면 해당 객체가 불안정한 상태에 빠질 수 있고, 불안정한 상태를 갖는 객체는 또 다른 에러를 유발할 수 있다. 하지만 불변 객체라면 어떠한 예외가 발생하여도 메소드 호출 전의 상태를 유지할 수 있을 것이다. 그리고 예외가 발생하여도 오류가 발생하지 않은 것 처럼 다음 로직을 처리할 수 있다.

Cache나 Map 또는 Set 등의 요소로 활용하기에 더욱 적합하다.

• 만약 캐시나 Map, Set 등의 원소인 가변 객체가 변경되었다면 이를 갱신하는 등의 부가 작업이 필요할 것이다. 하지만 불변 객체라면 한 번 데이터가 저장된 이후에 다른 작업들을 고려하지 않아도 되므로 사용하는데 용이하게 작용할 것이다.

부수 효과(Side Effect)를 피해 오류가능성을 최소화할 수 있다.

• 부수 효과란 변수의 값이나 상태 등의 변화가 발생하는 효과를 의미한다. 만약 객체의 수정자(Setter)를 통해 여러 객체들에서 값을 변경한다면 객체의 상태를 예측하기 어려워질 것이다. 바뀐 상태를 파악하기 위해서는 메소드들을 살펴보아야 하고, 이는 유지보수성을 상당히 떨어뜨린다. 그래서 이러한 부수효과가 없는 순수 함수들을 만드는 것이 상당히 중요하다. 불변 객체는 기본적으로 값의 수정이 불가능하기 때문에 변경 가능성이 적으며, 객체의 생성과 사용이 상당히 제한된다. 그렇기 때문에 메소드들은 자연스럽게 순수 함수들로 구성될 것이고, 다른 메소드가 호출되어도 객체의 상태가 유지되기 때문에 안전하게 객체를 다시 사용할 수 있다. 이러한 불변 객체는 오류를 줄여 유지보수성이 높은 코드를 작성하도록 도와줄 것이다.

다른 사람이 작성한 함수를 예측가능하며 안전하게 사용할 수 있다.

• 일반적으로 개발은 다른 사람들과 협업을 하게 된다. 불변성(Immutability)은 협업 과정에서도 도움을 주는데, 불변성이 보장된 함수라면 다른 사람이 개발한 함수를 위험없이 이용할 수 있다. 마찬가지로 다른 사람도 내가 작성한 메소드를 호출하여도, 값이 변하지 않음을 보장받을 수 있다. 그렇기에 우리는 변경에 대한 불안없이 다른 사람의 코드를 이용할 수 있다. 또한 불필요한 시간을 절약할 수도 있다.

가비지 컬렉션의 성능을 높일 수 있다.

• 불변성의 많은 이점 중에서 많은 사람들이 놓치는 것이 바로 GC성능을 높여준다는 것이다. 불변의 객체는 한번 생성된 이후에 수정이 불가능한 객체로, Java에서는 final 키워드를 사용하여 불변의 객체를 생성할 수 있다. 이렇게 객체를 생성하기 위해서는 객체를 가지는 또 다른 컨테이너 객체(ImmutableHolder)도 존재한다는 것인데, 당연히 불변의 객체(Object value)가 먼저 생성되어야 컨테이너 객체가 이를 참조할 수 있을 것이다. 즉, 컨테이너는 컨테이너가 참조하는 가장 젊은 객체들보다 더 젊다는 것(늦게 생성되었다는 것)이다. 이를 정리하면 다음과 같다.
  • Object 타입의 value 객체 생성
  • ImmutableHolder 타입의 컨테이너 객체 생성
  • ImmutableHolder가 value 객체를 참조

이러한 점은 GC가 수행될 때, 가비지 컬렉터가 컨테이너 객체 하위의 불변 객체들은 Skip할 수 있도록 도와준다. 왜냐하면 해당 컨테이너 객체가 살아있다는 것은 하위의 불변 객체들(value) 역시 처음에 할당된 상태로 참조되고 있음을 의미하기 때문이다.

public class MutableHolder {
    private Object value;
    public Object getValue() { return value; }
    public void setValue(Object o) { value = o; }
}

public class ImmutableHolder {
    private final Object value;
    public ImmutableHolder(Object o) { value = o; }
    public Object getValue() { return value; }
}

@Test
public void createHolder() {
    // 1. Object 타입의 value 객체 생성
    final String value = "MangKyu";
    
    // 2. Immutable 생성 및 값 참조
    final ImmutableHolder holder = new ImmutableHolder(value);
    
}

결국 불변의 객체를 활용하면 가비지 컬렉터가 스캔해야 되는 객체의 수가 줄어서 스캔해야 하는 메모리 영역과 빈도수 역시 줄어들 것이고, GC가 수행되어도 지연 시간을 줄일 수 있을 것이다. 그렇기 때문에 필드값을 수정할 수 있는 MutableHolder보다는 필드값을 수정할 수 없는 ImmutableHolder를 사용하는 것이 좋다.

2. Java에서 불변 객체를 생성하는 법

[ final 키워드 ]

final String name = "Old";
name = "New";  // 컴파일 에러 

final List<String> list = new ArrayList<>();
list.add("a");      // 가능

• 이를 방지하려면 불변 클래스로 생성해야함

[ 불변 클래스 예시 ]

Java에서 불변 객체를 생성하기 위해서는 다음과 같은 규칙에 따라서 클래스를 생성한다.

1. 클래스를 final로 선언하라
2. 모든 클래스 변수를 private와 final로 선언하라
3. 객체를 생성하기 위한 생성자 또는 정적 팩토리 메소드를 추가하라
4. 참조에 의해 변경가능성이 있는 경우 방어적 복사를 이용하여 전달하라

public final class ImmutableClass {
    private final int age;
    private final String name;
    private final List<String> list;

    private ImmutableClass(int age, String name) {
        this.age = age;
        this.name = name;
        this.list = new ArrayList<>();
    }

    public static ImmutableClass of(int age, String name) {
        return new ImmutableClass(age, name);
    }
    
    public int getAge() {
        return age;
    }

    public String getName() {
        return name;
    }

    public List<String> getList() {
        return Collections.unmodifiableList(list);
    }
    
}

클래스들은 가변적이여야 하는 매우 타당한 이유가 있지 않는 한 반드시 불변으로 만들어야 한다. 만약 클래스를 불변으로 > 만드는 것이 불가능하다면, 가능한 변경 가능성을 최소화하라. - Effective Java -

1013 - @ConfigurationPropertiesScan

@EnableConfigurationProperties에 등록해야 하는 클래스들이 많은 경우에는 일일이 등록하는게 번거로울 수 있다.

[ @EnableConfigurationProperties의 한계점 ]

@EnableConfigurationProperties를 이용해 설정 프로퍼티 클래스(@Configuration Properties)를 사용하는 경우에는 해당 클래스들이 많아질 경우에 코드가 상당히 무거워지는 한계가 있다.

@Configuration
@EnableConfigurationProperties({DataSourceProperties.class, InfluxProperties.class, ...})
public class SpringBootApplication {

}

SpringBoot 2.2부터는 이러한 문제점들을 해결하기 위해 @ConfigurationPropertiesScan 이라는 어노테이션을 제공하고 있다.

[ @ConfigurationPropertiesScan의 사용법 ]

@ConfigurationPropertiesScan 어노테이션은 @ComponentScan과 상당히 유사하다.
@ConfigurationPropertiesScan 어노테이션은 패키지를 기반으로 @ConfigurationProperties가 등록된 클래스들을 찾아 값들을 주입하고 빈으로 등록해준다. @ConfigurationPropertiesScan에 스캔을 실행할 패키지 또는 클래스를 지정해줄 수 있으며, 만약 별도로 지정하지 않는다면 해당 어노테이션이 붙은 패키지와 그 하위 패키지에 대해 스캔을 진행한다. @Component나 그 하위 어노테이션(@Configuration 등)이 붙은 클래스들은 @ConfigurationPropertiesScan에 의해 스캔되지 않는다.
일반적으로 Spring Boot의 메인 클래스에 @ConfigurationPropertiesScan 어노테이션을 다음과 같이 추가해주고, 필요한 경우 Base Package를 지정해준다.

@Configuration
@ConfigurationPropertiesScan("com.mang.atdd.membership")
public class SpringBootApplication {

}

1015 - 인덱스 생성전략

[ 인덱스 선정 기준 ]

• 모든 액세스 형태와 분석을 토대로이상적인 컬럼 구성과 순서 결정을 통해 최소의 인덱스로 모든 액세스 형태를 만족할 수 있도록 해야한다.
• 가능한 실측자료(액세스 형태 수집, 분석, 액세스의 빈도, 처리범위의 크기, 분포도, 테이블의 크기, 액세스 유형 등)를 활용하여 종합적으로 전략적인 결정을 해야한다.
• 여기서 분포도란 쉽게 말해 사용 빈도로 이해를 하면 된다. 즉, 분포도가 좋다는 의미는 한 컬럼에 해당하는 값이 희소성이 높다는 뜻이다.

[ 저장용 대형 테이블 적용 기준 ]

• 로그성 데이터를 관리할 목적으로 생성된 테이블을 저장용 대형 테이블이라고 한다.
• 이러한 테이블의 특징으로는 대량의 데이터가 지속적으로 입력이 된다는 것이다.
• 따라서 테이블에서 기본키(PK)를 가지는 것은 입력시 부담이 될 수 있으므로 이를 사용하지 않는 것도 고려해야 한다. 대신 UNIQUE INDEX 생성을 고려해야 한다.
• 또한, 테이블에 파티션을 만들고 파티션마다 필요한 인덱스를(Local Index)를 생성하는 것이 좋다.
• 파티션 인덱스 사용시, 사용 파티션의 인덱스만 사용하는 것도 고려해야 한다. => 즉, 전체 Local Index를 UNUSABLE 상태로 만든 후, 이후 필요한 파티션의 인덱스만 생성하는 방식

[ Composite index (결합 인덱스) ]

• 여러 컬럼을 모아 하나의 인덱스로 만드는 방식. 주로 SQL 문장에서 WHERE 절의 조건 컬럼이 2개 이상의 AND로 연결 되어 함께 사용되는 경우에 많이 사용.
• 단, OR로 조회되는 경우는 결합 인덱스를 만들면 안된다.
• 특징
  • 인덱스의 첫 번째 컬럼이 조건절에 없다면 일반적으로 인덱스가 사용되지 않는다.
    • Equal 연산이 아닌 검색 조건이 들어오는 경우(범위 연산), 처리 범위가 크게 증가하여 효율이 크게 저하될 수 있다.

[ 결합 인덱스를 구성하는 컬럼의 순서 ]

성능을 향상시키기 위해서는 결합 인덱스를 구성하는 컬럼은 반드시 다음의 순서에 맞도록 생성해야 한다.

• 1순위 : 컬럼이 사용한 연산자에 의한 인덱스 컬럼 선정
• 2순위 : 랜덤 액세스를 고려한 인덱스 컬럼 선정
• 3순위 : 정렬 제거를 위한 인덱스 컬럼 선정
• 4순위 : 단일 컬럼의 분포도를 고려한 인덱스 컬럼 선정

위 우선 순위를 지키지 않는다면 애당초 해당 인덱스를 이용한 성능 향상은 기대하기 조차 힘들다.

예시 1

SELECT 카드번호, 사용금액 FROM 거래내역 WHERE 카드번호 = '111' AND 거래일자 BETWEEN '20080501' AND '20080510';

• 카드번호 컬럼의 분포도는 매우 좋으며 거래일자 컬럼의 분포도는 매우 좋지 않다. 카드번호, 거래일자 순으로 결합 인덱스를 구성했을때, 카드번호 컬럼의 값에 의해 처리 범위는 감소하게 되며 또한 거래일자 컬럼에 의해서라도 처리 범위가 감소하게 되므로 원하는 데이터에 대해 최소의 액세스로 결과를 추출할 수 있게 된다.

예시 2

SELECT 카드번호, 사용금액 FROM 거래내역 WHERE 카드번호 BETWEEN '111' AND '555' AND 거래일자 = '20080515';

• 컬럼의 분포도만을 생각하여 카드번호 + 거래일자 인덱스를 생성한다면 카드번호 컬럼에 의해서만 처리 범위가 감소하게 되어 성능 저하가 발생한다.
• 그 이유는 111 카드번호부터 555 카드번호까지 2008년 5월 15일 데이터만을 액세스하는 것이 아니라 '111' 카드번호부터 '555'카드 번호까지 모든 데이터를 액세스하기 때문이다. => 즉, 거래일자 컬럼은 처리 위를 감소시키지 못한다.
• 따라서 결합 인덱스를 구성할 경우, 다음과 같은 조건에 따라 결합 인덱스를 구성해야 한다.
  • 점 조건(=, IN) + 점 조건(=, IN) : 두 조건에 의해 처리 범위 감소
  • 점 조건(=, IN) + 선분 조건(LIKE, BETWEEN) : 두 조건에 의해 처리 범위 감소
  • 선분 조건(LIKE, BETWEEN) + 선분 조건(LIKE, BETWEEN) : 앞의 선분 조건에 의해 처리 범위 감소
  • 선분 조건(LIKE, BETWEEN) + 점 조건(=, IN) : 앞의 선분 조건에 의해서만 처리 범위 감소

: 따라서 위와 같이 연산자에 의해 처리 범위가 결정되며 최소의 처리 범위를 보장받기 위해서는 점 조건 앞에 선분 조건이 존재하면 안된다.