스프링
마이크로서비스 코딩
공작소
2019.05.16
Chapter 4. 서비스 디스커버리
서비스 디스커버리
분산 아키텍처에서 시스템의 물리적 위치 주소를 찾는 것
서비스 디스커버리의 중요성
- 서비스 인스턴스 개수를 신속하게 수평 확장하거나 축소할 수 있다
- 애플리케이션 회복성을 향상하는 데 도움이 된다
4.1 서비스 위치 찾기
DNS와 로드밸런서를 사용하는 전통적 서비스 위치 확인 모델의 한계
단일 장애 지점: 로드 밸런서가 고가용성을 지원한다고 해도 전체 인프라스트럭처의 단일 장애 지점이고, 집중화된 병목 지점이 될 가능성이 높음
수평 확장의 제약성: 로드 밸런서 클러스터에 서비스를 모아 연결하므로 부하 분산 인프라스트럭처를 여러 서버에 수평적으로 확장할 수 있는 능력 제한, 상용 로드 밸런서 다수는 중복성 모델과 라이선싱 비용 두 가지 요소에 제약을 받음
정적 관리: 전통적 로드 밸런서 대부분은 서비스를 신속히 등록하고 취소하기 어려움, 중앙 집중식 데이터베이스를 사용해 경로 규칙을 저장
복잡성: 로드 밸런서가 서비스에 대한 프록시 역할을 하므로 물리적인 서비스에 매핑된 요청 정보가 있어야함, 매핑 규칙을 수동으로 정의하고 배포해야 하므로 서비스 인프라스트럭처의 복잡성 가중
4.1 서비스 위치 찾기
로드 밸런서 특징
- 중앙 집중화된 네트워크 인프라스트럭처를 이용해 처리할 수 있는 크기와 규모가 있는 기업 환경
- SSL 종료를 한 곳에서 처리하고 서비스의 포트 보안을 관리하는 면에서 중요한 역할
- 자기 후방의 모든 서버에 대한 인바운드 및 아웃바운드 포트 접근 제어 가능
- PCI(Payment Card Industry) 법규 준수처럼 산업 표준의 인증 요구 사항을 충족하려고 할 때, 최소 네트워크 접근 개념은 중요한 구성 요소
- 대용량의 트랜잭션과 증복성을 처리해야 하는 클라우드에서 중앙 집중식 네트워크 인프라스트럭처는 부적합
4.2 클라우드에서 서비스 디스커버리
- 고가용성: 서비스 검색 정보를 서비스 디스커버리 클러스터의 여러 노드가 공유하는 핫 클러스터링 환경을 지원해야 한다.
- 피어 투 피어: 서비스 디스커버리 클러스터의각 노드는 서비스 인스턴스의 상태를 공유한다.
- 부하 분산: 서비스 디스커버리는 요청을 동적으로 부하 분산해서 관리하는 모든 서비스 인스턴스에 분배해야 한다. 정적이고 수동으로 관리되는 로드 밸런서를 대체
- 회복성: 서비스 디스커버리 클라이언트는 서비스 정보를 로컬에 캐시해야 한다. 서비스 디스커버리 서비스가 가용하지 않을 때 로컬 캐시에 저장된 정보를 기반으로 서비스를 찾고 동작하게 한다.
- 장애 내성: 서비스 디스커버리는 서비스 인스턴스의 비정상을 탐지하고 가용 서비스 목록에서 인스턴스를 제거한다. 서비스 장애를 감지하고 사람의 개입 없이 조치를 취해야 한다
4.2.1 서비스 디스커버리 아키텍처
클라이언트 측 부하 분산
- 서비스 소비자가 요청한 모든 서비스 인스턴스를 위해 서비스 디스커버리 서비스에 접속한 후 데이터를 서비스 소비자 기기에 로컬 캐시한다.
- 서비스 소비자는 캐시에서 위치정보를 검색, 클라이언트 측 캐싱은 라운드로빈 부하 분산 알고리즘처럼 단순한 알고리즘을 사용해 서비스 호출을 여러 인스턴스로 분산
- 서비스 호출이 실패하면 로컬에 있는 서비스 디스커버리 캐시가 무효화되고 서비스 디스커버리 클라이언트는 서비스 디스커버리 에이전트에 목록 새로고침을 시도
4.4.2 스프링과 넷플릭스 유레카를 사용한 서비스 디스커버리
- 서비스 부트스트래핑 시점에 라이선싱 및 조직 서비스는 자신을 유레카 서비스에 등록한다. 서비스 ID, 각 서비스 인스턴스의 물리적 위치, 포트번호를 유레카에 알려 준다.
- 라이선싱 서비스가 조직 서비스를 호출할 때 넷플릭스 리본 라이브러리를 사용해 클라이언트 측 부하 분산 기능을 수행한다. 리본 라이브러리는 유레카 서비스에서 서비스의 위치 정보를 조회하고 로컬에 캐싱한다.
- 주기적으로 넷플릭스 리본 라이브러리는 유레카 서비스를 핑해서 로컬 캐시의 서비스 위치를 새로고침 한다.
4.6 요약
- 서비스 디스커버리 패턴은 서비스의 물리적 위치를 추상화하는 데 사용
- 유레카 같은 서비스 디스커버리 엔진은 서비스 클라이언트에 영향을 주지 않고 해당 환경의 서비스 인스턴스를 원활하게 추가, 삭제 가능
- 클라이언트 측 부하 분산을 사용하면 서비스를 호출하는 클라이언트에서 서비스의 물리적 위치를 캐싱해 더 나은 성능과 회복성을 제공
- 유레카는 스프링 클라우드와 사용하면 쉽게 구축하고 구성할 수 있다
- 스프링 클라우드와 넷플릭스유레카, 그리고 서비스를 호출하는 넷플릭스 리본으로 세 가지 메커니즘을 사용
- 스프링 클라우드와 DiscoveryClient
- 스프링 클라우드와 리본 지원 RestTemplate
- 스프링 클라우드와 넷플릭스 Feign 클라이언트
서비스 디스커버리
By Sungbin, Song
서비스 디스커버리
- 108