[Service Mesh] Envoy 용어 및 xDS, ADS정리

Envoy proxy

마이크로서비스 아키텍처용으로 설계된 오픈 소스 서비스 프록시 및 통신 오픈소스이다.

circuit breaker 등 MSA를 구축하면서 중요한 역할을 맡는다 특징은 아래와 같다.

• C++로 구현된 고성능 프록시
• 네트워크의 투명성을 목표
• 다양한 필터체인 지원
• L3/L4 필터
• HTTP L7 필터
• Dynamic configuration API 제공 -> 설정 정보를 동적으로 읽어와서 서버 재시작없이 라우팅 설정 변경이 가능함
• 기능이 많다. -> circuit breaker, 부하량 제한등 다양한 로드밸런싱 기능 제공
• CNCF / 벤더가 없다

 

다운스트림(Downstream) : 엔보이에 요청을 보내고 응답을 받는 호스트

 

업스트림(Upstream) : 엔보이로 부터 요청을 받아서 응답을 보내는 호스트

 

리스너(Listener) : 다운스트림 클라이언트에서 연결할 수 있는 네트워크 위치하며 IP/port에 바인딩하고, 요청처리 측면에서 다운스트림을 조정하는 역할

(envoy는 다운스트림에서 연결할 수 있는 리스너를 하나 이상 제공)

 

필터(Filter) : 수신된 메시지에 대해 라우팅, 프로토콜 변환, 통계 생성과 같은 다양한 작업을 수행하는 부분

여러 필터들을 모아 Filter Chain으로 사용

 

클러스터(Cluster) :  업스트림 호스트들의 그룹으로 헬스체크와 로드밸런싱 정책을 설정하며 endpoint들로 구성되어 졌다 

 

공식 사이트에서 제공하는 기본 envoy 생성 yaml 파일을 보면 아래와 같다

static_resources:
# 다운스트림이 들어오는 리스너
  listeners:
  - name: listener_0
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 10000
    filter_chains: # 여러 필터들을 모아 필터 체인으로 사용
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          access_log:
          - name: envoy.access_loggers.stdout
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  host_rewrite_literal: www.envoyproxy.io
                  cluster: service_envoyproxy_io # 라우트 클러스터 정의

  clusters: # 업스트림의 그룹이자 하나 이상의 endpoint들로 구성되어짐
  - name: service_envoyproxy_io
    type: LOGICAL_DNS
    # Comment out the following line to test on v6 networks
    dns_lookup_family: V4_ONLY
    load_assignment:
      cluster_name: service_envoyproxy_io
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: www.envoyproxy.io
                port_value: 443
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
        sni: www.envoyproxy.io

해당 야믈 파일 배포하고 localhost:10000으로 진입하면 아래와 같이 정상적으로 enovoy 화면 뜨는걸 확인 가능

배포방식

• Front envoy proxy
  전체 시스템 앞에 위치하여 프록시 역할로 클라이언트에서 들어오는 호출을 받아서 각각의 서비스로 라우팅 그 외 URL 기반으로 라우팅 하는 기능, TLS(SSL) 처리하는 역할 수행
  
  
• Service to service ingress listener
  특정 서비스 앞에 위치하는 배포 방식으로, 해당 서비스에 들어오는 트래픽 처리 및 트래픽에 대한 버퍼링이나 circuit breaker 수행
  
  
• Service to service engress listener
  특정 서비스 뒤에 위치하는 배포 방식으로, 해당 서비스로부터 나가는 호출에 대하여 대상이 되는 서비스의 로드 밸런싱, 호출 횟수 통제와 같은 기능을 수행

설명에서 envoy를 ingress/engress listener로 나누었지만 실제로 2개의 envoy를 설치하는게 아니라 하나의 envoy로 2개의 역할을 수행

 

xDS

처음에 envoy특징으로 Dynamic configuration API 제공과 이를 통해 설정 정보( Listener, Route, Cluster, Endpoint 등 )를 동적으로 읽어와서 서버 재시작없이 라우팅 설정 변경이 가능하다 설명 했는데 이러한 API들은 각각 LDS, RDS, CDS, EDS 등 이라고 부르며 Discovery Service API의 집합을 xDS라 한다.

 

EDS(Endpoint Discovery Service) : 업스트림 클러스터의 엔드포인트들을 관리

CDS(Cluster Discovery Service) : 라우팅하는 동안 사용하는 업스트림 클러스터를 관리

RDS(Route Discovery Service) : 필터의 전체 라우트 설정을 관리하는 기능.

LDS(Listener Discovery Service) : 리스너를 관리하는 기능 (각종 필터관련 설정도 여기서 함)

등

 

이렇게  Dynamic configuration API를 사용하면 위해서 생성했던 envoy.yaml파일 같은 설정들을 복잡하게 넣을 필요없이 api를 통해 설정할 수 있어 간단하게 사용 가능하다.

 

즉 아래 그림과 같이 Service Mesh에서 

1. xDS를 제공하는 istio Control Plane

2. Envoy가 설치 되어있어 Envoy에서 필요로 하는 xDS API를 적절히 제공 받는 Data Plane로 구성되어 있다.

또한 xDS는 gRPC 또는 REST 방식으로 제공할 수 있는데,  아래서 설명할 ADS는 REST방식을 제공하지 않고 gRPC만 제공하며 REST는 레거시이므로 보통은 gRPC로 구현하는 것이 일반적이다.

 

 

Aggregated Discovery Service(중요!!)

하지만 다양한 xDS를 사용해서 xDS의 API 호출 시 Race Condition이 발생하여 트래픽 드롭이 생길 수 있다.

 

* Race condition이란 두 개 이상의 프로세스가 공통 자원을 병행적으로 동작을 할 때, 공용 자원에 대한 접근이 어떤 순서에 따라 이루어졌는지에 따라 그 실행 결과가 같지 않고 달라지는 상황

 

아래 그림은 EDS와 CDS를 동시에 호출했다고 가정 시 발생할 수 있는 문제를 보여준다.

이렇게 Race Condition이 발생하여 EDS가 CDS보다 먼저 도착했다면 Cluster에 대한 정보가 아직 없는 상태이므로, Envoy는 4xx, 5xx를 클라이언트에게 반환하게 된다.

 

Envoy에서는 이러한 현상을 Aggregated Discovery Service(ADS)를 만들어 문제를 해결했다.

아래와 같이 ADS를 사용하면 EDS, CDS를 사용하기 위해 단일 gRPC 싱글 스트림에서 모든 xDS 인터페이스에 대해 API를 멀티플렉싱 방식으로 호출하며 업데이트 순서를 지정하는 기능을 제공하여 일시적으로 발생할 수 있는 Race Condition및 트래픽 드롭을 방지한다.

 

참조

https://www.envoyproxy.io/docs/envoy/v1.24.0/api-docs/xds_protocol

https://m.blog.naver.com/alice_k106/222000680202

https://bcho.tistory.com/1295