마이크로서비스 아키텍처에서 서비스 간 통신은 핵심적인 요소입니다. 그러나 클라우드 환경의 동적인 특성으로 인해 서비스 인스턴스의 IP 주소와 포트가 계속 변경되는 상황에서 어떻게 효율적으로 서비스를 찾고 통신할 수 있을까요? 이 문제를 해결하기 위한 핵심 기술인 Spring Cloud Eureka에 대해 상세히 알아보겠습니다.
1. MSA 아키텍처에서 서비스 디스커버리의 필요성
마이크로서비스 아키텍처(MSA)에서는 여러 서비스가 독립적으로 배포되고 실행됩니다. 클라우드 환경에서 이러한 서비스들은 다음과 같은 특성을 가집니다.
- 자동 스케일링에 의해 인스턴스 수가 동적으로 변경됨
- 장애 복구 과정에서 서비스 위치가 변경됨
- 컨테이너 기반 배포로 IP와 포트가 동적으로 할당됨
이러한 환경에서 정적인 설정 파일로 서비스 위치를 관리하는 것은 매우 비효율적입니다. 따라서 서비스의 물리적 위치에 의존하지 않고 논리적 이름만으로 서비스를 찾을 수 있는 메커니즘이 필요하게 되었습니다.
2. Eureka란?
2.1 Eureka의 기본 정의 및 역할
Eureka는 넷플릭스가 개발한 서비스 디스커버리 서버로, 마이크로서비스 아키텍처에서 서비스의 위치 정보를 동적으로 관리합니다. Eureka는 중간 계층 로드 밸런서(middle-tier load balancer)로 정의되며, 각 서비스의 IP, 포트, 인스턴스 ID 정보를 REST 기반으로 관리합니다.
2.2 서비스 디스커버리 패턴 개념
서비스 디스커버리 패턴은 분산 시스템 환경에서 동적으로 서비스를 등록하고 검색할 수 있는 메커니즘입니다. 이 패턴을 통해 클라이언트는 서비스의 물리적 위치를 몰라도 논리적 이름만으로 원하는 서비스를 찾아 통신할 수 있습니다.
핵심 용어
- Service Registration: 서비스가 자신의 정보를 레지스트리에 등록하는 과정
- Service Registry: 서비스 위치 정보를 저장하는 데이터베이스
- Service Discovery: 클라이언트가 필요한 서비스의 위치를 찾는 과정
2.3 Client-Side Service Discovery로서의 Eureka
Eureka는 Client-Side Discovery 방식을 채택하고 있습니다. 이 방식에서는 서비스 소비자(Client)가 서비스 레지스트리로부터 서비스 인스턴스의 위치를 직접 조회하고, 로드 밸런싱을 수행합니다.
Client-Side Discovery의 장점
- 서비스별로 소프트웨어적으로 로드 밸런싱 구현 가능
- 하드웨어 장비 없이 구현 가능하여 비용 효율적
단점
- 서비스별로 로직을 구현해야 해서 종속성이 높아짐
- 언어, 프레임워크별로 별도 구현 필요
3. Eureka의 주요 구성요소
3.1 Eureka Server
Eureka Server는 서비스 레지스트리의 역할을 담당합니다. 모든 마이크로서비스는 이 서버에 자신의 정보를 등록하고, 다른 서비스의 정보를 조회할 수 있습니다.
주요 기능
- REST API 기반으로 서비스 정보 관리
- 30초마다 서비스 목록 갱신
- 서비스 이름 기준으로 탐색
- 내부적으로 Ribbon을 사용한 로드 밸런싱 지원
3.2 Eureka Client
Eureka Client는 서비스 인스턴스로, Eureka Server에 자신을 등록하고 필요한 서비스의 정보를 조회하는 역할을 합니다.
주요 기능
- 서비스 시작 시 Eureka Server에 자신의 정보 등록
- 주기적으로 하트비트 신호를 보내 가용성 유지
- 서비스 레지스트리 정보를 주기적으로 조회하여 로컬 캐시에 저장
3.3 Service Registry와 Discovery 메커니즘
Service Registry는 모든 서비스 인스턴스의 정보를 저장하는 데이터베이스입니다. Service Discovery 메커니즘은 클라이언트가 이 레지스트리를 통해 원하는 서비스를 찾는 과정을 말합니다.
이 메커니즘을 통해 클라이언트는 서비스의 물리적 위치(IP, 포트)를 몰라도 논리적 이름만으로 서비스를 찾아 통신할 수 있습니다.
4. Eureka 동작 프로세스
4.1 서비스 등록 과정 (Service Registration)
- 서비스가 시작되면 Eureka Server에 자신의 정보(이름, IP, 포트, 인스턴스 ID)를 등록합니다
- Eureka Server는 이 정보를 레지스트리에 저장합니다
4.2 서비스 조회 과정 (Service Lookup)
- 클라이언트가 서비스 이름으로 Eureka Server에 서비스 위치를 질의합니다
- Eureka Server는 해당 서비스의 모든 인스턴스 정보를 반환합니다
- 클라이언트는 로드 밸런싱 알고리즘을 사용하여 인스턴스를 선택합니다
- 클라이언트는 선택한 인스턴스에 직접 요청을 보냅니다
4.3 헬스 체크 메커니즘 (Heartbeat)
Eureka Client는 주기적으로 Eureka Server에 하트비트(heartbeat)를 전송하여 자신이 살아있음을 알립니다.
- 기본 하트비트 전송 주기: 30초 (
eureka.instance.lease-renewal-interval-in-seconds) - Eureka Server가 하트비트를 받지 못하는 최대 시간: 90초 (
eureka.instance.lease-expiration-duration-in-seconds)
이러한 설정은 변경할 수 있지만, 서버 내부 로직과의 충돌 가능성 때문에 변경을 권장하지 않습니다.
4.4 서비스 제거 프로세스
서비스 인스턴스가 제거되는 두 가지 경우가 있습니다
- 정상 종료: 서비스가 정상적으로 종료되면 즉시 레지스트리에서 제거됩니다
- 비정상 종료: 설정된 시간(기본 90초) 동안 하트비트가 수신되지 않으면 해당 인스턴스를 레지스트리에서 제거합니다.
5. Eureka의 장점과 단점
5.1 장점
- 서비스 검색과 자동 등록: 서비스가 자동으로 등록되고 검색되므로 설정이 간소화됩니다.
- 탄력적인 확장성: 클라우드 환경에서 서비스 인스턴스의 동적 확장을 지원합니다.
- 장애 격리와 내결함성: A 서비스에 문제가 생겨도 B 서비스는 정상 작동합니다.
5.2 단점
- 단일 장애 지점: Eureka 서버 자체에 장애가 발생하면 전체 서비스 검색 메커니즘에 영향을 미칠 수 있습니다.
- 추가적인 인프라 요구: Eureka 서버를 위한 추가 인프라와 운영 비용이 발생합니다.
- 초기 설정 및 복잡성: MSA 아키텍처의 복잡성으로 인해 설정과 관리가 어려울 수 있습니다.
