'MSA'에 해당되는 글 30건

  1. 2017/02/20 용비 4. Service Discovery in a Microservices Architecture - 06 Summary
  2. 2017/02/20 용비 4. Service Discovery in a Microservices Architecture - 05 Service Registration Options
  3. 2017/02/15 용비 4. Service Discovery in a Microservices Architecture - 04 The Service Registry
  4. 2017/02/14 용비 4. Service Discovery in a Microservices Architecture - 03 The Server-Side Discovery Pattern
  5. 2017/02/14 용비 4. Service Discovery in a Microservices Architecture - 02 The Client-Side Discovery Pattern

4. Service Discovery in a Microservices Architecture - 06 Summary

Nginx/01. MicroServiceArchitecture 2017/02/20 16:45 용비
Summary
(요약)

마이크로서비스 어플리케이션에서 실행중인 서비스 인스턴스의 집합은 동적으로 변경된다. 인스턴스는 자동으로 네트워크 상의 위치를 할당받는다. 결과적으로 클라이언트에서 서비스로 요청을 보내기 위해서는, 서비스 검색 메커니즘을 사용해야만 한다.

서비스 검색의 핵심 부분은 서비스 레지스트리이다. 서비스 레지스트리는 이용 가능한 서비스 인스턴스에 대한 데이터베이스이다. 서비스 레지스트리는 Management API와 Query API를 제공한다. 서비스 인스턴스는 Management API를 통해서 서비스 레지스트리에 등록되거나, 등록이 취소된다. Query API는 이용 가능한 서비스 인스턴스를 검색하고자 하는 시스템 구성 요소에 의해 사용된다.

클라이언트 측면의 검색과 서버 측면의 검색, 2가지 주요 서비스 검색 패턴이 있다. 클라이언트 측면의 서비스 검색을 사용하는 시스템에서는 클라이언트가 서비스 레지스트리에 질의하고, 이용 가능한 인스턴스를 선택하고, 요청을 한다. 서버 측면의 검색을 사용하는 시스템에서는 클라이언트는 router를 통해서 요청을 하고, router가 서비스 레지스트리에 질의하고, 이용 가능한 인스턴스에 요청을 전달한다.

서비스 인스턴스를 서비스 레지스트리에 등록 및 등록 취소하는 2가지 주요 방법이 있다. 한가지 옵션은 서비스 인스턴스가 자체 등록 패턴(self-registration pattern)을 사용하여 서비스 레지스트리에 자신을 등록하는 것이다. 다른 옵션은 다른 시스템 컴포넌트가 서비스 대신 3rd-party 등록 패턴(third-party registration pattern)을 사용하여 다른 서비스를 통해 등록 및 등록 취소를 하는 것이다.

일부 배포 환경에서는, Netflix Eureka나 etcd, Apache Zookeeper와 같은 서비스 레지스트리를 사용하여 자체 서비스 검색 인프라를 구축할 필요가 있다. 다른 배포 환경에서는, 서비스 검색은 내장되어 있다. 예를 들면, Kubernetes와 Marathon에서는 서비스 인스턴스의 등록 및 등록 취소를 처리한다. 또한, 서버 측면의 검색 router 역할을 하는 각 Cluster 호스트에서 Proxy를 실행한다.

NGINX와 같은 HTTP Reverse Proxy와 Load Balancer는 서버 측면의 검색 Load Balancer로 사용될 수도 있다. 서비스 레지스트리는 NGINX에 라우팅 정보를 Push하고, 적절한 구성을 업데이트하도록 호출할 수 있다. 예를 들어, Consul Template를 사용할 수 있다. NGINX Plus는 추가적인 동적 재설정 메커니즘을 지원한다. - DNS를 사용하여 레지스트리에서 서비스 인스턴스에 대한 정보를 가져올 수 있고, 원격 재설정을 위한 API를 제공한다.

앞으로의 블로그 포스트에서는 마이크로서비스의 다른 측면에 대해서 계속해서 깊게 다룰 것이다. 이 시리즈의 향후 Article 릴리즈에 대한 소식을 받기 원한다면, (아래 양식의) NGINX 메일링 리스트에 등록하라.
TAG , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/771

4. Service Discovery in a Microservices Architecture - 05 Service Registration Options

Nginx/01. MicroServiceArchitecture 2017/02/20 16:08 용비
Service Registration Options
(서비스 등록 옵션들)

앞서 언급했듯이, 서비스 인스턴스는 서비스 레지스트리를 통해서 등록되고, 등록 취소 되어야 한다. 등록 및 취소를 다루는 몇가지 다른 방법이 있다. 한가지 옵션은 서비스 인스턴스가 자체 등록 패턴으로 등록하는 것이다. 다른 옵션은 서비스 인스턴스의 등록을 3rd-party 등록 패턴으로, 다른 서비스 컴포넌트에서 다루는 것이다. 먼저 자체 등록 패턴에 대해서 살펴보자.

The Self-Registration Pattern
(자체 등록 패턴)

자체 등록 패턴을 사용하는 경우, 서비스 인스턴스는 직접 서비스 레지스트리에 등록하고 등록을 취소한다. 또한 만약 필요하다면, 서비스 인스턴스는 등록이 만료되지 않도록 heartbeat 요청을 보낸다. 다음 다이어그램은 이 패턴의 구조를 보여준다.

사용자 삽입 이미지

이러한 접근법의 좋은 예제는 Netflix OSS Eureka 클라이언트이다. Eureka 클라이언트는 서비스 인스턴스의 등록 및 등록 취소에 대한 모든 측면을 다룬다. 서비스 검색을 포함하여 다양한 패턴을 구현한 Spring Cloud 프로젝트에서는 Eureka로 서비스 인스턴스를 쉽게 자동으로 등록하게 한다. Java Configuration Class에서 @EnableEurekaClient Annotation만으로 간단히 사용할 수 있다.

자체 등록 패턴은 다양한 이점과 단점이 있다. 한가지 이점은 상대적으로 간단하고 다른 시스템 요소가 필요없다는 것이다. 그러나, 큰 단점은 서비스 레지스트리와 서비스 인스턴스가 묶여 있다는 것이다. (상호 의존 관계임) 서비스에서 사용하고 있는 프로그래밍 언어와 프레임워크마다 등록 코드를 구현해 주어야 한다.

서비스에서 서비스 레지스트리를 분리하도록 대체하는 접근법은 3rd-party 등록 패턴이다.

The Third-Party Registration Pattern
(3rd-Party 등록 패턴 : 제 3자 등록 패턴)

3rd-Party 등록 패턴을 사용할 때, 서비스 인스턴스는 서비스 레지스트리에 스스로를 등록할 책임이 없다. 대신에 서비스 레지스트라로 알려진 또다른 서비스 컴포넌트가 등록을 처리한다. 서비스 레지스트라는 배포환경을 polling하거나 이벤트에 등록하여 실행중인 인스턴스 집합에 대한 변경을 추적한다. 서비스 레지스트라는 새로 이용 가능한 서비스 인스턴스를 알게 되면, 인스턴스를 서비스 레지스트리에 등록한다. 또한 서비스 레지스트라는 서비스 인스턴스가 종료되었을 때, 등록을 취소한다. 다음 다이어그램은 이 패턴의 구조를 보여준다.

사용자 삽입 이미지

서비스 레지스트라의 한가지 예제는 Open Source Registrator 프로젝트가 있다. Open Source Registrator 프로젝트는 Docker 컨테이너로 배포된 서비스 인스턴스들을 자동으로 등록하고, 등록을 취소한다. Registrator는 etcd와 Consul을 포함하여 다양한 서비스 레지스트리를 지원한다.

서비스 레지스트라의 또다른 예제는 NetflixOSS Prana를 들 수 있다. 주로 Non-JVM 언어로 작성된 서비스를 대상으로 하는, 서비스 인스턴스와 함께 실행되는 사이드카 어플리케이션이다. (Sidecar Application : 주로 사용하는 메인 기능 이외 부가적으로 사용하여 메인 기능을 향상시키는 어플리케이션) Prana는 Netflix Eureka를 사용하여 서비스 인스턴스를 등록하고, 등록을 취소한다.

서비스 레지스트라는 배포 환경에 내장된 구성 요소이다. Autoscaling Group에 의해 생성된 EC2 인스턴스는 ELB(Elastic Load Balancer)에 자동으로 등록될 수 있다. Kubernetes 서비스는 자동으로 등록되어 검색에 사용할 수 있다.

3rd-Party 등록 패턴은 다양한 이점과 단점을 가지고 있다. 주요 이점은 서비스가 서비스 레지스트리와 분리되어 있다는 것이다. 개발자들이 사용한 프로그래밍 언어와 프레임워크 마다 서비스 등록 로직을 구현할 필요가 없다. 대신에, 서비스 인스턴스 등록은 전용 서비스에서 중앙집중식으로 이루어진다.

이 패턴의 한가지 단점은 배포 환경에 내장되어 있지 않으면, 설치 및 관리할 필요가 있는 또다른 고가용 시스템 컴포넌트라는 것이다.


TAG , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/770

4. Service Discovery in a Microservices Architecture - 04 The Service Registry

Nginx/01. MicroServiceArchitecture 2017/02/15 16:38 용비
The Service Registry
(서비스 레지스트리)

서비스 레지스트리는 서비스 검색의 핵심적인 부분이다. 서비스 레지스트리는 서비스 인스턴스의 네트워크 상 위치를 포함하고 있는 데이터베이스이다. 서비스 레지스트리는 고가용성이어야 하고, 최신 상태가 되어 있어야 한다. 클라이언트는 서비스 레지스트리를 통해서 얻은 네트워크 위치를 캐시할 수 있다. 그러나 캐시한 정보는 점차적으로 오래된 데이터가 되고, 클라이언트는 서비스 인스턴스를 검색할 수 없게 된다. 결과적으로, 서비스 레지스트리는 일관성을 유지하기 위해서 복제 프로토콜을 사용하는 서버 클러스터로 이루어진다.

앞에서 언급했듯이, Netflix Eureka는 서비스 레지스트리의 좋은 예이다. 서비스 인스턴스를 등록하고 질의하기 위한 REST API를 제공한다. 서비스 인스턴스는 POST 요청을 사용하여 네트워크 상의 위치를 등록한다. 매 30초마다 PUT 요청을 사용하여 등록 정보를 새로 고쳐야 한다. 등록 정보는 HTTP DELETE 요청을 사용하여 삭제되거나, 등록 시간 초과에 의해 제거된다. 예상한 것처럼, 클라이언트는 HTTP GET 요청을 통해서 등록된 서비스 인스턴스를 조회할 수 있다.

Netflix는 각 Amazon EC2 가용성 존에서 하나 이상의 Eureka서버를 실행하여 고가용성을 실현한다. 각 Eureka 서버는 탄력적인 IP 주소를 갖는 EC2 인스턴스에서 실행된다. DNS TEXT 레코드는 Eureka Cluster 설정을 저장하는데 사용되고, Eureka Cluster 설정은 가용성 존에서부터 Eureka 서버의 네트워크 상 위치 목록까지의 맵이다. Eureka 서버가 시작되면, Eureka Cluster 설정을 얻기 위해서 DNS에 질의하고, 피어의 위치를 찾은 후 사용되지 않은 Elastic IP 주소를 할당한다.

Eureka 클라이언트 - 서비스와 서비스 클라이언트 - 는 Eureka 서버의 네트워크상 위치를 찾기 위해서 DNS에 질의한다. 클라이언트는 동일한 가용성 존에 있는 Eureka 서버를 사용하는 것을 선호한다. 그러나 아무것도 사용할 수 없는 경우에는 또다른 가용성 존에 있는 Eureka 서버를 사용한다.

서비스 레지스트리의 다른 예는 다음과 같다.

  - etcd : 설정의 공유 및 서비스 검색에 사용되는 고 가용적이고 분산되어 있는 일관성 있는 key-value 저장소이다. etcd를 사용하고 있는 주목할만한 2가지 프로젝트는 Kubernetes와 Cloud Foundry이다.
  - consul : 서비스 검색과 설정에 사용하는 도구. 클라이언트가 서비스를 등록하고 검색할 수 있도록 API를 제공한다. consul은 서비스 가용성을 확인하기 위하여 health check를 수행할 수 있다.
  - Apache Zookeeper : 분산 어플리케이션에서 폭넓게 사용되는 고 성능의 coordination 서비스. Apache Zookeeper는 원래 Hadoop의 하위 프로젝트였으나, 지금은 Top-Level 프로젝트이다.

또한, 이전에 언급했듯이, Kubernetes와 Marathon, AWS와 같은 몇몇 시스템에는 명시적인 서비스 레지스트리를 가지고 있지는 않다. 대신에 서비스 레지스트리를 인프라의 일부분으로 내장하고 있다.

지금까지 서비스 레지스트리의 개념에 대해 살펴보았다. 이제 서비스 인스턴스가 서비스 레지스트리에 어떻게 등록되는지를 살펴 보자.
TAG , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/768

4. Service Discovery in a Microservices Architecture - 03 The Server-Side Discovery Pattern

Nginx/01. MicroServiceArchitecture 2017/02/14 15:27 용비
The Server-Side Discovery Pattern
(서버 측면의 검색 패턴)

서비스를 검색하는 또다른 접근법은 서버 측면의 검색 패턴이다. 다음 다이어그램은 이 패턴의 구조를 보여준다.

사용자 삽입 이미지

클라이언트는 로드 밸런서를 통해 서비스에 요청을 보낸다. 로드 밸런서는 서비스 레지스트리에 질의하고, 이용 가능한 서비스 인스턴스로 각 요청을 라우팅한다. 클라이언트 측면의 검색처럼 서비스 인스턴스들은 서비스 레지스트리에 등록하거나 등록을 취소한다.

AWS(아마존 웹 서비스)의 Elastic Load Balancer(ELB)는 서버 측면의 검색 라우터에 대한 예제이다. ELB는 일반적으로 인터넷의 외부 트래픽 부하를 분산하는데 사용된다. 그러나, 가상 사설 클라우드(VPC) 내부의 트래픽 부하를 분산하는데 ELB를 사용할 수도 있다. 클라이언트는 DNS Name을 사용하여 ELB를 통해 요청(HTTP나 TCP) 한다. ELB는 등록된 Elastic Compute Cloud(EC2) 인스턴스나 EC2 Container Service(ECS) 컨테이너 모음 사이에서 트래픽 부하를 분산시킨다. 별도의 서비스 레지스트리는 없다. 대신, EC2 인스턴스와 ECS 컨테이너들은 ELB 자체에 등록되어 있다.

NGINX Plus와 NGINX와 같은 HTTP 서버와 로드 밸런서들은 서버 측면의 검색 로드 밸런서로 사용될 수도 있다. 예를 들면, 이 블로그 포스트는 Consul Template를 사용하여 NGINX의 Reverse Proxying를 동적으로 재설정하는 부분에 대해 설명하고 있다. Consul Template는 Consul 서비스 레지스트리에 저장되어 있는 설정 데이터를 이용하여 임의의 설정 파일들을 주기적으로 재생성하는 도구이다. 설정 파일들이 변경될 때마다 임의의 쉘 명령어를 실행한다. 블로그 포스트에서 설명된 예제에서 Consul Template는 Reverse Proxying을 설정하는 nginx.conf 파일을 생성한다. 그런 후, NGINX가 설정을 다시 로드하도록 명령어를 실행한다. 보다 더 정교한 구현은 HTTP API나 DNS를 사용하여 NGINX Plus를 동적으로 재구성할 수 있다.

Kubernetes와 Marathon과 같은 일부 배포 환경에서는 클러스터 내의 각 호스트에서 Proxy를 실행한다. Proxy는 서버 측면의 검색 로드 밸런서 역할을 수행한다. 서비스에 요청하기 위하여, 클라이언트는 호스트의 IP 주소와 서비스에 할당된 포트(port)를 사용하여 Proxy를 통해 요청을 라우팅한다. 그런 다음, Proxy는 클러스터 내 어딘가에서 실행 중인 사용 가능한 서비스 인스턴스에 요청을 투명하게 전달한다.

서버 측면의 검색 패턴은 여러 가지 장단점을 가지고 있다. 이 패턴의 한가지 커다른 장점은 검색의 세부사항이 클라이언트로부터 추상화되어 있다는 것이다. 클라이언트는 단순하게 로드 밸런서에게 요청한다. 서비스 클라이언트에서 사용한 프로그래밍 언어와 프레임워크에 대한 검색 로직을 구현할 필요가 없다. 또한, 위에서 언급한 것처럼, 어떤 배포 환경에서는 이 기능을 무료로 제공한다. 그러나 이 패턴은 몇 가지 단점이 있다. 로드 밸런서가 배포 환경에 의해 제공되지 않는 한, 로드 밸런서는 설치하고 관리해야만 하는 또다른 고가용성 시스템 구성 요소이다.
TAG , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/767

4. Service Discovery in a Microservices Architecture - 02 The Client-Side Discovery Pattern

Nginx/01. MicroServiceArchitecture 2017/02/14 14:53 용비
The Client-Side Discovery Pattern
(클라이언트 측면의 검색 패턴)

클라이언트 측 검색을 사용할 때, 클라이언트는  사용 가능한 서비스 인스턴스의 네트워크 위치를 결정하고, 인스턴스들 사이의 요청에 대한 부하 분산을 담당한다. 클라이언트는 이용 가능한 서비스 인스턴스들의 데이터베이스인 서비스 레지스트리(서비스 등록소)를 조회한다. 그런 다음 클라이언트는 이용 가능한 서비스 인스턴스 중에 로드밸런싱 알고리즘을 사용하여 하나를 선택하고, 요청한다.

다음 다이어그램은 이 패턴의 구조를 보여준다.

사용자 삽입 이미지

서비스 인스턴스의 네트워크 상 위치는 서비스가 시작될 때, 서비스 레지스트리에 등록되고, 서비스 인스턴스가 종료될 때, 서비스 레지스트리에서 삭제된다. 일반적으로 서비스 인스턴스의 등록은 Heart-Beat 메커니즘을 사용하여 주기적으로 갱신된다.

Netflix OSS는 클라이언트 측면에서의 검색 패턴의 좋은 예제이다. Netflix Eureka는 서비스 레지스트리이다. 서비스 인스턴스 등록을 관리하고 이용 가능한 서비스 인스턴스를 조회할 수 있도록 REST API를 제공한다.  Netflix Ribbon은 이용 가능한 서비스 인스턴스들 사이에 요청을 분산하기 위해 Eureka와 함께 사용하는 IPC 클라이언트이다. 이 기사(article)의 뒷부분에 Eureka에 대해서 더 깊이 다룰 것이다.

클라이언트 측면의 검색 패턴은 다양한 장점과 단점이 있다. 이 패턴은 상대적으로 간단하고, 서비스 등록을 제외하면 다른 움직이는 부분은 없다. 또한 클라이언트는 이용 가능한 서비스 인스턴스에 대해 알고 있기 때문에, 일관되게 해싱을 사용하는 것처럼 지능적이고 어플리케이션에 특화된 부하분산 결정을 할 수 있다. 이 패턴의 한가지 중요한 단점은 클라이언트가 서비스 레지스트리와 결합되어 있다는 것이다. 서비스 클라이언트에서 사용하는 각 프로그래밍 언어와 프레임워크에 대해 클라이언트 측면의 서비스 검색 로직을 구현해야만 한다.

지금까지 클라이언트 측면의 검색에 대해서 살펴보았다. 이제 서버 측면의 검색에 대해서 살펴보자.
TAG , ,
받은 트랙백이 없고, 댓글이 없습니다.

댓글+트랙백 RSS :: http://www.yongbi.net/rss/response/766

◀ 이전페이지 1 2 3 4 5 6 다음페이지 ▶