xDS
1. 개요
1. 개요
xDS는 서비스 메시 아키텍처에서 데이터 플레인 구성 요소에 동적 구성 정보를 전달하기 위한 일련의 API 및 프로토콜 세트를 가리킨다. 이 용어는 "X Discovery Service"의 약자로, 여기서 'X'는 구성 요소의 종류를 의미한다. xDS는 Lyft가 개발한 오픈소스 엣지 프록시 및 서비스 프록시인 Envoy 프로젝트에서 처음 등장했으며, 2017년경에 그 개념이 정립되었다. 이는 클라우드 네이티브 애플리케이션과 마이크로서비스 환경에서 서비스 간 통신을 효율적으로 관리하는 핵심 메커니즘으로 자리 잡았다.
xDS의 핵심 목적은 서비스 메시 내의 프록시 서버가 중앙 집중식 제어 플레인으로부터 리스너, 라우트, 클러스터, 엔드포인트 등의 구성 정보를 실시간으로 발견하고 동적으로 업데이트받을 수 있게 하는 것이다. 이를 통해 서비스 운영자는 애플리케이션 코드를 재배포하거나 프록시를 재시작하지 않고도 트래픽 라우팅, 로드 밸런싱, 보안 정책, 관찰 가능성 설정 등을 유연하게 변경할 수 있다. xDS는 서비스 메시의 핵심 구성 요소로서, Istio, Linkerd와 같은 서비스 메시 구현체의 기반이 된다.
2. xDS API의 종류
2. xDS API의 종류
2.1. LDS (Listener Discovery Service)
2.1. LDS (Listener Discovery Service)
LDS는 리스너 디스커버리 서비스의 약자이다. 이는 xDS API의 핵심 구성 요소 중 하나로, 데이터 플레인의 프록시 서버가 어떤 네트워크 포트에서 트래픽을 수신할지, 그리고 그 트래픽을 어떻게 처리할지에 대한 구성을 동적으로 제공하는 역할을 한다. LDS는 서비스 메시 아키텍처에서 엔보이와 같은 사이드카 프록시에게 리스너 설정을 중앙 집중식으로 관리하고 배포할 수 있게 해준다.
LDS가 제공하는 구성 정보에는 리스너가 바인딩할 IP 주소와 포트, 수신된 연결에 적용할 필터 체인, 그리고 트래픽을 암호화할 TLS 인증서 정보 등이 포함된다. 이를 통해 운영자는 각 마이크로서비스 인스턴스에 배포된 프록시를 직접 재구성하지 않고도, 중앙의 컨트롤 플레인을 통해 전체 메시의 트래픽 수신 정책을 일관되게 변경할 수 있다. 예를 들어, 특정 포트를 새로 열거나, 모든 수신 트래픽에 인증 필터를 추가하는 작업이 LDS를 통해 가능하다.
이러한 동적 구성 방식은 클라우드 네이티브 환경에서 서비스의 확장, 업데이트, 장애 조치가 빈번하게 일어나는 상황에서 특히 유용하다. LDS는 RDS나 CDS 같은 다른 xDS API와 긴밀하게 연동되어, 수신된 트래픽의 라우팅 규칙과 목적지 클러스터 정보를 완전한 처리 파이프라인으로 연결한다.
2.2. RDS (Route Discovery Service)
2.2. RDS (Route Discovery Service)
RDS(Route Discovery Service)는 xDS API 중 하나로, 데이터 플레인 구성 요소(예: Envoy 프록시)가 수신하는 트래픽을 어떤 백엔드 서비스로 라우팅할지에 대한 규칙을 동적으로 제공하는 서비스이다. RDS는 라우팅 테이블 또는 라우팅 구성을 관리하며, 이를 통해 인그레스 트래픽의 경로를 세밀하게 제어할 수 있다. 이는 서비스 메시 아키텍처에서 트래픽 관리의 핵심 구성 요소로 작동한다.
RDS가 제공하는 라우팅 구성에는 가상 호스트(Virtual Host) 정의, 경로(Path) 기반 또는 헤더(Header) 기반 라우팅 규칙, 트래픽 분할(예: 카나리 배포), 재시도 및 타임아웃 정책 등이 포함된다. 이를 통해 운영자는 애플리케이션 코드를 변경하지 않고도 외부 요청이 특정 마이크로서비스 버전으로 전달되도록 하거나, 장애가 발생한 서비스 인스턴스로의 트래픽을 차단하는 등의 정책을 유연하게 적용할 수 있다.
RDS는 일반적으로 LDS(Listener Discovery Service)와 함께 작동한다. LDS가 프록시의 수신 포트와 프로토콜을 정의한다면, RDS는 그 포트로 들어온 요청을 처리할 구체적인 라우팅 로직을 정의한다. 이 분리는 구성의 모듈화와 재사용성을 높여, 복잡한 마이크로서비스 환경에서의 관리를 단순화한다.
2.3. CDS (Cluster Discovery Service)
2.3. CDS (Cluster Discovery Service)
CDS는 클러스터 디스커버리 서비스의 약자이다. 이는 xDS API의 핵심 구성 요소 중 하나로, 데이터 플레인의 프록시가 트래픽을 전달할 수 있는 논리적 서비스 그룹인 클러스터의 구성을 동적으로 관리하는 역할을 한다. CDS를 통해 프록시는 업스트림 서비스의 그룹, 해당 그룹의 연결 정책, 부하 분산 설정 등을 중앙 컨트롤 플레인으로부터 실시간으로 수신받아 적용할 수 있다.
CDS가 제공하는 클러스터 구성 정보에는 클러스터의 이름, 유형(예: 로드 밸런싱을 위한 STATIC 또는 EDS를 통한 동적 엔드포인트 관리), 연결에 사용할 프로토콜(예: HTTP, HTTP/2), 연결 시간 초과 및 헬스 체크 정책 등이 포함된다. 특히, EDS와 긴밀하게 연동되어 클러스터에 속한 실제 서비스 인스턴스(엔드포인트) 목록을 동적으로 갱신받는 방식으로 사용되는 것이 일반적이다.
이러한 동적 구성 방식은 마이크로서비스 환경에서 서비스의 스케일링이나 장애 복구 시 발생하는 인스턴스의 변화에 유연하게 대응할 수 있게 해준다. 개발자나 운영자는 애플리케이션 코드를 재배포하지 않고도 컨트롤 플레인의 설정 변경만으로 트래픽 라우팅 대상을 추가하거나, 특정 서비스 그룹에 대한 연결 정책을 전역적으로 수정할 수 있다. 이는 서비스 메시 아키텍처가 제공하는 주요 장점인 중앙 집중식 관찰 가능성과 제어의 기반이 된다.
CDS는 Envoy 프록시를 위해 설계되었으며, gRPC 프로토콜을 통한 스트리밍 방식으로 구현체 간의 표준 인터페이스 역할을 한다. 이를 통해 다양한 컨트롤 플레인 구현체(예: Istio의 Pilot, Consul Connect)가 Envoy 프록시와 통신할 수 있는 공통 언어를 제공한다.
2.4. EDS (Endpoint Discovery Service)
2.4. EDS (Endpoint Discovery Service)
EDS는 서비스 메시에서 실제 서비스 인스턴스, 즉 엔드포인트의 정보를 동적으로 발견하고 관리하기 위한 API이다. 이 서비스는 데이터 플레인의 구성 요소(예: Envoy 프록시)에게 특정 클러스터에 속하는 모든 사용 가능한 엔드포인트(예: IP 주소와 포트 정보)를 제공하는 역할을 한다. CDS가 어떤 서비스 그룹(클러스터)이 존재하는지를 정의한다면, EDS는 그 클러스터를 구성하는 개별 서버 인스턴스의 실시간 상태와 위치를 알려준다.
EDS는 로드 밸런싱, 헬스 체크, 장애 조치와 같은 고급 트래픽 관리 기능의 기반이 된다. 컨트롤 플레인은 각 엔드포인트의 상태(예: 정상, 과부하, 오류)를 지속적으로 모니터링하고, 이 정보를 EDS를 통해 데이터 플레인에 전파한다. 이를 통해 프록시는 실패한 인스턴스로 트래픽을 보내지 않거나, 부하가 적은 인스턴스에 요청을 분산시키는 지능적인 라우팅 결정을 내릴 수 있다. 또한 오토 스케일링 환경에서 새로운 인스턴스가 생성되거나 제거될 때, EDS는 이를 자동으로 감지하고 구성 목록을 갱신하여 서비스 디스커버리의 부담을 줄인다.
EDS의 정보는 일반적으로 gRPC 스트림이나 REST 엔드포인트를 통해 전달되며, xDS 프로토콜의 일부로 표준화되어 있다. 이는 서비스 메시 구현체 간의 상호 운용성을 높이는 데 기여한다. EDS를 통해 얻는 동적 엔드포인트 관리 능력은 마이크로서비스 아키텍처의 핵심 요구사항인 탄력성과 내결함성을 실현하는 데 필수적이다.
2.5. SDS (Secret Discovery Service)
2.5. SDS (Secret Discovery Service)
SDS는 Secret Discovery Service의 약자로, 서비스 메시 아키텍처 내에서 TLS/SSL 인증서, 암호화 키와 같은 보안 정보(시크릿)를 데이터 플레인 프록시에 동적으로 전달하는 데 사용되는 xDS API 중 하나이다. SDS를 통해 각 Envoy 프록시는 중앙 집중식 제어 평면으로부터 필요한 보안 자격 증명을 안전하게 가져와 구성할 수 있다.
이 서비스의 핵심 목적은 인증서와 키의 라이프사이클 관리를 자동화하고 단순화하는 것이다. SDS를 사용하지 않는 전통적인 방식에서는 각 서비스 인스턴스에 인증서와 키를 수동으로 배포하고, 만료 시점을 관리하며, 갱신된 인증서를 다시 배포하는 복잡한 과정이 필요했다. 반면, SDS는 이러한 시크릿을 동적으로 제공하고 갱신함으로써 운영 부담을 크게 줄이고 보안 정책의 일관된 적용을 보장한다.
주요 작동 방식은 다음과 같다. 제어 평면(예: Istio의 Istiod)은 신뢰할 수 있는 인증 기관 역할을 하여 인증서를 발급하고 관리한다. 데이터 플레인의 각 Envoy 프록시는 초기 부팅 시 또는 정책 변경 시 SDS API를 통해 제어 평면에 연결하여 자신에게 필요한 시크릿(예: 특정 서비스 ID에 대한 개인키와 인증서 체인)을 요청한다. 제어 평면은 이 요청을 검증한 후 해당 시크릿을 응답으로 전송하며, 인증서가 만료되기 전에 새로운 인증서를 자동으로 푸시하여 지속적인 보안 연결을 유지한다.
SDS의 도입은 마이크로서비스 간 mTLS(상호 TLS)를 보편화하는 데 기여했다. 서비스 메시 내 모든 트래픽에 투명하게 mTLS를 적용하려면 수천 개의 서비스 인스턴스에 대한 인증서 관리가 필요하다. SDS는 이를 완전히 자동화하여, 개발자가 보안 구성에 신경 쓰지 않고도 기본적으로 보안이 강화된 통신 환경을 제공하는 클라우드 네이티브 보안 모델의 핵심 요소가 되었다.
3. 작동 방식
3. 작동 방식
xDS의 작동 방식은 제어 플레인과 데이터 플레인 간의 구독 기반 통신을 중심으로 이루어진다. 데이터 플레인 구성 요소(예: Envoy 프록시)는 xDS API를 통해 제어 플레인에 연결하여 필요한 구성 정보를 구독한다. 제어 플레인은 서비스 메시의 중앙 관리 지점으로, 서비스 레지스트리, 정책, 인증서 등의 정보를 통합 관리하며, 데이터 플레인의 구독 요청에 따라 해당 구성 정보를 스트리밍 프로토콜을 통해 지속적으로 전송한다.
이 과정에서 사용되는 핵심 메커니즘은 gRPC 스트림 또는 REST 엔드포인트를 통한 폴링이다. 특히 gRPC 스트림 기반 통신이 널리 사용되며, 이를 통해 데이터 플레인은 초기 구성 수신 후에도 제어 플레인과 장기간 연결을 유지한다. 이 연결을 통해 제어 플레인은 서비스 엔드포인트의 변경, 라우팅 규칙 업데이트, 보안 정책의 갱신과 같은 구성 변경 사항이 발생하면 실시간으로 데이터 플레인에 푸시할 수 있다.
이러한 작동 방식은 정적 구성 파일에 의존하는 전통적인 방식과 대비된다. xDS를 사용하면 서비스 디스커버리 정보가 변경되거나 새로운 라우팅 규칙이 적용되어야 할 때, 전체 프록시를 재시작하거나 재구성할 필요 없이 제어 플레인에서 업데이트된 구성을 전송하기만 하면 된다. 데이터 플레인 구성 요소는 이를 수신하여 런타임에 즉시 적용함으로써 서비스의 무중단 운영과 급변하는 클라우드 네이티브 환경에 대한 민첩한 대응이 가능해진다.
결과적으로, xDS는 마이크로서비스 아키텍처에서 분산된 수많은 데이터 플레인 인스턴스들의 구성을 중앙에서 동적이고 선언적으로 관리할 수 있는 표준화된 인터페이스를 제공한다. 이는 서비스 메시 구현의 핵심 기반이 되어 트래픽 제어, 보안, 관찰 가능성 등의 기능을 효율적으로 운영할 수 있게 한다.
4. 주요 구현체
4. 주요 구현체
4.1. Envoy
4.1. Envoy
Envoy는 Lyft에서 개발한 고성능 오픈 소스 프록시 서버이자 서비스 메시의 핵심적인 데이터 플레인 구성 요소이다. Envoy는 마이크로서비스 아키텍처에서 서비스 간 통신을 관리, 보호, 관찰하기 위해 설계되었다. xDS API는 Envoy의 동적 구성 메커니즘의 핵심으로, 실행 중인 Envoy 인스턴스에 리스너, 라우팅, 클러스터, 엔드포인트 정보를 실시간으로 전달하는 역할을 한다.
Envoy는 xDS 프로토콜의 참조 구현체이자 가장 널리 사용되는 구동체이다. Envoy 프록시는 컨트롤 플레인이라고 불리는 관리 서버에 연결하여 xDS API를 통해 구성 정보를 구독하고 수신한다. 이를 통해 재시작 없이 라우팅 규칙을 변경하거나, 서비스 디스커버리 결과를 실시간으로 반영하는 등 동적 구성이 가능해진다. Envoy는 LDS, RDS, CDS, EDS, SDS를 포함한 모든 핵심 xDS API를 지원한다.
Envoy와 xDS의 조합은 Istio, AWS App Mesh와 같은 주요 서비스 메시 솔루션의 기반을 이룬다. 이러한 솔루션에서 Envoy는 각 마이크로서비스 옆에 사이드카 프록시로 배포되어 모든 인바운드 및 아웃바운드 트래픽을 가로채고, 중앙 컨트롤 플레인은 xDS를 통해 모든 Envoy 프록시를 일관되게 제어한다. 이 아키텍처는 트래픽 관리, 보안(mTLS), 관찰 가능성(메트릭, 로그, 트레이싱)을 중앙에서 정책 기반으로 관리할 수 있게 한다.
4.2. gRPC
4.2. gRPC
gRPC는 구글이 개발한 고성능 오픈 소스 원격 프로시저 호출 프레임워크이다. xDS와의 연관성은 gRPC가 xDS 프로토콜을 네이티브로 지원하는 주요 클라이언트 중 하나라는 점에 있다. gRPC 애플리케이션은 xDS 프로토콜을 사용하여 서비스 메시의 제어 평면으로부터 동적으로 구성 정보를 받아올 수 있으며, 이를 통해 로드 밸런싱, 서비스 디스커버리, 트래픽 라우팅 정책을 적용한다. 이는 마이크로서비스 간의 통신을 보다 유연하고 관리하기 쉽게 만든다.
gRPC의 xDS 통합은 특히 gRPC-LB라는 로드 밸런싱 아키텍처를 통해 구현된다. gRPC 클라이언트는 xDS 서버에 구독하여 리스너, 라우트, 클러스터, 엔드포인트 정보를 지속적으로 받아온다. 이를 바탕으로 gRPC는 서버 목록을 동적으로 업데이트하고, 트래픽을 적절한 백엔드 인스턴스로 분산시키며, 회로 차단기나 장애 조치와 같은 고급 트래픽 관리 기능을 수행할 수 있다. 이 방식은 정적 구성 파일에 의존하는 전통적인 방법을 대체한다.
gRPC가 xDS를 지원함으로써 얻는 주요 이점은 클라우드 네이티브 환경에서의 긴밀한 통합이다. 개발자는 gRPC 서비스 코드를 크게 변경하지 않고도 서비스 메시의 강력한 네트워킹 기능을 활용할 수 있다. 예를 들어, Istio나 Linkerd와 같은 서비스 메시 솔루션은 데이터 플레인으로 Envoy 프록시를 사용하는 경우가 많은데, gRPC 애플리케이션이 xDS를 통해 직접 이 제어 평면과 통신하면 Envoy 사이드카를 생략하고도 유사한 수준의 트래픽 제어를 적용하는 것이 가능해진다. 이는 애플리케이션 성능과 효율성을 높이는 데 기여한다.
5. 장점
5. 장점
xDS는 서비스 메시 아키텍처에서 데이터 플레인 구성 요소의 동적 구성 관리를 가능하게 함으로써 여러 가지 중요한 장점을 제공한다. 가장 큰 장점은 중앙 집중식 제어 플레인을 통해 모든 프록시 인스턴스의 구성을 실시간으로 동기화하고 업데이트할 수 있다는 점이다. 이를 통해 운영자는 각각의 Envoy 프록시나 다른 데이터 플레인 에이전트를 개별적으로 재시작하거나 재구성할 필요 없이, 트래픽 라우팅 규칙, 로드 밸런싱 정책, 보안 정책(예: TLS 인증서) 등을 글로벌하게 변경하고 즉시 적용할 수 있다. 이는 대규모 마이크로서비스 환경에서 구성의 일관성과 정확성을 보장하며, 운영 복잡성을 크게 줄여준다.
또한, xDS는 선언적 구성 모델과 API 기반의 표준화된 인터페이스를 제공한다. 운영자는 원하는 최종 상태(예: "A 서비스로 가는 트래픽의 10%를 B 버전으로 전환하라")를 제어 플레인에 선언하기만 하면, 제어 플레인이 이를 xDS 프로토콜을 통해 모든 관련 데이터 플레인 구성 요소에 자동으로 전파한다. 이 표준화된 접근 방식은 벤더 종속성을 낮추고, 서로 다른 구현체 간의 상호 운용성을 높인다. 예를 들어, Istio의 제어 플레인은 Envoy에 xDS를 통해 구성을 전달하며, 이 원리는 다른 호환되는 데이터 플레인에도 적용될 수 있다.
마지막으로, xDS는 높은 수준의 관찰 가능성과 민첩성을 실현하는 데 기여한다. 구성 변경이 실시간으로 이루어지기 때문에 카나리아 배포나 A/B 테스트와 같은 고급 배포 전략을 안전하고 손쉽게 실행할 수 있다. 트래픽을 세밀하게 제어하고 모니터링함으로써 문제를 빠르게 감지하고 롤백할 수 있으며, 이는 전체 시스템의 안정성과 신뢰성을 향상시킨다. 결국, xDS는 클라우드 네이티브 애플리케이션의 핵심 요구사항인 동적성, 자동화, 그리고 탄력적 운영을 뒷받침하는 근간이 된다.
6. 사용 사례
6. 사용 사례
xDS는 주로 서비스 메시 아키텍처의 핵심 구성 요소로 활용된다. Envoy 프록시와 같은 데이터 플레인 사이드카에 라우팅 규칙, 클러스터 정보, 엔드포인트 상태, 보안 인증서 등을 동적으로 전달하여 마이크로서비스 간의 통신을 관리한다. 이를 통해 로드 밸런싱, 서킷 브레이커, A/B 테스트, 카나리 배포 같은 고급 트래픽 제어 기능을 중앙 집중식으로 구성하고 실시간으로 변경할 수 있다.
주요 사용 사례로는 Istio와 같은 서비스 메시 제어 플레인이 있다. Istio의 Pilot 컴포넌트는 xDS API를 구현하여 메시 내 모든 Envoy 프록시에 구성 정보를 배포한다. 이를 통해 운영자는 애플리케이션 코드를 수정하지 않고도 YAML 파일이나 커맨드 라인 인터페이스를 통해 서비스 디스커버리, 트래픽 라우팅, TLS 암호화 정책을 글로벌하게 관리할 수 있다.
또한, xDS는 gRPC 생태계에서도 중요한 역할을 한다. gRPC 클라이언트는 xDS 프로토콜을 통해 서버 엔드포인트 정보를 동적으로 탐색하고, 연결 풀을 최적화하며, 고가용성을 유지할 수 있다. 이는 클라우드 네이티브 환경에서 서비스 인스턴스의 빈번한 생성과 소멸에 대응하는 데 유용하다.
이 외에도 API 게이트웨이나 최신 애플리케이션 딜리버리 컨트롤러에서도 xDS를 채택하여 기존의 정적 구성 방식을 대체하는 추세이다. 이를 통해 데브옵스 팀은 지속적 배포 파이프라인과 통합된 더욱 민첩하고 자동화된 네트워크 구성 관리가 가능해진다.
