일반적으로 구성 정보는 저수준의 프로퍼티 파일 (YAML, JSON, XML 등)에 작성하고 미들웨어의 접속 정보와 애플리케이션의 행동 양식을 정하는 메타데이터가 존재하는 서버에 둔다. 그러나 이러한 방식은 수많은 마이크로서비스 인스턴스가 실행되는 클라우드 기반의 애플리케이션 상황에서는 관리가 까다롭다.
따라서 클라우드 기반의 마이크로서비스 개발에서는 다음 사항이 강조됨.
구성 관리를 사람이 수동으로 구성하거나 배포하면 구성 편차(Configuration drift)와 예상치 못한 장애, 애플리케이션 확장 요구에 대한 지체 시간(lag-time)이 발생할 수 있다. 특히 수많은 인스턴스가 실행되어야 하는 마이크로서비스에선 애플리케이션 구성 관리는 매우 중요하다.
따라서 다음 원칙을 준수하여야 한다.
애플리케이션 구성 정보와 서비스 인스턴스를 함께 배포하는 것이 아닌, 시작하는 서비스에 환경 변수로 전달하거나 중앙 저장소에서 읽어와 구성 정보를 전달한다.
서비스 인터페이스 뒷단의 구성 데이터 접근 방식을 추상화한다. 서비스 저장소에 직접 액세스 코드를 작성하기 보단 애플리케이션이 REST 기반의 JSON 서비스를 사용해 구성 데이터를 조회하게 만든다.
애플리케이션의 구성 정보를 일부 저장소에 집중시킨다.
애플리케이션 구성 정보를 배포된 서비스와 완전히 분리하고 중앙 집중화하므로 어떤 솔루션을 사용하더라도 고가용성과 다중성을 갖추어야 한다.
그리고 구성 관리를 실제 서비스와 분리함으로써 외부 의존성이 생기기 때문에 형상관리는 필수!
구성 관리는 마이크로서비스의 BootStraping 단계에서 일어난다.
프로젝트 이름 | 설명 | 특성 |
---|---|---|
Etcd | Go 언어로 작성된 오픈 소스 프로젝트로 서비스 검색과 키-값 관리에 사용되며, 분산 컴퓨팅 모델용 Raft(https://raft.github.io/) 프로토콜을 사용 | ✔️ 초고속, 확장 가능 ✔️ 분산 가능 ✔️ 명령줄 위주 ✔️ 사용과 설치가 간단함 |
유레카 (Eureka) | 넷플릭스가 만들었으며, 수많은 실전 테스트를 거침. 서비스 검색과 키-값 관리에 사용됨 | ✔️ 분산 키-값 저장소 ✔️ 유연하지만 설정하는 데 공수가 듦 ✔️ 동적 클라이언트 갱신 기능을 제공함 |
콘설(Consul) | 하시코프(HashiCorp)가 만듦. Etcd 및 Eureka와 비슷한 기능을 제공하나 분산 컴퓨팅 모델에 다른 알고리즘을 사용한다. (SWIM 프로토콜) | ✔️ 빠름 ✔️ DNS와 직접 통합해 네이티브 서비스 검색을 제공 ✔️ 동적 클라이언트 갱신은 기본 기능으로 제공하지 않는다. |
주키퍼 (Zookeeper) | 분산 잠금(distributed locking) 기능을 제공하는 아파치 프로젝트로 키-값 데이터용 구성 관리 솔루션으로 자주 사용함 | ✔️ 가장 오래되고 실전 경험이 많은 솔루션 ✔️ 가장 사용하기 복잡함 ✔️ 구성 관리에 사용 가능하지만 이미 사용 중일때만 고려할 것 |
스프링 클라우드 컨피그 서버 (Spring Cloud Config Server) | 다양한 백엔드와 함께 일반적인 구성 관리 솔루션을 제공하는 오픈 소스 프로젝트로 깃(Git), 유레카, 콘설 같은 백엔드와 통합 가능하다 | ✔️ 비분산 키-값 저장소 ✔️ 스프링 및 스프링 기반이 아닌 서비스와 통합 가능함 ✔️ 공유 파일과 시스템, 유레카, 콘설, 깃 등 구성 데이터 저장을 위한 다양한 백엔드 사용이 가능 |