envoy 기본 개념

 

envoy 주요 용어

 

호스트(Host) : 논리적인 네트워크 애플리케이션을 의미합니다. 하나의 물리적인 장비에 여러개의 호스트가 있을 수 있습니다. 물리 장비 하나에 여러개의 주소가 있는 경우에 그 각각의 주소를 이용하는 애플리케이션들이 모두 하나의 호스트가 될 수 있습니다.

 

다운스트림(Downstream) : 엔보이에 요청을 보내고 응답을 받는 호스트입니다. 보통 요청을 보내는 클라이언트를 뜻합니다.

 

업스트림(Upstream) : 엔보이로 부터 요청을 받아서 응답을 보내는 호스트를 의미합니다. 보통 요청을 받아주는 서버를 뜻합니다.

 

리스너(Listener) : 다운스트림 클라이언트에서 연결할 수 있는 네트워크 위치(포트, 유닉스 도메인 소켓)를 의미합니다. 엔보이는 다운스트림에서 연결할 수 있는 리스너를 하나 이상 제공합니다.

 

클러스터(Cluster) : 엔보이가 연결할 수 있는 논리적으로 비슷한 업스트림 호스트들의 그룹입니다. 엔보이는 서비스 디스커버리(service discovery)를 통해서 멤버들의 상태를 확인합니다. 헬스체크와 로드밸런싱 정책을 설정할 수 있습니다.

 

메시(Mesh) : 안정적인 네트워크 토폴로지를 제공하도록 관리하는 호스트들의 그룹입니다. “엔보이 메시”라고 하면 엔보이 프록시들의 그룹을 의미합니다.

 

런타임 설정(Runtime configuration) : 실행중인 엔보이를 재시작하지 않고도 주요 설정들을 변경할 수 있는 기능

 

 

스레드 모델

엔보이는 싱글 프로세스에서 다중스레드를 관리하는 아키텍처를 사용합니다.

하나의 마스터(master) 스레드가 여러개의 워커(worker) 스레드를 관리합니다.

일단 커넥션이 연결되면 해당 커넥션에 할당된 워커 스레드가 종료될때까지 관리를 담당합니다.

envoy는 워커 스레드 갯수를 장비의 하드웨어 스레드 갯수와 동일하게 설정하는걸 추천합니다.

기본값은 워커스레드들을 별도로 조정하지는 않고 커널이 관리하도록 맡겨둡니다. 

따로 설정하려면 각 리스너 마다 connection_balance_config 설정을 지정해야 합니다.

 

설정 방법

envoy를 설정하는 방법은 크게 2가지로 분류됩니다.

전통적인 방법인 정적설정방법과 API를 통해서 설정을 변경하는 동적설정 방법이 있습니다.

 

정적설정의 경우에는 설정을 변경하려면 hot restart를 해야 합니다.

 

동적설정 설정 방법은 API를 사용하는 것인데 보통 xDS라고해서 xxxx Discovery Service의 줄임말을 사용합니다.

별도의 management server를 실행해두고 envoy가 해당 서버를 바라보게해서 설정하는 방법입니다.

xDS에는 다음처럼 여러가지 종류가 있습니다.

 

EDS(Endpoint Discovery Service) : 업스트림 클러스터의 멤버들을 관리하는 기능

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

RDS(Route Discovery Service) : 실행중에 HTTP 커넥션 매니저 필터용의 전체 라우트 설정을 관리하는 기능.

VHDS(Virtual Host Discovery Service) : 라우트 설정에 가상 호스트를 관리하는 기능.

SRDS(Scoped Route Discovery Service) : 라우트 테이블이 너무 클 경우에 여러개로 나눠서 관리하는 기능.

LDS(Listener Discovery Service) : 실행중에 전체 리스너를 관리하는 기능. 각종 필터관련 설정도 여기서 함.

SDS(Secret Discovery Service) : 리스너의 보안 및 인증서 관련 정보들을 관리.

RTDS(RunTime Discovery Service) : xDS API를 통해서 런타임 계층을 가져올 수 있게하는 기능.

 

 

envoy 초기 실행 과정

• envoy가 처음 시작하면 cluster manager가 여러단계를 거쳐서 초기화를 시작합니다.우선 static/DNS 클러스터를 초기화합니다. 그리고 EDS 클러스터를 설정합니다. 그리고 CDS를 초기화하고 초기 응답(성공, 실패)이 오는지 기다립니다.

• 클러스터가 헬스체킹을 사용중이면, 헬스체크를 진행합니다.

• cluster manager 초기화가 끝나면, RDS, LDS를 초기화 합니다. LDS/RDS 요청에 응답이 오는지 대기합니다. 이 과정이 성공하고 나면 커넥션을 받기 시작합니다.

• LDS가 RDS응답에 필요한 리스너를 반환하면, envoy는 RDS 응답이 올때까지 기다립니다. 이 과정을 listerner warming이라고 합니다.

• 앞선 모든 과정이 지나고나면 리스너가 새로운 커넥션을 받아들이기 시작합니다. 이런 과정을 통하기 때문에 새로운 프로세스를 hot retsrat 할때 이전 프로세스의 드레인(drain)을 시작하기 전에 새로운 커넥션을 받아서 처리할 수 있습니다.

 

Hot restart 아키텍처

envoy는 “hot”, “live” 재시작을 할 수 있습니다. Envoy는 커넥션 유실없이 코드와 설정을 전체 reload할 수 있습니다.

 

• 통계와 락(lock) 정보는 공유 메모리 영역에 저장합니다. 이를 통해 프로세스가 재시작하는 동안에도 일관성을 유지할 수 있습니다.

• 두 프로세스가 기본 RPC 프로토콜을 이용한 유닉스 도메인 소켓을 통해서 서로 통신합니다.

• 이전 프로세스의 소켓 복사본을 요청하기전에 새 프로세스가 초기화를 완벽하게 해 놓습니다. 새 프로세스가 커넥션을 받기 시작하면 이전 프로세스에서 드레이닝(draining)을 시작합니다.

• 드레이닝 단계에서 이전 프로세스는 기존 커넥션을 gracefully하게 종료하려고 시도합니다.

• 드레인이 끝나고나면 새 envoy 프로세스가 이전 envoy 프로세스에거 스스로 종료하라고 말합니다.

• 프로세스간의 통신은 유닉스 도메인 소켓만 사용하기 때문에 hot restart할때 새 envoy 프로세스와 이전 envoy 프로세스가 다른 컨테이너에서 실행중이더라도 제대로 작동합니다. 

 

 

참조 

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/intro/terminology

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/intro/threading_model

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/dynamic_configuration

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/init

https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/hot_restart

https://jvns.ca/blog/2018/10/27/envoy-basics/