외부 구성 저장소 패턴

• 다양한 서비스 등록, 탐색 위한 Service registry , Service discovery 패턴
• 서비스 단일 진입을 위한 API 게이트웨이(gateway) 패턴 & BFF(Backend For Frontend) 패턴
• 외부 구성 저장소 패턴
• 마이크로서비스 인증/인가 패턴
• 장애 및 실패 처리를 위한 서킷 브레이크 패턴
• 모니터링과 추적 패턴
• 중앙화된 로그 집계 패턴
• 서비스 매시(Service Mesh) 패턴

외부 구성 저장소 패턴

다음은 어플리케이션 구성 정보 설정에 관련된 패턴이다. 클라우드 인프라와 같이 유연한 인프라를 사용하는 상황에서 DB연결 정보, 파일스토리지 정보같은 정보를 어플리케이션에 포함하게 되면 변경 시 재 배포 하는데 이럴 경우 서비스가 중단되게 된다. 또한 여러 마이크로서비스가 동일한 구성 정보를 사용하는 경우에도 일일이 변경하기가 어렵고 변경 시점에 일부 마이크로서비스의 구성 정보가 불일치 될 수도 있다. 따라서 마이크로서비스가 사용하는 자원의 설정 정보를 쉽고 일관되게 변경가능하도록 관리할 필요가 있다.

이를 위한 방법이 외부 저장소 패턴이다. 이는 각 마이크로서비스의 외부 환경 설정 정보를 공동으로 저장하는 백업저장소이다. PaaS솔루션을 개발하는 Heroku 사에서 발표한 Twelve-Factor 라는 클라우드 네이티브 애플리케이션을 만들기 위한 체크리스트가 있는데 ‘컨피그(Config)’라는 체크 항목을 언급한다. 이는 어플리케이션이 배포되는 환경(스테이징, 프로덕션, 개발, 테스트 환경)이 매번 달라지기 때문에 코드에서 사용하는 환경 설정 정보는 코드와 완전히 분리되어 관리할 것이 바람직하다는 말이다.

풀어 설명하면 클라우드에서 운영되는 애플리케이션은 특정한 배포 환경에 종속된 정보를 코드에 가지고 있으면 안 된다는 원칙이다. 왜냐하면 이러한 정보를 애플리케이션이 가지고 있게 된다면 배포 환경이 변경되었을 때 어플리케이션 또한 변경해야 하기 때문이다. 이렇게 분리해야 할 환경 정보로는 데이터베이스 연결 정보, 배포 시 변경되어야 할 호스트 명, 백엔드 서비스의 연결을 위한 리소스 정보 등이 되는데 예를 들면 개발 서버, 테스트, 운영 서버는 IP와 포트 정보 등이 환경 변수로 이용될 수 있다.

예로써 아래그림과 같이 스프링 클라우드 컨피그(Spring Cloud Config)를 사용하면 이러한 환경정보를 코드에서 분리하여 컨피그 서비스를 통해 런타임 시 주입되게 할 수 있다. 환경 정보는 GIT같은 별도의 형상관리 레파지토리에 보관되고 컨피그 서비스는 해당 서비스에 특정 환경에 배포될 때 적절한 환경정보를 형상관리 레파지토리에서 가져와서 해당서비스에 주입해 준다.

쿠버네이트 이런 외부 구성 저장소 패턴을 쿠버네티스 컨피그맵(ConfigMap)로 제공한다.