🚀 MSA 좀 한다는 회사들이 전부 '이것'을 쓰는 진짜 이유 (feat. Envoy Proxy)

요즘 클라우드 네이티브나 마이크로서비스 아키텍처(MSA)에 대해 이야기할 때, 절대 빠지지 않고 등장하는 이름이 있습니다. 바로 Envoy Proxy인데요. "그냥 프록시 아냐?"라고 생각하셨다면, 오늘 이 글을 통해 MSA 환경의 복잡한 통신 문제를 해결하는 Envoy의 숨겨진 잠재력을 발견하게 되실 겁니다. 왜 Envoy가 단순한 프록시를 넘어 클라우드 네이티브의 '표준'으로 자리 잡았는지, 그 핵심 비결을 낱낱이 파헤쳐 보겠습니다.

---

🤯 왜 우리는 새로운 프록시가 필요했을까?

과거의 애플리케이션은 하나의 거대한 덩어리(Monolithic)로 만들어졌습니다. 하지만 MSA 환경에서는 기능들이 수십, 수백 개의 작은 서비스로 쪼개져 서로 통신하죠. 이 구조는 유연하고 확장하기 좋지만, 네트워크는 그야말로 거미줄처럼 복잡해집니다.

• 서비스 A가 서비스 B를 어떻게 찾아가야 할까? (Service Discovery)
• 갑자기 서비스 B의 하나가 죽으면 어떻게 하지? (Resilience)
• 서비스 간 통신은 안전한가? (Security)
• 어디서 병목이 생기는지 어떻게 알지? (Observability)

이런 문제들을 모든 개발팀이 각자의 서비스 코드에 구현한다면? 끔찍한 중복과 비효율이 발생할 겁니다. 바로 이 지점에서 Envoy가 등장합니다.

1. 차원이 다른 속도와 효율성: C++과 비동기 처리 🚀

Envoy의 가장 큰 무기는 바로 성능입니다.

• C++ 기반: 시스템 레벨에서 하드웨어를 최대한 활용할 수 있는 C++로 작성되어 매우 빠릅니다.
• 비동기 이벤트 기반 아키텍처: 적은 수의 스레드로 수많은 동시 연결을 효율적으로 처리합니다. 이는 곧 적은 메모리와 CPU 자원으로도 높은 처리량을 보장한다는 의미입니다.

기존 프록시들이 하나의 연결마다 하나의 스레드를 할당하며 리소스를 많이 소모했던 것과 달리, Envoy는 MSA 환경처럼 수많은 서비스 간의 자잘하고 빈번한 통신을 처리하는 데 최적화되어 있습니다. 지연 시간이 짧고 리소스 사용량이 적다는 것은 곧 비용 절감과 직결되죠.

2. 서비스 재시작 없는 설정 변경: 동적 구성 (xDS API) 🔄

기존 프록시(Nginx, HAProxy 등)의 가장 큰 고통은 설정 변경이었습니다. 라우팅 규칙 하나를 바꾸려고 해도 설정 파일을 수정하고 서비스를 재시작해야 했죠. 잠깐의 다운타임이라도 발생하면 큰일 나는 서비스 환경에서는 치명적이었습니다.

Envoy는 이 문제를 xDS API라는 혁신적인 방법으로 해결합니다. x는 Listener(LDS), Route(RDS), Cluster(CDS), Endpoint(EDS) 등을 의미하며, 이 API들을 통해 Envoy는 중앙 관리 시스템(Control Plane)으로부터 설정을 동적으로 받아옵니다.

 

🤔 이게 왜 중요할까요?

컨테이너 환경에서는 서비스의 IP나 개수가 수시로 변합니다. 새로운 버전의 서비스가 배포되거나, 트래픽에 따라 서비스가 자동으로 늘어나고 줄어들죠(Auto-scaling). Envoy는 이런 변경사항을 API를 통해 실시간으로 전달받아 자신의 동작을 즉시 바꿀 수 있습니다. 서비스 재시작? 다운타임? 전혀 필요 없습니다.

xDS 동작 방식 엿보기

Envoy가 어떻게 동적으로 설정을 받아오는지 간단한 시나리오로 살펴볼까요?

1. Envoy는 시작될 때 Control Plane에 어떤 Listener(포트)를 열어야 하는지 물어봅니다. (LDS 요청)
2. Control Plane은 "80번 포트를 열고, 들어오는 트래픽은 my-service-routes 규칙을 따라 처리해"라고 응답합니다.

✅ Control Plane이 Envoy에 보내는 응답 (LDS 예시)

# Control Plane이 생성하여 Envoy에 전달하는 데이터
resources:
- "@type": type.googleapis.com/envoy.config.listener.v3.Listener
  name: listener_0
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 80
  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
        # 라우팅 규칙은 'my-service-routes'를 참조해서 동적으로 가져와! (RDS)
        rds:
          route_config_name: my-service-routes
          config_source:
            api_config_source:
              api_type: GRPC
              grpc_services:
                - envoy_grpc:
                    cluster_name: xds_cluster
        http_filters:
        - name: envoy.filters.http.router

 

위 설정은 Envoy에게 "80번 포트를 열고, 상세 라우팅 규칙은 my-service-routes라는 이름으로 다시 물어봐(RDS)"라고 지시합니다. 이런 식으로 필요한 설정을 연쇄적으로 받아와 스스로를 구성하는 것입니다. 정적 설정 파일의 시대는 이제 끝났습니다.

3. 서비스 메시의 심장: 데이터 플레인 🕸️

Istio, AWS App Mesh 같은 서비스 메시(Service Mesh)를 들어보셨나요? 이 서비스 메시의 실제 통신을 담당하는 핵심 부품(Data Plane)이 바로 Envoy입니다.

서비스 메시는 각 마이크로서비스 컨테이너 옆에 Envoy 프록시를 사이드카(Sidecar) 형태로 함께 배포합니다. 그러면 서비스에서 나가고 들어오는 모든 네트워크 트래픽은 애플리케이션 코드 수정 없이 자동으로 이 Envoy를 거치게 됩니다.

이렇게 모든 통신을 가로챈 Envoy는 서비스 메시의 중앙 제어 시스템(Control Plane)의 지시를 받아 다음과 같은 마법 같은 기능들을 제공합니다.

• 고급 트래픽 관리: 일부 사용자에게만 새 버전을 공개하는 카나리 배포, A/B 테스팅, 의도적으로 장애를 주입해 시스템의 안정성을 테스트하는 장애 주입(Fault Injection) 등을 코드 한 줄 없이 구현할 수 있습니다.
• 강력한 보안: 모든 서비스 간 통신을 자동으로 암호화(mTLS)하고, 특정 서비스만 통신을 허용하는 등의 세밀한 인증/인가 정책을 적용합니다.

4. 문제 추적의 신: 압도적인 관측 가능성 📊

수백 개의 서비스가 얽혀있는 환경에서 장애가 발생하면 원인을 찾는 것은 모래사장에서 바늘 찾기입니다. Envoy는 관측 가능성(Observability)의 3요소를 완벽하게 지원하도록 설계되었습니다.

1. 메트릭 (Metrics) 📈: 요청 횟수, 성공/실패율, 응답 시간 등 모든 트래픽에 대한 상세한 통계 데이터를 숫자로 제공합니다. Prometheus 같은 모니터링 툴과 연동하여 시스템 상태를 한눈에 파악할 수 있습니다.
2. 추적 (Tracing) 🕵️: 하나의 사용자 요청이 여러 마이크로서비스를 거쳐가는 전체 여정을 추적합니다. Jaeger, Zipkin과 연동하여 어떤 서비스에서 병목이 발생하거나 에러가 났는지 시각적으로 확인할 수 있습니다.
3. 로깅 (Logging) 📝: 모든 요청/응답에 대한 상세한 엑세스 로그를 남겨 디버깅에 결정적인 단서를 제공합니다.

애플리케이션 개발자는 그저 비즈니스 로직에만 집중하면 됩니다. 골치 아픈 네트워크 관측 가능성은 Envoy가 모두 처리해주니까요.

5. 무한한 확장성: 필터 체인과 WASM 🧩

Envoy는 필터 체인(Filter Chain)이라는 유연한 구조를 가지고 있습니다. 네트워크 요청이 들어오면, 마치 컨베이어 벨트처럼 여러 필터를 순서대로 거치면서 처리됩니다.

[인증 필터] -> [속도 제한 필터] -> [라우팅 필터]

이 구조 덕분에 우리는 필요한 기능을 필터 형태로 만들어 쉽게 끼워 넣을 수 있습니다. 예를 들어, 자체 인증 시스템을 연동하는 필터나, 데이터를 변환하는 커스텀 필터를 추가할 수 있죠.

최근에는 WebAssembly(WASM)를 지원하면서 Go, Rust 등 C++가 아닌 다른 언어로도 확장 필터를 개발할 수 있게 되어 확장성이 더욱 강력해졌습니다.

6. 누구에게도 종속되지 않는 자유: 플랫폼 독립성 🌍

Envoy는 특정 클라우드 회사나 기술에 종속되지 않습니다. 쿠버네티스를 관리하는 CNCF(Cloud Native Computing Foundation)의 최상위 등급(Graduated) 프로젝트라는 사실이 이를 증명합니다. 이는 기술적 성숙도와 커뮤니티의 활성도를 공식적으로 인정받았다는 의미이며, 전 세계 수많은 기업이 안심하고 Envoy를 도입하는 배경이 됩니다.

---

✨ 결론: Envoy는 단순한 프록시가 아니다

정리하자면, Envoy는 단순히 빠른 프록시가 아닙니다. 동적으로 변화하는 클라우드 네이티브 환경의 복잡한 네트워크 문제를 해결하기 위해 태어난 '네트워크 자동화 플랫폼'에 가깝습니다.

 

고성능, 동적 구성, 관측 가능성, 확장성이라는 강력한 특징들이 유기적으로 결합되어, 오늘날 서비스 메시의 핵심 엔진이자 MSA 환경의 사실상 표준(de facto standard)으로 자리 잡게 된 것입니다. 만약 당신이 클라우드 네이티브의 세계를 탐험하고 있다면, Envoy는 반드시 알아야 할 필수 기술입니다.