스프링 부트로 개발하는 MSA 컴포넌트 2 (책 정리)

YongHyun·2023년 1월 10일
JavaSpring boot
0

스프링 부트로 개발하는 MSA 컴포넌트 정리

목록 보기
2/4
post-thumbnail

스프링 애플리케이션 기본

1. 스프링 빈 사용


출처 : https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/beans.html

스프링 빈은 스프링 빈 컨테이너가 관리하는 순수한 자바 객체를 의미한다.
스프링 빈 컨테이너는 스프링 빈 정의 설정을 읽고 스프링 빈 객체를 생성한다. 그리서 서로
의존성이 있는 스프링 빈 객체들을 주입하는 과정을 거친 후 애플리케이션이 실행 준비 상태가 된다.
작업이 끝난 애플리케이션이 종료하기 전 스프링 빈 컨테이너는 관리하고 있던 스프링 빈들의 종료 작업을 실행한다.
이렇게 스프링 빈을 생성하고 소멸하는 전체 과정을 스프링 빈의 생명주기라고 한다.

책에 정리된 내용을 참고하였는데 그림과 같이 보면 이해하기 쉬울것 같아 가져와 보았다.

여기서 스프링 빈을 정의하는 방법이 여러가지 있는데 다음과 같이 나열하면 다음과 같다.

  • 자바 설정 클래스에서 @Bean 애너테이션을 사용하여 정의하는 방법
  • 스테레오 타입 애너테이션을 사용하여 정의하는 방법
  • BeanDefinition 인터페이스를 구현하여 정의하는 방법
  • XML 설정 방식을 사용하는 방법

BeanDefinition을 구현하는 방법은 빈 대상이 많아지면 복잡해진다는 단점과
XML 설정은 객체를 생성하는데 명시적이지 않는 단점을 가지고 있기 때문에

스프링 부트 프레임워크가 공통으로 사용하는 애너테이션 기준에 따른
@Bean과 스테레오 타입 애너테이션 사용을 추천한다.

@Bean 애너테이션 코드를 확인해보면 다음과 같다.

@Target({ElementType.METHOD, ElementType.ANNOTATION_TYPE}) 
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Bean {

    @AliasFor("name")					
    String[] value() default {};
										
    @AliasFor("value")
    String[] name() default {};

    /** @deprecated */
    @Deprecated
    Autowire autowire() default Autowire.NO;

    boolean autowireCandidate() default true;

    String initMethod() default "";

    String destroyMethod() default "(inferred)";
}

@Target({ElementType.METHOD, ElementType.ANNOTATION_TYPE}) : 정의할 수 있는 타깃은 메서드와 다른 애너테이션이다.
@Retention(RetentionPolicy.RUNTIME) : 런타임 시점까지 @Bean 애너테이션이 코드에 존재한다.

@AliasFor("name")
String[] value() default {};

@AliasFor("value")
String[] name() default {};

: @Bean 애너테이션은 value 또는 name 속성을 가질수 있으며, 빈의 이름을 별도로 설정할 때 사용하는 속성이다. 생략이 가능함.

따라서 스프링 빈을 정의할때 필수 요소는 스프링 빈 이름, 클래스 타입, 객체 이다.
만약 속성에 값을 설정하지 않으면 @Bean 애너테이션이 정의된 메서드 이름이 스프링 빈 이름
클래스 타입은 @Bean 애너테이션이 정의된 메서드의 리턴 타입
스프링 빈 객체는 @Bean 애너테이션이 정의된 메서드가 리턴하는 객체이다.

2. 자바 설정

스프링 애플리케이션을 구성할 때 프레임워크의 특정 기능을 활성화하거나 애플리케이션 전체에서 공통으로 사용할 기능이 있다면 애플리케이션을 설정해야 한다.
ApplicationContext 객체는 스프링 빈 컨테이너 역할을 하고 있기 때문에 실행될 때 가장 먼저 설정 파일을 로딩한다. 이때 설정 파일은 자바클래스를 기반으로 설정하는 자바설정과 XML 파일 등이 있는데 XML은 오래된 버전의 스프링 프레임워크에서 사용하였다고 한다.
자바 설정을 위해 프레임워크는 @Bean, @ComponentScan, @Configuration, @Import 애너테이션을 제공한다.
먼저 주로 쓰이는 @Configuration은 자바 설정을 포함하고 있는 자바 설정 클래스를 정의하는데 사용되며 클래스 선언부에 정의하면 된다.

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Configuration {
    @AliasFor(
        annotation = Component.class
    )
    String value() default "";

    boolean proxyBeanMethods() default true;
}

여기서 main 메서드에 선언된 @SpringBootApplication 내부로 들어가면@SpringBootConfiguration 이 있고 또 내부 안으로 들어가면 @Configuration 정의되어 있다.
그래서 @SpringBootApplication 이 정의된 클래스는 스프링 부트 애플리케이션을 실행할 수 있는 동시에 자바 설정 클래스가 될 수 있다.

다음으로 @ComponentScan은 설정된 패키지 경로에 포함된 자바 설정 클래스들과 스테레오 타입 애너테이션들이 선언된 클래스들을 패키지와 하위 패키기들에 포함된 모든 클래스를 스캔한다. 이때 설정하는 속성들이 value, basePackages, basePackageClasses이다.

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE})
@Documented
@Repeatable(ComponentScans.class)
public @interface ComponentScan {
    @AliasFor("basePackages")
    String[] value() default {};

    @AliasFor("value")
    String[] basePackages() default {};

    Class<?>[] basePackageClasses() default {};
    		.
    		.
    		.

이 속성들을 설정해주지 않으면 @ComponentScan이 정의된 클래스가 위치한 패키지가 기본값이 된다.

마지막으로 @Import는 명시된 여러 개의 자바 설정 클래스를 하나의 그룹으로 묶는 역할을 한다.많이 사용하지는 않는 애너테이션이라고 한다.
@ComponentScan 과 비교하면 @Import는 명시적으로 지정해서 더 직관적이지만 매번 수정해야한다는 단점이 있어 @ComponentScan은 사용하는 것이 더 편리하다고 한다.

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Import {
    Class<?>[] value();
}

3. 스테레오 타입 스프링 빈 사용

애플리케이션을 개발하면서 기능의 복잡도와 크기에 비례하여 클래스 개수도 같이 늘어나게 된다. 그래서 스프링 개발자들은 애플리케이션 설정 영역과 비즈니스 로직 영역으로 용도를 나누어 각 각 다른 방식으로 스프링 빈을 정의한다고 한다.
애플리케이션을 설정하는 상황에서는 자바 설정을 이용한 @Bean
비즈니스 로직을 담당하는 클래스는 스테레오 타입 애너테이션을 사용하여 정의한다.

스테레오 타입 종류

  • @Component - 클래스를 스프링 빈으로 정의하는 일반적인 애너테이션
  • @Controller - 사용자 요청을 가장 먼저 처리하고, 이를 비즈니스 로직을 포함한 다른 컴포넌트에 전달하는 역할을 하는 '컨트롤러' 역할을 하는 클래스를 스프링 빈으로 정의하는데 사용함
  • @Service - 도메인 주도 설계의 서비스 역할인 클래스에 정의할때 사용하며 주로 복잡한 형태의 비즈니스 로직을 구현한다.
  • @Repository - 도메인 주도 설계의 리포지터리를 의미하는 애너테이션, 객체를 저장 조회하는 행위를 담당하는 클래스를 의미함.

@Controller, @Service, @Repository는 모두 @Component 애너테이션을 포함하고 있다.

4. 의존성 주입

스프링 프레임워크는 의존성 주입이라는 기능을 제공하는데 의존성이란 어떤 클래스가 다른 클래스를 참조하고 있다는 뜻이다. 

public class NotificationService(
	public boolean sendNotification(User user, String message){
    	SmsSender smsSender = new SmsSender();
        smsSender.setEndPoint(...);
        smsSender.setPort(...);
        smsSender.setTimeout(4000L);
        return smsSender.sendText(user.getPhoneNumber(), message);
        }
    )

위에 예제 코드를 예시로 들면 NotificationService 클래스 내부에는 smsSender 객체를 생성하고 메서드들을 호출한다.
이 때 NotificationService 클래스는 SmsSender 클래스에 의존하고 있다는 뜻으로 서로 강하게 결합되어 있다.

그러다가 SmsSender 클래스 내부에 새로운 변수 connectionTimeout 과 이를 설정하는 setConnectionTimeout() 메서드가 추가되었다고 생각해보자
그러면 NotificationService의 sendNotification 메서드에서 setConnectionTimeout() 메서드를 꼭 사용해야 한다고 가정하면 NotificationService 코드를 수정해야 한다.

예제에서는 한 클래스만 수정하는 것으로 보이지만 만약 여러 곳에서 SmsSender 클래스를 사용한다면 수정해야 할 곳이 많아져 어려움을 겪게 된다 즉, 유지 보수가 어려워 진다.

객체 지향 프로그래밍의 SOLID 법칙이라는 애플리케이션 디자인 5가지 원칙 중에 의존성 역전의 원칙이 있는데

"프로그래머는 추상화의 의존해야지, 구체화에 의존하면 안된다."
의존성 주입은 이 의존성 원칙을 따른다.
즉, 클래스보다는 인터페이스나 추상 클래스와 의존 관계를 맺는 것이
유연한 프로그래밍에 도움이 된다.

의존성 역전의 원칙에 따라 위에 예시 Sender 인터페이스로 리펙터링 하면

public class NotificationService(
	
    private Sender messageSender;
    
    public NotificationService(Sender messageSender){
    	this.messageSender = messageSender;
   }
   
   public boolean sendNotification(User user, String message){
   		return messageSender.sendText(user.getPhoneNumber(), message);
   }

그러면 NotificationService는 생성자 방식을 통해서 외부에서 Sender 객체를 생성하고 주입해주는 방법을 이용해야 한다. 더 이상 구현 클래스에 의존하는 것이 아닌 Sender라는 인터페이스만 의존성을 갖는다. 이로써 강하게 결합되어 있던 것이 약한 결합으로 바뀌게 된 것이다.

이렇게 외부에서 객체를 생성하고 주입해주는 방식을 스프링 프레임워크에서 스프링 빈 컨테이너가 대신 해주는 것이다.

스프링이 제공해주는 의존성 주입의 장점

  • 객체 지향 프로그래밍 기반이므로 공통 객체를 재사용할 수 있다.
  • 테스트 케이스를 작성하는 경우 목(mock) 객체를 주입하기 편리하다.
  • 강한 결합에서 약한 결합이 되므로 유연하고 변화에 빠른 대응이 가능하다.

주입하는 방식은
자바 설정 방식과 애너테이션 방식이 있는데 어떤 점이 서로 다른지 확인해보자면

애너테이션 기반 설정의 의존성 주입

의존성 주입 과정에는 의존성을 주입받을 객체와 의존성 대상 객체가 있어야 한다.
이때 이 두 객체는 모두 스프링 빈 객체여야 한다. 의존성 대상 객체를 주입받을 클래스 내부에는
객체를 저장할 변수에 @Autowired와 @Qualifier 애너테이션을 조합해서 정의해야 한다.

--- @Autowired 코드 ---

@Target({ElementType.CONSTRUCTOR, ElementType.METHOD, 
ElementType.PARAMETER, ElementType.FIELD, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Autowired {
    boolean required() default true;
}

@Target({ElementType.CONSTRUCTOR, ElementType.METHOD, ElementType.PARAMETER, ElementType.FIELD, ElementType.ANNOTATION_TYPE})
: @Autowired를 정의할 수 있는 대상은 생성자, 메서드, 파라미터, 필드, 애너테이션이다

boolean required() default true : required 속성의 기본값은 true 이다.

--- @Qualifier 코드 ---

@Target({ElementType.FIELD, ElementType.METHOD, 
ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Qualifier {
    String value() default "";
}

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE})
: 정의할 수 있는 대상은 필드, 메서드, 파라미터, 클래스, 애너테이션이다.

String value() default "" : value 속성을 제공하며, 설정값은 스프링 빈의 이름이다.

@Autowired 애너테이션은 정의된 위치에 따라
필드 주입 방식, Setter 메서드 주입, 생성자 주입 이렇게 세 가지 방식으로 나뉘어진다.

필드 주입 방식

@Autowired
@Qualifier("localDateTimeFormatter")
private Formatter formatter01;

스프링 빈 컨테이너가 formatter01 변수에 직접 Formatter 스프링 빈 객체를 할당한다.

Setter 메서드 주입

private Formatter formatter02;

@Autowired
public void setFormatter02(@Qualifier("localDateTimeFormatter")Formatter formatter){
this.formatter02 = formatter;
}

스프링 빈 컨테이너는 메서드에 정의된 인자의 클래스 타입과 변수 이름을 확인하고 대상에 맞는 스프링 빈을 주입한다.

생성자 주입

private Formatter formatter03;

@Autowired
public OrderPrinter(@Qualifier("localDateTimeFormatter") Formatter formatter){
this.formatter03 = formatter;
}

메서드와 마찬가지로 인자의 클래스 타입과 이름을 확인하고, OrderPrinter 객체를 생성할 때 대상에 맞는 스프링 빈을 주입한다.

이 세가지 방식 중에서 생성자 주입 방식을 더 선호하는데 그 이유는
필드 주입 방식과 Setter 주입 방식은 반복적으로 선언해야 한다는 단점 뿐만 아니라 Setter 메서드는 개발자 의도와 다르게 런타임 도중 다른 객체를 호출할 수 있다는 단점이 있다.
다른 개발자의 실수로 호출된 Setter 메서드가 처음에 설정된 스프링 빈을 변경할 수 있기 때문이다.

자바 설정의 의존성 주입

@Bean, @Configuration 에너테이션을 사용한 자바 설정에서도 스프링 빈끼리 의존성 주입이 가능하다. 한 개의 설정 클래스 안에서 정의된 스프링 빈들끼리 의존성을 주입하는 경우, @Bean 애너테이션이 선언된 메서드를 그대로 사용하면 의존성이 주입이 된다.

@Configuration
public class ServerConfig {

    @Bean
    public String datePattern() {
        return "yyyy-MM-dd'T'HH:mm:ss.XXX";
    }

    @Bean
    public DateFormatter defaultDateFormatter() {
        return new DateFormatter(datePattern());
    }
}

코드를 예시로 들면 defaultDateFormatter() 메서드 내부에서 datePattern() 메서드를 사용하면, datePattern 이름의 스프링 빈 객체를 빈 컨테이너가 주입해준다.

또한 자바설정을 사용하는 경우 하나의 애플리케이션에 여러 개의 설정 클래스가 있을 수 있다. 그러면 다른 자바 설정 클래스에 정의된 스프링 빈을 참조하는 방법이 있다.

@Configuration
public class DividePatternConfig {

    @Bean
    public String localDatePattern() {
        return "yyyy-MM-dd'T'HH:mm:ss";
    }
}

@Configuration
public class DivideServerConfig {

    @Bean
    public DateFormatter localDateFormatter(String localDatePattern) {
        return new DateFormatter(localDatePattern);
    }
}

스프링 빈 컨테이너는 @Bean으로 선언된 localDateFormatter() 메서드의 인자를 분석한다. 인자의 타입은 String 타입 인자의 이름은 localDatePattern 인 스프링 빈을 빈 컨테이너에서 찾아서 주입해준다.

⭐️ BeanCurrentlyInCreationException 예외

위와 같은 에러는 스프링 빈을 생성하는 과정에서 순환 참조 때문에 발생하는 예외이다.
의존성 주입 과정에서 상위 모듈과 하위 모듈 관계를 명확하게 구분할 수 없는 상황일 때 발생한다고 한다.

@Service
public class CircularService {
    private CircularReference circularReference;

    public CircularService(CircularReference circularReference) {
        this.circularReference = circularReference;
    }
}

@Service
public class CircularReference {
    private CircularService circularService;

    public CircularReference(CircularService circularService) {
        this.circularService = circularService;
    }
}

두 코드를 보면 상위 모듈과 하위 모듈 관계를 정리 할 수 없다. 이런 상황에서는 클래스를 다시 설계하거나 @Lay 애너테이션을 사용하면 된다.

5. ApplicationContext

스프링 프레임워크에서 가장 중요한 역할을 하는 인터페이스로 다양한 구현 클래스가 기본으로 제공한는 역할을 하며 스프링 빈 컨테이너, IoC 컨테이너, DI 컨테이너 등 여러 가지로 부른다.

public interface ApplicationContext extends 
EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory, 
MessageSource, ApplicationEventPublisher, 
ResourcePatternResolver {

    @Nullable
    String getId();

    String getApplicationName();

    String getDisplayName();

    long getStartupDate();

    @Nullable
    ApplicationContext getParent();

    AutowireCapableBeanFactory getAutowireCapableBeanFactory() throws IllegalStateException;
}

EnvironmentCapable : 환경 변수를 추상화한 Environment 객체를 재공하는 getter 메서드가 포함된 인터페이스이다.
ListableBeanFactory : 빈 컨테이너인 BeanFactory를 상속받는 ListableBeanFactory 스프링 빈 리스트를 리턴하는 여러 메서드가 포함됨
HierarchicalBeanFactory : BeanFactory를 상속받고 있으며 리턴받을 수 있는 메서드를 제공한다.
MessageSource : 국제화(지역 정보에 맞는 적절한 언어를 제공하는 것을 의미) 메시지를 처리할 수 있는 메서드를 제공하는 인터페이스이다.
ApplicationEventPublisher : 스프림 프레임워크에서 사용할 수 있는 이벤트들을 생성할 수 있는 메서드를 제공하는 인터페이스이다.
ResourcePatternResolver : 패턴을 이용해 Resource를 다룰 수 있는 메서드를 제공하는 인터페이스이다.

6. 스프링 빈 스코프

순수한 자바 객체는 객체를 생성하고 가비지 컬렉터로 소멸하는 과정을 거치지만
스프링 빈 객체는 ApplicationContext로 생성되고 소멸된다. 이런 빈 객체를 생성하고 소멸하는 기간을 스프링 빈 스코프라고 한다.
여기서 각 스코프에 따라 스프링 빈이 생성되는 시점과 종료되는 시점이 다르다.

-singleton : 기본값, 스프링 빈 컨테이너에서 단 한 개만 생성한다. 그래서 하나의 객체가 여러 곳에서 공유된다. ApplicationContext가 생성되는 시점에 객체가 생성되고 종료될 때 같이 소멸된다.
-prototype : 스프링 빈 컨테이너에서 여러 객체를 생성한다. 의존성 주입을 할 때마다 새로운 객체를 생성하여 주입하기 때문에 빈 컨테이너에 여러 객체가 존재한다.
-request : 웹 기능 한정 스코프이다. 스프링 빈 컨테이너는 HTTP 요청을 처리할 때마다 새로운 객체를 생성한다.
-session : 웹 기능 한정 스코프이다. Http Session과 대응하는 새로운 객체를 만든다.
-application : 웹 기능 한정 스코프이다. Servlet 컨텍스트와 대응하는 새로운 객체를 만든다.
-WebSocket : 웹 기능 한정 스코프이다. Web Socket Session과 대응하는 새로운 객체를 만든다.

별도의 스코프 설정을 하지 않는다면 모든 스프링 빈의 기본 설정은 'singleton' 스코프이다. 그래서 스프링 빈 컨테이너에는 한 개의 객체가 생성되고 이를 여러 곳에서 주입한다.

스코프를 정의하는 애너테이션은 @Scope이며 아래와 같이 정의할 수 있다.

@Bean
@Scope("singleton")
public DateFormatter dateFormatter(){...}

@Bean
@Scope("prototype")
public DateFormatter dateFormatter(){...}

request, session, application, websocket 스코프는 web 기능을 추가 제공하는 ApplicationContext 에서만 동작한다. 이들은 별도의 애너테이션으로 정의할 수 있는데
다음와 같이 사용할 수 있다.

request : @RequestScope, @Scope("request")
session : @SessionScope, @Scope("session")
application : @ApplicationScope, @Scope("application")
websocket : @Scope("websocket")

7. 스프링 빈 생명주기 관리

스프링 빈의 생명주기는 스프링 빈이 생성되고 소멸될 때까지 거치는 여러 단계의 과정을 의미한다. 스프링 프레임워크는 인터페이스와 애너테이션 같은 여러 방법을 사용하여 스프링 빈 생명주기에 개발자가 관여할 수 있는데, 이를 콜백함수라고 한다.
그러면 왜 스프링 빈 생명주기에 관여해야 하냐면 스프링 프레임워크에서 제공하는 스레드 풀의 한 종류인 ThreadPoolTaskExecutor 클래스를 스프링 빈으로 정의한다고 생각해보자.
스레드를 생성하는 비용이 크기 때문에 런타임 도중에 생성하는 것보다는 실행 전에 미리 생성하는 것이 유리하다.
그래서 개발자는 스레드 풀을 초기화하는 코드와 정리하는 코드를 각각 함수로 만들고 이를 스프링 빈 생명주기에 실행하면 된다.

콜백함수를 지정하는 방법은 다음과 같다.

  • BeanPostProcessor 인터페이스에 postProcessBeforeInitialization(), postProcessAfterInitialization() 추상 메서드 사용
  • @PostConstruct, @PreDestroy 애너테이션 정의
  • @Bean 애너테이션의 initMethod, destroyMethod 속성에 함수 이름 정의

postProcessBeforeInitialization(), postProcessAfterInitialization() 함수는 애플리케이션 초기화 시점에서만 실행되는 함수이다.

사용자가 직접 선언한 콜백 함수를 지정하는 방법은 @PostConstruct, @PreDestroy 애너테이션과 @Bean의 initMethod, destroyMethod 속성이다.

다음은 콜백 함수들의 실행 순서이다.

8. 스프링 빈 고급 정의

스프링 프레임워크에서는 스프링 빈을 정의할 때 기본 설정을 위한 @Primary,
지연 로딩 설정이 필요한 @Lazy 애너테이션이 존재한다.

@Primary

클래스 타입이 같은 여러 스프링 빈이 빈 컨테이너에 존재하면 의존성 주입을 시도할 때 어떤 스프링 빈을 주입해야 하는지 알 수가 없어 NoUniqueBeanDefinitionExcetion 예외를 발생시킨다.
이때 @Pirmary 애너테이션을 정의한 스프링 빈이 있다면 그 스프링 빈을 우선적으로 주입한다.


위에 코드와 같이 같은 클래스 타입 PriceUnit을 갖는 두 개의 스프링 빈을 만들고 실행 시키면 에러가 발생한다. 주석 처리한 @Primary 를 풀고 다시 실행 시키면 정상적으로 실행된다.

마찬가지로 스프링 빈 이름을 중복해서 선언하는 경우에도 예외가 발생하는데 여기서는
BeanDefinitionOverrideException 예외가 발생한다. 스프링 프레임워크는 스프링 빈 이름이 같으면 덮어쓰는데


위와 같이 에러 메시지에서도 속성을 true로 변경해주면 예외가 발생하지 않는다고 친절하게 설명해준다.

가능하면 이 속성은 false로 유지하는 것이 좋다고 한다.

@Lazy

@Lazy 애너테이션은 스프링 빈 생성을 지연시켜주는데 스프링 빈 컨테이너가 설정만 로딩하고 의존성을 주입하는 시점에 스프링 빈 객체를 생성하는 방식이다.

profile
YongHyun
백엔드 개발자 되기 위한 여정
이전 포스트

스프링 부트로 개발하는 MSA 컴포넌트 1(책 정리)

다음 포스트

스프링 부트로 개발하는 MSA 컴포넌트 3 (책정리)

0개의 댓글