[스프링 핵심 원리와 활용] 섹션7. 외부 설정과 프로필1(3)-8/9

[im1sun]

9. 설정 데이터1 - 외부 파일

지금까지 학습한 OS 환경 변수, 자바 시스템 속성, 커맨드 라인 옵션 인수는 사용해야 하는 값이 늘어날 수록 사용하기가 불편해진다. 실무에서는 수십개의 설정값을 사용하기도 하므로 이런 값들을 프로그램을 실행할 때 마다 입력하게 되면 번거롭고, 관리도 어렵다.

그래서 등장하는 대안으로는 설정값을 파일에 넣어서 관리하는 방법이다. 그리고 애플리케이션 로딩 시점에 해당 파일을 읽어들이면 된다. 그 중에서도 .properties 라는 파일은 key=value 형식을 사용해서 설정값을 관리하기에 아주 적합하다.

application.properties` 개발 서버에 있는 외부 파일

url=dev.db.com
username=dev_user
password=dev_pw

application.properties 운영 서버에 있는 외부 파일

url=prod.db.com
username=prod_user
password=prod_pw

예를 들면 개발 서버와 운영 서버 각각에 application.properties 라는 같은 이름의 파일을 준비해둔다.
그리고 애플리케이션 로딩 시점에 해당 파일을 읽어서 그 속에 있는 값들을 외부 설정값으로 사용하면 된다.
참고로 파일 이름이 같으므로 애플리케이션 코드는 그대로 유지할 수 있다.

스프링과 설정 데이터
개발자가 파일을 읽어서 설정값으로 사용할 수 있도록 개발을 해야겠지만, 스프링 부트는 이미 이런 부분을 다 구현해두었다. 개발자는 application.properties 라는 이름의 파일을 자바를 실행하는 위치에 만들어 두기만 하면 된다.
그러면 스프링이 해당 파일을 읽어서 사용할 수 있는 PropertySource 의 구현체를 제공한다. 스프링에서는 이러한 application.properties 파일을 설정 데이터(Config data)라 한다.
당연히 설정 데이터도 Environment 를 통해서 조회할 수 있다.

참고
지금부터 설명할 내용은 application.properties 대신에 yml 형식의 application.yml 에도 동일하게 적용된다. yml 과 application.yml 은 뒤에 자세히 설명한다.

동작 확인

• ./gradlew clean build
• build/libs로 이동
• 해당 위치에 application.properties 파일 생성

url=dev.db.com
username=dev_user
password=dev_pw

java -jar external-0.0.1-SNAPSHOT.jar 실행

실행 결과

env url=devdb
env username=dev_user
env password=dev_pw

이렇게 각각의 환경에 따라 설정 파일의 내용을 다르게 준비하면 된다. 덕분에 설정값의 내용이 많고 복잡해도 파일로 편리하게 관리할 수 있다.

남은 문제

• 외부 설정을 별도의 파일로 관리하게 되면 설정 파일 자체를 관리하기 번거로운 문제가 발생한다.
• 서버가 10대면 변경사항이 있을 때 10대 서버의 설정 파일을 모두 각각 변경해야 하는 불편함이 있다.
• 설정 파일이 별도로 관리되기 때문에 설정값의 변경 이력을 확인하기 어렵다. 특히 설정값의 변경 이력이 프로젝트 코드들과 어떻게 영향을 주고 받는지 그 이력을 같이 확인하기 어렵다.

10. 설정 데이터2 - 내부 파일 분리

설정 파일을 외부에 관리하는 것은 상당히 번거로운 일이다. 설정을 변경할 때 마다 서버에 들어가서 각각의 변경 사항을 수정해두어야 한다.(물론 이것을 자동화 하기 위해 노력할 수는 있다)

이 문제를 해결하는 간단한 방법은 설정 파일을 프로젝트 내부에 포함해서 관리하는 것이다. 그리고 빌드 시점에 함께 빌드되게 하는 것이다.

이렇게 하면 애플리케이션을 배포할 때 설정 파일의 변경 사항도 함께 배포할 수 있다. 쉽게 이야기해서 jar 하나로 설정 데이터까지 포함해서 관리하는 것이다.

• 0. 프로젝트 안에 소스 코드 뿐만 아니라 각 환경에 필요한 설정 데이터도 함께 포함해서 관리한다.
  • 개발용 설정 파일: application-dev.properties
  • 운영용 설정 파일: application-prod.properties
• 1. 빌드 시점에 개발, 운영 설정 파일을 모두 포함해서 빌드한다.
• 2. app.jar 는 개발, 운영 두 설정 파일을 모두 가지고 배포된다.
• 3. 실행할 때 어떤 설정 데이터를 읽어야 할지 최소한의 구분은 필요하다.
  • 개발 환경이라면 application-dev.properties 를 읽어야 하고,
  • 운영 환경이라면 application-prod.properties 를 읽어야 한다.
  • 실행할 때 외부 설정을 사용해서 개발 서버는 dev 라는 값을 제공하고, 운영 서버는 prod 라는 값을 제공하자. 편의상 이 값을 프로필이라 하자.
    • dev 프로필이 넘어오면 application-dev.properties 를 읽어서 사용한다.
    • prod 프로필이 넘어오면 application-prod.properties 를 읽어서 사용한다.

외부 설정으로 넘어온 프로필 값이 dev 라면 application-dev.properties 를 읽고 prod 라면 application-prod.properties 를 읽어서 사용하면 된다. 스프링은 이미 설정 데이터를 내부에 파일로 분리해m두고 외부 설정값(프로필)에 따라 각각 다른 파일을 읽는 방법을 다 구현해두었다.

스프링과 내부 설정 파일 읽기
main/resources 에 다음 파일을 추가하자

application-dev.properties 개발 프로필에서 사용

url=dev.db.com
username=dev_user
password=dev_pw

application-prod.properties 운영 프로필에서 사용

url=prod.db.com
username=prod_user
password=prod_pw

프로필
스프링은 이런 곳에서 사용하기 위해 프로필이라는 개념을 지원한다.
spring.profiles.active 외부 설정에 값을 넣으면 해당 프로필을 사용한다고 판단한다.
그리고 프로필에 따라서 다음과 같은 규칙으로 해당 프로필에 맞는 내부 파일(설정 데이터)을 조회한다.

• application-{profile}.properties
  예)
  • spring.profiles.active=dev
    • dev 프로필이 활성화 되었다.
    • application-dev.properties 를 설정 데이터로 사용한다.
  • spring.profiles.active=prod
    • prod 프로필이 활성화 되었다.
    • application-prod.properties 를 설정 데이터로 사용한다.

실행

• IDE에서 커맨드 라인 옵션 인수 실행
  • --spring.profiles.active=dev
• IDE에서 자바 시스템 속성 실행
  • -Dspring.profiles.active=dev
• Jar 실행
  • ./gradlew clean build
  • build/libs로 이동
  • java -Dspring.profiles.active=dev -jar external-0.0.1-SNAPSHOT.jar
  • java -jar external-0.0.1-SNAPSHOT.jar --spring.profiles.active=dev

dev 프로필로 실행 결과

The following 1 profile is active: "dev"
...
env url=devdb
env username=dev_user
env password=dev_pw

prod 프로필로 실행 결과

The following 1 profile is active: "prod"
...
env url=prod.db.com
env username=prod_user
env password=prod_pw

이제 설정 데이터를 프로젝트 안에서 함께 관리할 수 있게 되었고, 배포 시점에 설정 정보도 함께 배포된다.

남은 문제
설정 파일을 각각 분리해서 관리하면 한눈에 전체가 들어오지 않는 단점이 있다.

11. 설정 데이터3 - 내부 파일 합체

설정 파일을 각각 분리해서 관리하면 한눈에 전체가 들어오지 않는 단점이 있다.
스프링은 이런 단점을 보완하기 위해 물리적인 하나의 파일 안에서 논리적으로 영역을 구분하는 방법을 제공한다.

• 기존에는 dev 환경은 application-dev.properties , prod 환경은 application-prod.properties 파일이 필요했다.

• 스프링은 하나의 application.properties 파일 안에서 논리적으로 영역을 구분하는 방법을 제공한다.

• application.properties 라는 하나의 파일 안에서 논리적으로 영역을 나눌 수 있다.

  • application.properties 구분 방법 #--- 또는 !--- (dash 3)
  • application.yml 구분 방법 --- (dash 3)

• 그림의 오른쪽 application.properties 는 하나의 파일이지만 내부에 2개의 논리 문서로 구분되어 있다.

  • dev 프로필이 활성화 되면 상위 설정 데이터가 사용된다.
  • prod 프로필이 활성화 되면 하위 설정 데이터가 사용된다.

• 프로필에 따라 논리적으로 구분된 설정 데이터를 활성화 하는 방법

  • spring.config.activate.on-profile 에 프로필 값 지정

설정 데이터를 하나의 파일로 통합하기
우선 기존 내용을 사용하지 않도록 정리해야 한다.
다음 내용은 사용하지 않도록 # 을 사용해서 주석 처리하자.
application-dev.properties 주석 처리

#url=dev.db.com
#username=dev_user
#password=dev_pw

application-prod.properties 주석 처리

#url=prod.db.com
#username=prod_user
#password=prod_pw

main/resources 에 다음 파일을 추가하자
application.properties

spring.config.activate.on-profile=dev
url=dev.db.com
username=dev_user
password=dev_pw
#---
spring.config.activate.on-profile=prod
url=prod.db.com
username=prod_user
password=prod_pw

주의!

• 속성 파일 구분 기호에는 선행 공백이 없어야 하며 정확히 3개의 하이픈 문자가 있어야 한다.
• 구분 기호 바로 앞과 뒤의 줄은 같은 주석 접두사가 아니어야 한다.

파일을 분할하는 #--- 주석 위 아래는 주석을 적으면 안된다.

...
#
#---
...

• 분할 기호 위에 주석이 있다. 문서가 정상적으로 읽히지 않을 수 있다.

...
#---
#
...

• 분할 기호 아래에 주석이 있다. 문서가 정상적으로 읽히지 않을 수 있다.

실행

• 커맨드 라인 옵션 인수 실행
  • --spring.profiles.active=dev
• 자바 시스템 속성 실행
  • -Dspring.profiles.active=dev
• Jar 실행
  • ./gradlew clean build
  • build/libs로 이동
  • java -Dspring.profiles.active=dev -jar external-0.0.1-SNAPSHOT.jar
  • java -jar external-0.0.1-SNAPSHOT.jar --spring.profiles.active=dev

dev 프로필로 실행 결과

The following 1 profile is active: "dev"
...
env url=devdb
env username=dev_user
env password=dev_pw

prod 프로필로 실행 결과

The following 1 profile is active: "prod"
...
env url=prod.db.com
env username=prod_user
env password=prod_pw

이제 application.properties 라는 파일 하나에 통합해서 다양한 프로필의 설정 데이터를 관리할 수 있다.

12. 우선순위 - 설정 데이터

application.properties

spring.config.activate.on-profile=dev
url=dev.db.com
username=dev_user
password=dev_pw
#---
spring.config.activate.on-profile=prod
url=prod.db.com
username=prod_user
password=prod_pw

이런 상태에서 만약 프로필을 적용하지 않는다면 어떻게 될까?
--spring.profiles.active=dev 이런 옵션을 지정하지 않는다는 뜻이다.
프로필을 적용하지 않고 실행하면 해당하는 프로필이 없으므로 키를 각각 조회하면 값은 null 이 된다.

실행 결과

No active profile set, falling back to 1 default profile: "default"
...
env url=null
env username=null
env password=null

실행 결과를 보면 첫줄에 활성 프로필이 없어서 default 라는 이름의 프로필이 활성화 되는 것을 확인할 수 있다. 프로필을 지정하지 않고 실행하면 스프링은 기본으로 default 라는 이름의 프로필을 사용한다.

기본값
내 PC에서 개발하는 것을 보통 로컬(local ) 개발 환경이라 한다. 이때도 항상 프로필을 지정하면서 실행하는 것은 상당히 피곤할 것이다.
설정 데이터에는 기본값을 지정할 수 있는데, 프로필 지정과 무관하게 이 값은 항상 사용된다.

application.properties - 수정

url=local.db.com
username=local_user
password=local_pw
#---
spring.config.activate.on-profile=dev
url=dev.db.com
username=dev_user
password=dev_pw
#---
spring.config.activate.on-profile=prod
url=prod.db.com
username=prod_user
password=prod_pw

스프링은 문서를 위에서 아래로 순서대로 읽으면서 설정한다.

여기서 처음에 나오는 다음 논리 문서는 spring.config.activate.on-profile 와 같은 프로필 정보가 없다.
따라서 프로필과 무관하게 설정 데이터를 읽어서 사용한다. 이렇게 프로필 지정과 무관하게 사용되는 것을 기본값이라 한다.

url=local.db.com
username=local_user
password=local_pw

실행
프로필을 지정하지 않고 실행해보자.

실행 결과

No active profile set, falling back to 1 default profile: "default"
...
env url=local.db.com
env username=local_user
env password=local_pw

실행 결과 특정 프로필이 없기 때문에 기본값이 사용된다.

이번에는 프로필을 지정하고 실행해보자.

실행

• 커맨드 라인 옵션 인수 실행
  • --spring.profiles.active=dev
• 자바 시스템 속성 실행
  • -Dspring.profiles.active=dev

실행 결과

env url=dev.db.com
env username=dev_user
env password=dev_pw

프로필을 준 부분이 기본값 보다는 우선권을 가지는 것을 확인할 수 있다.

설정 데이터 적용 순서
이번에는 설정 데이터의 적용 순서에 대해서 좀 더 자세히 알아보자.

application.properties

url=local.db.com
username=local_user
password=local_pw
#---
spring.config.activate.on-profile=dev
url=dev.db.com
username=dev_user
password=dev_pw
#---
spring.config.activate.on-profile=prod
url=prod.db.com
username=prod_user
password=prod_pw

사실 스프링은 단순하게 문서를 위에서 아래로 순서대로 읽으면서 사용할 값을 설정한다.

• 1. 스프링은 순서상 위에 있는 local 관련 논리 문서의 데이터들을 읽어서 설정한다. 여기에는 spring.config.activate.on-profile 와 같은 별도의 프로필을 지정하지 않았기 때문에 프로필과 무관하게 항상 값을 사용하도록 설정한다.

url=local.db.com
username=local_user
password=local_pw

• 2. 스프링은 그 다음 순서로 dev 관련 논리 문서를 읽는데 만약 dev 프로필이 설정되어있다면 기존 데이터를 dev 관련 논리 문서의 값으로 대체한다. 물론 dev 프로필을 사용하지 않는다면 dev 관련 논리 문서는 무시되고, 그 값도 사용하지 않는다.

url=local.db.com -> dev.db.com
username=local_user -> dev_user
password=local_pw -> dev_pw

• 3. 스프링은 그 다음 순서로 prod 관련 논리 문서를 읽는데 만약 prod 프로필이 설정되어있다면 기존 데이터를 prod 관련 논리 문서의 값으로 대체한다. 물론 prod 프로필을 사용하지 않는다면 prod 관련 논리 문서는 무시되고, 그 값도 사용하지 않는다.

url=dev.db.com -> prod.db.com
username=dev_user -> prod_user
password=dev_pw -> prod_pw

참고로 프로필을 한번에 둘 이상 설정하는 것도 가능하다.

• --spring.profiles.active=dev,prod

순서대로 설정 확인
극단적인 예시를 통해서 순서를 확실히 이해해보자.

application.properties - 수정

url=local.db.com
username=local_user
password=local_pw
#---
spring.config.activate.on-profile=dev
url=dev.db.com
username=dev_user
password=dev_pw
#---
spring.config.activate.on-profile=prod
url=prod.db.com
username=prod_user
password=prod_pw
#---
url=hello.db.com

스프링이 설정 파일을 위에서 아래로 순서대로 읽어서 사용할 값을 설정한다는 것은 이 예제를 실행해보면 확실히 이해할 수 있다.
결과가 어떻게 나올지 먼저 상상해보자.

• 1. 스프링은 처음에 local 관련 논리 문서의 데이터들을 읽어서 설정한다. 여기에는 별도의 프로필을 지정하지 않았기 때문에 프로필과 무관하게 항상 값이 설정된다.
• 2. 스프링은 그 다음 순서로 dev 관련 논리 문서를 읽는데 만약 dev 프로필이 설정 되어있다면 기존 데이터를 dev 관련 논리 문서의 값으로 대체한다.
• 3. 스프링은 그 다음 순서로 prod 관련 논리 문서를 읽는데 만약 prod 프로필이 설정 되어있다면 기존 데이터를 prod 관련 논리 문서의 값으로 대체한다.
• 4. 스프링은 마지막으로 hello 관련 논리 문서의 데이터들을 읽어서 설정한다. 여기에는 별도의 프로필을 지정하지 않았기 때문에 프로필과 무관하게 항상 값이 설정된다.

위에서 아래로 순서대로 실행하는데, 마지막에는 프로필이 없기 때문에 항상 마지막의 값들을 적용하게 된다.
만약 prod 프로필을 사용한다면 다음과 같이 설정된다.

The following 1 profile is active: "prod"
...
url=hello.db.com
username=prod_user
password=prod_pw

물론 이렇게 사용하는 것은 의미가 없다. 이해를 돕기 위해 이렇게 극단적인 예제를 사용했다. 보통은 기본값을 처음에 두고 그 다음에 프로필이 필요한 논리 문서들을 둔다.

정리하면 다음과 같다.

• 단순하게 문서를 위에서 아래로 순서대로 읽으면서 값을 설정한다. 이때 기존 데이터가 있으면 덮어쓴다.
• 논리 문서에 spring.config.activate.on-profile 옵션이 있으면 해당 프로필을 사용할 때만 논리 문서를 적용한다.

속성 부분 적용
만약 프로필에서 일부 내용만 교체하면 어떻게 되는지 알아보자.

url=local.db.com
username=local_user
password=local_pw
#---
spring.config.activate.on-profile=dev
url=dev.db.com

만약 다음과 같이 적용하고 dev 프로필을 사용하면 어떤 결과가 나올까?

먼저 순서대로 local 관련 정보가 입력된다.

url=local.db.com
username=local_user
password=local_pw

이후에 dev 관련 문서를 읽게 되는데, dev 프로필이 활성화 되어 있다고 가정하자. dev 관련 문서에서는
url=dev.db.com 만 설정한다. 이 경우 기존에 설정값에서 url 만 변경된다.

The following 1 profile is active: "dev"
...
url=dev.db.com
username=local_user
password=local_pw

최종적으로 url 부분은 dev.db.com 으로dev 프로필에서 적용한 것이 반영되고, 나머지는 처음에 입력한 기본값이 유지된다.

스프링의 우선순위에 따른 설정값은 대부분 지금과 같이 기존 데이터를 변경하는 방식으로 적용된다.

13. 우선순위 - 전체

스프링 부트는 같은 애플리케이션 코드를 유지하면서 다양한 외부 설정을 사용할 수 있도록 지원한다.

외부 설정에 대한 우선순위 - 스프링 공식 문서
https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config

우선순위는 위에서 아래로 적용된다. 아래가 더 우선순위가 높다.

자주 사용하는 우선순위

• 설정 데이터(application.properties )
• OS 환경변수
• 자바 시스템 속성
• 커맨드 라인 옵션 인수
• @TestPropertySource (테스트에서 사용)

설정 데이터 우선순위

• jar 내부 application.properties
• jar 내부 프로필 적용 파일 application-{profile}.properties
• jar 외부 application.properties
• jar 외부 프로필 적용 파일 application-{profile}.properties

설정 데이터 우선순위 - 스프링 공식 문서
https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config.files

우선순위 이해 방법
우선순위는 상식 선에서 딱 2가지만 생각하면 된다.

• 더 유연한 것이 우선권을 가진다. (변경하기 어려운 파일 보다 실행시 원하는 값을 줄 수 있는 자바 시스템 속성이 더 우선권을 가진다.)
• 범위가 넒은 것 보다 좁은 것이 우선권을 가진다.
  • OS 환경변수 보다 자바 시스템 속성이 우선권이 있다.
  • 자바 시스템 속성 보다 커맨드 라인 옵션 인수가 우선권이 있다.

추가 또는 변경되는 방식
Environment 를 통해서 조회하는 관점에서 보면 외부 설정값들은 계속 추가되거나 기존 값을 덮어서 변경하는 것 처럼 보인다. 물론 실제 값을 덮어서 변경하는 것은 아니고, 우선순위가 높은 값이 조회되는 것이다. 그런데 이렇게 이해하면 개념적으로 더 쉽게 이해할 수 있다.

예를 들어서 설정 데이터(application.properties )에 다음과 같이 설정했다.
application.properties

url=local.db.com

자바 시스템 속성을 다음과 같이 적용했다.
자바 시스템 속성 추가
-Dusername=local_user

조회 결과

url=local.db.com
username=local_user

자바 시스템 속성에서 기존에 없던 키 값을 추가했기 때문에 속성이 추가되었다.

커맨드 라인 옵션 인수를 다음과 같이 적용했다.
커맨드 라인 옵션 인수 추가
--url=dev.db.com
조회 결과

url=dev.db.com
username=local_user

커맨드 라인 옵션 인수는 기존에 있던 url 이라는 키 값을 사용했기 때문에 기존에 있던 값이 새로운 값으로 변경되었다.

정리
이렇게 우선순위에 따라서 설정을 추가하거나 변경하는 방식은 상당히 편리하면서도 유연한 구조를 만들어준다. 실무에서 대부분의 개발자들은 applicaiton.properties 에 외부 설정값들을 보관한다. 이렇게 설정 데이터를 기본으로 사용하다가 일부 속성을 변경할 필요가 있다면 더 높은 우선순위를 가지는 자바 시스템 속성이나 커맨드 라인 옵션 인수를 사용하면 되는 것이다.
또는 기본적으로 application.properties 를 jar 내부에 내장하고 있다가, 특별한 환경에서는 application.properties 를 외부 파일로 새로 만들고 변경하고 싶은 일부 속성만 입력해서 변경하는 것도 가능하다.