서버 측 서비스 발견과 로드 밸런싱

이번 강의에서는 마이크로서비스 네트워크에서 서버 측 서비스 발견과 로드 밸런싱의 개념을 깊이 있게 다룹니다.
이를 통해 Eureka 서버를 대체하고, 개발자의 부담을 줄이는 방법을 알아보겠습니다. 주요 개념과 과정을 단계별로 정리해보겠습니다.

1. 클라이언트 측 서비스 발견과 로드 밸런싱

• 개요: 마이크로서비스 네트워크에서 각 마이크로서비스는 시작 시 서비스 레지스트리(Eureka 같은)에 스스로 등록합니다. 서비스 종료 시에는 등록 해제하며, 주기적으로 자신의 상태를 나타내는 하트비트를 보냅니다.
• 동작 과정:
  1. 서비스 등록: 예를 들어, Loans 마이크로서비스는 시작할 때 Eureka 서버에 자신의 인스턴스 정보(호스트 이름, 포트 번호 등)를 등록합니다.
  2. 서비스 요청: Accounts 마이크로서비스가 Loans 마이크로서비스와 통신하려면, 먼저 Eureka 서버에서 Loans 마이크로서비스의 인스턴스 정보를 요청합니다.
  3. 로드 밸런싱: Eureka 서버는 Loans 마이크로서비스의 인스턴스 목록을 반환합니다. Accounts 마이크로서비스는 이 정보를 바탕으로 Spring Cloud Load Balancer를 통해 적절한 인스턴스를 선택해 요청을 보냅니다.
• 장점: 클라이언트가 로드 밸런싱 전략을 완전히 제어할 수 있습니다.
• 단점: 개발자가 Eureka 서버를 직접 관리하고, 각 마이크로서비스에서 Eureka와의 연결을 설정해야 하는 부담이 있습니다.

2. 서버 측 서비스 발견과 로드 밸런싱

• 개요: Kubernetes 클러스터에서만 사용할 수 있는 접근 방식으로, 서비스 발견과 로드 밸런싱이 클라이언트가 아닌 서버 측에서 수행됩니다. 이 접근 방식에서는 마이크로서비스가 Eureka 같은 서비스 레지스트리에 직접 등록할 필요가 없습니다.
• 동작 과정:
  1. Kubernetes 서비스 발견: Kubernetes의 서비스 발견 서버가 Kubernetes API를 통해 모든 마이크로서비스의 인스턴스 정보를 수집합니다.
  2. 서비스 요청: Accounts 마이크로서비스가 Loans 마이크로서비스와 통신하려고 할 때, 클라이언트는 단순히 Kubernetes 서비스 URL을 통해 요청을 보냅니다.
  3. 서버 측 로드 밸런싱: Kubernetes 서비스와 서비스 발견 서버가 협력하여 로드 밸런싱을 수행하고, 요청을 적절한 Loans 마이크로서비스 인스턴스로 전달합니다.
• 장점: 개발자가 Eureka 서버 관리와 관련된 작업에서 자유로워집니다. 마이크로서비스는 별도의 설정 없이 Kubernetes 환경에서 자동으로 관리됩니다.
• 단점: 클라이언트 애플리케이션이 로드 밸런싱에 대한 제어권을 잃습니다. 모든 로드 밸런싱은 Kubernetes 클러스터가 결정합니다.

3. 클라이언트 측과 서버 측의 비교

• 클라이언트 측 로드 밸런싱:

  • 사용 예: Eureka 서버와 Spring Cloud Load Balancer를 사용하는 경우.
  • 특징: 클라이언트가 로드 밸런싱 전략을 결정.
  • 개발자의 부담: 높음 (Eureka 서버 관리, 마이크로서비스 설정 필요).

• 서버 측 로드 밸런싱:

  • 사용 예: Kubernetes 클러스터에서의 마이크로서비스 배포.
  • 특징: 로드 밸런싱이 서버 측에서 자동으로 처리.
  • 개발자의 부담: 낮음 (Kubernetes가 서비스 등록 및 로드 밸런싱을 관리).

실습 목표

이번 섹션에서는 서버 측 서비스 발견과 로드 밸런싱을 구현하여 마이크로서비스 네트워크에서 Eureka 서버를 제거하고, Kubernetes의 네이티브 기능을 활용하는 방법을 실습합니다. 이를 통해 개발자는 더 효율적으로 마이크로서비스를 관리할 수 있습니다.

결론

이번 강의를 통해 클라이언트 측과 서버 측 서비스 발견 및 로드 밸런싱의 개념과 장단점을 명확히 이해했으며, 이를 실습으로 구현하는 방법을 학습하게 될 것입니다. 두 접근 방식 모두 각각의 장점이 있으므로, 비즈니스 요구 사항에 따라 적절한 방법을 선택하면 됩니다.

감사합니다.