Envoy Proxy는 MSA에서 사용하는 서비스 프록시 중 하나로, 서킷 브레이커&타임아웃&인증 같은 애플리케이션의 공통 네트워크 관심사를 인프라 레벨에서 처리해주는 L7 프록시입니다.
핵심 특징으로는 xDS API를 통해 런타임에 설정을 동적으로 반영할 수 있는 점과, 3레벨 필터 구조가 있습니다.
Listener Filter는 커넥션의 프로토콜&SNI 등을 파악해서 정확한 Filter Chain으로 매칭해주고, Network Filiter의 핵심인 HCM(HttpConnectionManager)이 TCP 바이트 스트림을 HTTP 요청으로 파싱한 뒤, HTTP Fileter들이 인증&인가&라우팅 등 L7 로직을 순차적으로 수행합니다.
- Service Mesh 중 1개
- Lyft에서 만들고 CNCF에 졸업 프로젝트로 올라간 L7 Proxy
- C++로 작성되어 있고, 핵심 설계 철학은 "네트워크는 애플리케이션에 투명해야 한다"임.
=> 즉, 앱 코드를 건드리지 않고 네트워크 관심사(라우팅, 보안, 관찰성)를 프록시가 전부 흡수
- Nginx나 HAProxy와 비교하면 가장 큰 차이는 "동적 설정(dynamic configuration)"
=> Ngnix는 설정 변경 시 reload가 통해되지만 Envoy는 "xDS API"를 통해 런타임에 설정이
hot-reload가 됨.
(추가 설명)xDS API
- Listener Envoy가 바인딩하는 "네트워크 주소 + 포트"임.
- 하나의 Envoy 인스턴스에 여러 Listener를 둘 수 있고, "각 Listener에 filter chain"이 붙음
- Filter Chain Listener로 들어온 "커넥션/요청"을 처리하는 파이프라인
=> 크게 세 레벨로 나뉨
1. Listener Filter : 커넥션이 들어오면 TLS 여부, SNI, 프로토콜 종류를 먼저 파악해서
이 커넥션이 어떤 Filter Chain을 타야 되는지 판단해주는 필터
2. Network Filter : TCP 바이트 스트림을 HTTP 요청으로 파싱해서, 안에 있는
HTTP Filter들이 L7 레벨로 요청을 처리할 수 있게 해주는 필터
3. HTTP Filter : Router, RBAC, Rate Limit, JWT Auth, Lua, Wasm 등 L7 로직
[ Filter Chain Listener 통신 흐름 ]
Client
-> Listener (0.0.0.0:15006 inbound / 0.0.0.0:15001 outbound)
-> Listener Filter (TLS 인스펙션, 프로토콜 감지)
-> Filter Chain match (SNI, ALPN, destination port 등으로 매칭)
-> Network Filter: HttpConnectionManager
-> HTTP Filter 1: jwt_authn
-> HTTP Filter 2: rbac
-> HTTP Filter 3: router
-> Route match (path, header 기반)
-> Cluster 선택
-> Load Balancing
-> Endpoint 선택
-> Connection Pool
-> Upsteam 전송
[ HttpConnectionManager 하는 일 ]
- 프로토콜 파싱 기능
- TCP는 "끊김 없는 바이트 덩어리"라서 어디가 헤더이고 어디가 바디인지 경계가 없음
- HCM이 이 바이트를 읽으면서 "GET /api/users HTTP/1.1\\r\\n..." 과 같은 구조를 해석
=> "이게 하나의 HTTP 요청" 인식