Service-Discovery

in Dev-Study on Spring


공부하는 내용을 정리하는 목적으로 작성하고 있습니다. 잘못 작성된 내용을 지적해주시면 좀더깊이 공부해서 내용을 수정하겠습니다.

서비스 디스커버리

Service discovery : 분산 아키텍처에서 시스템의 물리적 위치 주소를 찾는 과정 Service-Discovery가 Microservice-Architecture, Cloud Service에서 중요한 이유

  1. 서비스 디스커버리를 이용해 해당 환경에서 실행하는 서비스 인스턴스 개수를 신속하게 수평 확장하거나 축소 가능
    • 모놀리식의 경우 하드웨어를 추가하는 수직확장을 할 수 있는데, 수직확장의 단점은 Max를 알기힘드므로 필요한 자원보다 초과 구매를 하게 된다.
    • 마이크로서비스의 경우 필요한 인스턴스를 확장하거나 축소시키면 되므로 자원 낭비가 최소화된다.
  2. 애플리케이션의 회복성 향상 가능
    • 마이크로서비스 인스턴스가 비정상이거나 가용할 수 없는 수준이면 서비스 디스커버리 엔진은 사용할 수 없는 서비스로 인지하고 해당 인스턴스를 피해 라우팅하므로, 문제가 발생한 서비스로 인해 자원이 고갈되어 전체 시스템의 성능이 저하되는 문제를 피할 수 있다.

로드밸런서를 사용하여 서비스 디스커버리 기능을 사용할 수도 있지만, 결국 트래픽이 증가하면 로드 밸런스에 부하가 집중되고, 로드밸런서가 중지되면 로드밸런서에 의존하는 모든 마이크로 서비스들은 더이상 서비스가 불가능해지는 문제가 있다.

대용량의 트랜잭션과 중복성을 처리해야하는 클라우드 환경에서 중앙접근식 네트워크 인프라스트럭처는 효율적으로 확장되지 않고 비용 효율도 낮아서 제대로 동작할 수 없다.

서비스 디스커버리의 기능

  1. Highly available(고가용성)
    • 서비스 검색정보를 서비스 디스커버리 클러스터의 모든 노드가 공유하는 Hot 클러스터링 환경을 지원한다.
    • 한 노드가 사용할 수 없는 상태가 되면 다른 노드가 대신 처리할 수 있어야 한다.
  2. Peer to-Peer
    • 서비스 디스커버리 클러스터의 각 노드는 서비스 인스턴스의 상태를 공유한다.
  3. Load balancing (부하분산)
    • 요청을 동적으로 부하분산시켜 서비스 디스커버리가 관리하는 모든 서비스 인스턴스에 분배해야 한다.

서비스 디스커버리 아키텍쳐

  1. 서비스 등록
    • 각 마이크로서비스를 어떻게 서비스 디스커버리 에이전트에 등록할 수 있는지?
  2. 클라이언트가 서비스 주소 검색
    • 클라이언트는 어떻게 마이크로서비스 정보를 검색할 수 있는지?
  3. 정보 공유
    • 서비스 디스커버리 클러스터의 각 노드들은 어떻게 마이크로 서비스 정보들을 공유하는지?
  4. 상태 모니터링
    • 각 마이크로서비스는 자신의 상태를 어떻게 서비스 디스커버리 에이전트로 전달할것인지?

마이크로서비스 인스턴스가 시작하면 자신의 물리적 위치/경로, 포트정보를 서비스 디스커버리 에이전트에 등록한다.

  • ServiceID: 동일한 마이크로서비스 인스턴스 그룹 ID

클라이언트 축 부하 분산

  1. 클라이언트가 로컬캐시에서 서비스 인스턴스 IP 주소를 확인하고 직접 접근한다.
    만약 클라이언트의 캐시에서 찾지못한다면 서비스 디스커버리에서 검색한다.
  2. 클라이언트 측 캐시는 주기적으로 서비스 디스커버리를 통해 업데이트 한다.

스프링 클라우드와 넷플리스 유레카 서비스 디스커버리 엔진을 통해 서비스 디스커버리 패턴을 구현할 수 있고 스프링 클라우드와 넷플릭스의 리본 라이브러리를 통해 클라이언트 측 부하 분산이 가능하다.

  1. 서비스 부트스트래핑 시점에 각 마이크로서비스는 자신을 유레카 서비스에 등록한다. 이때, ServiceID, Instance의 물리적 위치, Port번호를 전달한다.
  2. 마이크로서비스가 다른 마이크로서비스를 호출할 때 넷플릭스-리본 라이브러리가 사용하여 클리아인트 측 부하 분산 기능을 수행할 수 있다.
리본은 유레카 서비스에서 호출할 마이크로서비스의 위치 정보를 찾고 로컬에 캐싱한다.
  1. 주기적으로 리본은 유레카 서비스를 Ping해서 로컬 캐시에 저장한 마이크로 서비스의 위치 정보를 업데이트한다.

리본은 호출한 마이크로서비스의 인스턴스가 문제가 있는경우 해당 인스턴스는 로컬 캐시에서 삭제한다.

유레카 서비스에 마이크로서비스를 등록할때 ApplicationID와 InstanceID가 필요하다.
ApplicationID: 마이크로서비스 인스턴스 그룹ID ({spring.application.name})
InstanceID: 마이크로서비스의 각 인스턴스 ID

서비스 디스커버리를 사용한 서비스 검색

대표 라이브러리: 넷플릭스 FeignClient (리본과 상호작용함)

FeignClient
스프링 클라우드 프레임워크는 대상 REST 서비스를 호출하는데 사용되는 프록시 클래스를 동적으로 생성한다.

@FeignClient("{호출할 Service Application 아이디})

스프링 마이크로서비스 코딩공작소 (존 카넬) 도서 참조




© 2020.09.23 by chpark

Powered by chpark