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는 클러스터 내 어딘가에서 실행 중인 사용 가능한 서비스 인스턴스에 요청을 투명하게 전달한다.

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

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

트랙백 주소 :: http://www.yongbi.net/trackback/767

트랙백 RSS :: http://www.yongbi.net/rss/trackback/767

댓글을 달아 주세요

댓글 RSS 주소 : http://www.yongbi.net/rss/comment/767
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다