서비스 디스커버리

서비스 디스커버리 (Service Discovery)

이 문서는 Hadoop에서의 서비스 디스커버리 메커니즘과 이를 활성화하는 단계를 설명합니다.

출처: 문서

본문

개요 (Overview)

표준 메커니즘인 DNS 조회를 통해 Hadoop에서 서비스를 발견할 수 있도록 DNS 서버가 구현되어 있습니다.

프레임워크 ApplicationMaster는 호스트네임과 IP 주소 같은 컨테이너 정보를 Hadoop 서비스 레지스트리에 게시합니다. DNS 서버는 Hadoop 서비스 레지스트리의 정보를 A 레코드, SRV 레코드 같은 DNS 레코드로 변환하여 노출합니다. 그러면 클라이언트는 표준 DNS 조회를 통해 컨테이너의 IP를 발견할 수 있습니다.

비-도커 컨테이너(Artifact가 null이거나 Artifact 유형이 TARBALL로 설정된 컨테이너)의 경우, 같은 호스트의 모든 컨테이너가 동일한 IP 주소를 공유하므로 DNS는 정방향(forward) DNS 조회는 지원하지만 역방향(reverse) DNS 조회는 지원하지 않습니다. docker를 사용하면 각 컨테이너가 고유한 IP를 가지도록 구성할 수 있으므로 정방향과 역방향 조회를 모두 지원합니다. 또한 DNS는 정방향/역방향 조회 모두에 대해 정적 zone 파일을 구성하는 것도 지원합니다.

클러스터에서의 Docker 컨테이너 IP 관리

컨테이너당 IP(per container per IP) 사용 사례를 지원하려면 컨테이너가 bridge 네트워크로 실행되어야 합니다. 그러나 bridge 네트워크를 사용하면 한 노드에서 실행되는 컨테이너는 기본적으로 다른 노드에서 라우팅할 수 없습니다. 단일 노드 테스트만 한다면 문제 없지만, 다중 노드 환경에서는 컨테이너를 다른 노드에서 라우팅 가능하게 만들어야 합니다.

이를 해결하는 방법은 GCE나 AWS 같은 플랫폼에 따라 여러 가지가 있습니다. 활성화 방법은 각 플랫폼 문서를 참조하세요. 온프레미스 클러스터의 경우, 한 가지 해결 방법은 각 노드에서 docker 데몬이 모든 노드에서 라우팅 가능한 커스텀 브리지(예: br0)를 사용하도록 구성하는 것입니다. 또한 docker 데몬의 fixed-cidr 옵션을 사용해 CIDR 형태(예: 172.21.195.240/26, 64개 IP)로 표현된 배타적이고 연속적인 IP 범위를 각 docker 데몬에 할당합니다. docker daemon.json은 다음과 같습니다:

"bridge": "br0"
"fixed-cidr": "172.21.195.240/26"

docker 브리지 네트워크를 커스터마이즈하는 방법은 해당 문서를 확인하세요.

Registry DNS와의 명명 규칙

DNS 지원으로 사용자는 아래와 같은 잘 정의된 명명 형식으로 자신의 서비스에 간단히 접근할 수 있습니다:

${COMPONENT_INSTANCE_NAME}.${SERVICE_NAME}.${USER}.${DOMAIN}

예를 들어, 도메인 이름이 yarncluster(core-site.xml의 hadoop.registry.dns.domain-name으로 정의)인 클러스터에서 사용자 devuser가 배포한 hbase라는 서비스에 hbasemaster, regionserver 두 컴포넌트가 있다면 다음과 같이 접근할 수 있습니다. 이 URL은 일반적인 hbase master UI를 가리킵니다:

http://hbasemaster-0.hbase.devuser.yarncluster:16010/master-status

YARN 서비스 프레임워크는 각 컨테이너에 단조 증가하는 정수 시퀀스로 COMPONENT_INSTANCE_NAME을 할당한다는 점에 유의하세요. 예를 들어 hbasemaster 컴포넌트의 첫 번째이자 유일한 인스턴스이므로 hbasemaster-0에 0이 할당됩니다. regionserver 컴포넌트의 경우 여러 컨테이너를 가질 수 있으므로 regionserver-0, regionserver-1, regionserver-2 ... 와 같이 명명됩니다.

또한 각 YARN 서비스 컴포넌트는 RegistryDNS를 통한 컨테이너 장애 허용(fault tolerance) 또는 로드 밸런싱을 위한 Multi-A 레코드를 가집니다. 명명 형식은 다음과 같이 정의됩니다:

${COMPONENT_NAME}.${SERVICE_NAME}.${USER}.${DOMAIN}

예를 들어 Chuck이 3개 컨테이너로 실행한 app 애플리케이션의 www라는 컴포넌트는 다음과 같은 DNS 레코드를 가집니다:

www.app.chuck.example.com IN A 123.123.123.1
www.app.chuck.example.com IN A 123.123.123.1
www.app.chuck.example.com IN A 123.123.123.1

고지: DNS 구현은 아직 실험적입니다. 완전한 기능의 DNS로 사용해서는 안 됩니다.

더 알아보기 (Learn more)