서비스 소비자를 중단하지 않고 서비스를 확장하고 축소할 수 있는 이러한 능력은 매력적인 개념이다. 모놀리식과 싱글 테넌트(single-tenant)(예를 들어 한 고객을 위한)2 애플리케이션을 구축하는 데 익숙한 개발 팀이 더 크고 좋은 하드웨어를 추가하는 수직 확장만이 유일한 확장 방식이라는 고정 관념에서 벗어나게 하고, 더 많은 서버를 추가하는 수평 확장을 더욱 강력한 접근 방식으로 인식하게 할 수 있다.
일반적으로 모놀리식 방식을 사용하면 개발 팀은 필요한 용량보다 초과 구매를 하게 된다. 이때 용량 증가는 큰 단위로 급증하지만 부드럽고 안정적으로 진행되는 경우는 드물다. 예를 들어 휴일 전 전자 상거래 사이트에서 증가하는 요청 수를 생각해 보자. 마이크로서비스를 사용하면 필요에 따라 새로운 서비스 인스턴스를 확장할 수 있다. 서비스 디스커버리(service discovery)를 사용하면 이러한 배포를 추상화하는 데 도움이 되며 서비스 소비자가 배포에 영향을 받지 않게 해 준다.
둘째, 서비스 디스커버리의 또 다른 장점은 애플리케이션 회복성을 향상시킨다는 것이다. 마이크로서비스 인스턴스가 비정상이거나 가용하지 못한 상태가 되면 대부분의 서비스 디스커버리 엔진은 그 인스턴스를 가용 서비스 목록에서 제거한다. 서비스 디스커버리 엔진은 사용이 불가한 서비스를 우회해서 라우팅하기 때문에 다운된 서비스로 입은 피해를 최소화한다.
이러한 이야기들이 다소 복잡하게 들려 서비스 디스커버리를 사용하는 데 DNS(Domain Name Service)나 로컬 로드 밸런서 같은 더 쉽고 검증된 방법을 사용하지 않는 이유를 궁금해 할지 모른다. 그럼 이 방법이 마이크로서비스 기반 애플리케이션, 특히 클라우드에서 실행되는 애플리케이션에 적합하지 않은 이유를 살펴보자. 그런 다음 우리 아키텍처에서 유레카 디스커버리(Eureka Discovery)를 구현하는 방법을 배워 보도록 하자.