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

4. Service Discovery in a Microservices Architecture - 01 Why Use Service Discovery?

Nginx/01. MicroServiceArchitecture 2017/02/13 20:19 용비
이것은 Microservice를 사용하여 어플리케이션을 작성하는 것에 대한 시리즈 중에서 4번째 article이다. 첫번째 article에서는 Microservice Architecture 패턴을 소개하고, microservice를 사용할 때의 이점과 단점에 대해서 논의했다. 시리즈 중에서 두번째와 세번째 article에서는 microservice architecture에서 통신의 다양한 측면에 관하여 설명했다. 이번 article에서는, 서비스 검색과 밀접하게 연관된 문제에 대해서 탐험할 것이다.

Why Use Service Discovery?
(왜 서비스 검색을 사용하는가?)

REST API나 Thrift API를 가진 서비스를 호출하는 어떤 코드를 작성한다고 상상해 보자. 요청을 하기 위해서는, 서비스 인스턴스의 네트워크 상의 위치(IP 주소와 port)를 알아야 한다. 물리적인 하드웨어에서 실행되는 전통적인 어플리케이션에서는, 서비스 인스턴스의 네트워크상 위치는 상대적으로 정적이다. 예를 들면, 때때로 업데이트되는 설정 파일에서 네트워크 위치를 읽을 수 있다.

하지만, 현대의 클라우드 기반 microservice 어플리케이션에서는 다음 다이어그램에서 보여지는 것처럼 해결할 훨씬 더 어려운 문제가 있다.

사용자 삽입 이미지

서비스 인스턴스에는 네트워크 위치가 동적으로 할당된다. 더우기, 서비스 인스턴스의 모음은 auto-scaling, 장애, 업그레이드 때문에 동적으로 변경된다. 따라서, 클라이언트 코드에는 더 정교한 서비스 검색 메커니즘이 사용되어야 한다.

서비스 검색 패턴에는 클라이언트 측면의 검색과 서버 측면의 검색, 2가지 유형이 있다. 먼저 클라이언트 측면의 검색을 살펴보자.



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

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

3. Building Microservices: IPC - 07 Summary

Nginx/01. MicroServiceArchitecture 2017/02/11 12:09 용비
Summary
(요약)

Microservice는 프로세스간 통신 메커니즘을 사용해야만 한다. 서비스가 어떻게 통신할 것인지 설계할 때, 서비스들이 어떻게 상호작용하는지, 각 서비스의 API는 어떻게 정의할 것인지, API를 어떻게 진화시킬 것인지, 부분적인 오류는 어떻게 처리할 것인지에 대한 다양한 이슈를 고려해야만 한다. Microservice가 사용할 수 있는 2가지 종류의 IPC 메커니즘이 있다. 비동기식 메시지, 동기식 Request/Response 메커니즘이 그것이다. 이 시리즈의 다음 article에서는 microservice architecture에서 서비스 검색에 대한 문제를 살펴볼 것이다.
TAG ,
받은 트랙백이 없고, 댓글이 없습니다.

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

◀ 이전페이지 1 ... 39 40 41 42 43 44 45 46 47 ... 216 다음페이지 ▶