3rd Party Registration 3rd Party Registration은 마이크로서비스 아키텍처에서 서비스 디스커버리를 위한 패턴 중 하나이다. 이 패턴에서는 서비스 인스턴스가 직접 자신을 서비스 레지스트리에 등록하지 않고, 별도의 외부 컴포넌트가 서비스의 등록과 해제를 담당한다. 주요 특징: 서비스 인스턴스와 레지스트리 간의 결합도 감소 중앙 집중식 서비스 관리 다양한 언어와 프레임워크에 대한 일관된 등록 메커니즘 제공 3rd Party Registration 패턴은 마이크로서비스 아키텍처에서 서비스 디스커버리를 효과적으로 관리할 수 있는 방법이지만, 추가적인 복잡성을 감수해야 하므로, 시스템의 규모와 요구사항을 고려하여 적절히 적용해야 한다. ...
Self Registration Self Registration은 각 마이크로서비스 인스턴스가 자신의 정보를 서비스 레지스트리에 직접 등록하고 관리하는 패턴이다. 서비스가 시작될 때 자동으로 등록되고, 종료될 때 해제되는 방식으로 동작한다. Self Registration 패턴은 마이크로서비스 환경에서 동적으로 변화하는 서비스 인스턴스를 효과적으로 관리할 수 있게 해주는 중요한 패턴이다. 하지만 구현의 복잡성과 유지보수 측면에서 주의가 필요하며, 프로젝트의 규모와 요구사항에 따라 적절히 선택해야 한다. 주요 특징 자동 등록: 서비스 인스턴스가 시작될 때 자신의 정보(호스트, IP 주소, 포트 등)를 레지스트리에 등록한다. 자동 해제: 서비스가 종료될 때 레지스트리에서 자신의 정보를 제거한다. 헬스체크: 주기적으로 레지스트리에 헬스체크 신호를 보내 자신이 살아있음을 알린다. 상태 관리: 서비스 인스턴스가 자신의 상태를 가장 잘 알기 때문에, UP/DOWN 외에도 STARTING, AVAILABLE 등 더 복잡한 상태 모델을 구현할 수 있다. 구현 방법 서비스 레지스트리 설정: Eureka, Consul, ZooKeeper 등의 도구를 사용하여 중앙 레지스트리를 구축한다. 서비스 등록 코드 구현: 각 마이크로서비스에 자신을 레지스트리에 등록하는 코드를 추가한다. 헬스체크 메커니즘 구현: 주기적으로 레지스트리에 헬스체크 신호를 보내는 로직을 구현한다. 서비스 디스커버리 클라이언트 구현: 다른 서비스들이 등록된 서비스를 찾고 통신할 수 있도록 한다. 장점 구현이 비교적 간단하다. 추가적인 시스템 컴포넌트가 필요하지 않다. 서비스가 자신의 상태를 가장 잘 알기 때문에 정확한 정보를 제공할 수 있다. 단점 서비스와 레지스트리 간의 결합도가 높아진다. 각 프로그래밍 언어와 프레임워크마다 등록 로직을 구현해야 한다. 서비스가 비정상적으로 종료될 경우 레지스트리에서 자동으로 제거되지 않을 수 있다. 구현 예시 Netflix Eureka는 셀프 등록 패턴의 대표적인 예시이다. Eureka 클라이언트는 다음과 같은 방식으로 동작한다: ...
Server-side Discovery Server-side Discovery는 클라이언트가 서비스의 위치를 직접 찾지 않고, 중간에 위치한 로드 밸런서나 프록시 서버가 서비스 위치를 찾아 요청을 라우팅하는 방식이다. Server-side Discovery는 클라이언트를 단순화하고 중앙 집중식 관리를 가능하게 하는 장점이 있지만, 추가 인프라와 관리가 필요한 단점도 있다. 프로젝트의 요구사항과 팀의 역량을 고려하여 적절히 선택해야 한다. 작동 원리 서비스 등록: 각 서비스 인스턴스는 시작 시 자신의 정보를 서비스 레지스트리에 등록한다. 클라이언트 요청: 클라이언트는 서비스의 실제 위치를 모르고, 로드 밸런서에 요청을 보낸다. 서비스 조회: 로드 밸런서는 서비스 레지스트리에서 해당 서비스의 가용한 인스턴스 정보를 조회한다. 요청 라우팅: 로드 밸런서는 적절한 서비스 인스턴스를 선택하여 요청을 전달한다. 응답 반환: 서비스의 응답은 로드 밸런서를 통해 클라이언트에게 전달된다. 장점 클라이언트 단순화: 클라이언트는 서비스 디스커버리 로직을 구현할 필요가 없어 단순해진다. 언어 중립성: 클라이언트 측 구현이 필요 없어 다양한 프로그래밍 언어로 개발된 서비스들을 쉽게 통합할 수 있다. 보안 강화: 로드 밸런서 수준에서 추가적인 보안 계층을 구현할 수 있다. 중앙 집중식 관리: 서비스 디스커버리와 로드 밸런싱을 중앙에서 관리할 수 있다. 단점 추가 인프라 필요: 로드 밸런서나 프록시 서버와 같은 추가 인프라가 필요하다. 단일 실패 지점: 로드 밸런서가 단일 실패 지점이 될 수 있어 고가용성 설계가 중요하다. 복잡성 증가: 전체 시스템의 복잡성이 증가할 수 있다. 구현 예시 AWS Elastic Load Balancer (ELB): 클라이언트는 ELB의 DNS 이름을 통해 요청을 보내며, ELB는 등록된 EC2 인스턴스나 ECS 컨테이너 사이에서 부하를 분산한다. Kubernetes의 kube-proxy: Kubernetes에서는 각 노드에서 실행되는 kube-proxy가 서비스 디스커버리와 로드 밸런싱을 담당하며, 클러스터 내의 서비스 요청을 적절한 파드(Pod)로 전달한다. Node.js를 사용한 Server-side Discovery 구현 예시 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 // 서버 사이드 디스커버리 라우터 구현 class ServiceRouter { constructor(options = {}) { this.registryUrl = options.registryUrl || 'http://service-registry:8500'; this.serviceCache = new Map(); this.cacheTimeout = options.cacheTimeout || 30000; // 30초 this.loadBalancer = new LoadBalancer(); } async handleRequest(req, res) { const serviceName = this.extractServiceName(req); try { // 서비스 인스턴스 찾기 const serviceInstance = await this.findServiceInstance(serviceName); // 요청 전달 const response = await this.forwardRequest(req, serviceInstance); // 응답 전달 this.sendResponse(res, response); } catch (error) { this.handleError(res, error); } } async findServiceInstance(serviceName) { // 캐시된 서비스 확인 const cachedInstances = this.getCachedInstances(serviceName); if (cachedInstances && cachedInstances.length > 0) { return this.loadBalancer.selectInstance(cachedInstances); } // 서비스 레지스트리 조회 const instances = await this.queryRegistry(serviceName); this.updateCache(serviceName, instances); return this.loadBalancer.selectInstance(instances); } async forwardRequest(req, serviceInstance) { const targetUrl = this.buildTargetUrl(serviceInstance, req.path); return await fetch(targetUrl, { method: req.method, headers: req.headers, body: req.body, timeout: 5000 }); } } 참고 및 출처
Service Registry Service Registry는 마이크로서비스 환경에서 각 서비스 인스턴스의 네트워크 위치(IP 주소와 포트)를 저장하고 관리하는 중앙화된 데이터베이스이다. 이는 동적으로 변화하는 마이크로서비스 환경에서 서비스 디스커버리를 가능하게 하는 핵심 요소이다. Service Registry는 MSA 환경에서 서비스 디스커버리를 가능하게 하는 핵심 컴포넌트이다. 이를 통해 동적이고 확장 가능한 마이크로서비스 아키텍처를 구현할 수 있다. 서비스 레지스트리의 중요성 MSA 환경에서는 서비스 인스턴스가 자동 확장, 장애 복구, 배포 등의 이유로 동적으로 생성되고 소멸되며, 이에 따라 네트워크 위치가 변경된다. 이러한 동적인 특성으로 인해, 서비스 레지스트리는 다음과 같은 역할을 수행한다: ...
Client-side Discovery Client-side Discovery는 서비스 클라이언트가 직접 서비스 레지스트리에 질의하여 필요한 서비스의 위치 정보를 얻고, 그 정보를 바탕으로 서비스를 호출하는 방식이다. Client-side Discovery는 마이크로서비스 환경에서 유연하고 확장 가능한 서비스 디스커버리 방식을 제공한다. 그러나 클라이언트의 복잡도가 증가하는 단점이 있으므로, 프로젝트의 요구사항과 팀의 기술 스택을 고려하여 적절히 선택해야 한다. 주요 구성 요소 서비스 레지스트리(Service Registry): 각 서비스 인스턴스의 네트워크 위치(예: IP 주소, 포트)를 저장하고 관리하는 데이터베이스이다. 서비스 인스턴스는 시작 시 자신의 정보를 레지스트리에 등록하고, 종료 시 등록을 해제한다. ...