스프링

마이크로서비스 코딩

공작소

2019.05.16

Chapter 4. 서비스 디스커버리

서비스 디스커버리

분산 아키텍처에서 시스템의 물리적 위치 주소를 찾는 것

서비스 디스커버리의 중요성

 

  1. 서비스 인스턴스 개수를 신속하게 수평 확장하거나 축소할 수 있다
     
  2. 애플리케이션 회복성을 향상하는 데 도움이 된다

4.1 서비스 위치 찾기

DNS와 로드밸런서를 사용하는 전통적 서비스 위치 확인 모델의 한계

단일 장애 지점: 로드 밸런서가 고가용성을 지원한다고 해도 전체 인프라스트럭처의 단일 장애 지점이고, 집중화된 병목 지점이 될 가능성이 높음

수평 확장의 제약성: 로드 밸런서 클러스터에  서비스를 모아 연결하므로 부하 분산 인프라스트럭처를 여러 서버에 수평적으로 확장할 수 있는 능력 제한, 상용 로드 밸런서 다수는 중복성 모델라이선싱 비용 두 가지 요소에 제약을 받음

정적 관리: 전통적 로드 밸런서 대부분은 서비스를 신속히 등록하고 취소하기 어려움,  중앙 집중식 데이터베이스를 사용해 경로 규칙을 저장

복잡성: 로드 밸런서가 서비스에 대한 프록시 역할을 하므로 물리적인 서비스에 매핑된 요청 정보가 있어야함, 매핑 규칙을 수동으로 정의하고 배포해야 하므로 서비스 인프라스트럭처의 복잡성 가중

4.1 서비스 위치 찾기

로드 밸런서 특징

  1. 중앙 집중화된 네트워크 인프라스트럭처를 이용해 처리할 수 있는 크기와 규모가 있는 기업 환경
  2. SSL 종료를 한 곳에서 처리하고 서비스의 포트 보안을 관리하는 면에서 중요한 역할
  3. 자기 후방의 모든 서버에 대한 인바운드 및 아웃바운드 포트 접근 제어 가능
  4. PCI(Payment Card Industry) 법규 준수처럼 산업 표준의 인증 요구 사항을 충족하려고 할 때, 최소 네트워크 접근 개념은 중요한 구성 요소
  5. 대용량의 트랜잭션과 증복성을 처리해야 하는 클라우드에서 중앙 집중식 네트워크 인프라스트럭처는 부적합

4.2 클라우드에서 서비스 디스커버리

  • 고가용성: 서비스 검색 정보를 서비스 디스커버리 클러스터의 여러 노드가 공유하는 핫 클러스터링 환경을 지원해야 한다.
  • 피어 투 피어: 서비스 디스커버리 클러스터의각 노드는 서비스 인스턴스의 상태를 공유한다.
  • 부하 분산: 서비스 디스커버리는 요청을 동적으로 부하 분산해서 관리하는 모든 서비스 인스턴스에 분배해야 한다. 정적이고 수동으로 관리되는 로드 밸런서를 대체
  • 회복성: 서비스 디스커버리 클라이언트는 서비스 정보를 로컬에 캐시해야 한다. 서비스 디스커버리 서비스가 가용하지 않을 때 로컬 캐시에 저장된 정보를 기반으로 서비스를 찾고 동작하게 한다.
  • 장애 내성: 서비스 디스커버리는 서비스 인스턴스의 비정상을 탐지하고 가용 서비스 목록에서 인스턴스를 제거한다. 서비스 장애를 감지하고 사람의 개입 없이 조치를 취해야 한다

4.2.1 서비스 디스커버리 아키텍처

클라이언트 측 부하 분산

  1. 서비스 소비자가 요청한 모든 서비스 인스턴스를 위해 서비스 디스커버리 서비스에 접속한 후 데이터를 서비스 소비자 기기에 로컬 캐시한다.
  2. 서비스 소비자는 캐시에서 위치정보를 검색, 클라이언트 측 캐싱은 라운드로빈 부하 분산 알고리즘처럼 단순한 알고리즘을 사용해 서비스 호출을 여러 인스턴스로 분산
  3. 서비스 호출이 실패하면 로컬에 있는 서비스 디스커버리 캐시가 무효화되고 서비스 디스커버리 클라이언트는 서비스 디스커버리 에이전트에 목록 새로고침을 시도

4.4.2 스프링과 넷플릭스 유레카를 사용한 서비스 디스커버리

  1. 서비스 부트스트래핑 시점에 라이선싱 및 조직 서비스는 자신을 유레카 서비스에 등록한다. 서비스 ID, 각 서비스 인스턴스의 물리적 위치, 포트번호를 유레카에 알려 준다.
  2. 라이선싱 서비스가 조직 서비스를 호출할 때 넷플릭스 리본 라이브러리를 사용해 클라이언트 측 부하 분산 기능을 수행한다. 리본 라이브러리는 유레카 서비스에서 서비스의 위치 정보를 조회하고 로컬에 캐싱한다.
  3. 주기적으로 넷플릭스 리본 라이브러리는 유레카 서비스를 핑해서 로컬 캐시의 서비스 위치를 새로고침 한다.

4.6 요약

  • 서비스 디스커버리 패턴은 서비스의 물리적 위치를 추상화하는 데 사용
  • 유레카 같은 서비스 디스커버리 엔진은 서비스 클라이언트에 영향을 주지 않고 해당 환경의 서비스 인스턴스를 원활하게 추가, 삭제 가능
  • 클라이언트 측 부하 분산을 사용하면 서비스를 호출하는 클라이언트에서 서비스의 물리적 위치를 캐싱해 더 나은 성능과 회복성을 제공
  • 유레카는 스프링 클라우드와 사용하면 쉽게 구축하고 구성할 수 있다
  • 스프링 클라우드와 넷플릭스유레카, 그리고 서비스를 호출하는 넷플릭스 리본으로 세 가지 메커니즘을 사용
    - 스프링 클라우드와 DiscoveryClient
    - 스프링 클라우드와 리본 지원 RestTemplate
    - 스프링 클라우드와 넷플릭스 Feign 클라이언트

서비스 디스커버리

By Sungbin, Song

서비스 디스커버리

  • 108