서비스 디스커버리

서비스 디스커버리 등장 배경?

분산 아키텍처에서는 시스템의 물리적 위치 주소를 찾아야 한다. 이 개념은 분산 컴퓨팅 초창기 때부터 존재했고 공식적으로 서비스 디스커버리라고 한다.

서비스 디스커버리 유형

• 서비스 디스커버리는 애플리케이션에서 사용하는 모든 원격 서비스의 주소가 포함된 프로퍼티 파일을 관리하는 것처럼 단순한 경우.
• UUID 저장소처럼 정형화되고 복잡한 것일 수 있다.

서비스 디스커버리 중요성

첫 번째, 애플리케이션 팀은 서비스 디스커버리를 사용해 해당 환경에서 시행하는 서비스 인스턴스 개수를 신속하게 수평 확장하거나 축소할 수 있다.

• 서비스 디스커버리를 통해 서비스의 물리적 위치는 서비스 소비자에게는 드러나지 않는다.
• 서비스 소비자는 실제 서비스 인스턴스의 물리적 위치를 모르기 때문에 서비스 풀에서 새로운 서비스 인스턴스의 추가나 삭제가 자유롭다.

• 일반적으로 모놀리식 방식을 사용하면 개발 팀은 필요한 용량보다 초과 구매를 하게 된다.

• 용량이 대량 큰 폭으로 증가되므로 원만하게 진행되는 경우는 드물다.

• 마이크로서비스 방식을 사용하면 새로운 인스턴스만 확장 축소할 수 있다.

두 번째, 애플리케이션 회복성을 향상하는데 도움이 된다는 것이다.

• 마이크로 서비스 인스턴스가 비정상이거나 가용하지 않다면 대부분의 서비스 디스커버리 엔진은 내부의 가용 서비스 목록에서 해당 인스턴스를 제거한다.

• 서비스 디스커버리 엔진이 사용할 수 없는 서비스를 피해 라우팅하므로 다운된 서비스가 야기한 피해를 최소화 한다.

서비스 위치 찾기.

애플리케이션에서 여러 서버로 분산된 자원을 호출할 때마다 해당 자원의 물리적 위치를 찾아야 한다. 클라우드가 아닌 환경에서 이 서비스의 위치 확인은 대개 DNS와 네트워크 로드 밸런서로 해결되었다.

이처럼 애플리케이션은 다른 조직에 있는 서비스를 호출해야 한다. 애플리케이션이 호출하려던 서비스를 대표하는 고유 경로와 함께 일반적인 DNS 이름을 사용해 서비스 호출을 시도한다.
(서비스 소비자에게 요청을 받으면 로드 밸런서는 사용자가 엑세스하려는 경로를 기반으로 라우팅 테이블에서 물리적 주소 항목을 찾는다. )