[Practice run] CloudCon Talk - I''m Behind 7 Proxies, Demystifying Envoy on Kubernetes, first half

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Kubernetes에서 Envoy를 이해하는 핵심은 이를 수신·판단·확장·전달을 수행하며 제어 평면으로 설정을 갱신하는 모듈형 요청 처리기로 보는 것이다.

📌 핵심 요점

1. Gateway API나 CRD로 Envoy를 사용하는 운영자도 실제 생성되는 설정을 이해하면 추상화 아래의 동작과 활용 가능한 기능을 파악할 수 있다.
2. Bootstrap은 Envoy의 시작 설정이며, 정적 설정을 담거나 외부에서 나머지 리소스를 가져오는 출발점이 된다.
3. Listener는 연결을 수신하고, route는 조건에 따라 동작을 결정하며, cluster는 트래픽을 보낼 업스트림 대상을 구성한다.
4. Filter chain과 HTTP Connection Manager(HCM)가 요청 처리의 중심이다. 네트워크 필터와 HTTP 필터를 조합해 분석·변환·접근 제어 등의 로직을 구성한다.
5. Envoy는 내장 필터와 사용자 정의 확장, 외부 서비스를 활용할 수 있다. 제어 평면과는 gRPC 양방향 스트림으로 리소스를 구독하고 변경 사항을 받는다.

🧩 배경과 문제 정의

이 영상은 Cloud Con Sydney 발표를 위한 연습 영상으로, 동료와 나누어 진행할 발표 중 앞부분을 담는다. 대상은 Kubernetes에 익숙하고 Envoy를 사용하지만, Gateway API나 CRD가 내부적으로 어떤 Envoy 설정을 만드는지는 충분히 알지 못하는 실무자다.

발표자는 Atlassian에서 8년간 근무하며 글로벌 프록시 인프라와 제어 평면을 구축한 경험을 소개한다. 해당 인프라는 단순 전달을 넘어 인가, 요청 제한, 고급 라우팅을 셀프서비스로 제공했다. 이 경험을 바탕으로 Envoy의 핵심 구성 요소와 확장 방식, 제어 평면의 관계를 설명해 내부 동작을 이해할 틀을 제공한다.

🕒 시간순 섹션별 상세정리

1. 발표 목적과 다룰 범위

• Cloud Con Sydney 발표를 연습하며, 제목은 ‘I'm behind seven proxies’, 부제는 Kubernetes에서 Envoy를 이해하는 내용이라고 보여준다. [00:26]
• Envoy를 사용하는 Kubernetes 실무자가 내부 동작을 이해하도록 개념적 틀을 만드는 것이 목표다. 설정과 xDS, bootstrap, 제어 평면을 다룬다. [01:27]

2. 글로벌 프록시 인프라 구축 경험

• 발표자는 Atlassian에서 글로벌 프록시 인프라를 구축하고 제어 평면을 직접 만들었다고 보여준다. CDN과 비슷한 면이 있지만 DDoS 보호 등은 제공하지 않았다고 구분한다. [02:04]
• Envoy로 요청 전달 외에도 인가, 요청 제한, 고급 라우팅을 구현했으며, 사용자가 필요한 동작을 지정하는 셀프서비스 방식으로 제공했다. [02:43]

3. Kubernetes 추상화 아래의 이해 격차

• 예상 청중은 Gateway API나 CRD를 통해 Envoy를 사용하면서, 그 결과 생성되는 설정은 자세히 모르는 운영자다. [03:32]
• 리소스를 추가하면 원하는 동작은 수행되지만, Envoy를 더 잘 이해했을 때 활용할 수 있는 기능은 놓칠 수 있다는 문제를 제기한다. [03:49]

4. Envoy를 이해하는 출발점은 모듈성

• Envoy의 특징을 ‘modular’로 요약하며, 셸 명령을 파이프로 연결하듯 여러 처리 단계를 연결하는 방식에 비유한다. [04:15]
• 문서의 ‘계층 7 프록시이자 통신 버스’라는 설명을 소개한 뒤, 사용 여부와 내부 리소스에 대한 이해를 구분하며 핵심 구성 요소로 넘어간다. [05:25]

5. Bootstrap과 외부 설정의 출발점

• Bootstrap은 동적으로 관리되는 프로세스를 시작하기 위한 비동적 초기 설정이며, 외부 소스가 리소스를 관리할 수 있는 상태로 Envoy를 준비한다. [05:58]
• 많은 설정을 정적으로 담을 수도 있고, node 정의와 나머지 리소스를 가져올 cluster 중심으로 최소화할 수도 있다고 보여준다. [06:20]

6. Listener가 담당하는 연결 수신

• 발표에서 제시한 시작 흐름에서는 node와 제어 평면 cluster를 정의한 뒤 listener를 가져온다. Listener는 요청을 받아들이는 입구다. [06:41]
• Listener는 TLS, 소켓, keepalive, 버퍼 등 연결과 원시 바이트 수준의 관심사를 이해하는 출발점이며, 이 단계에서는 아직 HTTP 헤더 같은 계층 7 정보로 처리하지 않는다고 보여준다. [07:24]
• 받은 바이트를 어떻게 처리할지 별도 지시가 필요하며, 발표자는 처리 구성이 없는 listener를 연결을 받아 닫는 형태로 보여준다. [07:47]

7. Cluster가 담당하는 업스트림 전달

• Cluster는 Kubernetes 클러스터와 구분되는 Envoy 용어로, 트래픽을 보낼 업스트림 대상이나 엔드포인트 묶음으로 드러난다. Envoy는 cluster 이름을 목적지로 사용한다. [08:21]
• Cluster에 포함된 주소와 엔드포인트를 바탕으로 DNS 해석, 상태 확인, 우선순위, 부하 분산을 수행한다. [08:50]
• Bootstrap, listener, cluster를 정리한 뒤, 수신과 전달 사이에 요청을 처리하는 부분이 빠져 있다고 짚어 본다. [09:21]

8. Filter chain으로 채우는 요청 처리 단계

• 빠진 부분은 filter chain이다. 하나의 listener에 여러 chain을 두고 TLS 서버 이름이나 출발지 IP 같은 조건으로 선택할 수 있다. [10:29]
• 선택된 chain의 네트워크 필터가 순서대로 동작하며, 필터를 조합해 요청을 변환하거나 분석할 수 있다는 점이 Envoy를 프로그래밍 가능한 요청 처리기로 만든다. [11:02]

9. HCM, HTTP 필터, 라우팅

• HTTP Connection Manager는 원시 바이트를 HTTP 요청으로 해석하는 네트워크 필터이며, 그 내부에서는 HTTP 필터가 요청에 적용된다. [11:50]
• 라우팅은 일치 조건과 일치했을 때 수행할 동작의 쌍으로 드러난다. HCM은 route를 제어 평면에서 별도로 받아 갱신할 수 있으며, 발표자는 이를 무중단 교체의 장점으로 보여준다. [12:47]
• 전체 흐름을 listener는 수신하고, route는 판단하며, cluster는 전달하는 구조로 정리한다. [13:06]

10. 프로세스 내부 확장과 갱신 방식의 차이

• 내장 필터는 요청 제한, 캐싱, 압축, 역할 기반 접근 제어 등의 기능을 제공하며, 설정을 통해 활성화하는 방식으로 드러난다. [14:17]
• 사용자 정의 로직은 Lua 스크립트, Go나 Rust 등으로 작성하는 WASM 모듈, 시작 시 로딩하는 dynamic module로 구현할 수 있다. [14:53]
• 발표자는 Lua·WASM을 제어 평면이나 데이터 소스로 전달해 런타임에 다시 로딩할 수 있지만, dynamic module은 실행 중 교체할 수 없다고 보여준다. [15:14]

11. 외부 서비스로 분리하는 확장

• 외부 인가 서비스는 HTTP 요청 문맥을 받아 허용 여부를 결정하고, 외부 처리 서비스는 보다 일반적인 요청 변경 로직을 수행한다. [16:19]
• 외부 처리의 관찰 모드에서는 Envoy가 응답을 기다리지 않는 비차단 요청을 보내며, 분석이나 WAF·보안 서비스에 트래픽 정보를 제공하는 용도를 제시한다. [16:50]
• 공개 구현을 사용하거나 Protobuf에서 gRPC 스텁을 생성해 직접 구현할 수 있다. 별도 배포가 가능하므로 프록시 인프라팀과 보안팀이 각자 담당 서비스를 운영하는 구조도 가능하다. [17:35]

12. 제어 평면과 최종 개념 정리

• Envoy 설정은 Protocol Buffers로 정의되며, 이름을 가진 리소스를 개별적으로 가져오고 다시 로딩하는 구조라고 보여준다. 일부 상황에서는 리소스를 무중단으로 교체할 수 있다고 덧붙인다. [18:59]
• Envoy는 제어 평면과 gRPC 양방향 스트림을 열어 필요한 리소스를 구독하고, 이후 변경 사항이 전달되기를 기다린다. [19:22]
• 마지막으로 Envoy를 계층 7에서 요청을 수신·판단·확장·전달하는 프로그래밍 가능한 요청 처리기로 정리하고, 동료 Jacob에게 발표를 넘긴다. [19:49]

🧾 결론

• 발표를 관통하는 관점은 Envoy를 프로그래밍 가능한 요청 처리기로 이해하는 것이다.
• 수신하는 listener, 판단하는 route, 전달하는 cluster를 먼저 구분하면 필터와 확장이 어디에 개입하는지 이해하기 쉬워진다.
• 설정 리소스를 개별적으로 갱신하는 구조는 동적 운영의 기반이며, 발표자는 일부 상황에서 무중단 교체가 가능하다고 설명한다.
• 확장 방식은 필요한 기능뿐 아니라 실행 위치, 런타임 갱신 가능성, 배포 책임까지 함께 고려해 선택해야 한다.

📈 투자·시사 포인트

• 인프라 투자 판단에서는 Envoy가 제공하는 인증·인가 연계, 요청 제한, 라우팅 기능을 현재 얼마나 활용하고 있는지 살펴볼 수 있다. 발표자의 사례에서는 이러한 기능을 셀프서비스로 제공했다.
• 운영 역량 측면에서는 Kubernetes 리소스와 실제 Envoy 설정 사이의 관계를 이해중요하다. 추상화의 사용법과 내부 요청 처리 구조를 함께 익힐 필요가 있다.
• 조직 설계 측면에서는 외부 확장 서비스를 별도로 배포하는 구조가 프록시 인프라팀과 보안팀의 책임을 나누는 선택지가 된다.
• 확장 기술을 평가할 때는 발표에서 제시한 런타임 재로딩과 네이티브 실행의 차이를 도입 기준에 포함할 수 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 제목의 ‘7 Proxies’에 대응하는 실제 일곱 단계의 프록시 구성은 제공된 전사에서 설명되지 않는다. 제목만으로 배포 구조를 추정하기 어렵다.
• 발표자는 listener를 먼저 가져오고 cluster를 가져오는 흐름으로 설명하지만, 구체적인 설정 예제나 xDS 교환 내역은 제시하지 않는다. 이 설명을 모든 구성의 고정된 순서로 일반화할 근거는 부족하다.
• 무중단 갱신은 일부 상황에서 가능하다는 설명이다. 리소스 종류별 조건, 실패 시 동작, 기존 연결에 미치는 영향은 다루지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 사용하는 Gateway API 또는 CRD가 생성하는 Envoy 설정에서 listener, route, cluster의 대응 관계를 확인한다.
• Bootstrap에서 정적으로 정의한 항목과 제어 평면에서 가져오는 항목을 구분한다.
• 대표 요청 하나를 골라 filter chain 선택, HCM 처리, HTTP 필터 적용, 라우팅, 업스트림 전달 순서로 추적한다.
• 필요한 기능을 내장 필터, Lua·WASM, dynamic module, 외부 서비스 중 어떤 방식으로 구현할지 비교한다.

❓ 열린 질문

• 현재 사용하는 Kubernetes 추상화는 Envoy의 어떤 기능을 노출하며, 어떤 설정은 직접 제어하기 어려운가?
• 인가나 요청 변환 로직을 Envoy 내부에 둘지 외부 서비스로 분리할지 결정하는 기준은 무엇인가?
• 어떤 리소스 변경까지 무중단으로 적용할 수 있으며, 이를 운영 환경에서 어떻게 확인할 것인가?