개요

사용자 관련 CRUD 기능 구현을 마치고 해당 모듈에 필요한 부가 기능(로깅AOP, 예외 처리 전역 설정 등) 구현까지 마쳤다.
이제 주요 기능을 추가하기에 앞서 MSA 환경을 구축하기 위한 아래의 Spring Cloud 기능을 사용해보려 한다.

• Spring Cloud Config
• Spring Cloud Eureka
• Spring Cloud Gateway
• Spring Cloud OpenFeign

이 중 Spring Cloud Config를 적용해보자.

Spring Cloud Config

이전에 프로젝트를 중간에 맡게 되었을 때 application.yml파일을 환경 별로 여러개의 파일로 나뉘어 관리하고 있었는데 demo, dev, prd, tb 등등 어떤 환경에서 사용하는 코드인지 명확히 구분할 수 없었던 경우가 있었다...
혹은 환경 별로 중복되는 코드가 있음에도 복사, 붙여넣기 하여 수정 시에도 번거롭게 되었던 경우도 있었다.

MSA 프로젝트의 경우 더욱 그러하다.
여러개의 모듈마다 환경 별로 설정을 해야하는데 모듈이 늘어날 수록 중복되는 파일이 늘어나게 된다.

이를 Spring Cloud Config를 통해 해결할 수가 있는데 Config 파일을 모아놓은 저장소를 만들고 각각의 모듈마다 import하여 공통으로 .yml 파일을 관리할 수 있어 공통 설정 값의 통일성과 유지보수 측면에서 많은 장점을 가진다.

무엇보다 좋은 점은 많은 중요 정보(db접속정보 등)를 해당 파일에 작성하게 되는데 별도의 private repository로 파일을 관리하다보니 중요 정보를 노출 시키지 않을 수가 있다.

로컬 환경에서 개발 후 Config Repository에 반영 해주어야한다는 점은 조금 번거로울 수 있으나 감수할만하다.

설정 방법은 간단하다.

필자는 config-files라는 github private repository에 설정파일들을 모아놓고 config-server를 구성했다.

Config-Server

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-actuator'
    implementation 'org.springframework.cloud:spring-cloud-config-server'
}

의존성은 spring-cloud-config-server를 추가해주면 된다.
actuator는 모든 모듈에 추가하여 health 체크 또는 refresh를 통해 변경된 설정 반영과 같은 기능을 사용하기 위해 추가했다.

Config Server에서는 설정을 변경한 후 /actuator/refresh를 호출하여 변경된 설정을 애플리케이션에 즉시 반영할 수 있다.

server:
  port: 8888

spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        encrypt.enabled: true
        git:
          uri: github-uri
          default-label: main
          username: username
          password: password

# actuator 설정
management:
  endpoints:
    web:
      exposure:
        include: "*"
  endpoint:
    shutdown:
      enabled: true

@EnableConfigServer
@SpringBootApplication
public class ConfigServerApplication {

	public static void main(String[] args) {
		SpringApplication.run(ConfigServerApplication.class, args);
	}

}

위와 같이 config-server에 코드를 추가해주면 github uri를 통해 설정 파일을 다른 모듈에서 가져갈 수 있게 된다.

server:
  port: 9000

spring:
  application:
    name: user-service
  config:
    import: optional:configserver:http://localhost:8888

config-client에서는 spring.config.import에 config-server의 주소를 넣어주면 된다. 그럼 어떤 설정 파일을 가져오게 되는 것일까?

https://velog.io/@haerong22/Spring-Cloud-%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-MSA-5.-%EC%84%A4%EC%A0%95%ED%8C%8C%EC%9D%BC-%EA%B4%80%EB%A6%ACconfig

위 링크에 자세히 설명 되어 있다.

간단히 이야기 하자면

ex) 프로젝트의 이름은 api-service, 환경(profile)은 dev 라고 가정해보자.
1. 프로젝트 내의 application.yml
2. Config Server의 application.yml
3. 프로젝트 내의 application-dev.yml
4. Config Server의 application-dev.yml
5. Config Server의 api-service.yml
6. Config Server의 api-service-dev.yml

이러한 순서로 참조를 하게 되는데 즉, config server의 application.yml에 공통 설정 값을 작성하고 서비스명으로 된 yml 파일에 개별 설정 값을 작성하면 중복 코드를 줄이면서 각각의 모듈과 환경에 맞게 설정 값을 참조할 수 있게 된다.

마치며

이렇게 설정 파일을 쉽게 관리할 수 있게 되었다.
이전에는 중요 정보 노출을 막기 위해 git submodule을 활용하여 설정 파일을 관리하였는데 두가지 모두 경험해보니 spring config를 활용하는 쪽이 더 편리한 것 같다.

다음은 eureka, gateway 적용 후 gateway에서 인증 작업을 담당하는 filter를 구현해보려고 한다.